GoboLinux Rethinks The Linux Filesystems 859
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.
Looks like Darwin. Smells like gnu. (Score:5, Interesting)
Last login: Fri May 9 23:02:15 on ttyp1
Welcome to Darwin!
[garou:~] numbski% cd
[garou:/] numbski% ls
Applications Network automount etc mach_kernel usr
Desktop DB System bin log.txt private var
Desktop DF Users cores mach sbin
Library Volumes dev mach.sym tmp
mixed case = bad for shell (Score:4, Interesting)
STFU (Score:-1, Interesting)
Re:SQL FS (Score:2, Interesting)
Enough (Score:4, Interesting)
Re:Is it just me, (Score:5, Interesting)
Nice idea (Score:2, Interesting)
My only comment: the directories should be lowercase. Why? Because it's easier to type, no other reason!
Bryan
Who cares about the directories? (Score:1, Interesting)
I like it, but.. (Score:5, Interesting)
For all those who ask, "Why?" (Score:5, Interesting)
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.
Re:Looks like Darwin. Smells like gnu. (Score:5, Interesting)
On the Mac, we have Documents and Pictures, making that unnecessary, and tab expansion can happen at the first letter. So longer, self-explanatory names can work well if the original developer isn't boneheaded enough to use names not unique at the first space.
D
doesn't seem like a bad idea... (Score:5, Interesting)
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?
Re:Is it just me, (Score:5, Interesting)
If you want to store information about how to handle and to interpret files, you have to be more verbose. That's why the MacOS filesystem had a ressource path from the beginning, and that's why NTFS has 64 KBytes for every file reserved for meta information.
Same with drive letters. Because drive letters were always overloaded with semantics (A: beeing the first floppy drive, C: the first hard disk) you run into limitations you don't need. When repartitioning one hard drive can destroy the installation of programs never installed on this harddrive, because they were expecting their CD-ROM in F:, and now it moved to G:, then something is wrong.
If you tell me now that programs should never expect a fixed letter for a CD-ROM and instead look for the type of the device, then you are supporting my point already: Putting too much semantics into single letters is not intuitive, and it is too easy to break it.
No, too much conventions in the Windows filesystems are a relict from CP/M times when memory was too precious to be spend on meta information and you just put everything into conventions hoping those conventions wouldn't interfere too much. But they never have been intuitive.
Re:Is it just me, (Score:3, Interesting)
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.
There could be a better layout, but this is not it (Score:2, Interesting)
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.)
Re:Is it just me, (Score:3, Interesting)
The possibilities extend far beyond that, however, but I forgot what possiblilties I came up with.
I know this is hard to understand (I barely understand what I wrote), but I could probably draw and explain it better in Real Life.
Almost there (Score:2, Interesting)
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.
Re:Is it just me, (Score:3, Interesting)
Window's recent recursive mapping of subdirectories back to the top level (Documents and Settings, Desktop and My Computer) are also a constant irritation when traversing the MS file system. Going one level up from the Desktop can put you in different places depending on the method chosen.
I think you're talking about familiarity, not simplicity.
Re:Looks like Darwin. Smells like gnu. (Score:4, Interesting)
Also, since the first letter of these folders is capitalized, and most of my files have lower-case names, tab completion works really well. Apple clearly had the command line in mind when choosing these folder names, and tab completion works in some GUI dialog boxes as well (Cmd-Shift-G in the Finder opens a Go To Folder dialog where you can type a path).
Some folders have spaces in them, but you never have something like "My Documents" and "My Pictures", just things like "Desktop Pictures" and "Screen Savers" - the beginning is unique, so tab completion works.
Re:mixed case = bad for shell (Score:3, Interesting)
Re:Is it just me, (Score:5, Interesting)
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
Re:Oh, good! (Score:4, Interesting)
Don't you remember the article (i think it was on wired?) "If i had my own linux distribution". In it the author explained that he envisioned a file system layout just like this, and explained that to keep compatibility he would create links to legacy locations, just like this distro does.. (obviously all very much inspired to that apple did with OS X)
Funny that a week or 2 later such a distro is announced..
Re:Finally! (Score:3, Interesting)
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).....
Re:Oh, good! (Score:5, Interesting)
http://www.osnews.com/story.php?news_id=3
In it he writes in the intro: " I'm going to make a sensible directory structure:
It was mentioned on slashdot here:
http://slashdot.org/article.pl?sid=03/04/2
Learning the Linux structure, not changing it (Score:3, Interesting)
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.
Re:Oh no, it's different! Let's hate it! (Score:5, Interesting)
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?
Re:Bad, Terrible Idea (Score:3, Interesting)
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
Re:Is it just me, (Score:2, Interesting)
Same in windows, been that way for several years (since at least NT4 betas and possibly in NT4, though if it was there it was better hidden).
Also, you can mount any device under multiple drive letters and/or multiple directories - even recursively under itself (which I just tried to see if it broke and it actually seems to work).
Re:mixed case = bad for shell (Score:1, Interesting)
Second, while case sensitive names may look confusing to you, they aren't to a computer. Temporary files and database systems are just two examples of systems that can make use of the expanded possibilities a case sensitive namespace provides.
There's also the little tidbit that the current Windows file systems (whether VFAT or NTFS) are case sensitive--just like Unix, you can store BlahBlah.doc, and it remembers it was BlahBlah.doc, rather than BLAHBLAH.DOC. It's just that Windows treats file names the same, regardless of capitalization (I bet that works real well in other locales with complex capitalization rules, bwahaha).
Here's another advantage of the Unix system, this time for humans: many sites on the Internet are Unix based. Because those systems are case sensitive, it's often tricky getting a Windows system to interoperate. Remember when you couldn't save a
I think you're being misguided by the idea that file systems are for people, rather than computers. Ideally, people should never see the file system unless they're doing administration. In fact, this is precisely the sort of model that the home directory provides. You can adopt a flat structure, or a tree, or whatever floats your boat. It's all up to you.
Looking further ahead, into the Future(TM), where the grass is Greener(TM) and everyone has a Flying Car(TM), we'll probably end up storing all of our data in databases, rather than in files. Data storage won't even care about things like file names, which will be maintained by a layer between the data store and the user. In fact, you'll have so many petaquads of data that the idea of finding stuff by looking at file names will seem utterly laughable.
Re:Take your head out of your ass. (Score:3, Interesting)
stupid people? To tell the truth, I have more respect for a prostitute than someone who is intellectually lazy.
NT and POSIX (Score:5, Interesting)
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
~~~
Re:Finally! (Score:4, Interesting)
Actually,
Some even argue against pronouncing it "user" but I find that I cannot help it, and am not overly keen on trying.
Re:You've answered your own question (Score:3, Interesting)
Re:Great Idea! (Score:3, Interesting)
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.
Re:Oh, good! (Score:3, Interesting)
obviously all very much inspired to that apple did with OS X
Or inspired by BeOS (now Zeta [yellowtab.com]), or AtheOS (now Syllable [sourceforge.net]), or some other OS that exsists longer than MacOS X.
Not everything is inspired by Apple.
Re:Finally! (Score:3, Interesting)
Environment strings don't seem like a robust way to solve the problem. They can be changed too easily (yes, too easy is sometimes bad.
Re:Thank god (Score:3, Interesting)
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.
Re:Is it just me, (Score:4, Interesting)
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.
Re:Is it just me, (Score:3, Interesting)
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.
MHS - Modern Heirarchy Standard (Score:2, Interesting)
http://mhs.sf.net [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.