Skip to main content

Ralsina.Me — Roberto Alsina's website

UNIX stuff that makes no sense ( the rant)

First of al­l, I love Lin­ux. I have used it ex­clu­sive­ly since about 1994 (yeah, the last Win­dows I ac­tu­al­ly used for re­al was WfW 3.11).

Let's see how it makes no sense.

The Bin

Your sys­tem has /bin /s­bin /us­r/bin /us­r/s­bin /us­r/lo­cal/bin /us­r/lo­cal/s­bin 6 dif­fer­ent bi­na­ry lo­ca­tion­s.

What sense does it make to split bin and sbin? It on­ly makes it hard­er for reg­u­lar users to use tools the can need, like net­stat and if­con­fig.

As for /bin and /us­r/bin, it makes lit­tle more sense, if at al­l. Sure, put a ba­sic, func­tion­al sys­tem out­side /us­r, be­cause /usr can be a net­work FS. Well, who does that?

I mean, I have seen al­l-lo­cal and al­l-net­work sys­tem­s, but I have nev­er seen a /-lo­cal, /us­r-re­mote sys­tem in ten years.

And I sup­pose some­one does it, but that does­n't mean it makes sense. If you want a re­al, func­tion­al, un­break­able sys­tem you can use in case of net­work fail­ure: use a sep­a­rate par­ti­tion. Or use a Live CD. Or use a flop­py. All of those are more re­silient than your /.

As for /usr and /us­r/lo­cal... that's just a throw­back to when peo­ple were scared of in­stalling soft­ware. Peo­ple should in­stall pack­aged soft­ware any­way.

The Libs

/lib /us­r/lib and /us­r/lo­cal/lib. Just as much sense as the above.

The vari­able

/usr and /var. Here's what I think I heard: /usr is for un­chang­ing ap­pli­ca­tion da­ta (bin­s, lib­s, doc­s, etc.) /var is for mu­ta­ble da­ta (logs, spool­s, caches).

That way, you put /var in a sep­a­rate par­ti­tion and if apps run amok, your / does­n't fil­l.

Well... ok, I sup­pose. Ex­cept that the right way to han­dle that is to make sure your apps don't freak­ing run amok!

Say, logs? Ro­tate them by size, not by date!

Spool­s? Use disk quo­tas, and max­i­mum sizes!

Caches? They should be space-lim­it­ed.

And all ser­vices should be kind enough to fig­ure out when your disk is about to burst and do some­thing grace­ful with it.

Fi­nal­ly: if your /var fill­s, all your ser­vices will crash just as hard as if / filled. So what's the point? That you can log in­to the crashed box and fix it? You can do that with a full /, too.

The root of all evil

We live with the con­cept of a sin­gle almighty ad­min. Why?

If ev­ery ser­vice ap­pli­ca­tion had a sin­gle point of con­fig­u­ra­tion and mon­i­tor­ing (ie: /etc/app and /var/ser­vice/app (in runit ;-) and /var/log/ap­p, it would be triv­ial, us­ing ACLs, to al­low par­tial man­age­ment of the sys­tem.

Sure, there would be a re­al root for stuff like pass­word man­age­ment and such, but that's not so bad.

Why has no one both­ered do­ing this?

Per­mis­sion to barf

The Unix per­mis­sion sys­tem is at the same time hard­er and less pow­er­ful than ACLs. That on­ly on the last two years it has be­come prac­ti­cal to use ACLs on Lin­ux, and that still you can't count on them in ev­ery dis­tro is... ug­ly.

I could go on, but... I think you get the idea. Com­ing some day: a pro­pos­al to fix the mess.

segedunum / 2006-04-03 15:54:

Unfortunately, as much as I like Linux/Unix systems I have to agree. All of this becomes especially pointed at the desktop/client end of thing unfortunately.

Leo S / 2006-04-03 15:55:

Indeed. I think the filesystem mess is not too bad though. Unless you are a developer, you shouldn't care about it. That's what I like about Linux, you don't have to give a damn about where your software goes, the package manager will take care of it for you.



Of course its better to make sure that you only run sane apps that don't make 10GB log files, but you can never guarantee that.



Amen on the ACL's though. I've always thought that the Windows way of handling permissions was much more intuitive (not that ACLs are a Windows tech, but they do have a user friendly implementation).

Richard Bos / 2006-04-03 15:55:

For the diff between /usr and /var:

it should be possible to mount /usr read only

(to be more secure), while /var should be mounted

rw.

Roberto Alsina / 2006-04-03 15:56:

About mounting /usr read-only:



Well, unless it's also remotely mounted, it adds zilch more security, since mount -o remount,rw /usr usually succeeds.



About it only mattering to developers:



Maybe. Too bad I am one ;-)

Roberto Alsina / 2006-04-03 15:57:

Oh, and you can guarantee that apps don't make 10GB logs. Yes you can. Just use a log service that rotates based on size, and don't rely on the app at all :-)

Peter / 2006-04-03 15:58:

You also forgot /usr/X11R6/bin/ and /usr/X11R6/lib.



That said, have you looked at GoboLinux's file system hierarchy? It's something that I wish would catch on with the rest of the Linux world. In short, / looks like this:

/Depot - Dumping ground for stuff like music and pics that should be shared between users.

/Files - for fonts and non-application files

/Mount - like /mnt

/Programs - All programs and libraries go here

/System - /boot, /etc, and /var rolled into one

/Users - like /home

Very nice, and works quite well. Version 012 should be coming out within a week or two.

an anonymous coward / 2006-04-03 15:58:

Here's that proposal to fix the mess: instead of making an archaic and obtuse directory structure to support flexibility in how you partition your drive, use *directory merging* to merge directories on many partitions into one. That way you can have one standard directory for binaries, but those binaries could still be stored in different partitions, even different computers over the network. Decouple the filesystem namespace from the underlying storage.



Directory merging is possible on Linux today using some experimental kernel patches, I believe. It should be fairly easy to make those patches standard in your new distro (which sounds interesting to me). This is your chance to do something radically different that makes your distro unique.



If you want to go even more radically further, then I think a KIOSlave-like URL scheme (http, ftp, etc) should be added to the kernel at the lowest level. But that's probably a job for kernel hackers, not KDE guys or even distro makers...

JD / 2006-04-03 15:59:

The reason you have /usr/[s]bin and /[s]bin is that quite often /usr is a seperate local partition. You need basic tools to deal with things that prevent you from mounting /usr. This is why fsck is in /sbin and why everything in /bin and /sbin are statically linked.

Giacomo / 2006-04-03 16:00:

He who does not understand unix, is doomed to re-implement it over and over again... your line of argument leads straight to Windows or the old MacOs, don't you think? The binaries are all in one place (Program Files), the user data files too (Documents And Settings), and you have ACL, pseudo-filesystems, no real root, etc etc. Now, if you really want all this stuff, why don't you just use Windows? Are you saying that Microsoft is just getting wrong the implementation details?



Don't get me wrong, I'm not flaming here: it's refreshing to think critically about decades-old conventions and solutions. However, you can't just come around and trash the place, especially when is too easy to do so: the Linux Standard Base is so young that only big-biz distributions care to follow it, and everything that's in there has a reason to be like that; a reason that has been heavily discussed for decades by people more knowledgeable than you and me. The filesystem hierarchies have been discussed forever, people have gone away to do their own things (MacOs, Windows, Be, Amiga, etc etc) and eventually they keep coming back to the unix way of filesystem organizaton because of its flexibility and power :)

an anonymous coward / 2006-04-03 16:00:

The split-permission thing sounds like SELinux.

rjw / 2006-04-03 16:01:

Giacomo,



Your argument is riddled with logical fallacies.



1. The excluded middle, or slippery slope: just because somebody supports changing some aspects previously baked into Unix, you can not immediately assume that they will end up with Windows. This is tantamount to saying that Unix was handed down from mount /dev/sinai , and can never be improved.



2. Roberto has been using Linux for 11 years, and he isn't allowed to have an opinion on what he considers braindead?



3. Putting a smiley at the end of a completely idiotic statement makes you look like a dilweed :)

Roberto Alsina / 2006-04-03 16:01:

JD: I know /usr is sometimes a separate local partition. I say that you gain nothing from that, though. And you forgot the fallacy of argument from authority ;-)



If your /usr gets so bad you can't mount it, you can just as easily use a rescue CD (or a wholly separate system in another partition) and have a much better rescue environment than your crippled / (for example, / will not have sshd!)



Giacomo: Well, I grok unix just fine. However, I see that lots of things are just crud. They are done that way because they have been done that way for 20 or 30 years, and noone wants to change them.



In fact, we want to cristalyze them, with things like the LSB, which would provide a real reason to implement this silly structure:



"We do it that way to be LSB compatible".



We are turning unnecessary complication into necessary complication :-(



And finally, I just can't take seriously a preference for unix permissions over ACLs just because windows had ACLs first :-P

Roberto Alsina / 2006-04-03 16:02:

Peter: thanks for the gobolinux pointer, never heard of it!

Alex / 2006-04-03 16:03:

"Well, unless it's also remotely mounted, it adds zilch more security, since mount -o remount,rw /usr usually succeeds."

Unless the /usr partition is on some read-only media, which may not be mounted read-write physically.

And about the /usr - /var issues :

/var and /tmp are often written to and often read from, and additionally to that, /tmp shouldn't mandatorily survive reboots. /usr is, OTOH, often read from and seldom written to. So you may put /usr on some "quick read - slow write" device, /var on "quick read - quick write" device, and /tmp on some volatile device. It is completely irrelevant when speaking about desktops, of course, but it may be relevant for servers / embedded systems.

Roberto Alsina / 2006-04-03 16:04:

Alex, in the case of a fisically read-only medium, or a slow/fast difference, I guess you should try to put /bin and /lib there, too.



So, your best bet is to put / there, and mount /etc /var and /tmp from the other medium.



In that case, there is nothing gained from a separate /usr, either.

Alex / 2006-04-03 16:04:

"and mount /etc /var and /tmp from the other medium"...

That would be a bit more complicated.

Normally, you wouldn't mount /etc, for you use /etc/fstab to mount things. The same applies to /bin and probably to /lib - utilities from there are used to mount things.

So, to reformulate and widen my thoughts about various /*'s:

/bin

/etc

/lib - all of these should be where the / is.

/sbin - may be united with /bin. Although, I think I understand why there are /sbin and /bin - you may not want a regular user to run some administrative command unintentionally

/var - read often, write often, survives reboots.

/usr - read often, write seldom ( or not at all), survives reboots

/tmp - read often , write often, not required to survive reboots

Giacomo / 2006-04-03 16:05:

Sorry guys, I didn't want to look like the dork I am :) it's just that... every once in a while this "UNIX filesystem doesn't make sense" conversation shows up somewhere, and someone goes along and makes its own version, and it's ok, everyone is free to fork what he wants... but after all, the hierarchy is a just a bunch of _conventions_; that is, if you can't get enough people to agree with you, you can have the best solution ever, and still go nowhere. So far, it's been quite difficult even to get to the LSB.



On the windows comparison I certainly went too far, but... I don't know, when this topic comes up I just can't stand it and lose a bit of fairness :)

Simon Edwards / 2006-04-03 16:06:

The filesystem hierarchies have been discussed forever, people have gone away to do their own things (MacOs, Windows, Be, Amiga, etc etc) and eventually they keep coming back to the unix way of filesystem organizaton because of its flexibility and power



huh? Those OSes didn't "keep coming back to the unix way [...] because of its flexibility and power", except perhaps for some compatibility with unix programs that expect it.



It is funny that the Amiga should be mentioned. It's filesystem made sense and also used a kind of union filesystem in places for handling things like libraries. This feature was called "assign"s. (like LIBS:). You could have multipe library dirs and still refer to a library file by "LIBS:intuition.library" and it just worked and it was sane and this was 20 years ago.



--

Simon

rjw / 2006-04-03 16:07:

RE Acls.



Acls are not my favorite security primitive. Take a look at capabilities. Not Posix caps ( these suck beyond belief), but real capabilities.



Of course, this really does mean saying goodbye to posix.

Thinko / 2006-04-03 16:08:

Doomed to repeat it again indeed..

The difference between /bin and /sbin is...

"if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path."

-- and --

"/sbin should contain only binaries essential for booting, restoring, recovering, and/or repairing the system"



The difference is simple, /bin for everyone, /sbin for root.



and as far as /usr/(s)bin goes.. the same argument applies, except for the fact that on some systems the root is a tiny fixed filesystem which doesn't have enough room (intentionally or not) to store all of the userspace applications. Again, sbin in /usr is for administrative tools and should not be needed by regular users.



as far as /usr/local goes.. just because you haven't seen it, doesn't mean that some of us don't have large clusters of systems that share a common '/' and '/usr' that are remotely netmounted at boot time.. Why store separate (dozens, even hundreds) of copies of all that data when one copy will suffice. We mount /usr read-only and the boxes mount /usr/local (system-specific) for application or system -specific code dependant on the role of the server.



I'm sure some of you will call me old fashioned, but some of these architectural structures are in place for a reason.. don't like it.. that's fine -- go use GoboLinux, your own custom layout, or MacOS. Just don't throw away a system you don't understand.

Thinko / 2006-04-03 16:09:

I agree about your remarks regarding ifconfig and netstat, but not to the extent a regular user should be given access to the sbin folder, but the opposite.. those tools have a use in userland, thus they should live in /bin or /usr/bin.. /sbin is an administrative toolbox, and should contain only those tools necessary for the administrator to do system-critical tasks necessary for basic operations.

I think ifconfig is in /sbin by default more for security reasons than anything else.. on a large multi-user system, there is *no* reason for a regular user to have a use for any of the tools in /sbin.



And you've misinterpreted my layout a little, the point of the network-mounted filesystems is to eliminate a disk (common cause of failure) from hundreds of servers.. these servers may be dynamically added or removed from the application pools they serve at will without a significant negative impact on the applications they are 'assigned-the-role' of. This would be overly time-consuming and have no where near the flexibility if the boxes (or at least their drives) had to be removed from the racks.

The basic system image is only 1-2GB, the /usr directory is 5-10GB in size, and the /usr/local is dependant on the server role.. between 1GB and 15GB.. the /usr stuff in certain cases could be merged with the root (/) stuff, but in our case the root stuff is all i686, where the usr dirs for some server classes are P4 optimized, and others are K7 Optimized. This gives us the benefit that we only need 1 core boot/root image for our net-boots, and it will start all of the servers.. The only special app resident on the root partition is our config-fetch tool/scripts that choose the right /usr (depending on the arch) and will report to our cluster masters to find the necessary appropriate role (/usr/local).



Anyways, I didn't mean to insult, I just found the article critical of a system that has its base in large computing environments.



Just my $0.02

Roberto Alsina / 2006-04-03 16:09:

Thinko: You are being silly. You assume I don't understand just because I disagree. I, on the other hand, could claim that you agree just because you don't think. Would that be nice? No.



For example, for the existance of /sbin, you simply repeat what you have been told. What difference does it make that a normal user doesn't have ifconfig or netstat in his path?



They perform a useful function for a non-admin, too!. And *what* is gained from not having them in your path? What's the freaking point?



If /usr and /usr/local is only necessary for large installations, then why not make it optional, and use it only when it makes sense, instead of making it the default?



BTW: you could do pretty much the same thing with a combination of system-imager, local storage, and a profile-based package manager.



It's not like basic system setup is taking all your storage, right? The apps you have on /usr and /usr/local amount to how much? 10GB? 20GB? 50GB? What's the disk size?



If we make then the default, we force everyone to live with it. If we make it optional, then only those sysadmins of large installations need to care (and they are better equipped to handle it anyway).

Roberto Alsina / 2006-04-03 16:10:

Well, my desktop is not a large computing environment ;-)



We are installing millions of boxes with a scheme that's only really useful for a few thousand of them.



And I still am not sure I understand why there should be stuff in /sbin. AFAICS, anyone can try to run it, it's just not in the default PATH.

sergio / 2006-04-03 16:12:

>And I still am not sure I understand why there >should be stuff in /sbin. AFAICS, anyone can try >to run it, it's just not in the default PATH.



Well, "chmod 700 /sbin" it's easier than chmoding particular binaries.

Roberto Alsina / 2006-04-03 16:13:

Well, why would I chmod 700 /sbin?



Unless you have a SUID binary there, users can do no harm by trying to run the stuff.

berkus / 2006-04-04 00:41:

Speaking of GoboLinux - there is Rubyx distro, which takes some ideas from Gobo, and its latest incarnation - Heretix, which comes back to the unix root, by using "normal" names like /bin, but putting packages under /pkg tree. Nice to check out too.



I use kernel trustees patch on my old server, which lets you define permissions very granularly. I haven't checked SELinux yet, but i guess it should be possible to do the same with it.


Contents © 2000-2024 Roberto Alsina