Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lists.busybox.net

Post reply on HN
Print view View original

141–150 of 158 posts

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

#141

Post by pconf »

kstenerud wrote: post #27
tmhedberg wrote: post #24

Earlier quoted context omitted.

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.

Because everyone's idea of what "makes sense" is different. Thus: /bin /usr/bin /usr/share/bin /usr/share/local/bin /usr/local/bin /usr/local/share/bin /opt/bin /opt/some/clever/path/system/bin Followed by hacky symlinks so that programs can find what they're looking for in /usr/local/share/lib/x, which really resides in /usr/share/lib/x or maybe /var/lib or maybe /var/local/lib or maybe just /lib because it's consid…

I really like the way FreeBSD separates system and third party software, the latter typically being installed to /usr/local.

Linux' failure to differentiate between system and non-system binaries is IMO one of it's worst features.

Neither FreeBSD nor Linux accommodate network mounted NFS mounted applications as well as SunOS did so successfully by the late '80s. This is probably due to the corrupting influence of Unix and Linux engineers who came from MS Windows backgrounds. Windows admins waste countless hours having to install software locally on every machine. Sad that only Solaris provides for a standard network-based application filesystem. Odd too that Solaris is home to the single most ill-thought-out non-system directory, /opt.

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

#142

Post by pconf »

rosser wrote: post #34
calloc wrote: post #23

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

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.

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

#143

Post by ars »

__david__ wrote: post #110
shabble wrote: post #108

Earlier quoted context omitted.

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

I prefer "apt-file search" which is much faster than "dpkg -S" at the cost of some disk space and having to periodically do "apt-file update".

apt-file search is [also] for uninstalled packages. If all you care about are packages actually installed use dlocate

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

#144

Post by prewett »

pconf wrote: post #142
rosser wrote: post #34

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

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.

If /tmp fills up, things start mysteriously not working (a surprising number of things create temp files, including things you wouldn't expect to), so it needs to be on a partition that won't fill up. I usually put it in its own partition, so that accidentally filling up / won't bring cause mysterious problems.

/var should go on a separate partition so that the log files don't fill up the partition that /tmp is on. A server can easily generate large log files quickly, and it would be unfortunate if that caused the server to fail in weird ways at inconvenient times.

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

#145

Post by prewett »

tomprince wrote: post #136
emillon wrote: post #29

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

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

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

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

#146

Post by rat87 »

DrCatbox wrote: post #115
Osiris wrote: post #87

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 suite…

"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…

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.

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

#147

Post by mgedmin »

justincormack wrote: post #47
dredmorbius wrote: post #43

Earlier quoted context omitted.

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

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

In that case they were not FHS compliant.

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

#148

Post by rbanffy »

sciurus wrote: post #46
dredmorbius wrote: post #39

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…

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

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.

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

#149

Post by [deleted] »

tikhonj wrote: post #91
Osiris wrote: post #87

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 suite…

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 thi…

[deleted]

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

#150

Post by im3w1l »

aaronh wrote: post #49
triffidhunter wrote: post #15

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.

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.

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