Symlink /usr to /

Just out of curiosity, how much would it break a system if one was to go ahead and link /usr to the root directory? It seems /usr contains all the important files nowadays anyway, and is more vital than root, yet root stays centric... I would google for testimonies but the nature of Linux directory and user naming makes that all the more impossible.

Make it idiot-proof, and someone will breed a better idiot.-- Oliver Elphick

Re: Symlink /usr to /

Terminator, have you ever dug into the /sys/class/ directory structure? You can keep digging deeper and deeper until you suddenly realize you are just going in circles. The pathname gets longer and longer, yet you remain in the same place. Perhaps they should rename /sys/class/ to /red/queen/.

Re: Symlink /usr to /

That's what the Hurd does, and it seems to work pretty well (at the small cost of cluttering / a bit). The reasoning being that /usr was created because root volumes were small but computers would have a large external storage volume which could be mounted after boot (/usr), but that's not an issue any more. Rather than just move everything in /usr to /, the symlink is kept for compatibility with things that expect a /usr.

Re: Symlink /usr to /

Barrucadu wrote:

That's what the Hurd does, and it seems to work pretty well (at the small cost of cluttering / a bit). The reasoning being that /usr was created because root volumes were small but computers would have a large external storage volume which could be mounted after boot (/usr), but that's not an issue any more. Rather than just move everything in /usr to /, the symlink is kept for compatibility with things that expect a /usr.

My thoughts exactly! I knew I'd seen it somewhere already...

drcouzelis wrote:

Why are you interested in doing this? Is it really just out of curiousity?

Of course I just recently set up another arch box and had to use a seperate /usr on lvm, which was quite a pain to set up. Given the high dependency on /usr nowadays, I just thought it should be merged with / instead. I don't see why it doesn't make sense not to, especially since Hurd has already done it and it works quite well there

Make it idiot-proof, and someone will breed a better idiot.-- Oliver Elphick

Re: Symlink /usr to /

Trilby wrote:

Terminator, have you ever dug into the /sys/class/ directory structure? You can keep digging deeper and deeper until you suddenly realize you are just going in circles. The pathname gets longer and longer, yet you remain in the same place. Perhaps they should rename /sys/class/ to /red/queen/.

Science geek humor, or English major humor? Either way: awesome. Anyway, that's exactly what I though of when it comes to linking a child directory to its parent: won't you end up with a series of potential regressios? And what are you doing with all the files previously in that child directory--are they just loose in '/' ? Maybe I'm not picturing this correctly, which might be why I don't see the point.

@frony0: Hurd is not Linux, but I'm not sure how much that really matters. I'm kinda curious to see what the results might be.

Re: Symlink /usr to /

In FreeBSD, they put /home as a symlink to /usr/home, I'm not sure why, it's just FreeBSD.

I made that the other way around on my FreeBSD server, just because I can and like it better that way

I do know why FreeBSD does this: FreeBSD has a very clear separation of what is the "base system" and what is installed on top of that.Every package/port you install that's not part of the "base system", goes into /usr/local and it's subdirectories. For example binaries go into /usr/local/(s)bin and configuration files go into /usr/local/etc

So the majority of utilities and applications is nicely tucked away in /usr(/local) and only the fundamentals of the system can be found below it.I quite like it that way, feels very tidy.

Re: Symlink /usr to /

In FreeBSD, they put /home as a symlink to /usr/home, I'm not sure why, it's just FreeBSD.

I made that the other way around on my FreeBSD server, just because I can and like it better that way

I do know why FreeBSD does this: FreeBSD has a very clear separation of what is the "base system" and what is installed on top of that.Every package/port you install that's not part of the "base system", goes into /usr/local and it's subdirectories. For example binaries go into /usr/local/(s)bin and configuration files go into /usr/local/etc

So the majority of utilities and applications is nicely tucked away in /usr(/local) and only the fundamentals of the system can be found below it.I quite like it that way, feels very tidy.

It has a tight little kernel too. Memory management is even tight.The /lib directory doesn't even have that many files in it.It's a perfect fit for a server and performs well.

Anyhow, I'm not sure why you'd try to symlink /usr to /, because then it would cause endless recursion.

I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...Look ma, no mouse.

Re: Symlink /usr to /

You would have to deal with /lib being a symlink to /usr/lib as well, since it would create an infinite loop of symlinks.

'What can be asserted without evidence can also be dismissed without evidence.' - Christopher Hitchens'There's no such thing as addiction, there's only things that you enjoy doing more than life.' - Doug StanhopeGitHub Junkyard

Re: Symlink /usr to /

nomorewindows wrote:

In FreeBSD, they put /home as a symlink to /usr/home, I'm not sure why, it's just FreeBSD.

Because then you can have a separate (minimal) root partition and combine your /usr and /home partitions. Works really great, especially if you've got a limited amount of disk space and don't want to play guessing games about how much you're going to need to split between user data and application data.

Unfortunately when it comes to the directory structure the Linux Powers That Be immediately lose about 20 IQ points. Figuring out what software is necessary to get Linux up and running is apparently prohibitively difficult.

Re: Symlink /usr to /

Bellum wrote:

Unfortunately when it comes to the directory structure the Linux Powers That Be immediately lose about 20 IQ points. Figuring out what software is necessary to get Linux up and running is apparently prohibitively difficult.

I suspect this has to do with the different development styles between the two: Linux, unlike *BSD, isn't intended to be a tightly integrated operating system. Each distribution is run by people with different ideas about how things should operate. Seems there might be a little more consensus pushing toward the *BSD-style, simplified filesystem hierarchy, but I don't know how far that'll go (since I honestly don't pay close attention).

Re: Symlink /usr to /

FreeBSD has a very clear separation of what is the "base system" and what is installed on top of that.

I wish this could be taken further, to do the filesystem hierarchy completely from scratch in a user-friendly way that leaves historical idiosyncrasies behind.For example:

/system/kernel/ <-- what is now in /boot
/system/drivers/ <-- kernel modules, etc.
/system/devices/ <-- what is now in /dev
/system/processes/ <-- what is now in /proc
/system/media/ <-- what is now in /mnt or /media
/system/bin/ <-- base system binaries
/system/lib/ <-- base system libraries
/apps/bin/ <-- binaries that don't belong to the base system
/apps/lib/ <-- libraries that don't belong to the base system
/apps/data/ <-- what is now in /usr/share or /opt
/apps/config/ <-- what is now in /etc
/apps/headers/ <-- what is now in /usr/include
/apps/state/ <-- what is now in /var or /run
/users/<username>/ <-- home dir
/users/<username>/.apps/ <-- what is now in ~/.local or ~/.config
/users/<username>/.apps/.../ <-- same subdirs as the global /apps

Re: Symlink /usr to /

FreeBSD has a very clear separation of what is the "base system" and what is installed on top of that.

I wish this could be taken further, to do the filesystem hierarchy completely from scratch in a user-friendly way that leaves historical idiosyncrasies behind.For example:

/system/kernel/ <-- what is now in /boot
/system/drivers/ <-- kernel modules, etc.
/system/devices/ <-- what is now in /dev
/system/processes/ <-- what is now in /proc
/system/media/ <-- what is now in /mnt or /media
/system/bin/ <-- base system binaries
/system/lib/ <-- base system libraries
/apps/bin/ <-- binaries that don't belong to the base system
/apps/lib/ <-- libraries that don't belong to the base system
/apps/data/ <-- what is now in /usr/share or /opt
/apps/config/ <-- what is now in /etc
/apps/headers/ <-- what is now in /usr/include
/apps/state/ <-- what is now in /var or /run
/users/<username>/ <-- home dir
/users/<username>/.apps/ <-- what is now in ~/.local or ~/.config
/users/<username>/.apps/.../ <-- same subdirs as the global /apps

Not sure why the fisrt think that come to my mind when I see this hierrarchi is the OSX hierarchy....

but maybe a LFS or in a Gentoo box this can be more plausible for make comparing to the actual state of arch, you need rebuild gcc and glibc and initscript and systemd-tools and (many others thinks) all apps that spect a /lib -> /usr/lib an soo

but This can be funy

PD: Actually move bin to usr/bin and make the simlink break boot (initscript) tested in april 2012 by me

Re: Symlink /usr to /

I wish this could be taken further, to do the filesystem hierarchy completely from scratch in a user-friendly way that leaves historical idiosyncrasies behind.

GoboLinux did something like that. Wikipedia says the project is dormant.

Not really. They organized things in Windows-like fashion:

Wikipedia wrote:

each program in a GoboLinux system had its own subdirectory tree, where all of its files (including settings specific for that program) could be found. Thus, a program "Foo" had all of its specific files and libraries in "/Programs/Foo".