Quick post on installing ZFS as a kernel module, not FUSE, on Debian GNU/Linux. The documents already exist for getting this going, I’m just hoping to spread this to a larger audience, in case you are unaware that it exists.

First, the Lawrence Livermore National Laboratory has been working on porting the native Solaris ZFS source to the Linux kernel as a kernel module. So long as the project remains under contract by the Department of Defense in the United States, I’m confident there will be continuous updates. You can track the progress of that porting at http://zfsonlinux.org.

Now, download the SPL and ZFS sources. I’m running the latest RC, which seems to be quite stable:

$ mkdir ~/src/{spl,zfs}
$ cd ~/src/spl
$ wget http://github.com/downloads/zfsonlinux/spl/spl-0.6.0-rc8.tar.gz
$ cd ~/src/zfs
$ wget http://github.com/downloads/zfsonlinux/zfs/zfs-0.6.0-rc8.tar.gz

At this point, you will need to install the dependencies for SPL, then go ahead and compile and make the necessary .deb files:

$ sudo aptitude install build-essential gawk alien fakeroot linux-headers-$(uname -r)
$ cd ~/src/spl
$ tar -xf spl-0.6.0-rc8.tar.gz
$ cd spl-0.6.0-rc8
$ ./configure
$ make deb
$ sudo dpkg -i *.deb

Now do the same for ZFS:

$ sudo aptitude install zlib1g-dev uuid-dev libblkid-dev libselinux-dev parted lsscsi
$ cd ~/src/zfs
$ tar -xf zfs-0.6.0-rc8.tar.gz
$ cd zfs-0.6.0-rc8
$ ./configure
$ make deb
$ sudo dpkg -i *.deb

If you’re running Ubuntu, which I know most of you are, you can install the packages from the Launchpad PPA https://launchpad.net/~zfs-native.

A word of note: the manpages get installed to /share/man/. I found this troubling. You can modify your $MANPATH variable to include /share/man/man8/, or by creating symlinks, which is the approach I took:

# cd /usr/share/man/man8/
# ln -s /share/man/man8/zdb.8 zdb.8
# ln -s /share/man/man8/zfs.8 zfs.8
# ln -s /share/man/man8/zpool.8 zpool.8

Now, make your zpool, and start playing:

$ sudo zpool create test raidz sdd sde sdf sdg sdh sdi

It is stable enough to run a ZFS root filesystem on a GNU/Linux installation for your workstation as something to play around with. It is copy-on-write, supports compression, deduplication, file atomicity, off-disk caching, encryption, and much more. At this point, unfortunately, I’m convinced that ZFS as a Linux kernel module will become “stable” long before Btrfs will be stable in the mainline kernel. Either way, it doesn’t matter to me. Both are Free Software, and both provide the long needed features we’ve needed with today’s storage needs. Competition is healthy, and I love having choice. Right now, that choice might just be ZFS.

However, mounting an image file means knowing where the root filesystem begins, which means knowing how to offset the mount, so you can access your data correctly. I used the following:

First, I setup a loop back device, so I could gather information about its partition setup:

# losetup /dev/loop0 virt01.img
# fdisk -l /dev/loop0

Disk /dev/loop0: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009bdb7

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1        37943296    41940991     1998848   82  Linux swap / Solaris
/dev/loop0p2   *        2048    37943295    18970624   83  Linux

Partition table entries are not in disk order

In this case, the virtual machine filesystem is 21.5 GB in size, in reads and writes in 512 byte blocks. Further, it appears as though swap occupies the second partition, while the ext4 root filesystem occupies the first, and begins at sector 2048, or byte 2048*512=1048576.

So, now I just need to tear down the loop back device, and create it again with an offset of 1048576 bytes, at which point, I should be able to mount the device:

# losetup -d /dev/loop0
# losetup /dev/loop0 virt01.img -o 1048576
# mount /dev/loop0 /mnt
# ls /mnt
bin/   home/            lib32/       mnt/   run/      sys/  vmlinuz@
boot/  initrd.img@      lib64/       opt/   sbin/     tmp/  vmlinuz.old@
dev/   initrd.img.old@  lost+found/  proc/  selinux/  usr/
etc/   lib/             media/       root/  srv/      var/

At this point, I can edit my problematic /mnt/etc/fstab file to fix the troubled boot, and boot it up.

First, let’s look at the basic setup for getting an interface online with DHCP. The file we’ll be looking at this entire time is the /etc/network/interfaces file:

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

The first line tells the kernel to bring the “eth0″ interface up when the system boots. The second line tells the kernel to start the interface if a “hotplug” event is triggered. The third line defines the configuration of the “eth0″ interface. In this case, it should use IPv4, and should request an IP address from a DHCP server. A static configuration could look like this:

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 10.19.84.2
    network 10.19.84.0
    gateway 10.19.84.1
    netmask 255.255.255.0

The first two lines remain the same. In the third line, we have decided to use static addressing, rather than dynamic. Then, we followed through by configuring the interface. It’s important to note that the indentation is not required. I only indented it for my benefit.

What about bonding? Simple enough. Suppose you have 2 NICs, one on the motherboard, and other in a PCI slot, and you want to ensure high availability, should the PCI card die. Then you could do something like this:

auto eth0
iface eth0 inet manual
    post-up ifconfig $IFACE up
    pre-down ifconfig $IFACE down

auto eth1
iface eth1 inet manual
    post-up ifconfig $IFACE up
    pre-down ifconfig $IFACE down

auto bond0
iface bond0 inet static
    bond-slaves eth0 eth1
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lcap_rate faste
    bond_xmit_hash_policy layer2+3
    address 10.19.84.2
    network 10.19.84.0
    gateway 10.19.84.1
    netmask 255.255.255.0

Technically, I don’t need to tell the kernel to bring up interfaces eth0 and eth1, if I tell the kernel to bring up bond0, and slave the eth0 and eth1 interfaces. But, this configuration illustrates some points. First, there are the pre-up, up, post-up, pre-down, down, and post-down commands that you can use in your network interfaces(5) file. Each does something to the interface at different times during the configuration. Also notice I’m using the $IFACE variable. There are others that exist, that allow you to create scripts for your interfaces. See http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_scripting_with_the_ifupdown_system for more information.

On the bonded interface, I’m putting in two slaves, then setting some bonding configuration that I want, such as using 802.3ad mode. Of course, the interface is static, so I provided the necessary information.

What if we wanted to add our bonded interface to a VLAN? Simple. Just append a dot “.” and the VLAN number you want the interface in. Like so:

auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lcap_rate faste
    bond_xmit_hash_policy layer2+3

auto bond0.42
iface bond0.42 inet static
    address 10.19.84.2
    network 10.19.84.0
    gateway 10.19.84.1
    netmask 255.255.255.0
    # necessary due to a bonding bug in vlan tools
    vlan-raw-device bond0

Bring the interface up, the verify that the kernel has assigned it to the right VLAN:

$ sudo cat /proc/net/vlan/config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
bond0.42        | 42  | bond0

Notice that I specified “vlan-raw-device bond0″. This is due to a bonding bug in the VLAN tools, where merely specifying which VLAN the interface should be in by its name is not enough. You must also tell the kernel the bonded interface that the VLAN interface should be in.

How about bridged devices:

auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lcap_rate faste
    bond_xmit_hash_policy layer2+3

auto bond0.42
iface bond0.42 inet manual
    post-up ifconfig $IFACE up
    pre-down ifconfig $IFACE down
    # necessary due to a bonding bug in vlan tools
    vlan-raw-device bond0

auto br42
iface br42 inet static
    bridge_ports bond0.42
    address 10.19.84.1
    netmask 255.255.255.0
    network 10.19.84.0
    gateway 10.19.84.1

The only new thing here is the “bridge_ports” command. In this case, our bridged device is bridging our bond0.42 interface, which is in VLAN 42. Imagine having a KVM or Xen hypervisor that has a guest that needs to be in several VLANs. How would you setup all those bridges? Simple. Just create a VLAN interface for each VLAN, then create a bridge for each bonded interface in that VLAN.

Lastly, what about virtual IPs? I’ve heard that you can assign multiple IP addresses to a single NIC. How do you set that up? Simple. Just add a colon “:” the append a unique number. For example, say I have only one NIC, but wish to have 2 IP addresses, each in different networks:

auto eth0
iface eth0 inet static
    address 10.19.84.2
    netmask 255.255.255.0
    network 10.19.84.0
    gateway 10.19.84.1

auto eth0:1
iface eth0:1 inet static
    address 10.13.37.2
    netmask 255.255.255.0
    network 10.13.37.0

It’s important to note that you generally only need one default gateway to get out. Your kernel will route packets accordingly. If you must specify multiple gateways, then you must manually make edits to the kernel’s routing table, if everything isn’t setup correctly.

Of course, we could combine everything we learned here. See if you can make out what each interface is doing:

auto eth0
iface eth0 inet manual
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down

auto eth1
iface eth1 inet manual
    pre-up ifcanfig $IFACE up
    post-down ifconfig $IFACe down

auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1 eth2 eth3
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lacp_rate faste
    bond_xmit_hash_policy layer2+3

auto bond0.42
iface bond0.42 inet static
    address 10.19.84.2
    netmask 255.255.255.0
    netwark 10.19.84.0
    gateway 10.19.84.1
    # necessary due to a bonding up in vlan tools
    vlan-raw-device bond0

auto bond0.42:1
iface bond0.42:1 inet manual
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down
    # necessary due to a bonding bug in vlan tools
    vlan-raw-device bond0

auto br42
iface br42 inet static
    bridge_ports bond0.42:1
    address 10.13.37.2
    netmask 255.255.255.0
    network 10.13.37.0

Lastly, MTU. There is a lot of misinformation out there about frame size. In my professional experience, setting the MTU to 9000 bytes does not result in improved performance. Not noticeably at least. But it does have an effect on the CPU. Setting a larger frame size can result in much lower CPU usage, both on the switch, and in your box. However, some protocols, such as UDP, might break with a 9k MTU. So, use appropriately. At any event, here is how I generally set my MTU when dealing with multiple interfaces:

auto eth0
iface eth0 inet manual
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down
    mtu 9000

auto eth1
iface eth1 inet manual
    pre-up ifcanfig $IFACE up
    post-down ifconfig $IFACe down
    mtu 9000

auto bond0
iface bond0 inet manual
    bond-slaves eth0 eth1
    # LACP configuration
    bond_mode 802.3ad
    bond_miimon 100
    bond_lacp_rate faste
    bond_xmit_hash_policy layer2+3
    mtu 9000

auto bond0.42
iface bond0.42 inet static
    address 10.19.84.2
    netmask 255.255.255.0
    network 10.19.84.0
    gateway 10.19.84.1
    mtu 9000
    # necessary due to a bug in vlan tools
    vlan-raw-device bond0

auto bond0.43
iface bond0.43 inet static
    address 10.13.37.2
    netmask 255.255.255.0
    network 10.13.37.0
    mtu 1500
    # necessary due to a bug in vlan tools
    vlan-raw-device bond0

Note that I set the MTU to 9000 on all interfaces except for bond0.43, which is 1500. This is perfectly acceptable. In all reality, setting the MTU to 1500 on bond0.43 is just capping what bond0 can really do. But, it is important to set the MTU on each interface, otherwise the frame size of 1500 bytes will get set, and you’ll end up chopping up your packets anyway. You must also set the MTU to 9000 on the switch ports as well, and any other server and interfaces that you want jumbo frames on.

Salt is a powerful remote execution manager that can be used to administer servers in a fast and efficient way.

Salt allows commands to be executed across large groups of servers. This means systems can be easily managed, but data can also be easily gathered. Quick introspection into running systems becomes a reality.

Remote execution is usually used to set up a certain state on a remote system. Salt addresses this problem as well, the salt state system uses salt state files to define the state a server needs to be in.

Between the remote execution system, and state management Salt addresses the backbone of cloud and data center management.

Think Puppet on steroids. And done correctly.

At any event, yes, I’m looking for a Debian Developer to sponsor me getting it into Debian proper. If you are an Ubuntu Developer, and could help sponsor me getting it into Ubuntu as well, that would be awesome!

$ dd if=/dev/scd0 of=cdimage.iso # NO!

Or worse yet:

$ cat /dev/scd0 > cdimage.iso # NO!

As you are probably thinking, the problem with the two commands above, is that they provide no error checking while building the image. So, in order to make sure you have all the bits, you need to use another tool, such as using the MD5 hashing algorithm:

$ md5sum /dev/scd0 cdimage.iso
d642d524dd2187834a418710001bbf82  /dev/cdrom
d642d524dd2187834a418710001bbf82  cdimage.iso

Thankfully, the hashes above match. But, what if they didn’t? Then, you get to redo your dd(1) command (or, shudder, cat(1)) from above, and then rerun md5sum(1) to make sure you got all the bits. Doesn’t sound like much fun to me. Thankfully, there is a better way, one which handles the checksum while doing the copy.

You want to use readom(1) (“read optical media”) from the wodim(1) (“write optical disk media”) package. Consider the following command:

$ readom dev=/dev/scd0 f=cdimage.iso # YES!

If readom(1) fails to get the bits during the copy, it will let you know that it’s struggling. If it got all the bits, you know you have them all, because of the error checking during the copy. Sure will save you a lot of time running manual hashes when finished.

Now, what about burning a copy of the ISO image? Surely you use dd(1), yes? Something like:

$ dd if=cdimage.iso of=/dev/scd0 # NO!

NO! Instead, use wodim(1) directly:

$ wodim -v -eject cdimage.iso # YES!

For the same reasons that you want to use readom(1) for creating ISO images from CD/DVD, you want to use wodim(1) for burning ISO images to CD/DVD. What happens if after using dd(1) to create your CD/DVD, the md5sum(1) hash doesn’t line up with the image? You didn’t get all the bits, and created a coaster. Use wodim(1) and should it succeed, you can rest assured that you have all the bits.

So, remember, readom(1) and wodim(1) are the tools you want when creating and/or burning ISO images from the command line. Any other tool, and you’re likely doing it wrong.

The command which(1) (which is often a csh script, although sometimes a compiled binary) is not reliable for this purpose. which(1) may not set a useful exit code, and it may not even write errors to stderr. Therefore, in order to have a prayer of successfully using it, one must parse its output (wherever that output may be written).

Note that which(1)’s output when a command is not found is not consistent across platforms. On HP-UX 10.20, for example, it prints “no qwerty in /path /path /path …”; on OpenBSD 4.1, it prints “qwerty: Command not found.”; on Debian (3.1 through 5.0 at least) and SuSE, it prints nothing at all; on Red Hat 5.2, it prints “which: no qwerty in (/path:/path:…)”; on Red Hat 6.2, it writes the same message, but on standard error instead of standard output; and on Gentoo, it writes something on stderr.

(Quotation and manpage reference additions mine). So, if which(1) is bad news, then what is the “proper” way to determine if a command is in your $PATH? Well POSIX has an answer, and not surprisingly, the command to use is “command”:

The “command” built-in also returns true for shell built-ins. If you absolutely must check only PATH, the only POSIX way is to iterate over it:

There are also Bash built-ins that can be used, should you have Bash installed on your system:

Or:

If you prefer the ZSH (my addition not present in the wiki), as I do, then you can look in the $commands associative array:

I like that at the end of the FAQ, he gives a shell script for using which(1) should it be absolutely necessary. Not only do you have to test for exit code, but you also have to test for common strings in the output, seeing as though which(1) doesn’t always use exit codes properly:

CONCLUSION:
You have many options to find whether or not a command exists in your $PATH, some POSIX, some proper built-ins. Regardless, you should be able to build platform-independent scripts using the proper tools, and using which(1) is not the right tool for the job. Hopefully, this has convinced you of that.

At any event, in graphical user interfaces, you’ll see floppy disks that represent saving a file to disk. It’s very, very common, yet I doubt many of the younger generation has ever used one. So, how are they supposed to know what it does?

So, here’s a poll for you to take. You’ll need to take the poll at my site, as it uses Ajax calls to the page, which means it won’t work in your RSS reader, or on any other site. I’m just curious to see what falls out.

1. The command line interface.
2. Various shells, including their script syntax.
3. Builtin programming language support for many languages.
4. Common Unix utilities, such as grep, rsync, ssh, lsof, and others.
5. All the supported filesystems (ZFS, Ext4, Reiser, UFS, etc.).
6. Overall rock-solid stability and reliability.
7. Lack of viruses, trojans, and other malware.
8. Tremendous networking capabilities (PPoE, TCP/IP, etc.).
9. Bulletproof firewall software.
10. Overall builtin security in general (MACs, PAM, etc.).
11. Quality user/group management.
12. System resource usage.
13. Both vertical and horizontal scaling.
14. Portability.
15. Plain text configuration files.
16. Open source kernel and user-space software.
17. Based on standards (POSIX, FHS, LSB, etc.).
18. Vast selection of software choices (various text editors, MUAs, etc.)
19. Simplicity in software design- do one thing, and do it well.
20. Mind-blowing hardware support.
21. Support for hundreds of languages and locales out of the box.

shred -n 3 -v /dev/sda

It works well enough. However, it doesn’t display a real useful progress meter, other than how far it’s done in the wipe, thus leaving it up to you to figure out the speed, while filling up your back scroll in the process. There must be a better way.

I used to “leave my mark” (much like a dog marks a fire hydrant), however, this is quite slow. There are other methods, such as using /dev/urandom, but the entropy from urandom relies on SHA1. While fast, it’s not the speed demon that is AES or other algorithms. There’s /dev/zero, but how do I get random bits from zeros? And more importantly, does it push the drive to it’s bandwidth threshold? Of course, I’ve heard about DBAN, but I’ve had issues with it booting on certain hardware. Lastly, I would like to have a good progress meter as the data goes down on the drive.

Here’s a solution that a friend of mine in an IRC channel suggested:

openssl enc -aes128 -k "foo" < /dev/zero | pv -trb > /dev/sda

The great thing with this command is two fold:

1. It’s fast. It pushes the drive to as fast as it can write data.
2. It provides a convenient progress meter with “pv”

Again, I’m shredding drives with pseudorandom data. I’m not too concerned about the security of the bits going down on the platter. Per corporate regulation, I need to do 3 passes, and I’m confident that the bits coming out of the pipe from OpenSSL using AES-128 will be sufficient. So, for doing 3 passes, I can script it easily enough:

for I in 1 2 3; do
    openssl enc -aes128 -k "$I" < /dev/zero | pv -trb > /dev/sda
done

That works. 1 drive down, 24 to go…

If you have various ways you shred your drive, let me know, and I’ll post it below.

So, when installing on a desktop or laptop, I’m slightly annoyed by the default package sets that are installed. I understand why they’re chosen, and I’m definitely not arguing with the decisions made, however, some of the packages just aren’t for me. So, on my wiki, I’ve been documenting what should be installed and removed on every Debian GNU/Linux installation I make. As soon as the install finishes, I’ll login to the system, pull up my wiki, and copy and paste the following commands as root (trying to keep the horizontal scrolling in your browser to a minimum):

# aptitude install abiword apt-file checkconfig chromium-browser clusterssh deborphan flashplugin-nonfree git-core \
gmrun gnumeric htop network-manager openbox openssh-server python-docutils rst2pdf screen tango-icon-theme \
vim vim-gnome xfce4 xfce4-icon-theme xfce4-terminal xscreensaver-data-extra zsh zsh-doc

# aptitude purge dasher gnome-accessibility gnome-accessibility-themes gnome-mag gnome-orca gok nano \
openoffice.org{,-base,-base-core,-calc,-common,-core,-draw,-emailmerge,-evolution,-filter-binfilter,-filter-mobiledev} \
openoffice.org{-gcj,-gnome,-gtk,-help-en-us,-impress,-java-common,-math,-officebean,-style-galaxy,-style-tango,-thesaurus-en-us,-writer} \
xserver-xorg-input-{all,synaptics,wacom} xserver-xorg-video-{all,apm,ark,ati,chips,cirrus,fbdev,i128,i740,intel,mach64,mga,neomagic} \
xserver-xorg-video-{noveau,nv,openchrome,r128,radeon,radeonhd,rendition,s3,s3virge,savage,siliconmotion,sis,sisusb,tdfx,trident,tseng,v4l,voodoo}

First, I will identify which xserver-xorg-video driver I’ll need for the hardware I’m installing to, and remove that from the purge, even though the VESA driver always works just fine for me, as I’m certainly no gamer, and it’s never let me down in my desire to power any video card at any resolution and frequency I’ve encountered. I’ll also leave the Synaptics driver in place when installing to a laptop.

Second, I realize that this isn’t for everybody. Most people won’t care about having OpenOffice.org or the GNOME accessibility packages installed. I don’t need them, they free up hard drive space for me, and when running updates, downloads are much faster. So, this works for me.

Lastly, I have a hard time deciding between using GNOME and Openbox for my default desktop. I like the GDM for logging in, and I like the power management features that GNOME brings to the table. However, I like the minimalist approach to Openbox, and its configuration capabilities. I login to both from time-to-time, just in case you noticed that I’m installing Openbox, but also removing GNOME packages that would only come from a default GNOME install.

I’ve gotten tired of executing this on every install, and wondered if there was something more I could do. So, I mentioned my frustration on Identi.ca, not really looking for a reply, but one came through at any event (thread here). The reply was to use DPKG to get a list of the software that is installed when I’m finished with my install and purge, then use that list during the next install.

So, how to do this? Well, after you have your system installed the way you want, with all the packages installed and purged to suit your needs, run the following command:

$ dpkg --get-selections \* > packages.txt

You now have a text file with all the packages that are installed on your system. So, when doing a fresh Debian install at a later date, it’s trivial to get these packages installed, so I don’t have to do the install and purge copy/paste that I was doing before. After installing only the base, and nothing more, login to the system, copy the packages.txt file you created via SCP or some other method to the filesystem, and run the following commands (as root):

# apt-get update
# dpkg --set-selections < packages.txt
# apt-get -u dselect-upgrade

You now have your system installed with exactly the packages you want installed, and nothing more. Not only that, but the latest version as well. No need to update after you login (Windows, you could learn something here).

To me, this is beautiful. This is a simplistic way to clone a Debian system, without using utilities like Norton Ghost or CloneZilla, either though both have their place in administration. I just love the simplicity and elegance of this. To me, this makes administration fun. When I can solve simple problems with core system tools, I'm a happy admin.

Long live Debian.

First, Andrew mentions that Google Chrome has a “much faster loading time”. I have Google Chrome installed on both my work laptop running Windows XP and two of my GNU/Linux machines, one running Ubuntu 9.04, the other running Debian Sid. In all three cases, Google Chrome does launch from cold boot noticeably faster than Firefox, but the daily web browsing is not so noticeable. Unless I’m benchmarking the two browsers side-by-side, which is really only good for showing benchmarks, I don’t see any recognizable differences in speed when rendering HTML, CSS or JavaScript. I’ve used both Chrome and Firefox with Gmail, Google Wave, and many, many other processor-intensive sites, and I see no such conclusion that Chrome has a “much faster loading time” versus Firefox, who is making the web a slow experience.

Second, he addresses that Chrome doesn’t crash. Funny you say that. I’ve had both the stable version running on Windows XP and the unstable version running on GNU/Linux tank very recently. It only happened once, in both operating systems, and I have not been able to reproduce it, but it wasn’t just a tab failure. The whole browser went south. I honestly don’t even know what happened, but I do know what I was doing, and what was lost, but I’ll address that in a second.

Thirdly, he likes some of the snazzy tab features with Chrome. It’s apparent though, that the features he addresses in Chrome also exist in vanilla Firefox 3.5, such as the ability close all tabs other than the open tab (right-click the open tab, select “Close other tabs”). I do wish Firefox would get closing tab order and tab placement correct though. It does bother me that when I open a link in a new tab, it doesn’t open the tab right next to the current, and when closing tabs, it doesn’t do so in oldest to most recent opened tab. However, that’s the beauty of Firefox- extensions, which again, I’ll cover in a minute.

Fourth, I do like the default home page in Chrome, and I wish Firefox had it. I’m hoping we’ll see it in 3.6 or maybe 4.0. However, it’s hardly anything new. As usual, Opera pioneered the feature, Safari followed suit, then Chrome. It is a leg up on Firefox, however.

Fifth, the Omnibar in Chrome is no different than the AwesomeBar in Firefox, except for the search functionality. But, seeing as though the search box in Firefox is just a tab keystroke away, I hardly find this inconvenient, and worthy of a reason for switching browsers. Further, it’s limited in its search scope- it can only search from one engine, Google by default. The search bar in Firefox is much more customizable, giving you the option to add virtually any search engine to the browser. Google, Wikipedia, eBay, Ubuntu packages, and so forth. Sure, you can change the default search in the options in Chrome, but you have to change the option by opening the options dialog every time you want to make the change, rather than just do it on the spot ad hoc.

The sixth option is just silly. Known more widely as “porn mode”, every major browser comes with this feature, even in Firefox 3.5. A mere “ctrl+shift+p” will put Firefox into “Private Browsing”, not saving an ounce of history to disk. Further, rather than opening a new window, it caches off your currently open tabs, closes them, and puts the new porn mode tab as the current tab, all in the same window. When you’re finished, stopping private browsing will restore your tabs from the saved cache, including any text you might have typed in any form field. Sorry, but this point I found rather silly.

The seventh point is likely just as silly. Firefox has had a bright future from the outset. It truly is the poster child for a grass roots open source project that becomes mainstream. Version 3.6 is looking up, and 4.0 has a bright future as well. According to the browser market share trends, Firefox has been up, up, up.

Now, here are seven reasons why I won’t be switching from Firefox to Google Chrome as my default browser in the foreseeable future:

1. Extensions- I know this is “in the works” for Google Chrome, but I can’t ditch Firefox just yet. I have a must set of extensions for every install of Firefox I ever make. I used to keep an updated list of such extensions, but I haven’t updated in a while. Maybe I should do so. But, on every install, I need AdBlock Plus, FoxyProxy, FireFTP, Firebug, Web Developer, Tab Mix Plus, Weave, NoScript and Flashblock, just to name a few. Again, I understand it’s only a matter of time with Chrome before extensions appear, and they will sand-boxed too, increasing the stability and security of the browser. However, Chrome isn’t there yet, and as such, Firefox remains my browser.
2. Caching- Firefox is the only browser that I know of that gets caching right. If, for any reason, my browser crashes, and I was typing an email, when I pull the browser back up, not only are my tabs restored, but the data in the tabs as well, including each tab history, and the text in any form fields that I was editing (provided I’m keeping a history of everything, as is default on a new install). I can’t even begin to tell you how valuable this feature is. Yes, the whole browser crashes with Firefox, versus single tabs with Chrome, but when Firefox comes up, my data is in tact. When I restore the tab with Chrome, form fields and text boxes that were once populated are now blank.
3. Cross Platform- Even though I have Google Chrome installed on my Debian and Ubuntu machines, Google Chrome is still very much a Windows application. It just hasn’t reached prime time for Mac OS X or GNU/Linux. So, unless I’m ready and willing to take the rolls with the punches, I’m stuck on Windows. Yes, Google Chrome is getting more and more usable every day on GNU/Linux, but it’s still unstable and comes with bugs.
4. Portable Firefox- Being a college student, I’ve come to love Portableapps.com. I can take so many applications with me on a USB stick, plug them into a Windows machine at school, and off I go. Firefox is no exception. I can have all my extensions, plugins, settings, bookmarks and so forth with me on a single USB stick. This way, I don’t have to worry about installing Firefox should it not be installed, and I don’t have to prep it installing and configuring it the way I like. So, until Chrome becomes a portable app as well, which I don’t think should take long, Firefox is here to stay.
5. Speed- Firefox is still a fast browser, and 3.6 is looking to up the ante even more. Tracemonkey is comparable to speed with V8 in terms of JavaScript engines, and HTML/CSS rendering is also snappy. In fact, I noticed a great improvement from 3.0 to 3.5 in terms of speed. And when browsing the sites I do from day-to-day with Firefox and Chrome, I honestly can’t tell if one is faster than the other. Yes, from a cold boot, Firefox is a second slower. Maybe two. Other than that, IMO, it’s neck and neck, and as a result, I see no reason to switch browsers if speed is a factor.
6. Configurability- Firefox is the only browser I know of that tinkering under the hood is a snap. Just pulling up the “about:config” URI, and I can tweak to my hearts content, and I have. I’ve modified the way DNS is handled. I’ve modified the way proxies are setup. I’ve changed the backspace key behavior, and much more, and it’s easy. Further, if I don’t like the setting I’ve made, I just change it back, all while it’s running in a tab in the browser. No need for open dialog windows, or taking you away from your work.
7. Support- This might seem like somewhat of a weak point, but Google Chrome has a bit to go before the community reaches the masses that Firefox has amassed. Support forms, IRC channels, wikis, mailing lists and on and on. If I need help with the Firefox browser, I’m likely to get the support I’m looking for, regardless of the platform. As Google Chrome increases it’s market share, there’s no doubt that it will increase it’s support options and community as well. However, it’s not there yet, and literally pales in comparison to Firefox. There is strength in numbers.

These may or may not be your reasons for sticking with Firefox, but they are certainly mine. Firefox is a solid browser that is showing tons, and tons of potential. While it might not have some bells and whistles that Chrome has, such as a process per tab, or sandboxing extensions, it’s still a robust and stable browser, and as a result, still remains my default browser.

Unfortunately, as efficient as they can be, rsync and jigdo still hit the servers, even if it’s light. Bittorrent doesn’t have to, being a peer-to-peer technology. So, when you’re looking to get your latest ISO downloaded and burned, so you can hand them out at release parties, install on new boxen, or just for archival, it would be best if you used bittorrent. Of course, if you use bittorrent, then rather than cut the connection when you’re done, get at least a one-to-one ratio on uploads to downloads, so everyone can benefit.

Many popular bittorrent clients exist as Free Software for GNU/Linux, such as Transmission, GNOME Bit Torrent and rTorrent (text-based). Trackers will be ready, if they’re not already, and the ISOs will be ready to go. Just find a link with a torrent to grab, and start downloading and sharing. No worries either for data speeds. Everytime I’ve used bittorrent on the release day, my connection was always filled to the max at 1 MB/s. Let us not forget how popular Ubuntu really is!

See you on the other side!

P.S.: The Ubuntu help documentation has a good guide for upgrading from 8.10, if you go that route. https://help.ubuntu.com/community/JauntyUpgrades

So, why migrate from Ubuntu to Debian on the server? Surely, Ubuntu isn’t that bad of a server platform. You’re correct. It isn’t. In fact, it’s been “good enough” for me since installing it, which actually has an interesting history. This server came from a repossession when I used to work for a major home furnishings company in Utah. It was a home HP desktop computer that was old enough, my employer wasn’t interested in reselling it, so I asked if I could have it, and brought it home for $20.

This was back in 2005, so I put Ubuntu 5.04 on it as a desktop with XFCE as the window manager, as it’s only a Pentium 700 with at the time 128MB of RAM and a 10GB HDD. I’ve since beefed up the RAM and disk space. It was updated from 5.04 to 5.10, and it was at this time, I realised that I could ditch my then running Windows Server 2003 for Linux. So, Ubuntu 5.10 became a server, hosting my blog and a couple other web sites. When Ubuntu 6.06 LTS was released, it was running full time as my production server, and I became convinced of the LTS releases, determined to keep this server on LTS versions only. Also, I realised that it was running headless, so there was no reason to have X11 installed any longer, so I went through the pain of removing every last package that I didn’t need for a headless server. This was done for security as well as resource management.

It stayed on 6.06 LTS until 8.04 LTS released, at which point I upgraded the server yet again. So, from roughly May of 2005 to Feb 2009, it had been a desktop and a server spanning four upgrades. Not a big deal really. Upgrading servers and desktops is getting easier and easier these days, with less headaches being encountered. I would keep it on 8.04 LTS waiting for the next LTS release, and upgrade again if I hadn’t decided to change operating systems to Debian.

During the path of an Ubuntu server, it’s had some rough spots, as some of my friends can attest to, none of which were Ubuntu’s fault at all, but the system administrator hacking it (me). For example, when I wanted to host my web site on it, I needed to know how to make that happen. I found a HOWTO on howtoforge for installing Apache, as well as ISPConfig, and a number of other packages that I realise now were not necessary. In fact, I ended up removing ISPConnfig a couple years later, as it was causing problems with logs, consuming a large amount of RAM, and just getting in the way. Then I wanted to run my own email server. Not knowing how to set an email server up, I fiddled with Exim, Sendmail, Postfix and others, failing at every pass, and further causing havoc on the filesystem and DPKG database. Eventually, I found the help I needed from a friend, and was able to get a Postfix server up and running as an external MTA. There were many other services I messed with from time to time, testing this out or the other, slowly filling the filesystem with pointless stuff. In a nutshell, what I’m trying to say, is the Ubuntu 8.04 install, while functional, was no longer pretty. It was hackish at best.

This prompted me to do a reinstall of Ubuntu 8.04 LTS. I wanted a fresh, clean install, restoring the needed data from backup (yes, I actually run backups). However, as I began thinking about it, I realised that I didn’t trust the build quality of the LTS releases as much as I trusted the build quality of Debian stable releases. Thinking about it further, I was having a hard time convincing myself to run an Ubuntu server. The reason being the way packages are tested in the Debian repositories. Consider for example a package that’s uploaded to the unstable repository. Before that package can reach the testing repository, it much meet certain criteria:

• After the package has been in unstable for a given length of time, it can qualify for migration to testing. This depends on each package, and the urgency of the migration.
• The package can only enter testing if no new release critical bugs exist. This means, that the package must have fewer release critical bugs than the current package in testing.
• All dependencies needed for the package must be satisfiable in the current testing repository. If not, those packages must be brought in at the time the current package is, and they must meet the same criteria related to time in unstable and the number of release critical bugs.
• The package migrating to testing must not break any other packages currently in testing.
• It must be compiled for all release architectures it claims to support, and all architecture specific packages must be brought in as well, meeting the same criteria as mentioned.

The above criteria for packages entering the testing repository ensure that packages are reaching a bug-free state for the next stable release. The goal is to have the number of release critical bugs drop and drop and drop approaching zero. Of course, bugs are only brought about by an active community reporting them, then decided on whether or not the bug is critical enough to be labelled a release critical bug. After the packages in testing have reached sufficient maturity and have few enough bugs to qualify a release, the testing repository is brought to stable. The current stable becomes “old stable”, and the current testing is reprepared for the next stable release. So, in theory, the stable distribution is STABLE. Rock sold stable. Anyone who’s anyone in the Linux world knows that Debian stable is just about as stable as you can get for an operating system.

Another nice thing with Debian stable, is it releases when it’s ready. The Debian community has taken some flack for this, with 2-3 years at times between releases. However, Debian stable is the operating system that is high production quality. While most end users tend to run testing or unstable on their desktops or laptops, many prefer stable for their production server.

Now, I ask the Ubuntu community, what are we doing to ensure the same build quality for the LTS releases? I would think that each 6 month release would hold the some criteria as Debian, namely that packages can’t enter that release unless it has fewer RC bugs than current. This way, as we approach the LTS release, we’re slowly but consistently stabilising the operating system. Unfortunately, this would mean that Ubuntu wouldn’t be as bleeding edge as it is currently. Many packages would stay rather old, due to having less RC bugs than the current release. But then, the LTS releases would be much more stable.

Now, with that said, I personally have never had any problems with my LTS server, either Dapper 6.06 or Hardy 8.04. But do I want to risk it? Should I chance it? While nothing may ever happen that causes critical concern for me with an LTS release, I feel more comfortable putting my trust in Debian stable than I do Ubuntu LTS. However, I want to see Ubuntu LTS succeed in the server arena. I was ecstatic to find that Wikimedia moved all their servers, or are moving, to Ubuntu LTS. I’ve heard other success stories of migrations to Ubuntu LTS. I think this is good, and the larger the community gets, hopefully, the more bugs will be reported, the more patches will be submitted, and more work will be done upstream to Debian. There’s no reason why Ubuntu can’t learn from Debian, and vice versa, creating a solid symbiotic relationship.

So, in a nutshell, I’ve put my faith behind Debian stable for any production servers personally, and Ubuntu for any desktops and laptops that can afford a little wiggle room in relation to stability. This is my opinion with my hardware, and your mileage will probably vary. That’s what makes our community as a whole so great. I want to see Debian succeed on the desktop, laptop and netbook arena, and I want to see Ubuntu succeed in the server / Big Iron arena, and I’ll do what I can to make that happen. But for now, I am where I am.

Any questions or comments of course, please populate the comment form below.

Now, here’s what I would like to see from the community: quit calling the releases after their codenames. Start calling them after their version number. Here’s why. Most people don’t know what version “Feisty Fawn” was without thinking about it, or pulling up Google. For those who have been running Ubuntu, they’ll remember their experience with the codename if it was significant, but the average Ubuntu user doesn’t recall codenames. But, they do recall time, with how long they have been using Ubuntu. So, when I say “I’ve been using Ubuntu since 4.10″, or “Remember Ubuntu 7.04?”, then people will know more specifically what version I am referring to. However, when I say “I’ve been using Ubuntu since Warty”, or “Remember Feisty?”, people will most likely not know what version I’m referring to. Consider the following scenario:

I started with Linux when Red Hat Enigma released. I then moved to Fedora Yarrow, and left around Zod. Now I’m running Debian Etch as a server with Ubuntu Intrepid on my laptop and Hardy on my Desktop.

You get the idea. After all, you don’t refer to OpenOffice.org by it’s codename, or Firefox for that matter. So why refer to Ubuntu by just the codename?

So, when the announcement is made, the Internet will be a buzz about the new codename, and we’ll see image mock ups galore. But, would it be too much trouble to start calling the releases after their version number instead of codename? If you’re going to insist on using the codename, would it be too much trouble to append the version number with it? “Ubuntu Intrepid 8.10″. It would be nice to see the version numbers in blog posts, forums posts, mailing lists, IRC, and even in speech used much more. As long as you’re familiar with the how the version number is compiled, people will feel less alienated and more likely to know what you’re talking about.

With that said, I do enjoy the codenames as much as the next guy, and I even enjoy the wallpaper themes that have surrounded the codename on the past two releases. Further, by default, the codename is used in the repository sources file on every Ubuntu system by default, so, becoming familiar with them is beneficial.