Linked by Thom Holwerda on Fri 25th May 2012 14:55 UTC
Thread beginning with comment 519711
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by kurkosdr
by tidux on Tue 29th May 2012 03:51
in reply to "RE[2]: Comment by kurkosdr"
Um... you don't have to put all the home directories on one disk. Nobody said you absolutely have to assign $HOME values within /home, although it is easiest.
http://sprunge.us/BUCV
That's the output of "df -h" on sdf.org, a NetBSD shell provider I use. My home directory isn't in /home at all, but in /arpa/tz.
RE[3]: Comment by kurkosdr
by Doc Pain on Tue 29th May 2012 04:52
in reply to "RE[2]: Comment by kurkosdr"
I shouldn't have to have to store all /home/ directories on one disk for example.
You don't have to. Home directories can be spread across many disks, they can even be placed on "no (local) disk" (see NFS home).
A bigger problem for me is the standard linux directory hierarchy. I prefer an application centric hierarchy rather than one where everything is dumped together in the big /usr/bin soup pot.
True, there are options to do it differently. For example, PC-BSD utilizes a concept as what you are suggesting. Still this may have disadvantages, e. g. doubled and tripled libraries. But as hard disk space is cheap, nobody sees a problem in this.
However, the traditional layout has advantages and intended baheviour, even if it's hard to see this on modern Linux where, as you said, things tend to be thrown into one pot.
Allow me to point you to the FreeBSD file system hierarchy documentation, "man 7 hier", for a more detailed description about what the different directories should be used for:
http://www.freebsd.org/cgi/man.cgi?query=hier&sektion=7
In addition to them, some systems even use /opt (directory initially coming from Solaris, if I remember correctly) to manually manage software that is not handled by the system's software magement facilities, so avoiding problems with standard tools.
RE[4]: Comment by kurkosdr
by tidux on Tue 29th May 2012 10:50
in reply to "RE[3]: Comment by kurkosdr"
RE[3]: Comment by kurkosdr
by Vanders on Tue 29th May 2012 10:38
in reply to "RE[2]: Comment by kurkosdr"
For me, linux mounting is a nice abstraction, but sometimes I'm put off by the lack of overlays in the mainline kernel. I shouldn't have to have to store all /home/ directories on one disk for example. Overlooking several caveats, we can mimic overlays manually using symlinks, but linux's mount capabilities are occasionally inadequate.
Linux has supported bind mounts since kernel 2.4.0




Member since:
2011-01-28
tidux,
"Wow, you really don't understand the Unix filesystem."
I don't think that the OP's opinion demonstrates any lack of understanding. For some *nix filesystems can seem cumbersome and it's a valid opinion.
For me, linux mounting is a nice abstraction, but sometimes I'm put off by the lack of overlays in the mainline kernel. I shouldn't have to have to store all /home/ directories on one disk for example. Overlooking several caveats, we can mimic overlays manually using symlinks, but linux's mount capabilities are occasionally inadequate.
A bigger problem for me is the standard linux directory hierarchy. I prefer an application centric hierarchy rather than one where everything is dumped together in the big /usr/bin soup pot.