On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: > On Thu, Nov 13, 2014 at 11:04 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote: > > On 11/12/2014 5:18 PM, Andrei POPESCU <andreimpopescu@gmail.com> wrote: > >> On Mi, 12 nov 14, 15:43:09, Tanstaafl wrote: > >>> > >>> Sounds good to me, but in reality, since the default *and only* init > >>> system for the last very many years was Sysvinit (this extremely salient > >>> point seems to be completely and totally lost on the systemd > >>> proponents), I think only systemd and sysvinit need to be there... but > >>> allowing for additions once required bugs implementing them are resolved > >>> as fixed. > >> > >> You're forgetting about: > > > > It doesn't matter Andrei... > > > > 1. The *default* is what we are discussing. > > > > The *default* for Debian has been sysvinit since - forever? It was claimed that sysvinit was the default *and only* (emphasis not mine) init, and therefore no selection was needed, but now that there are several a selection suddenly is needed. I was just pointing out that alternatives were indeed available, for quite some time, it's just that maintainers and users of alternate inits did not yell at the sysvinit maintainers to implement the choice for them. > To explain to the systemd advocates who refuse to understand the > engineering questions, this is the real engineering mistake in > systemd. [snip another wall of text about engineering principles] > For Fedora, where it was first brought into a major distribution, the > proper way to bring it in would have been to break policy and set up a > parallel fork. Keep the damage that necessarily occurs with this kind > of thing restricted to a sub-community willing _and_ _able_ to deal > with the damage by cooperating in the separate bug tracking, triage, > etc. Keep the questions of direction somewhat independent so that the > systemd side and the "legacy" side don't have to be in lock-step on > every tiny detail. Allow separate of source so that regressions and > merges can be safely scheduled and safely carried out. Etc. I'm not familiar with how Fedora evolves as a distribution, so I will refrain from commenting on this. > If they had done it right from the start, just about now, they would > be ready for beginning the integration process in earnest, which would > mean that about the beginning of this year, when the question came > formally before the committee here, Fedora would have been > implementing their own version of an installer that would allow > choosing the new init system on install. What the Fedora installer can or cannot do is irrelevant for Debian, unless one can use it to install Debian (is this the case?). > So Fedora is not, itself, really ready yet, except for two groups, a > certain group of workstation users who want and are willing to use > fairly new, relatively high-end hardware, including enough RAM and > processors to use VMs for certain things, and a certain group of > server-farm users who want and have budget for similarly recent, > relatively high-end hardware and lots of RAM and processors for lots > of VMs. > > The rest of the Fedora users jumped ship. Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just fine. Also my laptop running is quite far from being a speed monster. > Now, you who complain that Fedora and Red Hat are off-topic here, > remember that Debian is inheriting the results of Red Hat's work. Work > that did not allow a choice of inits on install, as one example of > where their work is incomplete. That choice was something we still > haven't got quite right yet, after how many months? Even if Fedora and/or Red Hat would have this choice it still wouldn't have helped Debian in any way, because the bug is in a Debian component (debootstrap, guess what the "de" stands for). > Debian set up kfreebsd to deal with these kinds of issues, relative to > replacing the linux kernel with the freebsd kernel. Setting up a > debian-sysd would not have been as extensive a project as setting up > kfreebsd, but would have been similar, because we are basically > pulling in a new layer between the kernel and the rest of the system. "Debian" as an entity doesn't really do much. There are only one or several volunteers who start doing things. Setting up a separate "port" for systemd would have been a major waste of resources (both human and hardware) with no real gain. > The systemd folks claimed it wouldn't be necessary. If we had looked > at the situation with an unbiased eye, we would have known they were > being overly optimistic. We still turn a blind eye to the problems, > claiming that the only problems are a bunch of recalcitrant > noisemakers like yours-truly. You are completely dismissing the work of Debian Developers who *did* have a very good look at the options and decided switching to systemd is doable and would be a good thing from a *technical* point of view. And yes, that included the costs for the migration. As far as I can tell by watching debian-user, debian-devel and pkg-systemd-maintainers the integration of systemd is mostly working fine and remaining issues (not all in systemd itself) will be dealt with before the release. The freeze could help with that, since the number of variables is reduced greatly. However, you and several others are rejecting systemd on ideological grounds. There's not much that can be done about that, short or re-implementing systemd according to your vision. I hope you do understand why neither the systemd developers, maintainers or users have any interest whatsoever in doing that. After all, systemd already works fine for them. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt
Attachment:
signature.asc
Description: Digital signature