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.
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?
> 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.
I'm not aware of the politics in this, are they saying the systemd people are rude, or that they just refuse to make their code compatible?
Also with regard to systemd, I really do like distros that have it in my virtual machines because I can do a full reboot in seconds, whereas other distros take much longer. This is just flat out awesome for reducing lost time during maintenance when something doesn't go as planned.
Is there a particular reason we can't have something like that AND comply with the "do one thing and do it well" rule? I'm not familiar enough with the low level stuff.
"logging messages just aren't important"?!
I guess you've never worked anywhere that had regulatory compliance requirements. Or ever wanted to debug something.
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.
Systemd makes server administration a lot harder - almost a nightmare. There's no way to see how stuff is related anymore, while with init you could see it with a quick glance using ls.
And if you add your own stuff it's not easier, it's darn hard.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
Your answer is problematic in the same way that the behaviour of the systemd people is problematic: you're essentially saying to the GP: you shouldn't have that problem. I get that a lot in newsgroups: I have a certain problem, I ask a newsgroup, and one of the first responses one gets is: 'you shouldn't want to do that.' No, *I* decide to do that!
Irritating doesn't even begin to describe it. So, the guy wants to reboot often. Maybe he has a very valid use case that you haven't thought of. You can't imagine every possible conceivable use case. But anyway, this is technology - we can make it work - with or without systemd.
Religion is what happens when nature strikes and groupthink goes wrong.
I understand that your life is easier, but this topic is about Busybox. Their life was made harder, just like many other people who are not satisfied with systemd. Obviously, you are a sysadmin with some own development, not a distro maker who tried to integrate 10+ applications where one of them doesn't want to cooperate with the rest.
Patents Drive Free Software as Hurricanes Drive Construction Industry
I think it is telling that poettering (note he has his hands in the design/state of systemd/dbus/pulse audio/XDG/PAM/...) when seeing a complaint that su - does not pass/or instantiate XDG under systemd came to the conclusion that su is broken and reimplemented it in systemd. The reality is that his designs for these systems disregard unix/posix and the issue in the bug report was directly related to how he designed XDG/dbus/systemd and pam -- not an issue with su.
He has also gone on record stating that he does not care about linux and unix compatibility, that he is building things that he wants to. Given that systemd is now up to 100+ bins and is wrapping everything from init to logging to virtual machine management to auth privilege tightly coupled to dbus it really sticks like most of the crappy design decisions that made windows lose in the server market. One of the core reasons unix is so powerful is that even on a full upgrade of a system you can pull out software and migrate easily and that is because there is loose coupling on all of these parts.
The latest version of MATE requires the latest upower (now dependent on systemd)
That's what you get when you use open source software. If the developer decides they want to become dependent on systemd then it's their project and they can do what they like, and you have no control over it. If you don't like it your only option is to fork.
That's not a criticism, it's just a statement of the way it is. No point getting upset about systemd and other software that now relies on it, because it's not like the developer owes you anything. That's the price of freedom - other people are free to do things you don't like.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
There was a problem involving systemd, networking, and aiccu.
The aiccu maintainer demonstrated how systemd wasn't properly making sure that networking was up before attempting to start aiccu
No they didn't demonstrate that. The relevant thread is this one, and the short version is that the aiccu author failed to understand that the network being unavailable temporarily is quite a different failure mode than, say, the configuration file having a syntax error. In the latter case, it's OK to terminate and require user intervention, whereas in the former case, if you're a long-running daemon that's supposed to keep a tunnel open, you keep running, backing off exponentially and waiting until the network becomes available again. Or at the very least, you exit with a specific exit code so that somebody can write a wrapper script that handles this particular error correctly and implements the backing-off thing in the wrapper script, and still terminates permanently for any other error condition (at which point it's fair to ask again why you wouldn't implement the exponential backoff in the daemon itself).
This whole thing is quite independent of the init system; sysvinit will expose just the same set of issues. What's broken is the daemon, not the init system.
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.
Sorry, if you need systemd to execute the kill -9 on an unresponsive java application you really shouldn't work in this field. All our java apps get a chance to shut down gracefully and get killed if the don't do it in time. That is ONE generic script dropped in any java deamons bin folder. Doesn't even need customization like the startup scripts. Btw systemd also got the job done on database shutdowns with lots of dirty pages wrecking the database. One solution doesn't fit all and that is what systemd is doing.
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.
Some people have so many problems with systemd, because it invades every part of the system and 'solves' one problem by breaking lots of other stuff. The power of unix systems was that if you run into problems you can easily fix them. Systemd makes a lot of assumptions that might or might not fit to your problem and forces them down your throat. And the instant kill of services was one of these bad decisions they had to backpaddle on. Breaking network boot by stripping search and domain from DHCP another. At least the idea to kill your current ssh connection on a system update kept being an idea.
Also tons of experience with RedHat is like tons of experience with Windows. Just because you know the limitations doesn't mean that you need to live with. them. And there is a big difference in patching a script compared to applying a patch to systemd.
Systemd needs to stop implementing feature requests without thinking them over.
Systemd needs to a let another software monitor daemon statuses, Daemon states can be much more complex than they account for and there is specialized software around that doesn't mind sending systemd the restart command.
In short systemd needs to focus.
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.
systemd does things like auto-detect all of the tty devices, and automatically associate them with login prompts when the device becomes active. This sounds good, until you hit an application where the tty device should not have a login prompt. After two days of trying to work around the issue (there is a work around), I now understand what everyone was complaining about ...
The biggest issue is that everything is wrapped in layers of configuration scripts, and this makes it is difficult to do something specific. The distros in an effort to "make everything easier" then have their own distro-specific scripts, and this makes the problems even worse.
The old way had one configuration script per activity, and this had the advantage that you only had to worry about one script.
> 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.
Indeed. And that is another reason to not have any dependencies on systemd, as you are then bound to one platform and are at the mercy of one company. Not smart.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.