On Mon, 2019-07-22 at 19:56 -0700, Mo Zhou wrote:
> Hi Marc,
>
> Sorry to hear that. In fact I have some similar feelings.
>
> On 2019-07-23 01:22, Marc Munro wrote:
> > [ . . .]
> I always fail to find a better free and independent replacement to
> Debian.
> Even if the current stable release does not deliver the user
> experience
> we expected, what the other distros deliver, I guess, would be more
> or
> less the same. That's because Debian is a collection of scattered
> software, where the user experience is not always decided by Debian
> itself but the software upstreams.
Thanks for your response, it is appreciated.
I don't expect to find a better or more free replacement. I will miss
Debian for many things, but especially for having a thoroughly
principled community behind it.
> That said, it's simply that I don't like the design of several
> programs. Luckily I still have the freedom to force these programs
> to stop: if systemd --disable gdm3 doesn't work (yes, it indeed
> doesn't
> work at all), I can mask that unit by symlinking it to /dev/null. If
> masking still doesn't work, I can e.g. `sudo rm -f /usr/bin/gdm3` and
> the annoying program will finally stop working.
[shrugs] Yep, I could have figured that out if I hadn't been so
frustrated. But it shouldn't be necessary. If systemctl disable does
not work it should be fixed. I guess I should have filed a bug report.
> Do you have any suggestion for the Debian side so we can make some
> concrete improvements, or mitigate some problems?
Beyond not releasing stuff that is obviously bad for the user
experience?
I understand how development works, and how with the best intentions
this sort of thing is pretty much inevitable. You want good software,
but you also need to get new releases out. You can't continually delay
the next major release while you wait for fixes from upstream
developers who may not care about the same things as you.
The first thing to do is to get serious. The only way to start solving
this, is to *insist* on minimal standards of quality.
Here's a thought:
Create a new bug category called "detrimental". This would be a bug,
that left uncorrected, would be detrimental to the user experience, or
reputation of Debian. I would argue that packagekit's current
behaviour is exactly that. In fact I think there are 2 detrimental
bugs in my story: packagekit's crazy resource usage, and systemd's
inability to disable it.
Tell your upstream developers that anything with a detrimental bug
will be deemed of insufficient quality and will be worked-around. The
possible work-arounds would be pretty serious, but also simple to
understand:
- the offending package would be removed
- the offending package or program would be disabled by default
- the offending package would be reverted to a previous non-
detrimental version
- the offending package would be forked
I know the fork thing is completely contrary to current Debian
practices where the pristine nature of upstream sources is highly
valued, but we're talking about detrimental bugs here, and we're
talking about giving the upstream developers a really strong incentive
to take things seriously. And forks, with modern tools, are much
easier to manage today than they were back in the day when the pristine
source philosophy originated.
I don't expect this suggestion to be implemented as such, but I think
it is worth having a debate around these issues to see what could be
done. At least to see whether the community is prepared to take it
seriously.
The other issue my story raises, is of attempts to simplify the user
experience at the expense of flexibility and configurability. I see
Linux moving closer to the windows and Mac experience, and although
some of that is good, much of it is not. I don't think Linux needs to
be more like windows or Mac. We don't need to dumb things down for a
target audience that doesn't care about the underlying Unix philosophy.
We have a target audience and it's us.
Thanks again for taking the time to respond.
__
Marc
