Debian TC vote on init system coupling
Debian TC vote on init system coupling
Posted Feb 24, 2014 22:57 UTC (Mon) by javispedro (guest, #83660)In reply to: Debian TC vote on init system coupling by anselm
Parent article: Debian TC vote on init system coupling
It would be perfectly feasible for a distribution to replace one part of systemd by something better on a trial basis and fold worthwhile innovations back into the main codebase later.Not even `mighty' canonical really managed to do that with logind. How can a mere mortal even dream to do that, specially when even systemd maintainers are encouring strongly tying everything to systemd (as exemplified by this very article)?
One of the points raised during the Debian discussion was that Debian's existing binfmt `manager' was better (objectively more featureful) than the one in systemd, which was based on Fedora's. Because Fedora won't change for standarization reasons, Debian would be forced to switch to systemd's or just rip systemd's builtin one from the codebase.
Just a few years ago it was still trivial to replace GDM's "shutdown" script with a simple bash script. I would gladly chose whichever distribution allows me to continue doing that, instead of "by UI experience". Please don't assume there's no differentiation left in the plumbing layer :( .
And there are still distros out there innovating on the kernel side (e.g. Debian offers Hurd!, Gentoo offers framebuffer, hardened stuff, etc.)
Sidenote: I already tried to be careful with the LSB RPM wording and thus my use of `a standard' instead of `the standard'. No discussion was intended.
Posted Feb 24, 2014 23:27 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
This is a lot less scary than it sounds. Since systemd is modular, the only thing you need to do is disable systemd-binfmt.service and enable Debian's binfmt support instead, which helpfully already comes with a systemd unit file. No ripping anything from any codebase involved.
Posted Feb 25, 2014 0:01 UTC (Tue)
by mchapman (subscriber, #66589)
[Link]
And if that's not good enough, you can even build systemd with --disable-binfmt. After all, isn't the choice of configure options the kind of decision package maintainers *should* be making?
Posted Feb 25, 2014 0:51 UTC (Tue)
by ermo (subscriber, #86690)
[Link]
@Anselm: Could you please stop being so damn well-informed and eloquent? You're ruining any chance of watching the discussion devolve into inane, yet highly entertaining and entirely unconstructive flamewars based on the notion that systemd/Red Hat/Lennart is evil (for a suitable definition of evil). P.S. I'm with Henry Ford on this one: You can have your init in any color as long as it's systemd.
Posted Feb 25, 2014 0:03 UTC (Tue)
by HelloWorld (guest, #56129)
[Link]
> And there are still distros out there innovating on the kernel side (e.g. Debian offers Hurd!, Gentoo offers framebuffer, hardened stuff, etc.)
Posted Feb 25, 2014 1:11 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Others have addressed the easy solution to the problem you are posing but I want to challenge this underlying assumption. Fedora frequently adopts new technologies and has a long history of throwing away home grown solutions in favor of the standardized components including for instance in the case of kudzu, various system-config-* tools, nash etc. Even systemd required adoption new conventions and configuration formats etc.
Posted Feb 25, 2014 1:38 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
The Debian utility has a long history inside Debian, but it doesn't appear to have been picked up by Red Hat prior to Fedora, or by SUSE, or by Gentoo as a widely used helper to simplify initscripts. It appears that the more "standard" thing to do was to poke at the /proc entry inside of multiple initscripts instead of dropping config files into a location on package install for a common binfmt helper to parse. Debian's implementation for a helper doesn't seem to have cross-pollinated at all in the years prior to systemd adoption, for whatever reason.
Regardless, it seems like Debian maintainers have this sorted out and are going to disable systemd's binary by default. Which actually does make some sense for their upgrade path. Debian has sysvinit scripts in service built assuming binfmt-support's implementation and its config directory, so its not unreasonable for Debian to continue to assume their traditional service implementation in their packaging as a conservative approach to their upgrade path. I don't think any of the previous systemd adopters had to worry about the existence of binfmt-support package and its related service, as they all appear to just be replacing hardwired sysvinit script logic with something equivalent.
Debian TC vote on init system coupling
Because Fedora won't change for standarization reasons, Debian would be forced to switch to systemd's or just rip systemd's builtin one from the codebase.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
>
> One of the points raised during the Debian discussion was that Debian's existing binfmt `manager' was better (objectively more featureful) than the one in systemd, which was based on Fedora's. Because Fedora won't change for standarization reasons, Debian would be forced to switch to systemd's or just rip systemd's builtin one from the codebase.
systemd's binfmt stuff can be trivially disabled with a configure switch. Are you honestly trying to say that that's an insurmountable challenge?
What does Gentoo do differently with respect to framebuffers? And I hate to bring this to you, but Hurd is a toy. I has been around forever, yet it's still nowhere near production ready, it's based on outdated technology (Mach), attempts to port it to other microkernels have failed, and worst of all, there's no momentum around it, nobody even takes it seriously.
Debian TC vote on init system coupling
Debian TC vote on init system coupling