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.
remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
With the major distros all moving to systemd, it's nice to see someone burn that bridge. I think if at least one top level distro was anti-systemd, then the drama would all go away, because the group that distrusts systemd could just go there. Someone quick spend your life forking fedora to a non-systemd thing. Pls?
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 you're depending on stderr for troubleshooting, you're doing it wrong.
And so many people are doing it wrong that you need to post AC or have your account go negative karma from all of us wrongbies.
Or maybe a nonmodular approach to something that was well documented and understood, that got glommed into every distro of note, has backlash. Maybe that.
No. Being able to use less, grep, egrep, awk, cut, etc. is very important.
Systemd is funded by Redhat, isn't it?
Mostly, yes.
How does it make server administration easier?
I've never heard a server administrator say systemd makes things easier for them. There are probably some server administrators somewhere who will claim that.
Systemd makes things easier for people who write init scripts. Init script writers are the people who have primarily been responsible for its adoption in various distros.
"First they came for the slanderers and i said nothing."
System boot time is only important if the system is booting frequently.
And pretty much irrelevant when my servers take about five minutes to get out of the BIOS and start running the operating system.
If you're depending on stderr for troubleshooting, you're doing it wrong.
What's your better idea?
What do you thing stderr is for?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
journalctl "pipe" [current tool of your choice]
configure system to forward all logs to syslog or rsyslog for the status quo
Journalctl is well worth getting to know http://www.freedesktop.org/sof...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
The decision to drop stderr has made my life hell. I wish systemd guys understood how important it is to those of us that run servers.
Maybe I'm missing the point here, but there has not been any "decision to drop stderr". It's clearly possible to set where it should go:
StandardError=
Controls where file descriptor 2 (STDERR) of the executed processes is connected to. The available options are identical to those of StandardOutput=, with one exception: if set to inherit the file descriptor used for standard output is duplicated for standard error. This setting defaults to the value set with DefaultStandardError= in systemd-system.conf(5), which defaults to inherit.
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.
Oh, a framework.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
ffs, init was 20k LOC systemd is now 100+ bins and 430k LOC. Before systemd you had a log file that was text and parsable using the commands that are core to unix (or specialized applications/services to injest them later), after systemd you have a binary log that mind you has code controlling it that can choose to destroy that log if it finds it is unreadable or corrupted. Init was special purpose and streamlined to do one task well, systemd is coupled to auth, dbus, vm startup and shutdown, vm management, privilege escalation, ....
No one is complaining about the features of systemd, everyone is complaining about the design of those features that is reminiscent of MS architecture and design (that even MS has started to run away from). Poettering has stood in front of rooms full of people and flatly said he does not care about posix or unix he wants to build something new. He is -- hes building a monolithic userspace kernel and RH is using the init functionality to shoehorn itself into a controlling position.
Because of the way systemd/XDG/pam/dbus are designed, the more he extends it the more other core bins on the system will need to integrate with it or rebuild functionality that has been displaced by it for no reason. It is a loss lead development and it will me Linux's loss in the long term.
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....
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have. Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development? These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.