3 ms·
Like someone already answered systemd started as init replacement "to make Linux boot faster" - that was PR pitch. But then it consumed many system services lik
by Woodi 5y ago
Like someone already answered systemd started as init replacement "to make Linux boot faster" - that was PR pitch. But then it consumed many system services like logging, time, logging in, hardware detection, network, mounting, audio, GNOME, etc etc. That alone is enough to clearly state systemd is bullshit. Everything is now interdependend and it is realy hard to replace some parts of it like eg. udev - decade old story ?
Yes, some things was improved but it could be done in sane way - making things by design replecable, as it was always in UNIX way. But systemd is intentionally
self absorbing, more - looks like it is intentionally layer above Linux. Now what we can do when one day Pottering or anyone from that IBM/Intel/MS cabal will merge Linux kernel uncompatible change ? And make Windows kernel "working flawless" - for some time of course. And with build in tracing. Or login right licensing ? :) That can be easily done today. And what plain users will tell ? "Works for me, what you talking about ??" Remember, some idiots already tried to sell plant seeds that you needed to re-buy every year. Business unchecked becoming evil.
Btw. about that "boot fast" :> Now it is dropped, of course. Also making system gooing down almoust instant is broken for years now.
My prediction is that in some time facepalm will be most common reaction when someone hears "systemD".
- kaba0 5y agoSystemd was never meant for “making init faster” - it was meant to making it correct and maintainable. That’s another added benefit that actually getting the boot dependency ordering correctly allows for parallelism beside many other benefits which will make it faster. Also, your listed “features” are bullshit: logging in, audio, GNOME, etc have absolutely nothing to do with systemd. Even logging can still be forwarded to any log tool you would like, but having it implemented inside is a sane choice — you have to start taking logs when there is not even a file system available. You know how was it solved in the pre-systemd days? It was simply ignored! System init is a very complex problem, systemd only gives you the essential complexity for the task. Also RE poweroff speed: there is a single flag you can toggle to either kill lingering processes (which is usually not enabled because some hacky tools like tmux likes to live in the background and systemd killing it is bad) or wait a bit before. So yet again, systemd does the correct thing while before these were simply killed.