After using systemd for a few years on arch linux I no longer despise it. It does have some good features like unifying system jobs and cron jobs, faster boot, journal forward secure sealing (to detect log tampering).
I don't like its effective ownership by redhat and its monolithic nature however this can be solved in the long run by forks and standardisation.
> this can be solved in the long run by forks and standardisation.
I keep hearing this refrain, but the reality of the situation right now is that Systemd (and the other processes under the same development umbrella) are moving too quickly and are too complex for any fork to ever have a realistic chance.
Does there exist a group of people outside of RedHat who understand the internals of the whole thing well enough to even chance a fork?
Gentoo uses OpenRC. It works awesome. I like not being surprised and I like avoiding conversation around systemd cause I don't see it (till I shell into a Debian)
Not so much standalone, but being able to substitute other services. Logging and service-management are two issues off the top of my head. I'd love to be able to disable those, and manage them with another service/package.
If you're hosting a bunch of apps for clients, but not all of them are being used all the time, then you can fit more onto one server by only activating them when they're used.
Used in the "olden" days to allow a single server to serve a bunch of services, not all of which are being used all of the time, to a bunch of clients, by only activating them when they are used.
It has one terrifying disadvantage. The socket is opened and appears to be owned by pid 1.
I haven't seen the code that does this, but my hope is that it is perfect in every way - if not then its an open door from the internet into my server.
Thats is indeed pretty cool, the whole question is more under the way decisions are beeing taken regardless of what the community says.
But I don't really see what this sort of feature has to do in an init process. I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu*.
But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)
"I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu...."
I've heard this argument a bunch, but looking at the actual systemd approach doesn't really convince me that it's the case. There are dozens of binaries, dozens of maintainers, hundreds of contributors. It's comparable to a project with a bunch of parts (think Gnome or KDE only at the systems-level), rather than one big black box that does everything.
If there were a single "systemd" program that did all the hundreds of things that the systemd system does, it would be alarming and impossible to maintain. But, it's not. They may be more tightly coupled than some like (I quite like systemd and still find it a little uncomfortably coupled in many places), but that's partially a symptom of doing a bunch of things in new ways. No one built the interfaces needed to do what systemd does in the past, so building systemd took reinventing the universe in some regards. That's actually some of what you're getting when you get "systemd"; things that aren't part of the init system, but existed in some form before and are now being replaced by systemd-provided services.
"But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)"
That becomes more feasible over time. Right now, there's a lot of moving parts. Another reason for the tight coupling is that the way things work together is still evolving as people learn the shortcomings of this new architecture.
systemd is not perfect, but it is a bunch of little pieces working together. A security issue in one of those pieces doesn't necessarily mean we're all fucked any more than a security issue in one part of any of the old systems necessarily meant we were all fucked.
Then why is it then being pressed into service across distros?! Why not let it churn on in its own world somewhere out of the way until it settles down and the interfaces are more defined?
Because it would never fit a real world use case, if isn't designed in and for the real world. Software built in a secret lab and trotted out to people after the fact is not the way Open Source works. We build the plane as it flies. It's always been that way in Linux.
I'm surprised there's still so much rage about systemd. It's not a bad solution to the problem. I mean, hell, just the move from procedural to declarative for service configuration is huge. The size of that improvement really cannot be overstated.
> "I'm surprised there's still so much rage about systemd. It's not a bad solution to the problem."
You can only be surprised if you've got blinders on. Systemd has some real technical superiority but also some questionable or worse technical decisions. Beyond that, it has a truly horrible community around it that has an incredible track record for being bad at justifying shaking things up and bad at easing migration pains and bad at responding to valid criticisms or accommodating use cases different from their own. A project can't trigger flamewars this reliably and be innocent in the matter. You don't see the same kind of social and organizational conflict surrounding the major Linux display stack overhauls over the past decade.
I think socket activation makes sense as part of the int process because of the 'activation' part. That's basically what you rely on init systems to do.
For more details about the advantages of this can be found here[1] and here[2].
It's an interesting feature but inetd (or xinetd) did it for a long time decoupled from the boot process.
A pro for systemd doing it is maybe consistent nomenclature for service startup, but a con is that it couples in yet another use case to systemd which may lead to a higher risk of security, maintainability problems down the line.
I'm not sure why starting services two different ways would lead to fewer security problems. Seems like a classic example of reducing surface area for attack. One way to start services means one pile of code to audit, one configuration syntax to understand (that it's new is a negative, but that it is declarative rather than procedural in the case of initscripts is a huge win; xinetd is also declarative, so systemd is converging on the known better way to configure starting services), one place to look when figuring out what is running and what is supposed to be running on your system.
There have been init bugs in the past. There have been xinetd bugs in the past (and inetd was occasionally notorious with regard to security, though it was usually the services it provided access to rather than inetd itself). There will be bugs in systemd. But, how does consolidating service startup into one project increase the risk?
Well for one, systemd hooks to a large number of functions/subsystems that used to be more isolated. Logging, udev, dbus, churn, networking functions, etc. So it's a bit of a judgement call to say it has a larger or smaller attack surface than separating the functions out. I don't know how to really quantify if in the end it ends up more risky one way or another.
I find it frustrating that systemd's socket activation API is via library calls and not a protocol. This makes it necessary for separate support in programs to support systemd rather than having a generic mechanism that all init systems might use.
`libsystemd` just provides an implementation of the socket-activation protocol. It is documented and can be implemented easily without libsystemd: after all it's in the end just reading which file descriptors to use as listening sockets from an environment variable.
I don't like its effective ownership by redhat and its monolithic nature however this can be solved in the long run by forks and standardisation.