Live data from Hacker News

Busybox removes support for systemd

git.busybox.net

71–80 of 203 posts

Re: Busybox removes support for systemd

#71
post #20

Earlier quoted context omitted.

After Arch Linux, Debian, Fedora, Red Hat and CentOS switched over to systemd, it must be a very tiny part of the Linux world.

Arch linux spawned a distro called manjaro which leads the way on not joining the systemd bandwagon. Debian got forked into devuan which is debian minus systemd. As systemd originated from redhat it is expected that the other faces of redhat namely fedora and centos would also feature systemd. Then there is slackware, gentoo, pclinuxos that either did not bit the systemd bullet or offer alternative option. Not sure a…

Err, Distrowatch claim that Manjaro use systemd...

Re: Busybox removes support for systemd

#72

PID 1 should be boring. Tiny, simple and boring. Any software project that raises this much controversy should be looked at with a raised eyebrow. A software project this large, complex, controversial and coupled that wants to be PID 1? Absolutely no way.

you are exactly on point.

the unix way is simplicity and transparency. systemd is complex and opaque.

it's ok to have systemd's goals, but an additional goal should be "not a huge monolith"

Re: Busybox removes support for systemd

#73
post #17

Earlier quoted context omitted.

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.

This is the only way I use Linux.

I will use the Linux kernel (although it is not my favorite kernel).

But I am interested very little in GNU userlands and all the idiosyncracies, complexity and politics that comes with them.

Re: Busybox removes support for systemd

#74
post #22

Earlier quoted context omitted.

I'd also like an answer to this question, as well as an answer to the question of what, in exacting detail please, was so wrong with the previous system it needed to be torn out and replaced? I definitely tend toward the curmudgeonly, but to this grumpy old man, it seems like we're replacing things simply for the sake of change.

Nah, the old system did need replacing [1], and plenty of them were in fact done. [2] Evidently they went understudied, though. [1] http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy... [2] http://blog.darknedgy.net/technology/2015/09/05/0/

At this point in time though i wonder if focusing on the init part is missing the forest for the trees.

I think just as much of a stink comes with how you need to have systemd-the-init to use systemd-logind (replacing consolekit for session tracking) or any number of other possibly interesting, but tied to the hip of systemd, sub-projects.

Re: Busybox removes support for systemd

#76
post #20

Earlier quoted context omitted.

After Arch Linux, Debian, Fedora, Red Hat and CentOS switched over to systemd, it must be a very tiny part of the Linux world.

Arch linux spawned a distro called manjaro which leads the way on not joining the systemd bandwagon. Debian got forked into devuan which is debian minus systemd. As systemd originated from redhat it is expected that the other faces of redhat namely fedora and centos would also feature systemd. Then there is slackware, gentoo, pclinuxos that either did not bit the systemd bullet or offer alternative option. Not sure a…

"Arch linux spawned a distro called manjaro which leads the way on not joining the systemd bandwagon."

...well, kinda: manjaro supports openrc, but the official, main installs are systemd. you can start with an official install and convert it, or you can use an openrc iso, but those are not officially supported.

Re: Busybox removes support for systemd

#77
post #59

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.

Yes systemd is Red Hat's "embrace, extend, extinguish" strategy for Linux.

Redhat used to be good before they forked off the desktop OS into Fedora. They went downhill in my eyes quickly after that.

Re: Busybox removes support for systemd

#78
post #69
post #23

Earlier quoted context omitted.

I'm just guessing here, but systemd makes some things more convinient by being overall more monolithic, like Windows, and especially distros that are targeting a less technical crowd want to be able to compete with Windows in terms of features and usability. Non-technical people most likely don't see any of the beauty of a strictly modular system or proper clean code. And this is not about the init-daemon, it is abou…

I'm more tempted to say that systemd does well what previously you needed a dozen half-broken tools to implement. For example, isolating the /tmp of an application, monitoring the process and restarting if necessary, more logging options (and imho cleaner/more efficient). Then again, all this has been debated over and over again. In practice, people are adopting it. Haters are noisy. It's like reading about debates o…

Process supervisors with reliable logging are nearly two decades old at this point. Isolating /tmp is then a namespacing feature, which in a system where execution state is composed as an explicit external manifest via chain loading (as opposed to serializing from a unit file into a private ExecContext structure, as with systemd) should be completely orthogonal to any one service manager. Else it is inflexible if it needs complex internal scaffolding.

(Actually I think supervision goes back to IBM's SRC in at least 1992, but I'm not exactly sure if the earliest versions had anything beyond process management.)

Re: Busybox removes support for systemd

#79
post #3

> systemd people are not willing to play nice with the rest of the world. Can we get a bit a of context on that?

People have been trying to fix the boot process in linux for years. Like most things, everybody screams when something changes, but nobody is willing to put in the work to make something better.

RedHat had enough, and finally jammed systemd down on the Linux ecosystem.

This had two effects:

1) Technical: it exposed a LOT of shortcomings in the architecture of Linux for operating on modern systems. The whole "This belongs in PID 1! No it doesn't!" stems from there not being good, correct, and obvious ways of accomplishing the tasks that need to be done.

2) Political: it pissed off everybody from Linus down who actually thought they had power and control by demonstrating forcibly that their opinions don't really matter.

As for the technical issues, I'm not terribly sympathetic. Somebody needed to fix this, and it was painfully clear that nobody was ever going to get consensus on this. In addition, Linus blocks a LOT of stuff attempting to evolve the kernel in directions that are improvements, but that he does like or doesn't understand. For example, Linus didn't handle the ARM board issues very proactively. He basically ignored things until they got untenable and then finally blew up at the ARM guys and threatened to rip them out of the kernel. People had tried several times to get a modular configuration system put in place, but Linus never wanted to commit it as there "wasn't consensus". True, but once his pants caught on fire, he didn't give a shit about consensus anymore.

As for political issues, I have even less sympathy, as RedHat simply did what Linus has been doing for years and imposed their will on the ecosystem by force. Enlightened dictatorship is a wonderful governmental mode, until you're no longer the dictator. Perhaps if Linus had figured out how to actually build consensus, I would find his words less hypocritical and more deserving of consideration.

The BSD's are no strangers to controversy. The whole existence of OpenBSD and NetBSD is a tribute to that. Even with FreeBSD, the GEOM subsystem changeover caused great friction. The difference is that Poul-Henning Kamp did the work and got a signficant level of consensus from the BSD leadership--but by no means unanimous and it was sometimes acrimonious.

Re: Busybox removes support for systemd

#80
post #20

Earlier quoted context omitted.

After Arch Linux, Debian, Fedora, Red Hat and CentOS switched over to systemd, it must be a very tiny part of the Linux world.

Just to add to the others CentOS was essentially bought by RedHat and there Core developer is now a RedHat employee. Magically there was a new major 7.0 version bump adopting SystemD as the one and only init system. A new flashy website and a refusal to allow any alternative init system into the official packages other then SystemD. Needles to say CentOS is no longer an independent alternative to RedHat Linux.

CentOS has always been RHEL without the trademarks, they'd have followed Red Hat to systemd regardless.
Post reply on HN