Understanding the bin, sbin, usr/bin , usr/sbin split

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

by sciurus • 14 years ago

857 151 14 years ago

lists.busybox.net

saulrh• 14 years ago

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.

bryanlarsen2• 14 years ago

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.

waitwhat3• 14 years ago

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

jrockway• 14 years ago

There are a variety of tools that live in /bin but are symlinked in /usr/bin, at least on my 10.04 LTS box:

  $ for f in /bin/*; do [ -e "/usr$f" ] && echo /usr$f; done;
  /usr/bin/dumpkeys
  /usr/bin/ksh
  /usr/bin/less
  /usr/bin/lessecho
  /usr/bin/lessfile
  /usr/bin/lesskey
  /usr/bin/lesspipe
  /usr/bin/loadkeys
  /usr/bin/mail
  /usr/bin/nano
  /usr/bin/tcsh
  /usr/bin/touch
  /usr/bin/which
  /usr/bin/zsh

This has the potential to blow something up during the installation procedure if it is not carefully crafted to realize that these files are the same and to ignore link's failure.

calloc3• 14 years ago

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

waitwhat3• 14 years ago

Presumably if FreeBSD went down the same path as Fedora, they could also change the default partition layout.

lanstein• 14 years ago

great sig:

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

drewcrawford• 14 years ago

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

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

farmdawgnation• 14 years ago

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.

ggchappell• 14 years ago

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• 14 years ago

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

rcthompson• 14 years ago

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.

agumonkey2• 14 years ago

Glorious.

More history bits like this please.

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

kryptiskt• 14 years ago

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.

aaronh3• 14 years ago

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.

agumonkey2• 14 years ago

Funny I just installed my first nixos yesterday. They indeed can move away from FHS even if they support it.

As said before GOBO does that too; there was a handful of distros at max.

aaronh3• 14 years ago

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

tmhedberg3• 14 years ago

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

hollerith2• 14 years ago

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

tmhedberg3• 14 years ago

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.

ta12121• 14 years ago

FYI, the linked post completely contradicts what you wrote.

gchpaco2• 14 years ago

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• 14 years ago

I wonder why rc still has $path in Plan9.

   term% echo $path
   . /bin

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

zobzu• 14 years ago

`quote'

rachelbythebay• 14 years ago

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.

nailer2• 14 years ago

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.

triffidhunter2• 14 years ago

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

a1k0n• 14 years ago

These limits are chiefly imposed by the BIOS (int 10h) calls available to a boot sector program (the 512 bytes of machine code you get inside the master boot record of a disk), and require a lot of cleverness to escape from.

triffidhunter2• 14 years ago

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.

aaronh3• 14 years ago

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• 14 years ago

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

sirclueless3• 14 years ago

That would break compatibility with a lot of existing scripts, which look for things in /bin, /lib, /usr/bin etc.

There are specific reasons why having a single mount point for all OS-provided binaries is a good idea, for example because maintaining a split that differs across distros and unixes is a maintenance nightmare. The main counterargument -- that it is desirable to have a minimally functional system without /usr mounted -- has been obsolete for years.

nailer2• 14 years ago

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.

ChuckMcM2• 14 years ago

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.

cbsmith2• 14 years ago

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

spitfire• 14 years ago

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

ChuckMcM2• 14 years ago

Actually /home was the first automounter map. Brent Callahagn at Sun had built this thing that, in conjunction with NIS (YP) or NIS+, could locate which server your home directory was on, and automatically mount it, decided that the automount point should be '/home' this was distinct from /usr/xx since /usr/xx was xx's home directory on this machine whereas /home/xx was xx's network home directory that would follow them around.

nknight2• 14 years ago

> The fact that Linux starts up differently is because Linux never was UNIX they are two different OSes, pretty much from the ground up.

No, it really has nothing to do with that at all. Linux can boot in pretty much the same way the genetic Unixes do, and in fact did for a long time. initrd and then initramfs came later and took some time to become widely used. Historically, Linux just mounted whatever filesystem the bootloader told it to as /, and executed init, which usually followed either a BSD or System V model, depending on distribution.

Linux evolved. Lots of things evolved. The filesystem layout, unfortunately, has merely become more chaotic.

calloc3• 14 years ago

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• 14 years ago

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

dredmorbius5• 14 years ago

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

calloc3• 14 years ago

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 softupdates on when using UFS2 since it is also the location where your kernel lives, along with rescue utilities and your main /bin. Nothing else.

The proposal as put forth is misguided (talking about Fedora's in this case) and I don't think that the system should be re-engineered just because that is the default use case these days. I remember when I first started using Linux and I created a separate, /boot, /, /usr, /home, and /tmp. Just because udev and others now fail to work correctly doesn't mean it isn't a good idea to keep those separate...

This is just going to cause more trouble, more fragmentation between unix/unix-like systems and Linux and it's various distributions.

bryanlarsen2• 14 years ago

Under the proposal, you can still keep /usr on it's own read-only filesystem. The difference is that it has to mounted in single-user mode.

pconf3• 14 years ago

Given today's disk capacities it rarely makes sense to create any partitions whatsoever within a disk other than for swap. Partitioning /usr, /var or anything else on the same disk only increases the chances of one or more partitions filling. Admins and OSs who create inter-disk partitions without an explicit need are operating on legacy superstition.

xenator• 14 years ago

Cargo cult driven development

emillon• 14 years ago

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

tomprince• 14 years ago

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

prewett2• 14 years ago

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" :)

dreamdu5t• 14 years ago

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.

justincormack2• 14 years ago

They start like that, like /proc did, and then get other stuff.

joeyh• 14 years ago

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.

peterwwillis• 14 years ago

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.

rlpb2• 14 years ago

> 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• 14 years ago

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?

sambeau2• 14 years ago

You'd need a bigger hard drive rather than more memory: dynamically shared libraries are paged-in to be used just as statically linked libraries are and are also paged-out when not in use, in just the same way.

Thus, to run a dynamically linked program you need to use the same amount of memory as you would a statically linked program.

However, if you are lucky (or have enough RAM), there is a chance that you won't have to load the page containing the library as it may already be in memory.

So there is a valid argument that to take full advantage of dynamically linked libraries you need more memory than for statically linked libraries.

barrkel2• 14 years ago

And the exactly corresponding security problem: when a problem is found in a library, you'll have to update all your applications, not just the library, otherwise you'll have an insecure system.

jerdfelt• 14 years ago

While not exactly what you are proposing, NixOS does something similar. It's not perfect, but it's far from hacky.

http://nixos.org/

comex2• 14 years ago

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.

vacri5• 14 years ago

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-Istence8• 14 years ago

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.

comex2• 14 years ago

I don't know if I'd prefer a non-portable way to do the same thing :)

Does 'ip' have a form that just prints the current addresses without all the surrounding cruft? That would be pretty useful for the occasional shell script.

drhowarddrfine• 14 years ago

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

jamesgeck0• 14 years ago

How does FreeBSD handle this?

X-Istence8• 14 years ago

man hier

http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...

dredmorbius5• 14 years ago

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• 14 years ago

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

cbsmith2• 14 years ago

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?

rbanffy• 14 years ago

I'd rather see /lib64 being collapsed into /lib. I never quite got why they have to exist. If you really need to support 32-bit legacy libraries on 64-bit machines (a big if) I'd much rather see a lib32 folder instead. Then it would be much cleaner to just kill it when it no longer makes sense.

vacri5• 14 years ago

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

DrCatbox2• 14 years ago

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

vacri5• 14 years ago

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

Osiris• 14 years ago

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.

Florin_Andrei• 14 years ago

I learned Linux pretty well before I learned Windows (I was an early adopter) and I felt equally baffled by Windows at a time. I felt nothing made sense. :)

contextfree• 14 years ago

I don't think either make any sense. I guess you could give Windows the nod for not really even making any pretense of making sense (my favorite detail is how 64-bit system files go in "System32" and 32-bit system files go in "SysWOW64"). OTOH while I never got the /bin /sbin /usr/bin /usr/sbin thing, I always vaguely assumed there was some deep reason behind it that I just didn't understand.

tikhonj• 14 years ago

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• 14 years ago

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.

tung• 14 years ago

For future reference, you can list all of the files associated with a package using this:

    dpkg-query --listfiles package-name

Or use Synaptic's 'Installed Files' tab in the package detail dialog.

mrb• 14 years ago

Or:

    dpkg -L package-name

shabble• 14 years ago

I often find myself looking for the opposite mapping; to which package does /usr/share/foo/bar.blob belong?

   $ dpkg --search /etc/apt/
   debconf, apt: /etc/apt

barrkel2• 14 years ago

I come from a DOS / Windows background, but now use Cygwin as my primary interface on Windows, and also regularly use Nexenta (Debian-flavoured Solaris) and Linux. I find the Unix way more understandable, particularly when things break.

Only the most simple of Windows applications get away with putting everything into a single folder under $PROGRAM_FILES. More usually, lots of stuff is in $COMMON_FILES, and may or may not be shared. And these common files are tied in to the program files via a giant complicated global variable, the registry; the program looks up ProgIDs and CLSIDs to instantiate COM objects, so the registry becomes a very sensitive source of failure, particularly when you have different versions of $COMMON_FILES that break the various linkages.

Furthermore, these days Windows Installer is often used to manage the Windows equivalent of packages. These too are sensitive to corruption; if you end up missing the MSI files from c:\windows\installer for one reason or another, you can easily get into a situation where you can't even reinstall an application cleanly, because the installer notices that you already have it installed, and tries to uninstall it first, but fails (usually quietly, in the middle of the installation, where the progress bar goes into reverse and at the end you get a cryptic and unhelpful error message). To fix this, you must venture forth once more into the registry, find out the cryptic (hex) name for the relevant package, and surgically excise it. Not even the MSI/MSP/etc. files have meaningful names. It's tortuous.

All that said, I by far prefer working in Windows to any other OS. If it had a faster performing yet fully POSIX compliant layer as well integrated as Cygwin (i.e. not off in its own parallel little world like SFU/SUA), it would be even better.

DrCatbox2• 14 years ago

"and a GUI is used to provide easy access to the application" How do you think the GUI finds the application? There is a PATH. Open up a cmd and type the name of any installed program.

1) Programs put themselves in various directories on my windows 7 machine, some are under \Program Files, some are under \Program filees (x86), some are \Programs and so on, variations and variations.

2) to locate a program you need to know its corporation, which people often dont know. There are setup.exe start.exe fireup.exe and run.exe and variations, which one should the user use to start the program?

3) all the applications components are not in a single place but are spread out over \Program-Files, \Windows\system, \windows\xx\xx and the registry at the least. Then they put stuff in \users\application data\ and \users\xx\applications or whatever.

You and many people dont understand where anything goes because unlike for Windows, GNU/Linux systems actually make sense and actually have a structure (that is different from windows) which you need to learn to operate the system, just as you learned to navigate the mess of windows.

rat87• 14 years ago

I thought the many of the shortcuts used fullpaths in windows I'm pretty sure not all of them can be accessed with name in cmd. Looking at the .desktop files under /usr/share/applications (ubuntu) most execute by name but some especially games(both third party and some gnome games) use fullpaths.

snowape2• 14 years ago

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?

sirclueless3• 14 years ago

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.

snowape2• 14 years ago

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

p0ckets• 14 years ago

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

Drorm• 14 years ago

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.

lispler• 14 years ago

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

cturner• 14 years ago

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• 14 years ago

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.

Symmetry• 14 years ago

Hard disk space isn't an issue, but internet bandwidth is. Also, being able to fit a fairly complete operating system on a CD.

Sorpigal4• 14 years ago

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?

Understanding the bin, sbin, usr/bin , usr/sbin split

Related Stories