Debian TC vote on init system coupling
Debian TC vote on init system coupling
Posted Feb 24, 2014 17:02 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 was never necessary to reinvent the "plumbing layer" before -- new distros that did not care just copied a existing one from another distro (often Debian or Ubuntu, or even Fedora).
But most of the interesting distros actually care; instead, they don't care on "the other tasks", which is the reason they will not able to keep on forward porting non-systemd Gnome3 forever.
This is an area where everyone wants to have its word and has been like that for the best of a decade or two. You should not be surprised that standardization is rejected (in the same way as when `rpm' was made LSB standard). E.g. I still remember initng (also readily ignored) which offered a extensible (plugins) init that was both event and dependency based. Even Fedora had a wiki page on the early days with ideas for a future init system based on D-Bus services and "launch on demand".
Such proposal actually resembled upstart more than it did resemble systemd, which basically appeared out of nowhere.
Posted Feb 24, 2014 17:28 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (8 responses)
I don't think using systemd as the plumbing layer precludes innovation. Many people don't appreciate the fact that systemd is actually a fairly modular framework that just happens to come in one big source tarball. 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.
By analogy, distributions don't seem to mind not differentiating on the kernel, either. There are some distributions that actually sponsor serious kernel development, but these usually have a policy of aggressively pushing their patches upstream; the idea of a »Red Hat kernel« or »Debian kernel« that includes innovative bits that no other kernel has and isn't going to get, and that motivates people to pick Red Hat over Debian or vice-versa, does not actually exist.
Finally, for Linux distributions there is ample room for differentiation left above the plumbing layer, which is probably much more gratifying from the point of view of addressing users – many of whom will probably not really care what their plumbing layer is like as long as it does the job, but may be quite passionate about »their« distribution's UI experience.
The problem with other standardisation efforts like the largely-stillborn LSB was that they usually meant extra work for distributions. One of the maxims of the Internet is »rough consensus and working code«, and while it was possible to get the consensus (sort-of anyway), the working code was left to the distributions to come up with (each on its own). The big difference is that systemd actually comes with the code that does the standardisation, and that allows distributions to save work rather than put extra effort in. Hence the buy-in to systemd was much more vigorous and widespread than the buy-in to LSB. (And the LSB RPM issue is a red herring – LSB didn't try to mandate RPM as the official packaging format for all Linux distributions, it made RPM the standard for the distribution of LSB-compliant software packages, which is not at all the same thing.)
Posted Feb 24, 2014 17:56 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
So any lsb package could easily be converted to and installed upon an apt-based system.
Cheers,
Posted Feb 24, 2014 22:57 UTC (Mon)
by javispedro (guest, #83660)
[Link] (6 responses)
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
Debian TC vote on init system coupling
Wol
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)?
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