Agent P waxes lyrical about 14 years of systemd
- Reference: 1738839670
- News link: https://www.theregister.co.uk/2025/02/06/14_years_of_systemd/
- Source link:
"It's now the biggest FOSS event in the world, in terms of the number of streams, program items and talks, and in terms of virtual attendees," co-organizer [1]Richard "RichiH" Hartmann told The Reg .
We spoke to him just before he delivered his [2]FOSDEM infrastructure review , and he claimed: "Every year sets new records for how many virtual attendees stream the event, and this year, we already broke it by midday on Sunday."
[3]
It's free, and there are no badges or memberships – you just turn up – so it's hard for them to track warm bodies. (It's the geek's Glastonbury, and it's pretty difficult for attendees to get from one talk to another too.) This year, doubtless the best-insulated warm body – at least financially speaking – was Twitter, Bluesky, and [4]Block co-founder Jack Dorsey , who had planned to give a keynote talk on [5]Infusing Open Source Culture into Company DNA .
[6]
[7]
Many, including über-hacker Drew DeVault, whom we have quoted in The Register a few times, received this news with [8]less than universal approbation . DeVault [9]organized a sit-in protest and the [10]talk was canceled . We did not see Mr Dorsey ourselves amid the teeming hordes, but FOSDEM is big enough that we didn't see lots of people we'd hoped to, even when trying to and frantically exchanging Signal messages.
Among some open-saucy circles, the figure of systemd supremo [11]Lennart Poettering is almost as controversial – he [12]joined Microsoft . His main-program item went ahead, titled [13]14 Years of systemd :
Let's have a look back at the tumultuous beginnings, how we became what we are now, and let's talk a bit about the perspective for the future, what systemd is supposed to be in the eyes of its developers – and what it shouldn't be.
He received a rapturous welcome, with a massive round of applause, and not a single rotten tomato was flung. It was a rapid, dense talk and he had to skip several of his [14]34-page slide deck [PDF].
Poettering started with what he called the prehistory: "Once upon a time, there was sysvinit. It's still maintained! But it's old," noting that sysvinit first appeared in 1983, and the Linux version in 1992. If that's prehistory now, then we are put in mind of other wise words: History became legend. Legend became myth. And some things that should not have been forgotten were lost.
[15]
Agent P then moved on to Canonical's Upstart, which he said was born in 2006 and was dead by 2014. He claimed it failed because:
It didn't solve the problem: admin/developer told the computer on which trigger to do what action, in order to build full tree of actions to reach some ultimate goal.
He also noted the contentious issue that Canonical requires copyright assignment, which isn't unique, but annoys some developers. (Just a day after his talk, we noticed André Machado's [16]Why Upstart from Ubuntu Failed , which covers this part of the history in more detail.)
The talk subsequently moved on to the early history, and what became today's systemd: babykit. At the time, Poettering said, there was a trend for all daemons to be called something-kit, for example, policykit , saying that "babykit was a process babysitter." He described it as a "transactional system, the basic ideas hashed out during a flight back from Linux Plumbers Conference 2009, by Kay Sievers and yours truly." He characterized it as a "proper open source project, with no copyright assignment, LGPL version 2.1." And he nodded to some influences and prior art, not only including Upstart but also [17]Apple's launchd , especially its Socket Activation feature, and [18]Solaris SMF . But, he said, systemd also includes "one or two original thoughts (I think?)"
This much is relatively established and agreed, but while those who were following this stuff a decade and a half ago knew that Mac OS X and Solaris both had next-gen init systems, we're not so sure that some of the louder voices today remember this. Now we mostly see comparisons with less-ambitious replacements such as OpenRC, and it seems to us that the original motivations are being forgotten. This really is a problem. As George Santayana wrote in 1905: "Those who cannot remember the past are condemned to repeat it." In his Usenet signature in 1987, Henry Spencer amended this to: "Those who do not understand Unix are condemned to reinvent it, poorly."
This struck us because next Agent P moved on to an attempt to establish systemd's UNIX™ credentials, asking: "What the heck is UNIX even?" Perhaps the team is still stinging from the response to the [19]systemd 256 announcement last year , which boasted "now with 42 percent less Unix philosophy." His argument runs thus:
Linux is not UNIX
UNIX: unified repository with kernel and userspace in one
Linux: everything split up, distributed ownership (aka: chaos)
Linux + systemd: still everything split up, just a little bit less.
Is this UNIX? Nope. Closer to UNIX? Yeah, probably!
Judge for yourselves if this is a fair summary. We personally disagree on the detail. As we [20]said in 2023 , we feel that Linux is a Unix, but only in ways that don't really matter in the 21st century.
He went into some detail on this aspect as it is a common criticism. For instance, questioning some dogma:
"Everything is a file"
(Is it really? Sorry, but my printer is not a file! 🙃)
Well, yes , Lennart, older ones that talk PostScript – or HP PCL, or Epson Esc/P – over a good old physical cable were nodes in /dev , and you absolutely can just cat some text to them.
"Shouldn't running services be files too"?
sysvinit: nope, why would you think so?
systemd: kinda, maybe directories at least? (cgroupfs)
This part has some persuasive force, although we see it as imposing a hefty additional layer of complexity on top of the basic Unix model. The real solution that [21]the chaps who designed Unix came up with is not to bolt on additional process namespaces; it is to put every process in its own namespace, virtual file system and all.
The result? Well, a few slides later, Poettering went on to systemd's size and complexity:
~690K SLOC
(compare: wpa_supplicant ~460K or glibc ~1.4M)
On Fedora, full blown install is 36M bytes (compare: bash ~8M)
"It's not that bad, I think"
Well, the entire 9Front OS kernel is about 5 MB, as we [22]described at FOSDEM last year :
The entire distribution including all sources, documents, local Git repository, and binaries is circa 530 MB for amd64.
[23]systemd begrudgingly drops a safety net while a challenger appears, GNU Shepherd 1.0
[24]systemd 256.1: Now slightly less likely to delete /home
[25]Version 256 of systemd boasts '42% less Unix philosophy'
[26]Microsoft's Lennart Poettering proposes tightening up Linux boot process
In our opinion, Ken Thompson and Rob Pike did the more elegant job, with some guidance from Dennis Ritchie. Perhaps we're biased, though, and to be fair, we use computers running Poettering's code almost every day, and ones running 9Front about twice a year. Speaking of which, a new release of 9front, dubbed [27]This Time DEFINITELY appeared on January 19. (We suggest you take a close look at the illustration on the cover: "Welcome, NIX. Seriously.")
[28]
Apple's Wall Street Journal ad circa 1981, which reads: Welcome IBM, Seriously – click to enlarge
Poettering was also keen to note his baby's modularity:
Suite of ~150 separate binaries
Quite modular
Most components optional, except for the core: the service manager, i.e. PID 1
(Almost) all in C
On the topic of the language, he said:
We started with the oxidation process (systemd-zram-generator)
(Not part of main repository yet, though)
Limitations in the Rust tooling remain problematic:
What so far slowed us down: we have a complex build, with many binaries and tests, with many interdependencies. Not fit for Cargo. And Meson didn't used to like Rust too much. The impedance mismatch sucked, and is not something we wanted to work around ourselves.
Criticisms aside, it's undeniable, systemd has won. He noted that by 2011 it started to become default: in Fedora since 2011, in openSUSE and Arch in 2012. Soon after, it got its own conference, systemd.conf, held in 2015 and 2016 in Berlin. Since 2017, it's been called All Systems Go. By 2019, it got a logo, and its own website. His summary was:
Where are we today: All major distros. The world runs on it.
He said there is a "vibrant community," with "six core maintainers, 60 people with commit access, and over 2,600 contributors."
Unfortunately, around this point in the talk, Poettering began to realize that he was running out of time, and as he moved to the section titled "Goals and Challenges for the Future," he started skipping more and more slides, while also speeding up, and things started to become a bit less coherent. He touched on the team's efforts toward "Boot and System Integrity," which is [29]an area we have examined before .
[30]
He said: "All big OSes (Windows, Android + ChromeOS, Apple) have boot and system integrity implemented in one way or another," and wants to bring this to generic Linux. This is where this vulture personally starts to disagree. We don't want encrypted drives, TPM modules, sealed validated boot processes, [31]managed home directories that aren't actual directories anymore, or pretty much any of these features – but little of that got discussed.
There were slides about the systemd efforts towards image-based OS deployment, persistent OSes, re-engineering inter-process communication, and replacing the use of [32]dbus with something called [33]Varlink , using JSON to pass information between programs instead of plain text – but, unfortunately, he skipped over almost all those slides.
It's clear that Agent P has a vision, or visions, for the future development of Linux and how it works. Sadly, this time around, we got more of the history and state of the art than the future. It's clear that not everyone is going to agree with this plan, but it must be conceded that so far, the world is going in that direction. We feel that efforts such as the Devuan fork of Debian lack an alternative proposal. They just want to retain the old ways, rather than proposing better alternatives. This applies equally to almost all the [34]systemd-free distros . That's not enough to mount an effective defense. The only project we've seen that really seems to engage with much of the modernization work that systemd is doing, such as [35]seat management , is [36]Daniel Kolesa's Chimera Linux , which tackles it using tools brought over from FreeBSD. ®
Bootnote
To be fair, it's not all that hard to get a main-program slot in the big Janson hall. Even this vulture has [37]spoken there – and on his first try, too. It can't have been that bad; the organizers even [38]put him there again in 2020 .
Get our [39]Tech Resources
[1] https://fosdem.org/2025/schedule/speaker/richard_richih_hartmann/
[2] https://fosdem.org/2025/schedule/event/fosdem-2025-6714-fosdem-infrastructure-review/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z6TqtDfmiQq7f-id6OAMeAAAAQQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] http://web.archive.org/web/20250118001428/https://fosdem.org/2025/schedule/speaker/jack_dorsey/
[5] http://web.archive.org/web/20250118001426/https://fosdem.org/2025/schedule/event/fosdem-2025-4507-infusing-open-source-culture-into-company-dna-a-conversation-with-jack-dorsey-and-manik-surtani-block-s-head-of-open-source/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z6TqtDfmiQq7f-id6OAMeAAAAQQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z6TqtDfmiQq7f-id6OAMeAAAAQQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://drewdevault.com/2025/01/16/2025-01-16-No-Billionares-at-FOSDEM-please.html
[9] https://drewdevault.com/2025/01/20/2025-01-20-FOSDEM-protest.html
[10] https://drewdevault.com/2025/01/23/2025-01-23-Transparency-and-governance-FOSDEM.html
[11] https://fosdem.org/2025/schedule/speaker/lennart_poettering/
[12] https://www.theregister.com/2022/07/07/lennart_poettering_red_hat_microsoft/
[13] https://fosdem.org/2025/schedule/event/fosdem-2025-6648-14-years-of-systemd/
[14] https://fosdem.org/2025/events/attachments/fosdem-2025-6648-14-years-of-systemd/slides/237028/14_Years_cfrZhmg.pdf
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z6TqtDfmiQq7f-id6OAMeAAAAQQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[16] https://machaddr.substack.com/p/why-upstart-from-ubuntu-failed
[17] https://github.com/apple-oss-distributions/launchd
[18] https://www.oracle.com/technical-resources/articles/solaris/intro-smf-basics-s11.html
[19] https://www.theregister.com/2024/06/13/version_256_systemd/
[20] https://www.theregister.com/2023/01/17/unix_is_dead/
[21] https://www.theregister.com/2024/02/21/successor_to_unix_plan_9/
[22] https://www.theregister.com/2024/02/21/successor_to_unix_plan_9/
[23] https://www.theregister.com/2024/12/13/systemd_257_gnu_shepherd/
[24] https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/
[25] https://www.theregister.com/2024/06/13/version_256_systemd/
[26] https://www.theregister.com/2022/10/26/tightening_linux_boot_process_microsoft_poettering/
[27] http://9front.org/releases/2025/01/19/0/
[28] https://mattrickard.com/welcome-seriously-ads
[29] https://www.theregister.com/2022/10/26/tightening_linux_boot_process_microsoft_poettering/
[30] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z6TqtDfmiQq7f-id6OAMeAAAAQQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[31] https://systemd.io/HOME_DIRECTORY/
[32] https://www.freedesktop.org/wiki/Software/dbus/
[33] https://varlink.org/
[34] https://nosystemd.org/
[35] https://man.sr.ht/~kennylevinsen/seatd/
[36] https://www.theregister.com/2023/02/13/chimera_non_gnu_linux/
[37] https://archive.fosdem.org/2018/schedule/event/alternative_histories/
[38] https://archive.fosdem.org/2020/schedule/event/generation_gaps/
[39] https://whitepapers.theregister.com/
"It's still maintained! But it's old,"
The (modern) human genome at least 100,000 years is unquestionably old and it is still maintained - an onerous task no doubt but I do believe many receive some pleasure from the undertaking.
Systemd by analogy would correspondingly be an upgrade offered by Lumic's Cybus Industries.
two corrections:
> Let's have a look back at the tumultuous beginnings, how we
1. It is not "tumultous", it is "tumorous"
and
2. With you (and your co-conspirators), there will never be a "we".
Re: two corrections:
Well, like a tumour, there has been a malignant takeover growth of other functions.
Modular?
I almost spit out my tea when I read that.... I is not modular in the sense that you can actually swap out modules with other modules, e.g. for sound. I would really encourage anybody to compare how difficult it is to make some daemon run at system start in sysV (copy or heck even write the init file, it is not hard, make a link in the runlevel you intend it to run, with the correct startup order in the name, f' just put it on 90) and replacing e.g. pulseaudio with pipewire....
Also: has systemd "won"? Wow, "winning" at that is... a messed up comment.
Re: Modular?
Modular as in "just on module needed to pull the other parts in via dependency".
Re: Modular?
As in RJ45 plug - when the weak plastic bit that locks the plug into the socket is (easily) broken off and the plug floats about in the socket but of course the patch isn't replaced so you are thereafter plagued by intermittent, impossible to diagnose faults....
Methinks t'is very like Poettering's pride and joy.
"And some things that should not have been forgotten were lost"
You see - he _did_ know better at the time.
Go OpenRC!
"(Almost) all in C"
I propose that systemd should be feature frozen and re-written completely in Rust. To keep him busy, because the devil finds work for idle hands.
Re: "(Almost) all in C"
And when the rewrite is almost done someone needs to come up with some other shiny modern language to rewrite it to.
Re: "(Almost) all in C"
Or an old one. APL.
Mandatory listening..
https://www.youtube.com/watch?v=o_AIw9bGogo
Benno Rice's talk "The Tragedy of systemd" from linux.conf.au
It is very good.
Reading this makes me cry
Every time I read about Potta's rants and grand schemes for devastating Linux even more than this, I just want to cry. Hopefully I'll be retired (or dead) soon enough to be able to just avoid the time when systemd will become the whole OS.
Re: Reading this makes me cry
One is reminded of the MCP in 'Tron'...
Re: Reading this makes me cry
when systemd will become the whole OS
We're already long past that point.
Re: Reading this makes me cry
Not on here we're not.
Sent from my Devuan-powered laptop.
"we have a complex build, with many binaries and tests, with many interdependencies."
Is this how you define "modular", Agent P?
How many lines-of-code is OpenRC?
I've been writing Rust, intensively, for the better part of a decade and I will be the first to agree that Cargo is not perfect. Don't even get me started on "features" – what they were, what they are, what they were intended to be and how people abuse them across the ecosystem. But the truth is that Cargo is actually bloody brilliant when one considers it, objectively, and thinks back to Autotools or CMake. Cargo works well enough right "out the box" and it works pretty much the same way for every project that applies it, correctly, on every supported platform. Rust is "nice" because you *can* just `git clone` most code-bases and Cargo will usually build them, run their tests and executables and their examples. You can edit those examples' `main.rs` source and start to hack right away and Cargo keeps running them so you can play. The on-boarding process to try out something in the Rust & Cargo ecosystem is easily the best I know by a million miles, chains, cables, furlongs or what-have-you.
But let's just take a step back: you're making an "init system". That is: a system that runs to spawn other processes, monitors them over their life-time, killing some and restarting others if they die. If the structure is, indeed, so convoluted that it can't be built with Cargo, you're inept or you're wildly out of scope and I wouldn't want to touch what you're making with a ten-foot pole.
I think the mention of Meson is apt, though. Meson is basically the systemd of build tools: it is extremely opinionated and hostile to every other build system, offering heavily begrudged support for integration with CMake out of necessity (because everything else either uses or supports CMake – it being the industry-standard incumbent) but holding the line that interoperability means "just port everything to Meson".
Do you want to link SDL in a Meson project? Great! You've got the flagship demo for that specific case. Oh: you want to use a version of the SDL that doesn't match the demo's current "wrap" version? Good luck, then, because SDL builds with CMake in a non-trivial way so you'll be patching the official demo "wrap" (and it is exceedingly verbose, being a complete reproduction of the SDL build mechanism), writing something entirely new or hacking together some very cursed solution that will never be supported because you're using Meson in a way that contravenes their "philosophy". Ditto for every other non-trivial dependency that doesn't coincide with an official "wrap": it's all just "port to Meson" because that is the only supported way. (Edit: citation: https://mesonbuild.com/Mixing-build-systems.html)
Re: How many lines-of-code is OpenRC?
What has this to do with OpenRC?
Re: How many lines-of-code is OpenRC?
Agent P chose to compare the number of lines-of-code of systemd with that for glibc – an implementation of the C standard library and not actually an init system – or that of bash (a shell, not actually an init sytem) or wpa_supplicant (a wifi thing, also not an init system) and so some crazy, off-spec, non-conformist part of my brain wondered if, just maybe, a more interesting comparison would be to – you know! – another init system.
But maybe he was trying to suggest that systemd isn't actually an init either. I'm sure it contains a complete implementation of a C standard library, a shell and a wifi layer, too, by now. Maybe those are written in fewer lines of code, too, for all I know.
Actually, I do wonder why he's bothered that Cargo doesn't meet their requirements. That seems a little off-brand; I'd have expected him to just add an entire Rust build toolchain to systemd and roll with it.
Not a Hater
I'm still trying to understand why I'm meant to hate it so much. I know it rather breaks the "do one thing and do it well" philosophy, and I know it forces certain ways of interacting; but it does solve some problems and brings the whole service management game up to date. I have no particular attachment to the ancient ways, even though I "should" as an old skool Unix bod (cut my teeth on Solaris in the 90s before Linux took over). Let's hear it for the positive aspects of systemd.
Re: Not a Hater
"Let's hear it for the positive aspects of systemd"
Tumbleweed.
Re: Not a Hater
Ditto. I just want to get things done. Systemd works. End of story. These are software tools, not objects of religious devotion.
Re: Not a Hater
For me, broadly it seems to work fine if I don't have to interact with it at all. But, and like the poster just below you, I once tried to get it to do a thing (in my case - more or less to automatically run something once networking was up), and I couldn't work out how to do it, and I found the documentation incomplete (or maybe I just couldn't find the right doco), and because the things that look like they should have worked (based on available doco/examples), didn't.
So there's different sorts of "works" here: (a) working ok in the background as setup by your distro, and (b) working when someone wants to make it do something beyond that .
Re: software tools
"These are software tools, not objects of religious devotion"
This is *open source* . Religious devotion was open-source developed and is widely popular here.
The fundamentally undeniable point: this, indeed *is* open source. All the distros are free to choose anything else besides systemd yet here we are, with systemd being the most popular choice among the largest Linux distros.
So [devout tech-head] users loathe it, yet system devs and distro creators seems to [accept/love] it. So, there's a disconnect between the hardest-core tech users...and, mostly, everyone else, as forum boards covering distros from Debian to Ubuntu aren't DDoS'ing over systemd.
So, why? As some of the posts here describe, some people are very focused on ethos of *nix rather than if the OS plain works for most people. "Do only one thing, and do it well" was all and good 30 years ago, during Unix's limited-use hayday, but pushing the ethos on widely-supported, unknown hardware and beginner-to-intermediate level users - is that still the best idea? 30 years ago you didn't have sophisticated kernel-level GPU drivers, sound drivers, muti-kernel and multi-thread virtualization, and more. Was it becoming too much of a patch-together hodgepodge for devs, never mind users, to debug and administer? Sounds like it from Poettering's view, and sounds like it from the open adoption of systemd by the developers of distros themselves.
icon: flamesuit. Because this is a fierce and heated topic here, but this seems to be the minority opinion ("He received a rapturous welcome, with a massive round of applause, and not a single rotten tomato was flung") and they'll never admit that to themselves.
Re: So, there's a disconnect
I'm inclined to say "of course there is". (Some/Many/but not all) system devs and distro creators accept it - well, probably because they have managed to get it to do what they want (or presumably they wouldn't have switched their distro over).
But that's not the only use case - many other linux users, such as the techy ones, might also want to get systemd to do something, but unlike the system-devs (etc) don't necessarily have the time to get to grips with the non-trivial ins-and-outs of how you get it to do things. But they do know that the old scripted system might've been clunky, but was otherwise dead easy, because even a vaguely techy linux users can write a script. So your techy user wants to make systemd do some particular task, but then hits what seems like a wall of poorly documented systemd blocking their way. And when they could've put together a simple bloody script to do it in 15 minutes. How is that not going to be annoying?
I'm a hater.
Does it work? Who can say? What does it work *at*? If that question were simple, I – too – would honestly not care very much about it because I do not count "init systems" amongst my areas of interest, particularly. I do consider myself to be a systemd hater, however. I'll own it!
I can't answer the question of what systemd works *for* or at because it seems that systemd is trying to be everything: it is not just init. Every other news story about systemd concerns its creeping into yet another domain it has no reason to touch.
So, I ask: who can say it works? We can't even define what its scope is or what it will be, tomorrow, so who can define whether it is fit for purpose or not?
I hate it because I can't ignore it as long as I'm a Linux user. The way it creeps into every domain makes it necessary for me to know about it and care about whether it is fit for purpose or compromised. The more systems it touches, the more irreplaceable it becomes and the more I need to care about it.
I run Gentoo, on OpenRC, and don't even use systemd and yet, still, I have to care about it because of its outsized impact on the whole Linux ecosystem – that's why I hate it.
I don't know a damn thing about how sysvinit looks on the inside, or how OpenRC's upstream code-base truly is to hack on, but I do know that I can define their standard operating conditions and the job they're supposed to perform and I can answer that question: do they work? If I determine that either one is lacking, I can implement my own replacement to meet my needs because their scope is contained. It is nearly impossible to "replace systemd" in the ecosystem, today, and only becomes more difficult with every new development in this farce.
To judge that it works would require confidence that it succeeds at what it claims to do which I've argued is ineffable but it is easy to prove that it does NOT work because one only needs to find the stuff it breaks. I use Gentoo almost exclusively on desktops and servers, today, but I have used systemd-based distributions often enough to see it break, frequently, often rendering Linux mechanisms that should be 100% independent of init, like `sudo`, totally inoperable or introducing new supply-chain attacks, like the way the whole `xz` thing transpired.
Should the OpenSSH developers have cared about whether the supply-chain of `xz` should form part of their threat model because of how distro package maintainers at Debian might link things to satisfy the requirements of agent P's "init system"? That would be totally absurd but, yet, that actually happened. That actually came to pass. That is why I care. That is why I'm a raving, frothing lunatic with rage whenever I read about systemd. This situation *is* absurd.
… and it threatens our operating system: Linux. I actually like to be able to use computers that run a sane operating system.
Re: Not a Hater
I tried to write a script to upload images from my camera when it was plugged in.
Simple enough task, right?
I fought systemd for about 4 weeks. Systemd did things like killing the script I ran to pop up an X Windows notification about what files were uploaded.
I gave up, moved from Debian to Devuan, and wrote a working udevd script in about an hour, which included learning how udevd worked.
"It's still maintained! But it's old,"
So am I. And wiser.