Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Thu, 05 Jan 2012 16:50:45 +0100
pk <peterk2@××××××××.se> wrote:

> On 2012-01-05 13:08, Alan McKinnon wrote:

[snip]

> > mdev has a much narrower scope where things are considerably more
> > static.
>
> Currently it does have a more narrow scope, yes, but that can change,
> no? Although I'm not entirely convinced that a userspace dev manager
> is needed (yes, devfs on Linux was an utter failure but Solaris, Mac
> OS X, *BSDs use it[1] and done properly in Linux it should work just
> as fine)...
>
> 1: https://en.wikipedia.org/wiki/Devfs#devfs

As I understand it, devfs had unfixable race-condition problems.
Normally these things can be fixed with an architectural re-design but
Greg then showed up with udev. It's in-kernel design is quite elegant
actually. But udev then and udev now are likely very different beasts.

And that's about my limit of things I know for certain with udev

> > As for re-arranging the fs layout, I think it was Canek in the last
> > thread that gave an excellent example of why this is needed. When
> > devices hotplug, or need to become active early on in the boot
> > process, they need to run code that can be located almost anywhere.
> > It wouldn't be fun trying to get a wireless keyboard going when
> > it's start-up script needs to get into /usr/lib/firmware and /usr
> > isn't mounted yet.
>
> Yes, I understand the need for this but... how does a wireless
> keyboard work under bios/firmware (*efi)? Never tried one and never
> will... A computer without ports should handle such connections in
> firmware (analogy: You don't need software to drive a cable).

To you and I it might seem absurd, but I think out there in the
marketplace it's quite a reasonable thing for a user to want. And if
that example never happens, there's hundreds more than can. Point
being, the code must be able to deal with such things.

> > I do agree with collapsing the executable code in /usr into /, or
> > having /usr on the root partition. A separate /usr/{,s}bin is pretty
> > pointless and was never done for safety or maintenance reasons. It
> > was done way way way back when disks were small and a convenient
> > hack was to keep the OS on the boot device and user apps somewhere
> > else on bigger but slower storage (which often was remote).
>
> Hm... I find it quite elegant and flexible with the separation of /
> and it's various underlying directories. I guess we can agree on
> disagreeing here... although, I'm a bit surprised to see you as an
> admin defending the "new" way... Windows does have such a philosophy
> with putting everything system related into a directory (\WINDOWS)...
> Ultimately one can argue why use anything else besides Windows, it
> does the job reasonably well.

Oh, I'm not advocating doing it Windows style, I'm simply saying what's
the point of the system itself having 4 locations for binaries when I
never use that separation? I gain nothing from having a /bin and
a /usr/bin.

/opt and /usr/local/bin *are* useful so I'd keep those. Same with /var
and all the other traditional separate mount points.


> > If /usr is local, what really is the point of having it separate
> > from /? Have you ever found a Linux system in any condition that
> > could not start just because the stuff in /usr was available? I
> > haven't.
> >
> > Even the split between bin and sbin is arbitrary. It's only there so
> > that users can take sbin out of PATH and not have the screen
> > cluttered with endless junk when they tab-tab. It makes much more
> > sense to me to just have one single bin and lib location and shove
> > everything into it.
>
> I'm not an admin of a large organization so what do I know... but, I
> still can appreciate the flexibility and "tidyness" it[2] gives you
> in a multi-user system. I also can see this from a security point of
> view ("keep the cool toys from the children")... I personally like it
> for my very local computer as well for the above reasons (flex./tidy).
>
> 2: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>
> What you are basically saying is that everything "we" have learned
> about computer systems should be abolished and we adapt the
> monolithic, "black box" philosophy of newish systems like Windows.
> That's how I interpret what you're saying (yes, I do know hardware
> has changed since the 60'ies but not that radically, IMO)... I tend
> to think of Unix as "Lego" where you have lots of little bits with
> clean(ish) interfaces with which you can build whatever you want.dual
>

Good analogy. I also like building systems from individual Lego bricks.
I don't like having to build the bricks themselves first :-)

Windows goes too far to the other extreme IMO. That OS seems to have
largely abandoned control and there's not much in the way of
structure. Too little control is just as bad as too much 


[snip]



-- 
Alan McKinnnon
alan.mckinnon@×××××.com