• I am, by definition, “the intended recipient”.
• All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it where I please.
• I may take the contents as representing the views of your company.
• This disclaimer overrides any disclaimer or statement of confidentiality that may be included on your message.

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.

Lastly, both distributions have done a solid job in artwork and look-and-feel for their operating system. No doubt. However, there have been some bumpy roads with both as well. For example, I love the latest default wallpapers for the past two releases on both distributions. However, Fedora Core 6 isn’t a solid wallpaper, and neither is Ubuntu 6.06. Those who know me, know I’m not a fan of the Human theme that is default in Ubuntu either. But, the latest Fedora theme isn’t any better in my eyes as well. So, what are your opinions? What do you think about the artwork between the two biggest GNU/Linux distributors? Share you judgments in the comments below.

Click on an image to see an uncropped larger image. All images are in order of release from oldest to newest. Hover your mouse over the image to see the release info.

Fedora:

Ubuntu:

The first choice, openSUSE (it’s not “openSuSE”), wouldn’t be my first pick- maybe second or third, but it would still make the list. However, PCLinuxOS I thought was an odd choice. PCLinuxOS is based on Mandriva, the company with a failing business model. The only thing PCLinuxOS has going for it, is the plethora of non-Free Software applications they bundle, making the transition from Windows a breeze. Other than that, it’s just a run-of-the-mill-everyday-linux-distro. Nothing special. Certainly nothing on par with Ubuntu. It had its rise to popularity just about half a year ago, but it seems to be slipping, as packages aren’t fully tested, and the common experience overall is an unstable one.

What would have been my second choice? Fedora. Although I too am a heavy Debian/Ubuntu fan, and prefer DPKG to RPM, Fedora is an innovative distribution. In fact, I would reorder the list, and put Fedora first. Its only drawback is the focus on system administration over the desktop. However, they haven’t neglected the desktop, and have turned out an overall pleasant experience. Fedora is more bleeding edge than Ubuntu, which could also be seen as a good and bad thing. Good, in that you’ll be able to test newer software before others, bad in that this newer software will probably break something, and you get to figure out how to fix it. But hey, you’re learning your operating system, right?

The other choice I found really odd was Freespire. I think the author chose this distribution, because he didn’t want to put Debian on the list, but couldn’t find a good enough Debian desktop replacement other than Freespire. Freespire is a dead distro. They haven’t seen a release since September of 2007, and their parent distro, Linspire has had a bumpy road in the past, such as getting into a court battle with Microsoft over their previous name “Lindows”. Kevin Carmony also was president and CEO up until June 2007, where he abandoned ship, and joined the Ubuntu community. In fact, Carmony himself, has noticed that Linspire is dead, after being sold to Xandros. Freespire was a very poor choice to put on the list, mainly for the fact that the users won’t be able to find updates or support for this desktop choice.

Rather, he should have stuck with his gut feeling, and picked Debian. Debian has always been a rock-solid desktop, and from the looks of the upcoming release of Lenny, will continue to be so. The Debian developers do all they can to package the software in a manner that is most compatible with the majority of hardware out there. I’ve personally run Debian on my laptop and on my desktop, as well as countless VMs. There are so many advantages to Debian as a desktop, it’s really quite silly that it didn’t make the list. Plus, because of the Ubuntu community, Debian is growing, whether it be disgruntled Ubuntu users that switch to Debian, or Ubuntu working with upstream Debian to make it more popular, Debian is becoming a top choice among users. However, Debian has a few scars, and even a couple open wounds. Debian holds true to the Free Software ideals, which means they don’t believe in shipping proprietary software. This results in Debian not working with as much hardware as distributions that do ship with it. It also means a lighter selection of software applications and codecs. Now, Debian has remained practical, and you can enable the non-free repositories to get access to that software, but it’s not enabled for you, which means a new user is unlikely to know about it.

Lastly, Linux Mint was a good choice. I’ll agree with this one as well. Linux Mint is a fork of Ubuntu Linux, where greater usability is top priority. DVD playback, Win32 codecs, browser plugins, Java, Flash, and other software is bundled by default, and makes for a good comfortable choice for someone coming from the Windows camp, and wishing to not do a lot of work.

So, those would be my picks, in order of first Fedora, then Debian, then openSUSE and then lastly Linux Mint. it also seems that Distrowatch agrees with me, although our orders might be a bit mixed.