Ultraman wrote: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.
Oh, God no!
]]>sas wrote: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:
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".
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.
]]>Ultraman wrote: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
]]>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
You would have to deal with /lib being a symlink to /usr/lib as well, since it would create an infinite loop of symlinks.
True. The /lib folder can just be made a folder again. Otherwise I don't see how the possible recursion in any way affects how the system would function, what program would look for usr in /usr?
NB: I also learned today that Solaris and Fedora have done something along these lines; see http://fedoraproject.org/wiki/Features/UsrMove or (god forbid) http://www.freedesktop.org/wiki/Softwar … heUsrMerge (although they did the reverse, instead of my lazy solution)
]]>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).
]]>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.
]]>nomorewindows wrote: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/etcSo 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.
]]>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.
@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.
Instead of merging everything into /usr, they chose to merge /usr in the root, that's all. The result would be these directories in /:
bin, boot, dev, doc, etc, home, i486-mingw32, include, lib, lib32, lib64, libexec, local, lost+found, media, mnt, opt, proc, root, run, sbin, share, src, srv, sys, tmp, usr, var
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.
]]>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...
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
]]>