Each release of Ubuntu just gets more and more, well, grown-up.  When I started using Ubuntu on the desktop, it was a brave man who would upgrade when a new release became available rather than install from scratch (and keep your fingers crossed with drivers.)  But things have improved significantly - even on hardware which is new and typically less well supported (see my Eee PC 701 setup guide later in this article.)

Things I like about Intrepid over previous versions:

1. Network Manager just seems to work.  The OpenVPN support just works.  It all just feels less flaky.  And when I plug my mobile phone in, it took about 10 seconds to setup a 3G connection through it.  All very plug-and-play.
2. Fonts: System > Preferences > Appearance > Fonts > Subpixel smoothing (LCDs) looks nicer than ever before.
3. The combination of Nautilus’s Tree organiser and it’s new Compact View really makes this a usable file manager.  At last.
4. Dual screen support seems much improved.  Two machines which I had trouble with in the past (one with an NVidea card) now work with a second monitor without having to wrestle with the xorg.conf.  What I’ll do with those cold winter evenings now, I don’t know.

One of my laptops is an Asus Eee PC 701.  Under Gutsy and Hardy, a number of tweaks were essential to get basic functions to work (wireless and sound in particular).  With the impending release of Intrepid, things go much more smoothly, and while a few tweaks are necessary, it’s almost plain-sailing.

Here are the steps I have taken to install Intrepid on my Eee PC 701:

1. Download the ISO and install from USB (using the ub8convert2.exe tool)
2. Get wireless working. Go to System > Administration > Hardware Drivers and deactivate the Atheros driver and reboot.  UPDATE! If that doesn’t work, it’s because the ath5k driver has been removed from Intrepid (on 28 October) - by the time you read this, it may be back.  If not, visit this bug report and you have the steps necessary to get back online.
3. Get up-to-date (especially as this is a beta currently.)  Keep an eye out for the update-manager icon in the top right of your panel and take suggested upgrades.  It may well suggest a “Partial Distribution Upgrade” as this is a pre-release version. Do it.
4. Shutdown doesn’t power-off.  To fix, add the following line to the end of the /etc/default/halt script:

rmmod snd-hda-intel

5. Sound doesn’t work out of the box.  To fix, create a new file (or append to the existing file) /etc/modprobe.d/snd-hda-intel:

options snd_hda_intel power_save=10 power_save_controller=Y

6. Turn on the microphone. Right click the volume icon (top-right) and choose Open Volume Control.  Then raise the e-mic control to the top.
7. Use the Riceeey script to achieve the following. You’ll need to edit the script down to size just to achieve this.  I haven’t tested whether the “overclocking” (which is really a “don’t underclock”) feature works.
   • allow windows to be moved above the top of the screen (by holding Alt while dragging)
   • set toolbar style to just show icons and set fonts to size 8 (to give you more space)
   • set Alt-F11 as the key for running apps full-screen
8. Get the hotkeys working:
   

wget http://www.informatik.uni-bremen.de/~elmurato/901/Ubuntu_ACPI_scripts-EeePC_901_1000.tar.gz
or
http://www.informatik.uni-bremen.de/~elmurato/EeePC/Ubuntu_ACPI_scripts-EeePC_900A_901_1000.tar.gz
tar -xfvz Ubuntu_ACPI_scripts-EeePC_901_1000.tar.gz
cd Ubuntu_ACPI_scripts-EeePC_901_1000/
chmod +x install.sh
sudo ./install.sh

Good luck - do tell me how you get on.  Thanks to devgru and Psychocats.

Subversion is different. It takes a different approach to any other source code control system I know. It uses lightweight ‘copy’ operations to achieve tagging and branching. It’s intuitive. If you didn’t have source code control and you had a code base that you wanted to keep as “version 1″, you’d most likely take a copy of the directory and call the new directory “version 1″. Well that’s tagging in svn.

But, like I say, this is all well-documented.

Bugzilla is a bug-tracking system. I hate the word “bug-tracking”. (I’m not very fond of the word “bug” at all!) But it’s a misnomer to label it a bug-tracking system because it tracks any sort task - typically a programming task. Frequently, it tracks the tasks involved in developing new products and new features. Not just bug-fixes. So I prefer task-tracker.

Bugzilla is a perl-based open-source task-tracker. It’s been around for years and with each release (especially the recent 3.x stream, which introduces custom fields, at last) it gets better and better, It’s basic. It lets you record a bunch of information relating to a task. A summary. The priority of the task. Who is interested in getting updates. The status.

10 years ago, when working at Thomson Datastream, we used Paradox to keep track of our tasks. It was implemented as a form-based database. Bugzilla is no different. Each task has an ID and associated with that ID are the fields.

It has some nifty additional features to facilitate workflow. When a “bug” is updated (don’t get me started on how wrong the grammar and accuracy of that phrase is), interested parties are emailed to be told what’s changed. It has a flexible reporting system. It has some basic project management facilities, such as task estimate and time tracking. But it’s still essentially just a bunch of fields in a database.

I often hear people confusing source code control with task-tracking. They are very different. One is concerned with the lines of code being written and managing the history of changes. The other is concerned (typically) with recording and managing the programming tasks.

And in any semi-mature development environment, both are needed. Especially where a team is working together. But even as a one-man team, I’d recommend the use of both.

That doesn’t sound too controversial, but it is. And here’s why. When a developer checks some code into svn, that change is given a unique “revision number”. The coder can provide a description of their change when they commit. And svn supports “hook scripts” which easily allow it to be configured to send emails when code is committed (or tags created or branches merged, etc.) And so the argument often goes: why bother with a task-tracking system too, when I’m getting most of the functionality with just Subversion?

The problem is this. Programmers are concerned with the nuts and bolts of development. Their change descriptions are likely to read, “Change the user array to be an array of objects instead of id’s”, or “Add new sort function”, or “Implement new View module for the admin n Controller”. But a project/product/commercial manager - or, perhaps much more prescient, a customer or prospect - is likely to think in terms of high level features or changes: “Improve performance of adding a new user to the system”; “Tracks should be sorted by ignoring the word ‘the’”; “New blue-themed look Admin screens”.

It’s not just the descriptions - that would be easily resolved. But more difficult to overcome is the granularity. A single feature (e.g. “Allow a user’s account to be disabled”) might involve multiple code commits. Perhaps by a number of different developers or designers. So now your developer has a number of lower-level changes and descriptions which are all part of a single piece of work as far as management or customers are concerned. And while one of those more granular changes may be concerned complete by a single programmer, the project manager knows that it’s not until all the associated pieces of work are complete that the task is really complete,

So it’s become an issue of communicating the right information to the right audience. And I don’t think you can ignore either your developers nor your managers and customers.

You need both source code control and you need effective task-tracking.

This has been the case for as long as I can remember (from those heady days of Paradox and Digital CMS, through proprietary databases and CVS, to Bugzilla and svn.) But despite there clearly being a role for both systems, and despite the prevalence of such systems, integration of the two is another matter. Getting Bugzilla to talk to svn and vice versa is not trivial. And there is certainly no inherent capability in either product.

There are “workaround” solutions to this - for example, getting developers to commit code changes for a single task in one single commit operation. Or get developers to keep track of the revision numbers associated with their issues. But these are largely impractical (or force a suboptimum development process on the team) or are labour intensive and subject to human error.

There are tools which can facilitate these tasks - such as trac (of which I have almost no experience but hear many good things - but am not convinced it meets all of the requirements.) I’d welcome more feedback on trac and tools which might help tackle the problems I’ve outlined above.

But ultimately I think to solve the twin needs of task tracking with Bugzilla and source code control with svn, it is necessary to choose between implementing some glue between the two or accepting some increase overhead (and risk) in manually running both in parallel.

# download the Google calendar ical file through the private URL
wget -c -N http://www.google.com/calendar/ical/yourname%40gmail.com/public/basic.ics

# copy it to the iPod
cp basic.ics /media/your-ipod-name/Calendars/google.ics
rm basic.ics

Now configure Ubuntu so that this script is run whenever you plug your iPod in. Add the following line to /etc/udev/rules.d/80-programs.rules:

KERNEL=="sdc1", RUN+="/path/to/your/script.sh"

(Replace sdc1 with the appropriate device name, which you can find out by typing “df”.)