UNIX stuff that makes no sense ( the rant)
First of all, I love Linux. I have used it exclusively since about 1994 (yeah, the last Windows I actually used for real was WfW 3.11).
Let's see how it makes no sense.
The Bin
Your system has /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin 6 different binary locations.
What sense does it make to split bin and sbin? It only makes it harder for regular users to use tools the can need, like netstat and ifconfig.
As for /bin and /usr/bin, it makes little more sense, if at all. Sure, put a basic, functional system outside /usr, because /usr can be a network FS. Well, who does that?
I mean, I have seen all-local and all-network systems, but I have never seen a /-local, /usr-remote system in ten years.
And I suppose someone does it, but that doesn't mean it makes sense. If you want a real, functional, unbreakable system you can use in case of network failure: use a separate partition. Or use a Live CD. Or use a floppy. All of those are more resilient than your /.
As for /usr and /usr/local... that's just a throwback to when people were scared of installing software. People should install packaged software anyway.
The Libs
/lib /usr/lib and /usr/local/lib. Just as much sense as the above.
The variable
/usr and /var. Here's what I think I heard: /usr is for unchanging application data (bins, libs, docs, etc.) /var is for mutable data (logs, spools, caches).
That way, you put /var in a separate partition and if apps run amok, your / doesn't fill.
Well... ok, I suppose. Except that the right way to handle that is to make sure your apps don't freaking run amok!
Say, logs? Rotate them by size, not by date!
Spools? Use disk quotas, and maximum sizes!
Caches? They should be space-limited.
And all services should be kind enough to figure out when your disk is about to burst and do something graceful with it.
Finally: if your /var fills, all your services will crash just as hard as if / filled. So what's the point? That you can log into the crashed box and fix it? You can do that with a full /, too.
The root of all evil
We live with the concept of a single almighty admin. Why?
If every service application had a single point of configuration and monitoring (ie: /etc/app and /var/service/app (in runit ;-) and /var/log/app, it would be trivial, using ACLs, to allow partial management of the system.
Sure, there would be a real root for stuff like password management and such, but that's not so bad.
Why has no one bothered doing this?
Permission to barf
The Unix permission system is at the same time harder and less powerful than ACLs. That only on the last two years it has become practical to use ACLs on Linux, and that still you can't count on them in every distro is... ugly.
I could go on, but... I think you get the idea. Coming some day: a proposal to fix the mess.
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.
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).
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.
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 ;-)
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 :-)
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...
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.
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.
The split-permission thing sounds like SELinux.
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 :)
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
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 :)
Peter: thanks for the gobolinux pointer, never heard of it!
"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.
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.
"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
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 :)
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
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.
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.
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
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).
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.
>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.
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.
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.