Author of Systemd Quits Microsoft To Prove Linux Can Be Trusted (theregister.com) 124
Lennart Poettering has left Microsoft to co-found Amutable, a new Berlin-based company aiming to bring cryptographically verifiable integrity and deterministic trust guarantees to Linux systems. He said in a post on Mastodon that his "role in upstream maintenance for the Linux kernel will continue as it always has." Poettering will also continue to remain deeply involved in the systemd ecosystem. The Register reports: Linux celeb Lennart Poettering has left Microsoft and co-founded a new company, Amutable, with Chris Kuhl and Christian Brauner. Poettering is best known for systemd. After a lengthy stint at Red Hat, he joined Microsoft in 2022. Kuhl was a Microsoft employee until last year, and Brauner, who also joined Microsoft in 2022, left this month. [...]
It is unclear why Poettering decided to leave Microsoft. We asked the company to comment but have not received a response. Other than the announcement of systemd 259 in December, Poettering's blog has been silent on the matter, aside from the announcement of Amutable this week. In its first post, the Amutable team wrote: "Over the coming months, we'll be pouring foundations for verification and building robust capabilities on top."
It will be interesting to see what form this takes. In addition to Poettering, the lead developer of systemd, Amutable's team includes contributors and maintainers for projects such as Linux, Kubernetes, and containerd. Its members are also very familiar with the likes of Debian, Fedora, SUSE, and Ubuntu.
It is unclear why Poettering decided to leave Microsoft. We asked the company to comment but have not received a response. Other than the announcement of systemd 259 in December, Poettering's blog has been silent on the matter, aside from the announcement of Amutable this week. In its first post, the Amutable team wrote: "Over the coming months, we'll be pouring foundations for verification and building robust capabilities on top."
It will be interesting to see what form this takes. In addition to Poettering, the lead developer of systemd, Amutable's team includes contributors and maintainers for projects such as Linux, Kubernetes, and containerd. Its members are also very familiar with the likes of Debian, Fedora, SUSE, and Ubuntu.
Bis später (Score:3)
Restricted stock vested (Score:2)
So his 3 years of restricted Microsoft stock awards has mostly vested and now he's leaving Microsoft.....
Linux can be trusted (Score:5, Insightful)
Poettering can't.
Re: (Score:2, Troll)
Poettering can't.
Hahaha. Only you know what? All of this is part of why this - and every other year - isn't the year of Linux on the desktop.
People who are getting fed up with Windows issues can't look at Linux as a clean, problem-free destination. Systemd, initd foopd hoopd sunnyd... the only people who care about this drama are embedded in the Linux world already. From the outside, all the stories about KDE this, Gnome that, arguments of distros and windowing managers and... if Linus is or isn't vibe coding this wee
Re: (Score:2)
Android aside the vast majority of Linux installs are backend servers when stuff like how easy it is interact with and debug issues with the init startup and other fundamental subsystems of the OS *DOES* matter. Clearly you have no idea about any of this.
Re: (Score:2)
Thanks for the heads up sherlock and way to go on completely missing the point.
Re: (Score:2)
I think you got modded down for begging the question.
What I mean here is, do people outside of the Linux world actually even hear about any of that stuff, let alone get scared off by it? What little I see about Linux from the mainstream tech press is generally cautiously optimistic and points users towards specific low-friction distributions where they won't be making a lot of choices. KDE vs GNOME is completely irrelevant to your average user, who wouldn't use advanced features if they had them. They don't
Re: (Score:2)
I think you got modded down for begging the question.
What I mean here is, do people outside of the Linux world actually even hear about any of that stuff, let alone get scared off by it?
People, yes. I'm one of them though I'd say turned-off rather than scared-off. I'm a three-decades-plus sysadmin. I've worked with SCO Unix, Irix, Linux, DOS, Novel Netware, OS/2 and every version of Windows from 3.0 to current though the vast, vast majority has been Windows. The value proposition of Linux over Windows on my personal machines is dubious since I can wrangle it to behave as I see fit. The spray of choices and politics in the Linux world is daunting.
Random users and grandmas? No. Yo
Re:Linux can be trusted (Score:5, Insightful)
If the Linux community had any sense, they would blacklist this asshole -- from EVERYTHING -- for life.
Re: (Score:2)
Re:Linux can be trusted (Score:4, Insightful)
The problem is breakage-ignorant and make-everyone-change-everything people get way too much influence per the value that they deliver mixes with gullible project managers who then foist this half-baked, buggy, incompatible, fragmentation-producing shit onto everyone else. While we could've done better with FHS across NIXes, it would've been better to have Borne script caching infrastructure than take over almost every goddamn thing.
New | different doesn't always deliver enough net value to justify change.
I hope this venture goes for a long time, wastes lots of AI investment money, and dies a Transmeta-like death. (VLIW could've been cool but I think Itanium proved the compilers at the time didn't know how to optimize for it.)
Re: (Score:2)
Besides, Linux isn't - or at least doesn't have to be - synonymous w/ systemd
Maybe Poettering can figure out a way for Emacs to run directly on systemd, w/o needing a separate kernel
Re: (Score:2)
Re: (Score:2)
I remember when people joked that Emacs stood for "Eighty Megs And Constantly Swapping"
*sob* VSZ of a current Emacs at startup is about 740MB and RSS is over 90MB.
But I still use Emacs. My muscle memory goes back 36 years and it's not going to change.
Re: (Score:2)
I remember when people joked that Emacs stood for "Eighty Megs And Constantly Swapping"
The trope is for 8 megs. My 486 motherboard couldn't go beyond 16MB and adding 8MB was > $2000.
Linux would run, with X11, on 4MB. So double the RAM and emacs still caused swapping.
Luckily, web browsers came out and made emacs look frugal with RAM
Re:Linux can be trusted (Score:4, Insightful)
That essentially sums it up. And systemd already had a few nice catastrophes, none of which affected me because I do not use it.
No trust (Score:2, Flamebait)
Well, Linux can already hardly be trusted, but CIA spy Poettering certainly never can.
Let's hope systemd will die soon!
Re: (Score:2)
Re: (Score:2)
Re: No trust (Score:3)
Remind me again what was wrong with sysinit scripts?
Re: (Score:2)
Remind me again what was wrong with sysinit scripts?
I think the idea of systemd, like most of the runtime systems, is fine, but I take issue with the expanse of systemd and it directly incorporating things, like date/time and resolver, it doesn't need to simply manage a system and its startup. The developers seem to have a not invented here attitude about things. Also, would it kill them to have it run as PID 2 instead of 1?
Re: (Score:2)
Remind me again what was wrong with sysinit scripts?
The sysv init was never finished. If you notice there are some similarities of inittab and a makefile.
The idea was the runlevel and action fields could be used for dependency and concurrency. The run levels A,B & C are hints of that as is the current total lack of use of the id field. There are hints in the 5ess software as well. Init's early features were limited because it could never be paged out and multi-cpus weren't an option on the newer 3b line
Re: (Score:2)
The sysv init was never finished.
Okay.
If you notice there are some similarities of inittab and a makefile.
What?
The idea was the runlevel and action fields could be used for dependency and concurrency.
But both of those things are actually used. So are the IDs, they actually have meaning. And the runlevels are part of dependency. You pass through runlevels on your way to other runlevels.
The run levels A,B & C are hints of that as is the current total lack of use of the id field.
Almost total. It's relevant to ttys :)
Init's early features were limited because it could never be paged out
init being limited is good. We want it to be simple. It doesn't often have to do anything but you want it to respond right away when it does. Today we can afford to burn more memory so we can afford a more complicated init from that perspective, but having more complexity in
Re: (Score:2)
Look at the names and descriptions in the fields and the pre-tab makefile format for far more similarity.
But both of those things are actually used. So are the IDs, they actually have meaning. And the runlevels are part of dependency. You pass through runlevels on your way to other runlevels.
The ID's aren't used for dependency. The id in sun sysv is a hack based on things like telnetd and rlogin. Part of the plan was to have the action field reference the ids and a state which was not done. The idea was to have a make like dependency check based on the current state of what was running.
Had inittab been expanded slight
Re: No trust (Score:2)
In order to not need scripts you would need a very ugly inittab, even if it had been expanded.
I didn't say the IDs were used for dependency.
Re: (Score:3)
I'll grant you that my
Re: (Score:2)
Parallel startup? Who cares with the hardware speeds we have today.
I care a lot about this on my laptop. It makes a significant difference.
I argue that anything that systemd does, you can write an init script that does the same job with around 1 million less lines of code, less bugs, less attack surface, and 50-75% less processes running in RAM.
And I'd argue that you're wrong. Does the average sysadmin write init scripts with the same care that software developers (are supposed to) take when they
Re: (Score:2)
It wasn't about you, it never was.
Re: (Score:2)
I don't know why Debian wrote such long init scripts but they did.
It is not a problem if an init script is long. It is only a problem when it is hard to understand. Debian's lsb-inherited functions library for init scripts and the specific structure used is what makes them easy to write. Shell scripting is a fundamental Unix feature, people should understand it well enough to copy an init script and make a few changes. There is a skeleton script to start with so you don't have to actually even understand what you're doing, you only have to (slightly) understand shell scri
Re: (Score:2)
That's why it's wrong. The GPL is about the user. Debian is in very large part about the GPL. Debian should be about the user.
You misunderstood: what I mean is that systemd was never about you. It was about making something that Debian maintainers would want to put into their system, and Poettering put a lot of effort into communicating with them and understanding what they wanted, something he doesn't do for other classes of users.
Re: (Score:2)
You see how that's not better though, right? Debian put all that stuff in their init scripts, if it was too complicated, they have themselves to blame. Since a unit script is just a pile of unique key value pairs separated by equals signs, you could have an init script which parsed them and you wouldn't need systemd but they chose to adopt systemd anyway. And not as an option which would have been ok, but as the only supported option, because yes you could and can change init systems but then tons of things
Re: (Score:2)
As for the Debian team, looking at their prior init scripts shows they wouldn't recognize good code if they saw it.
uh (Score:5, Insightful)
Poettering will also continue to remain deeply involved in the systemd ecosystem.
I therefore trust that it will continue to be shit.
Re:uh (Score:5, Interesting)
daemontools and runit at least were simple and dependable, could drop-in and stop services on-the-fly, and didn't have a weird-ass broken state where it refused to start because it failed X times before. Oh and GFL shipping systemd syslog to other systems. syslog-ng was even more performant and robust than rsyslog, even though rsyslog was nicer to configure.
Re: (Score:2)
now I'm elsewhere with saner housing prices.
The trick is to live somewhere with sane housing prices while working for a Silicon Valley company, for SV pay -- or at least close to it. Yeah, they'll ding you a little for being remote, because they can, so you'll only be making 80% of what you would living in SV... but you'll still be making 3-5X what local companies will pay.
Re:uh (Score:4)
It really cannot be anything else, regardless of maintainer. It increases complexity while trying to hide it. That is the road to hell in all engineering. Sure, you can (and should) do it to a limited degree and very carefully when some technology is really mature and exceptionally reliable. But IT and software is not there yet and will not be there yet for a long time. And hence the idea behind systemd is a very bad one at this time.
Re:uh (Score:5, Insightful)
Overrated. Prior to systemd Linux administrators famously admin'd thousands of systems vs tens in the windows world. That text/file/directory-based system combined with all the text-mangling power tools in linux, the shell, and perl... nothing compares.
It actually becomes much easier to work with configuration management tools when they are managing the state of text files as the Linux gods intended.
Re: (Score:2)
Systemd units are plain text files, you know.
I honestly don't understand the visceral hate for systemd. I've been using UNIX since 1989 and Linux since 1994, so I have plenty of experience with old ways of doing things.
Systemd, at least in my experience, just works and writing systemd unit files is easier than writing sysvinit scripts. So when Debian switched to it, it was fine. I adapted.
Re: (Score:3, Interesting)
I honestly don't understand the visceral hate for systemd.
It is the antithesis of the Unix way. This has been argued back and forth all along, and if you don't agree I won't try to convince you here.
Systemd, at least in my experience, just works and writing systemd unit files is easier than writing sysvinit scripts. So when Debian switched to it, it was fine. I adapted.
The problem with systemd and unit scripts is that they cannot do all the things that a script can do, so you often wind up using a script anyway. In that case you have really not made things any simpler than the usual case. Meanwhile you've added a whole lot of complexity which is largely unnecessary, some of which is utterly dependent on other parts so it is difficult
Re: (Score:2)
Appealing to "the UNIX way" is just silly. UNIX has been around for over 50 years, and it evolves as people figure out better ways to do things.
The problem with systemd and unit scripts is that they cannot do all the things that a script can do, so you often wind up using a script anyway.
I would say: very rarely, not often. Looking at the units on my machine, none of them uses an auxiliary script to start or stop a service.
Re:uh (Score:5, Insightful)
What was the point of the journal log system? We had stable tools for decades for manipulating and managing text logs. So systemd made the logs binary and then re-invented all the same tools but slightly different. Same as with ifconfig. Worked great for decades and now it’s replaced with “ip” and a different syntax. What was gained?
Re: (Score:3)
I agree with you about the binary logging. Not everything about systemd is better than what came before, but also, not everything is worse.
You can still have plain-text logging and AFAIK Debian still generates the normal plain-text log files by default.
I also get annoyed with ifconfig and ip, and iwconfig vs iw, etc. but AFAIK those are not Poettering's doing and are not related to systemd.
BTW, I think the reason for ip instead of ifconfig and route was to add support for different routing tables, wh
Re: (Score:3)
There are many things that aren't supported by ifconfig/iwconfig besides different routing tables (first which comes to mind is adding multiple addresses to the same interface).
It all comes down to how they communicate with the kernel -- ifconfig is using ioctls on a socket file descriptor, while ip & co are using netlink sockets. The ioctl interface is quite limited, and was not extended as new features were added to the kernel.
They could've adapted the old net-tools to use netlink behind the scenes wh
Re: (Score:2)
first which comes to mind is adding multiple addresses to the same interface
At the time that was done with interface aliases. ifconfig eth0:1 blah blah blah
Re: (Score:3)
You can still have plain-text logging
It's a second-class citizen. Those log messages are passed on to the real log daemon by systemd. If it fails to do that properly, which is often true in the early phases of the process, then log messages don't always make it.
The correct way to do what they did there would have been to add logging to an existing syslogd. It would have been a lot less work, too. Instead they felt they had to add their own incompatible solution instead. That's the biggest thing wrong with systemd in a nutshell.
Re: (Score:2)
When every Linux distro that matters is using systemd, it's not much of a lock-in.
And guess what? I distribute email-filtering software that runs on a wide variety of UNIX systems. I include sysvinit scripts for systems that use that, and systemd units for ones that use systemd. There's no lock-in.
Re: (Score:2)
"Every distro that matters?"
Sooo. Ubuntu and Redhat?
Vendor lock in is assured if you put critical systems on them. BECAUSE of proprietary extensions, of which, systemd could be considered one of them.
The old IBM/Microsoft playbook embrace, extend, extinguish.
Jesus, I wrote COBOL programs for the Treasury Board, here in capital city, about 100 years ago with IBM Report Writer. They paid thru the nose for the license, and as a gree
Re: (Score:2)
Vendor lock-in, to just about any vendor you could choose? You don't even need a vendor at all if you don't want one - just use Debian, or Fedora, or...
Re: (Score:2)
"Appealing to "the UNIX way" is just silly"
No, it's the Unix philosophy of small purpose built tools combined rather than large monolithic integrated solutions and that never changes. But you tipped your hand, you began as a proprietary unix guy and they use monolithic systemd-like chunks all over the place.
"it evolves as people figure out better ways"
The philosophy doesn't, the tools do, but systemd doesn't bring better ways to do things just one built with Microsoft's big monolithic one size fits all phil
Re: (Score:2)
I never began as a "proprietary UNIX guy" for two reasons; one is that I'm not a guy and second is I used SunOS and Solaris mostly as a student and a little bit on the job, and this was back in the day before SMF, etc. when the system was much more BSD-like.
The problem with appealing to "the UNIX way" is that nobody really knows what that is, beyond a few vague generalities. Systemd itself is not one monolithic program, by the way. It consists of 38 small purpose-built executables (on Debian 13, anyway)
Re: (Score:2)
Everyone is a "guy" dude. You aren't special man.
In case it's not obvious, about 50% of people are not "guys". I guess sysvinit folks are not great at seeing cases outside their own experience. :)
Change just for the sake of change isn't a good thing.
Yes, I agree. However, on balance, I think systemd (or something like it) is a good change for a number of reasons I've outlined in other posts:
1. Easy ability to do dependency management.
2. Ability to start services in parallel (which flows from 1)
Re:uh (Score:4, Insightful)
That's a total non-issue. The entire "daemonization code" is just 2 syscalls: fork(2) + setsid(2) and using syslog(3) instead of stderr for printing error messages.
Other stuff like redirecting stdin/out/err to /dev/null or chdir / is usually more trouble than it's worth (for instance, I'm always redirecting the std fds from a non-connected socket instead of /dev/null -- in order to have accidental read/write FAIL instead of silently succeeding and hiding real issues with the code).
Adapting to the canned "solutions" offered by systemd / daemontools / whatever is instead much more complicated and more limiting in what you can do. All that without any benefit (besides better fitting into someone else's worldview and OCD fixations).
Re: (Score:2)
OK, so you disagree with my point 3. How about the other 5 points?
Re: (Score:3)
1. Easy ability to do dependency management.
Debian has a script or script library I believe originally from the lsb which does this easily from some boilerplate at the top of the init script. That's how update-rc.d works, but it's also used to make init scripts require that other scripts have started successfully.
2. Ability to start services in parallel (which flows from 1).
startpar
3. Remove the necessity for every service to write its own daemonization code; you can just let systemd do it for you.
daemontools, inetd...
4. Standard way to run services as a non-root user
Funny thing about standards.
5. Standard way to use newer Linux features like cgroups and namespaces.
There already were standard ways to do this in the shell, and therefore in init scripts. They are even already used.
6. Standard commands for monitoring and controlling the status of a service.
That's always been a part of init scripts.
All of those things can be (and probably have been) implemented in sysvinit environments, but usually as hacks.
All of those things are av
Re: (Score:2)
Re:uh (Score:4, Insightful)
I capitalized that because it's a book title, and it's absolutely mandatory reading for everyone in this discussion and anyone developing software. It's such an important work that I make a point of re-reading it every year -- and each time, I learn something new.
But if I were to have the temerity to attempt to summarize it in one sentence, it would be this: a software tool should do one thing, and do it well. This approach drove the development of Unix, and Unix in turn was largely responsible for the development of the ARPAnet, CSnet, and Usenet. (Which I know because I was there for all of it.) And obviously Linux would never have existed without Unix.
If you understand this philosophy, then you understand immediately why systemd not only can be, but must be, summarily rejected. It's obvious on inspection. If you don't understand this philosophy, then you need to do the reading -- until you do.
Let me point something else out: do you think we -- the people who've been working in this field for many decades -- didn't consider the idea of something like systemd? In fact; we did. But because we have seasoned judgment and experience -- we're not mere ignorant newbies like Poettering -- and because we have the humility to recognize that Thompson/Ritchie/Kernighan/McIlroy/Bourne/etc. were quite likely smarter than we are -- we're also not egotistical jackasses like Poettering -- we did not rush into this. We considered it carefully, we debated it at length, and we rejected it.
To borrow an applicable -- but possibly apocryphal -- quote from Enrico Fermi: systemd is not even good enough to be wrong.
Re: (Score:2)
So when you say "we -- the people who've been working in this field for many decades", note that I have been developing software as a hobby since 1982 and professionally since 1990, and ran a software development company for 18 years. I think I'm likely as "seasoned" as anyone on Slashdot.
Second: If you say: "We considered it carefully, we debated it at length, and we rejected it.", then why is it that most Linux systems use systemd, Solaris uses smf, and Mac OS uses launchd, all of which are systemd-lik
Re: (Score:2)
> I didn't see a whole lot of anger when Linux went with sysvinit scripts instead of the conceptually-simpler BSD rc system.
Linux _didn't_ universally adopt sysvinit over BSD rc. Which one got used depended on the distribution. Slackware, which I like best because it keeps things simple and doesn't change for the sake of change, happens to (still) use BSD rc.
So, calling the debate "SystemD versus sysvinit" is and always was somewhat incorrect, but it's accurate enough since the actual init binary is th
Re: (Score:2)
Second: If you say: "We considered it carefully, we debated it at length, and we rejected it.", then why is it that most Linux systems use systemd, Solaris uses smf, and Mac OS uses launchd, all of which are systemd-like things?
All of those things are reviled to various degrees.
sysvinit's only crimes were that it was slow and you had to write scripts. startpar solved the slow problem and scripts are an integral and fundamental feature of the OS, and avoiding them is missing the point. Init scripts are made with skeletons and boilerplate and just aren't that complicated anyway.
There have been Linux distributions which used the BSD init script system. It's just inferior to doing it the System V way, which is yet still basically the
Re: (Score:2)
Re: (Score:3)
There is a lot of jealousy with Poettering's skills and capabilities
It's not clear exactly what you mean here. Do you mean that he's jealous of competent developers? There could actually be jealousy of his influence despite his lack of skill. As a statement which someone would be willing to make openly in public, that would also make sense. Everything he touches turns to poo.
Re: (Score:2)
Devuan
is free and you no have dependencies on suppliers, less bugs, and less attack surface. Binary compatible with apt repos. Uses less energy because less is running in memory. My wireguard hub runs with 86 processes in ram. One of my recent email servers, with dovecot 2.4 and postfix, has only 121 running processes. My desktop Devuan system I'm currently writing this on has 390 running processes. Compare by running ps aux | wc on your Ubuntu or Red
Re: (Score:2)
So much wrong.
Devuan is free and you no have dependencies on suppliers
So Devuan ships zero packages from third-party suppliers? That's a hot take.
Uses less energy because less is running in memory
Another hot take. A program sitting in memory uses essentially no energy unless it's scheduled to run.
One of my recent email servers, with dovecot 2.4 and postfix, has only 121 running processes.
My Raspberry Pi server running dovecot and postfix has 247 processes, but it also runs PostgreSQL, Aster
Re: (Score:2)
Re: (Score:2)
I think we are witnessing the software equivalent of Planck's Principle [wikipedia.org].
Re: (Score:3)
But you are not making sense. (And it's "Her", by the way, not "Him".)
As the person I replied to pointed out, if systemd doesn't quite do what you need, you can always fall back on a script. So the common use cases are easy and the uncommon ones are possible.
Now I personally have not encountered a use case that systemd couldn't handle natively, but I'm willing to admit that such use cases exist, in which case... you use a script that you call from a systemd unit. Problem solved.
Re: (Score:2)
in which case... you use a script that you call from a systemd unit. Problem solved.
No, that's new problems created with no benefit since the point was to get rid of the scripts.
Re: (Score:2)
OMG, lookit the triggered snowflake! LOL. A whole paragraph to whine about a simple two-letter spelling correction.
Re: (Score:2)
Re: (Score:2)
By this time, there are a lot of replies to you, but I'll try to add a little more context.
I think a lot of the "visceral hate for systemd" comes from not only the "it's not the Unix way" mindset, but that systemd comes across as "change for the sake of change". From my probably limited perspective, I don't feel that it really gives much of value, but it has made my life harder. I have new commands to learn, new text files in strange places to learn/create, and it's honestly hard to debug. A shell init scri
Fade Away (Score:4, Funny)
Hopefully Poettering will fade away now.
Systemd succeeded injecting itself because he had Red Hat's bulk behind him. As an independent, he'll have no traction. I guarantee he'll be looking for work ina year's time.
Please, no one hire him.
Re: (Score:2)
I guarantee he'll be looking for work ina year's time.
Or maybe he'll take up golf... Poettering, pottering, puttering, putting.
Re: (Score:2)
No, probably not. Most people have made their peace with systemd and I think it'll persist.
Re: (Score:2)
Making peace with systemd is easy: Just do not use it. Prevents a lot of problems.
Re: (Score:2)
Meh, whatever. If you don't want to use systemd, that's fine. But debate it on its merits, not because its author has an abrasive personality or because it doesn't follow some nebulous "UNIX philosophy".
Re: (Score:2)
Yes, I obviously have a lack of engineering skill... hmm... M.Eng in Electronics; seven engineering patents to my name; retired on the proceeds of selling a successful software company... yeah, that's it. Low skill for sure.
LOL. It's so funny how insecure people get personal instead of actually discussing technical merits.
Re: (Score:2)
Re: (Score:2)
try and keep the niche role by having scripts than no-one else knows about
This is nonsense. Nobody with any sense is developing their own solutions for everything, because someone else has already done it — unless it's so simple that someone else competent could just write essentially the same script. I write tons of short scripts, but I don't think any of them are magic, they're just time savers because I will do the same things again later. Then maybe they become the basis of some automation later.
It's also nonsense because one of the defining characteristics of shell scr
Re: (Score:2)
No, probably not. Most people have made their peace with systemd and I think it'll persist.
Definitely. It's the standard now in the major Linux distros and it's not going away. It works and they're happy with it.
I don't care, myself, but I only run a handful of machines. OTOH, the people I know who administer thousands of machines like systemd just fine, as do folks like the Debian leadership.
Trust? (Score:5, Insightful)
Trust is more than just technical stuff. You actually have to have the right attitude. Pottering's pretentious and overconfident attitude already casts doubt that he can be trusted.
Too Late (Score:3)
He already did a ton of damage to Linux already.
Re: (Score:2)
What are building? (Score:2)
Re:What are building? (Score:4, Insightful)
Re: (Score:2)
Likely something similar, yes. People have valid concerns about remote attestation being used for DRM, but that's mostly from the standpoint of an individual who uses services provided by big companies. For businesses deploying Linux across an enterprise, however, there's a lot of value in being able to cryptographically verify that your own machines are running exactly the software they're supposed to be.
Poettering wrote a lengthy blog post [0pointer.net] a few years ago which describes his overall vision for a signed,
Re: (Score:2)
ELI5 means: "Explain Like I'm 5"
Verifiable integrity (Score:2)
Let's hope this is about countering attacks and not about implementing Android Play Protect certification on Linux.
Given the current microsoft state? (Score:3)
He was probably being told daily to shove copilot in system-d somehow.
Not ruin linux on purpose or any sort of "make windows win" kind of deal, just get copilot inside linux because the copilot SOMEONE has to use the thing.
Re: (Score:2)
He was probably being told daily to shove copilot in system-d somehow. Not ruin linux on purpose or any sort of "make windows win" kind of deal, just get copilot inside linux because the copilot SOMEONE has to use the thing.
Given what he's decided to do, it's more likely he wanted to implement his trust verification ideas in Windows and got shut down, so he decided to go do it with Linux.
As someone who spent much of the last decade thinking and working on topics related to system integrity and remote proof thereof, I'm interested to see what his ideas are and if they're actually novel, or at least have some innovative twist.
Which one is it? (Score:3)
does not mesh with
Poettering cannot be trusted (Score:2)
He is a known incompetent with an outsized ego. Nothing he does "proves" anything in the direction of trustworthiness. But that he was willing to join Microsoft in the first place shows a lot.
Re: (Score:2)
Linus Torvalds had demonstrated how fed up he was with Pottering's wide-ranging and stable system breaking schemes. The unannounced and disastrous "kill all background jobs" misfeature was typical, and took time and work to clean up from.
Unclear why he left? (Score:2)
"Linux celeb Lennart Poettering has left Microsoft and co-founded a new company... It is unclear why Poettering decided to leave Microsoft. We asked the company to comment but have not received a response."
The writer might have early onset of dementia, or perhaps early onset of AI syndrom.
Amutable? (Score:2)
Sounds like a sleep medication.
dang (Score:2)
I threw shade on systemd a few weeks ago because he still worked for MS. I'm going to have to find some new material when I bitch about systemd.
First thing ... (Score:2)
Get back here and fix PulseAudio.
Re: (Score:2)
We no longer need it. We have pipewire and wireplumber. They do that job and some other jobs too. The combo replaces both pulseaudio and JACK, and also connects ALSA clients so they get their own volume controls as well.
Just a bandage (Score:2)
Cryptographic verification of the system components and all the other stuff is important, it's a way to detect and limit the damage once a system is compromised and in the process of being infected by malware. That, though, happens far too late. For it to work you have to assume that the parts of the system that enforce verification don't have exploitable bugs in them, and we've already seen that's never the case. Especially when a single key held by a single entity is the trust root for a large number of s
Re: (Score:2)
Re: (Score:2)
I wouldn't say it's fun, I'd say it's disappointing. A whole bunch of people who appear to be reasonably smart who are so entrenched in their long-held opinions that they can't see any value at all in doing anything differently.