Slashdot Mirror

← Back to Stories (view on slashdot.org)

Busybox Deletes Systemd Support

Posted by timothy on from the changed-our-minds dept.

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.

11 of 572 comments (clear)

  1. The Commit Message by Kunedog · · Score: 5, Informative
    Found it quoted elsewhere:

    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.

    1. Re:The Commit Message by Anonymous Coward · · Score: 5, Informative

      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?

      Both.

      People have found bugs that make systemd incompatible with existing programs, and rather than fix the bugs in systemd, the systemd people responded that the people who found the bugs should work around systemd and systemd didn't need to be compatible with existing code.

      Basically systemd completely wrecks the UNIX way and makes the distros that use it absolutely unmaintainable if you're a sysadmin.

    2. Re: The Commit Message by Anonymous Coward · · Score: 5, Informative

      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, something pretty much any other init system managed to do.

      The systemd folk, by way of Red Hat basically told those using aiccu the same thing others were told: 'too bad, systemd isn't betting "fixed" because we don't see this as our problem.'

      My opinion? Systemd is useless and makes more problems than it's worth. It has its mitts in far more than any init system should. It is a blight on system administration.

    3. Re: The Commit Message by multi+io · · Score: 5, Insightful

      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.

    4. Re:The Commit Message by Cassini2 · · Score: 5, Insightful

      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.

  2. Awesome news by Anonymous Coward · · Score: 5, Interesting

    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.

  3. Re: Dropping stderr and syslog messages... by cfalcon · · Score: 5, Insightful

    > 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.

  4. Re:The message in question: by phantomfive · · Score: 5, Insightful

    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."
  5. Re: Dropping stderr and syslog messages... by TechyImmigrant · · Score: 5, Insightful

    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.
  6. The systemd way by medoc · · Score: 5, Interesting

    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....

  7. Re:The Commit Message [Citation begged for] by Bengie · · Score: 5, Insightful

    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.