I’m serious.

Go out, buy a printer, throw away the driver CD that came with it, and just plug it in to your Linux system. This is what will happen:

Plug in your printer and start printing!

Firefox Print dialog

That’s right, no messing with drivers, no installing any stupid software that’s going to slow down your computer and cause you all sorts of headaches down the road, no extra drivers to install, you just plug it in and it works. Try that with Windows.

(This ease of use demonstration was performed on Fedora 9. Almost every printer manufactured through early 2008 is supported. For information overload, see LinuxPrinting.org.)

Well, OK, more people than that have heard of nginx, a lightweight, high-performance HTTP server and reverse proxy which was written by Russian coder Igor Sysoev. nginx is supposed to be able to handle as many as 8,000 to 10,000 requests per second using comparatively little memory, and while I get nowhere near that level of traffic, Apache has been a bit of a dog for quite a while, eating up all my memory and on occasion just taking my server out entirely.

So it had to go.

Now if you’re a web server administrator and you’re thinking of replacing Apache (and if you aren’t, you should think about it) the first thing you have to know is that there is no drop-in replacement for Apache. Things you’ve been accustomed to for years are suddenly going to be entirely different. For instance, nginx has no facility comparable to Apache’s .htaccess files, so it’s not going to work for shared hosting providers where multiple users have web sites on a single server. But I don’t have this problem, since I run all my sites on my own CentOS-based servers.

The first thing I did was to get a copy of the nginx-0.6.31 source RPM from the Fedora repository, update it to the latest version (0.7.6 as of this writing) and rebuild RPMs on my CentOS box. RPM may not be the perfect packager, but it at least keeps track of everything, so I try to use RPMs to install software whenever possible. If they aren’t available in CentOS repositories, I’ll grab a Fedora RPM and rebuild it.

After spending several hours Sunday writing up configuration files for my 16 HTTP virtual hosts and two SSL hosts, adding in customized nginx rewrite rules for software such as WordPress that I run, writing my own Red Hat init script to start PHP in FastCGI mode, and testing as much as I could, I stopped Apache and started nginx around midnight. I had a few problems with an SMF forum that I have, and caught a problem where I put the wrong document root in one virtual host, but the cutover went largely without incident.

I’d never used FastCGI before, and all my previous experiences with PHP in CGI mode were disappointing. I liked having it as an Apache module. And FastCGI doesn’t address my number one complaint about CGI, that it mangles HTTP headers. so I can’t tell in PHP exactly what came in on the wire. But I can’t argue with the results: With nginx, the site is much faster, memory usage has dropped significantly, the site is much faster, my server is running cooler, the site is much faster, and did I mention the site’s much faster?

I can probably even get away with downgrading my server and still have much more capacity to serve requests than I did with Apache. It’s that much smaller and faster.

I do have two complaints about missing features in nginx, though. The first is the lack of IPv6 support. I’m told that Igor plans to add this in the near future, and if he doesn’t, I may do it myself.

The second is the lack of content negotiation. This is where the server dynamically picks a file based on one or more possible alternatives. For instance if you request /index then the server looks for all files starting with /index and serves whichever one it thinks is most appropriate given whatever information the user has supplied (e.g. language, content encoding, and so forth). I used this little trick to remove the “.php” from some of my URLs in some custom PHP scripts, and all of those broke. Fortunately I was able to work around this with a simple configuration file change which I share here in case it helps someone else. Add this in the relevant location section:

                if (-e $request_filename.php) {
                        rewrite ^(.+)$ $1.php last;
                }

This will serve a file /example.php when you request the file /example.

Overall I’m quite impressed with nginx so far. I expect that now this server will stand up to anything that digg or slashdot can throw at it without even blinking. And now that I have room to grow, it’s time to actually start growing until I am getting 8,000 hits a second.

The good news is you’ll be able to set up encryption during the installation of a new system. You don’t have to install and then convert it anymore.

The bad news is it’s got bugs. Though I suspect they will be worked out before release.

Here’s a quick walkthrough of what installation with encrypted partitions is going to look like in Fedora.

First thing to do is decide whether you want the system encrypted in the first place.

In the installer as it is now, encryption is enabled by default. If you bypass this screen without looking, you may wind up surprised later. But, if you’re reading this, probably you won’t be.

Then you select your desired passphrase. (If you want to store a key on external media, such as USB stick, you can delete the passphrase and set this up after first boot.)

One thing to note is that Fedora prompts very early in the boot process for the encryption passphrase, and at the time the prompt is shown, no keymap has been loaded, so the system is using the default U.S. keymap. This means you won’t be able to type the passphrase correctly if you have a non-U.S. keyboard. You can probably work around this issue by selecting a U.S. keymap during installation, avoiding any odd characters in the passphrase you set, and selecting the keyboard map you really want during first boot.

If you select to review your partition layout, you’ll notice that the entire LVM PV is encrypted. This was done for ease of use and some other reasons.

But if you’re one of the 5 or 6 people (like me) who have been testing this functionality for the last two years, you probably have encrypted LVs instead. These will continue to be supported, and the installer should read them and prompt you for your passphrase when you perform your upgrade to Fedora 9. If not, it’s a reportable bug, so please test this.

Unfortunately, anaconda (the installer) still has some bugs.

Here, we see that it’s failed to create the encrypted PV. This bug has been reported already and should hopefully be fixed by the time Fedora 9 is released.

(By the way, anaconda can dump that traceback to a remote host via ssh. This is a nice touch; the last time I saw anaconda break, there was no way to get the traceback saved.)

As you probably know, I’ve been using an encrypted root filesystem (using encrypted LVs; the encrypted PV functionality is very recent) for a couple of years now. I’m looking forward to this installation issue to get sorted out so that I can more thoroughly test it and convert my own system to encrypted PV. (And I have to repartition the disk to reinstall Windows Vista with BitLocker anyway, but that’s another story.)

Aside from the keymap issue, there are some other caveats to using the feature right now, though. You may have trouble if you use a right-to-left language, such as Arabic or Hebrew. You also can’t hibernate your Fedora 9 system, even though the Hibernate button is shown; the computer won’t resume correctly. You must suspend, or shut down, until this functionality is added.

Even with the bugs and missing features needing to be added, I’m glad to see this feature finally come to fruition. Fedora is, unfortunately, one of the last major Linux distributions to gain this long-demanded capability, and I’m glad I don’t have to make RPMs for people anymore.

Unfortunately, while Fedora Core 5 and 6 support an encrypted swap partition, it doesn’t yet support encrypted root filesystems. (Due to release timing, official support is currently targeted for Fedora Core 7.) However, that doesn’t mean it’s impossible. In fact, I’ve done it. This is the second of a two-part series on encrypting your Fedora Core system.

(Read Part 1: Encrypting your swap partition on Fedora Core)

Before we get started, I must make one thing perfectly clear: This code is still experimental, and it could eat your files for breakfast, your children for lunch, drink all your beer, or do worse things. It works perfectly for me, but I can’t be responsible for your system, especially if you screw something up yourself. So follow along carefully. Read through the whole thing once before trying it, so you know what to expect.

Currently neither the Fedora Core installer nor the Fedora Core installation media support encrypted filesystems, so in order to create an encrypted system, you will need an already installed system, as well as a second hard drive (or partition) large enough to hold all the files on your root partition. For this reason, it’s best to do this just after you install the system, as you won’t yet have any sensitive files on the computer. Even if you do, though, we’ll securely erase the drive to help prevent recovery of your data.

In addition, you’ll need a Linux rescue CD which does support encrypted filesystems. For this example, I use the Gentoo minimal Live CD, as it has all the necessary kernel and userspace support to create an encrypted filesystem.

First, download the Gentoo minimal Live CD from OSUOSL or another mirror. (Currently the latest Live CD is /releases/x86/2006.1/installcd/install-x86-minimal-2006.1.iso.) Then burn it to a CD. It’s small enough to fit on a business card size CD. You can use another Linux live CD as long as it has a recent kernel and recent LUKS userspace utilities.

I am going to assume that you accepted all the partitioning defaults when you installed Fedora Core, and that your root partition is located at /dev/VolGroup00/LogVol00. If you installed it elsewhere, you’ll have to substitute the correct device. Also, I’ll assume that your second hard drive (or partition) which we’ll use temporarily will be at /dev/sdb1. Substitute your actual partition when running the commands below. Keep in mind that anything on that drive or partition will be destroyed!

The first thing you need to do is boot your (freshly installed?) Fedora Core system. You’ll need to obtain a patched copy of mkinitrd that understands encrypted root filesystems and can prompt you for the password. You can either get the patch yourself from Red Hat’s bugzilla and build RPMs yourself, or you can use the ones I’ve built for my own use. If you’re extremely paranoid, I suggest you build your own, but the instructions on how to integrate patches into and build RPMs are beyond the scope of this article.

Download the mkinitrd RPM and its dependency, libbdevid-python (and nash on FC6). The mkinitrd-devel package is optional. I’ve also provided the source RPM, with patch included, in case you really want to rebuild the packages yourself.

Fedora Core 5:

• libbdevid-python-5.1.15-1.i386.rpm (required)
• mkinitrd-5.1.15-1.i386.rpm (required)
• mkinitrd-devel-5.1.15-1.i386.rpm
• mkinitrd-5.1.15-1.src.rpm (source)

Fedora Core 6: (This is currently BROKEN on Fedora Core 6. Do not proceed until an update has been posted and this notice removed.)

• libbdevid-python-5.1.19-1.i386.rpm (required)
• mkinitrd-5.1.19-1.i386.rpm (required)
• nash-5.1.19-1.i386.rpm (required)
• mkinitrd-devel-5.1.19-1.i386.rpm
• mkinitrd-5.1.19-1.src.rpm (source)

Then install the packages. On Fedora Core 5, you may need to use the --nodeps option with these files as they were built against rawhide (but they work fine).

Fedora Core 5:

[root@fedora ~]# rpm --nodeps --replacefiles --replacepkgs -Uvh mkinitrd-5.1.15-1.i386.rpm libbdevid-python-5.1.15-1.i386.rpm

Fedora Core 6:

[root@fedora ~]# rpm --replacefiles --replacepkgs -Uvh mkinitrd-5.1.19-1.i386.rpm libbdevid-python-5.1.19-1.i386.rpm nash-5.1.19-1.i386.rpm

The next thing you’ll need to do is update everything. Among other things this will pull in the latest kernel, which you’ll need for encrypted filesystem support. The patched mkinitrd will, when the kernel update installs, create an initrd which understands encrypted root filesystems. The patched mkinitrd requires at least kernel version 2.6.17-2174. (2.6.18-2200 is current in FC5 at the time of this writing, and 2.6.18-2798 is current in FC6.)

root@livecd ~ # yum upgrade

Connect your second hard drive to the system, which we’ll use temporarily to encrypt all your files, and then boot from the Gentoo live CD or other live CD. Eventually you’ll get a root shell prompt. The first thing we’ll do is create mount points to mount our partitions:

root@livecd ~ # mkdir -p /mnt/disk1 /mnt/disk2

Next we need to load up the logical volumes:

root@livecd ~ # vgchange -ay
  2 logical volume(s) in volume group “VolGroup00″ now active

Next we’ll create the temporary partition on your second drive. It will be created at /dev/mapper/temp. We’ll also encrypt it using a throw-away key so that the data can’t easily be recovered later. (The /tmp directory is in RAM on the Gentoo live CD.)

root@livecd ~ # dd bs=32 count=1 if=/dev/random of=/tmp/temp-key
root@livecd ~ # cat /tmp/temp-key | cryptsetup luksFormat /dev/sdb1
root@livecd ~ # cryptsetup -d /tmp/temp-key luksOpen /dev/sdb1 temp

Now we’ll mount both the original partition and the temporary partition.

root@livecd ~ # mount /dev/VolGroup00/LogVol00 /mnt/disk1
root@livecd ~ # mke2fs -j /dev/mapper/temp
root@livecd ~ # mount /dev/mapper/temp /mnt/disk2

Then we’ll copy all the files over to the temporary partition, then unmount the original partition.

root@livecd ~ # cp -ax /mnt/disk1/* /mnt/disk2
root@livecd ~ # umount /mnt/disk1

The next step is to securely erase the original parititon which contained the unencrypted files. By default this command will write 25 different known and random patterns to the entire partition, which should leave the data formerly on it unrecoverable. Depending on the size of your drive, this may take several hours. You can add the -v option to see a progress report.

root@livecd ~ # shred /dev/VolGroup00/LogVol00

If you didn’t have any sensitive data on the disk, or you don’t care very much, then you can just write one pass of random data to the drive, which you’ll need to do anyway to help frustrate any future cryptanalysis. If you fail to do this, an attacker could be able to determine what data on your drive is encrypted, and what is garbage, and have an advantage in trying to recover your data.

root@livecd ~ # shred -n 1 /dev/VolGroup00/LogVol00

Finally, it’s time to set up the real encrypted filesystem and move your files back to your hard drive. First, you need to decide whether you want to use a passphrase to encrypt (an intermediate key which will then encrypt) your data, and boot directly from the hard drive, or whether you want to boot from a USB stick which contains your encryption key. I won’t be covering the USB stick method here, as right now it’s much more complex, the code isn’t well tested, and it’s much more inconvenient to use and maintain. As the code develops, I may post an update in the future.

Whether using a passphrase or a USB stick containing the key is the best method depends on your particular situation and the threats you are likely to face. For most people, the passphrase should be quite sufficient (provided it’s long enough). People who choose the USB stick method are those rare people who face torture or death if their data is compromised, and where simply losing the USB stick is sufficient to protect the data; since you don’t know the key, it can’t be rubber-hosed out of you. At the same time, though, you risk being captured with the USB stick still in your possession, which means all your efforts are for nothing. So there’s no one best solution for everyone.

The good news is you can start out with a passphrase now, and switch to a key on a USB stick later (when the code is better tested), without having to copy all your files around again.

So let’s encrypt your filesystem. Choose a long passphrase that’s easy for you to remember, but very difficult for anyone else to guess.

root@livecd ~ # cryptsetup -y -d aes-cbc-essiv:sha256 luksFormat /dev/VolGroup00/LogVol00
Enter LUKS passphrase:
Verify passphrase:

Now we’ll map the encrypted device at /dev/mapper/root, create the filesystem and then mount it.

root@livecd ~ # cryptsetup luksOpen /dev/VolGroup00/LogVol00 root
Enter LUKS passphrase:
Verify passphrase:
root@livecd ~ # mke2fs -j /dev/mapper/root
root@livecd ~ # mount /dev/mapper/root /mnt/disk1

Then we’ll copy all the files back from the temporary filesystem.

root@livecd ~ # cp -ax /mnt/disk2/* /mnt/disk1

One last thing. The Gentoo live CD doesn’t have support for SELinux, so if you use SELinux, (it’s enabled in the default Fedora Core installation) then everything on the new filesystem needs to be relabeled. So we’ll ask for that to happen on the next reboot.

root@livecd ~ # touch /mnt/disk1/.autorelabel

That just about covers it. Reboot the system, take out the live CD, and boot into your freshly encrypted new Fedora Core system! You’ll almost immediately be prompted to enter your passphrase. You have to get it right the first time; if you don’t, then you must hard reset the machine before trying again.

You can now erase the temporary hard drive you used for transferring your files around, if you like. The encryption key for it was random data which resided only in memory, and by this point will be long gone. Just to be safe, you can overwrite the disk partition you used again with some random data:

[root@fedora ~]# shred -n 1 /dev/sdb1

That should cover it. This thing has gotten just about as long as I’m comfortable making a post, so for the USB stick instructions, you’ll have to wait for part 3 (you can read the bugzilla for hints, but the instructions there are for PowerPC platforms). I also plan a quick tutorial on encrypting non-root partitions, in case you’re one who made your disks into multiple partitions and put different parts of your system on each partition. So I’ll wrap both of those into the update in probably a week or two.

If you find anything confusing, or catch any technical errors, please let me know and I’ll get them cleared up or corrected as soon as possible. Thanks!

Unfortunately, while Fedora Core 5 does support an encrypted swap partition, it doesn’t yet support encrypted root filesystems. (It’s looking like the support won’t make it into Fedora Core 6 either, due to release timing.) However, that doesn’t mean it’s impossible. In fact, I’ve done it. This is the first of a two-part series on encrypting your Fedora Core system.

(Read Part 2: Encrypting your root partition on Fedora Core 5)

In this part I’ll explain how to encrypt your swap space (it’s easy) and in the next part I’ll explain how to encrypt your root filesystem and everything else on your Fedora Core system (it’s a little harder, but not much).

Encrypting your swap space is vital even if you don’t encrypt your entire system, because applications which run on your computer sometimes get swapped out to disk, and with them, sensitive personal information such as passwords could be written into your swap space. And while you don’t have to encrypt your root filesystem in order to encrypt your swap space, it’s listed last because you do have to have a completed installation before encrypting your swap space.

To encrypt your swap space, first shut down any unnecessary applications to free up memory. You’ll have to temporarily turn off swap to complete the process, and if you don’t have very much memory in your computer, you may not be able to turn off swap if too many things are running. (In worst case, you can boot the system to single user mode using /sbin/telinit s which will shut down virtually everything except a single root shell.)

To begin, open a root shell by clicking Applications > Accessories > Terminal, and typing su - at the shell prompt. (If you booted your system to single-user mode, you can skip this, because you’re already at a root shell.)

[user@fedora ~]$ su -
Password:
[root@fedora ~]#

Next, turn off the swap space.

[root@fedora ~]# swapoff -a

Now, just in case anything sensitive was written to your swap space, we’ll overwrite the entire swap partition with random data using the shred command. This will help prevent recovery of anything that was written in that space before. Even if you’ve just freshly installed your system onto a brand new hard drive and nothing was in that space before, you should do this, because the random data will help obscure the fact that there is encrypted data in the partition. Expect this process to take about 30 minutes to an hour on newer hard drives.

If you installed your system without changing the default partitioning scheme, then your swap partition is located at /dev/VolGroup00/LogVol01. If you changed this during your installation, then you’ll need to substitute your actual swap partition below. If you aren’t sure, then you’ll find the partition listed in your /etc/fstab file; look in there to confirm where it’s located.

[root@fedora ~]# shred -v /dev/VolGroup00/LogVol01

Next, we’ll create a file to tell Fedora Core that the swap partition should be encrypted. Use your favorite text editor to create a new file named /etc/crypttab and enter the following data into it, separated by tabs:

swap    /dev/VolGroup00/LogVol01    /dev/random    swap,cipher=aes-cbc-essiv:sha256

This will cause a new device /dev/mapper/swap to be created at next boot which uses the default AES encryption and highly random data for the encryption key. Each time you reboot, the swap space will be re-created using a different random key.

Finally, you need to modify /etc/fstab to point to the new encrypted swap device. Open the file in your favorite text editor, and you’ll find a line such as this:

/dev/VolGroup00/LogVol01    swap    swap    defaults    0 0

Change it to this:

/dev/mapper/swap    swap    swap    defaults    0 0

Finally, reboot your system (if in single-user mode, use the reboot -n command). You’ll then be using encrypted swap space! But if you don’t want to reboot, create the encrypted swap partition for the first time manually using the following commands:

[root@fedora ~]# cryptsetup -d /dev/random create swap /dev/VolGroup00/LogVol01
[root@fedora ~]# mkswap /dev/mapper/swap
Setting up swapspace version 1, size = 2147479 kB
[root@fedora ~]# swapon -a

Don’t add those commands to any startup files, because they’ll be done for you automatically when your system boots.

I have tested and verified that this works on Fedora Core 5. It should also work on Fedora Core 4 and Fedora Core 3, after you download the available kernel updates for them, if what I read on the Internet is accurate. But what I read also hints that it may not be cryptographically secure on Fedora Core 2 because the startup scripts don’t initialize the random number generator before enabling swap. If you want to be sure, check the /etc/rc.d/rc.sysinit file, and make sure it seeds the random number generator before activating swap. (It does in recent releases.)

With Windows XP, this piece of software is called NTLDR. On Linux, it’s called GRUB. (There was also another bootloader called LILO, but it’s been obsolete for years and is not recommended for new installations, even if your distribution gives you the option.) Both of them do the same thing: they get the operating system loaded into memory, and optionally, present you a menu with different choices on how you would like to boot your system.

As I mentioned, there are two options for installing GRUB. First, you can install it to the Master Boot Record of your first hard drive. Second, you can install it to the boot sector of the active (bootable) hard drive partition. Which one is the right one? It depends.

If you intend to dual-boot Windows, then you should avoid installing GRUB to the MBR. The reason for this is that Windows occasionally overwrites the MBR, for instance, when you reinstall it, and that could be quite often. When that happens, your Linux system will seem to disappear as your system starts booting directly into Windows, bypassing the boot menu altogether. To avoid this, install GRUB to the boot sector of the active partition instead.

There’s an exception to that rule: If you are installing Linux to a secondary hard drive, and no part of it will be on your main hard drive, then you must install GRUB to the MBR, and take your chances with Windows overwriting the MBR with its own at some future date. If this happens, you’ll have to use a Linux rescue CD to get GRUB reinstalled. (I’ll cover this procedure in the future.)

If, however, Linux will be the only operating system on your computer, it’s perfectly safe to — and you must — install GRUB to the MBR.

Some special circumstance notes: If you run OS/2, you MUST NOT install GRUB to the MBR under any circumstances, or you won’t be able to boot OS/2! You will have to install it to the boot sector of the Linux /boot partition on your primary (first) hard drive. If you don’t have any free unpartitioned space on your first hard drive, you will have to use a resizing tool such as Partition Magic to create some space and have your Linux installation create the Linux /boot partition in that space. The space must be within the first 1024 cylinders of the hard drive. And it will have to be a primary partition as well, not a logical partition. Many computers can’t boot from logical partitions, only primary ones. The root (/) partition can be elsewhere, even on a secondary hard drive. You’ll then need to add the /boot partition to OS/2’s Boot Manager menu once you’ve completed the Linux installation.

If you have multiple Windows versions on your computer, and use a Windows boot menu to access them, you can add Linux to the Windows boot menu, but the process for this is somewhat complex, and I don’t intend to cover it here. Install GRUB to the boot sector instead, creating a /boot partition on the primary hard drive if necessary (see the OS/2 note above).

As you’ve probably gathered, the simple everyday act of booting up your PC is much more complex than you thought it was. This has a lot to do with the way your computer’s BIOS accesses internal hard drives. The BIOS is the very first bit of software which starts when you turn on your computer, and it’s located on a physical ROM chip inside the machine.

Twenty years ago, hard drives of 5 to 20 MB were common, and many PCs even shipped without a hard drive! Even as late as ten years ago, most computer BIOS software could not access more than the first 528 MB of a hard drive, creating booting problems. Eventually a solution called LBA (logical block addressing) raised this limit, first to 8 GB, and in more recent computers, to 137 GB. This is the range that the so-called first 1024 cylinders can access through the BIOS, before your operating system loads (using GRUB, NTLDR, or what have you). As hard drives exceed 137 GB now, and computers with 1TB of hard drive space are just now becoming available to consumers, the 20 year old BIOS design will again make trouble for the seemingly simple task of starting your computer.

Debian

Install the flashplugin-nonfree from the contrib unstable repository.

Fedora/Red Hat Enterprise/CentOS

The Mid-Pacific Linux User’s Group distributes RPMs for Flash Player 7 which you can download and install.

Gentoo

Run this command as root: emerge netscape-flash

Ubuntu

Install the flashplayer-mozilla package. Run the following command: sudo apt-get install flashplayer-mozilla

Did I forget your Linux distribution? Still can’t install it? Drop a note below.

But some poorly trained Web developers intentionally block out people who don’t use Internet Explorer, even when their sites work perfectly well with Firefox. Gap.com is one such site, and I’m sure there are many others.

A Firefox extension is available for you which lets you get in to sites like this. Named User Agent Switcher, its purpose is to cause Firefox to identify itself as Internet Explorer (or almost anything else) when you visit one of these Web sites.

After you install it and restart Firefox, you’ll have a new item on your Tools menu, called User Agent Switcher. Whenever you want to visit a site that blocks out Firefox users, go to Tools » User Agent Switcher and then select Internet Explorer 6 (Windows XP) from the menu. Then reload the page you were going to, and you’ll get in.

Once you’re done with the site, though, you should turn User Agent Switcher off, by going back to Tools » User Agent Switcher and then select Default. This way, other sites know you’re using Firefox, and the web developers of those sites know not to design sites that block you out if you aren’t using Internet Explorer.

If you want, you can also add a User Agent Switcher icon to your toolbar, by choosing View » Toolbars » Customize and then dragging the User Agent Switcher icon (it looks like a gray Earth) to wherever you want it. I personally have placed it between the Go button and the search box. Whenever you are faking out your user agent, the earth will be in color; otherwise it will be gray.

Finally, if you run across a site that blocks out non-Internet Explorer users, you should complain loudly to them about being locked out, and also consider doing your shopping elsewhere if they continue to lock you out. Remember that companies pay attention to their bottom line, and the idea of losing even a few percent of their revenues could be enough to get them to begin paying attention to Web standards.

So how do you figure out which one to use?

Perhaps the best place to start is with yourself. Make an honest assessment of exactly how comfortable you are with computers in general, and how much effort you want to put into learning new things, as Linux is full of them. Many of the ways of Windows that you are accustomed to simply don’t apply in the Linux world, and some argue that that’s because Windows has them wrong. Whether that’s true remains to be seen, but the fact is that even trying out Linux is going to expose you to a completely new way of doing things.

With that in mind, I’ll make the following suggestions and comments.

Regardless of your experience or comfort level with computers, Ubuntu is a great first choice. You can try it out directly from CD without having to install anything on your computer. If you decide Ubuntu is for you, then you can install it later. Knoppix also lets you run Linux from a CD without installing anything, but the installation process is a little more complicated, if you do choose to install it.

If you’re fairly comfortable with computers, and you foresee using Linux for business or to “get things done,” then check out Fedora Core and CentOS. While these don’t offer a live CD option, they do closely track Red Hat’s enterprise offerings, which are what you would most likely see in a business setting. CentOS is a free version of Red Hat Enterprise Linux and is considered a stable platform, while Fedora Core is the community-driven version on which it is based, and usually has more up-to-date software.

You should probably not try Debian, Slackware or Gentoo as your first Linux distribution if you have never used Linux before or are not extremely comfortable with digging yourself out of large holes. As you gain more experience with Linux, though, you may want to investigate these options.

In addition, as I said, there are hundreds of Linux distributions out there, most of which are highly specialized for particular circumstances. This means there’s a Linux for virtually every scenario. Distro Watch is updated daily with the release announcements for most known Linux distributions and is the best place to start if you are looking for a specialized Linux distribution.

If you’re already using Linux, which distribution did you try first? What did you like about it? What really annoyed you? Did you switch to another distribution later, and did it work out any better?

To conduct the study, the Browser Security Test people simply looked at how many days of 2004 each major browser had an unpatched remote code execution bug, that is, a problem which would let an attacker do whatever he wanted with your computer.

Internet Explorer had such a bug for all but seven days of 2004.

Actually there was only one period in 2004 when there were no publicly known remote code execution bugs – between the 12th and the 19th of October – 7 days in total. That means that a fully patched Internet Explorer installation was known to be unsafe for 98% of 2004. And for 200 days (that is 54% of the time) in 2004 there was a worm or virus in the wild exploiting one of those unpatched vulnerabilities. . . .

Mozilla and the family (including Firefox, Netscape Navigator and Camino browsers) display a much shorter window of opportunity for a prospective attacker. There were 56 days (15%) in 2004 when there was a publicly known remote code execution in Mozilla and no patched release. . . .

In 2004 Mozilla was not targeted by malware writers . . .

In total, in 2004 Opera had publicly known unpatched remote code execution vulnerabilities for 65 days (17%) – the two “unpatched periods” happened to intersect. There was no malware exploiting Opera bugs in the wild. — Browser Security Test

If you’re still using Windows, you need to stop using Internet Explorer immediately — well, after you’ve installed an alternative such as Firefox or Opera — and then disable access to it. Otherwise you’re just contributing to the security problem.

(Props to Schneier on Security.)