Comment by palata
1 day ago
> But there's a reason it's being adopted: it does it's job well
My problem with systemd is that it's taking over more and more and locking in. It is encouraging developers to have a hard dependency on it, and making it harder to have an alternative.
My problem is not philosophical with "it's a monolith, it's not unixy". My problem is "it's on the way to lock me in".
We like to complain about lock-in across the board. I don't see why it would be different with systemd.
I think you got it backwards. Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.
I somehow don't think your gripe is with systemd but with developers who prefer the easy route. To be honest though you get something for free. If you want it differently then you have to do it yourself.
I don't think it's backwards; it's not incompatible with what you said.
> It is just nice to know that all the tools you need for a system are there and work together.
It is indeed! Just like everybody uses WhatsApp for a reason. But because everybody uses WhatsApp, it is very difficult to get traction with an alternative. That's the lock-in part.
It is easier for developers to only care about systemd. It's often worse: many times I have seen projects that only work with Ubuntu. Of course I understand how it was easier for the developers of those projects to not learn how to "be nice" and "do it right". That does not mean I should be happy about it.
> If you want it differently then you have to do it yourself.
Or I should support alternatives, which I do. I am not saying you are not allowed to use systemd, I am just explaining why I support alternatives. Even though systemd works.
I'd argue that "do it right" and "be nice" are incredibly subjective. I'd say they were already nice enough to write open source software. And I don't think it is wrong to to write what you want to write.
The comparison with WhatsApp has a a huge flaw: WhatsApp is not LGPL licensed software. No one can really take systemd away. There is very little risk in depending on it apart from less choice. But I already argued that the expectation of choice in free software is a big ask.
And there is no one stopping anyone from implementing systemd's api surface.
The reason why I say you got it backwards is that you are against systemd making available all their tools when in reality it is the distro maintainers choice to use them and the developers choice to depend on them. Most of systemd is optional and nothing prevents developers from writing abstractions. But the simple truth is that systemd is offering a compelling value that people are just accepting.
> Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.
That's the official story, but like most official stories, it doesn't really hold up to scrutiny.
I built an entire system from scratch with over 1,500 packages installed. Everything under the sun. Works just fine with sysvinit. Completely seamless.
If KDE/Gnome can't figure out how to fit in with the overall system design the same way thousands of other packages somehow manage to do, then their services are no longer required. Good riddance to their bloated asses. I prefer to invest my CPU cycles in better software.
Init scripts for services and such are properly handled by the distro maintainer (packager), not the developer, although it's always nice to see examples he's provided to help guide the development of my preferred version.
I am honestly happy for you that you made your system the way you want it. That is a good thing and please keep doing what you are doing.
This is not relevant to the average user. The average PC user doesn't use Linux and the average Linux user uses an off the shelve distro. For these distros it is very attractive to have a bunch of core services ready that work together because they are released as one. It can be done but why the hassle? What is the upside for the maintainer apart from maybe the moral high ground?
Software projects can also benefit from standardization. They can concentrate on writing functionality instead of maintaining abstraction layers. And I believe the more mainstream distros choose the SystemD stack the more it becomes the default or at least the initial implementation for their software.
We also have to keep in mind that this kind of standardization is nothing new. Pretty much every distro depends on the GNU coreutils. Maybe not on the binaries themselves but at least on their API. That is not very different from SystemD. We have a POSIX standard.
Final word regarding sysvinit: I worked with sysvinit, upstart and systemd and having an opinionated config format for services is so much better, in my opinion. Not having to read a whole shell script to know how a service works is such an improvement and the easy overrides for units (for example distro packaged ones) is amazing.
Note: In my post I counted distro maintainers as developers.
1 reply →
It's not a lock-in as much as making a much better product.
For example, I never liked the idea of having my programs to manually daemonize, manage logs, set up permissions and all that boring, but security-critical stuff. And with systemd, I don't have to! Program reads from stdin/stdout, maybe gets socket from socket activation, and systemd does the rest.
Is it lock-in? Only because other system suck. Like, seriously, what stopped xinetd from having rudimentary volatile "on/off" control, so I could disable misbehaving service? Or why is start-stop-daemon so _stupid_, discarding all startup error messages? And don't get me started on all the different init file dialects for each system.
Maybe if the sysvinit programmers actually cared about providing nicer services to app developers, we would never end up with systemd.
The problem with the word "sysvinit" here is it's sort of a red herring. BSD init is better, in my opinion. I don't like managing all those symlinks. Plus, sysvinit is an old 90s application and its code does have some cruft built up over the years that could be removed and simplified. I'm devising a new init for my system that's much simpler than sysvinit and much closer to BSD.
"BSD init", "much simpler"... So does this mean you still expect applications to manage their own logs, daemonization and security setup themselves?
If yes, that's yet another init system not made for application writers.
3 replies →