Ugh - getting ugly.

I think the issue here is clearly a question of benefits vs costs. Sure, systemd will shave 5 (or even 10) seconds off my boot time. But at what cost ? - changing 30 or 40 startup scripts that have had the benefit of 10-15 years to mature and become rock-solid.

No thank-you. I'd rather see more effort going into things that actually benefit me, like getting LibreOffice into Slackware, or making the multimedia experience better, or the networking more reliable.

And the Linux kernel is NOT superior to all other kernels out there. You go ask the realtime folk, or the Solaris folk and I'm sure they'll disagree. Hell - even BeOS was giving a better multimedia experience 10 years back.

3 members found this post helpful.

If you had read the link I posted you'd know that the boot speed is merely a side benefit compared to the many advantages systemd provides. Systemd is not just a replacement for init it does many other things. The startup scripts won't need 10 to 15 years to mature simply because there's no such thing as startup scripts in systemd. It's simple, short, consistent config files and there's nothing to develop because as mentioned by someone in this thread, it already works on slackware as we are speaking.

That would certainly be nice as well.

It's superior in the sense that it provides the best hardware support - by far - after Windows. That's a hard, indisputable fact. Haiku is a very cool OS. But I couldn't use it right now because it doesn't or only has limited support for most of my hardware.

From a desktop distribution perspective, systemd has a lot of advantages and it's totally justified - a new, redesigned init system is NEEDED. First of all, in a modern Linux boot process, a very little amount of things have to be started, due to the fact that many services and daemons are handled on-the-fly by DBus. That leads to people overestimating the complexity of the boot process - you need no more than 5 daemons.
Second of all, systemd handles internally a lot of things that are just UGLY if handled by shell scripts.
Just read this: http://0pointer.de/blog/projects/systemd.html
And from an administrator's point of view, handling services is easier with systemd.

The "don't touch the 15-year-old rock-solid boot scripts" argument is invalid: it's not rocket science to redesign the boot process and still end up with a solid one. It's just not that complex!

2 members found this post helpful.

I have read the link - but the point here is whether Slackware needs systemd any time soon. Generally speaking Slackware works well for me and I don't pine for any of the things the article claims for. Maybe I'm like the pig who's happy to wallow in the garbage, but at least, like the pig, I'm happy. If the pen were cleaned, the pig would be unhappy. :-)

Those people whose hobby is system administration have some regard for users of legacy systems, unlike the attitude demonstrated here (from http://0pointer.de/blog/projects/systemd.html), which also fails to convince of a commitment to "more coherence and simplicity".
As the developer of sytemd also notes (again from http://0pointer.de/blog/projects/systemd.html)
The "fast to hack" is actually the key for me. Boot time execution is not the holy grail for me, but rather control of the final operating system environment.

Bottom line, if it ain't broke then don't fix it.

6 members found this post helpful.

Actually, instead of putting as much thought into my answer as I did, I should really have said the first thing that came to my mind after reading about the dozens (and dozens) of systems that systemd plays with - "What could possibly go wrong !"

3 members found this post helpful.

I guess the issue basically boils down to this :

* If slackware wants to be relevant on the desktop it needs to switch one day or another to systemd.

* If slackware just aims to be a BSD with better hardware support but without consistency (which means it aims to be relevant only on the server side of things) than sysvinit is good enough.

Anyway. I can foresee that after a while Slackware will be forced to get rid of sysvinit anyway because it will inevitably bitrot. And so slackware will probably end up switching to initng or something of the kind.

I guess you missed the part about systemd's modularity through the mecanism of socket activation.

No, it just means that you won't run it on your desktop.

And I guess that you missed the part about "don't fix things that aren't broken".

1 members found this post helpful.

Wanna bet ?


Sysvinit is broken by design. It can't keep track of daemons that have multiple processes. It relies on hacks such as pid files. It's a pile of shell scripty kludges that were invented ad hoc to get around it's inherent limitations. Systemd can do that better and properly. And much more...

1 members found this post helpful.

I foresee that this will follow the LILO vs GRUB debate. There will be adopters of systemd and, if a substantial satisfied user base develops that can be accommodated without warping Slackware too much, then systemd may well appear in /extra. Slackware is about choice.

7 members found this post helpful.

Very well said!

I hardly think this is going to happen with systemd. For the moment, there is no single similar standard to unify Linux start-up and configuration except systemd. There are many init systems, but they do only that - init. Systemd is planned to do much more and to give you an universal API to configure the system. For that reason, GNOME plans to use it. Also, all big distributions plan to use it. With so many big players agreeing on using systemd, I hardly think there is going to be an alternative developed.

I don't need that, I'm fine with my configuration text files and I find nosey for my daily job any layer over those, but this is a personal consideration.
what we have now counts?

Startup and configuration. Can it wash my socks, too?

That's not the Unix way of doing things.

3 members found this post helpful.

Do you have any other pavlovian sophisms in store ?

0 members found this post helpful.