GoboLinux Rethinks The Linux Filesystems 859
dolbywan_kenobi writes "GoboLinux is an alternative Linux distribution which redefines the entire filesystem hierarchy. In GoboLinux we have paths such as /Programs/XFree86/4.3/ and /System/Settings/BootScripts/Reboot." By design, GoboLinux is quite a bit different from most Linux distributions, and -- notably -- is a live ISO, always nice.
Oh, good! (Score:4, Funny)
Re:Oh, good! (Score:4, Interesting)
Don't you remember the article (i think it was on wired?) "If i had my own linux distribution". In it the author explained that he envisioned a file system layout just like this, and explained that to keep compatibility he would create links to legacy locations, just like this distro does.. (obviously all very much inspired to that apple did with OS X)
Funny that a week or 2 later such a distro is announced..
Re:Oh, good! (Score:5, Interesting)
http://www.osnews.com/story.php?news_id=3
In it he writes in the intro: " I'm going to make a sensible directory structure:
It was mentioned on slashdot here:
http://slashdot.org/article.pl?sid=03/04/2
Re:Oh, good! (Score:3, Interesting)
obviously all very much inspired to that apple did with OS X
Or inspired by BeOS (now Zeta [yellowtab.com]), or AtheOS (now Syllable [sourceforge.net]), or some other OS that exsists longer than MacOS X.
Not everything is inspired by Apple.
registry == bad (Score:3, Insightful)
Some Windows victim will trot this stupid idea out on
Re:registry == bad (Score:5, Insightful)
Judging by your loaded language and some other aspects of your post, I'm guessing you're not the kind of guy who would hear my argument, no matter how rational it may be.
For one, I'm not a Windows victim. I don't use Windows on any desktop or notebook. Grow up.
Some Windows victim will trot this stupid idea out on
There is absolutely no reason a Registry has to be binary, inpenetrable, non-text editable, undocumented or unfriendly. A registry can very well be all of these things, providing the benefits of a registry as well as the convenience that comes along with being able to edit your prefs with your favorite text editor.
One way I see a registry could be implemented on Unix is with a proc or proc-like file system setup. With a setup like this, you would achieve the ability to have binary and text preferences. You could edit them using any text editor. You could even get pref permissions management. You would also get, at no added charge, a consistent interface to preferences and settings. What good is done for Unix with dozens of different config file formats that all achieve the same end result being used? What good is done for Unix when it's a nightmare of
For instance, in this proc-like registry system, things could be accessed like-
# prints the number of processes which
# apache starts up on boot/apachectl start
cat
# Sets a preference in xtunes to look for
# the media library in such a folder-
cat "/home/rev/Music:/mnt/otherbox/Music" >
# what prefs are there to edit for the GIMP?
ls
# restore my Mozilla prefs to default
cp -f -r
etc.
There could also be a small API for enumerating groups of prefs, etc. It would be largely unnecesary considering the ease one can interact with the proc-prefs file system in a direct way programatically, but by that, also very thin, lightweight and easy to write. An API and proc-prefs-registry feature would be simple database-like features, allowing versioning and rollbacks for system, user, or global changes made to prefs. Not needed, but it'd be a very nice touch. Sure, some folks may be using RCS with their
But then again, I suppose a system that works for users and admins isn't Unix enough for the hardcore slashkiddies out there. Every new, disparate
As I said, it depends on the implementation. What I have described above is a registry. It isn't binary, although a binary file could be used in a pref. It is editable with any regular editor. It does not provide a single point of failure for system prefs. It does provide users and developers with a consistent interface for interfacing with preferences.
Re:registry == bad (Score:4, Insightful)
Ok, fair enough. Itis just that I see this same argument every month or so and it is usually someone who thinks the Windows registry is just great. Now on to your points.
I think the first thing of note is that you discussed the issue in the UNIX way, with comment lines with #. When I cat out
What filepath goes after vi to get all of the prefs for apache with comments? If you are going to maintain a transparent system to convert to/from registry to commented config file the argument has now settled to which format do you consider the canonical format to store in and which do you transform to on demand. I'd argue for storing in text format to make versioning and backup easy with existing well understood tools.
I don't see much else in your proposed
But of course in the end it is all a moot point for the forseeable future. No regularized system is likely to get off the ground because so much of the software we use comes from so many sources and too many authors are too quick to ignore standards. Remember that X had a pretty well developed system to manage preferences and neither GNOME or KDE used it. Think they would use ANY outsider's system? Motif stuff imported from generic UNIX will use the standard X resources in lieu of any new system. Bleh!
Figures (Score:5, Funny)
--
Need to calculate [webcalc.net] something?
Re:Figures (Score:3, Insightful)
The UNIX Way has proven itself over decades. Problems have been discussed and dealt with. Go read the Linux File System Standard documents if you are interested in learning WHY things are where they are on a modern distro. There is method behind the madness, designed to accomodate the needs of a disp
Re:Figures (Score:5, Funny)
Not if you're used to the old one.
At least there's no Progra~1
Looks like Darwin. Smells like gnu. (Score:5, Interesting)
Last login: Fri May 9 23:02:15 on ttyp1
Welcome to Darwin!
[garou:~] numbski% cd
[garou:/] numbski% ls
Applications Network automount etc mach_kernel usr
Desktop DB System bin log.txt private var
Desktop DF Users cores mach sbin
Library Volumes dev mach.sym tmp
Re:Looks like Darwin. Smells like gnu. (Score:5, Insightful)
Re:Looks like Darwin. Smells like gnu. (Score:3, Informative)
Re:Looks like Darwin. Smells like gnu. (Score:5, Interesting)
On the Mac, we have Documents and Pictures, making that unnecessary, and tab expansion can happen at the first letter. So longer, self-explanatory names can work well if the original developer isn't boneheaded enough to use names not unique at the first space.
D
Re:Looks like Darwin. Smells like gnu. (Score:4, Interesting)
Also, since the first letter of these folders is capitalized, and most of my files have lower-case names, tab completion works really well. Apple clearly had the command line in mind when choosing these folder names, and tab completion works in some GUI dialog boxes as well (Cmd-Shift-G in the Finder opens a Go To Folder dialog where you can type a path).
Some folders have spaces in them, but you never have something like "My Documents" and "My Pictures", just things like "Desktop Pictures" and "Screen Savers" - the beginning is unique, so tab completion works.
My documents... (Score:5, Funny)
Re:Looks like Darwin. Smells like gnu. (Score:3, Informative)
You don't even have to delete the closing double quote if you want to specify a file within the dir - just add on the backslash, press the first letter, and hit [tab], and it's all taken care of for you.
Re:um.. (Score:5, Informative)
Only Windows XP has tab completion enabled by default. Windows 2000 and NT (IIRC), have this capability in CMD.EXE but it's disabled by default.
To enable it (which I do all the time in win2000), do this:
1. Hit the "Start" button
2. Select "Run"
3. enter "regedit", hit OK
4. Expand "My computer" (by clicking the little [+] beside it)
5. Expand HKEY_LOCAL_MACHINE
6. Expand SOFTWARE
7. Expand Microsoft
8. Expand Command Processor
9. Double-click "CompletionChar"
10. Replace the value that's there with 9 (which is the ASCII equivalent of the TAB key)
11. Click OK
I found this here [jacobsen.no]. I just googled for "windows 2000 tab completion" and yes, I felt lucky.. :)
3 comments and nearly /.ed (Score:5, Informative)
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
Re:3 comments and nearly /.ed (Score:4, Insightful)
A severely bad idea.
A lot of systems I maintain have NFS-mounted home dirs - /home/ is on another machine.
When the sh*t hits the fan, I need to be able to log in - as root. The last thing I need is root's home dir inaccessible.
There are decades of wisdom behind Unix, most of which I have no desire to re-learn. Not broke ? Don't fix.
Cheers, Andy!
Re:3 comments and nearly /.ed (Score:5, Insightful)
Re:3 comments and nearly /.ed (Score:4, Insightful)
Well, to be honest, it's decades of tradition not wisdom. There's not a lot of wisdom in names like /usr and /etc. Wtf are they supposed to mean? Yes, *I* know what they mean, but I've been using UNIX for more than a decade. I'm not going to fool myself into thinking they're good names.
Though that I can agree with. However the joy of Linux is that people can take it in a new and interesting ways. If this guy wants to do this then more power to him. I'd be interested to see if the idea becomes popular.
Though surely this would have been easier with a VFS view in GNOME or something.
Finally! (Score:5, Insightful)
Re:Finally! (Score:3, Insightful)
There are several problems with symlinking all */bin directories to another directory. First, some of these directories are put in different places for good reason--/usr/bi
Re:Finally! (Score:5, Insightful)
this whole FS reshaping is a rediculous idea and goes against everything the LSB [linuxbase.org] has been tryig to fix, since there are so many deviants of GNU/Linux. i hope this distro dies off damn quickly... (how to lose all your karma in 10 seconds)
Re:You've answered your own question (Score:3, Interesting)
Re:Finally! (Score:4, Insightful)
/bin/someprogram/ ==
/lib/someprogram/ ==
/log/someprogram/ ==
/etc/someprogram/ ==
/share/someprogram/ ==
/bin/all/ ==
/lib/all/ ==
rm -rf
Your $PATH would only need to be
The same form could be followed for 'info', 'man', 'sbin', 'lock', 'include', et cetera. You could have programs in
Just me foaming at the brain.
Re:Finally! (Score:3, Interesting)
MS is adding something like this into longhorn.
first time heard about it, it was called "Object File", I'm sure the name will/Has change(d) to something more stupid proof.
Some of the functionality you want can be kinda emulated, with a system of file seaches in shell scripts, and Linked Files, and folders.....
but it doesn't quit behave, in a completely transparent manner....(which would be nice).....
Re:Finally! (Score:5, Funny)
Yes. Windows has this problem solved completely. For example in windows when you install a file it goes into c:\program files\progname. All the libraries go into c:\winnt\system32. The config files sometimes go into the c:\program files\progname or into c:\winnt\systems32 ir get merged into a binary file called the registry. Any files that are shared go into c:\program files\common files\progname.
Linux will no go anywhere until program installs are as clean as windows. Look how nice the windows system is!
Re:Finally! (Score:3, Insightful)
But I think the problem of inconistency is already bad. Is a program going to install in
What may be better is for package managers and install scripts to look for standardized environment variables to know where files should be insta
Re:Finally! (Score:3, Interesting)
Environment strings don't seem like a robust way to solve the problem. They can be changed too easily (yes, too easy is sometimes bad.
Re:Finally! (Score:3, Insightful)
Re:Finally! (Score:3, Insightful)
There is such a warning in windows 2000 and XP, but remarkably, you can turn it off, and it never shows up again. Microsoft windows (to SOME VAGUE extent) caters for people who know what they're doing as well as newbie users (admittedly I would l
Re:Finally! (Score:4, Interesting)
Actually,
Some even argue against pronouncing it "user" but I find that I cannot help it, and am not overly keen on trying.
Re:Sore wrists from long words (Score:3, Insightful)
I
mixed case = bad for shell (Score:4, Interesting)
Re:mixed case = bad for shell (Score:5, Insightful)
If anyone knows a reason why case-sensitive paths are a GOOD thing, please respond. I really would love to know - they just seem annoying as hell to me.
Re:mixed case = bad for shell (Score:3, Interesting)
Re:mixed case = bad for shell (Score:4, Insightful)
The computer works for me, so human priorities should come first.
I think you're being misguided by the idea that file systems are for people, rather than computers.
It is for people. The computer just needs to know to read from sector x through sector y of a particular disk, and it's perfectly happy. Anything beyond that is an abstraction made for human convenience, much like domain names or paths are there for humans; computers don't care.
Ideally, people should never see the file system unless they're doing administration.
And if you have a desktop computer, which is somewhat common these days, you are doing your own administration. Thus the computer should be set up to make things as easy as possible for the user.
Looking further ahead, into the Future(TM), where the grass is Greener(TM) and everyone has a Flying Car(TM), we'll probably end up storing all of our data in databases, rather than in files. Data storage won't even care about things like file names, which will be maintained by a layer between the data store and the user.
Filesystems already are databases. Somewhat crappy ones, but they are databases.
Re:mixed case = bad for shell (Score:3, Informative)
What you are describing is case preservation, not case sensitivity.
Re:mixed case = bad for shell (Score:3, Informative)
Re:mixed case = bad for shell (Score:3, Insightful)
I write Java. So I have class names like RoundObject and WebSite. Well, not that verbatim. But anyway, if I type shift-r+, I still get RoundObject. Now if you aren't a touch typist, i'd sligtly agree. Otherwise, shift-r vs r isn't that much slower. Hell, typing in English forces you to type that stupid shift key quite fast.
Now if you mean in terms of string compares, how much faster do you need a tab completion to be done?
-s
Enough (Score:4, Interesting)
Bad, Terrible Idea (Score:5, Insightful)
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.
Re:Bad, Terrible Idea (Score:3, Interesting)
You obviously don't get it. This wasn't done to make things easier for the distro maker - this makes things a pain in the ass for the distro maker, I'm sure. This was done to make things logical and orderly for the USER. I'm glad I wasn't the only one who thought it would be nice to do something like this, since I'm far too
I like it, but.. (Score:5, Interesting)
For all those who ask, "Why?" (Score:5, Interesting)
Now would anyone care to guess how many knee-jerk posts there will be, like "if you like a sane directory hierarchy, use OS X, ya weenie!" or "if it's not broke, don't fix it!" To which I respond, where do you keep your Mozilla plugins?
Much applause to the guys who were willing to think a little more critically about what we can do to make Linux just a little better.
Re:For all those who ask, "Why?" (Score:5, Informative)
Well, share is for platform-independent data, so that's out. (A Mac and a PC with the same Linux distro and packages should be able to use the same NFS-mounted
The rest are all possibilities, depending on whether you or your distribution vendor installed Mozilla, and whether you or they consider Mozilla to be a monolithic "black box" (like Windows apps) or an integrated part of the system (so it's easy for Galeon or other Gecko-based browsers to embed it).
It's valuable to have
I realise it's not ideal, particularly with some of the more subtle points (share vs. lib,
(I wish all my dotfiles followed a similar hierarchy, actually - I've started using symlinks to get the caches in ~/.tmp and the important config files in ~/.etc, so I can leave out
Some of the merging Gobolinux does seems like overkill; for instance, the benefit of having the
Another article... (Score:5, Informative)
root = gobo? (Score:5, Funny)
Re:root = gobo? (Score:3, Insightful)
Standards, standards (Score:5, Funny)
doesn't seem like a bad idea... (Score:5, Interesting)
The one thing I don't like is that they renamed root to gobo. While root doesn't have much inherent meaning to it, gobo has even less. If you're going to rename root, why not pick something more meaningfull like administrator, admin, superuser, BigManWithTheTopHat, etc? I guess I haven't checked recently, but is linux still limited to 8 characters for the username?
Explanation. (Score:5, Informative)
/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
Re:Explanation. (Score:5, Insightful)
And they are all asinine.
Users want stuff to work. They don't care that 20 years ago hard drives were too small to fit all your files or that some weirdo grouping of your programs allows you to share parts of the installation across your non-existant network of linux machines. My login script has over 60 lines dedicated to finding moron binary directories like
I'm not sure if this gobolinux stuff is the solution but at least it isn't happy with the status quo. IMHO the biggest problem with linux is that the users don't think there's anything wrong with it.
And THAT is important? (Score:3, Informative)
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
*nix Filesystem, Not Just Linux (Score:3, Informative)
Filesystem Hierarchy Standard [pathname.com] has included the BSDs since 1995 - it's more than just Linux. I'm all in favor of questioning the assumptions to avoid getting caught on a local maxima, and I think this one is a dead end. FHS has some historical baggage, but it also has the strength of years of tempering.
Thank god (Score:3, Insightful)
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.
Re:Thank god (Score:3, Interesting)
Yes it's crazy. There are some systems that do it the "non-crazy" way, but not many. And none which are popular or particularly current. I can think of RISCOS and NeXT and that's it.
Windows certainly doesn't do it that way. Do you seriously think I can type in "msword" at a DOS/NT prompt and expect anything meaningful to happen? You'll get an error message unless you have specifically set the path to wh
Oh no, it's different! Let's hate it! (Score:4, Insightful)
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.
Re:Oh no, it's different! Let's hate it! (Score:5, Interesting)
Personally, I think it sounds like a great idea. If you're putting together a desktop system, there's really no need to carry around the old UNIX cruft. Honestly. And as much as the fanboys jizz all over OS X, I'd think this would be a welcome change. I suppose if this came with a system capable of real translucency and drop shadows, the l33t boyz would be jizzing instead of bitching, eh?
Learning the Linux structure, not changing it (Score:3, Interesting)
The directory structure in Linux is one of the biggest shocks to experienced Windows users who are accustomed to navigating the files and folders of Windows, and its complexity is a major area that needs to addressed if Linux is to make gains in the desktop arena.
Re:Is it just me, (Score:4, Insightful)
Just my 2 cents...
Re:Is it just me, (Score:5, Funny)
Of course it does. Using real words for directory names instead of easy to remember abbreviations is a mark of evil.
Remember, they did it just to piss you off.
Re:Is it just me, (Score:5, Interesting)
Re:Is it just me, (Score:4, Insightful)
What I don't like about the M$ scheme is that they still wont accept "/" instead of "\", and they have a real boner for treating compressed files as directories.
Re:Is it just me, (Score:5, Informative)
Anyway, there's nothing wrong about treating compressed files as directories (especially if they have more than one file inside them). Technically, there isn't a big diference between, say, a ZIP file and a directory with file compression enabled.
Windows' default directory structure is reasonable, but I find some of the names too long (you can change them, BTW; programs will still install in the right places). I don't like drive letters at all, I would prefer drive / device names. It's possible to implement it with shares (ex., "boot:\\" instead of "c:\"), but some programs have problems with it.
On NTFS drives you can also mount volumes as directories (ex., mount your CD drive as c:\cdrom instead of e:, or whatever). NTFS is actually quite civilised.
RMN
~~~
NT and POSIX (Score:5, Interesting)
Two old but interesting articles about the evolution of NT:
http://www.winntmag.com/Articles/Index.cfm?IssueI
http://www.winntmag.com/Articles/Index.cfm?IssueI
NTFS has other nice features such as symbolic links, named streams, non-continuous files, etc.. I learned a few tricks a couple of years ago in a newsgroup discussion from a guy working at Microsoft. Some of these features appear to be completely undocumented (or at least the documentation is very well hidden).
RMN
~~~
Blasphemy! (Score:5, Funny)
RMN
~~~
Re:Is it just me, (Score:5, Insightful)
No. Stupid people should not be allowed to use computers. People should know how to use computers, not how to click and drool.
Stupid people sitting at a keyboard are hazards to the rest of the computing world. They wreck data, they spread viruses, the break hardware, they waste IT support time, they cost businesses money.
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..
I fail to see why computers should be dumbed down for the dumb. It makes no sense.
Don't understand your computer?? Stick to your Playstation 2, and use your Gameboy as your PDA..
Re:Is it just me, (Score:3, Interesting)
Stupid people driving a car are hazards to the rest of the driving world. They wreck mailboxes, they kill babies, they break cars, they waste auto mechanic time, they cost taxpayers money.
If stupid people were kept away from steering wheels and stayed at home in front of a TV set where they belong and left the driving world to those that understand it, things would go smoother, there
Re:Is it just me, (Score:3, Insightful)
Dumb people do society no favors. They contribute nothing to the betterment of m
Re:Take your head out of your ass. (Score:3, Interesting)
Re:Is it just me, (Score:5, Interesting)
If you want to store information about how to handle and to interpret files, you have to be more verbose. That's why the MacOS filesystem had a ressource path from the beginning, and that's why NTFS has 64 KBytes for every file reserved for meta information.
Same with drive letters. Because drive letters were always overloaded with semantics (A: beeing the first floppy drive, C: the first hard disk) you run into limitations you don't need. When repartitioning one hard drive can destroy the installation of programs never installed on this harddrive, because they were expecting their CD-ROM in F:, and now it moved to G:, then something is wrong.
If you tell me now that programs should never expect a fixed letter for a CD-ROM and instead look for the type of the device, then you are supporting my point already: Putting too much semantics into single letters is not intuitive, and it is too easy to break it.
No, too much conventions in the Windows filesystems are a relict from CP/M times when memory was too precious to be spend on meta information and you just put everything into conventions hoping those conventions wouldn't interfere too much. But they never have been intuitive.
Re:Is it just me, (Score:3, Insightful)
I never found file extensions intuitive. Because they can only be three letters long they tend to condense to cryptic symbols far away from every intuition. .BAT files don't fly around during the night, and .COM files don't talk to the COM ports (except you have a serial mouse and MOUSE.COM as driver ;) )
Not wanting to jump on you for stating your opinion, but why on earth not? File extensions can be any length you want nowadays (er as of win95..)
Personally I find it alot easier to recognise thet blah
Re:Is it just me, (Score:3, Insightful)
Even though newly generated files can have arbitrary length for their file type extensions, you still have all those old conventions with you. Up until now most of the file extensions are three letters, and a lot of them have cryptic forms.
And: Having now up to 254 letters for your file basename gives you 253 letters for the file extension, but it doesn't solve
Re:Is it just me, (Score:5, Insightful)
Hmm, are you talking about those self-rearranging drive letters Windows uses ? Have you tried adding a second disk and see all your old drive letters suddenly change ?
Some people prefer to know where each device is, regardless of the other devices' locations. Except at installation time, you do not need to know the names, and I believe "mounting" a device into a directory is much more intuitive than assigning it a random "drive letter" that requires special path handling. Mac people have no problem mounting volumes after all, and desktop Linux GUIs are slowly moving in that direction.
It is the letter drive system that is the archaic one because MS-DOS did not have a unified filesystem on top of its block devices, and we probably still have it today for compatibility reasons.
True, but... (Score:3, Informative)
Technically true, and useful most of the time, but try something like merging a couple old small drives to a large one. You'll have no choice but to partition that beefy drive to end up with the same drive letters, or else do some serious registry surgery.
Good luck if one of those moved drives contains DLLs or utilities that the system expects to access during startup (I have had that situation. Ugly. Very, very ugly.)
Re:Is it just me, (Score:3, Interesting)
Re:Is it just me, (Score:3, Interesting)
Re:Is it just me, (Score:4, Insightful)
I am glad you said that, sir. A long HEX string to represent an Outlook "identity"? Why not just name it the name of the identity, or the numerical order in which it was created? For that matter; why not put the danmed thing with the rest of the users' "Application Data" for chrissake?
Of course - because the NT filesystem layout is designed for a single user with multiple users kludged on top. Putting people's application settings (/data) as a trailer of the Windows install directory? So now we have to hunt down their individual Application Data as well as the "Identities" for their mail client (Oh, and unless you've backed up their Outlook identities from their original, fully functional copy of Outlook, you can't get them back. Mail folders and address book, fine, but not their account information. What an architecturally advanced system!)
And drive letters? Forget the first three (A, B, C) - they're reserved. Floppies and boot volume. The next one or two are scrapped for removeable media (DVD-R and CD-RW?), then something like Nero creates a virtual CD-ROM image device, let's call it 'F'. Now we're fundamentally limited to 20 additional drives/partitions - including network mounted filesystems - in our "easy to use" filesystem design. Is it any wonder NTFS now has the functionality to mount volumes as paths? Why, isn't that just emulating the sensible UNIX method that's been around for years? What happens in Windows when the, oh, say, \Windows directory gets a tad full? \Program Files perhaps? Well, we'll just remove \Windows\Fonts to a separate volume... Wait! Drive letters don't do that! Let's look to UNIX for answers!
Now we move on to "Program Files". What an oxymoron that is! Half the installed application gets dumped into \Windows\System anyways, which forces you to go through "DLL Hell" trying to uninstall any application. "I don't know, it's shared, but are other programs relying on it? Will my system cease to function if I say 'Yes' to any of these 54 'Shared' DLLs?"
"My Documents"? One folder, stamped on the root of the filesystem? What is it, the computer's documents? But wait - Win2k and XP have moved it to the oh-so-simple to find (not to mention making so much sense) location of "\Windows\Application Data\Username\My Documents". Sure; I'll bet any joe blow can find their documents there! (Doesn't the Windows directory come with a disclaimer that you'll irreparably damage your system if you touch the voodoo within? But how will I ever retreive my "My Documents" shortcut, errantly deleted from my desktop! My documents can harm the system? (Well, macro viruses, but hey ... ))
Now then. "Temporary Internet Files". Great idea; now if only they'd stop defaulting the bugger to 10% the total drive space! NO, I would not like to dedicate 12GigaBytes to temp files, thankyouverymuch. Same goes for you, Mr. Recycle Bin! I have to purchase a spare 40GB drive just to give me the 120GB I initially paid for!
Re:Is it just me, (Score:3)
You can always mount an ntfs partition inside a folder in another ntfs partition.
I have to run an app that, for some reason, has the log dir hardcoded. When the fs was getting full, I just added a new drive and mounted it into the appropiate dir.
And, yes, drive letters are a holdover that should have gone away a while ago. I don't remember using the "b:" drive since my "a:" was a 5.25 incher (and Sierra ga
Re:Is it just me, (Score:4, Insightful)
Yes, that's a real os problem there. Good thing Mozilla doesn't put all your information into a randomly named directory. Sheesh. (Ok, so it may not be random, but it's different on every machine I've ever used; I haven't bothered to look up their method of determining the name of that folder. You can change it; that's just the default. But that doesn't stop it from being a funny practice that needlessly complicates matters.)
Now we're fundamentally limited to 20 additional drives/partitions - including network mounted filesystems - in our "easy to use" filesystem design. Is it any wonder NTFS now has the functionality to mount volumes as paths?
Yeah, it's a good thing that Windows hasn't used unc names since at least win95 and NT 4. Oh, wait a minute, they have. Typing \\server\directory is sooo much more difficult than
Now we move on to "Program Files". What an oxymoron that is! Half the installed application gets dumped into \Windows\System anyways, which forces you to go through "DLL Hell" trying to uninstall any application.
Yeah, I hate it when an os has all these shared libraries living in different directories and programs require a specific library. I never know if it's in
But wait - Win2k and XP have moved it to the oh-so-simple to find (not to mention making so much sense) location of "\Windows\Application Data\Username\My Documents".
So, have you ever used w2k and xp or have I just been trolled? I guess c:\documents and settings\USERNAME\my documents is too difficult? That's the default location and has been for several years.
So I guess my question is, did I just get trolled?
Re:Is it just me, (Score:3, Informative)
In NT4, it lived i
Re:Is it just me, (Score:5, Interesting)
Where the hell are you people getting this BS about it being in the windows directory?! It wasn't there in w2k. I should know, I'm running it right now. It's not there in XP (Professional). I should know, the computer next to me is running it.
That being said, the linux file system structure SUCKS! Windows isn't much better, but christ.. especially with the distros. Where is your config file for samba? Well, I don't quite know. It's somewhere in the
Having all the stuff AT LEAST symlinked from some common directory would be SO NICE. (cd
Re:Is it just me, (Score:4, Informative)
Probably because that's where it used to be. Back when I was using Windows, programs would either put config files in the windows directory, or their program directory. All of the system config files were in the windows directory too.
I don't know about samba specifically, but to follow good conventions, it should be called /etc/samba.conf or for multiple files be under the /etc/samba directory. Problem is, too many programs don't follow good conventions. This happens with MS Windows too.
I suppose it depends whether the programmers think of it as a config file (/etc) or data file (/usr/share). Then again, considering we are talking about KDE/GNOME programmers, who knows. I don't think they get *nix type systems in the first place.
The Linux tree makes more sense to me. If all the programs would follow the conventions, then backing up /etc, /usr/etc, and /usr/local/etc saves all the global config info. /home contains all user files and config info. /var/log contains the logs (Can be skipped if you're not paranoid). If you're running a server, parts of /var/spool may need to be backed up, but probably not for a desktop machine. Everything else can be ignored. bin, lib, share are already saved with your software disks. When backup time comes, this tree is quite easy, and has been standard for quite some time.
The main problems occur when programs don't follow the conventions. Lynx puts the config file /usr/lib/lynx--probably because the project started on a different system (DOS I think). I think Apache used to put all their stuff in /var.
The worst offenders seem to be developers who just came from a home computer background (MS DOS/Win, Amiga, Atari, whatever). They don't get the directory structure, so things go in the wrong places. When I first started with Linux, I had the same problem. I was so bad, I even wrote my own search program because I didn't know about grep.
Re:Is it just me, (Score:4, Interesting)
Therefore double clicking it will run the program, but you can easily go right in side of it and see all the files, and treat them like files. This works on the command line too. (cd
There are similar commands for any packager because there needs to be. There's also a command for sorcerer that finds files it's not tracking. When wanting to COMPLETELY remove something, I have to check that list as well. And then hope that IT is complete. Being able to check a directory for a "data" folder, back that up if I want, then blow out the directory would be nice. (Yes, this does screw up symlinks. Therefore it MIGHT be better to have the directory for the program contain the symlinks, as opposed to scattering the symlinks in to the one solid directory. Unless there's a way to reversely traverse a symlink in constant time..)
Again, a pipe dream I'm sure, and I'll admit there are certain things about the linux/unix file system that are nice. Configs mostly in one place, etc. But yikes it's certainly a mess. Something like this would help a great deal, I think.
(Another example: at a konsole, hit k, then hit tab. How many things come up? How many of those are kde programs? Are those ALL the kde programs? Probably not. What if you want to see all the executables that are part of the 'kde distribution' ? I guess you're off checking your package manager: Make a list of what you consider the kde distribution, run that list through the package manager, dump that in to a tiny little thing that sees if they're executable, etc.
Not too much different than just using ls/find/grep/bash/whatever, but what if your package DB gets corrupt? If bash/ext2 gets corrupt you have a bit more to worry about I'd think.)
FS/OS support for links makes it so easy to do such cool stuff that's essentially impossible in some other operating systems (Shortcuts are files that are treated specially by the shell in Windows. Not by the OS's FS layer. Therefore, they're nowheres comparable.) Why don't we use that support to make a FS structure that makes sense to everyone, and kicks ass? You can keep the old layout, and have a nice new layout too. Best of both worlds.
Re:Is it just me, (Score:4, Insightful)
It has a similar file system structure.
I believe that if we really want to have an OS dedicated to the masses, this very much is the direction to go.
Apple wouldn't bet their company on the same concept if they didn't didn't believe it as well.
Sunny Dubey
Re:Is it just me, (Score:4, Insightful)
Personally I dislike the windows filesystem hierarchy, especially the whole "Documents and Settings" thing. I much prefer
Re:Filename extensions (Score:3, Insightful)
Every half decend FS developer knows, that modern FSs will be databases (see BeOS, Longhorn, etc...)
This makes arbitrary hirachies like the one proposed by GoboLinux guys superfluous and offers a natural way to attach all necessary metadata to a file (like _if_ it can be executed, or what program might be able to open the file, who is
Re:Filename extensions (Score:4, Informative)
Err, what do you mean "no one can really tell?"
If the file has an execute bit set, it's probably executable. If the file has a directory bit, it's a directory.
Yeah, you need to understand the system before you can use it, but learning that system is trivial.
drw-rw-rw- tells you everything you need to know.
Re:Filename extensions (Score:3, Insightful)
Re:Filename extensions (Score:4, Insightful)
jrodman@Skonnos:~/tmp> ls
bongo.jpg
Okay now watch this:
jrodman@Skonnos:~/tmp> mv bongo.jpg bongo.txt
jrodman@Skonnos:~/tmp> ls
bongo.txt
Now what is it? On windows, it's a text file now. Do you see the problem?
On linux, it's trivial:
jrodman@Skonnos:~/tmp> file bongo.txt
bongo.txt: PNG image data, 256 x 239, 8-bit colormap, non-interlaced
Oops, it wasn't ever a jpg! The website lied. Wouldn't it suck if your web browser didn't support mime types and had to rely on extensions? Why do you like your OS to make the same error?
Re:Filename extensions (Score:4, Insightful)
Perhaps it is just me, but Yellow on White, and DarkBlue on Black just don't strike me as wise color combinations considering that a significant portion of the population will have trouble seeing one or the other, and possibly both. I know I have problems with these combinations.
Visually adding an astrisk '*' after an executable is also handy.
-Rusty
Re:Close but not quite. (Score:5, Insightful)
Allow me to expand a little on why this is the case:
Case-insensitivity is a complicated business as soon as you leave the simple domain of the english language, and this is the reason you usually only head english-speaking people wanting case-insensitive file systems.
An example: German has a letter ß, which in upper case becomes SS. tchüß -> TCHÜSS. Now, when lowercasing, you can't just map SS to ß, instead it becomes ss. I.e. TCHÜSS -> tschüss.
Do you start to realise the implications this has on a case-insensitive file system? (the question to answer is: is "tchüß" and "tschüss" considered to be the same file?)
It gets worse. In french, as spoken in france, the letter ë is converted to uppercase E. I.e. citroën -> CITROEN. But in Canadian french, it becomes Ë. I.e. citroën -> CITROËN.
When you start to bring in other languages, for example the Japanese full-with and half-width latin characters it starts to get really messy.
In order to handle all of this in a case-insensitive file system the file system itself needs not only to be aware of the intricate details of character encodings and casing for different languages, every single file system operation would also have to look at the currently selected locale in order to determine wether two names are equivalent or not. If you believe this is simple, read the FAQ's at the Unicode [unicode.org] site and you will never again suggest that the file system should be case-insignificant.
However, making a user application work independently of case in file names is a reasonable idea. However, it would have to be specified by the UI framework, for example Gnome. I'm not sure exactly if that idea would work at all since I haven't given it much thought.
I'm so happy the Unix file system is case-significant.
Re:Great Idea! (Score:5, Insightful)
I think the situations with the layout of Unix filesystems is very similar. "Locals" have no trouble finding their way around, and even find that the layout makes a good deal of sense. Unfortunately Unix is getting a lot more visitors than it used to, and those visitors are starting to feel like tourists in Venice (i.e. lost). If you want those visitors to find Unix "useful" rather than "quaint" you need to re-think the street plan.
Re:Great Idea! (Score:5, Funny)
Pah, you Americans and your right-angle turn streets. Come to Britain and experience true street confusion - streets that turn right/left, with 'new' streets that carry on in a straight line, streets that change their name half way along, crazy one way systems and roundabouts. Seriously, non-intuitive names are a piece of cake by comparison.
Of course, I quite *like* the mad streets over here, it's symptomatic of the wealth of history this country has, and grid-layout streets IMO feel very very artificial by comparison. But then, I'm biased.
Re:Great Idea! (Score:3, Interesting)
My sister lives in one where they plunked a golf course in the middle and didn't bother to rename streets. So, they deadend at the golf course then continue, on the the other side. If that is not bad enough, there are streets that end in "T" intersections, that then continue a block or two later.
Of course even worse is Cape Coral, FL. You will have a "28th Street", "28th Terrace", "28th Court", "28th Avenue", and so on. The
Heh (Score:3)
Re:Make it like Windows. (Score:3, Insightful)
Not just for newbies. Here's the question: is there ANYTHING inherently "better" about the old UNIX filesystems compared to possible alternatives?
What advantage is there to /usr/lib and /lib over "/libraries"??
None.
The staunch unwillingness here to seriously consider alternatives makes me think the Linux community is not NEARLY as "forward-thinking" as claimed.
I us