slong at rathaus
May 16, 2012, 9:39 PM
Post #29 of 68
(180 views)
Permalink
|
|
Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
[In reply to]
|
|
Alec Warner wrote:
> Fabio Erculiani <lxnay [at] gentoo> wrote:
>> I think expressing my own opinion about Lennart-made software is my
>> right, after all.
>> Firstly, it's almost impossible nowadays to avoid including avahi,
>> systemd and pulseaudio into a desktop distro so, there is no real
>> choice. This issue became a sensible matter for those users who for
>> instance, wanted to have a silly mp3 player working without going
>> through the PA nonsense, really missing the old
>> ALSA-oh-it-was-always-working days.
>
> Er, the source is open, so choice is always there. What I think your
> complaint is the fact that it used to be easy to do those things
> (because upstream supported those options and USE flags exposed them
> to you) and now upstream is not supporting those options and there is
> no easy way to remove the dependencies without doing a bunch of work.
>
I think it's more a matter of process. These changes force major userspace
changes, which since they are not a matter of ABI export, don't really
concern kernel devs (after all, they design for userspace to do crazy stuff,
or their OS is not robust: beyond ABI stability, the contract they fulfil,
in the main they don't really care what happens there.)
However the changes are forced on admins and users, unless we take on a
development effort which means we're no longer just admins or users. And
yeah, people are clearly looking at doing that with mdev, though we'd rather
not have to be forced into that.
>> If you want to bring complexity but you end up not being able to
>> handle it, then you're not a really good engineer, IMHO.
>
> I don't think anyone expects complexity to come bug-free. Cathedral
> and the Bazaar? Release Early and Release Often? I expect the software
> to reach a stable state in a reasonable amount of time given the
> complexity involved.
>
The way to handle complexity is with small, modular components that are
loosely-coupled and cohesive. AKA "Do one thing, and do it well." Like udev
has been doing for quite a while.
>>
>> Having said that, I also wonder where's the lovely modularity the
>> various *nix platforms had. If this is the actual direction of Linux
>> Foundation, Redhat and Canonical, I am worried that Linux would end up
>> being an OSX-wannabe.
>
> The problem as I understand it is that you want other people to write
> software that meets your needs and it turns out that the world doesn't
> always work that way.
>
> You can fork the software you hate (using versions before you hated
> it) or you can write your own software (like mdev + busybox) to
> replace the hated components. Both of those things are actually
> somewhat useful. Complaining about how some random people on the
> internet don't write software that you find palatable is just silly.
>
It's not about that: the point is that massive changes are being pushed
through, and the people who actually have to implement them in the real-
world haven't been consulted. When they are, after their concerns about
administration (you know, their jobs) are dismissed and they're asked for
technical reasons, they draw attention to Unix principles, simply because
they have been proven over decades to be the best basis for software-
engineering.
And please: "random people on the internet"? That's not how I'd describe
upstream udev or kernel maintainers. Or is this your "it's the developer's
playground" philosophy again?
Simply put, there is no space in kernel mailing-lists, nor in upstream udev
et al, to have this discussion. It affects Gentoo users most, because we are
far more likely to run using custom-compiled kernels with base system
modules like motherboard disk-controllers built-in, and to have setup eg
/usr on LVM in accordance with docs, and since we use a rolling-release we
haven't needed to change what wasn't broken.
Nor do many of us think we've heard any benefit to outweigh the
disadvantages. For instance, we've been told several times that a) an
initramfs is the new root, in that we don't need rescue tools on an easy to
mount root anymore, our initramfs will be a souped-up rescue-shell; and b)
that an initramfs is easy to set up and maintain, and should typically only
be a few hundred kilobytes (so it's not going to bloat the boot process.)
Everything I've seen of people's configs in forum posts about setting up
initramfs, and heard of the process, makes me think it's going to be a
custom design per-Gentoo user, and tweaking what's in there is going to be
part of standard setup and ongoing maintenance. Forgive me for assessing
that as a regression in usability.
Ultimately of course, udev maintainers will do what they want. That's fine,
and I'll shut up about the whole thing as my concerns are on the record:
just so long as no-one pretends they've justified the breaches of basic
design principles.
Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
|
signature.asc
