Re: [gentoo-user] /dev/sda* missing at boot

["Canek Peláez Valdés" <caneko@gmail.com>]

On Thu, Sep 8, 2011 at 11:15 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Sep 8, 2011 at 10:51 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Wed, Sep 7, 2011 at 11:39 PM, Dale <rdalek1967@gmail.com> wrote:
>>> Canek Peláez Valdés wrote:
>>>>
>>>> Then don't update. Wanna keep up with upstream? Then accept that sometimes
>>>> you will need to change your setup, and change how you do stuff. Regards.
>>>
>>> This is so like something I have told folks about windoze.  Awesome !  To
>>> think I stayed away from windoze because of the freedom Linux gives a user
>>> just to find out now, its not as different as I thought.  :-(
>>
>> But the freedom is still there. The freedom to either keep your system
>> as it is (don't upgrade), or to modify the source code to suit your
>> own needs.
>
> Please don't ever, ever, ever recommend not upgrading as a reasonable
> long-term strategy. I don't like to think about how many security
> problems exist in systems I'm familiar with because "not upgrading"
> was the more convenient route.

Please refer to my other responses: of course you need to upgrade
security flaws. But in production, that's it.

> The other side of what you're saying, "show me the code," is
> reasonable. And if there's only one upstream maintainer who's got what
> feels like the entire Linux community over a barrel on this, that
> seems like a really good idea in principle.

I agree.

>> Just don't expect from upstream to maintain code for each and every
>> possible configuration. It gets really complex really really really
>> fast.
>
> See also: LibreOffice requiring CUPS discussion earlier this week. No
> surprises there, and it's understandable.
>
> Still, I think I understand the complexity of what we're talking
> about, yet it feels like the developer has a serious case of "my use
> cases are the most valid ones, and I want to simplify udev's problem
> space in favor of that."
>
> As long as (and only as long as) udev isn't required for a server to
> well and correctly, that's almost reasonable. That almost puts it in
> the same class as DBus. (See the discussion from *last* week.)
>
> Perhaps udev's problem is that it's too complex, as a result of having
> too large a problem scope.

I don't agree: udev is really small and (for what it does) really
simple. Not having udev (or dbus for that matter) is going back ten or
fifteen years. Both projects are prime examples of what I see as
*progress* in Linux.

>> Upstream (either Gentoo, or the kernel, or udev, or all of them) will
>> decide to support only a subset of all possible configurations and it
>> will mark them as supported. Don't aprove of that? Then maintain it
>> yourself (which you have the freedom to do), or keep up with the
>> change.
>>
>> Freedom doesn't equals to "give me everything I want, and the way I
>> want it". The freedom we have is "here is this set of programs, and we
>> support this set of configurations; if you don't like it, here is also
>> the source code". Which is light years better than in Windows or MacOS
>
> Code or GTFO. Classic FL/OSS fare. (Admittedly the best solution we've
> found so far)

It's not the best: it's the only one. Because as long as someone does
not write code, he can argue until his throat is dry but nobody will
really care.

> I remember devfs, and that it was rejected in favor of udev because
> some things belong in userspace. udev, as far as I understand, udev
> listens to hotplug events and performs actions in response. Perhaps an
> alternate implementation is in order.

Like I have been saying: by all means, write it if so you think. But
the kernel devs went through three iterations (classical Unix /dev,
devfs, and finally udev) to get to this point. I really don't think a
new implementation is neither necessary nor required.

But maybe I'm wrong, and some hotshot programmer will get it really
right (TM) next time. I really dubt it, though.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México