Forgot your password?
typodupeerror
Linux Software

GoboLinux Rethinks The Linux Filesystems 859

Posted by timothy
from the deep-linking dept.
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.
This discussion has been archived. No new comments can be posted.

GoboLinux Rethinks The Linux Filesystems

Comments Filter:
  • I'm surprised this is the first this type of system setup has surfaced. Using longer names is far more intuitive.
    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

  • by kstumpf (218897) on Saturday May 10, 2003 @01:56PM (#5926459)
    I think capitalized letters in directory/filenames in a unix filesystem is inherently annoying. Personally, I'd never go along with something that slowed down the efficiency of tab-expansion when working in a shell.
  • STFU (Score:-1, Interesting)

    by Anonymous Coward on Saturday May 10, 2003 @01:56PM (#5926461)
    Reading most of these preceeding comments, why is everybody so "offended"? Linux (and open source in general) has borrowed many of their ideas from Microsoft, so why stop now? Is renaming and re-organising the basic file structure so awful?
  • Re:SQL FS (Score:2, Interesting)

    by Anonymous Coward on Saturday May 10, 2003 @01:56PM (#5926465)
    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.
  • Enough (Score:4, Interesting)

    by krumms (613921) on Saturday May 10, 2003 @01:56PM (#5926466) Journal
    This is enough to make those cheering on Linux standardization sit down and cry ;)
  • Re:Is it just me, (Score:5, Interesting)

    by Blaine Hilton (626259) * on Saturday May 10, 2003 @01:57PM (#5926469) Homepage
    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 (Score:2, Interesting)

    by Dalroth (85450) * on Saturday May 10, 2003 @01:59PM (#5926484) Homepage Journal
    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
  • by Anonymous Coward on Saturday May 10, 2003 @02:04PM (#5926523)
    The longer filenames is the least of its worries. It looks some like a BBS coder did the shell colors (hint: white -> light blue -> cyan does not look like a "fading blue" or even good). At least they have a terrible looking logo and webpage (look! cubes!) and have to apply a "patch" to the kernel for Konquerer to read the new filenames... and after all the work that was done on the font system for X they chose the worst looking blocky fonts for the screenshots. WTF?
  • I like it, but.. (Score:5, Interesting)

    by _aa_ (63092) <j@@@uaau...ws> on Saturday May 10, 2003 @02:05PM (#5926525) Homepage Journal
    in other locales will the directory structure still be in english?
  • by PeterClark (324270) on Saturday May 10, 2003 @02:06PM (#5926533) Journal
    I say, "Why not?" I think this is a great idea; I'm all for a better directory structure. Just because the present system has been around for 30+ years doesn't mean that we shouldn't take a second look at it and see if it can't be improved.

    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?

    • /usr/share/plugins
    • /usr/share/netscape/plugins
    • /usr/share/mozilla/plugins
    • /usr/lib/mozilla/plugins
    • /usr/lib/mozilla/1.3a/plugins
    • /usr/lib/mozilla/1.3/plugins
    • /opt/netscape/plugins
    • /opt/mozilla/plugins
    • /usr/local/mozilla/plugins
    • ad naseum...
      • 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.

  • by daviddennis (10926) <david@amazing.com> on Saturday May 10, 2003 @02:12PM (#5926565) Homepage
    You also have My Documents and My Pictures, which means annoying exercises with double quotes.

    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
  • by Vellmont (569020) on Saturday May 10, 2003 @02:14PM (#5926583)
    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?
  • Re:Is it just me, (Score:5, Interesting)

    by Sique (173459) on Saturday May 10, 2003 @02:28PM (#5926648) Homepage
    I never found file extensions intuitive. Because they can only be three letters long they tend to condense to cryptic symbols far away from every intuition. .BAT files don't fly around during the night, and .COM files don't talk to the COM ports (except you have a serial mouse and MOUSE.COM as driver ;) )

    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)

    by swimmar132 (302744) <{ten.rekcupknip} {ta} {eoj}> on Saturday May 10, 2003 @02:29PM (#5926654) Homepage
    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.
  • by Ed Avis (5917) <ed@membled.com> on Saturday May 10, 2003 @02:40PM (#5926703) Homepage
    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.)
  • Re:Is it just me, (Score:3, Interesting)

    by Dunkalis (566394) <crichards.gmx@net> on Saturday May 10, 2003 @03:02PM (#5926806)
    Extensions should be handled by metadata, as others have said. There is no reason to keep around the old .??? format, since computers can support more, and metadata can store information. Extensions should help the user figure out what sort of stuff is in the file, but not determine anything else. For example, if a file has the extension .image, it could have some metadata saying that its a PNG or a JPG, and the program opening them could determine what to do with that. Metadata could hold much more, too. For example, lets say you rip a DVD to, say, Divx. In that Divx, you could include information about the movie, who directed it, etc. So, if you ripped Spaceballs, and wanted to watch only Mel Brooks movies, you could sort it properly.

    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. /me smashes into Internet communication barrier
  • Almost there (Score:2, Interesting)

    by vmalloc_ (516438) on Saturday May 10, 2003 @03:02PM (#5926807)
    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!

    As for the "Frankenstein" description, consider this: When a file is supposed to be in /usr/local for BSD, the same one is supposed to be in /opt/bin for SysV. It's a mess!

    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)

    by antiMStroll (664213) on Saturday May 10, 2003 @03:09PM (#5926841)
    How are drive letters more intuitive than UNIX-style mounts in which drives are just another directory? Unix doesn't care if it's a physical, RAM or network drive, to the user they appear transparently identical. The Linux naming convention is also far more rational and indicative of where files really reside. HDA - first physical hard drive on the first ide. HDB - second. HDA1 - first primary partition on said drive. In Windows, C: can be anything. Also, don't be deceived into believing A-Z is always enough, some machines (not mine!) at work have already hit the alphanumeric barrier.

    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.

  • by Phroggy (441) * <slashdot3&phroggy,com> on Saturday May 10, 2003 @03:11PM (#5926850) Homepage
    On the Mac, we have Documents and Pictures, making that unnecessary, and tab expansion can happen at the first letter.

    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.
  • by jez9999 (618189) on Saturday May 10, 2003 @03:34PM (#5926978) Homepage Journal
    You took the words out of my mouth. If there's one advantage the Windows filesystem has over *nix, it's being case insensetive. Why on Earth do you want to have the option of having two files with paths identical in every sense but case? Isn't this just confusing? And does anybody actually _use_ this functionality? It seems to me that common practice is to name different files differently in *any* OS, so why not make it case insensetive?
  • Re:Is it just me, (Score:5, Interesting)

    by spectral (158121) on Saturday May 10, 2003 @03:54PM (#5927080)
    This is, actually, C:\Documents and Settings\user

    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 /etc directory I'm sure. Is it in it's own subdirectory? Possibly! Let's go and see.

    Having all the stuff AT LEAST symlinked from some common directory would be SO NICE. (cd /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.
  • Re:Oh, good! (Score:4, Interesting)

    by chabotc (22496) <(chabotc) (at) (gmail.com)> on Saturday May 10, 2003 @04:01PM (#5927105) Homepage
    Heh that were no angels..

    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)

    by hswerdfe (569925) <slashdot@org.howard@swerdfeger@com> on Saturday May 10, 2003 @04:03PM (#5927115) Homepage Journal
    This is a Very Very Good Idea.

    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)..... ...sigh to bad I can only rant about it, I have no Idea how to go about adding something like this.....
  • Re:Oh, good! (Score:5, Interesting)

    by chabotc (22496) <(chabotc) (at) (gmail.com)> on Saturday May 10, 2003 @04:11PM (#5927143) Homepage
    Ah, it was OSNews and not wired:
    http://www.osnews.com/story.php?news_id=34 31

    In it he writes in the intro: " I'm going to make a sensible directory structure: /users, /apps, /system, /hardware, /downloads, /logs, /servers, /shared, and more. Then, using symlinks, we're going to recreate the current basic layout of the standard Linux/BSD filesystem to assist developers in porting applications. For example, our system would probably include the following the symlinks" (and goes on to describe a system much like this one)

    It was mentioned on slashdot here:
    http://slashdot.org/article.pl?sid=03/04/29 /195821 2

  • 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.
  • by Enahs (1606) on Saturday May 10, 2003 @04:19PM (#5927174) Journal
    Amen to that! You should have read the entirely different response to this on kuro5hin.org; I think I was the one that came the closest to a dissenting opinion, and I just wanted to know why they didn't just use Encap or GNU Stow! :-D

    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?

  • by Phroggy (441) * <slashdot3&phroggy,com> on Saturday May 10, 2003 @04:29PM (#5927219) Homepage
    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

    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 /Library/WebServer/Documents, but not so nice that the configuration file is /etc/httpd/httpd.conf.
  • Re:Is it just me, (Score:2, Interesting)

    by ray-auch (454705) on Saturday May 10, 2003 @04:38PM (#5927244)
    the cool thing about this is that you can mount a partition under an existing directory. Run out of space in /home/user? Add a new drive, mount it under /home/user/mp3 and move your music there

    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).

  • by Anonymous Coward on Saturday May 10, 2003 @04:41PM (#5927261)
    Maybe if you're a human. For one thing, computers see filenames as strings of bytes. It's much more complicated for a computer to operate on such byte strings if it first must capitalize/uncapitalize all the bytes, especially when paying attention to locale rules (so it's not that Unix's file system is case sensitive, but rather that the Windows file system is locale-dependent--bad). Whether or not tab completion cares about case is precisely the sort of user-configurable thing that should go in the shell, rather than sucking resources in the core operating system, where it also can't be customized to individual user's liking.

    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 .html file? Or when you'd download and then upload a file to a Web server, and it'd end up getting autocapitalized? Such pains are a result of a file system that doesn't do things the Unix way.

    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.
  • by be-fan (61476) on Saturday May 10, 2003 @04:52PM (#5927313)
    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.
  • NT and POSIX (Score:5, Interesting)

    by Rui del-Negro (531098) on Saturday May 10, 2003 @05:40PM (#5927590) Homepage
    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.

    Two old but interesting articles about the evolution of NT:

    http://www.winntmag.com/Articles/Index.cfm?IssueID =97&ArticleID=4500 [winntmag.com]

    http://www.winntmag.com/Articles/Index.cfm?IssueID =97&ArticleID=449 [winntmag.com]

    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)

    by Rysc (136391) <sorpigal@gmail.com> on Saturday May 10, 2003 @05:46PM (#5927620) Homepage Journal
    Sorry, but when i started using linux about 5 years ago (shit time passes fast), /var, /etc, /bin and the like were all pretty clear. If you don't know what etc. means, well, you're a sodding retard. /bin was obviously binaries - at least as soon as I figured out how to tell what a binary looked like, and how to read permissions. /usr is, well, user. Figure it out, there's only one missing letter.

    Actually, /usr is an acronym standing for UNIX Shared Resources and has nothing to do with users, except indirectly.

    Some even argue against pronouncing it "user" but I find that I cannot help it, and am not overly keen on trying.
  • by samhalliday (653858) on Saturday May 10, 2003 @07:09PM (#5927959) Homepage Journal
    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.
  • Re:Great Idea! (Score:3, Interesting)

    by swv3752 (187722) <swv3752&hotmail,com> on Saturday May 10, 2003 @08:36PM (#5928297) Homepage Journal
    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.
  • Re:Oh, good! (Score:3, Interesting)

    by KAMiKAZOW (455500) <kamikazow@hotmail.com> on Saturday May 10, 2003 @09:24PM (#5928491)

    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)

    by MobyDisk (75490) on Sunday May 11, 2003 @12:07AM (#5929103) Homepage
    This is something that Microsoft should get points for. None of the locations of anything are hard-coded. The OS can be in any folder. If you want to install an app, you call the GetSpecialFolder() API to find the proper location. Same goes for the "My Documents" and "My Crud" directories.

    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. :-)) It would be impossible to enumerate the special folders since they are just environment strings. There is no way to get additional information on them such as a description, or what file types belong in them. An API seems like the way to go.
  • Re:Thank god (Score:3, Interesting)

    by Arandir (19206) on Sunday May 11, 2003 @12:27AM (#5929172) Homepage Journal
    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.
  • Re:Is it just me, (Score:4, Interesting)

    by spectral (158121) on Sunday May 11, 2003 @02:22AM (#5929495)
    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.

    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 /MacOSXAppsDirectory/CompanyName/Program.Package/e tc will work. Of course those aren't real directory names, but you get the idea.)

    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)

    by BrokenHalo (565198) on Sunday May 11, 2003 @03:30AM (#5929697)
    I guess there's probably nothing inherently wrong with "meaningful" names for directories - for those who feel they need them. There is probably something to be gained from this when trying to "sell" Linux to the novice user.

    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.

  • by GlobalCombatDotCom (670485) on Sunday May 11, 2003 @03:52AM (#5929768) Homepage
    Hopefully GoboLinux and LinuxStep will join the the MHS standard so that this kind of improvement can start to spread to other distros.

    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: /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

    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 /Apps directory rather than cramming everything into /usr.

    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.

UNIX is many things to many people, but it's never been everything to anybody.

Working...