Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Open Source IT

Busybox Deletes Systemd Support 572

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.
This discussion has been archived. No new comments can be posted.

Busybox Deletes Systemd Support

Comments Filter:
  • by whoever57 ( 658626 ) on Saturday October 31, 2015 @10:26PM (#50840499) Journal
    It looks like more than just systemd support was deleted:

    No repositories found

    • The Commit Message (Score:5, Informative)

      by Kunedog ( 1033226 ) on Saturday October 31, 2015 @10:32PM (#50840533)
      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.

      • by ArmoredDragon ( 3450605 ) on Saturday October 31, 2015 @11:31PM (#50840731)

        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.

        • by Anonymous Coward on Saturday October 31, 2015 @11:42PM (#50840763)

          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.

          • Re: (Score:2, Interesting)

            by thule ( 9041 )
            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 j
            • by Anonymous Coward on Sunday November 01, 2015 @02:07AM (#50841079)

              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.

              • by multi io ( 640409 ) <olaf.klischat@googlemail.com> on Sunday November 01, 2015 @07:41AM (#50841809)

                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 [redhat.com], 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.

            • by someone1234 ( 830754 ) on Sunday November 01, 2015 @03:06AM (#50841189)

              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.

            • by Anonymous Coward on Sunday November 01, 2015 @04:22AM (#50841355)

              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.

            • by Cassini2 ( 956052 ) on Sunday November 01, 2015 @10:25AM (#50842387)

              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.

          • by Antique Geekmeister ( 740220 ) on Sunday November 01, 2015 @07:34AM (#50841795)

            > Both.

            It's not all the systtemd people. But the problem starts right with the technical leadership, Leonart Pottering. systemd is attempting to do _too many_ things. Daemon management, _and_ logging, _and_ network management, _and_ automounting, _and_ privilege management, _and_ Leonart has stated that the gola is a "stateless Linux" where no system specific configurations are stored in "/etc": they're all migrated to systemd configuration tools.

            The result is not only much too large, it's not cross-platform, because systemd _cannot_ run anywhere but Linux due to the kernel changes required. It thus creates a Linux lock-in, breaking broad availability and usability of services oriiginally compiled for Linux.

        • by TWX ( 665546 )
          Why are you having to reboot so often?

          Wouldn't the best approach be to use the kernel firewalling capabilities to block everything that isn't needed for the function of the daemons running on the box, including configuring the box for out-of-band management, so that the only thing that can be touched from the user-side is the particular set of daemons necessary for its function? That would allow you to update that particular application without having to restart the computer every time, and would ensure
        • by SlashdotOgre ( 739181 ) on Saturday October 31, 2015 @11:48PM (#50840787) Journal

          Systemd has taken an all or nothing approach for its components, and it has enveloped several significant components such as udev/upower/udisks. What this means in practice is you either have to take all of systemd (i.e. replace your init system, syslog, etc.) to use any of the components it has absorbed or you need to fork and maintain what you need yourself.

          Here's a personal example: I use Gentoo an MATE as a desktop which in turn uses upower for suspend & hibernate. The latest version of MATE requires the latest upower (now dependent on systemd) to support those functions. So now if I upgrade MATE, I have to either replace my init system (OpenRC) with systemd or not have those upower features on my laptop.

          Forcing their users(or distros) hand like that is not playing well with other software and I applaud Busybox for standing up.

          • by AmiMoJo ( 196126 ) on Sunday November 01, 2015 @05:23AM (#50841495) Homepage Journal

            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.

            • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Sunday November 01, 2015 @05:48AM (#50841533) Homepage Journal

              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.

              As opposed to what you get when you use closed source software. If the developer decides they want to become dependent on systemd (or whatever) 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 go fuck yourself, because you don't get the source. You're going to have to move to a competing project, if you can even manage that because that closed-source program is actually standards-based (often it is not) and you're not locked in.

              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.

              The developer of a closed piece of software doesn't owe you anything, either. You paid for a piece of software, and aside from being fit for the stated purpose, they don't have to do anything for you. If they make architectural changes with which you disagree, you simply have no recourse, unlike OSS, where at least a fork is possible.

              OSS is clearly superior to closed software in this regard. There's not even a counterargument to be made.

          • by thegarbz ( 1787294 ) on Sunday November 01, 2015 @06:47AM (#50841701)

            The logical follow up question is why does upower depend on systemd?

            The team decided they didn't want to duplicate support for suspend/hibernate when there's already a tool which does so. At the same time they released a solution for those people without systemd:

            UPower discontinued hibernate and suspend support in favor of systemd.
            Because of this, we have created a compability package at
            sys-power/upower-pm-utils which will give you the old UPower with
            sys-power/pm-utils support back.
            Some desktops have integrated the sys-power/pm-utils support directly
            to their code, like Xfce, and as a result, they work also with the new
            UPower as expected.

            All non-systemd users are recommended to choose between:
            # emerge --oneshot --noreplace 'sys-power/upower-pm-utils'
            or
            # emerge --oneshot --noreplace '>=sys-power/upower-0.99.0'
            However, all systemd users are recommended to stay with sys-power/upower.

            So what exactly is the problem? Why exactly is systemd so evil because someone else doesn't want to maintain a certain effort they are doing and instead hand off to another package, while even providing a compatibility option for the anti-systemd crowd?

        • I have never seen this quick reboot option people keep talking about.

          I run Debian Sid ( yes I know that maybe the problem) and since SystemD was installed, my bi-monthly reboots are slow in the order of 2 to 5 minutes.

          What is happening is that systemd is not turning the network on correctly, and it waiting forever to mount the NFS shares. When it finally gives up, I just open up a terminal, ifdown eth0, then ifup eth0 and all is well. I guess systemd can't handle a static IP on a desktop.
        • by arglebargle_xiv ( 2212710 ) on Sunday November 01, 2015 @01:25AM (#50840989)

          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?

          They indent using four spaces, and also apply this indentation to the braces at the start of a function. Spaces! Four of them! Not tabs, spaces! And they indent their braces!

          Removal from Busybox is too good for them, they should be exiled from the planet!

        • Oh boy your reboot takes 10 seconds less. Ever boot big hardware? That shit can take 10 minutes alone.

      • Here's something interesting:
        the person who commit that patch to remove systemd was also the first person to merge a systemd patch [busybox.net] into BusyBox.
        • The person who committed the patch to remove systemd seems like one of the more chill and reasonable people in the open source community. He recognizes that systemd has strengths and weaknesses, and asks for a calm analysis [busybox.net]:

          It does not help in discussions if you throw around inaccurate disparaging comments about things you criticize.

          What exactly is "good engineering"? I bet finding a consensus on that one won't be easy. So, while you and me feel that systemd isn't well engineered, there will be people (its authors, for one) who honestly believe it is.

          If you will talk to people about it, you need to carefully, with well-thought-out arguments, explain *why exactly* it is badly engineered.

      • The Systemd project has eaten quite a bit of the userspace plumbing (udev and consolekit->logind) for which upstream support is no longer systemd independent. They are also pushing to control future iterations of dbus. To truly be free of systemd, maintainers will have to fork and maintain these modules or otherwise provide equivalent functionality. My guess is that few are willing or able to commit the necessary resources at the present time.

        • FreeBSD has not chosen to incorporate Systemd and is doing just fine, thankyaverymuch. They also have more than enough resources to keep it in the shape they'd like it.

          Caveat: the FreeBSD team admits something better than init scripts will soon be necessary. But they're taking the time to figure out what and why and how. In the meantime, install FreeBSD or the desktop version that installs easily: PC-BSD, and enjoy a nice systemd-free experience. Oh no, it doesn't boot in 3 seconds! But it also doesn't

  • by Kunedog ( 1033226 ) on Saturday October 31, 2015 @10:27PM (#50840509)
    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.

  • by cfalcon ( 779563 ) on Saturday October 31, 2015 @11:19PM (#50840691)

    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?

    • FreeBSD. And it is growing. Admittedly, from a VERY small share, but...
      • by Dredd13 ( 14750 )

        Yeah, but Jordan's already implied that FreeBSD will be going down a very similar path....

        • by 0123456 ( 636235 )

          Yeah, but Jordan's already implied that FreeBSD will be going down a very similar path....

          To be fair, I don't think people are complaining about the idea of systemd--getting rid of clunky old init scripts is a good idea--they're complaining that the implementation of systemd seems to be Pulseaudio 2.0.

          I mean, my first experience of systemd was when I tried to install CentOS 7, and systemd crashed during the install. Not really a way to give me warm fuzzies.

        • Yeah, but Jordan's already implied that FreeBSD will be going down a very similar path....

          Actually, from what I've read, they are actually going down the launchd model path, and it's primarily being driven by iXsystems.

          I think that most people are not objecting to launchd because Mac OS X uses launchd, and is capable of passing the UNIX conformance tests; it's questionable whether or not a systemd based system could do the same, since in order to pass the tests, it was necessary to make launchd respond to a SIGHUP in the same way that initd did previously.

          It was also necessary for it to read fla

    • by DrJimbo ( 594231 )

      Check out MX Linux [mepiscommunity.org] and antiX Linux [distrowatch.com]. They are not in the top 10 distros but they are solidly in the top 30. They're based on Debian but don't use systemd. They also have some pretty neat features [mepiscommunity.org] and friendly [mepiscommunity.org] communities [freeforums.org].

  • Awesome news (Score:5, Interesting)

    by Anonymous Coward on Saturday October 31, 2015 @11:20PM (#50840695)

    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.

  • by Anonymous Coward

    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.

    • by Z00L00K ( 682162 )

      What works - and has worked for decades is the init system.

      It's not always the best, but it's easy to manage for a system administrator and it's easy to understand and debug startup problems.

      For stuff that takes time in an init script the historical way to solve that was to run that part in the background.

  • I have a problem with my debian server. The problem is that since upgrading to systemd, running fdisk causes the server to mount the partitions from the disk I'm trying to repartition. Even removing them from /etc/fstab doesn't prevent them from being mounted.

    I did not have this problem before systemd and God alone know where the stray configuration causing this misbehavior lies.

  • As I said before... (Score:4, Interesting)

    by QuietLagoon ( 813062 ) on Sunday November 01, 2015 @05:36AM (#50841515)
    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.
  • The systemd way (Score:5, Interesting)

    by medoc ( 90780 ) on Sunday November 01, 2015 @09:44AM (#50842243) Homepage

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

Fast, cheap, good: pick two.

Working...