I've finally figured out how the POSIX directory called "bin" works. I've wondered about how to tell your operating system where program files are stored ever since I heard, circa 1992, that it was inefficient to keep adding stuff to your Windows PATH variable whenever you installed a new program.

In Windows, when you launch a program, you usually click on a shortcut, or double click on a file, which in turn runs the command that starts your program. This command is called something like "word.exe", for example. The question is: if word.exe is installed in C:\Program Files\SuperWord\SuperWord Talker 8.0\, how does Windows know where to find word.exe?

It's actually simple. When you installed SuperWord, the installer added the path "C:\Program Files\SuperWord\SuperWord Talker 8.0\" to your PATH variable. In fact, every time you installed a program, the installer added its path to the PATH variable. In good time, your PATH variable looks something like:

C:\Program Files\Windows Resource Kits\Tools\;%SystemRoot%\system32; %SystemRoot%; C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;C:\kits\j2sdk1.4.2_10\jre\bin;C:\Program Files\Perforce;C:\Program Files\Common Files\GTK\2.0\bin;C:\bin;C:\Program Files\CVSNT\;%ANT_HOME%\bin;C:\Program Files\My Ass\Poo\;C:\Program Files\Mr. Poopy Pants\7.6\;C:\Program Files\Star Wards\;C:\Program Files\Crazy Crumbs Pick'm Up\;C:\Program Files\Lemmings 20\;C:\Program Files\Apache Web Server for Kids\;C:\Program Files\Microsoft\Internet\Explorer\4\;C:\Program Files\Netscape Navigator\1.0\;C:\Program Files\Flock\;C:\Program Files\Clock\;C:\Program Files\Block\;C:\Program Files\Truck\;C:\Program Files\Crock\;C:\Program Files\SuperWord\SuperWord Talker 8.0\;

Et cetera, et cetera.

Then, every single time you launch any program whatsoever, Windows always looks in every single directory listed in your PATH variable until it finds the program whose command you just launched.

So, in 1992, I heard that this was "inefficient". It strikes me as fairly intuitive why this way of searching for the location of a program could be ienfficient: you're looking through a lot of irrelevant directories. Why not just keep the directory name with the program itself?

Since that time, whenever I've gone on a cleaning binge, I've tried to remove entries from my PATH variable and find other ways to store the location of each command in a way that my operating system could read it. One of these techniques was simply to add the path to the command in every dialog box that asked for it. For example, when I change the default text editor that my browser launches, I enter the entire path, not just the name of the command. Another thing I like to do in Windows is to associate a different editor with any files that are in text format. In this case, I go through the Windows Reigistry and change all the paths that say "notepad.exe" to the full path to my preferred editor. I would do likewise with my web browser. This keeps my PATH variable short. However, it does mean entering a path in a lot of different places.

I had found it intriguing for quite some time, then, that in a POSIX-style system, all of the commands that run programs are stored in the directory called "/bin". How, I wondered, does the system manage the fact that every single program is in the same directory? Windows doesn't do this: Windows might put every program's directory in the big Program Files directory, but Program Files has a subdirectory for every program. Not in Debian: there, you have /bin, and all that's in /bin are files, one file per program. So the question floating at the back of my mind since I discovered the POSIX directory layout was, what happens when these programs in /bin need access to other files? How do they know where to search for them? What if they need libraries or configuration files? How do they point to all these things? If all you have is a program called /bin/toot, how does toot know where to find tootlib, tweet, boing or pow?

The answer is of course as simple as the Windows solution: the things in /bin are not programs at all, but just the commands that actually run the programs. If you open up /bin/toot in a text editor, you might find inside a line that actually runs the real program, and that specifies the location of that program, for example, a line like: "/usr/share/system/Program\ Files/My\ Program\ Files/Toot/8.0/toot.exe --volume 80 --nologging".

The advantage is, now when you run a program, the operating system only ever has to look in /bin to find the command that runs that program. That means that, if searching through a bunch of directories takes time, then you've saved time!

I don't know, however, if searching through all the directories listed in the PATH variable really takes all that much time. Computers have improved since 1992 after all. But my friend Arnold tells me that disk access is an important bottleneck (see Getting *ed by windows explorer) in computer speed, especially when mutli-gigabyte disks start getting full. It would seem to me, intutively, that reducing the number of directories that an operating system has to search to find a program would speed up the time it takes to launch that program, wouldn't it?

I could go through an analysis of the process of looking up a directory name in a filesystem table, then following that entry to the actual location of the directory on a disk, but I don't have the time right now. I'm pretty sure that no matter how you optimised your filesystem table, you still get better performance by not searching through a bunch of irrelevant directories.

All this said, this technique is by no means limited to Linux. You can make a directory called C:\bin on Windows, and you can put text files in this directory, each of which contain one line that actually runs the program. For notepad, you could make a file called C:\bin\notepad, and put a line in it like "C:\Windows\notepad.exe". Or you could make a file called C:\bin\firefox, and you could put in the line "C:\Program Files\Mozilla Firefox\firefox.exe". Then, you could remove the entry "C:\Program Files\Mozilla Firefox" from your PATH variable. Now, all you need to do when you want to run firefox, whether you are in Excel's Preferences window or just in the Windows Run dialog, is type "firefox". Of course, don't forget to add "C:\bin" to your PATH variable, since you still need to tell Windows that it has to always search C:\bin whenever it runs a program.

This is still a bit ugly on Windows, because it means that, now, instead of just Firefox nicely launching in a Firefox window like it always has, you will see a black command line window open first, a few instants before Firefox appears. And then, that black command line window will take up space on your Taskbar and on your programs list whenever you hit Alt+Tab. So I wouldn't recommend doing this for all your GUI programs. For more silent, batch tools like xsltproc or perl, though, this is much better than listing the path to every single one of them in PATH. I mean, at least it would have been much better in 1992.

Here is another reason I'm migrating to Debian: I just clicked on a directory in Windows Explorer, and it took about a month to open. Why is that?! Honestly, here are the stats:

• age of computer: < 1 month
• size of computer: Pentium 3.2GHz 2Gb RAM (sounds big to me)
• operating system: brand new fresh Windows 2003 Server
• time it takes to display a directory in Windows Explorer: 1 minute
• for comparison, time it takes Word to open: 2 seconds

I think you can see, from the last two stats especially, that there is something seriously funny going on with Windows Explorer. I don't have complaints about the rest of the applications, which for the most part are impeccable. I especially like how fast the Office applications start. But why does the simple operation of browsing my directories take an ice age?

In Debian, I am looking for a system that will tell me clearly why these things are happening. I know there's a reason, and I want the tools to find it. Without those tools, my work must cohabit with a nagging feeling that my computer is slewing off on paths off on which I have not authorised it to slough!

Since the journal is called "Windows to Debian", I should talk a bit about the operating system that marks the beginning of the journey.

I am wary of backtracking to Microsoft, and I fully intend to remain 100% Debian, with no dual booting. That said, I still have access to Windows computers at work, and my wife brings home a Windows XP laptop. So today, I used Windows to make an international video call.

I called my dad. We both ran Skype 2.0 with video calling. We both ran Windows. I had a Logitech Quickcam Zoom. My dad had no webcam.

I have no conception of the pain I would have had to go through to attain anything of comparable quality had I tried this on Debian. First: Skype 2.0 is not, as of today, released for any Linux distribution. So, I would have had to use Ekiga (previously called GnomeMeeting) to attempt to connect with video to my dad's computer. I would have had to tell my dad to use MSN Messenger, because MSN Messenger uses an open protocol to which Ekiga can connect, whereas Skype uses a closed protocol to which nobody can connect.

That's not so bad, but as of today, Ekiga's video support has not been released. I would have had to download the source code and build it myself. This is not impossible: as a student, and as a hobbyist, I've compiled source code, but I still don't quite understand how to do it properly on Debian.

Third, readers of this journal will know that I still haven't gotten my webcam working on Debian. Most of the articles that I have found about webcams on Debian begin with a sentence like: "Installing a webcam on Debian is one of the hardest things you will ever do."

So, in order to just make a video connection I would have had to figure out how to compile the source code for Ekiga, and then complete what is called "the hardest thing you will ever do on Debian". And then, would I have gotten a good quality video connection?

Because the connection we got between me and my dad was superb. Perfect voice quality, and he could see with clarity everything I pointed the webcam at. And all it took was plugging my webcam into the laptop. When I called my dad, Skype showed him the image automatically.

I do believe that I can match this experience with Debian, but I am not convinced that the effort and time I put in will equal the ease with which it worked on Windows. In this case, having Windows, in comparison to what Debian has made me suffer lately, was an absolute breath of fresh air.

Update: oops, Ekiga was released in beta with video support on January 16th. I had been eagerly checking the site for announcements, but had somehow missed that. What's more, Ekiga claims to have had video support since 2001. I think the issue is greater than this, though. If what the Ekiga site says is true, then I should have already been able to perform a video chat by now. But I have not been able to, and really, the only thing stopping me was lack of documentation.

I consider this a half-point for Debian. I appreciate the rapidity with which Ekiga was released after Skype 2.0, but it still doesn't solve my webcam problem, nor does it really clarify why I couldn't use Ekiga for video chat before.

Whereas two days ago, I had lost the wireless configuration from my bootup scripts, and I had been afraid that I would have to return to trawling the newsgroups for a solution, I booted up today to find that my wifi was working again.

What had changed? What could possibly have changed between the time I had turned off my computer on Wednesday, and the time I turned it on again on Friday?

This is the kind of thing that it distraughts me to discover in Debian. I was expecting a stability far beyond what I could find in Windows, the Windows that inexplicably slows down over time, making just the task of opening a folder to browse its contents an excruciating wait, no matter how deep I delve into the Windows Registry or the Services list to disable running programs, but instead, I seem to get behaviour that is just as unpredictable.

To be fair to Debian, there could have been another reason that my wifi did not work one day, and worked the next. If I am scientific about this experience, I can enumerate the following conditions:

• Two days ago, I was sitting farther away from my router (although I always get a good signal in that position).
• Two days ago, my internet provider could have had rupture in service (although this is rare nowadays).
• Two days ago, my wifi router could have been disturbed in some way.

However, I am not being scientific; just let down. Moreover, my mouse does not work all of a sudden. I am still not delivered of the need to perform a tedious investigation.

Over time, I tend to pile and pile up tasks that I want to complete in Debian, and instead of finishing any of the tasks, I keep rotating through the list hoping that something is going to turn out easier than what I've just failed to do.

Today, this method led to a big regression in my configuration. Namely, I lost the automatic bootup activation of my Wifi, which has up to now been one of my only successes on this system.

So I've got a gripe. I had a nice automatic Wifi working, and Debian erased it. Here's how.

We've got a baby on the way, so I decided that my top priority right now should be to get my webcam working.

So I started reading about my particular webcam and Debian, and I found several pages promising to get me going. One of these pages mentioned the need for an updated package called qc-usb-source. Before reading the rest of the article, I decided to use APT to check if I already had this package.

As root, I typed:

apt-cache search qc-usb-source

And I got a successful-looking result. But I wasn't quite sure if it was a successful result, because I also had an error. And I think the error was from my previous manipulation of APT preferences (these are in the file /etc/apt/preferences).

So I decided to try out some other APT commands first, just to make sure I got rid of the error, before proceeding with the rest of the article about the webcam was telling me to do.

And, woe is me, after undoing the preferences that I had recently manipulated back to their defaults, I typed in the following, as a test:

apt-get upgrade mutt

(I though this meant, "Advanced Packaging Tool: upgrade the 'mutt' email program." In fact, it appears to mean, "Advanced Packaging Tool: upgrade everything!" It ignored the "mutt".)

APT started upgrading every program in my entire system. To be fair, I realised what was happening, and I could have stopped it, but I thought "Well, why not? Let's get the newest versions of everything." The only problem came when the newest versions of everything included my kernel.

The entire upgrade only took about 45 minutes... but when it got to the kernel it gave me a message saying that after upgrading the kernel, it would have to "rebuild the modules dependency file" or something like that.

On top of that, Mr. Debian, who is supposed to allow you to replace kernels on-the-fly, even told me, Redmond-style, that I would have to reboot after this upgrade! Point against the spiral.

And indeed, when I rebooted, I sat through a painful series of requests for an IP address, and logged into my desktop to realise that I had no internet connection.

And that's where I am today. I was very disappointed, since, I repeat, getting my Wifi internet connection up automatically had to this point been my biggest accomplishment, and with a very standard command, I'm back to square one.

I will attempt to follow the same steps as previously to get my wifi connection during bootup, but I am afraid that my method is not very robust if it can be so easily knocked down.

I would also like to note that I am disappointed, because I can no longer claim to my Windows-loving friends that Debian never asks me to reboot.

Notes:

For the record: I've got a Logitech QuickCam Zoom.

APT is the Advanced Packaging Tool, used to download, install, and update most of your Debian applications.

I am using the 2.6 kernel. I do not compile my own kernel; I just installed a ready-made kernel image.

I had this problem reading a document that my friend wrote in Microsoft Word. I tried opening it in both AbiWord and OpenOffice.org Writer, and both screwed up.

The only funny thing about this document is that it contains one single huge table. This table is stretched out over 50 pages. This does not look at all strange, because the table is only used to align large paragraphs with their corresponding headings, and so there are only two columns, with large cells full of text.

What gives both AbiWord and OpenOffice.org trouble is that there are some large cells that span two or more pages. OpenOffice.org simply cuts the large cell at the end of its first page, so that I have no way to read the text that would normally span to the following page. (In truth, I can move the cursor down to that text, although the cursor disappears from view. Theoretically, then, I should be able to hold Shift while moving the cursor to the hidden text, thus selecting the text, which I should then be able to copy to the clipboard and paste, bit by bit, into a blank document. But that's a real, real, pain just to read a document.)

AbiWord reacts in, in my opinion, a worse way: once you scroll to the page containing the really large cell, you simply can't scroll past it. There is just no way to see any of the rest of the document.

So, I thought, why don't I try to upgrade to the new OpenOffice.org 2.0. I only have OpenOffice.org 1.1, and 2.0 is supposed to be much better.

Here's where I found out what Debian means when it says "stable".

The first time Debian booted, it took me by default to a graphical desktop. One of the questions I'm considering while I use Debian is what the typical Windows user feels when he or she switches to the "spiral system". In terms of putting a friendly face on the evil that is a computer processor, Debian is equivalent to its Redmond competitor. It may not start up initially with the prettiest desktop, but it's a desktop, and that means the user gets the certain comfort: he knows what he is doing with his computer. When my Debian first booted, it showed me its sober, sparse GNOME desktop, with all of the components you would see on a fresh Windows install... and more. But note that I don't put "more" on the same axis as "good". More could be better; it could be worse. And then: Debian's "more" is much, much different from Microsoft's "more". In this case of default desktop though, it didn't much matter.

It didn't matter because, despite the fact that Debian's default desktop reassured me that I had succeeded my installation, I had an immediate problem: my desktop was about two thirds of my screen. I suddenly had a big black border at the edge of my already-small laptop monitor. And, my initial foray through the Debian menus (which look like the Windows Start menu, only with "more"), did not yield results. I found some menus that seemed to mention screen size, but nothing changed the fact that my display was tiny.

I gave in almost instantly. Since I had performed the install at work (this was a smart move), I could go talk to B_____ about this problem. B_____ has Debian installed on several of his machines at work, and I get the feeling he knows what he's doing. In this case, he proved my feeling right.

Unfortunately, I can't tell you how B_____ fixed my small display problem. I couldn't follow neither his keystrokes nor his explanation, although I retained two things:

1. He said very clearly "All laptops have this problem, including when you install Windows".

2. He edited some text file and manually added a high screen resolution to several lists of screen resolutions in this file. If my memory serves me, he found lists that looked something like this:

   • 480x600

   • 840x960

   And he changed them to:

   • 480X600

   • 840x960

   • 1200x1648

   (I'm totally making up these numbers.)

So, considering point 1), I don't feel so bad that I didn't solve the problem myself, since I would have had the same problem on Windows. And, considering that I retained a few details of point 2), I think a quick google will probably direct me to the solution that my dear admin guy implemented, should I ever need it.

I now had a full sized desktop with a classy dark blue spiral background, and a couple of familiar-looking icons. My installation had worked.