Friday, February 12, 2010

Where's my stuff?

Stop and think for a moment - Where is your stuff? Your data, your photos, your games, your music? If you run Windows, I'll bet it's on the "C:" drive.

But what does "C:" really mean? Why does Windows put your important stuff on a drive named so cryptically, "C:"?

This is because of drive letter assignment. It's a process by which Windows picks letters to represent a drive (such as a CDROM or USB fob) or a partition on a drive. Drive letters date back to the days of MS-DOS and CP/M.

The first two drive letters ("A:" and "B:") are reserved for floppy disk drives. I'd be really surprised if your computer still has a floppy drive. Dell stopped selling systems with floppy drives in 2003, for example, and other vendors quickly followed. But Windows reserves letters for floppy drives anyway, for backwards compatibility.

So "C:" is the first hard drive that's on a Windows computer, which is why Windows always boots from "C:". If you have more than one hard drive on your system, and any CDROM or DVD drives, you'll see them show up as "D:", "E:" and so on.

Plug in a USB fob drive, and it will show up in the first available drive letter. Maybe that's "F:" or "G:".

If you are on a managed network (like, at the office) you likely connect to a shared network server, and Windows assigns drive letters to these spaces too. In our office, my network "Home" directory is the "H:" drive. We keep other things on the "O:" and "S:" drives.

One thing becomes clear - all these drive letters make it really hard to keep track of my documents. Where's my stuff?

But Linux makes it really easy to find your data. Drive letters simply don't exist under Linux. Instead, USB fob drives, DVD drives, and shared directories on the network are all referred to by a path in the filesystem. And the GUI makes it all easy to find.

Let's say I plug a USB fob drive into my Linux computer. Linux identifies the drive for me, makes it available to me, and creates a desktop icon so I can quickly access the files there:

These screenshots were taken using a "demo" user I set up on my laptop, hence the "demo's Home" folder.

Easy, isn't it? This USB fob drive happens to have a volume name of "My stuff", so that's the name Linux gives it.

If I'm in an application, this USB fob is always accessible as "My stuff". It's also conveniently located under the "Places" menu:

That screenshot shows the "My stuff" USB fob drive, but also a few other drives that are on my system because Windows is installed on the hard drive - my laptop actually boots Linux from a fob drive. On a system that just runs Linux, you wouldn't see the "Bitlocker" or "2.6 GB Filesystem".

Also in that list is something else that's cool with Linux - bookmarks to servers. You can easily create a connection to another server over a standard network protocol (Windows share, SSH, FTP, etc.) In my case, I've set up a bookmark ("Project web site") to access the web site for a project I run outside of Linux in Exile. If I click on that item, Linux opens a file manager window right to that location.

In a managed Linux desktop (say, an office that runs Linux) the administrator can set up access to network servers. I used to be a Unix/Linux systems administrator, long ago, and we set up file access to central servers in a very transparent way. For example, your home directory might look like it's on /home, but really it's on a central file server. And we had network shares available under /net.

You can do the same thing under Linux today, but a desktop administrator would also set up bookmarks for you automatically so you always have a quick way to access those resources. To me, a shared file area called "Software projects" (which points to /net/projects, on a network server) is more meaningful than calling it the "P:" drive. And my home directory in /home makes more sense than the "H:" drive.

35 comments:

I'm about to go and defend Windows a bit in a moment, but I want to start out by saying that file system organization is one of the things I think that *nix overall does better than Windows. I wish Windows made it easier to set things up like a Unix. That said, I think you're being too hard on Windows, both in what you say Linux does better, and in neglecting a few benefits of the Windows-like approach.

(Also, I'm not going to address the GUI features like the places menu or putting the icon on the desktop. I've been out of the typical-Linux-GUI loop long enough I can't comment intelligently on that.)

First, IMO Windows doesn't feature drive letters quite as prominently as you indicate. In both open/save dialogs' pull down location menus (pic) and in My Computer displays (pic, pic), volume names are featured not just prominently, but I would say more prominently than the corresponding drive letters.

(If you're curious, the BD-ROM is an emulated drive I can mount ISOs on (Linux doesn't need this from 3rd parties I'll point out). Ignore all the folders on my desktop; I'm notoriously bad about plopping stuff there. The pull-down would be much less cluttered for people who don't do that.)

(To switch gears for a moment, faults with these views: "MY STUFF" on my USB stick wasn't put in all caps by my choice. For some reason, I can't set my USB volume label in complete freeform. It's also truncated at 11 characters. I suspect this is due to the file system being FAT32 on the USB drive instead of NTFS like on the hard drives. Also, now that I'm actually thinking about what I'm looking at, I have no idea why a floppy drive shows up. I don't have one. Maybe I the BIOS is telling Windows one is present and I need to change one there, or maybe I installed a virtual driver for some reason... I have no idea.)

Second, you can set things up to some extent with nmenonics. You'll notice I have media on M: and programs on P:. (I: for work doesn't have a particular meaning.) At work there are network drives mounted at S:, P:, and U: -- these have some meaning ("s" for "software" and "u" for user), the drives derive from their mountpoints on the Linux systems, /s, /p, and /u, so they weren't set up any better under Linux.

This does somewhat require having foreknowledge of how you'll use the drives -- changing letters after the fact can be problematic. (You can mount the same volume under multiple letters, which would help that problem, but this doesn't seem like an attractive idea.)

Third, there are actually a few benefits to Windows's approach. For instance, when I open My Computer, I instantly see a graphical representation of how much space each of my drives has. I don't think I've ever seen something like that in Linux, though there's probaly some program you can get that would do it (and there's always df -H). I also wouldn't be surprised if Gnome & KDE gave you notifications when you are nearly full. But certainly that's not something that at least the version of Gnome I was using for a while showed you without asking for the data.

Phrased another way: mounting a different (i.e. non-root) file system at /home/evan somewhat hides the fact that it's a different file system, but that's already a leaky abstraction. /home/evan will have a different amount of space that's available than /home/jh. If I move a large file or tree from /home/evan/path1 to /home/evan/path2 it will be nearly instantaneous, but if I move the same thing from /home/evan/path1 to /home/jh/path1, it will take a long time because it has to cross devices. Making the volumes first-class objects like the classical DOS/Windows model brings out these characteristics in a way that makes it trivial to see what's going on without having to know what file systems are mounted where.

There's another ancillary benefit too, which is that if you're working at the command line and are changing back and forth between say three or four different directories, this is easier to manage if you are using Windows and they are split between devices. The reason is the Windows command prompt keeps a different current directory per drive, so you have sort of two dimensions of motion: you can either change directories or change drives. This has been a minor help on a couple of occasions. (Of course, then cmd goes and screws up this benefit by making the drive changes not implicit in a 'cd'; if you're in C: and say cd D:\foo you then have to do D: to actually get to that directory (or run cd /D D:\foo). This is annoying far more than the previous point is helpful.)

Finally, it generally seems to be a somewhat narrowly-known fact even among CS/IT people that you can actually mount drives at path locations in Windows. It's not as flexible as it is in Linux, but in some cases it does work fine. (In others, not so fine; we'll come back to that in a minute.) This is a file system feature and not an NT kernel feature, so the directory you're mounting upon (e.g. like the /mnt directory) has to reside on an NTFS volume. But beyond that, mounting local hard drive on local hard drive should work pretty well.

(The problems come up when you do other things. I tried mounting a CD drive at a path a while back, and while it "worked", the behavior was a bit strange. Though I forget what exactly was wrong, I suspect it had something to do with whether the CD had media in it or not. I can see something similar showing up with network drives. Nowadays though Windows supports true symbolic links, so even some degree of this can be emulated by symbolic links to other drives.)

evaned, you do make some good points, but of course, a lot depends on preferences. I'll address a few of these points.

First, on mnemonics for drive letters. This is a good way to work around limitations, but you're still having to rely on a single letter to encapsulate an idea and sometimes that falls apart. Take, for example, your mention of i being the drive for work stuff. There is no mnemonic there. With mount points on *NIX, you can have much richer descriptions that make more sense readily.

As for showing free space, on KDE4 at least under Dolphin, there is a free space indicator in the status area for each mount. There is no good way to get a list like df with the application.

Thank you for mentioning junctions on Windows. It is a cool NTFS function (think of it as a "bind" mount), and I've had to use them on a few occasions to have things share directories. There isn't a really nice UI for it, however except for mounting full volumes at a path.

That being said, I do agree with JH on the flexibility that *NIX offers for making a filesystem layout make sense for your needs.

Actually, in the 3 screenshots you posted, the drive letter is right there. The point isn't that Windows tries to hide the drive letter - the point is that Windows still uses drive letters.

Why should a general user be in charge of volume management? That's what you get when you have to refer to everything by a drive letter. In your example, you have 4 non-removable storage volumes/drives, and 4 removable storage devices. That's 8 volumes to keep track of, to remember where everything is. Wow.

I agree with others above about "nmenonics" really being a crutch. Yes, we do that at our work too. That's why my network Home is "H:". We have a Shared area on "S:", and "P:" is for Projects. But we also have "G:", and "K:" and "X:" drives - none of these have nmenonics back to something. It's irritating when you need to find something.

Even not comparing Winodows to Linux, Windows is stupid. The places where your files are located are not related to either partitions on physical or virtual drives, or to drive letters. Not only is this complexified by different users, but various Windoes software .... ESPECIALLY that made by Microsoft, arbigtrarily stores some of the most important data in places that are scattered about system-related directories, and that would not be backed up if someone wanted to just back up one's "my files" or "my documents" folder.

Like all emails, all contact information, all templates, and a bunch of other stuff. Windows approach to linking the physicality of the data to the access methods is deeply borked, and often the only way to get to the data when something goes wrong is to run Linux and access it that way.

I work in an all-Windows environment, and a couple truths surface each day like gassy turds in the network. One is that Windows does not handle network hiccups gracefully, but that is a digression. The other is that when you plug in a jump drive, Windows is not smart enough to hop over scripted network share "drive letters" to assign a free drive letter to the jump drive. Instead it connects to the jump drive but forgets to give the user any conceptual bridge to it. Then the user calls support, and there we are with drive management telling Windows what letter to assign to the jump drive.

Windows users, however, cannot even imagine a computer without drive letters. Which scares them to death when they look at a Mac. And the idea of using Linux sounds downright alien.

Except my mother. She's 82, and I sent her an Ubuntu machine a couple weeks ago. She's using it. Still a little freaked out by the lack of drive letters.

"The places where your files are located are not related to either partitions on physical or virtual drives, or to drive letters."

It uses the same type of paths internally, it's just not exposed to users.notepad is really \Device\HarddiskVolume1\Windows\System32\notepad.exe

on my system.

"Not only is this complexified by different users, but various Windoes software .... ESPECIALLY that made by Microsoft, arbigtrarily stores some of the most important data in places that are scattered about system-related directories"

And Mac and Linux do the same thing, especially for some of the default stuff. See ~/Library/Application Support on the Mac, and the various . directories in Linux.

Am I missing something? "Where's my stuff?" It's exactly where I saved it. Like Documents and whatever subfolder I put it in. Or Music. Or if it's on a USB drive I just plugged in, then it'll be right there in the Window that pops up. I use PCs and Macs, and it's always where I expect it would be. Sure, continuing to display the old C, D, E, F etc is a bit odd. And Windows has plenty of problems. But this is neither confusing or complex.

I am looking forward to hundreds of drive-letter conditioned users adjusting to the Libraries. OK, not to the adjustment itself, but to the adjusted state. We will be transitioning our labs to Win7 this summer, if it doesn't break too many apps.

Chris, the issue isn't finding specific things you've saved in "My Documents" on C. The issue is that all the drive letters that make no sense make it more difficult to find other things like your flash drive or whatever. Like why is a flash drive assigned a letter like E?

Heh, anyone else find it funny that evaned was the one that suggested a post on how it's stupid that Windows 7 still uses drive letters, but was the first to defend Windows and say how great drive letters are?http://linuxinexile.blogspot.com/2010/02/when-backwards-compatibility-bites-you.html?showComment=1265692982490#c6536862456102302029

One thing that hasn't been mentioned is that drive letters can *change* for volumes when switching between computers. I've learned that if you manually assign a letter via the LDM MMC snap-in, it's persistent across machines, but otherwise the USB stick that is H: on one system can easily be E: or K: on another, based on what letters are populated.

The point that Greg made isn't that you can perhaps save to "My Documents", it's that configuration files, and often data files are saved to obscure folders without telling the user where it goes. In Linux, everything is saved somewhere in /home. In Windows, it can be saved anywhere on any drive, and the user may have no idea where it is saved, depending on the app that is in use. You don't necessarily know where everything has been saved, especially configuration files.

Hi there, I'm not a computer geek--I found this through another blog. As a long time windows user I have gotten used to drive letters and see nothing wrong with them. As Chris says, my stuff is just where I put it. The drive letters do seem archaic, but what's really wrong with them? Nothing anyone has said gives a better reason than the anachronistic use of letter designations. My former office used windows and I always used the letter drive names, but others liked to use their name designations--that caused some confusion. I'd say f-drive, others called it "shared", but both letter and name were visible.

Maybe I don't understand the Linux model described above, but you still have to remember whether your stuff is in "Misc", "stuff to read" or whatever.It's just a filing system, like file cabinets--you set them up how you use them.I've been using shortcuts to folders for ages--one click and I open the folder. Easy. I only keep a few, everything else is easy to get through Windows explorer.

I was a bit flummoxed by the addition of Libraries in Win 7 (and that the file manager wasn't obviously called Windows Explorer anymore--and it opens right from the taskbar now). The libraries seemed a bit odd and I don't like to be told where to keep my stuff as it seems to do. It seemed set up for folks who don't know how to set up their own filing system.

I'd probably be perfectly happy with Linux and if I hadn't gotten Win 7 on my new laptop, I was considering trying it. But frankly I don't have time to learn a new system these days, so I stuck with windows.

I was too late for Anon's comment. Now that's a reason windows is a pain, but I don't think that has anything to do with the drives having letter names. Even a home drive would need to be divided up into some sort of filing system-wouldn't it?I certainly have "lost" stuff in my computer. But if I try to pay attention to where it goes in the first place, I have no problems. I suppose windows has "taught" me to pay more attention. Maybe that's the crux of the complaint here?

But it's just as easy in Windows too. I know all my documents on my Windows box live in Documents and Settings.

On Linux my home directory in /home and yes you can muck with fstab to change things around. But as far as device level the drives are hda, hdb, etc. So Linux (and unix) does use a lettering scheme. It's just hidden.

Lynn: Right! Your stuff is where you put it except the stuff that Windows or a piece of software put there for you. If you spend a lot of time designing Word templates, be aware that they are not stored where you can find them and back them up intuitively. If you use Outlook for email, be aware that the attachments you store there (because you probably use email like a short term storage system, like we all do) are not where you put them, but where Outlook put them. Whereever that is!

I love your point about how Windows makes you more careful. It's true. People who work with the lions are rarely bitten by them!

*nix and Windoze file management operates on somewhat archaic metaphors. *nix of course is more sensible and very importantly, predictable, but Windoze isn't completely stupid given their starting point.

All that said, file management should probably be managed via a relational database, like BeOS did all those years ago. There are various halfway measures grafted into the major OSes, but none of them quite do it right. File management and the filesystem are different beasts.

Personally, I like having multiple access routes to files. At least one conceptually based and one based on the physical storage locations. I currently have something like 4 internal drives, each with multiple partitions, so it can get a bit complicated without simlinks. I know jack about Win7, but the lack of simlinks in previous versions was a real crippling defect.

Actually, in the 3 screenshots you posted, the drive letter is right there. The point isn't that Windows tries to hide the drive letter - the point is that Windows still uses drive letters.

To play devil's advocate for a second, why would it matter if it uses drive letters if it hid them from the user? (This is particularly true since that even drive letters are a fiction from the kernel's perspective, and things move back to a general rooted namespace within the kernel: C:\ is translated to the path \GLOBAL??\C:\ which is a symbolic link to \Device\HarddiskVolume2. Note that the kernel namespace isn't really what you get with Unix, so it's not like the kernel could just expose it directly and you'd have a Unix-like file system.) Of course, the real issue is that Windows doesn't hide the drive letters entirely.

By way of analogy, there's no place called "My Stuff" when you mount your USB disk on Linux; you can't address "My Stuff/foo.txt". The presence of "My Stuff" in the places menue etc. is a fiction, hiding the fact that it's actually at "/mnt/my stuff" or whatever.

Of course, the issue is that it doesn't completely hide them -- as you point out, they're still there. But if you don't use the command line, they're basically always right next to the volume name, so what difference does it make?

To be fair, my number is very very much inflated from the average user. I have several partitions for a variety of reasons; most people just have C:\ as a local disk. (Maybe D: if they have two physical drives.) I have a floppy drive showing for some reason; most people won't. I have a virtual CD drive; most people won't.

Beyond that, I can address your previous question:

Why should a general user be in charge of volume management?

Because, to a large extent, it matters. Setting aside the issue (which most people don't ever deal with) of multiple local disks and the (admittedly more common) mulitple network drives, it matters. If I have a USB disk, I care whether I'm saving to it instead of the local disk, so I know if it'll go with me when I remove the drive. If I have a network drive, I care whether I'm saving to it instead of the local disk, so I know it'll go with me if I move computers, and be backed up by the network FS backups. If I have a CD drive, I know that I want to run setup.exe off of it.

Think of the the first and last situation typically look in Linux: your USB or CD drive gets mounted at /mnt or /media. IMO, /mnt/My Stuff is no more meaningful a name than My Stuff (G:) if you stick to the GUI. About the only benefit the former has is that you can type in a path just by knowing the volume name. If you're a mouse user, there's no difference.

The only times I view the Unix layout as a clear benefit on this point are in the following situations: you have multiple local drives, you have multiple network drives, or you want to have a second device looks local for some reason. (One such reason would be a read-only network file system containing programs.) Even in the first situation, knowing the free space of each volume and whether you have space to store something at a particular path is something that most people will have to deal with at some point, and at that point you have to know about the volumes. Knowing whether a move operation is cross-device and will be slow is also something that some people will care about.

Basically -- the user has to pay attention to volumes no matter the OS because volumes matter for many operations. My USB stick is a different device than my hard drive -- logically, not just physically -- and having a distinction between them is in no way a bad thing. This distinction's only a problem when things that are logically somewhat the same -- different local disks, or perhaps different network paths -- are forced apart. See my last reply, to Lynn Wilhem, for another problem. (And drive letters are also a problem that for purposes of manually-typed paths, the drive letters are unpredictable (you missed this fact; though youngmug caught it!) and terse.)

@Greg:

Like all emails, all contact information, all templates, and a bunch of other stuff. Windows approach to linking the physicality of the data to the access methods is deeply borked, and often the only way to get to the data when something goes wrong is to run Linux and access it that way.

Yep, though that's the applications' fault, and arguibly Windows doesn't bear much blame on that point at all. (Which is separate from saying Microsoft doesn't, because things like Office are some terrible perpetrators of this.)

BTW, "all emails", "all contact information", etc. is stating things way too strongly; my email lives in ~\AppData\Local\Thunderbird more or less like it does in Linux.

@Some guy:

That's called trolling, man.

Read what I said again. I'm not arguing that drive letters are all where it's at -- I even said I like the Unix style of mounting wherever better. My point is that drive letters do have a number of advantages, and the issue is not nearly as one-sided as the original post purports.

The world isn't black and white. (And file systems is a place where my opinions are especially developed and nuanced, as I've given a lot of thought to them, which is why I'm writing so much.)

The point that Greg made isn't that you can perhaps save to "My Documents", it's that configuration files, and often data files are saved to obscure folders without telling the user where it goes.

Or to the registry. */me shudders at the thoughts of backing up your settings*

Though I do wish that Linux programs would start putting config files in ~/.config ($XDG_CONFIG_HOME or something like that is the appropriate place) instead of shitting out a bunch of .blah files in my home directory*, but it's still better than scattered around the file system and/or registry like is common in Windows world. I've considered writing an LD_PRELOAD library that would essentially virtualize any accesses to files or directories in ~ beginning with a dot, directing them to a different directory, but this seems dangerous.

* This causes two problems: first, I use those files enough that it's inconvenient to have them hidden, but infrequently enough that having them shown -- at least often alphabatized before normal files -- is really obnoxious. Second, it makes it hard to put them in version control. I either have to make my entire home directory a working directory, or (what I actually do) put the files in another directory then set up a bunch of symlinks back to ~. Both solutions really suck. For programs that actually use it (like Firefox and Thunderbird do), the Windows ~/Application Data directories are way better.

(While I'm on the subject of things I don't like about Linux FS layout which is not particularly relevant to the post, I tend to dislike Linux's "all binaries in /usr/bin, all libraries in /usr/lib" organization... usually works fine, even a little better, but when it goes bad, it goes baaad.) Ever need to remove a program you deleted the .tar.gz file and didn't use a package manager for? It's basically impossible. At least with the Windows system you can delete the install directory and almost all the time you'll at least have gotten rid of most of it. The Unix has more or less one benefit: you only need to add one path to $PATH, $LD_LIBRARY_PATH, etc., but I think there are better ways to handle it. GoboLinux and GNU Stash (I think that's what it's called) do a decent job at making that particular layout sane even within the Linux system. It's just too bad that no one agrees how awesome this idea is, so it hasn't moved into any of the big distros.)

Nothing anyone has said gives a better reason than the anachronistic use of letter designations

Typing paths in manually is more of a pain, because you can't use the volume names to help you. More generally, there's more flexibility in what you call things from the perspective of the command line.

One more problem is that it's less flexible to hardware changes and such. Suppose my hard drive is filling up, so I get another one. Might as well keep using the old one, so I want to copy half of my stuff over. But... how do I do that? If the first one shows up as C:\ and the second one shows up as D:\, now my file system looks different. At the very least I'll have to re-adjust to where I put my files. More likely, I'll have to do something like reinstall a bunch of my programs to D:\. With a global file system like Unix, what I can do is copy my /Program Files directory to the second disk, then mount it at /Program Files and I'm done. (The real story wouldn't be quite that simple probably, but you get the idea. Having the mindset where this is common and support for it being easy means that it can be more flexible.)

This goes back to what I was saying before -- while I'll basically always care about the distinction between local disk and USB drive, I rarely care about which local disk things are actually going onto, and using separate drive letters basically forces me to.

(While I'm on the subject of things I don't like about Linux FS layout which is not particularly relevant to the post, I tend to dislike Linux's "all binaries in /usr/bin, all libraries in /usr/lib" organization... usually works fine, even a little better, but when it goes bad, it goes baaad.) Ever need to remove a program you deleted the .tar.gz file and didn't use a package manager for? It's basically impossible. At least with the Windows system you can delete the install directory and almost all the time you'll at least have gotten rid of most of it.

Then you dont really understand the UX filesystem layout. If you installed something in /usr or /bin that was from a tgz file, then youre doing it wrong. Youre supposed to put user-compiled things in /opt. So /opt/mypackage. Dont want it anymore? Just delete /opt/mypackage.

Wow, I hadn't expected this topic to be so divisive. You either love drive letters in Windows, or you don't. There doesn't seem to be much middle ground.

Just to nudge the discussion back onto the original topic:

I'm comparing volume and filesystem management between Linux and Windows, from the user's perspective. I've said in previous posts that I like to stick to the GUI - while I grew up on the command line, most general users are comfortable only with the GUI. So I try to focus all my posts on using the GUI.

And drive letters in Windows are still very visible when using the Windows GUI. Sure, Linux may address physical drives as /dev/sda, ... but at the GUI (and in the command line, actually) you only access the path to data, not the device to the data. Removable drives like DVDs and USB flash drives show up separately - because these really are separate volumes and you need to know it's something that's not permanent. But as a desktop user, you can (and should) use paths to get to data, whether it's on the network (for example, using /net) or elsewhere on your system (say, /home might be a mount point to another drive.)

It's curious that in 2010, Windows still uses drive letters. Why? Because that's what Gary Kildall decided when he wrote CP/M in 1974.(ref) There really are better ways to do it now.

Also remember that I'm writing this blog from the perspective of a long-time Linux user who is using Windows again, after a very long time. The difference between Windows and Linux has been shocking, to say the least. Since I find it interesting when long-time Windows users experiment with Linux for the first time, I thought it might be equally interesting for this long-time Linux user to blog about my first experience running Windows in over 6 or 7 years. When I blog about something being "broken" in Windows, or something in Windows that is confusing, it's because that feature really is broken or confusing in Windows. At least, compared to Linux.

That's what this blog item was about. The drive letters method just seems too confusing - compared to how it's done under Linux.

Every few months, you'll see a staff writer for some tech magazine claim he's going to try Linux exclusively for a month or so. When the "experiment" is over, the writer usually has lots to say about how this or that thing doesn't work "right" in Linux, because it doesn't work just like Windows does. If tech writers can do this with Windows-Linux, I think it's fair to do the same with Linux-Windows.

I think if i had to access my LInux drive partitions using /dev/sda1, /dev/sdb1, ... I'd go mad. "sda" means nothing other than the first drive attached to my system, and "sda1" is the first partition. That's why we have a filesystem to keep things organized. You just don't see "sda1" or any of that, just "/home" or whatever. As JH said, that makes sense.

But somehow people don't mind when that same drive & partition is called C?

I can see that from the Linux perspective,the Windows method is just confusing.

evaned, as I was reading your comments, I was considering posting something similar to what osamabama stated. If you're installing a pre-compiled application outside the package manager, it should be placed in /opt. I know I do this with applications like Komodo, and it works well.

For self-compiled applications where I don't want to mess with building an RPM or deb, I'll often just use Slackware's package tools to build and make a binary, which gives me the freedom of a tar, but with the ability to uninstall cleanly.

JH, it is an interesting perspective. I say this as someone who was a heavy Windows poweruser for many years (even going to hex editing the File Manager binary in Win3.1 to cause the titlebar to read "File Mangler"), and who has been on Linux primarily for about 1.5 years now. Both ways of handling things make sense in their own environment, but it's very very different when switching. I do find Linux to be more logical in how things are handled, however.

Drive letters indicate multiple independent file systems, rather than a single unified view of the file system. This is a problem for several reasons, but I'll give you one easy one - walking a file system tree looking for a file.

In the unix model, the file system has a root under which all other directories lie. 'find / -name foo.txt' can find your file; 'find /cdrive -name foo.txt' cannot, assuming foo.txt resides under /ddrive.

The concept of a root directory is important in reality as well as in metaphor (the directory tree as hierarchy) and it's frustrating when you use a file system without that hierarchy.

About Me

I've been a Linux user since 1993, and since 2002 I've been fortunate enough to run Linux full-time at work. But, I've been asked to move back to Windows, at least for work. The difference between Windows and Linux has been shocking, to say the least. Since I find it interesting when long-time Windows users experiment with Linux for the first time, I thought it might be equally interesting for this long-time Linux user to blog about my first experience running Windows in over 6 or 7 years.