When comparing operating systems people tend to roll out the same old reasons every time. I think
those of us who use Ubuntu are already aware that we have less viruses than Windows, less
malware, it’s free of cost and so on. I’m sure we’ve pointed out plenty of
times that you’re legally entitled to copy the CD and even create your own remix.
However I wanted to look at some of the things I’ve done recently on Ubuntu that under
Windows would be costly, difficult or impossible. So without further ado here’s my:-
Top ten things you can do with Ubuntu, that you’d find hard, costly, impractical or
impossible with Windows, which clearly makes Ubuntu better (in my humble opinion)
Snappy title huh?
Hardware support is better than you think
In the last year I have added the following hardware devices to my system and they were all fully
supported out of the box with zero driver installations, no reboots, no 3rd party downloads.
Truly plug and play.
- HP Printer/Scanner/Copier/Fax – everything worked including the memory card slots and
network auto discovery.
- Logitech USB headset – microphone and headphones worked with pulseaudio, and even
enabled me to switch music playback dynamically from speakers to headset with the
‘pavucontrol’ utility.
- Bluetooth dongles – never had a single one fail, and I’ve bought some really
dirt-cheap devices here, where ordinarily I’d be wary about hardware support.
- Ortek infrared remote control – again, I just plugged in the USB infrared receiver and
it was working before I’d put batteries in the remote control.
- 3G dongle – this was surprising but again, plug in the USB dongle and network manager
on Ubuntu spotted it and let me use it for internet access. The same happened with my Android
based cellphone – the list goes on.
- USB Apple Ethernet adapter – amusingly on the bag it comes in it says “Only
compatible with Macbook Air”. This runs the internal half of my firewall
- Nintendo Wii USB Ethernet adapter
Of course it’s not perfect, there are still some hardware manufacturers who fail to support
Ubuntu, but the point stands, it’s better than most people think. Your mileage may vary, I
don’t doubt that, but this is my blog outlining my experience.
Access more than 4GiB RAM on a 32-bit install out of the box
Many 32-bit operating systems including Windows XP, Vista and 7 support a maximum of around 3GiB
RAM. With Ubuntu 9.10 the 32-bit install detects how much RAM the machine has and if it’s
more than 3GiB you should get a ‘PAE-enabled’ Linux kernel.
With no additional work required on your part, you get access to all the RAM in your PC. So you
don’t have to switch to 64-bit Ubuntu if you don’t want to, and still access all your
RAM. If you’re already running Ubuntu and you upgrade your RAM you can just manually
install the above named kernel to get access to all that lovely memory. Om nom nom.
Easily create a bootable, functional operating system on a USB stick
Ubuntu ships with “USB Live USB Creator” which takes an ISO image and creates a
bootable USB stick from it. Simply download an Ubuntu ISO image from http://ubuntu.com/download and start the USB creator application
on Ubuntu from System -> Administration -> USB Creator.
Tell USB creator where the ISO image is, and it can prepare and write the contents of the ISO
image a USB stick of at least 1GB in size. If you have a CD already and not an ISO image then you
can use mkisofs to make an ISO image, and then make a USB stick from that, which will save a
700MiB download.
Find out where each file comes from
The typical desktop PC has many thousands of files on the boot disk. Much of this will be your
own data in your home directory, but there’s a lot that’s required by the system to
boot up and function. Sometimes you might want to know where a file came from.
It may be that you’re a curious user, wanting to know how things got onto your machine, or
perhaps you’re diagnosing a problem with an Ubuntu installation. Either way it’s
trivially easy to find out where files came from – if you stick to installing packages
either from repositories or manually downloaded .deb files.
Lets say for example I am diagnosing a problem with my system – maybe a program is eating
CPU and I want to know where it came from. Knowing the package the process lives in is a good way
to find out why you have it (because the name and package documentation may describe it well
enough). Also if I wanted to file a bug against that program, I’d need to know what package
it’s in. Lets say for this example that my system is sluggish. I might use the System
Monitor to identify the process eating up CPU time.

Note: In the above screenshot Skype happens to be idle, but this is how I might discover the
process name if it was chewing up my CPU.
I can use the command line to discover where that file is located on the file system using the
which command:-
$ which skype
/usr/bin/skype
I can then use the dpkg command to find out which package installed this program:-
$ dpkg -S /usr/bin/skype
skype: /usr/bin/skype
We can even combine the two commands:-
$ dpkg -S `which skype`
skype: /usr/bin/skype
So this tells us that the ’skype’ package installed the ‘/usr/bin/skype’
program. Not surprising really, but you get the idea. Also worth knowing is dpkg -L which lists
all files installed by a package.
Email me when system updates are available
I have an Ubuntu PC behind my TV which I use to watch streamed video via Boxee. More often than
not the TV is switched off, and when it’s on it’s showing the Boxee user interface
and not the Ubuntu desktop. So I don’t tend to see any update notifications – in fact
I don’t want to see them – especially if I’m watching telly.
I’d like to know when there are updates pending on that system, so I have configured it to
send me an email when there are updates available. Installing a package called apticron. Just
edit /etc/apticron/apticron.conf and maintain the “EMAIL” setting, placing your own
email address in the quotes, and remove the # from the start of the line:-
EMAIL="alan@example.com"
Then wait. Each day apticron will run and you’ll get an email telling you what packages
need updating.
root@revo1 to me
show details 9 Mar (2 days ago)
apticron report [Tue, 09 Mar 2010 21:12:09 +0000]
========================================================================
apticron has detected that some packages need upgrading on:
revo1
[ 127.0.0.1 127.0.1.1 10.10.10.124 ]
The following packages are currently pending an upgrade:
gnome-screensaver 2.28.0-0ubuntu3.5
micromiser-beta 2.1.2-0karmic1
========================================================================
Package Details:
Reading changelogs...
--- Changes for gnome-screensaver ---
gnome-screensaver (2.28.0-0ubuntu3.5) karmic-security; urgency=low
* SECURITY UPDATE: information disclosure via monitor hot-plugging
- debian/patches/11_CVE-2010-0285.patch: make sure to show windows that
are added in src/gs-manager.c.
- CVE-2010-0285
* SECURITY UPDATE: locked screen bypass via monitor hot-plugging
- debian/patches/12_CVE-2010-0422.patch: improve window handling logic
in src/{gs-grab-x11.c,gs-manager.c,gs-window-x11.c}.
- CVE-2010-0422
-- Marc Deslauriers Tue, 02 Mar 2010 16:48:56 -0500
--- Changes for micromiser-beta ---
micromiser-beta (2.1.2-0karmic1) unstable; urgency=low
* Initial release
-- btbuilder Thu, 04 Mar 2010 19:18:06 -0500
========================================================================
You can perform the upgrade by issuing the command:
aptitude full-upgrade
as root on revo1
--
apticron
Note: You may need to some basic configuration of the mail system on the machine sending the
mail. The default mail transfer agent is ‘postfix’ and it can be configured with:-
sudo dpkg-reconfigure postfix
Once that is done you can look forward to receiving mail whenever your system needs to be updated
with details of the updates required.
Go from blank disk to fully installed in under an hour
On most moderate hardware these days a standard installation of Ubuntu takes around half an hour.
Getting all the apps you need for daily use might take a little longer. However if you take note
of what apps you use regularly the additional applications can be installed pretty quickly, and
in one big hit.
Whenever I’m installing Ubuntu 9.10 whether for myself or friends, there’s a set of
things I tend to do post-install that rarely changes from one machine to another. This usually
consists of installing audio/video codecs, fonts, updated video driver, flash, java and a few
other bits and pieces. Some of that comes from the standard Ubuntu repositories, and some from
3rd party repositories or PPAs. Once the installation of Ubuntu is complete and all updates have
been installed there’s just a few lines to paste in and then I leave it to run for a while.
# Add repo for Lifesaver screensaver
sudo add-apt-repository ppa:cmsj/lifesaver
# Add repo for chromium daily build
sudo add-apt-repository ppa:chromium-daily/ppa
# Update local package lists
sudo apt-get update
# Install all the stuff!
sudo apt-get install ubuntu-restricted-extras # Installs flash, codecs, java, fonts
chromium-browser # Installs daily build of Chromium
lifesaver # Install lifesaver screensaver
gtk-recordmydesktop # Install app for recording screencasts
gnome-do # Install Gnome-Do
vlc # Install VLC media player
openssh-server # Install SSH server for remote access
smbfs # Install samba client for accessing Windows shares
gwibber # Install microblogging client
Building a list like this can significantly reduce the amount of time taken to get up and running
with Ubuntu. What’s especially cool about this is there is no need to visit any third party
websites or download external installers. Those applications listed above are the ones I use
regularly, you will have your own set of “must have” packages. What are they?
Move a hard disk
Ubuntu has no direct equivalent to “Windows Genuine Advantage” fortunately. This is
the tool that seeks to reinforce the Microsoft End User License Agreement for Windows users by
causing havoc when system hardware changes. Windows also has quite a fit when you move a hard
disk from one system to another as it detects and installs new drivers for all the newly found
devices.
Ubuntu does most of its hardware detection automatically at each and every boot-up with no user
interaction. As a result you can take a hard disk containing a standard install of Ubuntu from
one system and put it in another and expect it to work without much effort. The only time I have
had an issue is when I have made some manual configuration changes for the specific hardware in
the computer.
For example if you have installed and enabled the nVidia binary driver and configured it in
/etc/X11/xorg.conf and the target computer doesn’t have an nVidia graphics card then it
might fail to start the graphical environment due to it being forced to load the
‘wrong’ driver. In this instance probably the easiest thing to do is backup and
remove the /etc/X11/xorg.conf and restart the machine. At that point it will automatically detect
the video hardware and should work much the same as a standard install.
Compiling and packaging applications for older OS releases
With the 6-month release cycle some people can feel left behind if they don’t upgrade to
the next release promptly. Ubuntu has a Long Term
Support (LTS) release every two years to cater for many users who wish to stay with one
stable release. Ubuntu 6.06, 8.04 and the upcoming 10.04 are all LTS releases, with all other
releases being non-LTS.
There will always be some users who are not on an LTS release, but have still chosen to stick
with their currently working system rather than upgrade. There is nothing wrong with this
approach, but it can lead to users wanting a newer version of a package to be
‘backported’ to their release of Ubuntu, whilst the rest of the development community
have moved on. There are developers who backport applications from newer releases to older ones,
but they don’t backport everything, and there is a finite resource of developers available
to do this task. The good news is that with a little time and effort, you can do this yourself.
I recently had a friend who was using Ubuntu 9.04 with an nVidia graphics card using the driver
supplied, but he wanted to try the newer driver from Ubuntu 9.10. It’s generally not
recommended to take a package built for one version of Ubuntu and just install it on an older
release. It may work, but there’s no guarantee, and it can break the system in
unpredictable and catastrophic ways.
So I took the ’source’ code from Ubuntu 9.10 and used the tools provided in Ubuntu to
rebuild the driver for 9.04. This was a trivial thing to do. The really cool thing is that
I’m running Ubuntu 9.10 64-bit and was able to build the driver for Ubuntu 9.04 64-bit on
my local PC. Once I was confident that it worked I uploaded it to my launchpad Personal Package
Archive (PPA) where it was built for Ubuntu 9.04 32-bit and 64-bit architectures.
So not only was I able to backport a driver to an older release, but I also built it for an
architecture that I don’t even run myself. The observant among you may have noticed that
the package I built is not open source – the nVidia driver is proprietary code. Yet I was
still able to take the packagable parts and in only a matter of minutes have it rebuilt for
another release.
All the commands I used (dch, debuild, pbuilder-dist, dput) are well documented tools for managing, building and
uploading Debian packages (.debs) and their contents, and of course, they’re all freely
available in the Ubuntu repositories. The Ubuntu Masters of The Universe (MOTU) are a helpful bunch
and their pages can be found at https://wiki.ubuntu.com/MOTU and on irc in #ubuntu-motu.
Fixing a bug
Whilst it’s easy to dismiss this as an advantage only if you’re a coder, let me first
say that I’m not a developer at all. I can just about read someone elses
very simple code with some help and google, but I don’t really ever write anything myself.
So if I can fix a bug, anyone can!
I recently discovered a very simple bug in the ifdata command which I filed in launchpad –
the Ubuntu bug tracker . With a little help from
some of the Ubuntu developers – who were keen to help me – I was able to create a
patch, test it and submit it to Ubuntu and upstream to Debian. The critical step that really made
me consider even trying to look at this bug was that the source was available and easily
installable. I was able to identify the package containing the buggy command:-
$ dpkg -S `which ifdata`
moreutils: /usr/bin/ifdata
Once I knew the package name I could download and unpack the source code for that package very
easily with one simple command:-
$ apt-get source moreutils
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'moreutils' packaging is maintained in the 'Git' version control system at:
git://git.kitenet.net/moreutils
Need to get 37.8kB of source archives.
Get: 1 http://gb.archive.ubuntu.com karmic/universe moreutils 0.35 (dsc) [822B]
Get: 2 http://gb.archive.ubuntu.com karmic/universe moreutils 0.35 (tar) [37.0kB]
Fetched 37.8kB in 0s (191kB/s)
gpgv: Signature made Tue 05 May 2009 20:19:33 BST using DSA key ID 788A3F4C
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./moreutils_0.35.dsc
dpkg-source: info: extracting moreutils in moreutils-0.35
dpkg-source: info: unpacking moreutils_0.35.tar.gz
The tricky part for me is then actually finding the incorrect code in the program. With a lot of
help from a good friend and after asking on-line I was able to create a patch. I tested my
patch and submitted it to the developers for review. That process is all well documented and I
was supported through the process by Ubuntu developers.
All in all it took me a few hours to get this done, spread over a week or so. Not a massive
investment of time, and I’ll certainly be quicker next time, now I have learned how to
handle bugs like this. Plus I now have a better understanding of the packaging system which helps
me with other great things.
Re-install the OS and Applications without losing your data
A default installation of Ubuntu wil place all the operating system files and user data in one
partition on the disk called the ‘root partition’ or /, and a second partition for
swap. Many users like separating their OS/apps from their user data, so they create a separate
partition for /home. This is useful for a number of reasons including allowing you to reinstall
the OS on the root partition without touching your data in the /home partition. One little-known
feature of the installer on the Live Ubuntu CD is that you can do this – reinstall the OS
and not wipe your data – even if you dont have separate partitions for / and /home.
Ok, so you want to reinstall the OS but keep your data in /home. Perhaps you want to upgrade but
prefer a clean install, or maybe you’ve played with the system a bit too much and
it’s become damaged, and you’d like to quickly ‘reset’ everything with a
reinstall. Simply boot from the Live CD and run the installer. When you get to the partitioning
step, choose ‘manual partitioning’ which takes you to the more advanced partitioning
tool. Select your root partition for installation but don’t tick the “format”
checkbox. Continue with the installer as normal.
The installer will recursively delete all files (except those in /home) before copying the new
install files onto the disk. Create the same first username during the installer and it will
re-use the /home/username folder as your home directory, with all your files intact.
Note: Some user data files (such as mysql databases which are in /var) may be stored in other
folders than /home, so you will probably want to back the system up before hand in case there are
any files you need to recover.
So those are 10 things I do with Ubuntu that I’d have a hard time doing
on Windows. It’s arguable whether you’d need to be able to do some of this stuff, and
that I accept.
I realise that there are Windows-based tools that can replicate/emulate some of these tasks, or
maybe Windows Vista or 7 can do some of the above tasks. I kinda stopped bothering with Windows
after XP, so my knowledge may be lacking. Feel free to correct me in the comments, or suggest
what you can’t live without.