Slashdot Mirror
GoboLinux Rethinks The Linux Filesystems
dolbywan_kenobi writes "GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy. In GoboLinux we have paths such as /Programs/XFree86/4.3/ and /System/Settings/BootScripts/Reboot." By design, GoboLinux is quite a bit different from most Linux distributions, and -- notably -- is a live ISO, always nice.
or does this smack of M$ windows???
While we're at it, let's rename all the streets so we all have to relearn how to get where we want to go! Excellent!
That's not a soda... it's a caffeine delivery device!
See subject. This may be a fun exercise for the programmers. Don't expect it to catch on, though.
/System/Settings/BootScripts/Reboot, /System/Devices, /System/Status..... Is there a /Winnt/System32 too?
plz?
First Link:
:-)
/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). /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. /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.
/Programs/XFree86/4.3/ and /System/Settings/BootScripts/Reboot. Like it? Read more...
/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. :)
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,
* 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
* 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
Second Link:
Overview
GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy. In GoboLinux we have paths such as
News
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
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 gobolinux.org 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
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Brace yourselves for all the posts from Mac iDiots saying "bah, Apple invented the word 'Programs', this is just a bad copy of Mac(ac)OS X".
I wonder if the designer of this filesystem has
ever used a shell with case senseitive filesystems
Not the mentions the case problems that it could cause trying to make programs more portable.
At least i know i wont be using it.
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.
...since my servers are named after the Fraggles...
gobo is my mailserver, boober is the fileserver, boober is my printserver and red is my web surfing machine.
Just my 2-radishes-worth...
RickTheWizKid
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
Maybe we should have a file system like Windows, such as: /XFree86 /Program Files /Documents and Settings
/bin /sbin /usr/local/bin /usr/local/sbin /etc /lost+found ??!!! It's so confusing trying to figure out what goes where. And when they ask for help, someone tells them to just do a "rm -rf" in the root directory. Brilliant!! Part of Linux's problem is its insane file structure. Even I can't find things sometimes, or at least wonder why in the world some things are where they are. Couple that with the fact that every distro sticks things in different places and you've got a real mess on your hands. Just look at the state on fonts on XFree86. Why do we need so many font directories?
etc...
It would sure simplify system adminstration for those coming from a Windows background. Do you know how confusing for a newbie it is to see directories like
What do you care if people in a different city have different streets? It's not like anyone's forcing you to move there.
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/ld.so.conf 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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Apparently, with the current "streetnames," only .1% of people know how to get there right now. Why not make the directions readable so the rest of the world can share too?
Oh yes.. i think this could be some real step forward to make Linux more accessible to the 'normal' low-end user... I am looking forward to more positive changes like that with further evolving of Linux distributions...
Spelling errors were made for your amusement only...
in other locales will the directory structure still be in english?
By making the layout different from other distros, GoboLinux effectivly locks in its users to its (and derived) system by denying them skills transferable to other Linux's
Does this matter? Probably not either people will use it (and at a wild guess there the sort turned off by the cryptic Linux argo and thus new recruits to Open Source) or it will be road kill on the information superhighway
The OS should be case-insensitive. Nobody in real life thinks that 'Cat', 'cat', 'CAT', and 'cAt' are different words; why should they be different file names?
Now would anyone care to guess how many knee-jerk posts there will be, like "if you like a sane directory hierarchy, use OS X, ya weenie!" or "if it's not broke, don't fix it!" To which I respond, where do you keep your Mozilla plugins?
Much applause to the guys who were willing to think a little more critically about what we can do to make Linux just a little better.
I suspect this system will be quickly snubbed by the Linux elite who actually spent days and hours learning the arcane Unix/Linux directory structure. (The "We've all mastered it the hard way, so you should too!" mentality). This mentality is so pervasive on Slashdot. Every time someone says something the tiniest bit negative about Linux usability, a bunch of people post comments to the tune of "Linux isn't for inexperienced people like you" or "Go back to Windows" etc. This kind of thinking is part o what is keeping Linux out the mainstream. What's odd is that many of these same people espouse the Mac OS X for its ease of use and simplicity of design. "It's so easy even my grandmother can use it!" they say. But if they curse their grandmother for trying to use Linux because she's not skilled enough. Huh??
What, we give AOL a bittorrent link for animatrix but we can't help these guys out? .torrent yet?
Anybody find a
my other penis is a vagina
Kuro5hin also has a good article on GoboLinux.
One of things I like about the Unix filesystem is that all important system files are separate from user accessible files. Maybe I havent fully grasped how the current file system is setup, but I was under the impression that is the way it is to keep important files far far away from meaningless files installed from non critical apps.
The only thing they have actually done new is initialization procedure, according to the article. Or they think that I'll set up a new system just because of new weird paths?
I guess this distro is still "Yet another... "
May Peace Prevail On Earth
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! :)
--
One by one the penguins steal my sanity...
You should move to Edmonton, Alberta. The streets are (nearly) all numbered, with "streets" running north-south and increasing in number to the west, and "avenues" running east-west and increasing in number to the north. So, for example, 1st street and 1st avenue is in the extreme southeast corner. 100th street and 100th avenue (where they started the numbering system, giving themselves room to expand) is downtown. Edmonton is large enough now that they have to go with a directional system to expand to the southeast (e.g., 5th street NW, etc.). If you're paying attention, it's virtually impossible to get lost.
... and I can say this because I grew up there ... this probably happened because Edmonton is utterly bereft of heroes, so there's nobody to name things after. One of the most major traffic arteries in town is Wayne Gretzky Drive, after the hockey player who won four championships with the Edmonton Oilers. (Imagine Chicago changing the name of a major highway to Michael Jordan Boulevard.) Before that, for decades it was called the Capilano Freeway, since Capilano was the name of the construction company that built it. The names of other highways in town are the "Yellowhead" and "Whitemud", which I believe have aboriginal significance.
While on this topic
Toronto-area transit rider? Rate your ride.
Yeah,, yeah, standards are good, you have many to choose from.
sgis ddo ekil t'nod i
I know the unix file hierarchy well, but I've always thought it was arranged haphazardly. Why are there six different places for system executables? (/bin, /sbin, /usr/bin,/usr/sbin, /usr/local/bin, /usr/local/sbin)? That's not even counting the alternative directories that some programs like to be installed under like /opt, or X11 programs.
The one thing I don't like is that they renamed root to gobo. While root doesn't have much inherent meaning to it, gobo has even less. If you're going to rename root, why not pick something more meaningfull like administrator, admin, superuser, BigManWithTheTopHat, etc? I guess I haven't checked recently, but is linux still limited to 8 characters for the username?
AccountKiller
Also available for purchase here
It's this type of attitude that keeps Linux away from newbies and wanna be converts. The poster wants to make things simpler for the 95% people of the world who, by their own choice or not, use Windows and are the most comfortable with it. You, by your own admission, state that the Windows file system is easy to use, but then blast the poster for wanting to make Linux easier in the same way. The Windows system, while not perfect, works quite well. The Linux world, however, is obsessed with reinventing the wheel, unconvinced that something they didn't invent could possibly be easier or better! Oh, I'm sorry... I guess I forgot that Linux forever has to have a steep learning curve. That way the Linux elites can feel special about their skills and fluant them over other users. Meanwhile, all along they proclaim how the demise of Gate's empire is just around the corner. Get real!!
Hey we were here first!
Both arguments are stupid. They are different for a reason.
That said however, I DON'T agree that we need to drift away from the Unix-ish standard for Linux type distro.. that is only asking for incompatibilities and troubles.
---- Booth was a patriot ----
Bringing Linux 2003 up to par with Mac OS X 1999!
There was an old and little known linux distribution called cLIeNUX which did something similar. Not sure if it's still alive though.
It's not the responsibility of a distro builder to teach you to use Linux or, even moreso, teach you to use another Linux distro.
Certainly, OS X doesn't teach you to use FreeBSD. Is that a problem?
http://www.kuro5hin.org/story/2003/5/9/05015/62649
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;
GAH! If I wanted to use Apple's fucked up filesystem, heierarchy, I'd use Mac OS X. But I suppose as long as these idiots don't go influencing the Linux FHS, I'll be happy.
How appropriate- MI6's Agent 006 was a traitor.
I like my filesystems shaken up, not stirred.
Please help metamoderate.
From page:
;)
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".
And default username should be changed to "luser" o "dumbass" or something like this
Today is not April Fool's Day, what those guys are smoking?
:wq
If you think the Unix filesystem isn't a mess currently, then either you have to look again, or you're using a floppy distro under 2 meg in size.
Even when you know what each directory is meant to have in, which the rather excellent LFS is good at doing, it's still an awful system. In fact, if you know where everything goes and why, it's even harder not to consider it a bad system. Unix was alright in its day, and certainly better than some other popular operating systems around now, but I'd hardly claim that the standard filesystem for Unixes is anything but a hack upon a hack upon a hack.
Personally, I really liked the idea of reorganising directory structure. Unix isn't perfect, and can, in many, many, many ways be improved.
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.
I agree with bazik's comment that finding the superuser account's name is one more obstacle to crackers.
Will I retire or break 10K?
The website gobolinux.org is currently hosted on a very "humble" server. If anybody is able to make any mirrors (especially for the ISO image), please do so. We were arranging some mirrors when we posted on Kuro5hin, but as probably always happens to everyone, we were not ready for Slashdot yet. If you want to help, drop a message to lucasvr(at)terra.com.br and we'll arrange something. Thanks!
What I would really like to see is a change to the init. Instead of starting one script at a time and having to work out the dependencies using starting numbers embedded in names, and working with runlevels using symlinks why not have a system where multiple daemons could be started at once, startup order determined on the fly and all runlevels are defined in files. This might make for quicker startup times and a cleaner system.
I think netBSD has a system like this, perhaps a linux distribution (debian?) should look into it.
What does Linus think? :)
If anybody is able to make any mirrors (especially for the ISO image), please do so.
Try BitTorrent. If you can get a .torrent up for the ISO, the bandwidth use will go down.
--
Will I retire or break 10K?
What is so funny about "/Winnt/System32?" What an obvious and unclever joke. Slashbots fall over themselves trying to mod up stuff like this.
Haha. "/Winnt/System32." That's funny.
"Sufferin' succotash."
Really? /S/L/Shared? Maybe we should make a symlink to that... Perhaps even a whole network of symlinks, with short, convenient names: lower-case, easy-to-type, and easy to remember! ;)
[Disclaimer: You can mod me down, but I really do like this idea... if only it didn't break all of the existing binary packages ever written. ;)]
-Dan
When I moderate, I only use "-1, Overrated". That way, I never get meta-moderated!
/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
.org, .net and .com have lost their meanings.
Of course many modern lunix distributions break this by placing files wherever people think is cute, much like how the
--- I do not moderate.
The idea of setting up an easier filesystem is not new - and I think it can be really very advantageous - if only for promoting desktop usage. Using caps in directory names however should not be allowed atleast on the root and system levels. I have been using linux for the past 3 and half years, so I have become quite used to the current file systems, but I still don't know what /etc/ stands for (like /usr = "user") or why there is not a standard application directories (/usr/share/, /usr/local/share/, /opt/ ...)
It seems to me that all they've done is replace one set of hardcoded directory names with another. Whether you have /usr/X11R6 or /Packages/XFree86 makes very little difference.
The trouble with the Unix filesystem is that it makes it hard to install and uninstall software, because the files for an application are scattered all over the place. Package managers like RPM work around this problem a bit - and indeed if you are stuck with the conventional filesystem layout then using RPM or dpkg is the best option - but there is no easy or intuitive view of the packages installed.
This leads to user interfaces and desktop environments which try to hide the filesystem from users. Windows mas 'My Documents' and all that, not giving any clue where My Documents really is on the disk; Unix desktop environments aren't usually that bad but still they don't dare to just show the root of the filesystem to the user, or even to show by default a complete view of the user's home directory (because there are 'hidden' files scattered around it like confetti).
The Mac OS X or ROX-desktop approach is better; an application is contained in its own directory, installing an application is just copying it and uninstalling is just deleting. On RISC OS (which ROX spritually inherits from) I used to arrange my applications by task, so drawing apps would be in one directory and music apps in another. Often the apps and the files they operated on would be in the same directory, but this is of course up to the user. Then there is no 'start menu' or similar layered brokeness trying to disentangle the different applications into a meaningful hierarchy - you just move apps around to where you want them. So the root directory of the hard disk would have Drawing and Music subdirectories.
I think this is the key point, BTW - if you ever find yourself building some tree-structured abstraction on top of the filesystem in an attempt to make life easier for users, you should stop and ask whether the filesytem itself couldn't handle the job better. This applies to Start Menu, My Computer, and their imitators in Unix world. It also kinda applies to the Windows registry, another case where Microsoft reinvented a new tree structure instead of using the filesytem.
Now I should say I'm not a big fan of the ROX approach *at present*. I think it is too confusing to have a mixture of conventional RPM-installed apps and application directories on the same system, and it would be better to have some smoother transition, such as being able to treat uninstalled RPM packages as application directories and double-click to run them. But if a whole distribution took the appdirs approach, it would rock.
There are questions about how to make _everything_ installable, deletable and movable just by dragging things around the filesystem. How do you handle shared libraries? What about multi-user systems where two users will want different arrangements of applications? (For that I'd say user symlinks, and yes, they should be exposed to the user as part of the GUI.)
-- Ed Avis ed@membled.com
Legacy and Propeitry apps won't like this layout, especially as they use hard coded paths to layout their files. Building packages will be hard too, as they traditionally go into /usr/local by default.
Rethinking the filesystem is something more like the long overdue database filesystems; filesystems where objects are not restricted to directories but can be properly described, filesystems where applications are not left to guess the type of object by the extension (the crudest possible method).
Why does it take 2 minutes for me to search for a file XYZ using 'find' or the Windows equivalent when I don't know it's location?
Why can I rename a file and hence it cannot be opened by a default program?
There's a lot of issues with filesystems today, Windows, Unix, and everything else.
In my opinion, the naming conventions is among the least of them. This distribution will probably fail because it'll prove too much, having to patch so much software.
Since the site is down, I can't give you a link, but one of the files used when installing GoboLinux allows you to set the directory names for everything.
/Programs
/Programme Dateien
They did this because originally GoboLinux was ment to run in user space. I can have an entire goboLinux install in my home directory. So in that case, I'd set:
$GOBO_PROGRAMS_DIR = ~/MyPrograms
To simplify a long story, all they did to make it a real linux distro was to change the one file that set all these variables. So the new line would be:
$GOBO_PROGRAMS_DIR =
Of course, if you live in Germany, and you can change that line to:
$GOBO_PROGRAMS_DIR =
(I used BabelFish, so excuse the translation of "Program Files". The system variable name isn't $GOBO_PROGRAMS_DIR either, but again, the site was down.)
So yes, GoboLinux does support multiple locales.
Mosfet, creator of many things Unix-wise, well known for his KDE work, wrote this article about file system structure in 2001.
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.
Perhaps the most interesting thought regarding this is that if it were Windows, people would be ragging on it left and right. Microsoft and its "haphazard" filesystem with "six different places for system executables."
But it's Linux, so it's okay because there's a so-called filesystem standard.
"Sufferin' succotash."
"If stupid people were kept away from keyboards and stayed at home in front of a TV set where they belong and left the computing world to those that understand it, things would go smoother, there would be less computer problems,far less virus problems, much less IT support time wasted, and business would save a lot of money.."
.....
Yeah and you would still have to play with a TRS80 as a computer because stupid people is the mass and without the mass buying puter you will pay 8000$ for a puter(trs80) instead of a P4 3gig for 800$
"I fail to see why computers should be dumbed down for the dumb. It makes no sense."
maybe it just because you are like the mass, to STUPID to understand you have a closed mind! so you must not be allowed to see why
To which I respond, in "/Library/Internet Plug-Ins" (the same place as I keep the plugins for all my browsers). This is Mac OS X, so I don't see what your point is about the system.
I would have liked to respond, "Where not?" but you can't be clever twice about that sort of thing.
A decibel - a RELATIONSHIP between two values of POWER http://arts.ucsc.edu/EMS/Music/tech_background/TE-
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
SoftMaker Office for Windows|Linux|Android
RiscOS and Next/OSX do this "the right way". BeOS did this too. On all this system you could move applications around at will, and used the filesystem to arrange the applications, as God intended. Add BeFS MIME typing and live queries, and we have a winner.
J.
execvp()/execlp() can be changed transparently to work with this library. Another advantage is that if the library implements some sort of conflict resolution, we can do away with the alternatives kludge for choosing from multiple packages implementing the same function (LPRng/CUPS, sendmail/postfix, etc). Might also have minor advantages such as dealing with other obscure things such as the dot-first-in-PATH trap.
Just what we need. Linux distributions named after Fraggles.
I have a better question. Why is the filesystem even exposed? You can't complain about what you can not see. A DB with a vFolder view would be better. The user, power and newbie alike can dictate whatever they want. Hierarchical, flat, long names, short, the user is in control. Or to be more advanced since the filesystem is a storage space for data ending up to be used by applications (view, create, delete, modify). You pick the application that most reflects what your intentions are, and then retrieve what you need. Maybe the vFolder view makes an apperance here (Music classified by genre, artist, etc).
This is interesting, but it really doesn't get there. Mind you, I have always been a large advocate of changing the unix file structure: It is a messy, disguisting frankenstein of combinations from the old unix system days, that even experienced unix hackers get messed up in. Hell, until I got a book on porting unix software, -I- didn't know how the unix file structure was defined, and I've been doing this for 5 years!
/usr/local for BSD, the same one is supposed to be in /opt/bin for SysV. It's a mess!
As for the "Frankenstein" description, consider this: When a file is supposed to be in
What needs to happen is that a new STANDARD needs to come out, and everybody needs to support it. Of course, nobody will ever support new standards, so that's out of the question, but if you really want to improve the unix file structure you have to do that. Anything less than that, and you're simply adding to the fragmentation problem.
Finally, there are two technical problems with this guy's method, too. Firstly, all the directories use Capital letters, which is unneccessary for clarification, AND makes it harder to type. Same goes for the full name of the folders: reducing "Executables" to "exe" would be just as recognizable, AND a lot easier to deal with in a shell command.
HoMoLinux....
I figure RedHat would try to be more like Windows first...but it seems these guys jumped on the bandwagon early.
-Rob
I've been using computers since 1995 and I have been astounded by the advances linux has made in this time. Once a hobbyists dream and an alternative for the hardcore, linux has now become a viable solution in the server market. Built upon years of transparency and the input of whoever the hell wanted to; a robust, efficient and competitive operating system is now within the hands of the many. Linux is thriving in the server market and emerging as a potential saviour to the corporate desktop market, but it is still miles away from becoming a viable desktop operating system for the masses. There needs to be a solution for the average joe, the technologically illiterate and the avid tinkerer. This is where linux loses ground to the mainstream operating systems. The quirks and technicalities that are pervasive in the linux operating system only serves to confuse and bewilder those who want to actually do something with their system. Sure a pretty desktop and application support is a good thing, and I'm astounded by how far linux has come, but it is when the user delves below this thin veneer that the alienation and obfuscation begin. A user wants to trust his system; not to know it inside and out, but in some obscure way understand his system. When presented with the nightmare that is root, all trust and all understanding is promptly thrown out of the window. Simple efforts like the accomplishments of the GoboLinux team is what will bring Linux to the masses. Removing the complexities at the cost of security is a small price to pay when security is not of the utmost importance. Presenting an understandable operating system is of the utmost importance. Bring us a logical file system, bring us file extensions; bring us, those who don't desire to become guru's yet who still want some understanding, the linux kernel. It is robust, efficient, secure, trusted, viable and an undeniable success in the server market. All it needs is developers who understand the requirements of the masses and linux will truly dominate.
I've seen some comments on how the various acronyms in the Linux filesystem make using Linux difficult for newbies, and how they can be confusing for people.
Can someone tell me what happened to LEARNING? If you're new to Linux then you've got to learn a few new things. The file system hierarchy (which isn't in need of improvement) being one of those things.
If you want to have some whacked out names for your directories, then do that in your home directory. The average user shouldn't even need to worry about root file system directories. When applications are installed, the binaries go to the right place (and are in $PATH, so you don't need to go find them), libraries go in the right and standard place, so programs know where to find them, (etc..).
There's a reason the file system is the way it is, and it doesn't need changing. It's just one of the things that goes along with learning a different operating system.
-kidlinux.
It is an act of futility to so dramatically change the linux file system. Uptake on this will be very small, and (alas) eventually this distro will just fade away. Worse, yet, is that new linux users that try this as their first distro will find that they will get almost no help from more experienced linux users. Frustration and ridicule will set in, and a linux newbie will realize that they have wasted their time and will (1) have to start all over again, or (2) move to another OS (MS, Apple, etc.). E.
With the power of modern computers this would make no difference to execution time, but then those who used the old skool conventions would be happy and newer users could have a more intuitive system.
Either the system could work out what to execute or you could even switch between filesystems with a command.
On top of this, at installation you could pick which system you wanted to use (or even define your own).
This idea was invented by Shampoo.
You have no right to judge how people live their lives. Disagree if you want, but don't go feeling all smug and supperior because you're doing something that other people aren't. That's just ego stroking over your hobby.
Do you understand anything about people? Different people are different in different ways. While you may like to think that people don't want to sit down and understand are stupid, you're ignoring people who don't have time for things, or simply aren't interested in learning something. Part of how humanity has moved forward (besides designing tools that reduce work by not forcing you to spend years in university for every appliance you own), is by specialization. I can't know everything about everything if I want to get anywhere in life. As early as grade 9 I need to start specializing the classes I take towards an eventual career if I want to be in that career by my mid-20s.
If thinking you're better than other people because you know about computers is how you base your fragile ego, I really want you to go outside into the real world and do some growing up. Your intollerance is disgusting. Grow up. No one is better or worse than anyone else because of what they know, people are only better or worse because of how they act. Your actions leave much to be desired.
People like you are the reason that most people stop reading Slashdot or Kuro5hin.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
The short names /etc /bin /usr etc need little typing.
Carpal tunnel and other work-related upper limb conditions are an occuaptional hazard of people who work with keyboards a lot.
Giving it longer names makes this more likely.
"Maybe we should have a file system like Windows, such as: /XFree86 /Program Files /Documents and Settings"
Isn't it a bit "arrogant" for Windows (former or otherwise) to expect the world to conform to them?[2]
Why not change the Unix FS hierarchie for those moving from other platforms to Unix? i.e Amiga, Acorn, OS9, etc.
And what about other non-Unix platforms? If Windows users start moving there, should changes also be made?
How about everyone else moving to Windows, can we demand that you all change your filesystem?
Basically the only thing some Windows users are bringing to the table is "Design by popularity[1]" rather than "Design by good engineering", and there's a long Windows history to show how much of a pain that's caused.
[1] Popularity is really stretching it considering past history, but even that doesn't cause former users to question the wisdom of the decisions that made them leave in the first place.
[2] history is littered with the corpses of cultures "dominated" by a "popular" culture.
Maybe it's time for the "Indians" to move on before the "Settlers" start breaking out the blankets.
In my town we have a mirrored setup, 4th street and south 4th. That way we can expand all that we want too. I once lost control on south 4th and dove over the median, the other lane, and down a hill, while spinning around. And then drove through a fence.
autopr0n is like, down and stuff.
...and GNUstep, which is the same system as OSX. Well, I also looked at the GNUstep built app stuff and the complications under the hood are pretty convoluted, but at least it hides the complexity. Binary distribution seems pretty straightforward - there's AppName.app directory tree that can be tarred and untarred under /Local/Applications. Very neat. Now, if only the whole development environment would be >1.0 and there would be some *good* documentation... oh, yeah, more actually working applications would do no harm either.
I LOVE ROUNDABOUTS. When playing GTA3 it really annoys me how there are no roundabouts, the driving on the wrong side of the road I can get used to but considering that the game is made in Scotland the devs really should put some sort of hidden level in there!
There is no god
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.
Stop-Prism.org: Opt Out of Surveillance
What are they going to do next? Change our intuitive utility names like grep, ls, rm, tail, mv, and fsck? What the hell is the world coming to?!?! We'll actually have users trying to use these utilities instead of referring to the oh so helpfully named man pages or just giving up all together...
The world is truly coming to an end.
I think this is a very good idea. I'm sure some of the former (current?) BeOS users will have a bond with this filesystem layout. Beos had a layout somewhat like this and I loved the way it was easy to navagate. Hey, it could even help out some opened BeOS projects like B.E.OS and Cosmoe
It's a great response!
Mutation and evolution is what Linux stands for, otherwise, why is there 6 billion linux distrobutions?!
Change is good, if you don`t like it you don`t choose it, but i think every distrobution needs something to say "this is why you should choose us" well done to the gobolinux team for having the balls to try this out.
-relik
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).
/apps/[appname]
/apps/[bin,lib,doc,conf] if you wish, like Stow does.
/sbin) live in a mirror structure at: /sys/[appname]
/sys dir.
/etc.
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:
[appname]/[bin,lib,doc,conf]
All user applications live in:
You may choose to symlink the nested app dirs into
All "system" apps (e.g. stuff that is typically in
Again, any utility binaries or common libs *may* be symlinked into the base
Application configuration would live with each app, no more throwing every fscking config file into the mud pit of
Things like 'man' would index *into* the seperate app dirs, not the other way around.
It's 10 PM. Do you know if you're un-American?
Really an idea from VMS: you define a directory as a path. When you look in it, it shows all the items in that path, using the first one it gets to.
/bin => /bin:/usr/bin:/usr/local/bin...
so
Unfortunately, it does make the filesystem slow. It was especially bad for VMS when you got more than a few hundred files in a diretory when you listed it (it would take SECONDS to print each file when I had ~500 files).
Try the patch, you may like it.
This seems very much like what Apple have done with Mac OS X. It's not a bad idea for end users, but a really bad idea for any UNIX people that have to administrate things. I would suggest though following more closely Apple's lead on this in that the standard system software sites in its normal locations (/etc, /usr, /bin, etc) and then user-level applications and files sit in new directories following a similar naming scheme to Gobo - /Users /Applications etc. I like in UNIX the /usr/local convention for additionally (non-system) installed software. Dunno, I don't think it's that complicated anyway at the moment, apart from a bit disorganised - telling someone that their files are in /home/username makes a lot of sense, binary things in /bin is cool, and that there's loads of other random stuff in /etc makes sense too. Don't know whether it's really needed in the end. Changing the root username is just plain daft really. Sorry! Lastly, being British, I would like a very customised with the programmes in /Programmes please.
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.
"Freedom is letting people do things that you don't like." -Linus Torvalds
Some of the oganizing principles:
1. All (non-imported)
pieces of one app/library are under a single parent directory (modularity).
2. There is a single standard name for the
root of all apps/libs.
3. A given app/lib has to be in a dir named according
to its proper name and its provenance (as in java class/package/dir-location restrictions.)
4. There must also be a standard URI (includes mirrors) at which the "official" version
of any app/lib's code lives on the net.
5. Versioning will be handled in a standard
naming convention added to the above rules.
6. OS can operate with multiple versions of
given apps/libs in filesystem. Apps/libs that
need to link/interoperate with different
versions of other apps/libs can happily
co-exist. If the version they need isn't on
local disk, the OS automatically grabs it
from the appropriate standard URI, caches
it in standard location on local disk, and
links it.
Where are we going and why are we in a handbasket?
I have concluded that beyond the trivial, trees have outgrown their usefulness in file systems. Trees force static, artificial taxonomies on things which really need a more flexible, multi-perspective (multi-factor) way of looking at them.
I have been kicking around set-based file systems, possibly built around relational technology. Microsoft has been kicking around the death of trees also in their future file systems.
Table-ized A.I.
The current filesystem is not exactly difficule, and if any distro wants to change it, why the hell didn't they use symlinks to do it?
/programs and /usr/bin in paralell, rather than f^king things up for people who know exactly what the old names mean and where to find them, thank you very much.
/etc, user stuff is in ~/.etc.
That way they could have run
The only change that I would like to see, that can't really be accomplised with symlinks (although I have it this way on my LFS box) is to put all user config stuff in ~/.etc, and other dirs to clean up my home dir and emulate the system wide file system. _That_ would make life easier for new users, as their own local stuff would look the same as the system wide stuff, just system things are in
Beep beep.
... for GUI applications, similar to that on MacOS X, will go along way toward helping Linux on the desktop.
By your same contention, what is the advantage of separating the "Windows" (/usr) and "Program Files" (/opt, /usr/local) directories on WinXX? Why not just put everything in "Windows"?
Oh, you don't want application programs clobbering the system files? Gee, I guess that's why *nix does the same thing (and did it first!)
It's not an issue of not wanting to consider alternatives, but the overhead and effort involved in making such changes just to appease users of a foreign environment (WinXX.) Would you consider it "staunch unwillingness" when Ford and GM use different dashboard or engine designs? Could it possibly be that they are competitors not imitators?
On a side note, do most WinXX users have any idea where their menu and desktop items link to? The user just clicks an icon or selects a menu item, and the program runs -- the same as KDE or Gnome. Why would the user give a damn whether it's running out of /opt/myutil or "/Program Files/MyUtil"? Hell, most WinXX users I know don't even partition their drive -- everything goes wherever installer suggests as a default (99% C:).
I do not fail; I succeed at finding out what does not work.
Let's face it. Those of us with jobs in the computer field have them because of all of the playing around we did with computers/OS's/languages/networking at home.
Bad move for the community, gobolinux.
This is what is wrong with this distro.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Maybe distro developers could try creating better ways of teaching the Linux directory structure instead of changing it. For example, a sidepane that appears in folder windows, describing the purpose of the folder currently being viewed. Or perhaps Windows-esque "tooltips" appearing over color-coded system folders that provide similar information. Both methods would be infinitely more convenient than constantly referring to documentation.
The directory structure in Linux is one of the biggest shocks to experienced Windows users who are accustomed to navigating the files and folders of Windows, and its complexity is a major area that needs to addressed if Linux is to make gains in the desktop arena.
Personally, I think it sounds like a great idea. If you're putting together a desktop system, there's really no need to carry around the old UNIX cruft. Honestly. And as much as the fanboys jizz all over OS X, I'd think this would be a welcome change. I suppose if this came with a system capable of real translucency and drop shadows, the l33t boyz would be jizzing instead of bitching, eh?
Stating on Slashdot that I like cheese since 1997.
Do these problems really exist? are they bad? Can we have some real evidence instead of just opinion.
--
Simon
The ultimate test of which file system is the best is the one that results in the fewest duplicate slashdot posts.
Table-ized A.I.
One thing that's always irritated me with linux is how difficult it can be to REMOVE an application. By default, most things tend to install their executables into /usr/local/bin or even /usr/bin or /bin - the problem here is that we end up with one directory with potentionally hundreds of unrelated binaries in it.
./configure/make/make install, and then realise I forgot to specifically set the --prefix on configure, it's already too late. I've come across very very few Makefiles that have an uninstall target, and thus let me uninstall them.
This is all well and good for the things that come with the OS - like cat and top and diff etc, but when I install another app with
The obvious reply to this is to say 'use the package manager!', and this would be fine if everything I installed came as a package (and if the package manager in slackware was nice.)
I guess it comes down to the individual distros to make their own package managers (rpm etc) to deal with this problem.
In windows, apps love to install to \program files\company\app name\, (some of the more badly behaved ones also like to install dlls into system32 etc), and installshield, or MSI, or whatever, create an uninstall script at the time of installation.
I think this is one of the bigger stumbling blocks that linux needs to overcome to gain wider acceptance - if joe public can't install a new app, try it, and then if they don't like it, remove it *cleanly and easily*, then they're never going to use a linux system.
I think that the autogenerated Makefile that most tgz files use should always contain an uninstall target, and that it is regarded as being just as important as the install target.
You mention that the *nix file structure is the way it is for effeciency, and that it has been around for ~30 years.
30 years ago, finding an executable program or a library was important, and keeping them all in one place was one way of reducing a couple of k's of memory requirement.
Thankfully this is 2003 and ram is cheaper now, so such worries are nicely behind us. Perhaps now we can keep programs together in a logical way.
___
Cogito cogito, ergo cogito sum.
I'm an English expatriate living in Boulder, Colorado, USA. There are four of five roundabouts that I'm aware of in the state. All on small backroads, single-lane, lots of warning signs. Horrible traffic lights at 99% of the junctions, particularly the larger ones.
You end up choosing routes through the town based on the probability of hitting a red light - going in a particular circular flow because you know there's a chance you'll have a 2 minute wait if you go the other and need to make a left-turn through traffic.
The only slightly redeeming feature is that right-turn-on-red (equivalent of left-turn in the UK) kicks ass. Permitting undertaking and not having to drive on the right (left in the UK) on a multi-lane highway is sheer torture if you get stuck behind slow-moving traffic blocking both lanes.
For the love of god, I never thought I'd miss roundabouts so much. They solve so many traffic conjestion problems at junctions. But they couldn't build the damn things here because the average beginning American driver has a level of driver's ed that makes me blush and would crash and burn at the first complex multi-lane roundabout they encountered. Sigh.
export MOZ_PLUGIN_PATH=/usr/local/mozplugins
/usr/local/mozilla without having to reinstall my plugins all the time, and unlike most of the locations you listed, I know where they are because I put them there myself. However, I didn't realize that /usr/lib/mozilla/plugins exists already (I wonder how it got there?) so perhaps I should use that instead.
This allows me to upgrade Mozilla in
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
>>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
This is why Linux will never succeed on the desktop. The guy is making a change that could improve usability. It may work. It may not. But before it is given a chance to succeed, all sorts of losers come out of the woodwork and denounce him for even trying.
That is all. In general, the system will have an admin only area, an area for applications, and an area for users. What else do you need?
some of their location choices and even filenames remind me very much of BeOS.
You know you've really become a command-line snob when you catch yourself dismissing a system of descriptive filenames as a "needless GUI"
Click on parent and the posts have more room to spread out properly in the resulting view.
I like the idea of Gobo Linux, I'm just not very impressed by the implementation. I really think that some of the 20 year old UNIX crustiness should be scraped off the top, but slapping symlinks all over the place seems sort of like a recipe for disaster to me.
"Think you can take me? Go ahead on. It's your move." --Joe Don Baker in Final Justice
in share you dont store any binarys !! doh!
(binarys as in runable or lodabel librarys)
CIA Factbook 2002 (US):"Since 1975, practically all the gains in household income have gone to the top 20% of households
Microsoft tried that approach, and we all know what a total mess any and all windows systems are after a few months and a couple installations and removals of software.
./configure and Makefile install)", they would've worked with links and retained compatability. Or better yet, left the filesystem alone and added an abstraction layer on top of it.
And if they had put some thought into this instead of playing "look ma', I can rename files (and break pretty much every
There's a ton of not-yet-very-much-implemented innovations in the filesystem area, from document-oriented approaches to database-like systems (instead of the hierarchical ones we use currently).
Assorted stuff I do sometimes: Lemuria.org
That's supposed to be read /System/Links/Shared. That kind of abbreviation is just a jargon from the GoboLinux mailing list. That's because we use tab-completion, you know, we just type "s", "tab", "l", "tab" and we're there. And in case you're wondering, yes, that's case-insensitive tab-completion. We're not "Shift key" addicts.
Hi!
Einstein stated the first law of sotware engineering, "Make something as simple as possible, but no simpler."
There is some notion in some of the threads here that perhaps a file system can be made simpler than it really is. The file system is a very complicated roadmap to the computer.
Anyone who claims that something with hundreds of thousands of files can be made "simple of enough for user who doesn't know computers" is sadly misdirected and misinformed.
The second law of software engineering is "you have to be careful if you don't know where you are going because you might not get there."
-Yogi Berra
Cheers!
-Mybrid
There it says you can change it to whatever you like. Surprisingly, even "root".
The superuser-name convention is one of those conventions that's so deep in the community that people think that's a religious law. In the future, it will probably ask in the installation whether you want to use 'root', 'gobo' or something else.
Why can't the filesystem just do _that_ in the first place then? The filesystem itself is largely an abstraction -- the computer basically just cares about what sectors on the disk to read. No reason why the fs can't be better designed for users.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
So there are two directory structures in Darwin. /usr, /etc, /var, etc, and the structure that's designed to work with dynamically loaded bundles through the CFBundle API.
In short, a bundle is not a file. A bundle is an organized directory of files. It contains executables (one executable for each platform the bundle is compiled for, PPC-code in the MacOS directory, x86 in the Windows directory), localized resources (in Resources, Resources/en, etc), and meta info explaining what kind of bundle the directory is (in an xml file in the root of the bundle, describing it as a application, startup item, kernel extension, app plugin, framework (shared lib & headers), etc), and more.
There's not much point of messing up the traditional Unix file system layout. It works, and it's perfectly serviceable. Simplicity is a virtue, and Darwin does use it for very core uses (ie. first stage of booting and single-user mode). The bundle-based file system layout is something like this (I'm adding /Local, which was in Rhapsody, but merged into / in Darwin for simplicity and to avoid confusing users).
So, /Local contains dynamically loadable resources on the local machine, /Network are things on the network, /System are things that are only part of the operating system. When you do a 'global' search for a resource, the search path is to search for resources in $HOME, then /Local, then /Network, then finally /System.
Within a bundle tree (tree, domain, whatever they're called, /Local, /Network, etc), there's a typical layout. Here's an example of /Local (/ in Darwin),
Naturally, /Applications would contain executable bundles that are GUI applications. Think about this for a moment. This is a simplified example/implementation, but if the user wants to launch the application associated with 'http:', the OS would first look in $HOME/Applications, then /Local/Applications, then /Network/Applications, then /System/Applications. Cool huh? (Again, that's simplified. Actual application finding is handled by Launch Services; applications can be stored anywhere on the hard drive. But this is part of the search criteria.). /Applications is the bundle counterpart for GUI 'bin'. For actual command-line tools, Darwin does use /usr/bin, but Apple also uses Tools for some of its Developer package extras (and this is not handled by Launch Services, put blah/Tools in your $PATH in your zshrc. Unix acts like Unix.).
Application Support - folders like Microsoft, Adobe, for app-specific resources. Often in $HOME /System /usr/lib AND corresponding
Audio
Caches
ColorSync
Contextual Menu Items
Filesystems - ftp.fs, hfs.fs, msdos.fs, udf.fs, ufs.fs, all are bundles. These ones are actually in
Fonts
Frameworks - these are bundles that equate to
Moderators should have to take a reading comprehension test.
Congratulations on your plan, Gobo!
/home to /users.
I first read the LSB hoping for an understanding of some of the esoteric Unix paths, and there were some reasonings. However, the LSB was mostly an excuse to keep things the way they were with no explanation.
The *real* reason Unix is so messy is because various groups have been slopping things around for 30 years. It's time for a refactoring!
Having said that, I have 2 suggestions:
1. keep path names lower-case for easier typing
2. don't change something that serves a reasonable purpose just because you don't like the name. e.g. don't change
Great job!
During the 80s, the UNIX with the biggest user base was... XENIX (made by none other than Microsoft), which was later sold to SCO, and which was one of the systems used as a basis for the POSIX standard. NT (and, subsequently, W2K and XP) does comply with a big chunk of the POSIX standard (I suspect one of the reasons was to make it easier to port software from Xenix to NT - Microsoft didn't want to lose market share to the other UNIXes). In some ways, though, NT is closer to VMS than to XENIX.
D =97&ArticleID=4500
D =97&ArticleID=449
Two old but interesting articles about the evolution of NT:
http://www.winntmag.com/Articles/Index.cfm?IssueI
http://www.winntmag.com/Articles/Index.cfm?IssueI
NTFS has other nice features such as symbolic links, named streams, non-continuous files, etc.. I learned a few tricks a couple of years ago in a newsgroup discussion from a guy working at Microsoft. Some of these features appear to be completely undocumented (or at least the documentation is very well hidden).
RMN
~~~
What we have here is a tug of war between skilled technicians of the present who want to continue the knowledge gap they enjoy over users of systems, especially Linux systems, and ordinary users who want to have complete control over their machines. It's a contest of wills. The trend of computing has been to further and further decentralize power by putting tools in the hands of users at the expense of administrators, and designing those tools for ease of use for those with less and less training. GoboLinux seems to get that.
GoboLinux huh .. I want to see the Doozer fork of Debian .. the one with usability enhancements for 6 inch tall puppets.
Would RedHat be Linux for the Gourds ?
Would the windows gaming package be made in spirit of Wembly, Boober and Red.
I have no idea what version of linux Trash Heap would be.
I can say that the old man would probably be running Slackware 3.0 on some old box under a pile of crap in the workshop.
for your kind, thoughtful, considered and amiable response.
Yes, such a thing would definitely be possible. I know, because I've been using a system very much like that on my Solaris system since (let me check real quick...) Dec 21, 1997.
I have a directory called /packages. In that
directory, I have a separate directory for
each version of every package I have installed,
and a symlink to the default version. For
instance, /packages/gcc-2.95.3 and /packages/gcc-3.2 exist, and /packages/gcc is a symlink to gcc-2.95.3. (I should probably update
gcc, eh?)
I then have a big list of directories that should get merged into a big "everything" sort of directory. /usr/local is built
automatically by running a Perl script
against this list and /packages.
Thus, /usr/local/bin/gcc is linked to /packages/gcc/bin/gcc, which in turn
reaches /packages/gcc-2.95.3/bin/gcc
because of the symlink from gcc to gcc-2.95.3.
All in all, it works pretty well. Apart from helping me keep /usr/local
manageable and making it possible
to easily remove stuff without having to build
some sort of RPM or similar for everything
(since I always build from source), I've
found one of the big advantages is that
I can install a new version of some package
without deleting the other, and move back
to the old version if the new version has
problems. I can also keep them both and
use them both by changing PATH, etc.
Also, I don't have to rebuild everything when I upgrade a shared library, or any other file that a package depends on. For example, anything that uses the PNG library is linked against /packages/libpng,
and that is a symlink to /packages/libpng-1.0.5
right now. I can upgrade to a newer version
by building it and changing the symlink.
I'm in the process of inventing a more advanced scheme where dependencies between packages are more carefully managed so that, at install time, I can select what dependencies a package uses on a package-by-package basis, then change it later (again, on a package-by-package basis) without being forced to rebuild anything from source. All of this happens without special tools, except the one Perl script (which is very simple).
By the way, ultimately what you're talking about is, in effect, overcoming some weaknesses of hierarchies. Hierarchies make things simple, but they do have one bad effect: if you want to organize things by two separate criteria, you must arbitrarily choose which criterion is at a higher level in the hierarchy. For example, if you're organizing a bunch of photos, should you mkdir -p wedding/thumbs wedding/fullsize vacation/thumbs vacation/fullsize or should you mkdir -p thumbs/wedding thumbs/vacation fullsize/wedding fullsize/vacation? Hierarchies force you to make this decision arbitrarily. One could imagine a system where every file is tagged with attributes instead of grouped into directories. For example, the "gcc" executable could be tagged as "purpose=executable, package=gcc-3.2, name=gcc", and the GNU standard C library could be tagged as "purpose=shared-library, package=gcc-3.2, name=libstdc++". Then you could set your $PATH to "all files whose purpose is executable and whose package is a member of the set foo". When it came time to remove gcc, you could just rm "all files whose package is gcc-3.2". There are some problems with this scheme (who chooses the attribute names? they are all global. plus it feels like all your files are floating in a big soup, and how do you organize them onto different partitions?), but it might be worth investigating.
Yes, let's just up and agree that no one should ever innovate again.
By this logic, what the f are you doing using anything but Windows? That's where 95% of the market is. By your logic, Linux as a whole has "very small uptake." Therefore, should we all just save ourselves the trouble and (2) move to another OS?
Topography has a lot to do with confusing streets too. Here in Portland, it is very hilly and a lot of our streets were old trails from the settler days. This leads to streets like Boones Ferry Road which twists and turns, stops only to reappear later, and extends for dozens of miles. If that wasn't confusing enough their is Boones Ferry Road, Upper Boones Ferry Road, and Lower Boones Ferry Road. I remember my days in logically designed cities fondly.
...now just try to install any software on it which depends on finding things in a "standard" *nix filesystem order.
-Cnik
LSB is Linux-specific, and deals with far more than file placement.
You want File Hierarchy Standard documentation, which is a vendor-agnostic standard for file locations on *nix systems.
Unfortunately most sites I've worked at know "better" and have weird homebrew setups that aren't used anywhere. One client site I'd recently worked at was using FHS, then a new honcho got into one of the "standards" groups in the company. Now they've got stuff going into "/apps" that used to be in "/opt".
Funny thing is, the sysadmins still put everything in /opt where it belongs, then create a bunch of symlinks from /apps to keep putz-boy happy that they're "following" the unconventional "standard" cooked up by people who don't write code or maintain systems.
I do not fail; I succeed at finding out what does not work.
183 also has more names than it needs. Research. Bluebonnet Parkway. (And, uh, 183, with the confusing direction confusion you noted.) [I hope I haven't just misremembered those ...]
Manor -- pronounced *how*?! It look a while for that one to sink in. I never said Guadaloop, too stubborn.
You forgot: Manchaca ("man-SHACK") and Koenig ("CANE-ig"). And the multiple 1st, 2nd, etc. streets (again, my memory is poor, but iirc, they start over south of town lake).
However, Mopac is good -- I used to think it was a bizarre name, but the origin makes it OK: The Missouri-Pacific Railway. Now, calling it "Loop 1" at the same time, that's less cool.
GPS machines need to be made smarter so the average $50 GPS device from Walmart can at least say "You are going south on MoPac, also known as Loop 1."
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Sorry.
...) started in Massachusetts (they're widespread there) and in Washington DC (where they're big and dangerous). Now they're adding them in central Maryland, evidently because Marylanders are masochists.
;)
I've never been to England, and mean no offense -- my experiences with roundabouts (or rotaries, or traffic circles, or Dante's Circles
You may choose routes based on avoiding red lights, which is understandable, but I often choose mine by minimizing my exposure to rotaries.
Therefore, if I visit England, I will try to occupy passenger seats and buses more than driver's seats
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Can anybody explain me what's with all the hype about putting each app in it's own directory?
Being able to see the "contents" of an app is exposing implementation detail to the user. That's bad, bad bad. Users shouldn't have to know what files a program has! They should launch their app using menus or icons and uninstall using the package manager. They should never have to know more than that! Everything else should be taken care of automatically without exposing implementation details!
So, what good is putting each app in it's own directory? It will certainly encourage people to take a look and try to hose their filesystem. I know many "average users" who fsck their Windows system because they randomly delete stuff from C:Program Files.
with /opt/mozilla pointing to mozilla1.3a
No question about it. Everything else is legacy. Of course a lot of distros have not modernised. A better question concern something like VIm. Vim is on the border of three rules. It is kinda small to be going in /opt, but not unduely so. It is often a basic component of a distribution so /usr makes sence. But it is also often a user added tool and thus most naturaly in /usr/local. Personaly. I have desided to put it in /opt because it is one of my major apps.
It was called "SCO OpenServer 5", and I first used it in 1994. It was hideous. Any time you installed a traditional unix program you shat all over the symlink hierarchy and generally hosed something.
It made mangement of vendor supplied packages slightly simpler, but the whole point of open systems is that you are not locked into dependence on your OS vendor!
-- veni vidi nuclei deceri --- I came, I saw, I dumped core.
One more reason why the standard file hierarchy needs to change is the difficulty of doing file management. Let's say I put in an application and now I want to remove it; I have no idea where to look for its files. Even using RPM or another package manager doesn't always work. What if I extracted a tarball and now want to know where its files went? Here are the choices for where executable X got place:i na l/X/bin
/X, /Program Files/X, /Windows, or /Windows/System.
/Windows and /Windows/System which get very big and accumulate all sorts of stuff.
/Windows. This includes /bin, /etc, /usr and all the subdirectories of /usr. Yes, packages help with this, but only if I installed it as a binary.
*/usr/bin
*/usr/local/bin
*/usr/X11R6/b
*/usr/local/X/bin
*/X/bin
*/local/bin
*/loc
*/usr/X/bin
and the list goes on.
In contrast, on a windows machine, if I want to remove an application X, I can be 99% sure that all of its files are either in
What if I want to clean my hard drive? On a Windows machine, I can look through the directory names to find programs I no longer use. The only exception is
On a Linux system, every directory is like
What if I want to give my computer to someone which has a fully configured setup but also a lot of my personal settings and programs? Beyond the things in ~, I'm lost.
The trouble with the Unix filesystem is that it makes it hard to install and uninstall software
/usr/bin/install to /usr/bin/gnu-install and make /usr/bin/install a script simply calling gnu-install and logging every file into /var/log/install.log?
:-)
Then why not rename
I did that on my machine before and it was quite easy then to remove stuff. Just make sure to timestamp entries in your log and try not to install too many things in a row
Hopefully, this will become an example to be followed by other Linux distros.
I'm a bit worried about compatibility though. One should hope there are some ln -s 'es hidden in there pointing back to the "original" entries so that they can be found with the old names.
Anyway, great initiative! All we need now is Red Hat and Gentoo to copy you
Maybe I'm revealing myself as too much of a TV junky, but most scenes I see from 'Wildest Police Videos' (or the like) involving runabouts in countries other than the US look like a nightmare to navigate. If you're not in the correct lane at the right time with a break in the traffic you're either stuck or cutting someone else off. I am by no means suggesting that US streets/highways are better; just different. Given the two seperate scenarios though, I'm happy here!
[SIG] Remember Mattel handheld games?
Maybe I'm pointing out the obvious here, but for those who like the idea of GoboLinux's revised directory structure (as I do), check out the encap package manager. It's not as complete and elegant a solution, but it's along the same idea and it works with your existing Linux distro. I use it for every package I install from source.
More seriously, someone needs to come up with a scheme whereby users can configure their own standards for filesystem layout and applications will transparently use it. This would eliminate all the arguments over the "right" way for a filesystem to be layed out.
All you need to do is setup a system-wide configuration file in well known place (it needs to be in /, since we can't depend on any directory structure, so my suggestion would be /layout.conf). You then need hooks in glibc so that applications can find their configuration files and libraries. You also need hooks in the installer so that applications will be properly installed.
This is easy to design, difficult to implement. You'd need to convert enough applications to use this scheme to get the ball rolling and get other developers to see the light and start writing their programs to be /layout.conf-aware. I keep on thinking I should convert a FreeBSD tree to use a scheme like this, but the tedious work involved in patching the tree would take more than what I've got available in free time.
Think about the payoffs though. You no longer need to choose your distribution based on what filesystem layout you like. And RPMs (or debs, or whatever) would become substantially more portable between different distributions. The distribution authors would merely 'suggest' a default layout. The end user would be free to override those defaults in the installer (or kickstart) and pick different layouts. If you wanted to build your system so that every single binary was in /app/progname/bin (even to the extreme of /app/ls/bin/ls) then you could -- and with the right libraries and databases of installed programs your PATH would transparently become a complete nightmare! Then you could fix that PATH nightmare by configuring /bin to contain symlinks to every single binary on your system. Whatever you want.
The BitTorrent for GoboLinux is available at:
http://f.scarywater.net/GoboLinux-006.iso.torrent
(those using the gobolinux.org torrent are advised to switch to the scarywater.net torrent, since the gobolinux.org one is based on a bttracker running on a machine with a dynamic IP)
With all that OOP overhype I don't see any operating system of being migrated from files-systems to object stores. Doesn't it prove that OOP concept is not a panacea?
Less is more !
Much more, in fact.
Maybe we should just ditch all other languages. Think of the economies if we just talk the same language everywhere...
Since the GoboLinux site is suffering from the Slashdot Effect, here's a link to get the ISO using BitTorrent (known for the RedHat 9 ISO for instance):
http://f.scarywater.net/
You can get your RedHat 9 ISOs there too btw.
You're completely correct. In the case of the person above, they don't realize that just because someone doesn't want to learn, doesn't mean that they're bad. I'm simplifying for someone who seems too immature to understand the subtles of human interaction.
I didn't really feel like spending more paragraphs explaining life to someone who seems smart enough to go out and experience it, even though they've curiously not done so yet.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
the feminist alliance of america demands woman pages
You have a threshold setting of at least 2, which means you missed the critical reply of a person (rated 1) who was trying to debunk the original good post as a troll.
I can probably do a lot more maturing. To think that you're grown up when you're in your 20s is pretty serious hubris.
Also, I haven't had much of a hand in administration of kuro5hin for quite some time. Rusty quietly showed me the door, so to speak. Except for checking in from time to time, and occasionally posting polls (every few months), I really have little to do with things there anymore. I've been much busier with my hobby of video gaming than computers.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
In NT4 and prior, user profiles typically were stored in C:\WINNT\Profiles.
Are you suggesting that anyone needs more than 640KB...?
RMN
~~~
It's much more in depth, and is correct in addressing this.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Well, they're separate issues, but both ones I have rants to spare ;)
... sometimes. But you mean we have to do it *all* the time? The big ones in D.C. are even worse. Now Howard County has the fashionable traffic circle bug, and it's an irritation to drive certain routes because of it. I *do* like the fact that they allow a minimal flow when otherwise none might be afforded, as you point out, but Ack. Normally, my family does not agree on everything, but the fact that my parents and siblings are with me on this surely says *something* about them.
...) but often perfunctory. Sign the dotted line, take some multiple choice tests, get a few hours with a lax instructor ....
circles: As a long-time Maryland resident, an absence of traffic circles is one thing I used to grant the state credit for, especially after a trip to Massachusetts. Up there, despite years of familiarity, the drivers seem intent on making the rotaries dangerous. Yield to traffic in circle?! Well
Licensure: You are right. For instance, when I got my own license, I was (I know in retrospect) seriously underprepared and overconfident. I wonder if there's a good market for serious driving schools. It would be good if it was approached more like flight school. Driving schools in the U.S. are often *required* (at least below a certain age; I waited until 18 for my license so technically I don't think I needed to have taken the course, but I did take one
It would be better with video analysis, many more hours logged (and I mean logged, with notes), and greater knowledge demonstrated of laws, car parts and driving situation responses.
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Once you understand the Linux filesystem is makes a lot of sense.
/sys/admin for /root, /sys/bin /sys/lib and /sys/settings. This would make things easier for new people as then you'd have /sys /usr /var /boot /tmp - a bit easier. Still, why type /sys/admin when you can type /root etc etc - it's more effient.
/boot.
/home growing out of hand from fools catting /dev/random and redirecting output to a file and stupid things like that. It also means you can mount /usr from a remote nfs share on your lan....you can still have /usr/local as your own partition on your own hard drive.
/bin easier to type than /system/binaries
/home and /usr
/var can be on it's own partiton in case it fills up. likewise for home..
It's all boils down to partitioning.
Partition reason #1
Unix was developed when hard drives were small and thus partitioning was based on hard drive capacities. Sure you could have LVM and combine two hard drives together, but this is not really good for fault tolerance if one of the drives goes bad.
Ignoring LVM spanning of drives, small hard drives meant you had to partition. You want the smallest possible working system on the one hard drive so you have one hard drive mounted at / and this contains the 'root' 'bin' and 'lib' and 'etc'. Since these patitions *really should* be on the same drive or partition there's no reason why they couldn't be simplifed to 'system'. You could have
When hard-drives got over 8GB (1024cylinders in standard CHS parlance) earlier boot-loaders couldn't talk LBA so a seperate partition is often created at the start of the disk and mounted under
Partition reason #2
Quotas and remote storage. Partitions means seperate filesystems, which means you can have quotas to stop / and
The more you dig into it you realise why it is setout the way it is and it boils down to:
EFFICIENCY
FLEXIBILITY
directies are organised so that hard drives can be added easily and directories moved onto them, and remote nfs shares can be setup to be useful in the case of
SECURITY
since of writing now... goodbye
" 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."
That would be because all you can see is the trees, while ignoring the forest. The issues going on isn't something as petty as "I don't like your filesystem" or "We can't handle case". It's deeper than that. As I pointed out earlier this is culture clash. East meets west, indians meet white man. One stronger culture is bringing it's own ways into a pre-existing weaker culture. The problems start were the dominent culture is basically at best ignoring the ways of the culture they're intruding into. At worst they are actively trying to bend the weaker culture to their way of seeing and doing. And in the face of that you're surprised that there is resistance? History repeats itself.
to make the filesystem intuitive, as well as logical. Sure, the *nix filesystem is logical, once you learn about it. However, it would be nice to have a filesystem that is intuitive to the point that there is no learning required before it is considered logical.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
just providing a link
I believe the intention with gobo is for one to be able to say something like
/$dir/Packagename/Version/
for dir in Programs Libraries Whatever do
rm -r
done
and have it remove all associated files.
The key thing is consistency. All files in one dir is very consistent, but so is all files in one pattern (as long as the pattern is simple).
I want my Cowboyneal
How does this help? How many newbies are going to leave their home directory anyway?
/etc or /sbin. And if they are smart enough to know what they're doing, then there's no need to change their names anyway.
If someone can't get beyong the GUI, then a simple "Home" icon is all they need. If they can get beyond that location, and don't know anything, then the directory names should be *scary* so that they don't start deleting random files out of
Organizing the home directory makes sense. But reorganizing and renaming the system infrastructure just so we don't scare off people who shouldn't be there anyway is silly. Who cares that "/Programs/XFree86/4.3/" is more friendly than "/usr/X11R6" when we don't want the clueless in that directory to begin with?
A Government Is a Body of People, Usually Notably Ungoverned
I see where they are going with this, make Linux more accessible for those coming from Windows or Mac. In practise it'll just break things and teach the newbie bad habits. The creators of this distro much be better off doing this in the KDE/Gnome desktop than using symblinks.
/usr/bin a symblink to something, do it the other way around. Better still, don't.
If you MUST use symblinks DON'T make
The UNIX file heirarchy has been around for a very long time, we're all stuck with it even those who don't like it.
whoo, congratulations. sounds like you're well on your way to inventing plan 9.
Look, it's really quite simple: if you can't wrap the very limited brainpower some of you have around the ordering of the linux filesystem, you can always go crawling back to Windows.
I don't have any problem with improving linux. However, I do *not* see how making linux more like Windows can be considered an 'improvement'.
Linux isn't for fuckwits who can barely locate the 'on' button. Said fuckwits have Windows for that. If linux is just too tough for you to master then you know which OS is for you.
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
Then you would love Houston, Texas. Most of the Gulf Coast area in general, in fact. It too "just happened."
Streets/Roads that used to wander across the countryside have kept their names and it isn't unknown to change street names when going thru an intersection. Just like London and Paris, parts of some streets have been renamed - the part of Bellaire Blvd. east of Bellaire was renamed Holcombe Blvd. years ago for a Mayor.
Our ancestors learned their lessons well at Britannia's footstool, rebels tho' they may have been.
I have 1777 files sitting in /usr/bin... /usr/bin.. /opt/??? mostly wind up getting links to them stuffed in /usr/bin !!..
In fact, my distro (Gentoo) put pretty much everthing gets stuffed into
In fact, things that get installed in
Is it really that crazy of an idea to try and bring some structure ?
It would be nice to know be able to know that these 73 files belong to this program, and those 86 belong to this other one WITHOUT having to rely on a package management system
Time travel is possible. We are quickly heading for 1984.
Good grief! When I got my first computer (a used 486 at a computer show for $450), I didn't even know how to run a program. I finally got my hands on Win311, then 95,98,XP etc, etc. Somewhere in there I read about a "new" OS i desperately wanted to try - RedHat (ok, a distro now, but I thought RedHat was equal to Windows). That was 6 years ago. I have been using/learning Unixes ever since. I now have 3 commercial servers running various distros.
You know what - you want to be proficient in Windows, ya learn the hiarchy. You want to be proficeit in Unix, ya learn the hiarchy.
BSD to Linux - annoying yes, but I can always run "locate myfile" to find something. And I love the color-enhanced terminal. It makes life so much easier. Gobo wants to have a "unified & logical" hiarchy - more power to them. No one said real users have to use it or support it. It goes back to the Corel Linux-type stuff - get M$ desktop user's feet wet. If they like it, they stay. If not, they run home to M$ and are the cause of most of the virii and worms running rampart that we hear about on the evening news.
In the mean time, Power to the Pengiun!!!
Agreed.
This is a terrible tendency that Slashdot has.
Free software and the switch to Linux was supposed to be about a degree of freedom and choice. But an alarming minority of slashdotters seem to think otherwise.
They think people don't like them cos they are nerds. Wrong, its because they're jerks...
woohoo, they were fun (we've since moved away...)
^_^
Black holes are where the Matrix raised SIGFPE
But does the standard UNIX login sequence let a user authenticate by id instead of by name?
Will I retire or break 10K?
Please suggest some to me.
I have at least half a dozen *nix books on my shelf and none of them talk about it. They might tell you what the top level directories are for, but the other 300 mysterious sub-directories are left out. This has been one of the most befuddling aspects of switching to Linux. Whenever I compile programs, I just have to basically guess at where stuff should go.
Reading the threads on this article has been the most information I've gotten on this subject.
It's because it's exposing implementation details to the user. It encourages new users to mess up their filesystem. I know tons of people who have fsck'ed their Windows system because they deleted random files from C:\Program Files.
Users shouldn't have to care about the underlying filesystem! They should launch apps via menus and the only folder they should have to know about is $HOME. If you have the need to expose the underlying filesystem to the user then there's something very wrong.
In other words, whether / contains usr or Applications or whatever, the user shouldn't have to care! The names of those folders should be irrelevant.
If the name of the folders are irrelevant anyway, why not aim for efficiency instead? The traditional FHS gives you that efficiency. It's proven.
This is already off-topic, but NT is has some POSIX compatibility so that Microsoft can sell it to the government. The US government requires POSIX compatability for all its OS's. And, btw, the POSIX subsystem in NT is totally broken -- MS made sure it will never run anything but the most basic stuff.
Hmm but if you remove /Libraries/Zlib or whatever how does it know to also remove all applications that depend on zlib - or to warn you about them and ask if you really want to go ahead?
-- Ed Avis ed@membled.com
..I'm not talking about how intuitive "file" and "directory" are. I am talking about how easy it is to comprehend the purpose of each directory (and thus, the type of files one could expect to find there). If I give my 50-yr old mother two computers, one running OS A, and the other running OS B, and she sees the following directories:
/bin
/etc
/home
/lib
/usr
/Applications
/Settings
/Library
/Users
OS A:
OS B:
I'll bet any amount of money that she is better able to find her way around the filesystem of OS B, simply because it is much more clear as to the purpose (and thus, contents) of each directory.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
What you suggest is done by programs like GNU Stow, I think. Although I would prefer to build an RPM package from the source code and then install that, that way you can use the standard RPM tools to manage and update packages.
/programs/grep/ or whatever but be soft-symlinked to /bin/grep for compatibility.)
But either of these solutions don't address the problem nearly as well as appdirs. We have a mechanism for grouping related files, it is called directories. Let's use it.
(Random thought: how about 'soft symlinks' which when the pointed-to file is removed are also removed themselves. Then grep could live in
-- Ed Avis ed@membled.com
Sorry about this, but had to do it. It's really informative (and due to the current state of the GoboLinux servers), necessary. Thank you.
The filesystem is the package manager
Since the site is down, I found a story on Kuro5hin.org by the core developer of the distro.
/Programs/XFree86/4.3/, and ping at /Programs/Netkit-Base/0.17/bin/ping. To see what programs are installed in the system, all you need to do is ls /Programs.
/System/Links grouping files from each application as symbolic links: Executables, Libraries, Headers, Shared and Manuals. For compatibility, each "legacy" directory is a link to a corresponding category. Therefore, /bin, /sbin, /usr/bin, /usr/local/bin (and so on) are all symlinks to
http://www.kuro5hin.org/story/2003/5/9/05015/626 49
The Unix tree rethought: an introduction to GoboLinux (Technology)
By LodeRunner
Lately, there has been lots of discussion on the current state of Linux as a desktop system, and articles pop up here and there, occasionally with very good ideas. However, none have surprised me more than this one. It was all very hyphothetical, but had pretty radical ideas on how the author thought the Linux directory tree should be reorganized. This was clearly the most polemical part of the article, and raised many discussions whether something like this could actually be implemented. And that's the reason for my surprise: we had this implemented for over an year. GoboLinux is a Linux distribution based on an alternative directory tree, which has evolved from a custom LFS installation to a distro that's used and maintained by a small group of people today. It was interesting to see that there are a lot of people interested in ideas similar to ours. So, maybe it's time for us to come out of the shadows.
A bit of history
We all remember the time when talking about Linux distributions for the desktop meant arguing which has the best installer. Much has evolved since: the easy, graphical installers are here, but we're not quite there yet. Among the usual rants on "why (insert pet peeve here) is the problem", some interesting ideas come up from time to time. More interestingly, some people started to believe maybe it's time for more adventurous attempts.
Oddly, GoboLinux did not start as one of those. The whole thing started when I had to install programs at the University. As I had no write access to the standard Unix directories, I created my own directories under $HOME the way I saw fit. I upgraded the programs from source constantly, and couldn't use a package manager. My solution was the most obvious one: to place each program in its own directory, such as ~/Programs/AfterStep. Soon the environment variables (PATH, LD_LIBRARY_PATH...) got bigger and bigger, so I created centralized directories for each class of files, containing symbolic links: ~/Libraries, ~/Headers and so on. A natural evolution was to write shell scripts to handle the links, configures and Makefiles.
This system proved itself to be very convenient to use. At my home system, I started to gradually remove pre-compiled packages and recompile them with those scripts. I was moving towards a completely custom Linux system, which I jokingly called LodeLinux. When I had it about 80% complete, the Great Filesystem Crash struck. It was time to start it all over again, but this time through a different route: instead of "deconstructing" an existing distribution, a friend (André Detsch) and I (Hisham Muhammad) spent two days building a modified Linux From Scratch system. Without much fuss, on March 20, 2002, GoboLinux was born. A month later, we presented an article at the 3rd. Workshop on Free Software called "A new proposal for the Unix directory tree".
What is it all about?
GoboLinux is definitely not "yet another Linux distro for the desktop". It is entirely based on an alternative directory structure. Every program lives in its own directory: you'll find XFree86 4.3 at
For each category of files, there is a directory under
Bryan
CT
Hopefully GoboLinux and LinuxStep will join the the MHS standard so that this kind of improvement can start to spread to other distros.
/bin => /System/Commands /sbin => /System/Commands /boot => /System/Boot /dev => /System/Devices /etc => /System/Config /lib => /System/Libraries /proc => /System/Process /mnt => /Mount /opt => /Apps /tmp => /Temp /home => /Users /usr/bin => /System/Executables /usr => mostly placed under /System /var => mostly placed under /System
/Apps directory rather than cramming everything into /usr.
http://mhs.sf.net
The goal of the MHS project is to define a Modern Hierarchy Standard for UNIX-like operating systems which will further enable them to evolve, innovate, grow, and compete with Windows and other modern OSes.
Specifically, MHS technology will provide the following benefits:
100% Application Directory Oriented
Internationalization of Directory Names
More Intuitive Directory Names
Fewer Root Directories
Support for Case-Insensitive File Systems
Full Coexistence with Legacy FHS
Increased System Flexibility
A new hierarchy will be a big enough change to make distributions switch to application directories.
Set of environmental variables pointing the location of major system directories.
Applications would no longer need to hard code directory names.
System level directories grouped together under a common directory. (/System)
Currently, the directories are expected to be moved to the following locations:
All paths will be lower-case on a case-sensitive file system. As shown otherwise.
Application developers and distribution makers will need to use the
The autoconf family of tools will be patched to support the new hierarchy which will make most applications translate easily.
Although it can still be done, MHS will not support the same level of shareability (i.e. mounted over a network) as the legacy FHS standard.
FHS can be emulated via symlinks and MHS can be emulated on existing FHS systems. A kernel/file system hack of some kind may be done to have the legacy directories disappear in directory scans, to help improve user friendliness.
In addition to the standard, the project is developing a set of scripts that will setup the new hierarchy on existing FHS compatible systems.
The standard will not be finalized until a Linux distribution ships based upon it.
Bryan
CT
I don;t hate it because it is different. I do think it is lame.
Democrat delenda est
Those who fail to understand UNIX are doomed to reinvent it... poorly. And it is clear the people behind this project don't understand UNIX. If someone who DID understand the reasons why UNIX does things the way it does rethought the system and proposed a new layout us greybeards would actually listen instead of laugh.
But we have seen this broken thinking too many times to take it seriously this time. And if you hang in there for a few years you too will probably grok UNIX and start laughing at the kids who keep trying to reinvent the wheel for no good reason.
Democrat delenda est
There's something wrong with storing sourceballs at /root: it implies you compile as root. Never make or compile stuff as root! Make a "common" user (common among your admins) and throw all the sourceballs in its home dir. Alternatively, you coul set up a very lax umask before make/compile.
What moron modded this?
What's offtopic about having a bittorrent link for the distro refered in the article?
We are Turing O-Machines. The Oracle is out there.
Unix has always been a system for networks,and so is the FS layout. / (without /usr) contains everything to machine needs to connect do a network and mount NFS exports. /usr may be on a file server and not on the local host. In big networks /usr/share can be the same nfs export for all clients. /usr/lib /usr/bin,.. can be the same nfs export for all clients with the same architecture....and so on How to do this with a layout proposed here?
PS:sorry for bad english
(this is according to my dad) is that long before they were widely deployed in the U.S., cateyes were in place on English roads. The U.S. highway system (not to mention all the smaller roads) involves many more road miles, so it's not surprising that cateyes still are not everywhere, but my father says they saved his life a few times when driving through London fog.
In the U.S. by contrast they are rather spottily deployed, but much appreciated when they're in place. Badly marked roads are a pet peeve which I hope one day does not kill me. Paint's getting better too, so there are some places where the road divider markings eliminate the need for separate cateyes, but that too is only in some places.
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Brave Move
Unix grew on the ashes of the failed Multix. It started as a hack. But, now, many people try to make a religion of it. The more cumbersome the file system, the better for the 'experts'. But, do we really need that sort of experts?! Do we really have to spend all our time on tinkering and tweaking the system, and being hopelessly lost? No! I can see the light! The dark ages are over! We are witnessing a new dawn! What I asked so many times "How can make anyone any sense of the installation that is a mapping among two hopelessly messy file systems: the source system on the source CD-s, and the Unix file system on the hard drive?" finally got an extremely simple and very elegant solution: a new functional organization of both file systems that facilitates an almost one-to-one relation. Congratulation, and the very best wishes to carry the idea to full completion!
Well, if M$ has its way...
Try this.