Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Fri, Nov 14, 2014 at 11:26 AM, Andrei POPESCU
> On Vi, 14 nov 14, 08:59:11, Joel Rees wrote:
>> On Thu, Nov 13, 2014 at 11:04 PM, Tanstaafl <email@example.com> wrote:
>> > On 11/12/2014 5:18 PM, Andrei POPESCU <firstname.lastname@example.org> 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
>> To explain to the systemd advocates who refuse to understand the
>> engineering questions, this is the real engineering mistake in
> [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,
I would like to give my opinion. I have been using Debian for 14
years. I switched to Debian because I believe in freedom. I used to
use fvwm, then switch to blackbox, enlightenment, kde, LXDM, gnome,
etc. We still have those options because that is how Unix works and I
love that. It is very important to keep that approach.
Let's imagine a country where 49% of the population likes blue jeans
and 51% of the population likes black jeans. Then there is a
referendum and the 51% decide to impose by law to wear black jeans.
Although that might be legal, it is certainly not correct.
Debian is a community made by developers and users. Both are equally
important to keep the community alive. The type of users is very broad
and it goes from teenagers to server guys. Because of that we should
keep the freedom of choice an important part of Debian.
This is why I do believe that we should have to the option to choose
the init system and it has to be easy. It has to be clear how to do it
with the installation program. A "geek" approach where you have to
install systemd and then you have to remove it, is in practice: "no
choice". Not everybody is a geek.
Personally I prefer not to use systemd in my servers, but I find
wonderful to have the choice. Do you remember the Gnome/KDE war? Now
we have two great desktop. Let's not impose by law an init system.