Re: [gentoo-user] udev + /usr

[Joost Roeleveld]

On Wednesday, September 14, 2011 10:30:03 AM Canek Peláez Valdés wrote:
> On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld <joost@××××××××.org> wrote:
> > On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote:
> >> On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer
> >> <grimlog@×××.de>
> >
> > wrote:
> >> > If gentoo follows fedora on this mandatory initramfs trail, I'll
> >> > switch to FreeBSD completely. My software works on way more
> >> > systems than just "Linux".
> >>
> >> That's of course your prerogative. And, as I said before: "Linux
> >> strives to be much more than Unix, and that means do things
> >> differently." If you want to do things the same way that it was done
> >> in the last 20 years, maybe Linux is not the best of choices.
> >
> > I read it before, but to be much more then Unix, Linux should be doing
> > things better. Being different is what led to MS Windows'
>
> But that's the thing: we (you and me) don't see the situation the same
> way. To me, the proposed changes are for the better.

There are not many people who agree with you here.
The changes will lead to a C:-drive, similar to MS Windows, where everything 
has to be a single partition.
For various reasons, using seperate partitions are a better solution:
-  It allows for the use of filesystems better suited to the type of files and 
usage on each partition. 
- It prevents a single part of the filesystem to kill the entire system. (I 
can risk loosing 1 partition and not loose the rest of my data)

> >> I myself think the new technologies are worth to change the way we did
> >> things before. But that's just me.
> >
> > The new technologies have great merit. But, the implementation of it
> > isn't thought through.
>
> In my humble opinion, what you just said is a little pedantic. You can
> disagree with the proposed changes, you can argue why you think
> another approach could be better. But just saying "the implementation
> of it isn't  thought through", is a little insulting to the devs. I
> think they though about the implementation a lot.

They may have thought about it, but didn't think things through.
I have already stated a better way of doing it in the past few days. I will 
repeat it here.

The problem-scope that udev is TRYING to solve should NOT be solved in a 
single tool.
The main purpose of udev is to populate the /dev-tree.
The running of scripts based on /dev-tree events should be in a seperate tool 
that starts later in the boot-process.

Merging these 2, without properly handling failures, is bad design.
Forcing ALL Linux users to use a C-drive is one of the worst design flaws I 
have ever encountered.
Forcing the use of an init* which can leave systems unbootable, is also a 
design flaw.

How do you propose to fix the situation where the init* is broken and someone 
is unable to mount all the filesystems needed to rebuild the init* because 
udev, which SHOULD be populating the /dev-tree, refuses to do the single job 
it is designed to do?
Then rethink about the fact that not all computers are easily accessible 
and/or have cd-drives/usb-ports active.
My desktop has them active, my servers don't as I do not need USB on the 
server.

> >> >> And maybe I shouldn't even mention it, but I don't use OpenRC. I
> >> >> use
> >> >> systemd. And it works great on Gentoo.
> >> >
> >> > Well. Linux only. If I wanted a monoculture, I would use
> >> > MS-Windows or
> >> > OSX.
> >>
> >> Relax man. I mention what I use: I'm not forcing you (or anybody else)
> >> to use it. But I repeat (because I said it before) that I care about
> >> Linux, and Linux only.
> >
> > If you care about Linux, why do you allow it to be broken in such a
> > fundamental way?
>
> Again, to me is not "breaking it". To me is "improving it".

Adding another SPOF (Single Point Of Failure) is not an improvement.

--
Joost