Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Busybox removes support for systemd

git.busybox.net

Post reply on HN
Print view View original

81–90 of 203 posts

Re: Busybox removes support for systemd

#81

Post by otterley »

bossrat wrote: post #72
erpellan wrote: post #38

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"

What is the criteria by which you classify something as "opaque"? The documentation for systemd and its utilities is second to none.

Re: Busybox removes support for systemd

#82

Post by XorNot »

vezzy-fnord wrote: post #78
mgbmtl wrote: post #69

Earlier quoted context omitted.

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…

Process supervision goes back a long away...and has pretty much never been included out of the box in any server-oriented Linux distros.

It also looks a lot more like systemd in systems with good process supervision like Solaris.

Re: Busybox removes support for systemd

#83

Post by digi_owl »

vezzy-fnord wrote: post #78
mgbmtl wrote: post #69

Earlier quoted context omitted.

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…

I think one thing that gave systemd adoption a big boost was a declaration from the maintainer of the cgroups sub-system of Linux.

At present multiple processes can set up and manage cgroups, but the maintainer wants to change to there being a single user space manager.

Thus systemd was pushed as "the" cgroups user space process.

You can already seeing the systemd devs behaving as if this was a done deal.

Ran into a email a while back about systemd clobbering a libvirt managed cgroup. And in it Poettering "suggested" that libvirt should hand control over to systemd as it would be THE cgroups manager going forward.

You can probably find similar encounters between, say, Docker and systemd.

Re: Busybox removes support for systemd

#84

Post by XorNot »

bigbugbag wrote: post #30
MichaelGG wrote: post #19

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.

Well that's a good question, I'd like to have an answer to that. debian adoption of systemd was a bumpy ride to say the least, it caused a few long time contributors to resign and others to fork debian to remove systemd in a new distro called devuan. Then again systemd gobbled other critical components such as udev, there's also gnome that made it a strict requirement, like a cancer it grows and takes over other comp…

Devuan is someone's extended tantrum and little more. Like every other rage-fork it'll die a slow death because who wants to develop on a platform founded on the premise of "why do we need to change anything? It's all working fine!"

Re: Busybox removes support for systemd

#85

Post by bsder »

Avshalom wrote: post #41
MichaelGG wrote: post #33

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.

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.

> By comparison Debian just has enough resources for keeping Debian running.

I think that's a touch unfair. The fact that Debian runs on the BeagleBone Black and RedHat doesn't puts a bit of lie to that statement.

Re: Busybox removes support for systemd

#86

Post by Avshalom »

bossrat wrote: post #72
erpellan wrote: post #38

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"

The unix way is also a different incompatible implementation of regex in every utility and a thousand interesting and dangerous modes of failure in the event of whitespace

Systemd has issues I'm sure and I don't trust poettering's software further than I can throw him but not being 'unix'-y isn't a strike against it.

Re: Busybox removes support for systemd

#87

Post by XorNot »

erpellan wrote: post #38

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.

Most of systemd is not in PID 1.

People making this complaint don't seem to have any idea what is in init normally or why you might want to add more stuff there (for example, where are you going to manage cgroup trees for system processes from?)

Re: Busybox removes support for systemd

#88

Post by vezzy-fnord »

XorNot wrote: post #82
vezzy-fnord wrote: post #78

Earlier quoted context omitted.

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…

Process supervision goes back a long away...and has pretty much never been included out of the box in any server-oriented Linux distros. It also looks a lot more like systemd in systems with good process supervision like Solaris.

Which is a failure of people making server distros, not those writing process supervisors.

Not at all. SMF supports delegated restarters, its milestones can contain far more state information (and explicitly) than targets can, it uses a configuration repository which enables runtime dynamic service state modification at a far higher rate than the relatively static systemd, its dependency system is simpler, it's integrated with the hardware fault manager (also to provide service resource identifiers beyond the COMM name), its profiles are more granular than presets, it has explicit service instance support and logging is flat file-based in /var/svc/log.

SMF has plenty of its own issues, but it's quite different from systemd. I think the delegation aspect is one of its most valuable lessons, but ultimately I also believe it's too overarching for a modern init.

Re: Busybox removes support for systemd

#89

Post by vezzy-fnord »

otterley wrote: post #81
bossrat wrote: post #72

Earlier quoted context omitted.

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"

What is the criteria by which you classify something as "opaque"? The documentation for systemd and its utilities is second to none.

The documentation for systemd and its utilities is second to none.

God help the software industry if that is indeed the case (of course, it is not).

Re: Busybox removes support for systemd

#90

Post by generic_user »

digi_owl wrote: post #58
generic_user wrote: post #49

Earlier quoted context omitted.

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 ver…

Ultimately you can go for something like Linux From Scratch. And even they have gotten somewhat fed up with the Systemd antic. For instance their main book use eudev rather than udev, because they found the effort of extracting udev from the larger systemd project a right pain. They do however maintain a parallel systemd book for anyone interested.

Linux was/is an extremely flexible system. The vendors like RedHat should be able to refashion Linux in what ever way they see fit. The big problem with SystemD is that it stepped over the red line from in-house RedHat Linux component like SE-Linux and there various "enhancement" to a rigid default that attempts to lock down a large array of system components under a project that has commercial motives and drivers, driven by a single vendor. And it was done with a pre-meditated social engineering push which was quite nasty. Big no-no for Linux and Open Source eco-system in general. Projects Like Linux from scratch, GNU, Busybox etc will not role over for the endless attempts at vendor lockin. Its all been tried before and while the players may be new the game is very old and ultimately we will defeat these new attempts just like we did with SCO and the proprietary Unix/Microsoft Corporations that tried to kill Linux in the 90s.
Post reply on HN