What you’re refering to as Linux, is in fact, Systemd/Linux, or as I’ve recently taken to calling it, Systemd + Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning Systemd system made useful by the Systemd corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX
ProgrammersAreHumanToo, great stuff.
🤣
When does systemd stop? Linux without it is increasingly looking unlikely in the future. Are we not worried about it being a single point of failure and attack vector?
This isn’t a moan about the unix philosophy btw, but a genuine curiosity about how we split responsibilities in todays linux environment.
SystemD will consume the entirety of Linux, bit by bit.
- In 2032, SystemD announces they’re going to be introducing a new way to manage software on Linux
- In 2035, SystemD will announce they’re making a display system to replace the ageing Wayland
- In 2038, the SystemD team announces they’re making their own desktop environment
- In 2039 SystemD’s codebase has grown to sixteen times its size in the 2020s. SystemD’s announces they’re going to release replacements for most other packages and ship their own vanilla distro.
- In 2045 SystemD’s distro has become the standard Linux distribution. Most other distros have quietly faded away.
- In 2047, SystemD announces they’re going to incorporate most of GNU into SystemD. Outrage ensues from the Free Software Foundation, which vehemently opposes this move.
- In 2048, Richard Stallman dies of a heart attack after attempting to clone SystemD’s git repo. SystemD engages in a hostile takeover and all resistance within the FSF crumbles
- In 2050, SystemD buys the struggling RedHat from IBM for $61 million.
- In 2053, most world governments have been pressured into using SystemD.
- In 2054, Linus Torvalds, fearing for his life, begins negotiations to merge kernel development into SystemD
- In 2056, the final message on the Linux kernel development mailing list is sent.
- In 2058, Torvalds dies under suspicious circumstances after his brand-new laptop battery explodes.
- In 2060, SystemD agents assassinate the CEO of Microsoft.
- In 2063, after immense pressure from SystemD-controlled human rights organisations, Arch developers discontinue development.
- In 2064, the remaining living Debian developers release the next stable version of their clandestine and highly illegal distro.
I think you might want to recheck the ages of some of the people in your timeline, most of them aren’t that young anymore.
Thanks for that write up. Made my day! 😄
That comment was brought to you by an AI LLM. No one actually took the time to write that.
🥴
Nope, doesn’t have any of the hallmarks of an LLM and LLMs aren’t yet clever enough to produce original humor like that.
Debian already uses systemd.
Debian in many ways isn’t as slow-moving as people think.
For example, they moved to Wayland by default (for Gnome anyway) in 2019. A number of well-known distros likely won’t have that until 2025/2026 or beyond.
Sadly they’ve been dropping archs throughout the years, meaning they’re no longer the distro you can use to run on “anything” from a pi to a mainframe…
Doesn’t trixie still support like a dozen arches? I think one of the more recent deprecations was MIPS BE which is functionally obsolete in 2024, at least insofar as practically no one is using it to run a modern distribution.
Bookworm, Trixie, and Sid all currently support a total of 10 different architectures.
And looking through the Wikipedia article for Debian’s version history, most of the dropped architectures were functionally obsolete when they were dropped, or like the Motorola 68000, when support was added. (notable exceptions being IA-64 which was dropped 4 years before intel discontinued it, SPARC which is still supported by Oracle, and PowerPC.)
If your bar is “modern distribution” stick to Ubuntu.
If you want to maintain older hardware Debian used to be a go-to solution.
What’s the go-to solution now?
deleted by creator
Agreed, this is a nice inclusion. I also hate sudoers with a passion - I already use
doasbut it’s not standard (in the Linux world anyway), but with systemd providing an alternative means that it’ll become a standard which most distros would adopt, and I hope this means we can finally ditch the convoluted sudoers file once and for all.deleted by creator
The thing with this is: its just a symlink to the
systemd-runbinary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debiansystemdpackage includessystemd-run.I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is
makepkgthat should never be executed as root, but does internally call some things with elevated privileges (mostlypacmanto install and remove packages). Currently it checks forsudoand if not falls back tosu, but maybe it might be worth considering changingsuforrun0if its guaranteed to be there.deleted by creator
I read the original mastodon post by the developer of run0 and I am still don’t understand what the problem with SUID is.
Whats an example of an attack that would work with sudo and doas (which also uses SUID) and not on run0?
deleted by creator
I’m no Linux expert, but I’ve never had any problems with sudo, it just works. Shouldn’t systemd have higher priorities on their mind? This feels like change for the sake of change. And if this does happen, I sincerely hope that it just works, like sudo.
It’s still missing core functionality for an init system, like a display server protocol, compositor, desktop environment and web browser smh.
systemd-chromiumd
This but unironically, would be better than Electron (low bar, I know)
But for why (I’m commenting this before reading) wouldn’t it make more sense to home I’m the scope of systemd so it can be easier to maintain? Why have it do everything?
Why have it do everything?
Isn’t the guy behind systemd a (former?) Microsoft employee? I feel as though that might offer a clue as to why the trajectory towards bloat.
It is. He is poisoning Linux, slowly, from the inside. Like the XZ attack, just smarter and much slower.
Why do you consider it as poisoning? I’ve heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?
Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they’re a very welcomed feature imo
By itself, solely doing init, it would have been fine, however, binary logging (even if you eventually end up with a text log, that’s wasting disk space on a binary format no one wants or needs), and it didn’t stop there. He keeps replacing Linux subsystem after subsystem, and many of those replacements are not progress, just duplication of effort and creates more ways for configuration drift.
You can still forward to text syslog or to a central logging server like Loki if working with multiple hosts. I still don’t get the issue with binary logs.
Yes, and many distros have that out of the box… But they don’t have it sent to keep the binary journal as close to empty as possible. So you end up with twice the space in use for logs. As for the issue with binary logs, text logs can be read by far more tools and utilities, rather than just journalctl and pipes.
You can set the space limit for journals logs really low then, to avoid double space usage. As for the last argument, that also was an issue for me years ago because not all tools were compatible with the journald format, but that’s since long fixed now and I’ve not experienced any issue for a long time. Journal logs provide a standard format for all applications, so third party tools don’t need to be compatible with every log format of your applications. And it also comes with great additional features like -b or --since etc. So I still don’t get the issue here
