How to beta-test your Linux distribution

Many GNU/Linux users keep old computers around for testing purposes. Many of these same users like to change from one distribution to another once in a while (Fedora was quite popular for a while, then it was Ubuntu, and so on...)

So many of these people test final versions of their candidate distribution on their old machine. If it impresses them there, they'll try installing it on their production machine. But here they can run into problems, because the hardware might not be supported out of the box, making time-consuming tweaking necessary.

The solution:

1. Decide that you are going to give a certain team of developers a chance of making the distribution work for you (be they Ubuntu or Fedora or whoever).
2. In the run-up to the next release, try their public betas on your new computer, doing your normal work. Save often and keep backing up to another machine. (It's a good habit to get into anyway...)
   
3. If bugs occur, report them, and follow up whether they are being resolved. Give all the relevant information that developers will need to find and fix the problem, i.e. describe the bug as accurately as possible. If possible, help with debugging!
4. Meanwhile, keep your old machine productive so you don't endanger your work, your job etc. You can only devote so much time...
5. Keep testing until the final release (i.e. install and test every new beta as soon as it is released) and beyond - some things may still need fixing in the first few weeks after release. It often happens.
6. Enjoy a Linux distribution that you know will work on your new production machine!

It is likely you will only have to do this once, and that even subsequent releases of the same distribution will just keep working (the only exception will be a new kernel series, but it'll probably be about 2 years before we have to even think about that again).

Mac OS X 10.4 Tiger

These are some thoughts I had back in December, following the Apple conference where Tiger was introduced. I'm opining on the main features of Tiger, which are:

Automator seems to be some intermediate between an AppleScript front-end and an IDE. AppleScript, incidentally, is also being described as being new, although I seem to recall it being in Mac OS. Dashboard is the idea of a virtual desktop with the generalisation removed. Do Apple users really need this level of guidance? You could have just given them a virtual desktop and shown them how you think it could be used.

Spotlight is a desktop search engine, apparently based on Lucene, from which dotLucene, the library driving the Linux Spotlight equivalent, Beagle, also springs. Spotlight is why you want Tiger.

I don't want to say much about RSS processing in Safari, other than that I'd be surprised if they had a better implementation of it than Thunderbird, and Thunderbird had it much earlier, as did Firefox - even before the conference!

Then there are CoreImage and CoreVideo, components that remarkably acelerate your graphics manipulations - it made quite an impression at the conference. I expect CoreAudio will be similarly effective. I hope I'll find time to look into how they are designed and work - what level of the OS they reside at etc.

So now you know what I was thinking back in December!

Laptop specifications (wishlist)

In order of importance:

1. Long battery life: in excess of 3hrs under load (if you need to give me an extra battery for this, fine, but why not make the first one last longer?)
2. Large, easy to view display aka screen, even in bright light (quite a few models now seem to have ~1400*900, good to see)
3. Decent keyboard
   
4. Quiet operation
5. Fast DVD/CD-ROM drive - so I can run LiveCDs at more appreciable speeds. Some laptops now ship with 40 times drives, and my current laptop has already got a 24 times one!
6. Fast hard drive so GNOME can load faster.
   
7. I used to think CPU speed was important. I'm beginning to accept the idea that I need a separate headless machine to run big simulations on. However, with Linux, processing power really matters at the moment, because you've got a lot of cool Python apps on that platform, but Python is very slow. I haven't tried Mono yet. Leaving aside the question of whether we should use Mono, it will be interesting to find out how fast it is. And of course - fast memory and front side bus. So I guess I'll have to watch the benchmarks in the magazines.
   
8. A high-quality microphone, or preferably just microphone and headphone jacks that don't suffer from interference (like my current one, sadly, does!).
   
9. Enough USB ports for my keyboard, mouse, printer and either a PDA or digital camera. How about another one for an external HDD? That makes five. Hmm, maybe forget about the printer, don't seem to use it much lately. So four USB ports.
   
10. Weight: not that important to me, but sure, I prefer them lighter if I can have them.
11. Graphics cards: leave me alone - I'm not a gamer! So long as any variant of X and window manager run on it without noticeable lag, I'm happy.
    

Technical specs:

• at least 512MB RAM, I guess extensible until 1.5GB would be nice
• no inbuilt speakers (headphones are the way to keeping friendships at the office), no wireless (too insecure)
  
• 80GB+ hard disk
• Dual-layer DVD writer, hmm... is 8-speed asking too much?
  

Filenames

The problem with files is that they need to have a different name, depending on context. Let's suppose I've written a travel diary about Belize. On my computer, this could be called "Belize2005_v5". On my girlfriend's computer, "PhilBelize2005Diary"; when I upload it to a travel website dedicated to Belize, it needs to be called "Belmopan PhilippWesche May2005 english" etc. (Belmopan is a place name in Belize.)

Files need to know which filename is most informative in a given context. This is addressed to some extent by meta-tags in some filetypes such as mp3 and pdf. However, I am not currently aware of any OS or desktop environment that filters out only the most informative information, e.g. test whether the file is residing in the filespace of the creator; if not, include the name of the creator in the label. I'm sure one could think of many more simple rules that would be enormously helpful, and in combination could revolutionise the way we interact with files.

Edit 24/07/05: This is of course where Unix was going all along, with the idea of uid and gid for files!