Okay, and here’s the reasoning for “sticking to an antiquated” init system:
I fully believe that Debian should be as flexible as possible when meeting users’ needs. There is already a big downstream running on Upstart, and I believe that, given the assumption that we need to decide on one/the init system, there is indeed market for another big Debian downstream that runs on systemd and offers GNOME after it has, by Neil’s suggestion (and, if we decide to only support one init and it’s not systemd, that *is* the logical outcome, *and* one I fully support), been removed from Debian. This will cause “the market” to work and make for some healthy competition, while accepting the goodies from both downstreams to flow back into Debian if they’re good enough (i.e. do not prevent sysvinit from working). This appears to work pretty well with Ubuntu already, with early hostilities (on both sides) having been overcome. I believe that sysvinit allows for the most flexibility for users and porters, and imposes the least on package maintainers unwilling to write init scripts for more than one system. Both newcomers support running packages from initscripts, whereas it’s their way or the highway for the respective native scripts, which may be added to Debian to be used by Debian users running a nōn-default configuration (meaning with upstart of systemd as init, which would presumably still be doable by users, but not by packages, leading to the GNOME removal), and, of course, by the aforementioned downstreams. There needs to be said that sysvinit is the one closest to Unix principles by not being as “integrative” (cf. modular), not insisting on its own, proprietary binary logging format, and other things. There may be a place for FLOS, but a Universal OS is not it. Additionally, sysvinit, at this point in time, is the only system working universally across Debian thanks to the Hurd GSoC by Justus Winter, whose Planet posts I read amazedly. I believe we should solidify its status in Debian, as diversity is a good thing, and the newcomers are not as portable (even if a GNU/kFreeBSD port of upstart was begone). Downstreams may want to limit their set of architectures for arbitrary reasons, so they would not have the same constraints of being universal. Finally, sysvinit is “the thing to expect” in the GNU/Linux world, despite attempts from two big and a very small number of smaller GNU/Linux vendors. Keep the principle of least surprise and accept that sysvinit is the most universal one, the one people coming from other GNU/Linux systems and even some Unicēs will know, expect, or at least (if they’ve been at Fedora before) know something about, and one which even BSD people can accept and understand. It’s widespread, and a good common denominator. So I believe that, if we need to choose a default right now, it must be sysvinit, and this must be a reliable outcome, i.e. we commit to this and don’t arbitrarily change our mind later. I believe that, should this question be forced first, GNOME needs to be removed from Debian and welcomed as a downstream. That being said, I would support upstart over systemd alone for the fact that it doesn’t appear to do such “land grabs”, is open for improvement (such as the kFreeBSD port) and not as hostile as some of the people behind systemd/GNOME have shown themselves to be, over and over again; I believe that the fact of it being mainly driven by a company is not a big problem (if needs be, fork it), especially as they have shown themselves capable of doing large-scale projects in a mostly technically sound manner, and be somewhat more consistent in the implementation, as opposed to the perceived “a big change every other week” of the other newcomer systemd. bye, //mirabilos -- <ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^ <mika> sorry, no idea and rebasing just fscked │<mika> Segmentation <ch> should have cloned into a clean repo │ fault (core dumped) <ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
