The FHS has been poorly done for years. For e.g. where is the canonical place for a Web vhost root? /srv/www? /srv/web? /var/www?
I made something not dissimilar, which lists all the man page sections for a given term with a brief description, to help you pick the right section.
I was wondering recently if there could be any role for something like Docker in an experimental/radically different Linux distro.
Under stali, would these be in /svc?
One thing I don't like about its filesystem is its insistence that all binaries go into /bin. As a user, I greatly appreciate the concept of having some sort of /local directory to distinguish between files (or just executable in this case) which the end user installed and which are part of the distribution. If you abandon the idea that /bin has no subdirecories, then I could see /bin/local as a viable alternative (although I think I would still prefer a /local folder where that had /local/bin, /local/etc ...).
One of my pet peeves when I work on clusters before I even mess with the fstab or ufw is always deleting this folder.
Debian Policy makes this more explicit by noting that it defines what packages (and hence: package maintainers) must do, may do, and must not do.
Among the latter: other than creating some of the hierarchy under /usr/local, packages may not delete content under this tree. That is for local system management.
Similarly, /opt as a location where third-party vendors can install their crap, excuse me, packages, is a pretty well established standard. Note too that you can offer the filesystem view independent of the underlying storage view, whether by symlinks (e.g., ln -s /usr/local/opt /opt), union mounts, or other means.
Any parts of the filesystem you create outside the defined standards are pretty much yours to worry about, though I've also got extreme reservations about polluting the root filesystem excessively. Better to create a structure under /usr/local or elsewhere (if for no other reason: it simplifies backups). This is a practice often respected in the breach in reality, however....
Thank you for posting this link! I never knew why the paths were what they were, I could only explain what to expect in each.
Still sucks dealing with spaces when it comes to command processes like ffmpeg -i <no_tab>...but awesome for cd'ing or ls'ing!
> The reason that depending on PATH is not considered good practice is that the script can make no assumptions about the content of the PATH environment variable, breaking the "sequential dependency model" of binaries where
1. /bin contains the executables needed at boot time;
2. /usr/bin contains the other executables used by the OS installation;
3. /usr/local/bin contains executables installed by the system administrator that are not part of the base OS.
4. ~/bin contains the user's own executables.
> Each level should not assume the existence of binaries later in the sequence, which are more "application" but may rely on binaries earlier, which are more "fundament". And the PATH variable tends to run from applicationy to fundamental, which is the opposite direction to the natural dependency above.
> To illustrate the problem, ask yourself what happens if a script in ~/bin invokes an script in /usr/local/bin that invokes Ruby? Should that script depend on the OS installed version at /usr/bin/ruby, or on the personal copy the user happens to have at ~/bin/ruby? PATH searching gives the unpredictable semantics associated with the latter (maybe ~/bin/ruby is a broken symbolic link), while baking in the path to #! gives the former.
On the Unix&Linux SX - http://unix.stackexchange.com/a/11917/5197
So don't put spaces in path names, it's a bitch to work with.
Since alot of the clusters I work on are web servers or parallel computing servers (that still have access through to a network), I like to clear out any dirs and files that aren't needed, mount ro access to any dirs that shouldn't be written to, and do every other thing I do to lock down the server.
It's helped me before detect unauthorized files that contained malicious code.
[1]: https://www.archlinux.org/news/binaries-move-to-usrbin-requi... [2]: https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc...
I expect there will be people who reply to this comment to argue it should be "E-T-C" or "Et Cetera". You can ignore those people; they probably say "exclamation mark" instead of "bang".
I know the old Bell manuals actually spelled out "et cetera" long hand in places, but still, any time i hear someone say that out loud meaning the directory, i have a (wholy irrational) cringe reaction!
This is one of those "jif" v. "gif" holy war issues. (Maybe "etc" is a minor skirmish rather than a full blown war.)
Says you. I say 'ek' and my pronunciation is just as valid.
> You can ignore those people; they probably say "exclamation mark" instead of "bang".
Bah. Everyone knows that's a shriek. You probably put sugar in your porridge.
A poor excuse for advancing illiteracy in both the linguistic and operational spaces. It's faster to say, but you've also made it harder for the lay person to understand. This sort of user hostility is a general problem in Linux; we are long since liberated from the days of unreliable teletype links, and the fetish for 3-letter contractions and abbreviated commands like cp and mv (instead of copy and move) does absolutely nothing to foster computer literacy.
20120128 http://lists.busybox.net/pipermail/busybox/2010-December/074... Understanding the bin, sbin, usr/bin, usr/sbin split
Ohhh THATS why! Taking the meaning of 'legacy' to new extremes. This very detail, is one of the prime reasons I refuse to use Linux. I have always thought the categorization of folder usage was insane. Now I know WHY it's insane.
20030430 http://www.osnews.com/story/3431 http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page... http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page... If I Had My Own Distro (Linux)
Some machines only have python 2.4 and others 2.7. So /usr/local/python is not a good answer for python scripts in /project/x/bin (network mapped). Worse someone puts gnu coreutils in /project/x/bin, but for sparc architectures, so PATH becomes touchy if you're on a x86 server.
I've resorted to having my bashrc build my path by scanning uname for architecture/platform and conditionally adding path entries to these network folders.
All organization scripts on network drives now have caveats "This only works on linux x86 servers" or "This only works on server X". Not because it can't work elsewhere, but because the PATH and #! management problems when the dependencies are installed at different places on different servers.
Blegh </rant>
Passwd = "password" /usr = "slash user"
If someone doesn't understand you, then you explain and move on. But the industry has based around this jargon and removing/redefining it just creates separate standards.
Also it doesn't take /run into account (for which many distros had a hack before settling on /run).
/run has been widely adopted, but the /usr merge is a bit more controversial. I expect this will become another factor in the growing bifurcation of Linux into Red Hat-style distros and Ubuntu-style distros (see also systemd vs. upstart, Wayland vs. Mir, etc.) with a few "traditionalist" distributions like Slackware on the sidelines. As a Debian user, I expect that the next few years will be...interesting.
All of these "solutions" fail somewhere because some system does it differently. Why can't one just use #!bash or #!python and have the system just look on the path for it?
https://www.archlinux.org/news/binaries-move-to-usrbin-requi...
Minor details (ahem capitalized directory names ahem) aside, having a designated place for each distinct software release (/Programs/Bash/3.0/bin/) in my personal opinion looks more practical than having a separate database of package-installed files.
Unfortunately, the projects seems to be dead or nearly dead.
#!/bin/sh
file=`env PATH=$THIS_ARCHITECURES_PREFERRED_PATH /usr/bin/which $1`
shift; exit "$file" "$@"
It's akin to debating Einstein on physics by belittling his accent.
HIER(7) FreeBSD Miscellaneous Information Manual HIER(7)
NAME
hier — layout of file systemsGobolinux: http://www.gobolinux.org/
Also, many of the basic tools have a -0 option which uses the null character to replace many uses of space. Still far from an adequate solution though.
For example, when I say "etsy" out loud, it makes it clear that I'm referring to the actual directory and not just saying "and other things".
It's a way to avoid a bad "who's on first" routine.
To take an example from further down in this thread: Likewise, in print, using cp and mv make it clear these specific things rather than the abstract concepts of copy and move.
Not really a big difference in meaning or tone, if you ask me.
Now, if Dennis told you it was pronounced etsy, you would have a point.
If you look up "etc unix pronounciation", while there is a lot of bickering, I still think "etsy" is the slight majority among old timers. I will admit that this usage seems to have faded.
I spent some time trying to find video of any of the original Bell Labs Unix team actually saying the directory out loud--I couldn't find any. I'm going to keep searching, but they honestly seem to go out of their way to avoid it. I did find some fascinating videos along the way [1].
To my chagrin, there are a few oblique text references on the web that say indicate that within Bell Labs, it was pronounced "etcetera". But I'd still like a canonical reference.
[1] Like this video from 1982, including Kernighan, Thompson, Ritchie, and Aho. http://youtu.be/tc4ROCJYbm0
[1] Ha!
Also, one thing I think is needed right now is an easy way for users to install programs in $HOME, only for themselves (not system-wide) and without root access. On most distros (AFAIK), you can only do "sudo apt-get install PKG" (or something similar) which installs the package system-wide for everyone, or you can go through the whole configure&&make fun to install a program in your home directory. I'd like to see something like $HOME/bin and $HOME/lib where users can auto-install binaries that only they use.
It is a school exercise at least in some European countries. It is a syntactic transformation of the sentence. Depending on the verb and other factors, the transformation preserves meaning, but sometimes it brings up a subject which was not clear in the original sentence in passive voice.
Thus, Numeromancer is suggesting a way for you to reflect on the scope of authority by using a syntactic transformation.
Commands generally reside in directory /bin
(for binary programs). Some programs also
reside in /usr/bin, to save space in /bin.
Here is the manual:
> Not enough people know this, but when you say "etc" out loud in reference to the directory, I suppose it should sound like "etsy".
The passive voice, combined with the opening phrase, gives the false appearance that the subject is the pronunciation of ‘/etc’, when the true subject is you. I put it the way I did because it is a good exercise and because I didn't want it to seem impetuous.
If you're saying that I was being passive aggressive, that's my bad, because I was aiming for over-the-top bravado and didn't go big enough for it to be funny, I guess. http://dilbert.com/strips/comic/1995-06-24/