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.
The real "Libtards" are the Libertarians!
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.
> No one uses syslog any longer on servers so they were correct in dropping syslog messages to discourage its use.
So correct you had to post AC because you'd be frying karma from all the no ones with mod points.
> 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.
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.
Look at where systemd originated, from someone that worked on a user-level sound daemon.
Do not look into laser with remaining eye.
Systemd does make things easier for some people and some tasks, which is why it's been adopted.
Systemd is funded by Redhat, isn't it? How does it make server administration easier?
I've had to work with a Redhat 7 server at work, and all systemd does is force me to learn new ways to do the things I've been doing for years.
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."
Then there are people like me. I started using Linux back in the '90s, just to learn it. I ended up moving to Fedora with Fedora Core 6, and made it my main OS with Fedora 9. I can't say that I was thrilled with systemd when it came along, but I realized that it wasn't going away any time soon, and learned enough to work with it. At this point, I suspect, sooner or later every mainstream Linux distro is going to end up using it so if you want to work in Linux system administration you're either going to have to know something about it or find yourself stuck in a dead-end niche job.
Good, inexpensive web hosting
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.
Then you haven't had problems trying to figure out WTF systemd is doing on a box. No logs means that it's taking hours to figure out what the problem is - and the problem can be a missing option in a config file that's needed for systemd operation where the error message is thrown away by systemd.
One fine example of catch-22 by systemd.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
but you can tail journalctl and pipe it. hint: journalctl -f
here's a helpful site that gives lots of examples on the power of journalctl. https://www.loggly.com/ultimat...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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
It's the trigger for your watchdog service. If it sees anything on stderr, it restarts the application.
Except warning messages are also emitted on stderr, not just abend-worthy messages. If you did this by default to every daemon, your system would completely shit itself.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
It's only by looking at them one at a time and drawing the relations in some external tool that I can figure out how they are related.
It's like going back to stone and chisel to do filing.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
No advantage as far as I can see compared to syslog and the ordinary text tools. Just a way to force the use of binary file processing tools and as soon as something pukes in the binary file it may be completely unreadable. A text file might not look good after a puke but it's still mostly readable.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Except Linux is the number one OS used in cloud services where servers get spun up and torn down like processes on a single machine. This is why a 5 second boot is important, rather than a 5 minute one.
Wannabe nerd.
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.
Having a file residing in plain text vs having plain text piped to another program is a pretty significant difference. You can't seek around piped input, unless you cache it memory -- which could be resource-consuming. (And maybe your tool for reading piped input is broken because of shared library problems). Being able to read a resting file in plain text is very important in recovery situations.
As far as failure cases the people pushing systemd the most strongly are the people who run the most sophisticated date centers and cloud OS installations that run the internet.
I don't think that's true lol.....you are the only person in that category I've ever seen who favored systemd. And from what I gathered discussing it with you previously, you only like it because of features you hope will eventually make it into systemd (features which I think will never make it, but that's predicting the future so who knows).
"First they came for the slanderers and i said nothing."
> the people pushing systemd the most strongly are the people who run the most sophisticated date centers
This kind of dismissive attitude is a classic example of the systemd problem. It's fanboys just baselessly assume that anyone who's not on board is "just an amateur". Both parts of that are quite wrongful. That includes the assumption about the experience of critics AND the idea that the "amateurs" don't matter.
If Redhat wants to build "pretentious cloud Linux" they should just do that and leave the rest of Linux alone.
A Pirate and a Puritan look the same on a balance sheet.
Linux is controlled by money because its authors have been hired by commercial companies who control their employees. Red Hat management forbids to create competitive solutions, I speculate because Red Hat is partially owned by proprietary IT companties in a risk of FOSS competition.
systemd was created for containers. Containers are a quick&dirty way of packaging. Containers again come from the evil business side of Linux, no sane person would make that debugging nightmare happen.
RedHat was backing Upstart, a Canonical project. Systemd was started by RedHat developers working without the direction of management, it was forces external to RedHat who actually got RedHat on board with Systemd.
I did an Internship with RedHat years ago, I don't know how they compare to other open source companies but in my experience they give their developers a remarkable amount of autonomy.
I stole this Sig
"And for people who want to read through log files without having to become regex experts." ??? So people who just scan the entire text file and do a search in their viewer program could only do so with systemd? And here's me thinking that even vi allows a simple search on /var/log/message ...
So I don't want to manually search a text file and your answer is that I should use another tool to manually search a text file? An editor no less reading a continuously changing file?
Seriously someone who doesn't know how to use tail -F or cat and grep should NOT be admining a Unix based system.
Or I could just open a file in gedit.
You are demonstrating the biggest advantage and the biggest downsides to Linux at the same time. The rich and widely available different ways to administer the system, and the self important douchbags in the community who believe their way is the one true way (tm).
You're wrong on this one. If you need a graphical tool to administer your system, you clearly are not meant for sysadmin work.
Most of the time, graphical tools like gedit aren't even usable (like on a constantly changing file) or available.
Boot faster? bullshit, the majority of embedded systems have one core, systemd would help nothing.
All my machines suddenly were taking exactly 90 seconds to boot, guess what systemd was part of an update. Removed systemd boot time is 2 fucking seconds.
systemd folks and redhat are just brain dead.