topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday March 28, 2024, 6:10 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: *nix /usr - where it came from, why it's still there, and how to get rid of it.  (Read 10429 times)

Gothi[c]

  • DC Server Admin
  • Charter Honorary Member
  • Joined in 2006
  • ***
  • Posts: 873
    • View Profile
    • linkerror
    • Donate to Member
usr.png

Ran across this interesting read, explaining some of the history of the /usr folder :

  http://bsdtips.utcor.../index.php/Helio/usr

The article suggests a very nice way to have all binaries into the same folder (ie, unite /bin and /usr/bin) on FreeBSD using nullfs and union.

I found the historical bit about the magnetic tapes for / and a faster disk for /usr was particularly interesting :)

I figured I'd share the link... :)

housetier

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • default avatar
  • Posts: 1,321
    • View Profile
    • Donate to Member
and while we get rid of /usr the distros introduce /opt, /sys, /srv and whatnot. Heck the other day I saw ~/.local/ with a similar structure to /usr/local.

I wish they'd follow the LSB standard; well, and not make such deep directory hierarchies in my home directory.

Gwen7

  • Participant
  • Joined in 2009
  • *
  • Posts: 134
    • View Profile
    • Donate to Member
and while we get rid of /usr the distros introduce /opt, /sys, /srv and whatnot. Heck the other day I saw ~/.local/ with a similar structure to /usr/local.

I wish they'd follow the LSB standard; well, and not make such deep directory hierarchies in my home directory.

GoboLinux's Hisham Muhammad had the same problem, and asked much the same question. He came up with an interesting alternative to the insanity of the Linux directory tree. That alternative was then incorporated into his own version of Linux which garnered some press a few years ago and now has a small but dedicated following.

You can read the documentation up on his website.
http://www.gobolinux...p?page=documentation

Especially interesting are the first two links in the Articles section where he examines the problem, and then offers his solution. The second article entitled "I am not Clueless" where he refutes several imagined reasons for why things are the way they are is an especially good read.

When you finish reading about Gobo, try downloading and giving it a try. It's an enlightening experience realizing how much better Linux could be if it would just abandon some of its more traditional ways of thinking.

Not everything historic is worth preserving.





Gothi[c]

  • DC Server Admin
  • Charter Honorary Member
  • Joined in 2006
  • ***
  • Posts: 873
    • View Profile
    • linkerror
    • Donate to Member
When you finish reading about Gobo, try downloading and giving it a try. It's an enlightening experience realizing how much better Linux could be if it would just abandon some of its more traditional ways of thinking.

Interesting... I'll give it a go.

zridling

  • Friend of the Site
  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 3,299
    • View Profile
    • Donate to Member
Yea, first thing I do with a new distro is establish my ground, usually on a separate partition.

Gothi[c]

  • DC Server Admin
  • Charter Honorary Member
  • Joined in 2006
  • ***
  • Posts: 873
    • View Profile
    • linkerror
    • Donate to Member
Ok, I tried gobo.

It seems it makes heavy use of symlinks to force it's own hiearchy, and hides the traditional folders. Example:


gobohide --unhide /lib
gobohide --unhide /bin
gobohide --unhide /dev
ls -ahl /lib /bin /dev
lrwxrwxrwx 1 gobo gobo 24 2008-03-30 03:55 /bin -> System/Links/Executables
lrwxrwxrwx 1 gobo gobo 21 2008-03-30 03:55 /dev -> System/Kernel/Devices
lrwxrwxrwx 1 gobo gobo 21 2008-03-30 03:55 /lib -> System/Links/Libraries
gobohide --unhide /usr
cd /usr
ls -ahl
total 0
lrwxrwxrwx 1 gobo gobo 27 2008-03-30 03:55 bin -> ../System/Links/Executables
lrwxrwxrwx 1 gobo gobo 23 2008-03-30 03:55 include -> ../System/Links/Headers
lrwxrwxrwx 1 gobo gobo 25 2008-03-30 03:55 lib -> ../System/Links/Libraries
lrwxrwxrwx 1 gobo gobo 1 2008-03-30 03:55 local -> .
lrwxrwxrwx 1 gobo gobo 23 2008-03-30 03:55 man -> ../System/Links/Manuals
lrwxrwxrwx 1 gobo gobo 23 2008-03-30 03:55 sbin -> ../System/Links/Executables
lrwxrwxrwx 1 gobo gobo 22 2008-03-30 03:55 share -> ../System/Links/Shared
lrwxrwxrwx 1 gobo gobo 1 2008-03-30 03:55 X11R6 -> .

It's an interesting concept but I can't see myself using it because:

  • There is no utility to check installed packages for vulnerabilities such as glsacheck on gentoo or portaudit on bsd.
  • Many applications use hardcoded paths, their compatibility 'solution' of hiding the traditional filesystem with gobohide is a hack at best. Sorry, but no thanks :) And if you're going to use a hack, nullfs+union sounds like a cleaner way to do this than symlinks imo. 
  • Very few packages, and little up-to-date ones. Being able to create your own recipes is nice, but I can make gentoo ebuilds or freebsd ports just as easily, and both do have a decent package collection. In the end it would just be more hassle.

Also, for some reason they put libraries under programs. Personally i would have separated them. A dynamically loadable lib is not a program. Why call pears, apples? As a developer i find it handy to have all libs under the same folder. having them mixed in with all programs present on the system is just a big pain, not to mention a mess.
« Last Edit: April 10, 2009, 03:38 PM by Gothi[c] »

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,857
    • View Profile
    • Donate to Member
The Linux file 'hierarchy' is a pet peeve of mine. A couple of observations:

hiding the traditional filesystem

Unfortunately, the 'traditional file system' is routinely ignored, misunderstood, and screwed with, such that much of its underlying concept has become largely meaningless today. Hidden or not, Linux's directory structure is total garbage and desperately needs to be replaced with something that makes more sense.


[/li]
[li] Many applications use hardcoded paths

Which is very poor coding practice at best. No. Correction. It's just plain wrong. Developers should (and hopefully do) know better than that. Heck, even Microsoft knows better than that.

Re Gobo:

I don't think the GoboLinux crowd ever had any intention of creating or maintaining their own distro. I think what they've tried to accomplish is to spark some debate and possibly get people thinking about changing things. I hope they're not holding their breath.

Just my 2ยข

Gothi[c]

  • DC Server Admin
  • Charter Honorary Member
  • Joined in 2006
  • ***
  • Posts: 873
    • View Profile
    • linkerror
    • Donate to Member
Which is very poor coding practice at best. No. Correction. It's just plain wrong. Developers should (and hopefully do) know better than that. Heck, even Microsoft knows better than that.

True of course, but reality is that they don't. :) 
(oh, and Microsoft has plenty of hard-coded paths in their software btw)

desperately needs to be replaced with something that makes more sense.
I'm all for that, but I'd love to see a cleaner solution than hiding folders and multiple layers of symlinks ..


40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,857
    • View Profile
    • Donate to Member
(oh, and Microsoft has plenty of hard-coded paths in their software btw)

Yes they do. But in their case they aren't doing it because they're ignorant or too lazy to do it correctly. They're doing it for business reasons. :)

As far as a cleaner solution goes, the only effective and sustainable solution would be to fix the real problem rather than try to put a Bandaid over a severed artery.

The reason why this hasn't happened, and probably won't happen, goes back to three fundamental factors. Two are unique to Linux, one isn't.

1. Inertia. (Not unique to Linux.) Objects in motion tend to remain in motion and follow a straight path. When it comes to executable code, something that's working adequately and now will invariably trump something more elegant or flexible or correct - especially if the 'better way' requires significant changes be made to what is already available. And nobody is going to turn their back on GNU/Linux's huge codebase just because a a good portion of it wasn't designed or programmed 'correctly.'

2. Ad Hoc Development and Amateurism. A large amount of the software developed for Linux is either done by amateurs or on a 'quick & dirty' basis. Trying to argue 'best practices' in this environment is difficult. And when you add in the fact that most of this software is free, you can't in all fairness make too many demands on the developers.

3. Linux is not a standard - "it's really more of a guideline." (Linux's claim to fame.) There can be no enforcement of coding standards because GNU/Linux is not owned by anyone.

So if you take inertia and a bunch of sloppy or overworked coders - and add that to the lack of anything resembling an enforceable rulebook - what you wind up with is a lot of the nonsense that goes on in the NIX world. And although it drives the software development and support people crazy, most of the users really don't care.

So short of an 'epic fail' somewhere along the line, I doubt we'll ever get an overhaul of the file structure until Linux itself gets replaced by something better.

I'm all for that, but I'd love to see a cleaner solution than hiding folders and multiple layers of symlinks ..

Me too. Got any workable ideas for how to best accomplish that? Maybe even something like:

gothiclogo.gif


(HA! I suspected as much.   ;) ;D )

« Last Edit: April 10, 2009, 09:37 PM by 40hz »

Gothi[c]

  • DC Server Admin
  • Charter Honorary Member
  • Joined in 2006
  • ***
  • Posts: 873
    • View Profile
    • linkerror
    • Donate to Member
I really can't agree with you're nr 2 and 3, sorry :)

Linux is a kernel not a guideline, nor a standard.
The way distributions lay out their file system however, is pretty much 100% a mix of historical reasons and maintaining compatibility with various applications. And yeah, there ARE standards. POSIX is a standard, not a guideline.

I won't even comment on 2. It's just completely false. I see more amateurism on windows than elsewhere honestly. Do I have to mention all those folks that discover visual basic and think they suddenly are a developer?

Inertia is probably the main reason why anything is the way it is.

Got any workable ideas for how to best accomplish that?
Yeah, get rid of the symlinks and compatibility layers. If developers want to their apps to run on your distro, they had better stick to good coding practices. It's the only way to change the situation. Every time a compatibility layer is added, developers have less incentive to change their ways.

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,857
    • View Profile
    • Donate to Member
I think we're starting to have two separate conversations here. I was discussing what I believe are factors contributing to the inertia surrounding any attempts to radically change the Linux "standard" file hierarchy. :)

Linux is a kernel not a guideline, nor a standard.

I was using the word Linux in its colloquial sense as a term referring to the entire environment (i.e. the kernal, the GNU codebase, the user/developer community). So in this sense, it is a guideline. Or a convention, or a philosophy, or anything else you may want to call it. But the one thing that it is not is a 'standard.'

People have argued for 'standardizing' Unix for years without success. There have also been some halfhearted attempts to do the same with Linux. To date, it hasn't gotten very far. While most developers in the Linux environment recognize the need for some standards, very few seem willing to agree on just what those standards should be. So in place of a standard, there is now a corpus of "generally accepted ways of doing things."
Sure sounds like a guideline to me. :)

And yes, POSIX is a standard. Mostly on paper IMHO. Because in actual use it has also become more of a guideline. Even if you ignore actual deployments, only a relatively small number OSs (BSD, OSX, Solaris, and a few others) completely comply with it. Most shoot for being "mostly compliant" in that they follow POSIX standards where there is a clear benefit in doing so, and deviate from it when there isn't. Microsoft implements what POSIX compliance it has via a compatibility feature.

It has also been noted, that there is a fair amount of ambiguity in the POSIX standard itself. Furthermore, an OS does not need to implement every function in the standard in order to be certified as being compliant with it. A "significant fraction" is sufficient for certification. So maybe POSIX isn't as much a 'standard' (in the colloquial sense ;D) as many people think?

Re: #2 (BTW, since you "won't even comment on 2" , should I ignore the next three sentences that follow?  ;D Sorry... couldn't resist. Still friends right?  :))

Anyway...

I was using the word amateur in its original sense as one who engages in a pursuit, study, science, or sport as a pastime rather than as a profession. I did not mean to imply anything negative by it.

So in that sense, yes - much of what gets developed in the Linux is done by amateurs - who may also be professional developers elsewhere. Linus Torvalds himself still often refers to Linux as his "hobby-thing" .

The point I was trying to make, was that one contributing factor to the 'inertia' is that most Linux developers are not doing it for a living. For many, there is a limit to the time and energy they can put into working on their hobby so to speak. They are also not centralized, as they would be if working for a company. Each developer is working at his/her own pace on whatever he/she feels is most important.

And if they're like most people, they tend to be reluctant to do a rewrite of their working code just to comply with some vague standard unless they have to. In this environment, the general feeling is "What's good is what works!"

Which in turn leads to a lot of (dare I say it?) 'quick & dirty' development. Maybe I should have said recursive improvement cycles instead? :)

If developers want to their apps to run on your distro, they had better stick to good coding practices. It's the only way to change the situation. Every time a compatibility layer is added, developers have less incentive to change their ways.

Agree 100%. Which leads me back to numbers 1,2, and 3 above... ;) :)


« Last Edit: April 11, 2009, 01:20 PM by 40hz »