Almost 20 years ago, and desktop Linux has improved immensely, but the underlying problem mentioned in this article remains: enterprise Linux takes priority over desktop Linux.
Or the people who don't think systemd provides benefits for servers are simply wrong. Sometimes "the truth is in the middle" but more often than not there's a correct and an incorrect answer.
systemd (with the constellation of its assorted tooling like udev, logind etc.) is the only system that correctly models stuff that happens around kernel (like hotplugging stuff, on top of starting services). It's a compelling choice for general-purpose distros (those that span both servers and desktop), who don't want to maintain more stuff than they absolutely must (like two different init systems), and almost inescapable for today's DE's.
Unfortunately that's about the only good thing that can be said about it. The community is perceived as toxic, because of the way it was adopted (by vote, not by consensus, i.e. pushed down the throats over the reasonable objections of large body of developers) (though it's false: it's not toxic at all, if you just approach them from outside with well founded feature request, they'll be far more accomodating than many FOSS projects). Conduct of lead developers was criticised (cf. kdbus). The stability and code quality has much improved, but at the time of discussion it was questioned. Last but not least, it comes with it's own load of complexity: you need to learn new concepts (e.g. something called "job") that are simply not there in inittab-derived systems like openrc, so it comes across as "undebuggable" if you're before the learning curve.
I guess but with elogind I have no problem running DEs without systemd. I have just never really come across systemd, having mostly used distros like alpine and gentoo
I am rearely involved in ops, however from what i have gathered i think its killer feature is the exact thing most people complain about when talking about it.
Systemd is not an init system, its an entirely system layer that does a lot of things of which init is just one piece.
However since there is a unified vision, all the things are controlled and configured the same way. This combined with its near universal adoption makes ops realy easy to do.
Many, many things. (Note: not an openrc expert, so not commenting on whether it's possible to arrange these things using entirely what openrc provides, in a uniform fashion that works identically on any openrc system.)
Universal trivial logging, including of text just printed to the daemon's stdout/stderr, and you can easily ask "give me the log messages from just this application". And you can log to memory for stateless systems, or to disk.
Service monitoring as the default expectation: services are a thing that are monitored and restarted if they fail, not a thing that gets run once and hopefully stays running.
Full integration with all kinds of event handling. Whether something is triggered by a kernel event (e.g. new device), a timer job, an incoming socket, or system boot, it uses exactly the same mechanism to start a service. So you don't need one mechanism (cron) for timers and another (inetd) for sockets and another (init scripts) for system boot. And all of them use the same service monitoring, logging, etc.
Easy integration with various kinds of sandboxing. One line in a .service file and a service runs in a chroot, or has no network access, etc.
And then there's just the general standardization effort to unify the dozens of different places that things get configured into one mechanism that's the same across distributions. For instance, before systemd, distributions had various different places to configure the hostname; now, distributions have largely standardized on `/etc/hostname`. There are many more instances of such standardization, and most of them have been successful.
My impression of SystemD, from reading a lot of Poettering interviews, is that it was inspired by desktop operating systems (Mac and Windows), however, it ironically it was popular with server distro vendors (most notably Red Hat and Microsoft, who have both employed Poettering at one point or another).
Believe me, I also looked for any example of desktop Linux getting any kind of prioritization in the kernel, and it just doesn't happen.
I have no idea how this actually could be made to work but there should be at least ten thousand people on this planet for which a better desktop Linux experience would be worth 50 bucks a month. Would 20 fulltime devs solely focused on desktop Linux be enough to move the needle?
I used Linux desktop 2007-2018 as my primary OS. It improved a lot in terms of hardware support and ease of use. I was very satisfied as it being my daily driver and miss it. The problem I face now is app ecosystem. I have developed hobbies besides programming (music, photography). The second problem is that Apple Silicon/hardware is just so good.
I don’t know if 20 devs can solve the app ecosystem problem. Although, gaming is getting there … so maybe there is hope for regular apps as well.
Most likely not. The easy wins have been accomplished, to push beyond that you'll probably need to fork the kernel and various related components, and make desktop-focused changes while backporting bug and security fixes. I think the job would take a lot more than 20 devs.
The main takeaway from this article should be that if you want to make changes that improve latency, make a benchmark tool first. If you can't measure it you can't really discuss the pros and cons with the implementation.
There is more, the push he got from the maintainer was horrible and I read the maintainer released a more elegant but same idea
What’s the maintainer name ?
It's a bit strange in the article. It mentions Ingo Molnar and also "the maintainer" as a separate person. I thought Ingo Molnar was the maintainer. Anyway, Molnar landed CFS in 2007. The scheduler is EEVDF since 2023, a design that AFAIU comes much closer to Con Kolivas' goals (i.e. no latency spikes for interactive - or in this case any - processes)... 16+ years later.
And here we are again with a maintainer blocking rust because they feel no one should add rust users of “his” subsystem. The idea all the maintainers are perfect is not a good thing
"Back in 2011, Con Kolivas left the Linux kernel community. An anaesthetist by day, he was arguably the last great Linux kernel hobbyist hacker. In the years since it seems things have, if anything, only gotten worse. Today, it is practically impossible to survive being a significant Linux maintainer or cross-subsystem contributor if you’re not employed to do it by a corporation. Linux started out as a hobbyist project, but it has well and truly lost its hobbyist roots."
27 comments
[ 31.3 ms ] story [ 828 ms ] threadUnfortunately that's about the only good thing that can be said about it. The community is perceived as toxic, because of the way it was adopted (by vote, not by consensus, i.e. pushed down the throats over the reasonable objections of large body of developers) (though it's false: it's not toxic at all, if you just approach them from outside with well founded feature request, they'll be far more accomodating than many FOSS projects). Conduct of lead developers was criticised (cf. kdbus). The stability and code quality has much improved, but at the time of discussion it was questioned. Last but not least, it comes with it's own load of complexity: you need to learn new concepts (e.g. something called "job") that are simply not there in inittab-derived systems like openrc, so it comes across as "undebuggable" if you're before the learning curve.
Systemd is not an init system, its an entirely system layer that does a lot of things of which init is just one piece.
However since there is a unified vision, all the things are controlled and configured the same way. This combined with its near universal adoption makes ops realy easy to do.
Universal trivial logging, including of text just printed to the daemon's stdout/stderr, and you can easily ask "give me the log messages from just this application". And you can log to memory for stateless systems, or to disk.
Service monitoring as the default expectation: services are a thing that are monitored and restarted if they fail, not a thing that gets run once and hopefully stays running.
Full integration with all kinds of event handling. Whether something is triggered by a kernel event (e.g. new device), a timer job, an incoming socket, or system boot, it uses exactly the same mechanism to start a service. So you don't need one mechanism (cron) for timers and another (inetd) for sockets and another (init scripts) for system boot. And all of them use the same service monitoring, logging, etc.
Easy integration with various kinds of sandboxing. One line in a .service file and a service runs in a chroot, or has no network access, etc.
And then there's just the general standardization effort to unify the dozens of different places that things get configured into one mechanism that's the same across distributions. For instance, before systemd, distributions had various different places to configure the hostname; now, distributions have largely standardized on `/etc/hostname`. There are many more instances of such standardization, and most of them have been successful.
Believe me, I also looked for any example of desktop Linux getting any kind of prioritization in the kernel, and it just doesn't happen.
I don’t know if 20 devs can solve the app ecosystem problem. Although, gaming is getting there … so maybe there is hope for regular apps as well.
Maybe Hector (from Asahi linux) can learn something from Con. Con maintained scheduler patches for a long time.
It is sad that he no longer does it, but given Linus' attitude, this was expected.
However, it is much easier to talk about these things if there is actual data you can point to and that did not seem to be available.
https://news.ycombinator.com/item?id=43127568
"Back in 2011, Con Kolivas left the Linux kernel community. An anaesthetist by day, he was arguably the last great Linux kernel hobbyist hacker. In the years since it seems things have, if anything, only gotten worse. Today, it is practically impossible to survive being a significant Linux maintainer or cross-subsystem contributor if you’re not employed to do it by a corporation. Linux started out as a hobbyist project, but it has well and truly lost its hobbyist roots."