> Perhaps as BPF subsumes Linux into making it a managed-runtime hybrid kernel with subsystems becoming increasingly componentized and instrumented (with early signs in the proposal to add Linux Security Module hooks to BPF programs), as pidfd/process descriptors allow for reliable supervision to be distributed across self-contained processes, as the native Linux mount API becomes more event-driven on its own, and as a generation of Rust fanatics in their undying religious zeal insist that all men are obligated to offer sacrifices to the borrow checker, a new shift may emerge where once again, the init system is made to cease mattering.
Alpine, Devuan, Gentoo and other devs have kept init choice available.
> Alpine, Devuan, Gentoo and other devs have kept init choice available.
Nothing stopped anyone, including yourself, from modifying or forking a distro like Fedora to make it support non-systemd, it's just you can't expect others to do it for you.
It's not about expectations it's about distributions going out of their way to remove choices from users in some highly opinionated ways.
Which is all fine, I just won't use your distribution, what surprises me are the people who feel the need to step in an "defend" this rather pointless outcome for some reason. My favorites are those who suggest that this had to occur in order for linux to "mature" or "become modern."
> Nothing stopped anyone, including yourself, from modifying or forking a distro like Fedora to make it support non-systemd
Pottering et al went out of their way to make this harder than it would otherwise be (e.g. adding the gnome hard-dependency on logind which they then variously claimed was necessary, was unintended, was accidental...)
Nothing's stopping me from modifying Windows to do what I want either, it's just hard. There was a time when Linux people cared about whether their systems were easy to modify.
logind isn't really the worst of it, systemd has a tendency of usurping existing solutions into only working with the rest of systemd, instead of helping improve the ecosystem for everyone.
logind provides features developers of software that use them want or like, people aren't adopting it just for the sake of it.
e.g. GNOME Shell now uses systemd user services to manage its sub services rather than starting them itself. Why? Because systemd does service management a lot better and provides proven features (logging, sandboxing, cgroups etc) rather than GNOME having to re-implement them.
> logind provides features developers of software that use them want or like, people aren't adopting it just for the sake of it.
On the contrary, as the article describes, Pottering and the RedHat team pushed all these projects to adopt their stuff, and part of that was making the patches themselves and saying a lot of things that turned out not to be true. It absolutely wasn't an organic success on its technical merits.
What good is being able to install sysvinit if it doesn't run your services? Debian killed first-class sysvinit, the downgrading of Debian/kFreeBSD is proof enough.
(And more importantly it killed all other well-behaved cooperative init options - this isn't about systemd vs sysvinit, it's about systemd vs standards-based init systems that play nice)
https://www.youtube.com/watch?v=o_AIw9bGogo (The Tragedy of systemd) is an interesting talk on this topic from the view of someone (Benno Rice) in BSD land. Highly recommended.
EDIT: this is mentioned in the article, thanks koalacola
I'll second this recommendation! Benno Rice is an insightful, energetic, witty, and just plain enjoyable tech speaker. 'What UNIX Cost Us'[1] is another favorite of mine that the audience on this post might enjoy: https://www.youtube.com/watch?v=9-IWMbJXoLM
Benno intentionally misrepresents his opponents in a way I find disingenuous, especially in that video, and it boils my blood.
Tacitly: most people don’t like launchd, but they don’t interact with it either. Find me a person who writes or debugs launchd plists and you’ll find that:
1. they’re quite rare
2. they don’t like launchd
launchd and systemd aren’t even comparable, one is part of a monolithic proprietary operating system and the other is an ecosystem that is semi-modular which lends itself strongly to being an entire layer of your computing experience (dubbed: “the system layer” by Lennart Poettering).
There is an element of “do it yourself” with Linux, which leads to people (especially people with entrenched knowledge) being wary of things that cannot be debugged easily- but launchd exists in an ecosystem where “take it to the store” is a legitimate fallback, and even if it weren’t there is a built in backup/restore system that literally restores the machine to its entire previous state.
Disregarding the proprietary or “creep”/complex discussion about systemd/launchd:
> Tacitly: most people don’t like launchd, but they don’t interact with it either. Find me a person who writes or debugs launchd plists and you’ll find that:
> [...]
> 2. they don’t like launchd
This is true in my case, although the main thing on my mind when I work with launchd my main complaint often boils down to 'I wish this were more like systemd'. IME, systemd has much nicer CLIs, more capabilities, clearer and more comprehensive documentation, more abundant examples, and more conveniences/less privileges required for per-user stuff. The simple INI format for systemd units is also a lot easier and nicer to deal with than the XML format that plists use, even though there's a lot of tooling around plists.
> even if it weren’t there is a built in backup/restore system that literally restores the machine to its entire previous state.
I get this for free on NixOS and it's really easy to get on other distros by plugging /etc/systemd into etckeeper, even without a snapshotting filesystem. (Plus many distros have backups via snapshots of CoW filesystems built in just like macOS does.)
> launchd and systemd aren’t even comparable, one is part of a monolithic proprietary operating system and the other is an ecosystem that is semi-modular which lends itself strongly to being an entire layer of your computing experience (dubbed: “the system layer” by Lennart Poettering).
Benno says literally all of this in his talk. He even has a diagram with the phrase 'system layer' up on a slide while he's talking about it. I just re-watched it yesterday. In case it's missing from the linux.conf.au version, which is the one linked to in the LWN article linked to by the OP, here's the earlier BSDCan version, which is what I rewatched yesterday: https://www.youtube.com/watch?v=6AeWu1fZ7bY
Unlucky. Posted to HN the day after SSL expired. You need to turn on certbot-auto to renew your LE cert.
I recall the initial systemd stuff that was constantly posted etc. but now I routinely write unit files and it's really nice. I'm sure the constraints that systemd introduced were a pain in the ass for maintainers but for a user it's been tremendous. Admittedly, some times I just a service unit instead of a mount unit for FUSE and so on, and I still have trouble with `After` and `Before` and `Wants` but overall I rather like it.
Now I have to go check what happened about PulseAudio which is the other Poettering work that everyone and their uncle hated (or maybe it was just Ulrich Drepper who hated systemd). It's funny to me that in the end, my teenage self was some sort of equivalent of a k-pop stan: applying Con Kolivas's scheduler patches, and choosing Poettering over Drepper or whatever. And now all that memory has faded but the names.
Pulse was only really janky in the early years; by 2010 it was as solid as anything else in tech. Even then, it was absolutely an improvement over the previous system which either needed manual configuration per program to choose whether to use ALSA, OSS, EsoundD, or Arts with success of portaudio and other sound systems too keep things interesting. Even if you did get things working, I distinctly recall having to restart Firefox in order to play music because Firefox had the only available connection to the sound device.
> by 2010 it was as solid as anything else in tech.
Nah, it stayed flaky well past then.
> it was absolutely an improvement over the previous system which either needed manual configuration per program to choose whether to use ALSA, OSS, EsoundD, or Arts with success of portaudio and other sound systems too keep things interesting.
No it wasn't. It was just one more annoying option in the list.
> Even if you did get things working, I distinctly recall having to restart Firefox in order to play music because Firefox had the only available connection to the sound device.
That was a misconfiguration that was possible to do in some systems, sure. There were plenty that avoided it.
Actually, I used ALSA without anything else for a long time until recently. I only needed to install pulseaudio because Microsoft Teams didn't work without it and I needed it for work.
I guess modern apps were developed against those APIs that they've become a necessity now?
If you want to keep using alsa with applications that otherwise only work with pulseaudio, you can try apulse[1].
When I used to use it, it worked nicely, but I started using pulseaudio around the time of its most recent release, when I got frustrated by having to tweak asoundrc to use a USB microphone, and being unable to figure out how to bump up its sample rate.
Pipewire was created to support containerized applications (with limited system access), to also support video, and to unify both pro low-latency audio (JACK) and regular low-power audio (PulseAudio).
It might have been possible to retrofit this all into the PulseAudio project - but the authors decided to start from scratch. There are some interviews and talks on YouTube, they might have insights into why exactly that was the case. But I have not seen any indications that it was because PulseAudio did not work for what it was designed for.
Pipewire is a weird case. It was made as a general multi media orchistrator, that includes video and audio. It takes a lot of stuff from different sources.
> Then why was PipeWire introduced as a PulseAudio replacement
One of them is putting more focus on permission management with support for sandboxed containers, which is kinda necessary with the direction the Linux desktop is going. But it also is just a backend, that supports jack, alsa and pulse interfaces, so it was mostly a drop in replacement for the applications.
I switched from Pulseaudio to Pipewire at the beginning of the year, and all of a sudden my laptop is so stable I no longer need to reboot it every month or so. It seems to just be better disguised nowadays, not really much better.
The funniest to watch was systemd deciding to kill user processes on "last logout" so it would happily kill your elected PostgreSQL cluster leader as soon as the last follower is done catching up the WAL via rsync (over SSH). It was the perfect whack-a-mole game, always killing the leader once the cluster healed. Obviously you had to mark any service user as a system account.
How else could systemd purge left over processes (e.g. GNOME tracker and gvfsd)?!? You don't expect developers of the inevitable perfect Linux desktop to fix their code? No lets break the system and take down the well behaving applications with the fallout unless the operator knows (and has permission) to restore the old behaviour. Oh and I hope you didn't expect screen/tmux/dtach/nohup to work.
If you're using systemd as a service manager (which you probably should do, if your hosts are running systemd?), you don't need the user running your services to be a system user. You can just have (either) your services launch from a systemwide systemd service, or make sure your user has lingering enabled if you're using systemd user services.
If you're not using systemd to manage your application's services, you can still use the methods above if you just have systemd launch your process supervisor of choice (which you should definitely do if your hosts are running systemd and you're using some other process supervisor).
Reading the full history of all the attempts at modernizing sysv I really do think Lennart deserves all the credit for making a car when everyone else made faster horses. It's the true hacker spirit to look at problems with dizzying complexity and say, "eh give me a weekend." systemd really is a jewel of open source that did so many things right from the beginning that by the time it was done it made other hard problems outside of service management tractable.
Man I love systemd. Never has it been easier for me to setup a binary as a service. I dread the memories of customizing or writing init scripts and dependencies.
I don't get all the hate, that primarily argues about the philosophy of Linux, when the philosophy made everything just harder..but I guess some people just want to suffer for their believes, mich like some Catholics
It was about the udev/systemd maintainers writing "fuck you Gentoo developers" in a mailing list when they wanted udev to support only systemd, actually that udev should be part of systemd (for no real reason) and reimplementing things (sometimes badly for years) instead of reusing what was in place. It was about pretty big bugs (I remember a bug around coredumps being cut at ~700MB in size, which the systemd maintainers responded with the equivalend "well that's your problem not ours, journald is not fast enough and so we cut the max size" and was only closed eventually - ~3 years - probably because some RH customer screamed loudly enough). And the original discussions were even before systemd decided to hardcode what essentially is random IP addresses into resolved ("maintainers should change those values if they don't like them!") and other network services (NTP? I don't remember now anymore). It was about the billion libraries (later on there have been some security fun issues) it brought in and made your stuff link to (I vaguely remember something to parse qr codes?). It was about not-documented DBUS interfaces and making DBUS a core part of the system...
Most complex services still had heavy, long prestart script written in bash anyway at that point in time even when using systemd, so the script complexity was not really gone (and I think postgresql for example still has something like that).
Now, Redhat pushed hard for it and you cannot just ignore what they do and go your own way since the number of maintainers they employ is massive along the entire stack, from kernel to GNOME - Systemd was convenient to use and people went for it even with all the issues it had/has for good reasons (same as pulseaudio), but thinking the only discussion at the time was about the "linux philosophy" is a strawman and changing history a fair bit. :)
What does "proper software" have to do with systemd? Sometimes upstream provides unit files but normally it's on the packager to provide the integration into your distro.
I've seen some software depend on libsystemd for the sd_notify but I think after the whole security kerfuffle there won't be many of those anymore.
> Never has it been easier for me to setup a binary as a service. I dread the memories of customizing or writing init scripts and dependencies.
If you just wanted simple/easy init scripts you could do that with runit for years without having to switch dozens of unrelated system components over to the systemd-approved version and render your system unbootable every so often.
Windows has nothing equivalent to systemd. Windows "Task Scheduler" is very simplistic and disorganized compared to systemd. systemd is definitely one of the nicer things in the Linux world.
I like it a lot and my team uses it extensively to precisely specify the behavior of our embedded products. systemd has a low memory footprint for what it does. It also helps us make our products more secure by making it easier to isolate processes / different system services as much as possible. So the risk of getting hacked over a network service is reduced a lot. Without systemd we would be forced to create our own which wouldn't be as secure.
The service manager? It manages services with many of the same features of systemd units, including advanced features, like firewall integration. This is combined with windows event system which provides many of the same features of the systemd journal.
> making it easier to isolate processes / different system services as much as possible
These features are built into the operating system. systemd provides a particular method of accessing them, but certainly not the only one.
> So the risk of getting hacked over a network service is reduced a lot.
Your risk of getting hacked has nothing to do with systemd. You are hoping that the easy process isolation features you're referencing actually work and thus _mitigate_ the potential damage of that hack. This is not bad strategy, but is on it's own, entirely incomplete.
> Without systemd we would be forced to create our own which wouldn't be as secure.
At the risk of being hyper critical, this is precisely the type of logic I would use to sell snake oil, too.
I still haven't fully grasped the Systemd drama, or systemd for that matter, but boy do I love it. I enjoy how Linux has those turf wars nobody outside of it knows about.
SystemD is great when it works, which is most of the time. But when it breaks or you have to do something that SystemD doesn't support it becomes an enormous pain in the ass. It's like being back in Windows land again.
Some DBus message is not appearing and it stalls out your boot process, finding where it was supposed to come from and why it didn't appear is a nightmare. If you want to use a different daemon than the one SystemD provides for some service it will fight you every step of the way, sometimes even undoing whatever you had to do to make the process work in a random update. As someone who experiments with weird networking stuff from time to time I've been kicked in the nuts by NetworkManager on several occasions.
I know this is a completely unimportant tangent. But I'm always amused that systemd skeptics insist on the "SystemD" spelling. Where does that come from? I never see anybody talk about NtpD, InetD or VsftpD. But somehow systemd needs to be SystemD. As I said, amusing.
I'm pretty sure it's just ingroup signaling: it's not the only example of "spelling something wrong because you really hate it". For years I've seen people on forums who want to show their dislike say "MAC" instead of "Mac", "MicroSoft" and so on.
> As someone who experiments with weird networking stuff from time to time I've been kicked in the nuts by NetworkManager on several occasions.
nit: NetworkManager is not the one provided by systemd in the first place - that's systemd-networkd.
That aside I do wierd networking stuff for a living and here's how I see the available tooling:
* NetworkManager - great for a laptop where you're moving between networks and don't need anything too fancy.
* systemd-networkd - great for servers and other mostly static networking setups, even weird ones.
* If you're doing anything weird dynamically (e.g. experimenting) - disable the above or move the interfaces you are experimenting on to a fresh netns and do everything by hand with the ip command (and maybe udchpc or dhclient if you need a dhcp client, but be aware of how to write your own callback scripts for how to handle various associated events).
Now for the weird part: Redhat wrote both NM and sd-nd, and decided what servers really need is NM by default, and getting a server to actually use sd-nd is like pulling teeth on RHEL. Completely baffling.
NetworkManager can read old style sysconfig network configuration, which is still used to this very day even if Red Hat wishes you wouldn't, and you really shouldn't.
I don't know why Redhat would do that, but I've never used RHEL - I quit the redhat and derivatives in the 90's due to rpm hell, and never looked back.
A new job forced me to get intimately familiar with how fractally dysfunctional RHEL and derivatives still are, and the only thing more baffling than Redhat's self-sabotaging decision making process is why anyone would voluntarily use it.
Yes, but then NetworkManger will override Netplan sometimes but not others. There is a setting in one of the buried config files to configure this behavior, but it doesn't always work depending on how NetworkManager is feeling that day.
I'm not keen on the network config being scattered across a dozen tiny files. It makes it hard to see what's going on, or to spot a configuration error.
Here's one for you: I can't remember the exact details, but I was trying to get do something with a samba share folder via systemd unit file and the way systemd handles the escape characters used by the samba client was not compatible for windows network shares that used spaces in the name.
Because it completely violates the UNIX philosophy and mission creeps into taking over essentially every part of the system. It was shoved down the throats of every user because the major distros kowtowed to a FOSS diva with a spotty track record, creating a monoculture built on awfulness and bloat.
I appreciated it. I fucking hated all these init scripts and find it muuuuuch easier to get services running under systemd. I don't care about philosophy when it gets in my way of managing systems.
> Had it not been for the philosophy, Linux would not have been a thing
I'm not entirely sure what you mean by this, but linux (the kernel) is very much not a "do one thing and do it well" kind of program. You'd need a microkernel for that.
Hot take: the 'UNIX philosophy' is stuck in the 1970s. It was the only practical compromise when computers were constrained to kilobytes of memory (at best) and a megabyte of storage (at best).
No, the UNIX philosophy persisted since the 70s because it is great default philosophy for building software. Not all kinds of software but most, I'd say. Doing one thing well plus all the other stuff (like preferring plain text output) means that users can easily assemble whatever they need. When applications are doing only one thing, you can thoroughly test them as well and enjoy a level of security that monolithic programs have to add via sketchy hacks. And when a monolithic system is compromised, it is a bigger threat than one with smaller scope.
With modern software it's a pain in the butt. Remember CD burning software? That at least used to invoke cdrecord underneath, and whenever that went wrong it was awful, because text is an awful interface for a complex system.
Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface.
A GUI program invoking a program not designed to be a GUI in the laziest fashion is fringe example. Such a GUI would have been a herculean feat to implement if the authors could not piggyback off of an existing, simple tool. If the GUI authors really wanted, they could have tried to parse the output of cdrecord and/or contribute to making the output of cdrecord suitable for easy processing.
>Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface.
There are tradeoffs to this simplicity. Your "library" is most likely a pain in the ass to use even for people using the same language, much less other languages. The output and invocation of a simple program is less likely to add a breaking change than its code. Do you think libraries were just invented, or what?
I like the idea of making the library first and then using that to build a tool. But that may not make sense in all cases, and it's extra work as well. For people using other languages, or trying to write simple shell scripts, a library alone is not going to work.
Systemd itself is a fine idea, but its maintainers and governance are not.
They screwed up the libsystemd first by bringing tons of dependencies (including libxz), and then inventing a braindead delayed loading mechanism. That required adding custom ELF sections. It's funny that they used "macOS does this!" as an argument for the delayed loading, when in reality macOS removed that functionality about a decade ago (for being braindead).
While all they needed to do was simply split libsystemd into two libraries.
> and then inventing a braindead delayed loading mechanism. That required adding custom ELF sections.
What are you talking about???
dlopen is hardly a new "delayed loading mechanism" and having a custom ELF section where the dlopen'd libraries are listed is just a positive thing for package managers, so that it can be automatically detected during build just like used SO files (for writing the build metadata files).
> Perhaps as BPF subsumes Linux into making it a managed-runtime hybrid kernel with subsystems becoming increasingly componentized and instrumented (with early signs in the proposal to add Linux Security Module hooks to BPF programs), as pidfd/process descriptors allow for reliable supervision to be distributed across self-contained processes, as the native Linux mount API becomes more event-driven on its own, and as a generation of Rust fanatics in their undying religious zeal insist that all men are obligated to offer sacrifices to the borrow checker, a new shift may emerge where once again, the init system is made to cease mattering.
Alpine, Devuan, Gentoo and other devs have kept init choice available.