[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: support for merged /usr in Debian

On Sat, 09 Jan 2016 11:09:00 -0800, Russ Allbery <rra@debian.org>
>For one specific example, it's become quite clear over the past year that
>systemd has achieved the same status as abortion debates in US politics.
>Not only is it clear that we will *never* stop arguing about systemd,
>opposition to or support of systemd has turned into a tribal identity
>marker for at least some people.  Those who disagree aren't just
>prioritizing different things, or even just wrong, but are actively evil,
>horrible people who should be shunned.  This is hugely demoralizing and
>hugely off-putting.  While it is by far not the only thing that has led to
>me not spending as much time on Debian over the past year plus, it's
>certainly been a factor.

I disagree with this point of view.

The technical problem with systemd is its inflexibility. It can do
about 80 % of things that the alternatives were able to. It does those
80 % exceptionally well, with clear design and good documentation.

Unfortunately, getting the 20 % to reach the old feature set is almost
impossible since systemd's upstream is fiercely opposed to implement
things that they themselves don't deem necesary, and they're also
opposed to add documented interfaces that would allow local additions
to be hooked in.

I am not even talking to go beyond the 100 % that we used to have with
the alternatives by using _their_ interfaces because systemd doesn't
have those interfaces.

It's simply unproductive to first having to argue with upstream if one
needs one certain IPv6 /proc/sys/net option in systemd-networkd _and_
to wait for the next Debian stable release for this possibility to
become available, if I need to set this option for my network to work

And it's simply frustrating to instinctively think "here should be a
variable" when writing a systemd unit because one cannot use a
variable here since systemd upstream thinks that it is unnecesary.

And it's quite arrogant to not implement things that ease starting
daeons that don't have their own configuration files, saying the
daemons should have configuration files and not rely on their command
line, hence systemd should not have features to make building daemon
command lines easier. Heck, some of those daemons have been around
since before systemd upsteam was born.

>This is obviously one of the biggest examples, but I don't think it's the
>only one.  There are numerous large and small examples that show up when
>people want to change how something has historically worked.

There is nothing wrong with change. There is a lot wrong with changes
that makes a significant portion of people's work harder and more
clumsy in the name of making things easier.

Of course this is something that will be discussed over and over again
because it makes people's live harder over and over again. One never
praises things that have become easier. But one will always blame
things that have become (unnecessaryil) harder, especially if the
hardship could be reduced by a bit more cooperation instead of
arrogance and dogmatism.

>And the pattern I've seen, time and time again, is that someone will come
>forward and say "look, I think this aspect of Debian is kind of broken,
>and has no real plausible path for getting better, and I think we should
>embrace this other way of solving the same problem."  And is met by people
>who are furious about the fact that the thing that is currently broken is
>not being fixed instead of putting effort into something new.

I think that greatly depends on how much existing functionality is
lost by this other way of solving the same problem.

>> It sees to me that it is because:
>> * I haven't been giving talks (or writing mailing list messages or
>>   manpages) where I attack people's beloved tools, data formats, or
>>   source code management practices.  I could certainly give such
>>   talks, but it would just serve to make me (more) enemies.
>In fact, you *have* done this occasionally.  You've been vocal about
>things that you think are broken or insane or horrible, using terms like
>that.  I remember hearing several of them in person.  :)  For example, I
>recall you not being much of a fan of how 3.0 (quilt) packages work.

And, additionally, Ian sounds pretty different when one _reads_ what
he wrote or when he is _heard_ saying those exact same words. My
perception of Ian has changed a lot (in a positive way!) when meeting
him in person at Debconf.

>Another good recent example (well, "recent"; the debate has drug out over
>*years*, which is typical) is the Debian menu vs. desktop files argument,
>which went all the way to the TC, got a TC decision, and now still isn't
>completely settled because there's a separate Policy argument.

Yes, it's another change that kills existing functionality without a
real replacement.

Or can I have an executable that generates virtual .desktop files on
the fly as I can with Debian menu?

>To me, this is far more of a social issue than a technical issue: we're
>intolerant of innovation, we're intolerant of enthusiastic people who step
>on toes because they're enthusiastic,

I don't mind people stepping on does. I do mind people being arrogant
<censored> out of their enthusiasm, killing others' enthusiasm in the
process. Any project built from volunteers does have its share of
<censored>, and this might be one of the reasons while company-backed
projects are more successful in the long run.

>This is not entirely one-sided.  I completely agree with you that
>declaring other people's much-loved code or configurations to be dead is
>not a good communication technique and contributes to this problem.  But I
>feel like we have the balance set all wrong here.  We're putting all of
>the weight of the emotional work and communication on the people who want
>to make changes, and that's how a project stagnates.

There is a truckload of changes that are urgently necessary.

>I'll say it again: enthusiasm is fragile.  If we slap down excited people
>every time they make intemperate comments out of enthusiasm, we lose SO
>MUCH energy.  And I don't think we can afford to lose that much energy
>from the project.

We are losing energy either way.

-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Reply to: