Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 05:20 AM, Thomas Goirand wrote:
>> It's like being able to customize internal parts of your cars engine
>> when ordering one from your dealer. Customers don't care who the
>> manufacturer of your ignition system is as long it's the best
>> possible one. (Yes, I know comparisons with cars are bad ;)).
> That's partly not truth. Some customers care, and do customization of
> their car.
No, it's absolutely not. You can have the choice for the interior
design, the paint job, the radio, the type of engine and comfort
features, but you certainly cannot have the choice on internal
parts like the ignition system or starter motor.
Furthermore, if you do decide to replace these parts on your own,
you will end up losing your car manufacturer's warranty.
And this is very much what I would see in Debian. Use your desktop
and applications of choice and you will get support, but if you
want to change core components, you are free to do so, but you
will lose support.
A very reasonable approach in my opinion as you weigh the cost
of maintenance vs. advantage of being able to choose.
>> Neglecting reliability and maintainability for the sake of being
>> able to choose such a core component is a bad idea. I do not
>> think it's really feasible to maintain several init systems, it
>> just affects too many components of the system.
> It's just up to the volunteers, which was my message. If some of us car,
> it's going to be possible. If there's not enough interest, then you are
And since there are virtually no volunteers for OpenRC besides
you and the other two OpenRC maintainers, Roger and Benda, it
will be unsupported at some point when you guys step down.
Do you really think this is a desirable situation for our users?
I have seen you asking for help on OpenRC so many times during
these discussion, but I am yet to see people raise their hands
and say "Yes Thomas, I am going to help you!"
All I read are statements from you like "Yes, it would work
in general if we had someone to implement it, I don't have
the time right now unfortunately."
See, I am one of the people involved in the m68k port of Debian.
Just recently, one of our main contributors decided to jump
the ship who cannot be replaced by someone else easily as
public interest in the m68k port is simply way too low meaning
we have lost lots of development manpower.
Thus, I fully agree that m68k has been abandoned as a release
architecture long time ago. It's nice that it's there, but
there isn't any official support and the rest of Debian
shouldn't have to worry about it.
>> We don't even manage to maintain two versions of ffmpeg (the original
>> and the fork) even though many users actually prefer the original. How
>> should this even work with the init system then?
> Maybe no DD cares enough for ffmpeg?
No, it's because it's not possible to have libav and ffmpeg packaged
at the same time due to conflicting so names and the fact that reverse
dependencies would have to be taken care of as well.
> On 02/11/2014 04:10 AM, John Paul Adrian Glaubitz wrote:
>> Again, I do not understand how our users will actually profit from
>> being able to choose their init system.
> It doesn't mater, we don't force our thinking on you. Nor it's a good
> idea that you try to convince everyone that they should adopt *your*
> choice. I believe there's been enough discussion so that you will agree
> not everyone shares your view on systemd. I don't see it as a problem
It's not *my* choice, systemd is the choice of the majority of the
Linux community. OpenRC and upstart are used in Gentoo and Ubuntu
only (ChromeOS doesn't really count in that context, it's a more
or less closed system by Google), while virtually every other
of the large distributions has adopted systemd.
Using something which is not widely adopted and has very few supporters
in the development community means that if any of the OpenRC or
Upstart people will decide to retire, these systems will lose
much more development manpower than systemd does.
>> Can you imagine this being an option in Debian Installer just like
>> you can configure your time zone or filesystems? What would you
>> write to the description texts of the different choices?
> Ubuntu users have a choice of installer: the Debian one and the standard
> Ubuntu one. I don't use the standard Ubuntu installer, though I have no
> pb with others using it.
That's not what I said. I asked whether it's possible to choose
the init system in the installer and it's not possible in either
the Ubuntu or Debian installer.
>> It's crazy just to think about it.
> I don't see any craziness, it's just like all of Debian: volunteer
> based, and depending on everyone's motivation and involvement.
And that's the exact problem with OpenRC and Upstart - besides the
technical side - there are just a handful of volunteers in the
whole Linux community while systemd has a very large community meaning
even if any of their main developers decide to step back at some
point, systemd will still be well supported by the community.
I do not think that anyone will ever step in when you decide
to abandon OpenRC or Steve decides to abandon Upstart and, yes,
it will happen at some point in the future.
>> Do we allow users to choose their FireWire stack, WiFi or Audio Driver
>> stack in the kernel? There were several alternative implementations
>> of these, yet we only provide one of each.
> I don't see why we would explicitly forbid this choice (which has
> nothing to do with what we provide by default). Last time I checked, it
> was possible for our users to rebuild their own kernel. We even provide
> some userland tools for that.
We do not forbid it, but we do not support it either. If users write
bug reports about crashes related to custom kernel configurations
or setups, the Debian kernel team will most certainly close them
as UNSUPPORTED-WONTFIX which is very reasonable.
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - email@example.com
`. `' Freie Universitaet Berlin - firstname.lastname@example.org
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913