Oh no, there is no victory. Your summary is pretty good here. But the idea that Linux is provably less secure because old bugs were found is flatly wrong. They were found late, but they were indeed found. How many ancient bugs are lurking in proprietary software that nobody has found for positive reasons and made full disclosures of so affected parties know they need to mitigate? Nobody knows!

Server OSes are more likely to have older versions of software and then backport fixes. Desktop OSes are more likely to default to doing automatic updates, or at least hassling the user to do them.

I was hoping at the bottom of the article it would say that Professor Utonium accidentally added Chemical X.

The fines should be proportional to actual damage caused (ie: 100% coverage of any interest on loans, any extra spending the person needed to do in consequence, loss of compound interest, damage to credit rating along with any additional spending this resulted in, and any medical costs that can reasonably be attributed to stress/anxiety). It would be difficult to get an exact figure per person, but a rough estimate of probable actual damage would be sufficient. Add that to the total direct loss - not the money that went through any individual involved, and THEN double that total. This becomes the minimum, not the maximum. You then allow the jury to factor in emotional costs on top of that.

In such cases as this, the statutary upper limit on fines should not apply. SCOTUS has repeatedly ruled that laws and the Constitution can have reasonable exceptions and this would seem to qualify.

If a person has died in the meantime, where the death certificate indicates a cause of death that is medically associated with anxiety or depression, each person invovled should also be charged with manslaughter per such case.

The only difference is that servers are more likely to have more outdated software.

Love of convenience, I guess. I often find it astonishing myself. The software might do 100 times more but it takes 1000 times as much memory...

How granular would the permission be? If web browsers start blocking all animation and post-load layout shifting by default, including CSS transitions and animations, this would encourage website operators to structure the page to coerce permission to animate in each document. For example, a website operator could make each page load blank other than a notice to the effect "Tap or click to view 'Title of Article' on Name of Site."

In my experience on laptops and tablets, I've found the exact opposite (eager loading) helpful in some situations with limited or no data. I would download an entire page on unmetered Wi-Fi, go offline, and read while riding as a passenger in a car or bus.

I sincerely doubt that 14,500 USD per year (full-time minimum wage) is near enough to pay for income tax, rent, food, health insurance, and a round-trip taxi ride every weekday in most of the United States. I'd be interested to read examples of budgets that you have in mind.

Linux underpins the internet. It's the primary server OS on the planet. High-value data is held on Linux systems. The idea that it's not profitable to attack those targets is silly. They're harder to attack. People still do it. That's why there are still ssh port scans for example.

Ontogeny recapitulates phylogeny.

It is, but IME a lot of software needs architectural changes to work on it, similar to when you're trying to build software for Windows in cygwin. That's one reason I decided it wasn't worth the hassle back when I was running it.

When it comes to being allowed to do what you want with your computer, it's a lot more like Windows than it is like Linux. And it's been getting worse.

Now tell us how many similar bugs are in Windows, and will be found even without the obscurity of closed source. You don't know, because you depend on Microsoft to tell you when they fuck up, but you're declaring this a victory for Microsoft anyway? Do fucking tell.

No, 2MB was never enough for a Linux desktop. I had 8MB on my 386 and it was only just sufficient.