51–60 of 158 posts
Directories that are based on objective criteria don't have this problem. For example /dev is defined by objective criteria, and thus there's not much argument to what goes into /dev. We should only have core directory structure defined by objective criteria.
Earlier quoted context omitted.
I know about FHS and the rationale FHS uses for the continued existence of /usr, I just do not agree with it (nor with the existence of /usr/share).
I'm curious, what is your opposition to `/usr/share`? It seems quite logical to me as a place to store non-executable, read-only, shareable data like man pages and other documentation, fonts, keymaps, color profiles, game data, etc. Where else would you propose to store this sort of thing? I can't really think of a different location in the hierarchy that would make sense.
Now suppose you are an admin for a network in which the numerical software foocode is a big deal. the software contains a large read-only database of numbers, which according to the logic of the FHS goes into /usr/share/foocode/. Now suppose that some machines upgrade to a new version of foocode which for performance reasons stores integers in some specialized format, not the ones-complement format that has become something of a standard. So now, if we continue to apply the logic that motivated the creation of /usr/share in the first place, we need a place to put numbers of the new format so that they are kept separate from the numbers in the old format. Thus /usr/share/ones_complement/foocode and /usr/share/new_format/foocode are created. Suppose further that yet another version of foocode is released, and again that some machines are upgraded to it and some are not. This new version introduces a new, more performant format for the database in which the numbers are stored. Well, if the old format is called the 'hyperbolic' format and the new format is called the 'elliptical' format, then the logic that led us to create /usr/share leads us to create /usr/share/ones_complement/hyperbolic/foocode, /usr/share/ones_complement/elliptical/foocode, /usr/share/new_format/hyperbolic/foocode and /usr/share/new_format/elliptical/foocode. My point is that at some point you need to move to some way of assigning 'attributes' (and "read-only, shareable, non-executable" would be an example of an attribute) to files in some way other than putting those attributes in the name of the file. It would have been better for that point to have arrived before the FHS caused programmers around the world to have to type /usr/share/emacs/23.3/lisp 500 million times when /emacs/23.3/lisp would have done.
What would this other way of assigning attributes to files be? A detailed explanation would be too many words for a HN comment. For the specific problems mentioned in this comment, namely, centrally-adminned file servers, you probably make your net-mount command more complicated like they did in Plan 9.
ADDED. div and mod are well know numeric functions, right? The mere fact that some group of people would like some convenient way to refer to all the numeric functions does not justify requiring every programmer to write numeric/div and numeric/mod (or numeric :: div and numeric :: mod) every time they want to use or refer to one of those functions. I say the same argument applies to /usr and /usr/share.
Earlier quoted context omitted.
Every one of those paths I mentioned are paths I have encountered during my use of various unix distributions since 1991 (Solaris was the worst offender). And that's not even the complete list. I gave up trying to predict where software would install to a long time ago. My point is that what "makes sense" is subjective. Each developer/distro manager who made one of those paths thought to himself "it makes perfect sen…
Your encountering them doesn't make them part of FHS. Their being included in FHS does.
Reason #9364 why I am soooo glad I stick with FreeBSD.
There's an interesting piece of advice at the bottom of this post - the author symlinks /bin, /sbin, and /lib to /usr/whatever. Anybody else have an opinion on that practice? It's kind of unnecessary, but it also doesn't break anything.
It would break FreeBSD's single user mode when using the defaults during installation for partitioning. FreeBSD's default install creates: /, /usr, /tmp, /var and swap space. When you boot in single-user mode all you get is / and nothing else. If everything was in /usr you wouldn't be able to mount /usr ... :P
I still have various partitions: /, /var, /usr, and /tmp (on a single slice). When I am in single user mode the only binaries I have available are in /bin. Unless I mount /usr that is all I have access to, so the split still makes perfect sense. A lot of Linux distributions by default suggest using the entire disk and creating a single partition named /. In that case it doesn't make sense to have the various differen…
If this proposal ends up being widely adopted, you're only losing the ability to keep /usr on its own filesystem. You still can (and very much should) keep /var and /tmp on dedicated volumes. (And should probably also symlink /var/tmp to /tmp, so that you don't have a world-writable directory on the filesystem you want to keep safe for writing logs to...)
The FHS (Filesystem Hierarchy Standard) [1] is the go-to reference for this sort of thing. It explains that `/bin` is for binaries that are essential before other file systems are mounted (e.g. in single user mode), and `/usr/bin` is for "most user commands" (all others). This allows you to keep a minimal local filesystem containing only the binaries needed for init to get the system running, and then `/usr` can be m…
The central thing about all these conventions is they developed in the absence of good union mounts. In Plan 9 there is no $PATH: all such things are bound into /bin. This works both because Plan 9 has very good union mounts, but also because those union mounts can be localized to a specific process and as a result are user accessible. I seem to recall some work was done to make this possible on Linux but It didn't g…
term% echo $path
. /bin
There's an interesting piece of advice at the bottom of this post - the author symlinks /bin, /sbin, and /lib to /usr/whatever. Anybody else have an opinion on that practice? It's kind of unnecessary, but it also doesn't break anything.
That's an over simplified version of what the next Fedora is going to be doing. http://fedoraproject.org/wiki/Features/UsrMove The Fedora move is why this link got posted and is getting upvotes.
Earlier quoted context omitted.
The central thing about all these conventions is they developed in the absence of good union mounts. In Plan 9 there is no $PATH: all such things are bound into /bin. This works both because Plan 9 has very good union mounts, but also because those union mounts can be localized to a specific process and as a result are user accessible. I seem to recall some work was done to make this possible on Linux but It didn't g…
I wonder why rc still has $path in Plan9. term% echo $path . /bin What happen with Ape ports whom expect the path environment variable?
Inferno's shell doesn't use a $path variable.
Earlier quoted context omitted.
If this proposal ends up being widely adopted, you're only losing the ability to keep /usr on its own filesystem. You still can (and very much should) keep /var and /tmp on dedicated volumes. (And should probably also symlink /var/tmp to /tmp, so that you don't have a world-writable directory on the filesystem you want to keep safe for writing logs to...)
Except that /usr is where /usr/local lives (all software installed through the FreeBSD ports tree) and I don't want that on my / partition, so now I have to create a partition just for /usr/local? How about the various other files under /usr, they now have to be moved to / as well? On FreeBSD /usr also houses /usr/home. /home/ is a symlink to /usr/home! / on a FreeBSD system is generally kept small. It doesn't have s…
FreeBSD recommends softupdates on all filesystems, including /.
Also, the LSB doesn't really apply much to the BSD's.