Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Linux Software

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.
This discussion has been archived. No new comments can be posted.

GoboLinux Rethinks The Linux Filesystems

Comments Filter:
  • Oh, good! (Score:4, Funny)

    by Anonymous Coward on Saturday May 10, 2003 @01:53PM (#5926430)
    I was just thinking this morning, "Man, all these Linux distributions are too similar. I wish someone would come in and fuck up the Linux filesystem hierarchy so they could really set themselves apart!" It's like the angels were listening and hand-passed my suggestion up to the heavens. Thanks!
    • Re:Oh, good! (Score:4, Interesting)

      by chabotc ( 22496 ) <chabotc AT gmail DOT 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:Oh, good! (Score:5, Interesting)

        by chabotc ( 22496 ) <chabotc AT gmail DOT com> on Saturday May 10, 2003 @04:11PM (#5927143) Homepage
        Ah, it was OSNews and not wired: 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: /195821 2

      • Re:Oh, good! (Score:3, Interesting)

        by KAMiKAZOW ( 455500 )

        obviously all very much inspired to that apple did with OS X

        Or inspired by BeOS (now Zeta []), or AtheOS (now Syllable []), or some other OS that exsists longer than MacOS X.
        Not everything is inspired by Apple.

  • Figures (Score:5, Funny)

    by Blaine Hilton ( 626259 ) * on Saturday May 10, 2003 @01:53PM (#5926431) Homepage
    It figures that as soon as I about have the file system understood they come up with a distro that uses a more normal setup...

    Need to calculate [] something?

    • Re:Figures (Score:3, Insightful)

      by jmorris42 ( 1458 )
      It isn't more normal unless you are one of those poor wretches so abused by living in Microsoft's Hell that you have started to love your captors and accept them as normal. If that is you, go get some help.

      The UNIX Way has proven itself over decades. Problems have been discussed and dealt with. Go read the Linux File System Standard documents if you are interested in learning WHY things are where they are on a modern distro. There is method behind the madness, designed to accomodate the needs of a disp
  • 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 baywulf ( 214371 ) on Saturday May 10, 2003 @02:03PM (#5926517)
      Except that for a command line user, longer names mean more typing. In Windows 2000, we have "Documents and Settings" as the base directory for users. Not only is it long but it has spaces which complicates the typing. Yes I know there is tab completion but it still can be a problem when names start the same way.
      • this is why you type out part of the name, then hit [TAB] to autocomplete the name. I use it in the OSX command line all the time.
      • by daviddennis ( 10926 ) <> 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.

        • 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 johannesg ( 664142 ) on Saturday May 10, 2003 @04:03PM (#5927114)
          Ah, yes: my documents. On my computer. As if I could walk into my study, and think to myself "I wonder whose computer that is. I'd better turn it on to see if it is really mine."
  • by evilviper ( 135110 ) on Saturday May 10, 2003 @01:54PM (#5926442) Journal
    First Link:

    Differences between GoboLinux and a traditional Linux system

    Once you installed GoboLinux, your experience will be greatly improved if you are aware of the following facts... :-)

    * In the GoboLinux hierarchy, files are grouped by their functional category (executables, libraries, and so on). There are links at the classic directories you are used to (/bin, /usr/bin, and so on), but remember that they all point to the same place. This is a huge advantage, as it means, for example, that you'll never have to search for a library throughout your filesystem again -- it will always be in /lib (and in /usr/lib, because they point to the same place! -- no worries about compatibility).
    * A little known UNIX rule states that what defines the superuser is its user id (which is zero), not its name. Through the years, there has been a convention to call the superuser "root". In GoboLinux, we chose to choose the superuser's name. It's called "gobo". It's fun, less ambiguous and even a bit more secure (since most crackers will try to login in your machine as root, you can setup a dummy, easy-to-break "root" account that will serve as a cracker-trap). In any case, if you wish to change the superuser's name back to "root", it is easy to do so.
    * There are symbolic links relating most of the usual UNIX directories to the GoboLinux tree. Therefore, you will find directories such as /etc, /var/log and /usr/bin in the expected places. However, some directories, such as the users' directories, didn't need to be linked to their "legacy" locations. This way, for a given user called "joe", you'll have, instead of /home/joe, /Users/joe. Notice also that the superuser's directory is no different than the ones from the other users, so, gobo's directory is at /Users/gobo. Mount points are under /Mount, not /mnt.
    * Another major difference between GoboLinux and most Linux distributions is that it does not use a BSD nor a System V initialization procedure. Instead, it has its own. At /System/Settings/BootScripts you will find a few files that command the entire boot procedure: Init and Done run at system boot and shutdown, respectively; Single and Multi are used after Init for initialization of single-user and multi-user modes. Halt and Reboot are used after Done for each specific kind of finalization. The Options file separate site-specific settings from the rest of the scripts, and Tasks serves as a function library.

    Second Link:

    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. Like it? Read more...
    It's official: GoboLinux 006 is out!

    May, 9th, 2003 at 1:05

    Five months after the first alpha version, GoboLinux version 006 is now the official stable release. There are too many improvements to list here, the greatest ones being /System/Links/Shared, FiboSandbox, and last but never the least, GoboHide. As usual, the ISO is compiled for i686 and is a "live CD" so you can try out GoboLinux without actually installing it, so you have no reason not to check it out. :)

    Existing users don't need to reinstall from scratch (actually the idea is to never have to reinstall from scratch!). An upgrade mini-HOWTO will soon be posted on our mailing list.
    To-do list: ideas for the future

    May, 2nd, 2003 at 17:04

    GoboLinux is all about cool ideas. A lot of them float around in the mailing list, but end up buried in the archives. Now has a place to store them, with an optimistic name of To-do List. It is part of the documentation section.
    New GoboLinux webpage u
    • by andyr ( 78903 ) <> on Saturday May 10, 2003 @04:38PM (#5927248) Homepage Journal
      Notice also that the superuser's directory is no different than the ones from the other users, so, gobo's directory is at /Users/gobo.

      A severely bad idea.

      A lot of systems I maintain have NFS-mounted home dirs - /home/ is on another machine.

      When the sh*t hits the fan, I need to be able to log in - as root. The last thing I need is root's home dir inaccessible.

      There are decades of wisdom behind Unix, most of which I have no desire to re-learn. Not broke ? Don't fix.

      Cheers, Andy!

      • by sheriff_p ( 138609 ) on Saturday May 10, 2003 @06:08PM (#5927719)
        "Those who don't understand UNIX are condemned to reinvent it, poorly." -- Henry Spencer
      • by nathanh ( 1214 ) on Saturday May 10, 2003 @07:00PM (#5927926) Homepage
        There are decades of wisdom behind Unix, most of which I have no desire to re-learn.

        Well, to be honest, it's decades of tradition not wisdom. There's not a lot of wisdom in names like /usr and /etc. Wtf are they supposed to mean? Yes, *I* know what they mean, but I've been using UNIX for more than a decade. I'm not going to fool myself into thinking they're good names.

        Not broke ? Don't fix.

        Though that I can agree with. However the joy of Linux is that people can take it in a new and interesting ways. If this guy wants to do this then more power to him. I'd be interested to see if the idea becomes popular.

        Though surely this would have been easier with a VFS view in GNOME or something.

  • Finally! (Score:5, Insightful)

    by TwistedSpring ( 594284 ) on Saturday May 10, 2003 @01:56PM (#5926457) Homepage
    I've always held that the filesystem organisation in linux is the primary reason that new users find it hard to get to grips with. Names like etc, bin, var, usr, are meaningless to newbies, and novice users can get confused with /usr/local/share vs. /usr/share Hopefully gobo have also sorted the Installing-a-program bomb-blast, i.e. as soon as you install something it scatters a million files all over the filesystem in different directories that makes it impossible to keep track of and (sometimes) impossible to completely remove if you compiled it rather than used a package manager. It's about time this was re-vamped if linux is to become a viable desktop OS.
    • Re:Finally! (Score:3, Insightful)

      by mdfst13 ( 664665 )
      I think that this operates rather backwardly. Instead of making /bin a symlink to some new directory, it would make more sense to make a conglomerate directory that includes the contents of /bin, /usr/bin, etc. One can do this comparatively easily in a GUI environment (or in a database filesystem--it's just a matter of query structure).

      There are several problems with symlinking all */bin directories to another directory. First, some of these directories are put in different places for good reason--/usr/bi
    • Re:Finally! (Score:5, Insightful)

      by samhalliday ( 653858 ) on Saturday May 10, 2003 @02:34PM (#5926672) Homepage Journal
      dont be ridiculous... those FS are designed with efficiency in mind, and careful refining of 30+ years of UNIX experience. just becuase the FS hierarchy is different from windows is not a good enough reason to change it. people worry too much about how these 'newbies' are goign to think about GNU/Linux, when in the end, getting used to a new filesystem is not a hard thing, with some form of "intro to GNU/Linux" book in front of you you can learn the basics in a day. add on top of that, end-users (non-root accounts) do not even NEED to see the FS hierarchy, they see /home/$USER and that is easy-peesy to understand.

      /usr and /usr/local are entirely different things, and not the worry of users. they are also very intuitive. /usr is standard system stuff, /usr/local is locally hacked stuff, so i can place 'my' hacked version of any program in /usr/local and override the system one (if i were the sysadmin).

      this whole FS reshaping is a rediculous idea and goes against everything the LSB [] has been tryig to fix, since there are so many deviants of GNU/Linux. i hope this distro dies off damn quickly... (how to lose all your karma in 10 seconds)

    • Re:Finally! (Score:4, Insightful)

      by oyenstikker ( 536040 ) < minus city> on Saturday May 10, 2003 @02:37PM (#5926687) Homepage Journal
      Would it be possible to have some sort of combination of file system and organization such that:

      /bin/someprogram/ == /usr/someprogram/bin/
      /lib/someprogram/ == /usr/someprogram/lib/
      /log/someprogram/ == /usr/someprogram/log/
      /etc/someprogram/ == /usr/someprogram/etc/
      /share/someprogram/ == /usr/someprogram/share/
      /bin/all/ == /bin/*/* (== /usr/*/bin/*)
      /lib/all/ == /lib/*/* (== /usr/*/lib/*)

      rm -rf /usr/someprogram would completely delete the program, no having to go into /usr/bin/, /usr/share/, /etc/, /var/log/, et cetera individually.

      Your $PATH would only need to be /bin/all/, your $LDPATH would only need to be /lib/all/

      The same form could be followed for 'info', 'man', 'sbin', 'lock', 'include', et cetera. You could have programs in /opt/ and /local/ as well as /usr/, and /bin/, /lib/, . . . would also pull out of those.

      Just me foaming at the brain.
      • Re:Finally! (Score:3, Interesting)

        by hswerdfe ( 569925 )
        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 add
    • Re:Finally! (Score:5, Funny)

      by Malcontent ( 40834 ) on Saturday May 10, 2003 @03:54PM (#5927077)
      "Hopefully gobo have also sorted the Installing-a-program bomb-blast, i.e. as soon as you install something it scatters a million files all over the filesystem in different directories that makes it impossible to keep track of and (sometimes) impossible to completely remove if you compiled it rather than used a package manager."

      Yes. Windows has this problem solved completely. For example in windows when you install a file it goes into c:\program files\progname. All the libraries go into c:\winnt\system32. The config files sometimes go into the c:\program files\progname or into c:\winnt\systems32 ir get merged into a binary file called the registry. Any files that are shared go into c:\program files\common files\progname.

      Linux will no go anywhere until program installs are as clean as windows. Look how nice the windows system is!
    • Re:Finally! (Score:3, Insightful)

      by Ozwald ( 83516 )
      I'm not sure if the directory structure really needs to be changed, and forcing backwards compatibility with symbolic links couldn't look all that pretty after awhile.

      But I think the problem of inconistency is already bad. Is a program going to install in /usr/bin, or /usr/local/bin, or /usr/appname/bin? Configuration, logs, same. Don't get me started on /opt.

      What may be better is for package managers and install scripts to look for standardized environment variables to know where files should be insta
      • Re:Finally! (Score:3, Interesting)

        by MobyDisk ( 75490 )
        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
  • 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.
    • by Hanji ( 626246 ) on Saturday May 10, 2003 @02:16PM (#5926592)
      Perhaps you're looking at it incorrectly. It seems to me that the real solution would be to make tab-expansion case-insensitive. I'm not saying that this is practical, but case-sensitive filesystems and paths really only add a major annoyance to a system, rather than any great benefit.

      If anyone knows a reason why case-sensitive paths are a GOOD thing, please respond. I really would love to know - they just seem annoying as hell to me.
      • 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?
    • Actually this doesn't slows down the efficiency of tab-expansion. ZSH, the default GoboLinux shell, does handle graciously tab expansion, so it is possible to press 'p', tab, and you will be in /Programs.
    • Well, you say it slows down tab completion, but I'm not sure I see why.

      I write Java. So I have class names like RoundObject and WebSite. Well, not that verbatim. But anyway, if I type shift-r+, I still get RoundObject. Now if you aren't a touch typist, i'd sligtly agree. Otherwise, shift-r vs r isn't that much slower. Hell, typing in English forces you to type that stupid shift key quite fast.

      Now if you mean in terms of string compares, how much faster do you need a tab completion to be done?

  • 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 ;)
  • Bad, Terrible Idea (Score:5, Insightful)

    by evilviper ( 135110 ) on Saturday May 10, 2003 @02:00PM (#5926497) Journal
    This 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/ to include /usr/lib as well as /lib

    The only minor problems I have EVER experienced with libs/headers is that some will install themselves in a subdirectory, and software that uses it expects it to either not be in a subdirectory, or expects the subfolder to be in the LD/C/CPP path. That is easilly fixable, and this distro doesn't address that issue at all.

    Hey, why make a mess out of the Unix filesystem anyhow??? If you want is a bit less complex, throw in a few symlinks. No need to cause all sorts of #%@^ to happen with this type of hack.
    • by Phroggy ( 441 ) *
      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/ 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
  • 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 smcv ( 529383 ) on Saturday May 10, 2003 @03:44PM (#5927023) Homepage
      /usr/share/plugins /usr/share/netscape/plugins /usr/share/mozilla/plugins

      Well, share is for platform-independent data, so that's out. (A Mac and a PC with the same Linux distro and packages should be able to use the same NFS-mounted /usr/share tree, hence the name "share"; this matters more on traditional Unix hardware than it does now).

      The rest are all possibilities, depending on whether you or your distribution vendor installed Mozilla, and whether you or they consider Mozilla to be a monolithic "black box" (like Windows apps) or an integrated part of the system (so it's easy for Galeon or other Gecko-based browsers to embed it).

      It's valuable to have /usr/local and /usr separate - that way you, the local sysadmin (installing self-compiled stuff to /usr/local) and your package management system (installing to /usr) will never get in each others' way. /opt vs. /usr/local is a bit more subtle - you're meant to use /opt for identifiable "modules" which could be removed without side effects (I use it for games), and /usr/local for things which fit into the traditional Unix hierarchy (if you installed Mozilla in /opt the executable should be something like /opt/mozilla/mozilla or /opt/mozilla/bin/mozilla, if you installed in /usr/local it should just be /usr/local/bin/mozilla). Some distros don't have even have a /opt directory in the default install (Debian doesn't).

      I realise it's not ideal, particularly with some of the more subtle points (share vs. lib, /usr/local vs. /opt), but it's pretty much standardized by now.

      (I wish all my dotfiles followed a similar hierarchy, actually - I've started using symlinks to get the caches in ~/.tmp and the important config files in ~/.etc, so I can leave out .tmp when I do backups)

      Some of the merging Gobolinux does seems like overkill; for instance, the benefit of having the /usr hierarchy is that you can put all the critical system files (/bin, /lib, ...) on a separate, smaller partition, which can sometimes even be read-only, guaranteeing that you have a bootable system.
  • Another article... (Score:5, Informative)

    by illsorted ( 12593 ) on Saturday May 10, 2003 @02:08PM (#5926541)
    Kuro5hin [] also has a good article [] on GoboLinux.
  • by bazik ( 672335 ) <bazik@ge n t o> on Saturday May 10, 2003 @02:08PM (#5926547) Homepage Journal
    In GoboLinux, we chose to choose the superuser's name. It's called "gobo". It's fun, less ambiguous and even a bit more secure (since most crackers will try to login in your machine as root, you can setup a dummy, easy-to-break "root" account that will serve as a cracker-trap). Remember to set the roots prompt to PS1="C:\>" for the ultimate cracker-trap! :)
    • Re:root = gobo? (Score:3, Insightful)

      by sootman ( 158191 )
      Great idea, except that everyone who reads the manual (ahem) will set the root user to 'gobo' and the password to 'gobo'. :-)
  • by gallir ( 171727 ) on Saturday May 10, 2003 @02:13PM (#5926579) Homepage
    Yeah,, yeah, standards are good, you have many to choose from.
  • by Vellmont ( 569020 ) on Saturday May 10, 2003 @02:14PM (#5926583) Homepage
    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?
    • Explanation. (Score:5, Informative)

      by juuri ( 7678 ) on Saturday May 10, 2003 @02:40PM (#5926698) Homepage
      I'll help you out here.

      /sbin utilities needed to get the the system to a booted state

      /bin bare essential utilities needed to manipulate the system once booted or before multi-user mode

      /usr/sbin system control programs needed to manage or alter a system once in multi-user mode

      /usr/bin/ programs for interacting with a multi-user system

      /usr/local/sbin/ system control programs that don't come from the os/hardware vendor

      /usr/local/bin/ other programs that don't come from the os/hardware vendor

      Of course many modern lunix distributions break this by placing files wherever people think is cute, much like how the .org, .net and .com have lost their meanings.

      • Re:Explanation. (Score:5, Insightful)

        by bmetz ( 523 ) on Saturday May 10, 2003 @04:03PM (#5927117) Homepage
        I don't think he needs a lecture. We all know the reasons why they slowly added new directories.

        And they are all asinine.

        Users want stuff to work. They don't care that 20 years ago hard drives were too small to fit all your files or that some weirdo grouping of your programs allows you to share parts of the installation across your non-existant network of linux machines. My login script has over 60 lines dedicated to finding moron binary directories like /usr/local/X11/bin and /usr/local/java/bin. This is not acceptable.

        I'm not sure if this gobolinux stuff is the solution but at least it isn't happy with the status quo. IMHO the biggest problem with linux is that the users don't think there's anything wrong with it.
  • by martin-k ( 99343 ) on Saturday May 10, 2003 @02:51PM (#5926757) Homepage
    Please... spend your energy on improving general Linux usability, not on just renaming a few folders.

    There are many more important areas that could be improved, like a consistent clipboard, working drag & drop, unique hotkeys in menus (or: hotkeys at all!), KDE's Start menu in most distributions containing literally dozens of programs, etc. etc.

    If somebody uses the Linux shell, remembering that /dev means "devices" and what /usr/bin is for is the least of his worries...

    Martin Kotulla SoftMaker Software GmbH

  • by Bob9113 ( 14996 ) on Saturday May 10, 2003 @03:28PM (#5926946) Homepage
    GoboLinux Rethinks The Linux Filesystem

    Filesystem Hierarchy Standard [] has included the BSDs since 1995 - it's more than just Linux. I'm all in favor of questioning the assumptions to avoid getting caught on a local maxima, and I think this one is a dead end. FHS has some historical baggage, but it also has the strength of years of tempering.
  • Thank god (Score:3, Insightful)

    by Hard_Code ( 49548 ) on Saturday May 10, 2003 @03:41PM (#5927013)
    I've been suggesting this for a long time, and I usually only get blank stares. I have yet to find ONE good reason to maintain the "traditional" unix filesystem layout on a desktop machine (well, even server, but let's not go there).

    The Unix tradition of splitting up applications by *type of content* instead of *application* is crazy. Thre are two bad reasons: 1) "Hey, I can throw every little binary in 'bin', go me!" 2) "Hey, I can throw every little library in 'lib', go me!". Parts of an application are hardly ever dealt with seperately. Does anybody install only the binaries of an app, and not, say, it's libraries?? or it's docs? No, these all belong to a cohesive unit that should be installed, uninstalled, moved, and run together.

    As for #1, when your primary interface to the OS is a GUI desktop, having every piddly executable on your system in one directory doesn't really confer any benefit. As for #2, not all applicatinos need to use all other applications to begin with, and for those who do, why should those libraries not then be considered reusable common libraries, and then and only then, linked or put in a common place?

    The system i'd propose would look something like this:

    all applications have a structure like:


    All user applications live in: /apps/[appname]

    You may choose to symlink the nested app dirs into /apps/[bin,lib,doc,conf] if you wish, like Stow does.

    All "system" apps (e.g. stuff that is typically in /sbin) live in a mirror structure at: /sys/[appname]

    Again, any utility binaries or common libs *may* be symlinked into the base /sys dir.

    Application configuration would live with each app, no more throwing every fscking config file into the mud pit of /etc.

    Things like 'man' would index *into* the seperate app dirs, not the other way around.
    • Re:Thank god (Score:3, Interesting)

      by Arandir ( 19206 )
      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 wh
  • by Three Letter Acronym ( 665094 ) on Saturday May 10, 2003 @03:48PM (#5927050)
    Bitch bitch bitch bitch bitch. Wow, I'm really suprised at the venemous reaction from you guys. Now, no matter what you think of this idea, some of the things I've seen posted here are disgusting.

    All this is is a different filesystem in ONE distro. It's not being federally mandated, nor is it going to become a standard that you have to deal with. It's one group's solution to what they perceive is a problem. If you don't want to use GoboLinux, then don't. There's no reason for everybody to pull out their pitchforks and torches.

    I even read some post where the guy said something along the lines of I hope they die a quick and painful death. That's fucking pathetic.
    • 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; 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?

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

MESSAGE ACKNOWLEDGED -- The Pershing II missiles have been launched.