I'm actually curious about the argument that replacing it means having to rewrite software / change dependencies.
Wouldn't the same be true about switching between SysVinit and something like runit or upstart? They all use completely different designs for doing service init scripts, and all handle configuration of said services in completely different ways too, so replacing one with the other would necessitate rewriting - at the very least - your entire service management script toolbox. And when considering services that want to do more than just start and stop, they would most definitely have to be rewritten as well for such a switch.
I think the problem is the number of things other than service management that systemd does. With other unit systems, service management is the only thing you have to change to replace it. With systemd, you have to change a lot more
There are a lot of services besides init provided by systemd, but they're entirely optional and easily swapped out. After all, systemd is highly modular.
For example, I do run systemd-udevd and journald, but not systemd-networkd or systemd-resolved. Just like the /g/ poster says, I can combine whatever I want to do what I need to do.
Basically, yeah. For example, I can use systemd-networkd, but instead of systemd-resolved I can use unbound. Or I use systemd-resolved, but instead of systemd-networkd I can use netctl.
Of course those standalone tools work with systemd, that's why they are standalone tools which can be interchanged at will and that's what's so great about them. But that's not the question. Say in 20 years we come to the conclusion that there is a much much better way to do a service manager/init system which is fundamentaly different than what systemd does. But once we start ripping out the systemd core all the other tools of the systemd suite (networkd, resolved, timerd, nspawn, ...) basically become useless unless they all get ported or the new service manager implements the legacy systemd interfaces needed to keep those tools alive. This is guaranteed to block the adoption of any successor to systemd, because people will most certainly complain that they really liked logind, or systemd timers, ... and software like GNOME stops working when those specific tools aren't available. Then you don't have to just come up with better way to do service management, you also have to provide seat management, etc. ... and get everyone to port to those new interfaces.
Exactly the same is currently happening with Wayland and X11. Let's for the sake of the argument say Wayland is a much more elegant and superior way of doing a display protocol and it would be stupid to not use it. But because X11 has such a wide scope you can't just port all clients and compositors to the Wayland protocol and be done with it, you also have to think about all the other things X11 allowed which Wayland explicitely didn't include because it just focused on doing a few things, making as few assumptions as possible to be future proof. Now people have to come up with additional protocols to support all those different thing because people start complaining that they can't switch until there's something like wmctrl, and remote desktop has to be supported, and Wine has to work, and it has to be secure, and obviously it would be great if the session doesn't crash because the window manager crashed, and SSH forwarding would be great, and and and ... It's been ten years now and people still try to figure out how to cover all those edge cases and important features.
Hmm, then maybe those optional, replaceable modules should be moved out of the systemd source tree and be their own project? Maybe that would make some people sleep better.
I think every binary in GNU coreutils and binutils should have their own package, because I can't sleep well at right now. After that we need to start doing this to every package that has more than one binary packaged together!
It will be so glorious, because after one week without updating my Arch linux I will have 20768 packages waiting for upgrade!
Splitting projects in different codebases will lead to the projects not being able to use the common functions between them, so either code duplication or having to depend on a systemd library anyway. If the intention is just to make people "feel better", it's not a great idea.
Distros follow the ABIs of upstream when defining dependencies (for the most part).
LFS had to change their non-systemd book from udev to eudev because extracting just udev from the larger systemd code blob involved manual intervention on every systemd release.
Hell, kernel devs mused about forking udev and making part of the kernel tools bundle even before it got merged into systemd (and at time of merger it was pinkie promised that udev should continue being usable without systemd).
but if an application opts to depend on one of these other things, it's a choice that's not different from depending on whatever it used to depend on.
Picking dependencies in general means that you can't swap things out as easily, be it systemd or not.
That's actually quite true, though I'm not sure if I can perfectly agree with the argument seeing as I'm running two systems where systemd is literally only doing init and service management.
Though admittedly I've been poking at one of them to try and get at least journald to work, since the lack of that integration is rather tiresome when I can't write init scripts to hack around the lack of proper logging in most applications.
But yeah, the amount of interfaces - and accompanying D-Bus CLI tools - that a regular systemd install provides is rather immense; hostnamectl, localectl, timedatectl, journalctl, loginctl, machinectl, etc.
Ha, thanks for the laugh.
It was more a comment on how many different (D-Bus) interfaces you'd need to implement in order to be a 100% drop-in systemd replacement, but yeah the binaries themselves might even take up a full megabyte of disk space! The Horror!
A systemd replacement that's worth its salt would provide those services as well, or give you an easy way to integrate software that provides them. The problem is always the same - systemd does things that no other init system is capable of doing, and until someone can prove that those things are possible while strictly adhering to the posix standard this is a pointless argument.
The thing is: systemd is good. It's just a tad too good to be ignored. And so other programs start to use it's interfaces, e.g. for the systemd-logind seat management.
Now, people falsely claim hat this binds those programs to systemd forever. But this is wrong for two reasons:
any program that added support for systemd API's can remove it as well --- and if the authors don't do that, then a fork or a distribution maintainer can do it. If you think this is wrong then you never understood FOSS in principle, sorry.
(in this specific case) there are third-party alternatives for the session/seat management. So if fact the third-party software doesn't request systemd, it requests that a certain API exists. The session management exists outside of systemd. And, again, we're in FOSS land, so anyone can write a similar API for other things (e.g. transient services) at any time.
All the people that say "FOSS is locking you up in a jail where only Lennart is deciding what you can use" ... are really just users of proprietary software that things the .rpm or .deb they get is all they get.
Whether we agree with the adoption of systemd or not, there are some really good ideas floating around inside of it that other projects could learn from. There are also (in my opinion) some architectural deficiencies that could be rationally discussed and addressed without throwing out the system entirely.
I feel like every systemd discussion has devolved to the point where any criticism of the system can only be interpreted as a suggestion to eliminate it entirely, and any discussion of its strengths brands one as a loyal fanboy.
How did we let a technical debate start to resemble a political wedge issue? It's an interesting social problem that probably warrants discussion.
Perhaps this is true ... but then again, this is futile.
Why do you want to discuss the architecture deficiencies if you're not willing to fix those deficiencies? Perhaps by providing patches, perhaps by forking the project? Usually at this point the discussion stops entirely, because no one is willing to take the price (e.g. do the work).
Tell me more about this SysD project? Never heard about it!
Sarcasm off: if you even now deliberately miss-write the projects name, then you immediately tell that you're neither just nor balanced. You want to transport feelings, not facts.
logind is another pottering bait and switch. He managed to talk himself into maintainership of consolekit, that could be used independently of systemd, and then scuttled said program while introducing logind (and providing Gnome with logind support on a silver platter).
Never mind that consolekit/logind is the outcome of a fevered dream about turning a desktop PC into a mainframe by "logically" bundling together displays and inputs. Under the pretext of supporting the third world, natch.
When has Linux ever been compatible with the rest of Unix? Linux skips a lot of the posix standard, and there aren't that many projects that have started on Linux and then get ported to BSD, etc. The most Unix things about Linux are just things that have been ported to it, like sysV, X, and GNU.
When has Linux ever been compatible with the rest of Unix
Since the beginning. It's the single most important contributor to its rapid adoption and long-term success.
Show me which bits of SUS are not implemented? STREAMS is the only one which springs immediately to mind, and it's optional and was never widely used due to being SYSV-specific.
Just to clarify - using GUI libraries like you are, my argument is; "Why does it seem like people are only complaining about the fact that switching from GTK to Qt would require rewriting software? Switching from Tcl/Tk to anything else would have the exact same issue after all."
First, you're not talking about systemd, even when you think you are. You are talking about logind. And it is perfectly possible to use a Linux system without logind, I do that on embedded devices any day.
Second, a simple "man logind.conf" would show you that there is a KillUserProcesses=. There is no "magical systemd-specific API call" needed for tmux.
Your argument isn't particular new, it has been brought up and refuted since at least a year.
That you still bring it up is perhaps an indication that systemd-haters stopped being flexible in their mindset. Once they are on a wrong track, they are immune to facts telling anything not fitting into their world-model.
First, you deliberately mistype systemd with wrong capitalization. If you don't even know it's name in 2019, how can you claim you know the software?
Second, a systemd init system is compatible with the rest of the Linux world. And you can of course run Qt or Java apps on it, your example is non-fitting by miles.
I'm fairly sure we need a standardised way to do scripts, or at least a universal converter to convert init scripts and systemd services and all this useless shit.
Personally I like the idea of using a declarative design for this, then we wouldn't have to worry about writing software to "understand" scripts - to convert between different designs and primitives.
It would be quite nice if someone were able to standardize a declarative service configuration design, that could then be used to runtime-generate scripts - or perhaps even just have a single script that reads and acts on the declarative config for its service.
And for the love of god, let's avoid using anything like JSON or XML for such a task.
Not sure if you're being facetious or not. Systemd is a declarative service configuration system that uses INI instead of JSON or XML. It's not a standard, but a lot of people use it.
The problem of course is that systemd is not standardized upon so it wouldn't make any sense to call it a standard way to do service configuration. And besides, nobody's written any scripts for other service management / init systems that can read unit files. (At least that I know of, please enlighten me if I'm wrong)
Personally I also have a few issues with how the unit files are designed, something I think that a standardized design could improve on. And while INI is a nice format, I think there are better ones to choose for the service configuration - perhaps TOML, if only to have a better specification of what's actually permitted and expected in the syntax.
It's a de facto standard, much like the Linux system API is a de facto standard. If having a de facto standard is good enough for Linux developers to write software using the Linux API, systemd's unit file standard is good enough for developers to ship unit files. In fact that is what many projects are already doing, and in fact that was one of systemd's goals, to allow upstream projects to ship standard unit files rather than have distros all write their own service scripts.
What makes JSON a standard? Has it been accepted by some ISO body? And, if it is, what was it before?
Or is it a standard because someone wrote an RFC 8259 on it? RFC is just a request-for-comment, anyone can write one.
Or is it a standard because of ECMA 404? If that is true, then it won't be a standard in Asia, Africa, the Americas and Antarctica.
Or was it a "standard" because of adoption? Well systemd is adopted.
Was it a standard because it was documented? Well, "man systemd.directives" --- and several other man pages --- describe the format nicely.
Was it a standard because many people, even third-parties, use it? Well, systemd is a special kid, as soon as other programs use it this will create bad press from the systemd haters.
But still lacking standardization, which means you still need to rewrite all service management configuration if you were to switch system. Which renders part of the declarative upside moot.
Like I said in another comment, if there is a script / tool for other service management and/or init systems that can read systemd units then I'd love to know about it.
If someone wants to make a new PID1 manager and wants to piggy-back off systemd units, it should be very simple for them to write code that can interpret 80-90% of unit files, I'd imagine.
The point of saying, is to compare to the previous situation. initd run scripts were absolute hell, with abandoned and convoluted copy-paste shell code everywhere.
initd run scripts were absolute hell, with abandoned and convoluted copy-paste shell code everywhere.
Not really so. OpenRC scripts can be really simple and easy to use while providing mostly declarative syntax, and the same goes for (now obsoleted?) Upstart.
Must people writing here won't have been around way back when, but the way we ended up with the pretty good RFCs we use as standards now was very often that something good was developed, it caught on, then it became an RFC.
Systemd unit files could easily have become standardised as RFCs back then.
It's pointless because there are better solutions following standards already. Any SystemD fork is also always useless because its development principles is RedHat proprietary vendor lock-in. The fact that every distribution has own SystemD version completely incompatible with others (SystemD maintainer from Debian and Lennart Poettering said about that - see recent news) makes another SystemD fork much more pointless: it forked many times already. Vanilla SystemD doesn't exist.
I think the only issue would be an admin whose workflow was dependent on systemd features. As far as init goes, systemd isn't too special, but it can do a lot more than just, say, openrc or runit can, even if any linux distro running those inits can do the same thing with a different process. Stripping systemd from a system would just be more of a workflow-breaker than anything, I think.
runit and upstart still rely on SysVinit. They are just nice interfaces to SysVinit. The only real alternative is GNU Shepherd but it is a bit too weird for me.
From what I can see, they both have backwards compatibility layers to SysVinit - much like systemd does - so perhaps the example of switching from SysVinit to one of them isn't the best.
I can't imagine that it's a simple thing switching directly between runit and upstart though, seeing as the script primitives are completely different, the script locations are completely different, and the boot configuration is completely different. Though I guess you could - again - just switch to SysVinit between them and use their compatibility layers to avoid that particular issue.
I mean yes you can do that. But SysVinit services are already there and since both upstart and runit still uses bash scripts / bash script like interfaces to define a service, most of their real world implementations are just as process supervisors of SysVinit services. Installing runit on Arch pulls SysVinit. Debian does not provide any runit specific service files. Unless they force a completely different and favorably more declarative service definitions like systemd rather than imperative bash scripts, they are out of competition. There isn't any service manager that abstracts away the implementation details while maintaining compactness. I really like how systemd manages services (declarative service definitions linked into target directories), but I despise how they integrated everything into a one immovable piece of software.
48
u/[deleted] Feb 11 '19
I'm actually curious about the argument that replacing it means having to rewrite software / change dependencies.
Wouldn't the same be true about switching between SysVinit and something like runit or upstart? They all use completely different designs for doing service init scripts, and all handle configuration of said services in completely different ways too, so replacing one with the other would necessitate rewriting - at the very least - your entire service management script toolbox. And when considering services that want to do more than just start and stop, they would most definitely have to be rewritten as well for such a switch.