Debian TC vote on init system coupling
Debian TC vote on init system coupling
Posted Feb 24, 2014 18:53 UTC (Mon) by HelloWorld (guest, #56129)In reply to: Debian TC vote on init system coupling by mgb
Parent article: Debian TC vote on init system coupling
systemd doesn't care where the plumbing comes from, it just tries to pick the most sensible alternative. And in quite a few cases, they adopted debianisms, which were then also adopted by Fedora.
> Systemd distros will migrate to Fedora plumbing elements whenever systemd so dictates - a huge loss of Debian functionality.
systemd can't possibly dictate anything, it's just an open source project, and also new functionality in systemd doesn't mean that the equivalent features in debian somehow magically disappear. In short, what you're saying here is nonsense.
In fact, if debian has a better implementation of something, the sensible thing to do is to try to push it into systemd, so other distros eventually end up offering it to their users too (except if they go out of their way to disable it). Everybody wins that way.
> And systemd have further made it very clear that they will continue to "standardize" additional plumbing whenever they feel like it - leaving Debian struggling under an endless deluge of systemd bikeshedding.
WTF? Sometimes storing the hostname in /etc/HOSTNAME, sometimes in /etc/hostname and sometimes in /etc/sysconfig/network, *that's* bikeshedding. It's a huge win that systemd stops that kind of madness.
Posted Feb 25, 2014 1:19 UTC (Tue)
by rahvin (guest, #16953)
[Link] (9 responses)
I have no idea how anyone could feel that way but it's clearly her/his point of view and it's rather pointless to even discuss facts because the facts really aren't relevant to the point he/she is trying to make, which is Redhat is evil. You'd have better luck trying to have a philosophical discussion with an inanimate object.
Posted Feb 25, 2014 4:44 UTC (Tue)
by mgb (guest, #3226)
[Link] (8 responses)
Fedora is different. It works better for some people. Debian works better for some people.
Replacing Debian plumbing with Fedora/systemd plumbing is a serious loss.
Posted Feb 25, 2014 5:56 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
To be honest, you want to call that Fedora/RHEL/Mageia/openSUSE/Arch plumbing instead of pretending it is Fedora specific.
Posted Feb 25, 2014 6:07 UTC (Tue)
by mgb (guest, #3226)
[Link] (1 responses)
Nobody is claiming there's anything unique about Fedora plumbing.
However Debian/Ubuntu/etc plumbing is different, many but not all people find it better, and replacing it with Fedora/systemd/etc plumbing is a massive loss.
Posted Feb 25, 2014 6:23 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Ironically, that is a big strawman by itself.
" Nobody is claiming there's anything unique about Fedora plumbing."
If you don't mean to imply that, you should avoid writing Fedora/systemd that gives that impression you are trying to equate these two projects. If you want to attach distros to the systemd project, then you want to list all the distros that use systemd instead of singling out Fedora.
Posted Feb 25, 2014 8:48 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (2 responses)
Which is why nobody is proposing to do this, at least not in a way that does cause »serious loss«.
First of all, »systemd plumbing« is not necessarily »Fedora plumbing«. Considerable parts of »systemd plumbing« actually derive from Debian, or from other Linux distributions.
Secondly, in many cases it doesn't actually matter. For example, whether a system's host name is stored in /etc/hostname, /etc/HOSTNAME, or /etc/sysconfig/hostname is quite immaterial, and it is hard to argue that one approach is technically superior to another. Which is why the standardisation that systemd catalyses is overdue and very welcome.
There are cases where it makes sense for Debian to stick with »Debian plumbing«, e.g., for compatibility or because the Debian approach offers more features than the systemd default. In these cases it is generally easy to disable/mask or override the systemd default, with a view to possibly integrating whatever Debian does into upstream systemd if it is of general interest.
I'm personally confident that the systemd developers and the Debian systemd maintainers are going to come up with a way of providing systemd for Debian that will let us take full advantage of the stability improvements and new features that systemd enables. There will not be »serious loss«. Two or three years from now we will look back and wonder what all the fuss was about.
Posted Feb 25, 2014 9:41 UTC (Tue)
by bangert (subscriber, #28342)
[Link]
And that even though Debian had not committed itself to systemd at that point. I take this as a clear indication of the systemd developers being committed to technical excellence and their willingness to cooperate...
... or, if that does suit your world view, it could be an effort to bribe Debian into adopting systemd.
Posted Feb 25, 2014 14:31 UTC (Tue)
by mebrown (subscriber, #7960)
[Link]
Posted Feb 25, 2014 14:28 UTC (Tue)
by mebrown (subscriber, #7960)
[Link]
Asserting this over and over does not make it true and moves my mental slider for your comments further into troll territory every time you repeat the same thing without offering anything new.
Posted Feb 25, 2014 15:00 UTC (Tue)
by Chousuke (subscriber, #54562)
[Link]
I've been running systemd as a default init for a long while on my Debian laptop now (and finally uninstalled sysvinit a shorter while ago when the package dependencies no longer prevented it) and it's been working perfectly.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Replacing Debian plumbing with Fedora/systemd plumbing is a serious loss.
Debian TC vote on init system coupling
> from other Linux distributions.
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
