People just don’t want to believe that China can win at capitalism because it undermines all their internal narratives around the innovation power of liberalism. I say this as someone who does not personally like China and its authoritarianism.

The fact of the matter is with a population of nearly 1.5 billion people, you’re statistically guaranteed to have enormous pools of talent to draw on. Even a relatively modest per capita investment in education, focused on key objectives and funneled into the portion of the talent pool that they’ve managed to identify, will be able to yield massive innovation.

A lot of people will suffer under this authoritarianism. The people from these talent pools will be exploited and burnt out at a young age. This is already happening in China. But as a nation, it will be able to position itself extremely well technologically and economically, and this is a reality the rest of the world needs to be prepared to deal with.

Which is exactly the position that the Rust for Linux devs have understood and accepted for themselves, and yet they still get yelled at (literally, in public, on recordings) by C Linux devs for existing.

Oh and they get snidely told that introducing the Rust language must be a mistake because suggestions to introduce other languages to the kernel turned out to be mistakes and obviously Rust is the same as all those other languages according to C developers who, by their own admission, have never used or learned anything about Rust beyond a superficial glance at some of its syntax (again this was recorded from a public event).

PG&E was literally the villain in the real life Erin Brockovich story.

Nothing is ever better in every conceivable way than the current state of the art.

Probabilistically, sure, but it’s not impossible that there has been some piece of knowledge or understanding that’s been missing, and that massive breakthroughs are possible once the process is figured out.

I think a fair modern example is LED light bulbs. They are better in every conceivable way than incandescent or fluorescent lightbulbs: they last longer, use less energy, shine brighter, use less toxic materials, and are easy to mass produce. But there were several decades where much of the industry believed that LEDs would never be very useful as a light source because we could only produce red and green, and it was generally believed that a blue LED would be impossible to produce.

Then one guy decided it would be his life mission to invent the blue LED, and the sonuvabitch did it. Now LEDs are the only sensible thing to use to produce light.

It’s always possible for this kind of breakthrough to happen, especially in material science where the complexity of how molecules interplay is nearly incomprehensible.

I don’t doubt that in this case it’s both silly and unacceptable that their driver was having this catastrophic failure, and it was probably caused by systemic failure at the company, likely driven by hubris and/or cost-cutting measures.

Although I wouldn’t take it as a given that the system should be allowed to continue if the anti-virus doesn’t load properly more generally.

For an enterprise business system, it’s entirely plausible that if a crucial anti-virus driver can’t load properly then the system itself may be compromised by malware, or at the very least the system may be unacceptably vulnerable to malware if it’s allowed to finish booting. At that point the risk of harm that may come from allowing the system to continue booting could outweigh the cost of demanding manual intervention.

In this specific case, given the scale and fallout of the failure, it probably would’ve been preferable to let the system continue booting to a point where it could receive a new update, but all I’m saying is that I’m not surprised more generally that an OS just goes ahead and treats an anti-virus driver failure at BSOD worthy.

When talking about the driver level, you can’t always just proceed to the next thing when an error happens.

Imagine if you went in for open heart surgery but the doctor forgot to put in the new valve while he was in there. He can’t just stitch you up and tell you to get on with it, you’ll be bleeding away inside.

In this specific case we’re talking about security for business devices and critical infrastructure. If a security driver is compromised, in a lot of cases it may legitimately be better for the computer to not run at all, because a security compromise could mean it’s open season for hackers on your sensitive device. We’ve seen hospitals held random, we’ve seen customer data swiped from major businesses. A day of downtime is arguably better than those outcomes.

The real answer here is crowdstrike needs a more reliable CI/CD pipeline. A failure of this magnitude is inexcusable and represents a major systemic failure in their development process. But the OS crashing as a result of that systemic failure may actually be the most reasonable desirable outcome compared to any other possible outcome.

I think a long time ago a vicious cycle began in the advertising space where predatory ads had more incentive to pay for ad space, so sensible people start to perceive ads in general as predatory. Now no sensible advertiser that’s trying to promote a legitimate product for legitimate reasons will do so by buying ad space, thus reinforcing the increasingly accurate perception that all ads are predatory.

He absolutely has not.

There are two big problems with the point that you’re trying to make:

1. There are many open source projects being run by organizations with as much (often stronger) governance over commit access as a private corporation would have over its closed source code base. The most widely used projects tend to fall under this category, like Linux, React, Angular, Go, JavaScript, and innumerable others. Governance models for a project are a very reasonable thing to consider when deciding whether to use a dependency for your application or library. There’s a fair argument to be made that the governance model of this xz project should have been flagged sooner, and hopefully this incident will help stir broader awareness for that. But unlike a closed source code base, you can actually know the governance model and commit access model of open source software. When it comes to closed source software you don’t know anything about the company’s hiring practices, background checks, what access they might provide to outsourced agents from other countries who may be compromised, etc.

2. You’re assuming that 100% of the source code used in a closed source project was developed by that company and according to the company’s governance model, which you assume is a good one. In reality BSD/MIT licensed (and illegally GPL licensed) open source software is being shoved into closed source code bases all the time. The difference with closed source software is that you have no way of knowing that this is the case. For all you know some intern already shoved a compromised xz into some closed source software that you’re using, and since that intern is gone now it will be years before anyone in the company notices that their software has a well known backdoor sitting in it.