hunger

I am not trying to convince you: Use whatever you want.I am trying to explain it, so that people can have a more informed discussion. The web is full of either systemd is the best since sliced bread and systems is horrible. It is neither: It is just a technical system that made technical choices that make certain things easier or even possible and others harder or even impossible.

The sytemd time thingy is actually more minimal than openntpd: It only supports sNTP and not the full NTP protocol and is a client only... Openntpd is a full NTP implementation with both client and server. It also is a great technical choice, so keep using it, especially when you need an NTP daemon.

You behemoth is my plumbing layer:-)

I like the ton of small and simple tools that systems brings along: systemd-nspawn is a really lightweight way to run containers that works basically everywhere, no need to install docker or podman. Disk resizing, sysusers, tmpfiles, boot, Key Management, homed, etc. enables me to build reliable, immutable images for my systems. There is no tooling whatsoever for this outside the systems umbrella.

If you do not try to build a 1980-style UNIX system, then you basically are stuck with systemd. Nobody else is even thinking about how to move forward. If you try to raise the challenges you see outside systemd, you get laughed at and are told that your usecase is obviously stupid. The limitations admins ran into 1980 are gospel now and you may not question any of that.

First off, there are lots of problems with systemd (mostly down in the details) and controversial defaults at times, bugs, bloat, and hickups and whatnot. Like basically in all projects all the time. So of course there is valid critique on systemd, lots of it.

But I have a problem taking any argument seriously that is based on "I am smarter than everybody else". I do not like detail Y or developer Z, so the project X sucks and everybody that disagrees is either a paid shill, forced into it or just stupid. There is no point in even talking with people like that.

Yeap, it is always the same set of poorly researched links that get pasted in threads like this.

Unix philosophy, evil corporate interests, insecure, bloated, entangled mess... it is these individuals thatbhave seen the light, notnthe silent majority that does all the work in distributions and when developing software that kind of opted withbtheir feet.

Check out the devuan mailing lists then:-)

Portability matters.

In general: Yes. In the specific case of an init system for a specific OS: Not so much.

This is nicely demonstrated by none of the non-Linux OSes embracing any of the options you listed. They all want something that plays to the strength of their specific systems over some generic Unix thing.

If using Linux specific features was the only approach to security, I wonder how OpenBSD exists.

It is the best approach we have on anything running a Linux kernel.

systemd cannot compete with their simplicity, maintainability, smaller attack surface, and the list goes on and on and on.

It is also easy to have really simple code that does nothing interesting whatsoever. And for something that does not do much at all, the fork-dance that e.g. s6 does is pretty complex.

Maintainability also does not seem to be a big issue for systemd at this point in time either.

The smaller attack surface is relative as well: systemd-the-init is a bit bigger than the ones you list. But the difference is not as big as you make it sound and an init system does not do many interesting things that can get attacked by either.

On the other hand systemd can seriously lock down any service it starts (and does so out of the box for anything from the systemd project and many upstream projects that ship locked down systemd unit files). The init systems you listed do can not do that directly and either need helpers (which increases their attack surface again) or just do not bother. Considering that a init system starts way more lines of code that do more security critical things than an init system: I think this lockdown does lead to a smaller attack surface of the system overall.

systemd de-facto causing other projects to put in (sometimes radically) more work than they should have to, is not okay;

Somebody has to invest work to make things convenient and easy to use. You either run with what everybody else uses and share the effort or you do not and do the work all by yourself.

This is in no way systemd specific.

There is no significant section. It is just a few people telling each other the same old conspiracy stories over and over again.

None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there. Thatbis a design decision eachnofnthese made.

So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features. Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.

Systemd moved the goal posts for what a Linux init system needs to do. I doubt any generic Unix init system can compete.

Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That's because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.

Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).

Or if you prefer a more negative spin: "Systemd is on huge entangled mess of interdependent binaries" :-)

SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.

No, it is not. It is always the same few people that repeat the same slogans that failed to convince anyone ten years ago. But that does not really matter: In open source the system that can captures developer mind share wins. Systemd did, nothing else came even close.

That comparison is bad on several levels:

First off, systemd-the-repo does contain way more than an init system. But yes, I am pretty sure systemd-the-init is slightly bigger than runit.

Secondly: Systemd-init does set up some useful linux kernel features for the processes it manages in an easy and consistent way. That's why other services started to depend on systemd-the-init by the way: Systemd does linux-specific things developers find so useful that they prefer adding a dependency on systemd over not having the functionality.

Runit does not support any linux kernel specific features at all to stay portable to other unixes. Other alternative inits made the same design choice.

Thirdly: The overall attack surface of the system without systemd is bigger than a typical systemd system. That's because so much code run by the init system is way more locked down as systemd provides easy ways to lock down services in a cross-distribution way. Note that the lockdown functionality is 100% linux kernel features, so it involves little code in the init itself. Users of other inits can of course add the same lockdown features as service-specific startup code into the init scripts. We saw how well that works across distributions with sysv-init...

Finally lots of security features implemented outside systemd-the-init require a systemd system as they need the lockdown features offered by the systemd-init. One example is systemd-logind: That depends on systemd-init to be secure where the pre-systemd attempts all failed to archive that goal. Logind makes sure only the user sitting at a screen/keyboard can actually interact with the device interfaces of the kernel device files managing that hardware, so no other user but you can see ehat you type and take screenshots of your screen. Contrast that to devuans approach: Add all users allowed to start the UI to a group and make the devices controllable by that group. Much simpler, KISS and the Unix way... but it also allowes all users on the system that ssh into the machine somebody sits on can log what other users can type. Apparently that is not a problem, since no system ever will have more than one user in the age of personal laptops and desktops. That seriously isvtheir answer... and they even rejected to maintain the ubuntu-before-systemd logind replacement when canonical asked them, because such functionality is not needed im Devuan.

Librewolf

Maintaining a browser is a huge endeaver. Using some random browser that is maintained by a a lone person or maybe even a handful of developers basically guarantees that the whole thing is insecure. This is especially true when keeping functionality around that was removed in the "main" browser to improve security there. One example is the old plugin system that firefox replaced with a more secure one with less hooks into the core engine, breaking some old plugins.

Stay with mainstream browsers folks and install some plugins to improve them that way. At least you get patches asap.