
Understanding the bin, sbin, usr/bin , usr/sbin split - sciurus
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
======
ChuckMcM
Wow. As someone who was there (I know dating my self here) reading this is
kind of like that scene in Sleeper where the person from the future is trying
to understand artifacts from the past.

So during the BSD / System V merge (project Lulu at Sun) the /opt filesystem
was introduced as a way to keep 'packages' separate from 'system'. The
difference between /bin and /sbin was that sbin was 'static-bin' which is to
say everything in it was statically linked and could run without any libraries
being available.

The fact that Linux starts up differently is because Linux never was UNIX they
are two different OSes, pretty much from the ground up. They use similar
concepts, processes, file descriptors, Etc, but they are two different
species. FreeBSD on the other hand _is_ a derivative of UNIX and last time I
checked it started up in a similar way.

The lack of space on the RK05s was indeed the reason for the addition of
/usr/{lib, bin} and the general consensus at Sun and AT&T in the 80's was that
the root file system contained the system, and the /usr file system contained
stuff that was not-system.

AT&T (the guys that 'owned' UNIX) had some pretty detailed specifications
about what lived in what directory and why. It was a "BigDeal" (tm) to add a
new directory in the root file system so new directories, when they were
proposed, appeared under /usr. And once /opt existed it gave people free reign
to create their own trees. Early package managers would build
/opt/<package>/{bin/lib/share/man} and the downside was that ones path
variable got longer and longer, and there arguments about if there should be
more constraints on opt.

~~~
cbsmith
I also have no memory of /home even existing in roughly the first decade of
Unix's existence.

~~~
spitfire
home directories iirc, lived in /u (/usr these days)

~~~
bodyfour
Depended completely on the site. The first UNIX machine I worked on (ca
1985-1986) still was putting them in /usr for instance.

There were certainly sites that used /u for what is now commonly /home (or
/export/home on Solaris, /Users on OS/X, ...) This was not something that
predated "/usr" though: /usr was already added back in the early 1970s (the
linked article was correct about that, although it got many other details
wrong)

Basically /usr was originally _only_ for home directories (as the name
implies) Then it became the place for anything you didn't want to use the
precious space on the root filesystem for (hence /usr/bin popped up, and later
things like /usr/dict/words) Finally, it became so cluttered that people
started locating home directories elsewhere and now the name "/usr" is
completely unrelated to its actual purpose.

~~~
waitwhat
_/usr was originally only for home directories [...] /usr/bin popped up_

I wonder if this is the origin of the 'bin' user as well, because that's a
design decision that never seemed to make any sense.

------
tmhedberg
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 mounted, say, from a network share.
This is useful because then network admins can install software to the common
`/usr` share and make it immediately available to all machines which mount
that share.

The `/sbin` and `/usr/sbin` directories are for commands needed only by
administrators, which will not normally be used by regular users.

Most systems don't really require this separation, but it does make sense.
Perhaps the historical reason for doing it is no longer a factor, but that
doesn't mean it's perpetuated merely because of tradition.

[1] <http://www.pathname.com/fhs/pub/fhs-2.3.html>

~~~
gchpaco
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 get accepted into the main kernel because it
is at odds with how we see how a Unix system should behave.

It would be interesting to see a Linux distro that embraced this.

~~~
pmarin
I wonder why rc still has $path in Plan9.

    
    
       term% echo $path
       . /bin
    

What happen with Ape ports whom expect the path environment variable?

~~~
p9idf
Ape's execlp() tries first the program name passed to it (be it relative or
absolute), and if that fails it prepends "/bin/" and tries again. It ignores
environment variables entirely.†

Rc's path variable allows you to easily tell rc to check the current directory
when looking for programs to exec. Doing that with bind after each cd would be
clumsy. And if your working directory is a remote server, you can set path to
just /bin so that you aren't statting the remote directory before each exec.
Inferno's sh does use a path variable, but it is typically left unset and the
default (/dis .) is used.††

† See [http://plan9.bell-
labs.com/sources/plan9/sys/src/ape/lib/ap/...](http://plan9.bell-
labs.com/sources/plan9/sys/src/ape/lib/ap/plan9/execlp.c)

†† See /usr/inferno/appl/cmd/sh/sh.b:/^runexternal

------
drewcrawford
> I'm still waiting for /opt/local to show up...

Wait no longer: <http://guide.macports.org/>

~~~
farmdawgnation
If someone else didn't say this already, I was going to. Although, I've got to
admit that Fink's solution of /sw isn't much better.

------
Osiris
As someone who comes from a Windows (and further-back, OS/2) background, the
directory structure of -nix systems is baffling. It's really interesting to
read the background on why it came to be structured a certain way, but I feel
that the current structure doesn't jive with how we use computers in a modern
way. The structure seems to be optimized for single-file command-line based
applications and are not well suited to today's much more complicated GUI
applications.

Mac OS X, I think, has done a decent job of structuring the file system to be
more user friendly despite the -nix background.

Modern use cases typically revolve around either installation and use of
specific applications, often with dozens or hundreds of files needed, and data
storage. In Windows/Mac, applications (for the most part) are installed into
their own individual application folder and a GUI (as opposed to the PATH) is
used to provide easy access to the application. This makes it easy to 1) know
where to put a program you're installing, 2) know how to locate a program
after install, and 3) keeps all the application components in a single place
for easy move or removal.

In my somewhat limited experience with Linux, I find that the complicated
nature of the file system makes package management systems necessary to simply
keep track of where all the files are: executable in /usr/local/share/bin,
configuration files in /etc, libraries in /usr/lib, and I'm not sure where
non-binary resources of an application get stored.

I once installed my favorite browser (Opera) in Ubuntu. It didn't make a
desktop or Applcation menu icon for some reason, so I figured I'd just go make
a icon to point to it. It took quite a while to just figure out where the
executable was at.

This could very well be one of the reasons that many people find Linux on the
desktop difficult to use. They don't understand where anything goes.

I hope that one day one Linux distribution will at least step up and consider
restructuring the file system to be more friendly and straight forward and to
take advantage of the availability of long file names.

~~~
tikhonj
While the system is, indeed, complicated, there is a reason changing it has
not been Ubunutu's highest priority: almost all installation is done via the
package manager. I haven't used Ubunut much, but at least on Fedora 95% of
what I use is in the repositories and the rest is available as an rpm file
which installs itself. I have never had to worry about where to put executable
files.

Of course, I have installed things manually from source. But when I do, I only
install them locally in my home directory.

So the complexity _is_ there, I just haven't had to deal with it.

Also, I think that GUI-centrism is short-sighted, but that's another matter
altogether. In short: command-line tools are just as "modern" as GUI tools;
they're just harder to learn but tend to be more powerful.

~~~
VMG
As a user, this may well be tolerable. As soon as you start developing for
Ubuntu (or any other OS), these kinds of things will make you suffer.

------
calloc
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 different locations since mounting / means you have /usr/bin
as well.

I don't want a user being able to fill up the hard drive stopping me from
writing my logs, stopping me from logging in or various other things (yes,
i've filled up my / partition at one point and was unable to log in because
SSH was failing to log something or other). There are also security reasons
and being able to set various security flags on mount makes it easier to
secure a machine as well (such as noexec on /tmp and or /var).

~~~
rosser
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...)

~~~
dredmorbius
'Nix allows mounts at any arbitrary point in the filesystem hierarchy. While
you could symlink /var/tmp to /tmp, you could also dedicate a filesystem to
it. Given that the strict definitions differ (/var/tmp _does_ persist across
reboots, /tmp _may_ persist), you risk annoying/disapointing someone at some
point if you do otherwise.

~~~
justincormack
I am sure I have used systems with tmpfs /var/tmp.

~~~
mgedmin
In that case they were not FHS compliant.

------
aaronh
much of the original traditional unix file system hierarchy is basically
redundant and unnecessary in the modern age. for a good overview (from the
author of a linux distribution which departs completely from this tradition),
see:

[http://www.gobolinux.org/index.php?page=doc/articles/clueles...](http://www.gobolinux.org/index.php?page=doc/articles/clueless)

------
peterwwillis
Oh man... if only we had all statically-compiled Linux systems these days.
Sure it'd be a pain to deploy changes in libraries, but less dependency-
breaking consequences means you can push a patch to a single application
without testing a whole suite of dependent apps.

The really hacky solution to that seems to be building versioned packages in
versioned directory paths (e.g. "/opt/lib/db/4/4.2/4.2.52/libdb.so") and mess
with linker paths and create a sprawling tree of symlinks and wrappers for
weird use cases. With a custom package manager it works really well: run 6
conflicting versions of the same library and just build apps against the
library you know works, instead of fighting to get everything running on one
compatible library.

~~~
rlpb
> Oh man... if only we had all statically-compiled Linux systems these days.

Would you mind buying me a memory upgrade when this happens? I'll need one.

~~~
corysama
I honestly have no clue how much extra memory this would cost. I can see it
being a big issue on embedded systems. But, with 512 megs being considered
very low on modern desktop/server systems, I always thought the vast majority
of recent memory use was data rather than code.

Roughly how many processes are you running? Can anyone give a wild-assed guess
how much memory it take to boot and load gmail in FireFox on a statically
linked Linux?

~~~
yew
You shouldn't see _that_ much difference, at least on a system designed for
static linking (modern GNU/Linux is explicitly not such a system, see
<http://www.akkadia.org/drepper/no_static_linking.html>). There's still quite
a bit of potential for interprocess resource-sharing.

If you somehow managed to get a statically linked Firefox (I think it would be
very difficult, given the degree to which Drepper has abandoned the idea) on a
modern Linux system, though, the resource usage would admittedly probably be
quite impressive.

------
rachelbythebay
Let's not forget the whole partition split situation due to the 1024 cylinder
limitation. Once upon a time, you couldn't get to certain parts of the disk
from your bootloader (using BIOS calls), so you had to make something like a
tiny /boot which would hide < 1024.

This situation has only improved a little. There are still lingering bits of
it here and there, depending on how deeply you poke and which distribution you
have installed.

~~~
nailer
It annoys the hell out of me that people are still imposing the 486-era
1024Cyl and 8GB limitations in 2012.

ArchLinux, for example, still really, really wants you to make a /boot.

~~~
triffidhunter
There are plenty of good reasons to make a /boot. Encrypted laptops for
example.

~~~
vacri
I ran into problems when /boot was part of the larger xfs filesystem, so had
to create an ext3 /boot instead.

~~~
sirclueless
And in general, if you want to use any filesystem that your operating system
supports but your bootloader does not, you need a /boot

------
saulrh
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.

~~~
bryanlarsen
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.

~~~
waitwhat
While they're at it, they should move /usr/src somewhere else (/var/src?)

------
comex
It drives me crazy every time I'm on a Linux system and ifconfig is in /sbin,
and not on users' PATH, even though the no-argument form works perfectly fine
as a user.

~~~
vacri
use 'ip' instead, ifconfig is deprecated. 'ip addr show' is the simple
replacement for 'ifconfig', but ip is pretty flexible in what it can do.

~~~
X-Istence
Why? What exactly does ip bring to the table that ifconfig doesn't have? Why
am I required to learn YET another tool to do something that ifconfig has no
problems doing.

On linux to configure a wireless device you have iwconfig and ifconfig. And
you have to use each in a different order to get it work. Whereas in FreeBSD I
have ifconfig and it does all of it.

~~~
rlpb
Most newer advanced networking is unavailable in ifconfig. ifconfig and route
are now just there for backwards compatibility. The ip tool lets you do all of
what ifconfig and route can do, and more.

------
cturner
I think that the motivations for shared libraries was once valid but these
motivations are obsolete, and they're destructive. I think there's a lot to be
said for the simplicity and reliability of static linking.

There is an argument that it's nice to be able to upgrade libraries and have
everyone pick them up, but in practice that's mostly a myth because such
upgrades are vulnerable to nasty small failures. Another argument is that is
saves hard disk space - not an issue these days (perhaps it is in a small
number of embedded systems still).

Any good counters to that?

Update: thanks for response. I found the link to the Drepper article linked
elsewhere in this thread v informative also.

~~~
Derbasti
Well, consider GUI libraries like Qt, GTK or Cocoa. Cocoa in particular does
not have any concept of a user modifyable "theme" or "style". However, it
changes its looks with OS upgrades and all GUI applications change with it.

With static linking, that would clearly not happen.

Also, these libraries/frameworks are not exactly small, not even for todays
hard drives, so the de-duplication does make some sense (and that is not
factoring in the smaller size of SSDs). That said, I guess you could make this
into an argument for filesystem level deduplication instead of dynamic
linking.

------
lanstein
great sig:

GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem
Forever, and as welcome as New Coke.

------
ggchappell
The title isn't quite correct. He explains /bin vs. /usr/bin, but not /bin vs.
/sbin.

My understanding for the latter is that /bin is "normal stuff", while /sbin is
system maintenance. But, hey, maybe that split is actually there for obsolete
historical reasons, too. Does anyone know?

~~~
bebop
My understanding is that bin is used for programs that do not require super
user privileges, where as sbin programs do.

~~~
rcthompson
And the reason for splitting them is so that normal users don't have the
super-user programs in their $PATH, since they would be useless there. Of
course, this is arguably obsolete now since the advent of sudo, policykit, and
so on.

~~~
wmf
For some reason traceroute is in /sbin, but it works for normal users.
Probably another historical accident (did it used to require root?).

~~~
gchpaco
Conventional (that is, without capabilities) traceroute and ping were setuid
root because it there was no provision for emitting ICMP packets in the
network APIs and only root could assemble raw packets.

------
xenator
Cargo cult driven development

------
emillon
So, /usr really means "user", and the "Unix System Resources" acronym was put
together afterwards. Interesting, thank you !

~~~
tomprince
I don't think I have ever heard that acronym before. I don't think it is
common usage.

~~~
prewett
I've heard "user shared resources" which is similar. I'm glad "usr" meant
"user", though, I can go back to naming my home directories on Windows "usr"
instead of "home" :)

------
lispler
Everyone's talking about initramfs as if it would replace a self-contained /.
Have you ever been there? Usually all the relevant repair tools are missing
and the shell gives you a headache. Its the point where you usually give up,
walk into office and boot a rescue disc.

So no, it does not replace a working /.

------
dredmorbius
And why / /usr split still makes sense:

 _If it's needed to boot, it goes in root:_ boot images (including root
filesystem) can be initrds, bootp images, flash sticks, or other similar
tools. Maintaining the discipline of keeping what you need in / and what you
don't need to boot in /usr helps when you're trying to minimize boot images,
troubleshoot, and/or just simply keep things comprehnsible.

 _Different partitions can be mounted differently:_ There are still a few
things in the root FS which are written periodically, especially in /etc. By
contrast, /usr is largely static. They can be mounted writeable vs. read-only
(dittos /boot BTW). Root may require device permissions. Both require suid
(but /home doesn't). For various degrees of security and self-inflicted foot-
gunshot incidents, mounting with minimal permissions can be useful.

 _Not all bootloaders handle all filesystems and storage:_ Applies more to
/boot, but particularly for exotic / networked storage, ensuring that early-
stage bootstrapped filesystems are accessible with a minimum of fuss can be
useful.

 _The arguments from Fedora about the ability to manage a system from within
an initramfs are particularly amusing given RHEL's traditional use of a non-
interactive, script-only shell:_ Yes, that's right, you can't exit out of the
initramfs shell to do maintenance. Debian's 'dash' shell is not only smaller
than the RHEL equivalent, but supports interactive use. Go figure. (Apologies
if this has changed recently but it was true as of the past year or so).

 _Shared/network mount purposes:_ A read-only, shared /usr filesystem can be
used and accessed by multiple systems. Maintaining the root /usr split ensures
that local system commands (if necessary) can be provided independently of the
shared bits.

While the _origins_ of /bin vs. /usr/bin lie in what are now largely
irrelevant disk capacity constraints, there are a number of reasons why
maintaining the split continues to make sense. As has been noted, a fair bit
of hierarchy persistence is on account of differentiating between differently-
managed packages at different parts of the system. As the guy who gets to come
in, comprehend, rationalize, and clean up systems afterward, I can assure you
that a logical ordering and seggregation does help markedly.

For distros with a decent package management policy and toolset, there's no
particular problem to maintaining this. $PATH variables already make the end-
user impact essentially nil.

For those who wish to combine things, union mounts or symlinks can certainly
be used, again, with little or no end-user impact. For some embedded/small
systems this makes sense. There's no reason to force one-size-fits-all on
everyone, however.

I'm also generally opposed to arbitrarily adding top-level directory trees.
The naming rarely stays consistent over time (business unit / institutional
name changes are notorious). And it tends to complicate matters especially
concerning backups and where essential local data lives.

Tempest in a teapot.

~~~
sciurus
For those who haven't seen the proposal for the / /usr merge:

"Fedora (and other distributions) have begun work on getting rid of the
separation of /bin and /usr/bin, as well as /sbin and /usr/sbin, /lib and
/usr/lib, and /lib64 and /usr/lib64. All files from the directories in / will
be merged into their respective counterparts in /usr, and symlinks for the old
directories will be created instead"

[http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...](http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge)

~~~
cbsmith
Thanks. These seems like one of those things that while it might be sensible,
wouldn't provide much of a win, so why bother with the mess?

~~~
el_presidente
Probably because fedora has a six month release cycle and they feel the need
to make some kind of revolutionary change on every release.

Of course, /bin will never be removed since there are millions of scripts
depending on /bin/sh in the wild. So they'll basically end up having to
maintain this symlink spaghetti for a long time.

~~~
aangjie
I agree with that symlink spaghetti for a long time comment.. It seems harsh
to fedora to say they feel a need for a revolution.. i really don't follow
release cycles/linux versions... close enough.. but my upgrade experiences so
far(Fedora 8-13 vs Ubuntu 8-11.10) indicate it's ubuntu that feel a need to
make revolutionary change.. i.e: to say, i have gone wtf more times searching
for some custom setting on ubuntu menu's than fedora's

------
snowape
Why did the Fedora team choose to move /bin -> /usr/bin etc instead of moving
stuff out of usr into root (/usr/bin -> /bin)? What is the point of having a
usr directory when there is no separation between stuff in usr and stuff in
root?

~~~
sirclueless
If you want to mount system directories read-only or over a network, it's
easier if you put them all in a single mount point. This way you can just
mount /usr, instead of having to mount /bin, /lib, and /lib64 this way.

~~~
snowape
So /usr is now the directory for where all programs installed by the system or
package manager gets installed. That actually does make sense.

------
agumonkey
Glorious.

More history bits like this please.

At the same time, makes you think about dropping FHS .. yeah I said it.

~~~
kryptiskt
A distribution that does just that is NixOS (<http://nixos.org/nixos/>). It
has to, because it's purely functional (new stuff shouldn't overwrite any of
the old stuff) and it has to support several different versions of the same
package being installed at the same time.

It is awesome, especially the easy rollback and that you can specify an entire
system with a recipe. Still, it feels strange for us who are used to
mainstream Unix systems.

~~~
aaronh
GoboLinux does it too.

And for that matter, another "unixy" OS uses "bundles" to keep all of an apps
files together instead of splattering them all over the OS: Mac OS X.

~~~
X-Istence
OS X isn't just "unixy", Snow Leopard is UNIX certified...

------
p0ckets
/opt/local is already used (by MacPorts).

------
triffidhunter
The Fedora changes are bikeshedding. They start with wanting to change
something, and then find a justification. Why not just put all the executables
files in /Program Files/?

All this to save a few bytes in $PATH, to avoid problems with systemd, and to
avoid fixing udev.

~~~
aaronh
why not put all .txt files in /txt? we have .../man for man pages, .../lib for
libs, .../src or source and .../include for C includes after all.

~~~
im3w1l
I know, I know! Why not let the extension indicate which package a file
belongs to? Then we could have /txt/readme.GTK

------
nailer
Way, way too long. Go read the FHS:

\- If it's needed to boot the system, it belongs in /

\- Binaries for normal users are in bin, system (i.e., root user only)
binaries are in sbin

That's all.

------
Sorpigal
How about we stop mincing around and make some gut-wrenching modifications? As
long as you're going to go through all the trouble of shuffling things around
let's kill more than one bird at a time. Let's not worry about legacy needs,
let's just worry about current needs. We no longer care about disk space and
(for the most part) things can be tab-completed, so there's little reason to
keep anything small if there's a down side.

What's attractive about /usr? A lot of things, but mostly: single export-
point, possible to separately mount (from a network, read only, whatever),
logically nice to have all those directories not polluting /.

I propose that / should contain the following directories:

/cfg/ /home/ /local/ /mnt/ /system/ /tmp/

You would mv /boot /dev /bin /sbin /var /root /proc /sys /usr /lib /run
/system, then mv /opt /local

/etc/ is renamed /cfg/ just because I can and left in / because some things
really are global configuration (and we can't be mounting /etc ro all the
time).

But don't stop there, because now /system/ is a mess. You obviously still
can't treat /system as /usr because e.g. /dev is there, so put /dev, /proc and
/sys under /system/kernel, because these things are figments of the kernel's
imagination anyway. Under /system/boot/ throw in a directory for your
bootloader, initrd and whatnot and one for any statically-linked binaries you
have, if you have any (hey, it's optional). No need for a lib, because it's
all static or in the initrd. Just because I'm a mean curmugeon who hates
greybeards and love n00bs, let's mv /system/var /system/data. Inside
/system/usr let's merge files from games, bin and sbin into bin and get rid of
the empty directories. Then mv /system/usr/local/ /local/usr/.

Speaking of /local/, it'd have two subdirs: /local/opt/ and /local/usr/. The
former would contain an opt-style directory hierarchy and the latter would be
like /system/usr, only with the purpose of the FHS /usr/local. Okay, so the
/local/ stuff isn't to be found in an exported /system/usr/, but /local/ is
just a fetish of mine. You could put it in /system/usr/, too. And yes, /system
and part of its structure is required to be on / during boot. So sue me.

Now you have:

/cfg/ /home/ /local/ /local/usr/ /local/opt/ /mnt/ /system/ /system/data/
/system/boot/loader/ /system/boot/sbin/ /system/kernel/dev/
/system/kernel/proc/ /system/kernel/sys/ /system/root/ /system/run/
/system/usr/bin/ /system/usr/lib/ /system/usr/share/ /tmp/

Now you have a tree for homes, a tree for the whole system, which has a splits
where you might need them for partitioning and exporting, a tree for
configuration, which also has a name users can understand, a tree for non-
packaged software, which allows for both crazy-opt style layout and
traditional, and you have your global tmp and temporary mount point root.

Did I leave anyone out?

------
vacri
I've been liking the new location /srv, where you stick things that are custom
to that machine. No more trying to guess where the previous admin thought
files should go (/usr/share? /usr/local? /usr/foo?).

[http://www.linuxtopia.org/online_books/linux_beginner_books/...](http://www.linuxtopia.org/online_books/linux_beginner_books/linux_filesystem/srv.html)

~~~
DrCatbox
You dont stick things that are custom to that machine in /srv, thats not what
the article you linked to says.

Its for serving using various services, so you would have /srv/http /srv/ftp
and so on, you dont put packages/programs into /srv

~~~
vacri
Looks like I might be misusing it then. I've been migrating some old
spaghettied servers to single-use VMs recently, each server has had almost
half a dozen admins all with their own weird ideas. The idea of saying 'hey,
all the custom stuff is in this directory' for future admins is seductive.
Basically I'm replacing half a dozen admins' peculiarities with one admin's
peculiarity...

------
dreamdu5t
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.

~~~
joeyh
Except for /dev/MAKEDEV (required to be there by the FHS and for hysterical
raisins). And then there was all the crap udev used to put in /dev/.udev/,
which has thankfully migrated to /run.

------
drhowarddrfine
Reason #9364 why I am soooo glad I stick with FreeBSD.

~~~
jamesgeck0
How does FreeBSD handle this?

~~~
X-Istence
man hier

[http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...](http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html)

------
Drorm
This email is clearly wrong. Anyone, who knows anything about Unix knows that
the world didn't start till 1970, so all this stuff about things happening in
1969 is clearly impossible.

