williamh pushing usr merge

[saellaven]

[Ant P.]

That's actually great news. With his "vision" for openrc no longer squatting in those directories, we can much easier build a drop-in replacement that installs there.

[skiwarz]

[derk]

If you want more info check the gentoo-dev mailing list archives.. for where this started.

To add to the questions to be asked are: how does this idea effect "system security", compartmentalization , protection from user errors, program usage restrictions- via directory permissions etc.

are we going to a non-directory based system .. everything in one pot.. really makes no sense to me.. how does this idea effect disk storage efficiency.

sure we have "historical artifacts" in the file system .. but really is it necessary to make these changes .. what is the real gain in value?

any other concerns .. ignoring system init choices specificly.

[ct85711]

the only thing I see having everything in one folder, is to work around lazy programmers and to be easier to the Windows people. Though, I do forsee a larger performance hit for combining everything together, loss of security (i.e. users become more like admin users in windows that can do anything). Thinking to control security through pam or through ACL's is not a good idea. Anyone that's had to deal with the hassles of dealing with all the ACL's and permissions in a windows network, knows that it's a pain that never truely works properly. Specially when you end up having multiple different permission sets from a different source, and who knows which one is going to apply that instance (which may not be the same next time). A good example on windows, is user permissions on the local system and the ones from the network. Then you get my favorite, the Read only flag on files. On windows, the read only flag has effectively no meaning unless a program is designed to honor it (the filesystem does not care able that flag, so you can easily delete or modify the file even though it is read only).

[Yamakuzure]

Who said everything to go into one folder?

This is just to get rid of /{bin,lib,lib32,lib64,sbin} which all exist in /usr for ages and are mainly filled there.
The only reason for the stuff in the root folders is (and ever was) to make tools available that are needed before /usr comes online.

So the only people who would have a problem with this are those who want both: A separate usr partition and booting without an initrd.

The only thing that puzzles me is the merge of the sbin folders into /usr/bin. I do not like that one.

[mv]

[khayyam]

[khayyam]

[Naib]

[Roman_Gruber]

no idea what the fhs says

but

[derk]

mmm after having read the articles linked earlier .. including the Fedora article on the usr move.

.. where do the kernel modules get stored .. in such a way so that usr " in theory" could be network shared and each cpu have it's own kernel config .. and cache of installed modules ..

moving /lib into /usr/lib blows up that separation .. does every cpu now need to be the same ..

or do we move kernel modules into /etc or /var or /var/lib ..how does fedora do that?

[khayyam]

[krinn]

The point of having /sbin symlink is to force everyone to use the same tools.

If you put openrc into /usr/sbin instead of /sbin: it doesn't make any difference at first, but that's a big one.
- when you boot a non diskless client using /usr from a server, the server tools will be magically export to the client : if server have /usr/sbin/openrc, client could use it, but if client use another init, it will not be able to use openrc anyway, so it have access to a tool it have no use for.
- worst: when your client boot, it use its /usr/sbin that of course have openrc as it use it, then it mount /usr from the server that is using systemd, and all openrc tools are now gone! it lost its own control of its system: it couldn't anymore do any "/etc/init.d/whatever restart/stop/start" because it need a /usr/sbin/openrc that is no more usable.

So the thin (that are just client with a tiny disk) clients will have no choice than using the same init (and tools) as their server.
After the usr move, the next step will be "force anyone to install their critical tools into /usr/sbin instead of /sbin" with the argument that "one day, we will remove the /sbin symlink, all tools should be in /usr/sbin".

What a nice world where all clients must use systemd because systemd was use to boot that server, all clients must use bash because server is using bash...

I wonder if fedora plan to offer some /usr as cloud service or something like ltsp...

[steveL]

Anyone who thinks this is a good idea, is off their head AFAIC.

Next.

[steveL]

[saellaven]

[Anon-E-moose]

Oh boy, what's next running as root all the time.
If I wanted to run windows, I would run windows.
Not some morons version of linux as windows.

I've never considered stupidity a handicap, but I may have to rethink that given what I'm seeing from the gentoo dev leaders.

One does have to wonder just how much is RH paying people like WH to ruin a distro.
That's the only reason I can see for some of the outright idiocy being proposed.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[tld]

[depontius]

Why don't we put up a poll about the whole /usr merge thing?

I know quite a few of us here don't like the idea, but are we just a concentration of curmudgeons? Maybe, maybe not. But at any rate, it seems pretty well proven that we can't send a message to WilliamH, perhaps a poll could.

Is there any way a /usr merge could be made optional, say a USE flag or other portage directive?

If pressed hard, perhaps I don't mind merging /bin and /usr/bin - THAT badly, because I've read enough LKML to understand that to some, initrd is the new /. But merging sbin content into bin is just not a good idea at all, and to me that is a bigger mistake than the /usr mess.
_________________
.sigs waste space and bandwidth

[Naib]

[Anon-E-moose]

It seems as if WH is hell bent on destroying gentoo, at least as it has existed for quite some time.

The real question is will the trustees to allow people like WH to destroy it.

For me, I can always choose to roll my own, it won't be the first time.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[khayyam]

[depontius]

[Tony0945]