Linked by Thom Holwerda on Fri 4th Apr 2008 14:49 UTC, submitted by lucasvr
Linux GoboLinux 014.01 has been released. "We are pleased to introduce GoboLinux 014.01, the new release of GoboLinux, the Linux distribution featuring a rethought file system structure. This release is our first 'point release', providing a stability update for our latest major release, GoboLinux 014, which was released three months ago."
Thread beginning with comment 308164
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Gobolinux simplified my Life
by olefiver on Fri 4th Apr 2008 16:52 UTC in reply to "Gobolinux simplified my Life"
olefiver
Member since:
2008-04-04

While I agree with you that Average Joe will not understand (nor care for) the difference between, say /lib and /usr/lib, or get a compleet overview as to where all installed files in a package went on his disk, I fail to see why this is an issue.

Average Joe should not need to know where his installation went, just that it went well. Newly installed programs should just popup in his menu, and his distro's packagemanagment should cleanly uninstall any program.

A user should only se his /home folder and there he's free to organize his folders any way he would wish.
And should Joe need to venture out in the unknown FH beyond his /home, give the man a warning: This be the domain of root, become him at your own peril 'cause here be dragons that'll bork your box.

Reply Parent Score: 6

computrius Member since:
2006-03-26

Thats also a good way to scare people out of learning anything new ;) If everyone took the "There is no reason for you to know so im not going to teach you, and you shouldnt bother learning" attitude, where would any of us be?

Im pretty good with linux and honestly ive never really understood the difference between /usr/bin, /bin, /usr/local/bin, etc..

I mean, as far as local goes, they are all local arent they? Its not like the other two are on a network drive or something (they probably could be, but then again so could /usr/local/bin).. As far as /usr goes, none of them are related to any specific user, or it would be in the home directory. Why make this pointless distinction between three different versions of bin that no-one seems to have a good answer as to why there are these distinctions at all? The same goes for /usr/lib /lib, and /usr/local/lib, and all the other pointless duplicates...

I love what this distro has done, and its a long overdue clean up of the giant mess that is the standard unix directory layout.

Edited 2008-04-04 18:39 UTC

Reply Parent Score: 7

Dasher42 Member since:
2007-04-05

Im pretty good with linux and honestly ive never really understood the difference between /usr/bin, /bin, /usr/local/bin, etc..

I mean, as far as local goes, they are all local arent they? Its not like the other two are on a network drive or something (they probably could be, but then again so could /usr/local/bin).. As far as /usr goes, none of them are related to any specific user, or it would be in the home directory. Why make this pointless distinction between three different versions of bin that no-one seems to have a good answer as to why there are these distinctions at all? The same goes for /usr/lib /lib, and /usr/local/lib, and all the other pointless duplicates...


Here's where learning by playing with a single Linux box shows its limits. In networks where a server exports filesystems over NFS, /usr/local is used for things that are actually still specific to individual machines. Of course, I've actually seen it the other way around, where /usr/local/ was an NFS mount.

What I want to know is what GoboLinux is doing about .so libraries. Drag and drop application installations in Linux frameworks often involve hackery with LD_LIBRARY_PATH and applications being precompiled monoliths, and this is not good when a security fix comes out for something common like say, SSL or gzip. Then, who knows if all the apps are really fixed? You're no better off than you were with Windows. Give me a mature package manager over that anyday.

Reply Parent Score: 2

sorpigal Member since:
2005-11-02

It can be deeply bewildering to attempt to understand the *nix FSH, especially since each *nix is a little different. Most detractors simply stop trying after a short time and declare the whole thing to be rubbish. This is unfortunate as no replacement system could possibly hope to see adoption if it fails to offer the benefits of the system it hopes to replace. Real admins will laugh at you if you try to tell them your simplifications are harmless.

That said, some kind of rethinking would not be out of order. There is no particular reason why everything has to be the way it is, especially the admittedly arcane names. /usr and /etc are my two favorite examples.

GoboLinux's approach can work, but not for everybody., (Repeat after me: App bundles are not the answer to all of our problems. If you think that's crazy then you are already out of touch.) GoboLinux is good because it opens the door to an examination of the original problem, not because it has the ideal solution. For some desktop scenarios their answer is a fine one and I applaud the fact that they *did* it rather than just insist that an existing distribution change.

What you should take away from this post is this: Even if you don't see it there *is* a sound and logical reason for (almost) everything you see. Modification is *good*; you shouldn't let anyone tell you that it ought to stay the way it is, but if you just try to throw out what you don't understand you wont get anywhere useful.

Reply Parent Score: 2

ZephyrXero Member since:
2006-03-22

As while I agree that the "average joe" user does not have to know where everything is. The benefit in a FHS like Gobo uses is much more beneficial to the people who have to fix things for those people. System administrators and IT staff would greatly benefit from a simpler, logically structured FHS. Developers would too. As much as people try to argue the traditional Unix FHS is great for developers, 95% of them would most likely disagree. I cant' tell you how many Windows only developers I've known that found the FHS as one of their greatest hurdles in switching to Linux development.

Simple is always better...

Reply Parent Score: 2

olefiver Member since:
2008-04-04

I cant' tell you how many Windows only developers I've known that found the FHS as one of their greatest hurdles in switching to Linux development.

If you couldn't tell me how many Linux only developers that switched to Windows development 'cause they found the Linux FH to be a problem, I'd take that into consideration.
Windows only developers finding great hurdles in switching to linux development, is another case of linux != windows

Reply Parent Score: 1

shevegen Member since:
2008-04-04

"And should Joe need to venture out in the unknown FH beyond his /home, give the man a warning: "

An OS should empower the user, not cripple his rights.

As long as these things are optional I have no problem, but I have a huge problem if any developer thinks his way is better than my way (no matter who is "right" and who is "wrong") and wants to enforce his way upon me.

This is why I will only agree (and of course favour) on modular solutions, and I will forever disagree on anything that requires the user to stick to the "only true way" of whatever solution upstream developers give you.

Exactly THAT is the big advantage of Linux - you can tweak it to however you want it to have.

This is, by the way, not specific to Gobolinux. This is valid for *every* distribution and to every upstream developer.

Gobolinux is just ahead of most other distributions in the sense that it allows self-contained applications, something which you simply dont get anywhere on a distribution-level. And if people do not realize that self-contained programs are better than spread-over programs, then noone can help them anyway (but with that being said, there are multiple ways to view it, and noone is inherently "wrong" or "right" on it. But my perception is that self-contained apps are much more "right" than the FHS "solution").

Reply Parent Score: 1

sorpigal Member since:
2005-11-02

And if people do not realize that self-contained programs are better than spread-over programs, then noone can help them anyway (but with that being said, there are multiple ways to view it, and noone is inherently "wrong" or "right" on it. But my perception is that self-contained apps are much more "right" than the FHS "solution").


Self-contained apps are like alluring candy; they doom you to rotten teeth, but damn if they don't look good!

There are serious advantages to having apps spread out and only a single disadvantage (or two, if you prefer to count it that way). The disadvantage is: It's hard to delete. Secondarily you might say that it's hard to know whether a given file is needed by a given app.

Even on Mac OS the self contained application is largely mythical. Yes it is *possible*, but rarely does it happen. On Windows you still see it very rarely, usually only for very simple apps. For those crying foul... on your Mac, how many library and framework files get thrown around by your apps? I know some apps have dependencies, like iTunes requiring QuickTime. How self contained is self contained?

One big, nasty problem with self-contained apps: How much of the system is standard? On Windows and Mac you can be *pretty* sure that a vast array of userland libraries are present on all systems. Your self contained app can be installed, use Win32 or Cocoa and be just fine. A truly self contained app operating on a Linux box can assume... what? Libc, most of the time, the kernel, and that's about it. In order to be sure it can be dropped into any distribution every stand alone app would require a huge portion of the standard userspace libraries to be bundled with it. Common-distribution foundations are a partial answer, and LSB helps a lot, but it's still unpleasant to contemplate.

The standard solution to the one issue with spread out apps is to allow a package manager to track the files, which mostly works. If adequate solutions could be found to the several problems of self-contained apps then I might consider them seriously, but as of now only one viable answer exists.

Reply Parent Score: 2