I don't want this to be a tech blog, and it will never be... Anyway...
I've been an advanced computer user (programming, modifying, etc) for more than 20 years now. I've worked on Apple II, DOS (from 3.0-the end), several Windowses (95,98,2000,NT,XP,Vista), and several linux distros (Ubuntu, Kubuntu, Red Hat, Gentoo). And there is this part on it that totally gets me confused and not wanting to explore...
THE ROOT DIRECTORY:
/bin
/boot
/cdrom
/dev
/etc
/home
/initrd
/lib
/lost+found
/media
/mnt
/opt
/proc
/root
/sbin
/srv
/sys
/tmp
/usr
/var
Hello? Can't we use a "little" more descriptive names?
/bin Ok, so by now I know this is binaries... but which binaries? I'll tell you one thing... ALL the binaries are not there. (Also please note... not a recycle bin - shouldn't be "emptied".)
/boot is good. Like it keep it.
/cdrom... well, it's good enough on it's own... almost like D:\
/dev devices maybe? This isn't perhaps the development libraries? (I'm trying to convey a point...)
/etc well, this is where it all started. What is /etc? What's the difference between that and /usr... and /usr and /home? I've tried to explore it, but it's got about 2 gizillion "files" in it... Windows has "Program files" where the space messed everything up for the first 2 or three years... but one thing I can say is that it's descriptive.
/home I know now. It's good, and can stay. But what is /usr then?
/initrd I have no idea. Something with initialization. But it's not part of /boot.
/lib This I know is libraries. Thinking of it as a literal library may make it easier to accept the total levels of chaos in there... (sorted chaos, but to the untrained eye, it is chaos) *phew* and don't get me started with the cryptic library names.
/lost+found Well, at least it's descriptive. I have no idea how to use it... or what even goes in there. But it's descriptive.
/media This makes sense, and wasn't there years ago. It's a good addition. And in a way makes /cdrom unneccasary.
/mnt GRRRR... I know now (ok for about 12years now) what is a "mounted" device. But we have media now thank you... /mnt or /media... why both?
/opt I dunno... I think it's new from the old days, and I assume it's options. Why doesn't it then go into /home?
/proc Again... No idea. Procedures? Processes? No idea, never visited there.
/root Okay... I know what / is... /root? I assume it's root's /home folder?
/sbin ... Uhmmm /bin is binaries... sbin? No idea.
/srv This one is new to Hardy. I assume it's server stuff. Dunno, don't care.
/sys *sigh* what is in here? Must be "system" stuff... but what isn't covered in /dev /opt /proc /boot /initrd?
/tmp Now here's one I can identify and understand. We don't even need an "e" because the data is so temporary we don't have time for the "e". So /tmp can stay, I'll be forever grateful.
/usr Well... see the comments on /home and /etc
/var No idea... Variables?
A fresh windows (vista, XP, etc... /etc?) install has about 5-8 "folders" in the root. It "hides" all the stuff that I don't want to know about. And it all looks clean and understandable.
Please Mr. Shuttleworth or Mr. Torvalds, please, please can we make this part a bit easier?
Subscribe to:
Post Comments (Atom)
9 comments:
I was confused for a while too. But Linux was not the cause of my confusion, it was Windows or more precisely, Microsoft. I guess I'm the one to break the news to you. You've been mislead, fooled, had, led down the path. Unix is the proto OS. Linux and the other variants are its progeny. Microsoft had a choice to follow that path but they chose differently. I don't know what the technical or proprietary constraints were but that decision is hurting them now. It's hurting you too. Microsoft can choose to change their directory structure any time they want because they are not beholden to any standards but their own, which can also change at any time. When Microsoft sneezes, the whole industry shudders. That's not a good situation. In spite of the fact that there are a bazillion distributions of Linux, they are very similar underneath. Their file structures are so close that any user who has bothered to become familiar with it will know his/her way around any other distribution. And it's been that way since its inception.
If that weren't enough, there is another gotcha. This too is not the fault of Linux but rather from the poor design of Windows. Linux is case sensitive, Windows is not. This fact has caused much trouble with Linux compatible software that must interact with Windows. The Samba project has had to deal with this unpleasant situation. While it's true that you can specify case in file names, Windows treats them as if they were all lowercase. Dumb. It's easy to see, once you've been exposed to a real file system, how Microsoft was not planning for the long-term in the design of their file system (What happens when you run out of the alphabet?).
I'm not even a geek and I know about this. I would never have known had I stayed with Windows though. As far as the names are concerned, they are short. Now that I think of it, almost all the names in Linux/Unix are short. I know the commands have many switches and parameters. I suppose the brevity makes stringing them all together easier for the administrator. I don't know but like everything else, once you get used to it, the other thing suddenly becomes foreign.
I see your point... But here's mine very briefly:
The fact is it is not GOOD.
It may be a set standard, and everyone may be doing it. The only good thing about it, is that all the distros use approximately the same stuff.
It's like saying: "Oh, they've invented this thing they call an 'Automobile'... But we should all continue to use our horse and cart, because that's the way we've always done it." Longer, more descriptive names are clearly better.
I mean really. The only reason it's so short is because they are C variable names. Their function is to type quickly (I assume it started before auto completion was implemented in bash).
That root must be close to 30 years old.
Also... Case sensitivity... Why must WE (humans, superior race, etc.) conform to the perfectionism of a computer. Case sensitivity can be called a feature, but it is really, really a pain in the behind, and serves no, no, purpose at all. I'll never run out of the alphabet, because I can just add a 2, or a 3 behind what I need.
I'll never have backup, BACKUP, Backup, all in the same place... I would have wanted all of them in the same folder.
If I *really* needed it... here's how I'd do it.
backup
backup_uppercase
TADA! :-)
Linux is for professionals, windows is for users. No more, no less.
I like when computers respect us as human beings so I agree in this point. So you say the system directory structure should be more comprehensive. You say that Linux must change this.
I want to confront this idea closer with the reality.
One argument from the other side is that the Linux/Unix directories and commands are really short. It's more efficient in the view of speed and time to write shorter sequences of letters, shorter commands. Not even that administrators have to type the same patterns many times interactively in the shell but they (and the system developers) also have to write very long shell scripts or makefiles - that are constituted of these, for now short and traditional names.
Yes, on the contrary, bash completion is already implemented… it's a great feature so the argument of fast writing comes partially into trash. That's the point of the speed of the work with the system.
But there's also an argument of small code size. Maybe you'll laugh over this one but it still comes into dispute. Wherever a huge path listing comes to word, it still sucks a bit of disk or memory space on behalf of other useful information. Yes but by today's sizes of operating memories and storage media… Maybe that part of the argument is a bit old-styled too.
And now there's the argument of rationality, hand in hand with nice, "human understandable" reading, on one side, and tradition on the other. It's well established and proven × it doesn't make sense and it's too cryptic.
It would be (at least sensed as) a standard breaking reform, not to say a revolution. I don't know much about Apple OS X but I think they did kind of such a reform in their directory tree.
But ask people why they don't change too rapidly from Windows to Linux even though Linux costs a bargain or namely nothing at all.
Human beings are very likely to be used to something, and every reform must prove its sort of "economic" usefulness (including ergonomy ;-) ).
Just start a distribution that would use your own naming standard and see if people like your scheme. Or find some group of enhusiasts that would like to start maintaining such a distro. I'd like to see your or their success.
In Mandriva Linux 2008.0, there were unlocalised names of the KDE and Gnome default folders in the users' home directories. I just made symlinks of them to the names I was used to before. How about to start customising the names by making symbolic links? Like:
/Program Files -> /bin
/Crucial System Program Files -> /sbin
/Settings -> /etc
/Optional Programs -> /opt
/Program Library Files -> /lib
/Users' Program Files -> /usr
A comment on case preservation: I like that. When you accent human readability and longer names I would suppose you would also prefer accuracy that in my opinion belongs to good practice in natural language usage (though my English doesn't shed a good light on me in that point) :-)
So imagine the elder days when a language dictionary would have been built up of files mentioning the topics as file names. Then the resolution made by letter case comes in handy - the original printed book would have cited i. e.:
- diamond - 1. precious stone, a special form of carbon, hardest natural jewel, 2. a graphical sign resembling the shape of a diamond jewel
- Diamond - a sparsely given girl's or dog's name, mostly by people who got rich quickly, sociologists suppose
- DiaMond - a diamond digging company claiming to work worldwide (therefore notice the Mond component)
In the directory, not to go so far, this would mean these three files:
"diamond.html"
"Diamond.html"
"DiaMond.html"
Would it be nice on the resulting web portal to have addresses ending with
…/diamond.html,
…/diamond%20-%20d%20uppercase.html and
…/diamond%20-%20a%20and%20m%20uppercase.html?
Yes, I metioned a special example.
I just tried to mention the plus points for letter case preservation.
But once more - having bash completion, all the letter case things come easier (if the completion doesn't find a file starting with lowercase, we can think of a file starting with a capital letter and try it).
I'm not on either side, just wanted to clarify those things for myself and to share these thoughts with others :-)
If the auto-completion would understand that:
d
[tab]
should find stuff that starts with D as well as with d, then one my frustrations will be addressed.
Just start a distribution that would use your own naming standard and see if people like your scheme. Or find some group of enhusiasts that would like to start maintaining such a distro. I'd like to see your or their success.
Had I been someone who understood linux a bit better I just as well might have... But I'd like to have it as an option. (Or have an option to do your symlink suggestion):
/Program Files -> /bin
/Crucial System Program Files -> /sbin
/Settings -> /etc
/Optional Programs -> /opt
/Program Library Files -> /lib
/Users' Program Files -> /usr
Thanks for this list! Now I understand it much better. In "my" linux distro though, I'll remove the spaces, and the other non alphanumerics. (I'll also remove the "crucial").
What is the point of having "opt" then? Isn't any program that you load "optional"?
Your CaSe preservation argument does bring the point across, and I would concede it, if the operating system can "guess" your intent. ie. If I write "Diamond" while only "diamond" exist, then take me there.
Yes, yes.
It would be fine to have the bash autocomletion more "intelligent", that is, as you describe, that it should recommend you the other letter case if no other alternatives exist. Or, as another option, the autocompletion could be a bit "case insensitive" - it could list all the entries regardless of their letter case.
This wouldn't be a great pain to rewrite the core of the completion script.
In my Mandriva, the completion is accomplished by a long bash script: /etc/bash_completion.
There I found that every type of completion is established by a call to some "complete" command.
So I thought this would be another script.
No, by typing "man complete" you can notice that it's a built-in command of BASH.
OK, so I went to "man bash". There you can find a section READLINE -> Readline Variables:
A variable may be set in the inputrc file with a statement of the form
set variable-name value
And the variable we search for is this:
completion-ignore-case (Off)
If set to On, readline performs filename matching and completion in a case-insensitive fashion.
So where do we find the initrc file? Humm, maybe the locate or find utility should help. The locate is much faster (though it needs to operate over a regularly updates map of your system) so i chose locate inputrc. And it gave me /etc/inpurc on the first place and that's the right one.
So, we can edit this file as root and set the completion-ignore-case variable on, right?
This addition to the file (maybe best on the start of it) should suffice your particular wish:
# Ignore case
set completion-ignore-case on
Then start a new shell (this could be accomplished by a single su command) and you'll get the new case-insensitive completion in it. In every new bash shell you then start you'll get the case insensitive completion.
So this issue won't mean a revolution but only a simple customisation ;-)
Yes, I know that you wanted a case insensitive completion only when there is only one option (one file etc.) to list. So this solution doesn't meet your request exactly but it may be of some use.
To the directory naming: yes, you are free to give it your own style - you're the author of the idea :-)
I don't know exactly what /opt means, I'm not an expert either. I only know that experimental stuff goes often there. KDE4 in Mandriva 2008.1 resides there because it isn't trusted as a finished work. So what maybe Mandriva wants to say by storing it there is, KDE4 is a "very optional" component; don't blame us if it doesn't work as expected, we warned you; we get our hands away from that stuff, we didn't push you to use it, we say it's optional. But as you say, what other component isn't optional in your system? We could find some – you have to have a kernel. Yes, it is replaceable by other kernels but you have to have one installed to run your system ;-) And then maybe a command shell (or maybe a single-purpose program that replaces it after boot). But, on the other hand, most of the stuff other than the kernel is really optional.
Yes, I know that you wanted a case insensitive completion only when there is only one option (one file etc.) to list. So this solution doesn't meet your request exactly but it may be of some use.
No, I think I wanted totally case insensitive completion, so thank you, that was exactly what I am looking for.
Great ;-)
I found a link to this blogpost on my own blog. Returning after a long time, and I have to correct myself in one thing.
The usr directory name on the Linux/Unix systems stands for Universal Serial Repository. It has nothing to do with user files. User files are stored in your /home/<user> directory.
Post a Comment