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.
Anything to make Linux easier is a plus, however there is one Windows and many, many Linux distros, this is like dividing the cause. However it does provide for far more flexibility and doesn't lock you into any one company.
in other locales will the directory structure still be in english?
Now would anyone care to guess how many knee-jerk posts there will be, like "if you like a sane directory hierarchy, use OS X, ya weenie!" or "if it's not broke, don't fix it!" To which I respond, where do you keep your Mozilla plugins?
Much applause to the guys who were willing to think a little more critically about what we can do to make Linux just a little better.
I know the unix file hierarchy well, but I've always thought it was arranged haphazardly. Why are there six different places for system executables? (/bin, /sbin, /usr/bin,/usr/sbin, /usr/local/bin, /usr/local/sbin)? That's not even counting the alternative directories that some programs like to be installed under like /opt, or X11 programs.
The one thing I don't like is that they renamed root to gobo. While root doesn't have much inherent meaning to it, gobo has even less. If you're going to rename root, why not pick something more meaningfull like administrator, admin, superuser, BigManWithTheTopHat, etc? I guess I haven't checked recently, but is linux still limited to 8 characters for the username?
AccountKiller
No. Stupid people should not be allowed to use cars. People should know how to use cars, not how to accelerate and drool.
Stupid people driving a car are hazards to the rest of the driving world. They wreck mailboxes, they kill babies, they break cars, they waste auto mechanic time, they cost taxpayers money.
If stupid people were kept away from steering wheels and stayed at home in front of a TV set where they belong and left the driving world to those that understand it, things would go smoother, there would be less computer problems, far less accidents, much less auto mechanic time wasted, and tax payers would save a lot of money.
I fail to see why cars should be dumbed down for the dumb. It makes no sense.
Don't understand your car?? Go fuck yourself.
This is, actually, C:\Documents and Settings\user
/etc directory I'm sure. Is it in it's own subdirectory? Possibly! Let's go and see.
/Programs/XFree86/4.3 .. oh look, everything X installed.) Yeah, that could get confusing. Therefore there might be a bin directory, a config directory, and a data directory. They can all be symlinks, I don't care, but if I had to come up with where KDE stores it's default menu, I would have no f*cking clue. Somewhere in /usr I guess? Might depend on the distro.. Agh.
Where the hell are you people getting this BS about it being in the windows directory?! It wasn't there in w2k. I should know, I'm running it right now. It's not there in XP (Professional). I should know, the computer next to me is running it.
That being said, the linux file system structure SUCKS! Windows isn't much better, but christ.. especially with the distros. Where is your config file for samba? Well, I don't quite know. It's somewhere in the
Having all the stuff AT LEAST symlinked from some common directory would be SO NICE. (cd
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.
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
~~~
This is certainly the unix way I guess. There shouldn't need to be a special packaging command to help me find the files though. This filesystem still makes more sense to me. If all things install to their own separate directory tree, then symlink them so everything also appears it's in one spot (like /Configurations .. or just call it /etc since it's shorter ;)), we have the best of both worlds. I shouldn't have to depend on some package manager tracking every file that a program needs to run, especially if it's made with scripts afterwards. MacOSX has it right here: Most things are just a 'Package'. A Package is a compressed folder/disk image, and is treated like one by the OS.
/MacOSXAppsDirectory/CompanyName/Program.Package/e tc will work. Of course those aren't real directory names, but you get the idea.)
Therefore double clicking it will run the program, but you can easily go right in side of it and see all the files, and treat them like files. This works on the command line too. (cd
There are similar commands for any packager because there needs to be. There's also a command for sorcerer that finds files it's not tracking. When wanting to COMPLETELY remove something, I have to check that list as well. And then hope that IT is complete. Being able to check a directory for a "data" folder, back that up if I want, then blow out the directory would be nice. (Yes, this does screw up symlinks. Therefore it MIGHT be better to have the directory for the program contain the symlinks, as opposed to scattering the symlinks in to the one solid directory. Unless there's a way to reversely traverse a symlink in constant time..)
Again, a pipe dream I'm sure, and I'll admit there are certain things about the linux/unix file system that are nice. Configs mostly in one place, etc. But yikes it's certainly a mess. Something like this would help a great deal, I think.
(Another example: at a konsole, hit k, then hit tab. How many things come up? How many of those are kde programs? Are those ALL the kde programs? Probably not. What if you want to see all the executables that are part of the 'kde distribution' ? I guess you're off checking your package manager: Make a list of what you consider the kde distribution, run that list through the package manager, dump that in to a tiny little thing that sees if they're executable, etc.
Not too much different than just using ls/find/grep/bash/whatever, but what if your package DB gets corrupt? If bash/ext2 gets corrupt you have a bit more to worry about I'd think.)
FS/OS support for links makes it so easy to do such cool stuff that's essentially impossible in some other operating systems (Shortcuts are files that are treated specially by the shell in Windows. Not by the OS's FS layer. Therefore, they're nowheres comparable.) Why don't we use that support to make a FS structure that makes sense to everyone, and kicks ass? You can keep the old layout, and have a nice new layout too. Best of both worlds.