Slashdot Mirror
Busybox Deletes Systemd Support
ewhac writes: On 22 October, in a very terse commit message, Busybox removed its support for the controversial 'systemd' system management framework. The commit was made by Denys Vlasenko, and passed unremarked on the Busybox mailing lists. Judging from the diffs, system log integration is the most obvious consequence of the change.
Great work BusyBox!
Now if some of the desktop distros would listen to their core base and drop systemd as the default things would really be looking up for 2015 and next year.
That's not to say some of the ideas in systemd are entirely without merit. But the execution is entirely and utterly wrong. Maybe not for a version of Windows, but totally wrong for UNIX.
If given a choice, the user base stays with what works and quick adopts the better available alternatives. When forced they will look for the quickest out, seeing those that try coercion as a form of damage that must be rooted around.
The best thing to come from this is that the systemd crew have pulled much their code under one umbrella making it much easier to see which bits to replace. Now if they can try a little harder and embrace avahi and pulseaudio in the same way.
Unmaintainable? Really? That is a bit over the top.
So far, systemd has made my life easier. The company I work for has written custom daemons. I'm expected to get the software deployed into AWS. It is very easy to whip up a systemd script to manage the software no matter what quirks the software has about running as a daemon. I have also noticed that systemd does a much better job making sure daemons get shutdown. Java programs seemed to be the worst when it came to shutting them down. Systemd gets the job done. Some programs are not the best written daemons, but systemd seems to wrangle them in.
I keep seeing message about systemd causes strange crashes. So far I haven't experienced this. I've been upgrading a personal desktop system since Fedora Core 9. There was a difficult upgrade around Fedora 15 or so (first systemd). But I was able to get the system back into shape.
So why do some people have so many problems with systemd? I dunno. Maybe I just have a ton of experience with RedHat. I started with RedHat 3.0.3. Before that I ran Slackware. That, and maybe I just like to learn. I'm not put off by a glitch here and there. I want to learn why and how something broke. But, again, systemd hasn't broke on me.
I will just say that there are plenty of times that questions are put on forums/lists/irc/whatever where the question itself shows a fundamental lack of understanding or poor design. If you are asking how to enable root auth on your ftpd whatever sounds like a really bad idea you will be called out on it. Maybe you actually do have a good reason to do something -- most of the time the person asking the question that exposes these designs does not understand how bad they are. Take the feedback for what it is and choose not to ask for it when you get it (for free).
The position was not stated that he should not do that. It was asked why he rebooting often enough for the startup time of his services to be even an extremely small percentage of 1% of the overall run time of the system. There was no answer to the question. The question is valid -- systemd (or init for that matter) is a very small portion of actual start/stop time on most all systems.
Even the comment in the threat talking about boot time being the latency for bringing services online in cloud is kind of silly in so far as init on unoptimized systems takes 30 seconds or so unless you have very heavy procs starting. Optimized it is much lower and if you do have those heavy procs starting systemd is not more than 30-40 seconds faster. If you are spinning up a server in a cloud environment you are usually doing so for more than an hour at a time and this is a small portion of the overall run time. If you are running thousands of instances, then this time will be costly for either solution and should be optimized down. If you are running thousands of instances for an average run time of less than an hour you best cost benefit will not be managing 10 seconds off of startup time but managing matching the charge window of the instance to the shutdown so that you are not paying for 1 hour of minimal run time for running an instance for 5 minutes.
I doubt if everyone who jumped aboard the systemd cargo ship really knew the journey they were in for. Some of those travelers started to regret their ticket purchase when sudo was eaten up by systemd. And others... well it will take a bit longer to realize their fate.
Just an anecdote: during a recent upgrade from Debian Wheezy to Jessie, the first boot into the new system failed with a message from systemd about mtab not being a link into /proc/something (a trivial problem as far as I can see).
Can't remember the exact message from systemd, but it was something about being "frozen"
No going into single user, nothing, just F... you and go reboot on the CD image. Happy enough that the machine was on my desk...
And they wonder why many people don't like systemd....