Slashdot Mirror
GoboLinux Rethinks The Linux Filesystems
dolbywan_kenobi writes "GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy. In GoboLinux we have paths such as /Programs/XFree86/4.3/ and /System/Settings/BootScripts/Reboot." By design, GoboLinux is quite a bit different from most Linux distributions, and -- notably -- is a live ISO, always nice.
Good thing about SQL core file systems is that you can have any god damn view you want, want to make it look like unix? not a problem. Define youre own View. Linux lagging behind? forsure. BeOS and now Longhorn have SQL cores.
Anything to make Linux easier is a plus, however there is one Windows and many, many Linux distros, this is like dividing the cause. However it does provide for far more flexibility and doesn't lock you into any one company.
Nice idea, though not really new. I frequently use my own directory structures on my systems to organize things better.
:)
My only comment: the directories should be lowercase. Why? Because it's easier to type, no other reason!
Bryan
in other locales will the directory structure still be in english?
Now would anyone care to guess how many knee-jerk posts there will be, like "if you like a sane directory hierarchy, use OS X, ya weenie!" or "if it's not broke, don't fix it!" To which I respond, where do you keep your Mozilla plugins?
Much applause to the guys who were willing to think a little more critically about what we can do to make Linux just a little better.
I know the unix file hierarchy well, but I've always thought it was arranged haphazardly. Why are there six different places for system executables? (/bin, /sbin, /usr/bin,/usr/sbin, /usr/local/bin, /usr/local/sbin)? That's not even counting the alternative directories that some programs like to be installed under like /opt, or X11 programs.
The one thing I don't like is that they renamed root to gobo. While root doesn't have much inherent meaning to it, gobo has even less. If you're going to rename root, why not pick something more meaningfull like administrator, admin, superuser, BigManWithTheTopHat, etc? I guess I haven't checked recently, but is linux still limited to 8 characters for the username?
AccountKiller
No. Stupid people should not be allowed to use cars. People should know how to use cars, not how to accelerate and drool.
Stupid people driving a car are hazards to the rest of the driving world. They wreck mailboxes, they kill babies, they break cars, they waste auto mechanic time, they cost taxpayers money.
If stupid people were kept away from steering wheels and stayed at home in front of a TV set where they belong and left the driving world to those that understand it, things would go smoother, there would be less computer problems, far less accidents, much less auto mechanic time wasted, and tax payers would save a lot of money.
I fail to see why cars should be dumbed down for the dumb. It makes no sense.
Don't understand your car?? Go fuck yourself.
It seems to me that all they've done is replace one set of hardcoded directory names with another. Whether you have /usr/X11R6 or /Packages/XFree86 makes very little difference.
The trouble with the Unix filesystem is that it makes it hard to install and uninstall software, because the files for an application are scattered all over the place. Package managers like RPM work around this problem a bit - and indeed if you are stuck with the conventional filesystem layout then using RPM or dpkg is the best option - but there is no easy or intuitive view of the packages installed.
This leads to user interfaces and desktop environments which try to hide the filesystem from users. Windows mas 'My Documents' and all that, not giving any clue where My Documents really is on the disk; Unix desktop environments aren't usually that bad but still they don't dare to just show the root of the filesystem to the user, or even to show by default a complete view of the user's home directory (because there are 'hidden' files scattered around it like confetti).
The Mac OS X or ROX-desktop approach is better; an application is contained in its own directory, installing an application is just copying it and uninstalling is just deleting. On RISC OS (which ROX spritually inherits from) I used to arrange my applications by task, so drawing apps would be in one directory and music apps in another. Often the apps and the files they operated on would be in the same directory, but this is of course up to the user. Then there is no 'start menu' or similar layered brokeness trying to disentangle the different applications into a meaningful hierarchy - you just move apps around to where you want them. So the root directory of the hard disk would have Drawing and Music subdirectories.
I think this is the key point, BTW - if you ever find yourself building some tree-structured abstraction on top of the filesystem in an attempt to make life easier for users, you should stop and ask whether the filesytem itself couldn't handle the job better. This applies to Start Menu, My Computer, and their imitators in Unix world. It also kinda applies to the Windows registry, another case where Microsoft reinvented a new tree structure instead of using the filesytem.
Now I should say I'm not a big fan of the ROX approach *at present*. I think it is too confusing to have a mixture of conventional RPM-installed apps and application directories on the same system, and it would be better to have some smoother transition, such as being able to treat uninstalled RPM packages as application directories and double-click to run them. But if a whole distribution took the appdirs approach, it would rock.
There are questions about how to make _everything_ installable, deletable and movable just by dragging things around the filesystem. How do you handle shared libraries? What about multi-user systems where two users will want different arrangements of applications? (For that I'd say user symlinks, and yes, they should be exposed to the user as part of the GUI.)
-- Ed Avis ed@membled.com
This is interesting, but it really doesn't get there. Mind you, I have always been a large advocate of changing the unix file structure: It is a messy, disguisting frankenstein of combinations from the old unix system days, that even experienced unix hackers get messed up in. Hell, until I got a book on porting unix software, -I- didn't know how the unix file structure was defined, and I've been doing this for 5 years!
/usr/local for BSD, the same one is supposed to be in /opt/bin for SysV. It's a mess!
As for the "Frankenstein" description, consider this: When a file is supposed to be in
What needs to happen is that a new STANDARD needs to come out, and everybody needs to support it. Of course, nobody will ever support new standards, so that's out of the question, but if you really want to improve the unix file structure you have to do that. Anything less than that, and you're simply adding to the fragmentation problem.
Finally, there are two technical problems with this guy's method, too. Firstly, all the directories use Capital letters, which is unneccessary for clarification, AND makes it harder to type. Same goes for the full name of the folders: reducing "Executables" to "exe" would be just as recognizable, AND a lot easier to deal with in a shell command.
This is, actually, C:\Documents and Settings\user
/etc directory I'm sure. Is it in it's own subdirectory? Possibly! Let's go and see.
/Programs/XFree86/4.3 .. oh look, everything X installed.) Yeah, that could get confusing. Therefore there might be a bin directory, a config directory, and a data directory. They can all be symlinks, I don't care, but if I had to come up with where KDE stores it's default menu, I would have no f*cking clue. Somewhere in /usr I guess? Might depend on the distro.. Agh.
Where the hell are you people getting this BS about it being in the windows directory?! It wasn't there in w2k. I should know, I'm running it right now. It's not there in XP (Professional). I should know, the computer next to me is running it.
That being said, the linux file system structure SUCKS! Windows isn't much better, but christ.. especially with the distros. Where is your config file for samba? Well, I don't quite know. It's somewhere in the
Having all the stuff AT LEAST symlinked from some common directory would be SO NICE. (cd
This is a Very Very Good Idea.
...sigh to bad I can only rant about it, I have no Idea how to go about adding something like this.....
MS is adding something like this into longhorn.
first time heard about it, it was called "Object File", I'm sure the name will/Has change(d) to something more stupid proof.
Some of the functionality you want can be kinda emulated, with a system of file seaches in shell scripts, and Linked Files, and folders.....
but it doesn't quit behave, in a completely transparent manner....(which would be nice).....
--meh--
Maybe distro developers could try creating better ways of teaching the Linux directory structure instead of changing it. For example, a sidepane that appears in folder windows, describing the purpose of the folder currently being viewed. Or perhaps Windows-esque "tooltips" appearing over color-coded system folders that provide similar information. Both methods would be infinitely more convenient than constantly referring to documentation.
The directory structure in Linux is one of the biggest shocks to experienced Windows users who are accustomed to navigating the files and folders of Windows, and its complexity is a major area that needs to addressed if Linux is to make gains in the desktop arena.
Personally, I think it sounds like a great idea. If you're putting together a desktop system, there's really no need to carry around the old UNIX cruft. Honestly. And as much as the fanboys jizz all over OS X, I'd think this would be a welcome change. I suppose if this came with a system capable of real translucency and drop shadows, the l33t boyz would be jizzing instead of bitching, eh?
Stating on Slashdot that I like cheese since 1997.
This is is a terrible idea... It makes a complete mess of the Unix filesystem, just so that the distro maker doesn't need to edit /etc/ld.so.conf to include /usr/lib as well as /lib
/Library/WebServer/Documents, but not so nice that the configuration file is /etc/httpd/httpd.conf.
You obviously don't get it. This wasn't done to make things easier for the distro maker - this makes things a pain in the ass for the distro maker, I'm sure. This was done to make things logical and orderly for the USER. I'm glad I wasn't the only one who thought it would be nice to do something like this, since I'm far too lazy to actually go to the trouble.
You should take a look at what Apple has done with Mac OS X - they've taken a similar approach, except that they just hid the legacy UNIX directories from the GUI, and tacked all their stuff on top. I expect that they'll slowly move things out of the legacy UNIX directories as it becomes practical to do so, taking an approach very similar to Gobo in addition to what Apple has already done - at least I sincerely hope that's the direction they take. It's nice that Apache's DocumentRoot is
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
I think the guy you were replying to has a point. I don't buy into this "I'm OK, you're OK, never judge anybody" BS. Not being judgemental is okay within certain limits, but there are limits. It's fine is somebody don't want to learn about computers or cars or whatever. But there is a large segment of the population that doesn't want to learn about ANYTHING. They don't know anything about the world, but the still think they have a right to spout their opinions about politics. They know nothing about business, but still think they have the right to complain about corporate practices. I'm talking about the kind of people who have no idea what the first ten amendments are, no idea what the platforms of the people they're voting for are, no idea about anything beyond what's on FOX tonight and what J-Lo's ass is doing this week. There are some limits to how intellectually lazy we should allow people to be. After all, we make judgement calls about child molesters, murderers, theives, prostitutes, etc, so why not
stupid people? To tell the truth, I have more respect for a prostitute than someone who is intellectually lazy.
A deep unwavering belief is a sure sign you're missing something...
During the 80s, the UNIX with the biggest user base was... XENIX (made by none other than Microsoft), which was later sold to SCO, and which was one of the systems used as a basis for the POSIX standard. NT (and, subsequently, W2K and XP) does comply with a big chunk of the POSIX standard (I suspect one of the reasons was to make it easier to port software from Xenix to NT - Microsoft didn't want to lose market share to the other UNIXes). In some ways, though, NT is closer to VMS than to XENIX.
D =97&ArticleID=4500
D =97&ArticleID=449
Two old but interesting articles about the evolution of NT:
http://www.winntmag.com/Articles/Index.cfm?IssueI
http://www.winntmag.com/Articles/Index.cfm?IssueI
NTFS has other nice features such as symbolic links, named streams, non-continuous files, etc.. I learned a few tricks a couple of years ago in a newsgroup discussion from a guy working at Microsoft. Some of these features appear to be completely undocumented (or at least the documentation is very well hidden).
RMN
~~~
in fact, libraries are a new thing... in those days everything was statically linked. i really dont see how this relates to RAM being cheap though... or how you see gobo as being 'logical' when the *NIX filesystem is the perfect example of a logical FS heirarchy. if you dont see it as logical, then you don't understand it.
We have those too, just usually they are in boneheaded layed out developements.
My sister lives in one where they plunked a golf course in the middle and didn't bother to rename streets. So, they deadend at the golf course then continue, on the the other side. If that is not bad enough, there are streets that end in "T" intersections, that then continue a block or two later.
Of course even worse is Cape Coral, FL. You will have a "28th Street", "28th Terrace", "28th Court", "28th Avenue", and so on. Then there are the canals. Then canals will cut a street, and it will continue on with the same name on the other side. Imagine a maze of streets with near identical names except one might be "St" or "Terr" and every so often if you make it to the right street you find your way blocked by a canal. I can see why postmen go crazy.
Just a Tuna in the Sea of Life
The Unix tradition of splitting up applications by *type of content* instead of *application* is crazy.
Yes it's crazy. There are some systems that do it the "non-crazy" way, but not many. And none which are popular or particularly current. I can think of RISCOS and NeXT and that's it.
Windows certainly doesn't do it that way. Do you seriously think I can type in "msword" at a DOS/NT prompt and expect anything meaningful to happen? You'll get an error message unless you have specifically set the path to wherever it's installed. DOS/NT has no idea where "msword" is unless you tell it. That's why people run that program using the menu or clicking an icon. But oddly enough, UNIX knows exactly where "abiword" is when you type it on the command line.
It would certainly be nice to have a RISCOS like directory structure. But that's not what GoboLinux is doing.
p.s. If you can think of any sensible mechanism to make a RISCOS like directory structure usable for any arbitrary application under UNIX, please let me know, because I would like to implement it. Making it work for just ROX applications isn't good enough. It needs to work for XEmacs, Konqueror, OpenOffice, and anything else not specifically designed for that infrastructure.
A Government Is a Body of People, Usually Notably Ungoverned
This is certainly the unix way I guess. There shouldn't need to be a special packaging command to help me find the files though. This filesystem still makes more sense to me. If all things install to their own separate directory tree, then symlink them so everything also appears it's in one spot (like /Configurations .. or just call it /etc since it's shorter ;)), we have the best of both worlds. I shouldn't have to depend on some package manager tracking every file that a program needs to run, especially if it's made with scripts afterwards. MacOSX has it right here: Most things are just a 'Package'. A Package is a compressed folder/disk image, and is treated like one by the OS.
/MacOSXAppsDirectory/CompanyName/Program.Package/e tc will work. Of course those aren't real directory names, but you get the idea.)
Therefore double clicking it will run the program, but you can easily go right in side of it and see all the files, and treat them like files. This works on the command line too. (cd
There are similar commands for any packager because there needs to be. There's also a command for sorcerer that finds files it's not tracking. When wanting to COMPLETELY remove something, I have to check that list as well. And then hope that IT is complete. Being able to check a directory for a "data" folder, back that up if I want, then blow out the directory would be nice. (Yes, this does screw up symlinks. Therefore it MIGHT be better to have the directory for the program contain the symlinks, as opposed to scattering the symlinks in to the one solid directory. Unless there's a way to reversely traverse a symlink in constant time..)
Again, a pipe dream I'm sure, and I'll admit there are certain things about the linux/unix file system that are nice. Configs mostly in one place, etc. But yikes it's certainly a mess. Something like this would help a great deal, I think.
(Another example: at a konsole, hit k, then hit tab. How many things come up? How many of those are kde programs? Are those ALL the kde programs? Probably not. What if you want to see all the executables that are part of the 'kde distribution' ? I guess you're off checking your package manager: Make a list of what you consider the kde distribution, run that list through the package manager, dump that in to a tiny little thing that sees if they're executable, etc.
Not too much different than just using ls/find/grep/bash/whatever, but what if your package DB gets corrupt? If bash/ext2 gets corrupt you have a bit more to worry about I'd think.)
FS/OS support for links makes it so easy to do such cool stuff that's essentially impossible in some other operating systems (Shortcuts are files that are treated specially by the shell in Windows. Not by the OS's FS layer. Therefore, they're nowheres comparable.) Why don't we use that support to make a FS structure that makes sense to everyone, and kicks ass? You can keep the old layout, and have a nice new layout too. Best of both worlds.
I'm content, however, with a directory structure that has been used with little variation on any number of flavours of Unix systems for 30-odd years, because it works.
As an aside, I can see this thing causing major problems for anybody wanting to compile their own packages through the ./configure && make && make install cycle. You would probably have to create so many symlinks, you might as well stay with the old system anyway.
Hopefully GoboLinux and LinuxStep will join the the MHS standard so that this kind of improvement can start to spread to other distros.
/bin => /System/Commands /sbin => /System/Commands /boot => /System/Boot /dev => /System/Devices /etc => /System/Config /lib => /System/Libraries /proc => /System/Process /mnt => /Mount /opt => /Apps /tmp => /Temp /home => /Users /usr/bin => /System/Executables /usr => mostly placed under /System /var => mostly placed under /System
/Apps directory rather than cramming everything into /usr.
http://mhs.sf.net
The goal of the MHS project is to define a Modern Hierarchy Standard for UNIX-like operating systems which will further enable them to evolve, innovate, grow, and compete with Windows and other modern OSes.
Specifically, MHS technology will provide the following benefits:
100% Application Directory Oriented
Internationalization of Directory Names
More Intuitive Directory Names
Fewer Root Directories
Support for Case-Insensitive File Systems
Full Coexistence with Legacy FHS
Increased System Flexibility
A new hierarchy will be a big enough change to make distributions switch to application directories.
Set of environmental variables pointing the location of major system directories.
Applications would no longer need to hard code directory names.
System level directories grouped together under a common directory. (/System)
Currently, the directories are expected to be moved to the following locations:
All paths will be lower-case on a case-sensitive file system. As shown otherwise.
Application developers and distribution makers will need to use the
The autoconf family of tools will be patched to support the new hierarchy which will make most applications translate easily.
Although it can still be done, MHS will not support the same level of shareability (i.e. mounted over a network) as the legacy FHS standard.
FHS can be emulated via symlinks and MHS can be emulated on existing FHS systems. A kernel/file system hack of some kind may be done to have the legacy directories disappear in directory scans, to help improve user friendliness.
In addition to the standard, the project is developing a set of scripts that will setup the new hierarchy on existing FHS compatible systems.
The standard will not be finalized until a Linux distribution ships based upon it.
Bryan
CT