1 |
Alec Warner wrote: |
2 |
|
3 |
> Fabio Erculiani <lxnay@g.o> wrote: |
4 |
>> I think expressing my own opinion about Lennart-made software is my |
5 |
>> right, after all. |
6 |
>> Firstly, it's almost impossible nowadays to avoid including avahi, |
7 |
>> systemd and pulseaudio into a desktop distro so, there is no real |
8 |
>> choice. This issue became a sensible matter for those users who for |
9 |
>> instance, wanted to have a silly mp3 player working without going |
10 |
>> through the PA nonsense, really missing the old |
11 |
>> ALSA-oh-it-was-always-working days. |
12 |
> |
13 |
> Er, the source is open, so choice is always there. What I think your |
14 |
> complaint is the fact that it used to be easy to do those things |
15 |
> (because upstream supported those options and USE flags exposed them |
16 |
> to you) and now upstream is not supporting those options and there is |
17 |
> no easy way to remove the dependencies without doing a bunch of work. |
18 |
> |
19 |
I think it's more a matter of process. These changes force major userspace |
20 |
changes, which since they are not a matter of ABI export, don't really |
21 |
concern kernel devs (after all, they design for userspace to do crazy stuff, |
22 |
or their OS is not robust: beyond ABI stability, the contract they fulfil, |
23 |
in the main they don't really care what happens there.) |
24 |
|
25 |
However the changes are forced on admins and users, unless we take on a |
26 |
development effort which means we're no longer just admins or users. And |
27 |
yeah, people are clearly looking at doing that with mdev, though we'd rather |
28 |
not have to be forced into that. |
29 |
|
30 |
>> If you want to bring complexity but you end up not being able to |
31 |
>> handle it, then you're not a really good engineer, IMHO. |
32 |
> |
33 |
> I don't think anyone expects complexity to come bug-free. Cathedral |
34 |
> and the Bazaar? Release Early and Release Often? I expect the software |
35 |
> to reach a stable state in a reasonable amount of time given the |
36 |
> complexity involved. |
37 |
> |
38 |
The way to handle complexity is with small, modular components that are |
39 |
loosely-coupled and cohesive. AKA "Do one thing, and do it well." Like udev |
40 |
has been doing for quite a while. |
41 |
|
42 |
>> |
43 |
>> Having said that, I also wonder where's the lovely modularity the |
44 |
>> various *nix platforms had. If this is the actual direction of Linux |
45 |
>> Foundation, Redhat and Canonical, I am worried that Linux would end up |
46 |
>> being an OSX-wannabe. |
47 |
> |
48 |
> The problem as I understand it is that you want other people to write |
49 |
> software that meets your needs and it turns out that the world doesn't |
50 |
> always work that way. |
51 |
> |
52 |
> You can fork the software you hate (using versions before you hated |
53 |
> it) or you can write your own software (like mdev + busybox) to |
54 |
> replace the hated components. Both of those things are actually |
55 |
> somewhat useful. Complaining about how some random people on the |
56 |
> internet don't write software that you find palatable is just silly. |
57 |
> |
58 |
It's not about that: the point is that massive changes are being pushed |
59 |
through, and the people who actually have to implement them in the real- |
60 |
world haven't been consulted. When they are, after their concerns about |
61 |
administration (you know, their jobs) are dismissed and they're asked for |
62 |
technical reasons, they draw attention to Unix principles, simply because |
63 |
they have been proven over decades to be the best basis for software- |
64 |
engineering. |
65 |
|
66 |
And please: "random people on the internet"? That's not how I'd describe |
67 |
upstream udev or kernel maintainers. Or is this your "it's the developer's |
68 |
playground" philosophy again? |
69 |
|
70 |
Simply put, there is no space in kernel mailing-lists, nor in upstream udev |
71 |
et al, to have this discussion. It affects Gentoo users most, because we are |
72 |
far more likely to run using custom-compiled kernels with base system |
73 |
modules like motherboard disk-controllers built-in, and to have setup eg |
74 |
/usr on LVM in accordance with docs, and since we use a rolling-release we |
75 |
haven't needed to change what wasn't broken. |
76 |
|
77 |
Nor do many of us think we've heard any benefit to outweigh the |
78 |
disadvantages. For instance, we've been told several times that a) an |
79 |
initramfs is the new root, in that we don't need rescue tools on an easy to |
80 |
mount root anymore, our initramfs will be a souped-up rescue-shell; and b) |
81 |
that an initramfs is easy to set up and maintain, and should typically only |
82 |
be a few hundred kilobytes (so it's not going to bloat the boot process.) |
83 |
|
84 |
Everything I've seen of people's configs in forum posts about setting up |
85 |
initramfs, and heard of the process, makes me think it's going to be a |
86 |
custom design per-Gentoo user, and tweaking what's in there is going to be |
87 |
part of standard setup and ongoing maintenance. Forgive me for assessing |
88 |
that as a regression in usability. |
89 |
|
90 |
Ultimately of course, udev maintainers will do what they want. That's fine, |
91 |
and I'll shut up about the whole thing as my concerns are on the record: |
92 |
just so long as no-one pretends they've justified the breaches of basic |
93 |
design principles. |
94 |
|
95 |
Regards, |
96 |
Steve. |
97 |
-- |
98 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |