> like a person still proud in 2026 that they are still using Vim for large projects.
I remember a small competition where people do a well-defined "share this content to others" routine to showcase how OS A is way more intuitive than OS B. There was also an OS C, which was way slower than A&B. Then, someone came using OS C, topped the chart with a sizeable time difference.
The point is, sometimes mastery pays back so much that, while there's theoretically better ways to do something, the time you save from that mastery is enough of a reason to not to leave the tool you're using.
I also have a couple of "odd" tools that I use and love, which would cause confused looks from many people. Yet, I'm fast and happy with them.
Yes, but if a car is using regenerative braking 99% of the time, the car should track this and use brakes occasionally to "polish and maintain" them. It's not hard, and if the pads are running out, it should warn the user. Tesla does neither AFAIK.
You should check your tires, yes. At least while changing from winter to summer and vice versa, however if the cars torque profile is too aggressive and it's eating tires, you should note it at the user's manual that thread wear should be checked more frequently with respect to other cars.
> how is that to do with Tesla manufacturing standard?
My friend's Toyota Auris needs new discs every 100,000KM, new pads every 60,000KM. I change discs around 60,000KM (heavier car, mostly rush-hour traffic, hilly city, automatic transmission), and never failed an inspection w.r.t. braking power.
Most of the people are bashing Tesla because they 1) Overpromised and underdelivered 2) They claimed/acted like they're so ahead that nobody can touch them.
Now, other automakers are closing the gap fast, and their overpromise of camera-only FSD is reaching Duke Nukem Forever levels, while other automakers use a diversified sensor set with more conservative autonomy levels because they value human lives more than playing fast and loose (plus, they are scrutinized way more heavily for various right and wrong reasons).
For me, it's not hatred, but I saw that they were hyped a bit too much and need some correction, and this correction is coming hard for them.
Valuations means nothing except investor trust. We have seen some spectacular collapses under unbelievable valuations. Theranos had a valuation of $9 billion. Tesla is not a scam or balloon per se, but they were a bit too overconfident of their moat.
The elephant Tesla mocked has run, and stomped over them. Now there comes the pivot.
While "The old auto establishment" is not a benevolent structure, they proved that experience is something earned with time and doing things. Corporate knowledge and memory is real, and you can't beat it with brute force.
They started the change, but they failed to keep up with the pace. Also hubris, greed and monies.
I don't really get this take... not when Tesla is by a wide mile the world's most valuable automaker. How does Tesla ending production of the S and X equate to the old auto establishment "stomping over them"?
Worth related statistics doesn't mean anything in the realm of hard engineering. I completely look from the point of "what the companies are doing tech-wise".
When Tesla came about, they were distinctively different. A different chassis, a different weight distribution, completely different dynamics. Since they started with a blank slate, their cars were greenfield projects, and they correctly took note of the pitfalls, and avoided them.
On the other hand, avoiding past pitfalls or remedying them doesn't make you immune from the future ones, and doesn't mean the other companies can't learn, too. This is where they made the mistake.
They overpromised (esp. with the Autopilot thingy) and underdelivered massively on that front, and while they "made" the software-defined-vehicle, they underestimated the problems and behaved like the problems they face are as simple as configuring a web service right. This is what slowly broke them. They also underestimated hardware problems of the car (like using consumer grade parts in the critical parts of the hardware. Remember wearing down flash chips and bricking cars?)
Because while car is software defined now, it's also an "industrial system". It has to be robust. It has to be reliable, idiot-proof even. Playing fast and loose with these things allowed automakers to catch them, maybe slowly but surely.
Because, "the old automakers" has gone through a lot of blood, sweat and tears (both figuratively and literally), and know what to do and what not to do. They can anticipate pitfalls better then a "newbie" carmaker. They shuddered, sputtered, hesitated, but they are in the move now. They will evolve this more slowly, but in a more reliable and safer way. They won't play that fast, but the products will be more refined. They won't skimp on radars because someone doesn't believe in them, for example.
Not everything is numbers, valuations and great expansions which look good on quarterlies, news, politics, and populists. Sometimes the slow and steads wins, and it goes for longer.
Physics and engineering doesn't care for valuations. They only care about natural laws.
Thank you for the explanation. I guess the thing I don't understand is what exactly the problems are that you are seeing. We've all heard the stories of wooden parts in initial production runs of Tesla models, sure. But it does seem like they iron out these kinks over time. Maybe I'm biased because I'm in the bay area, but it seems like every 3rd car you see on the highway is a Tesla, and lots of my coworkers speak very highly of theirs that they own. It just doesn't seem to me like there is actually a quality issue here?
If anything, ending production of SX and giving more focus to 3Y would probably increase the quality of those models, I'd imagine.
If you're pointing to Autopilot / camera-only as the main transgression here, yeah I'll agree that they have definitely overpromised, but it doesn't really seem to me like the lack of a L5 system is actually a deal-breaker for anyone, because from what I hear they are just damn good cars anyway.
Mark's and Meta's total business knowledge and experience is comparably a small drop w.r.t. ASML's ocean of knowledge and heritage (considering Philips' involvement in it, too).
> but considering Windows requirements drive the PC spec, this capability can be used to force Linux distributions in bad ways
What do you mean by this?
Is the concern that systemd is suddenly going to require that users enable some kind of attestation functionality? That making attestation possible or easier is going to cause third parties to start requiring it for client machines running Linux? This doesn't even really seem to be a goal; there's not really money to be made there.
As far as I can tell the sales pitch here is literally "we make it so you can assure the machines running in your datacenter are doing what they say they are," which seems pretty nice to me, and the perversions of this to erode user rights are either just as likely as they ever were or incredibly strange edge cases.
Microsoft has a "minimum set of requirements" document about "Designed for Windows" PCs. You can't sell a machine with Windows or tell it's Windows compatible without complying with that checklist.
So, every PC sold to consumers is sanctioned by Microsoft. This list contains Secure Boot and TPM based requirements, too.
If Microsoft decides to eliminate enrollment of user keys and Secure Boot toggle, they can revoke current signing keys for "shims" and force Linux distributions to go full immutable to "sign" their bootloaders so they can boot.
As said above, it's not something Amutable can control, but enable by proxy and by accident.
Look, I work in a datacenter, with a sizeable fleet. Being able to verify that fleet is desirable for some kinds of operations, I understand that. On the other hand, like every double edged sword, this can cut in both ways.
I don't see how this relates in any way to Amutable and it has been a "concern" for 20+ years (which has never come to pass). How do you think this relates at all?
Before this point in time, Linux never supported being an immutable image. Neither filesystems, nor the mechanism to lock it down was there. The best you could do was, TiVoization, but that would be too obvious and won't fly.
Now we have immutable distributions (SuSE, Fedora, NixOS). We have the infrastructure for attestation (systemd's UKI, image based boot, and other immutability features), TPMs and controversially uutils (Which is MIT licensed and has the stated goal to replace all GNU userspace).
You can build an immutable and adversarial userspace where you don't have to share the source, and require every boot and application call to attest. The theoretical thickness of the wall is both much greater and this theoretical state is much easier to achieve.
20 years ago the only barrier was booting. After that everything was free. Now it's possible to boot into a prison where your every ls and cd command can be attested.
> Before this point in time, Linux never supported being an immutable image.
What? As just one example, dm-verity was merged into the mainline kernel 13 years ago. I built immutable, verified Linux systems at least ten years ago, and it was considered old hat by the time I got there.
> The best you could do was, TiVoization, but that would be too obvious and won't fly.
What does this even mean? "TiVoization" is the slang for "you get a device that runs Linux, you get the GPL sources, but you can't flash your own image on the device because you don't own the keys." This is the exact same problem then as it was now and just as "obvious?"
I understand the fears that come from client attestation (certainly, the way it has been used on Android has been majorly detrimental to non-Google ROMs), but, to the Android point, the groundwork has always been there.
I'd be very annoyed if someone showed up and said "we're making a Linux-based browser attestation system that your bank is going to partner on," but nobody has even gone this direction on Windows yet.
> Oh, Rust is memory safe. Good luck finding holes.
I break secure boot systems for a living and I'd say _maybe_ half of the bugs I find relate to memory safety in a way Rust would fix. A lot of systems already use tools which provide very similar safety guarantees to Rust for single threaded code. Systems are definitely getting more secure and I do worry about impenetrable fortresses appearing in the near future, but making this argument kind of undermines credibility in this space IMO.
Yes, I reference Android client attestation in my comments in this thread frequently. I actually see this company as likely to be the flip side of the “bad” client attestation coin; server attestation actually provides a lot of nice properties to end users and providers who wish to provide secure solutions with very limited user downside.
It won't remain "server" attestation. It will become "client" attestation, with the end result that you won't own your own machine anymore, you'll just be paying for a client device upon which you won't control the hardware or software anymore. See any mobile phone at all, anymore.
I don’t see anyone investing in this for general purpose desktop Linux in the state desktop Linux exists today; the harbinger of the Desktop Linux Apocalypse would be web-based Windows attestation (just as Android attestation is eroding alt-OSes) which feels like a viable “threat” but thankfully doesn’t seem to be happening just yet.
I do think this approach might get used for client attestation in gaming, which I actually don’t mind; renting/non-owning a client that lets me play against non cheaters is a pretty good gaming outcome, and needing a secure configuration to run games seems like a fine trade for me (vs for example needing a secure desktop configuration to access my bank, which would be irksome).
Thanks for the answer. Let me ask you something close with a more blunt angle:
Considering most of the tech is already present and shipping in the current systemd, what prevents our systems to become a immutable monolith like macOS or current Android with the flick of a switch?
Or a more grave scenario: What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle, hence every Linux distribution has to go through Microsoft's blessing to be bootable?
So adding all of this technology will certainly make it more easy to be used for either good or bad. And it will certainly become possible to build an OS that will be less hackable than your run of the mill Linux distro.
But we will never enforce using any of these features in systemd itself. It will always be up to the distro to enable and configure the system to become an immutable monolith. And I certainly don't think distributions like Fedora or Debian will ever go in that direction.
We don't really have any control over what Microsoft decides to do with Secure Boot. If they decide at one point to make Secure Boot reject any Linux distribution and hardware vendors prevent enrolling user owned keys, we're in just as much trouble as everyone else running Linux will be.
I doubt that will actually happen in practice though.
I would be _shocked_ if, conditional on your project being successful, this _wasn't_ commonly used to lock down computing abilities commonly taken for granted today. And I think you know this.
> we will never enforce using any of these features in systemd itself. It will always be up to the distro
So, plausible deniability. It's not the systemd project, it's the distro.
> I certainly don't think distributions like Fedora or Debian will ever go in that direction.
In the past they made decisions that we can call unexpected. I believe that in the short term future they won't but in say ten years? I'm not sure. The technology (created by Amutable?) will be mature by that time and ready to close Linux down.
> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle
Theoretically, nothing. But it's worth pointing out that so far they have actually done the opposite. They currently mandate that hardware vendors must allow you to enroll your own keys. There was a somewhat questionable move recently where they introduced a 'more secure by default' branding in which the 3rd party CA (used e.g. go sign shim for Linux) is disabled by default, but again, they mandated there must be an easy toggle to enable it. I don't begrudge them to much for it, because there have been multiple instances of SB bypass via 3rd party signed binaries.
All of this is to say: this is not a scenario I'm worried about today. Of course this may change down the line.
> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle, hence every Linux distribution has to go through Microsoft's blessing to be bootable?
Why are you buying hardware that Microsoft controls if you're concerned about this?
Also, I know. A few of my colleagues run {open, free, dragonfly}BSD as their daily drivers for more than two decades. Also, we have BSD based systems at a couple of places.
However, as a user of almost all mainstream OSes (at the same time, for different reasons), and planning to include OpenBSD to that roster (taking care of a fleet takes time), I'd love to everyone select the correct tool for their applications and don't throw stones at people who doesn't act like them.
Please remember that we all sit in houses made of glass before throwing things to others.
Oh, also please don't make assumptions about people you don't know.
You could describe Richard Stallman as someone who refuses to use proprietary software because he sees using it as becoming complicit--however indirectly--in a technology ecosystem that violates the values he’s committed to.
"Just don't use X" is in fact a very engaged and principled response. Try again.
Immutability means you can't touch or change some parts of the system without great effort (e.g. macOS SIP).
Atomicity means you can track every change, and every change is so small that it affects only one thing and can be traced, replayed or rolled back. Like it's going from A to B and being able to return back to A (or going to B again) in a determinate manner.
I remember a small competition where people do a well-defined "share this content to others" routine to showcase how OS A is way more intuitive than OS B. There was also an OS C, which was way slower than A&B. Then, someone came using OS C, topped the chart with a sizeable time difference.
The point is, sometimes mastery pays back so much that, while there's theoretically better ways to do something, the time you save from that mastery is enough of a reason to not to leave the tool you're using.
I also have a couple of "odd" tools that I use and love, which would cause confused looks from many people. Yet, I'm fast and happy with them.
reply