Live data from Hacker News

Busybox removes support for systemd

git.busybox.net

41–50 of 203 posts

Re: Busybox removes support for systemd

#41

Earlier quoted context omitted.

Part of the reason is that systemd has absorbed functionality of a number of additional pieces of software, to the point that they are no longer maintained discretely - udev being the best example. Another part of the reason is that Red Hat forcibly landed systemd in Fedora and then RHEL7, and RH is an elephant on the scale of Linux development.

So RedHat's choices impact Debian/Ubuntu, Arch, and SUSE so much? Honest question; I don't know the details. Or are you saying that distros rely on other components that are simply not feasible (maintained) anymore, so they have no choice? Just seems like if it's as bad as so many say, it just doesn't make sense for all these distros to blindly go along. Even the GNOME lockin doesn't seem like it'd explain it.

Redhat does a lot of upstream development.

By comparison Debian just has enough resources for keeping Debian running. SUSE seems to be an afterthought at this point. Ubuntu seems to mostly be concerned with itself.

Re: Busybox removes support for systemd

#42
post #29

Earlier quoted context omitted.

It's worth noting that this is a case of Linus flying off the handle based on incomplete information. It was latter revealed that the bug which caused this whole spat on LKML had already been fixed in systemd, Kay Sievers just failed to communicate that in the bug opened by Borislav Petkov.

that is not at all what happened. Here's Kay Sievers, defiantly posting after in his own words after the incident: https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB

There were two different issues at play:

1. A system hang due an assertion in journald spamming kmsg.

2. The question of whether systemd should be logging to kmsg or doing anything based on the "debug" kernel command line argument.

Linus got pissed because, based on Steven Rostedt's post to LKML and the referenced bug report, it looked like Kay was refusing to fix issue #1, but that bug had already been addressed and a fix committed to systemd. In the aftermath there was also a flamewar over issue #2, which is what Lennart is responding to in that G+ post.

Re: Busybox removes support for systemd

#44
post #17

Earlier quoted context omitted.

Correct Also, most of systems using busybox shouldn't be running Systemd (or any other 'new' init system to be honest)

What about initrd? Most of those use busybox and it's now "recommended" to start systemd there. (Granted, I don't see why anyone would run busybox's syslog - the only component affected by this change - in an initrd.)

If you want an extremely small system, you can put everything you need into the initrd. It's not strictly an initrd then, since it's not really used for bootstrapping a larger system image.

Re: Busybox removes support for systemd

#45

Earlier quoted context omitted.

What I don't get is, if systemd is so troublesome, why are so many distros picking it up? I know popularity isn't a perfect signal, but in this case of highly technical users that are distributing OSes it seems valid.

Part of the reason is that systemd has absorbed functionality of a number of additional pieces of software, to the point that they are no longer maintained discretely - udev being the best example. Another part of the reason is that Red Hat forcibly landed systemd in Fedora and then RHEL7, and RH is an elephant on the scale of Linux development.

[deleted]

Re: Busybox removes support for systemd

#46

Earlier quoted context omitted.

Part of the reason is that systemd has absorbed functionality of a number of additional pieces of software, to the point that they are no longer maintained discretely - udev being the best example. Another part of the reason is that Red Hat forcibly landed systemd in Fedora and then RHEL7, and RH is an elephant on the scale of Linux development.

So RedHat's choices impact Debian/Ubuntu, Arch, and SUSE so much? Honest question; I don't know the details. Or are you saying that distros rely on other components that are simply not feasible (maintained) anymore, so they have no choice? Just seems like if it's as bad as so many say, it just doesn't make sense for all these distros to blindly go along. Even the GNOME lockin doesn't seem like it'd explain it.

[deleted]

Re: Busybox removes support for systemd

#47
post #42

Earlier quoted context omitted.

that is not at all what happened. Here's Kay Sievers, defiantly posting after in his own words after the incident: https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB

There were two different issues at play: 1. A system hang due an assertion in journald spamming kmsg. 2. The question of whether systemd should be logging to kmsg or doing anything based on the "debug" kernel command line argument. Linus got pissed because, based on Steven Rostedt's post to LKML and the referenced bug report, it looked like Kay was refusing to fix issue #1, but that bug had already been addressed and…

Note that going by the Torvalds email, this is far from the first time him and Sievers has been at odds.

Re: Busybox removes support for systemd

#48

Earlier quoted context omitted.

Politics. "But politics shouldn't be a factor in software design. We should cooperate to work with the technologically most useful solution and not let personal or ideological differences get in the way." Bless your heart.

Of course, this makes the assumption that the actors are actually cooperating.

That also makes the assumption that there is only one "technologically most useful solution", when in practice every application has its own unique requirements, and trying to satisfy all of them just makes a system which is not particularly good at any one of them (systemd seems to be moving in that direction, not unlike other "enterprise" software.)

Re: Busybox removes support for systemd

#49

Earlier quoted context omitted.

Part of the reason is that systemd has absorbed functionality of a number of additional pieces of software, to the point that they are no longer maintained discretely - udev being the best example. Another part of the reason is that Red Hat forcibly landed systemd in Fedora and then RHEL7, and RH is an elephant on the scale of Linux development.

So RedHat's choices impact Debian/Ubuntu, Arch, and SUSE so much? Honest question; I don't know the details. Or are you saying that distros rely on other components that are simply not feasible (maintained) anymore, so they have no choice? Just seems like if it's as bad as so many say, it just doesn't make sense for all these distros to blindly go along. Even the GNOME lockin doesn't seem like it'd explain it.

At this point RedHat has consumed de-facto governance of some core projects that make up the Linux desktop system that sit atop the kernel. They pay developers to work on these projects and there employees have decision making authority. SystemD is almost entirely driven by current/former RedHat employees.

The fact of the matter is that "Distros" like Debian etc are dependent on upstream developers to provide new versions of there system. If a large portion of important subsystems are developed by RedHat developers then they will adopt that code and be driven in the direction upstream wants to go.

"Distros" do not develop, they package upstream into compiled binaries and add there configs and perhaps package management. In short most of the distros will bend which ever way the upstream wind blows.

Thats why I use a "Distro" Like Slackware or Crux that is built from scratch and not based on another system. What limited autonomy there is in Linux land is with the independent Distros.

Re: Busybox removes support for systemd

#50

Earlier quoted context omitted.

So RedHat's choices impact Debian/Ubuntu, Arch, and SUSE so much? Honest question; I don't know the details. Or are you saying that distros rely on other components that are simply not feasible (maintained) anymore, so they have no choice? Just seems like if it's as bad as so many say, it just doesn't make sense for all these distros to blindly go along. Even the GNOME lockin doesn't seem like it'd explain it.

Debian isn't really a leader. They're more of a passive target platform and their committee has people from various strokes of the Linux community. As such, RH decisions with significant influence definitely would impact them. Ubuntu, in turn, is symbiotic with Debian, though still quite forked from it in most aspects beyond the packaging infrastructure (now with Snappy diverging even further). Nonetheless, Unity nee…

Systemd is pointing out the truth about lots of "emperor's clothes" in the current Linux ecosystem.

When there were problems about a desktop manager revamp or some crashy audio daemon, you could liquidate certain choices as irrelevant or lazy. Now the entire ecosystem's guts are being rewritten by RedHat for RedHat, and the developer community is simply going along because, in practice, they have no other choice. Nobody else has the appetite, the manpower or the political weight to put together a competing project with a single chance of success.

When chips are down, Red Hat owns Linux more than we like to admit.

Post reply on HN