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.

Comments

Commit Message Missing for Me

[Kunedog]

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.

The Commit Message

[Kunedog]

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.

Re:The Commit Message

[Anonymous Coward]

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:The Commit Message

[SlashdotOgre]

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.

Re:The Commit Message

[ArmoredDragon]

I keep the systems configured so that in the event of a complete power outage, EVERYTHING must come back up without any intervention required. This is saves a lot of explaining when it's time to put out a fire and -- oh shit, the admin forgot to document how to get everything back up and running when somebody crashed their car into a nearby transformer and the UPS failed to signal the diesel generator to start, and now we're spending 3 days trying to get shit working again because the guy who set it all up quit about 5 months earlier. (Yes, I've seen exactly this happen before.)

The reboots are only necessary when testing changes to make sure that everything comes up the way it's supposed to in the event of a total loss of power. Sometimes this doesn't happen (for example, a new kernel image breaks ZoL, so after the reboot the array doesn't get mounted) and it might take multiple reboots before you've got it all set.

Re: The Commit Message

[Anonymous Coward]

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.

Re:The Commit Message

[thegarbz]

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?

Re:The Commit Message

[Antique Geekmeister]

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