thyristan

I'd wager that we couldn't be, even back in the 1992 USSR collapse. I'd guess a few are gone missing, and they didn't tell the world, or didn't even notice.

> And pick-ups are very unpopular here, unless you're a farmer there's no point in such a large open loading bed.

And even if you are a farmer, an american pick-up seems to be a rare choice around here. If you see something pick-up-like, it's usually more a variant of UniMog https://en.wikipedia.org/wiki/Unimog .

And for the "small-time farmer without enough money to buy lots of equipment" (rare nowadays), tractors with tons of included functions were often more practical: https://de.wikipedia.org/wiki/Fendt_GT (no english version, sorry). Since Germany is more dense and distances are smaller, low speed is less of an issue I guess, compared to the US. And you can pull real farm equipment, which a pick-up car usually cannot.

The safety of titanium dioxide is somwhat in doubt and it is suspected to be carcinogenic (in Europe at least): https://www.bfr.bund.de/en/service/frequently-asked-question...

Docker != podman. Entirely different.

With podman, RedHat made an effort to make SElinux work. With Docker, as third-party-software, no proper SElinux config was ever written. With Docker, there is no hope at all that you'd get SElinux to work.

With podman, there is hope, as long as all your containers and usecases are simple, "well-behaved" and preferrably also RedHat-based and SElinux-aware. In the easy cases, podman + SElinux will just work. But unfortunately, containers are the means to get crappy software running, where the developers were too lazy to do proper packaging/installation/configuration/integration. So most cases are not easy and will not work with SElinux, if you don't have infinite time to write your own config...

Yes, but the reason for that pain is SElinux. The first, second and third law of RedHat sysadmin work is "disable SElinux".

For a stream, you use a sliding window to compute the FFT. The size of the window of course limits the lowest frequency range that you can 'see', same for the highest frequency through the time quantization that digital data usually has. So there will be an upper and lower frequency limit, beyond those limits the results are meaningless.

And the window of course creates a latency, which is sometimes relevant for realtime audio filtering by FFT.

In the same vein one could argue that Therac-25 was not actually a software bug but a hardware problem. Interlocks, that could have prevented the accidents and that where present in earlier Therac models, were missing. The software was written with those interlocks in mind. Greedy management/hardware engineers skipped them for the -25 version.

It's almost never just software. It's almost never just one cause.

Maybe, maybe not. Antibiotic resistance develops because antibiotics are only somewhat deadly to bacteria, so natural selection can occur and bacteria develop resistance over time. There are some antibiotic/bacteria combinations where this doesn't happen, because the respective antibiotic is so deadly to that special kind of bacteria, that no survivors can pass on their slightly increased resistance.

And bacteria self-replicate, whereas a virus needs to infect a cell and be reproduced by that cell. Some antiviral mechanisms attack the reproduction proteins that the human cells use, which the virus cannot do without. And the human cells don't have reproductive pressure to replicate viruses, quite the contrary.

Waterfall is a caricature straw man process where you can never ever go back to the drawing board and change the requirements or specifications. The defining characteristic is the part where design up front, you can never go back and really really have to do everything in strict order for the whole of the project.

Just having requirements and a specification isn't necessarily waterfall. Almost all agile processes at least have requirements, the more formal ones also do have specifications. You just do it more than once in a project, like once per sprint, story or whatever.

Even with this change, Android is still more free than iOS by far.

You've got to be kidding. Doesn't work, Apple is even more locked down than what this article announces. No sideloading whatsoever, signature checks ala Play Protect are mandatory and cannot be switched off, no alternative app stores, etc.

Different situation. You already had a product that they were quite happy with, and that worked well for them. So they saw change as a problem, not a good thing. They weren't waiting for anything new, or anything to improve, they were happy on their couch and you made them move to redo the upholstery.

> How about the tons of products we don't even see? Those that tried to do it right on the first try, then never delivered anything because there were too slow and expensive.

I would welcome seeing a lesser amount of new crappy products.

That dynamic leads to a spiral of ever crappier software: You need to be first, and quicker than your competitors. If you are first, you do have a huge advantage, because there are no other products and there is no alternative to your crapware. Coming out with a superior product second or third sometimes works, but very often doesn't, you'll be an also-ran with 0.5% market share, if you survive at all. So everyone always tries to be as crappy and as quick as possible, quality be damned. You can always fix it later, or so they say.

But this view excludes the users and the general public: Crapware is usually full of security problems, data leaks, harmful bugs that endanger peoples' data, safety, security and livelihood. Even if the product is actually useful, at first, in the long term the harm might outweigh the good. And overall, by the aforementioned spiral, every product that wins this way damages all other software products by being a bad example.

Therefore I think that software quality needs some standards that programmers should uphold, that legislators should regulate and that auditors should thoroughly check. Of course that isn't a simple proposition...

It only takes one tiny vibe-coded insecure extension to a pre-existing codebase (that might have been good secure code), to turn the whole thing into a catastrophe.

It's basically the same as in other parts of IT security: It only takes one lost root password, one exploited software/device/oversight, one slip, to let an attacker in (yes, defense-in-depth architecture might help, but nonetheless, every long exploit-chain starts with the first tiny crack in the armor).

Well, actually there could be a separate step: understanding is done during and after gathering requirements, before and while writing specifications. Only then are specifications turned into code.

But almost no-one really works like that, and those three separate steps are often done ad-hoc, by the same person, right when the fingers hit the keys.

Everything takes longer than ppl want to wait. But when building a house, ppl are more patient and tolerant about the time taken, because they can physically see the progress, the effort, the sweat. Software is intangible and invisible except maybe for beta-testers and developer liaisons. And the visual parts, like the nonfunctional GUI or web UI, are often taken as "most of the work is done", because that is what people see and interact with.

The alternative is obviously: Do it right on the first try.

How much of a problem it is can be seen with tons of products that are crap on release and only slowly get patched to a half-working state when the complaints start pouring in. But of course, this is status quo in software, so the perception of this as a problem among software people isn't universal I guess.

> [create prototype], then throw out the code and write a proper solution.

Problem is, that in everyones' experience, this almost never happens. The prototype is declared "good enough, just needs a few small adjustments", rewrite is declared too expensive, too time-consuming. And crap goes to production.

> it is sensible to speak of the statement "this parameter's value is zero" as either true or false.

Nope. The correct way is rather something like "the measurements/polls/statistics x ± ε are consistent with this parameter's true value to be zero", where x is your measured value and ε is some measurement error, accuracy or statistical deviation. x will never really be zero, but zero can be within an interval [x - ε; x + ε].

There is a known maximum error introduced by those simplifications. Put the other way around, Einstein is a refinement of Newton. Special relativity converges towards Newtonian motion for low speeds.

You didn't really miss anything. The article is incomplete, and wrongly suggests that something like "false" even exists in statistics. But really something is only false "with a x% probability of it actually being true nonetheless". Meaning that you have to "statistic harder" if you want to get x down. Usually the best way to do that is to increase the number of tries/samples N. What the article gets completely wrong is that for sufficiently large N, you don't have to care anymore, and might as well use false/true as absolutes, because you pass the threshold of "will happen once within the lifetime of a bazillion universes" or something.

Problem is, of course, that lots and lots of statistics are done with a low N. Social sciences, medicine, and economy are necessarily always in the very-low-N range, and therefore always have problematic statistics. And try to "statistic harder" without being able to increase N, thereby just massaging their numbers enough to get a desired conclusion proved. Or just increase N a little, claiming to have escaped the low-N-problem.

Very cool. Having something to fill forms and sign them that works and isn't Acroread would be even more awesome than you project already is!

It doesn't matter if it is exact or not. It is a problem that people may think it looks line a swastika.

Certain places in Europe, for example Austria and Germany, are far more sensitive in those regards, for obvious historical reasons. You really don't want to be associated even remotely with those kinds of things. Even if the similarity isn't sufficient to land you in jail, it will lead to weird looks, social ostracism, loss of business and jobs, hostile behaviour, and increased attention by the authorities.

If you never want to do business or live in central Europe, fine, ignore all that. I know that the rest of the world is more relaxed. But just as USian sensitivities sometimes induce a heated discussion about why a visible nipple isn't actually harmful, this is one of those topics from the European perspective.

> How exactly do NULL ciphers accomplish enterprise monitoring goals?

I don't understand how this isn't obvious. Unencrypted means it is monitorable.

Then please prove the possibility by doing so.

Up to now, there has only been intense wishful thinking by politicians, and strong "NOPE" by anyone with any kind of knowledge about cryptography. Either really everyone, including the likes of NSA, CIA and other spy services don't actually employ top cryptographers. Or they repeatedly tried and failed miserably. Or really nobody, including the spies, wants backdoored NOBUS encryption.

But it is. In those European countries, IDPs and certification authorities are one and the same entity. So the technical requirement of privacy evaporates, the government will always know who is proving their age to which porn site.

Yes, my first link is about that. It illustrates and explains the push to weaken TLS1.3 that has later been accomplished by the re-inclusion of NULL ciphers.

And all the earlier weaker ciphers were explicit device configuration as well. You could configure your webserver or client not to use them. But the problem is that there are easy accidental misconfigurations like "cipher-suite: ALL", well-intended misconfigurations like "we wan't to claim IoT support in marketing, so we need to enable IoT-'ciphers' by default!" and the sneaky underhanded versions of the aforementioned accidents. Proper design would actually just not create a product that can be mishandled, and early TLS1.3 had that property (at least with regards to cipher selection). Now it's back to "hope your config is sane" and "hope your vendor didn't screw up". Which is exactly what malicious people need to hide their intent and get in their decryption backdoors.

Thought this was common knowledge. When TLS1.3 was standardized, it explicitly left out all NULL and weak (such as RC4) ciphers. It also left out all weaker RSA/static-DH key exchange methods, such that easy decryption of recorded communication became impossible. To that the enterprises who would like to snoop on their employees and the secret services who would like to snoop on everyone reacted negatively and tried to introduce their usual backdoors such as NULL ciphers again:

https://www.nist.gov/news-events/news/2024/01/new-nccoe-guid... with associated HN discussion https://news.ycombinator.com/item?id=39849754

https://www.rfc-editor.org/rfc/rfc9150.html was the one reintroducing NULL ciphers into TLS1.3. RFC9150 is written by Cisco and ODVA who previously made a fortune with TLS interception/decryption/MitM gear, selling to enterprises as well as (most probably, Cisco has been a long-time bedmate of the US gov) spying governments. The RFC weakly claims "IoT" as the intended audience due to cipher overhead, however, that is extremely hard to believe. They still do SHA256 for integrity, they still do all the very complicated and expensive TLS dance, but then skip encryption and break half the protocol on the way (since stuff like TLS1.3 RTT needs confidentiality). So why do all the expensive TLS dance at all when you can just slap a cheaper HMAC on each message and be done? The only sensible reason is that you want to have something in TLS to downgrade to.

There was a computer game by that name based on the film: https://en.wikipedia.org/wiki/Firefox_(video_game)

NULL ciphers in TLS are intended to enable downgrade attacks. Nothing else.

Same thing with weaker ciphers. They are a target to downgrade to, if an attacker wishes to break into your connection.

Never had a problem with them. Just put each node in maintenance, migrate the VMs to another node, update, move the VMs back. Repeat until all nodes are updated.