Posted by hornedhob 1/27/2026
I'm interested in what Amutable is building, but I'm personally uneasy about Lennart Poettering being involved. This isn't about denying his technical ability or past impact. My concern is more about the social/maintenance dynamics that have repeatedly shown up around some of the projects he's led in the Linux ecosystem - highly centralizing designs, big changes quickly landing in core technology, and the kind of communication/governance style that at times left downstream maintainers and parts of the community feeling steamrolled rather than brought along. I've watched enough of those cycles to be wary when the same leadership style shows up again, especially in something that might become infrastructure people depend on.
To keep this constructive: for folks who've followed his work more closely than I have, do you think those past community frictions were mostly a function of the environment (big distro politics, legacy constraints, etc), or are they intrinsic to how he approaches projects? And for people evaluating Amutable today, what signals would you look for to distinguish "strong technical leadership" from "future maintenance and ecosystem headaches" ?
If anyone from the company is reading, I'd be genuinely reassured by specifics like:
- a clear governance/decision process (who can say "no", how major changes are reviewed)
- a commitment to compatibility and migration paths (not just "it's better, switch")
- transparent security and disclosure practices
- a plan for collaboration with downstream parties and competitors (standards, APIs, interop)
I realize this is partly subjective. I’m posting because I expect I'm not the only one weighing "technical upside" against "community cost," and I'd like to hear how others are thinking about it.
If you don't think that's a community opinion, it's at least an AI's opinion, since all I prompted it with was "rewrite my comment to follow the HN guidelines"I want to know if they raised VC money or not.
Either way at least it isn't anything about AI and has something to do with hard cryptography.
The systemd crowd are perhaps worse than GNOME, as regards "my way or the highway", and designing systems that are fundamentally inadequate for the general use-case. I don't think ethnicity or gender diversity quotas would substantially improve their decision-making: all it would really achieve is to make it harder to spot the homogeneity in a photograph. A truly diverse team wouldn't make the decisions they make.
Imagine you're using a program hosted on some cloud service S. You send packets over the network; gears churn; you get some results back. What are the problems with such a service? You have no idea what S is doing with your data. You incur latency, transmission time, and complexity costs using S remotely. You pay, one way or another, for the infrastructure running S. You can't use S offline.
Now imagine instead of S running on somebody else's computer over a network, you run S on your computer instead. Now, you can interact with S with zero latency, don't have to pay for S's infrastructure, and you can supervise S's interaction with the outside world.
But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.
However --- if S's author could run S on your computer in such a way that he could prove you haven't tampered with S or haven't observed its secrets, he can let you run S on your computer without giving up control over S. Attestation, secure enclaves, and other technologies create ways to distribute software that otherwise wouldn't exist. How many things are in the cloud solely to enforce access control? What if they didn't have to be?
Sure, in this deployment model, just like in the cloud world, you wouldn't be able to run a custom S: but so what? You don't get to run your custom S either way, and this way, relative to cloud deployment, you get better performance and even a little bit more control.
Also, the same thing works in reverse. You get to run your code remotely in a such a way that you can trust its remote execution just as much as you can trust that code executing on your own machine. There are tons of applications for this capability that we're not even imagining because, since the dawn of time, we've equated locality with trust and can now, in principle, decouple the two.
Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.
But it won't be used like that. It will be used to take user freedoms out.
> But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.
That use case you're describing is already there and is currently being done with DRM, either in browser or in app itself.
You are right in the "it will make easier for app user to do it", and in theory it is still better option in video games than kernel anti-cheat. But it is still limiting user freedoms.
> Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.
Majority of the uses will be user-hostile things. Because those are only cases where someone will decide to fund it.
To be honest, mainly companies need that. personal users do not need that. And additionally companies are NOT restrained by governments not to exploit customers as much as possible.
So... i also see it as enslaving users. And tell me, for many private persons, where does this actually give them for PRIVATE persons, NOT companies a net benefit?
> This potential shouldn't prevent our inventing new kinds of tool.
Why do i see someone who wants to build an atomic bomb for shit and giggles using this argument, too? As hyperbole as my argument is, the argument given is not good here, as well.
The immutable linux people build tools, without building good tools which actually make it easier for private people at home to adapt a immutable linux to THEIR liking.
In my personal philosophy, it is never bad to develop a new technology.
"Trust us" is never a good idea with profit seeking founders. Especially ones who come from a culture that generally hates the hacker spirit and general computing.
You basically wrote a whole narrative of things that could be. But the team is not even willing to make promises as big as yours. Their answers were essentially just "trust us we're cool guys" and "don't worry, money will work out" wrapped in average PR speak.
I'm guessing you're referencing my comment, that isn't what I said.
> But the team is not even willing to make promises as big as yours.
Be honest, look at the comment threads for this announcement. Do you honestly think a promise alone would be sufficient to satisfy all of the clamouring voices?
No, people would (rightfully!) ask for more and more proof -- the best proof is going to be to continue building what we are building and then you can judge it on its merits. There are lots of justifiable concerns people have in this area but most either don't really apply what we are building or are much larger social problems that we really are not in a position to affect.
I would also prefer to be to judged based my actions not on wild speculation about what I might theoretically do in the future.
Not just can. They will use it.
Why should we trust microsofties to produce something secure and non-backdoored?
And, lastly, why should Linux's security be tied to a private company? Oooh, but it's of course not about security: it's about things like DRM.
I hope Linus doesn't get blinded here: systemd managed to get PID 1 on many distros but they thankfully didn't manage, yet, to control the kernel. I hope this project ain't the final straw to finally meddle into the kernel.
Currently I'm doing:
Proxmox / systemd-less VMs / containers
But Promox is Debian based and Debian really drank too much of the systemd koolaid.So my plan is:
FreeBSD / bhyve hypervisor / systemd-less Linux VMs / containers
And then I'll be, at long last, systemd-free again.This project is an attack on general-purpose computing.
Community ran servers with community administration who actually cared about showing up and removing bad actors and cheaters.
Plenty of communities are still demonstrating this exact fact today.
Companies could 100% recreate this solution with fully hosted servers, with an actually staffed moderation department, but that slightly reduces profit margins so fuck you. Keep in mind community servers ran on donations most of the time. That's the level of profit they would lose.
Companies completely removed community servers as an option instead, because allowing you to run your own servers means you could possibly play the game with skins you haven't paid for!!! Oh no!!! Getting enjoyment without paying for it!!!
All software attempts at anti-cheat are impossible. Even fully attested consoles have had cheats and other ways of getting an advantage that you shouldn't have.
Cheating isn't defined by software. Cheating is a social problem that can only be solved socially. The status quo 20 years ago was better.
In that world, authoring technology that enables this even more is either completely mad or evil. To me Linux is not a technological object, it is also a political statement. It is about choice, personal freedom, acceptance of risk. If you build software that actively intends to take this away from me to put it into the hands of economic interests and political actors then you deserve all the hate you can get.
I use Linux since the Slackware day. Poettering is the worse thing that happened to the Linux ecosystem and, of course, he went on to work for Microsoft. Just to add a huge insult to the already painful injury.
This is not about security for the users. It's about control.
At least many in this thread are criticizing the project.
And, once again of course, it's from a private company.
Full of ex-Microsofties.
I don't know why anyone interested in hacking would cheer for this. But then maybe HN should be renamed "CN" (Corporate News) or "MN" (Microsoft News).
agreed, and now he's planning on controlling what remains of your machine cryptographically!
Same here, Linux since about 1995. Same opinion.
> And, once again of course, it's from a private company. Full of ex-Microsofties.
And funded. And confident they will sell the product well.
https://news.ycombinator.com/item?id=18321884
- Linux is better now
- Nothing bad