SteveStreeting.com

Git is picky when it comes to converting large, moderately complex Subversion repositories and so far the only option I’ve found that works reliably is using the very latest version on Linux. Forget about using 1.6.5 on Windows via msysGit, at least for the git-svn conversion it’s very, very unreliable. Similarly I found Git 1.5 on Linux very flaky for the svn conversion. This doesn’t give me the greatest confidence in Git but in order to properly explore all the angles, I’ve committed to making it work even if it means I have to monkey about a bit.

So, I installed a fresh Kubuntu 9.04 (and of course, 9.10 went stable a few days later) and tried to build Git 1.6.5 from source. The configure script is unfortunately a bit rubbish and doesn’t bother trying to detect the dependencies though, so for those that don’t want to go through the fail/retry build loop I went through, here are the packages you’ll want to install via apt from a clean version:

• build-essential
• curl
• libcurl3
• tk
• subversion
• libsvn-perl
• cpio
• zlib
• zlibg1-dev
• expat
• perl
• iconv

If like me you use the excellent wajig wrapper around apt, you can also do ‘wajig build-depend git-svn’, but that seems to install things that are not strictly necessary in the default build (but maybe are needed with some non-standard options).

sudo apt-get install curl
   41  sudo apt-get install libcurl
   49  sudo apt-get install tk8.4
   53  sudo apt-get install cpio expat
   55  sudo apt-get install zlib
   61  sudo apt-get install build-essential
   66  sudo apt-get install zlib1g-dev
   72  sudo apt-get install asciidoc
   75  sudo apt-get install xmlto

Ok, so I discovered a number of shortcomings in my recent attempt to sync a folder in one direction to Amazon S3 using encryption, the most important of which was that it wouldn’t resume a failed transfer efficiently, which in the case of large transfers wasn’t at all ideal (as I learned to be own cost – damn my 256k upload speed).

So, this is attempt number 2. I decided to completely rewrite the script in Python instead to give me some more flexibility, coupled with the availability of Boto, a nice Python library for accessing all the Amazon Web Services. Rather than rely on just local information, or even date/time stamps, I decided to use hashes to track whether files were different. Amazon already stores the MD5 of the file you upload to them and makes that available without downloading the file, but that’s no use when you encrypt your files before uploading them, because the MD5 is of the encrypted contents rather then the original; so unless you keep the encrypted copies around too, or encrypt the local files again every time just to check the match (expensive if you’re dealing with large files) you won’t be able to compare them – I think this is the reason why ‘s3cmd sync’ currently doesn’t support encryption.

So, I decided to use S3′s ability to store custom metadata in keys, and stored the MD5 hash of the original file against the encrypted contents that I uploaded. That way, I can check the hashes against each other pretty quickly without having to re-encrypt the local files. If the hashes are different, I encrypt and upload. This approach trades a bit of preprocessing against avoiding uploads, so it’s likely to be more efficient on small groups of very large files rather than lots of small files – that’s how I use S3 for my backups of course. It also means I don’t have to worry about timestamp variations, it’s the content of the file that is the driver of whether it’s uploaded or not.

So, here’s the new version. It’s a bit more powerful than the last one – I’m calling gpg myself now so you have the choice between encrypting using public keys (more secure, and the default), or using symmetric encryption with a passphrase. You need to install Boto before you can run it, and it depends on Python 2.5 with hashlib installed. I’ve run it on both Linux and the Mac, it should work on Windows too provided you take the trouble to set up Python and GnuPG, but I haven’t tried; my Linux (apt) and OS X (macports) setups make these things quicker so being short of time I just went with that. Here’s the usage from –help:

Usage: s3putsecurefolder.py [options] source_folder target_bucket gpg_recipient_or_phrase

Options:
  -h, --help            show this help message and exit
  -n, --dry-run         Do not upload any files, just list actions
  -a ACCESS_KEY, --accesskey=ACCESS_KEY
                        AWS access key to use instead of relying on
                        environment variable AWS_ACCESS_KEY
  -s SECRET_KEY, --secretkey=SECRET_KEY
                        AWS secret key to use instead of relying on
                        environment variable AWS_ACCESS_KEY
  -c, --create          Create bucket if it does not already exist
  -v, --verbose         Verbose output
  -S, --symmetric       Instead of encrypting with a public key, encrypts
                        files using a symmetric cypher and the passphrase
                        given on the command-line.

Once again, no warranty is given, MIT license. If you see that I’ve done anything dumb, let me know

Edit: this script is deprecated in favour of a rewritten version 2.

I use Amazon S3 to host large media files which I want cheap scalable bandwidth on, and for expandable offsite storage of important backups. I used to have some simple incremental tar scripts to do my offsite backups, but since I moved to Bacula, I’ve just established an alternative schedule and file set definition for my offsite backups, the critical subset of data I couldn’t possibly stand to lose (like company documents). Since I was refreshing all my procedures and tarring the Bacula volumes no longer made any sense, I rewrote my script for putting the resulting backup data on S3.

The prerequisite in all cases is s3cmd, which is pretty mature now and available on most distros (“apt-get install s3cmd” and you’re done on Ubuntu). s3cmd actually has a ‘sync’ command, but firstly that tries to sync in both directions, which I don’t want (I know in theory it should never overwrite any local version so long as I don’t update the remote copies from somewhere else, but I’m paranoid when it comes to my backups and prefer to be explicit), and secondly it obviously has to connect to S3 to determine the sync status, wheras I always know whether I need to upload new files just from my local environment (and S3 charges per request – not much, but it’s not zero and it’s the principle of the thing). So, I decided not to use the ‘sync’ command, and just determine locally what new files I needed to ‘put’ on the server.

Secondly, encryption is a must, since some of the data is sensitive and I don’t want to trust anyone else with it. I used to manually GPG my tarballs before uploading them, but I noticed that s3cmd supports an encryption option too. It just uses GPG anyway, just in symmetric form rather than asymmetric like my version did (translation: you use the same passphrase for encryption and decryption; a little less secure than using generated public/private keys but still ok so long as you pick a good passphrase and look after it). The default symmetric algorithm in gpg is CAST5 which seems pretty good, although you can change it if you want by editing your s3cmd config file. So, I decided to give it a try – after you configure s3cmd to use encryption, it actually automatically decrypts too when you pull the data back (symmetric key, remember) – being distrustful, I pulled the data back from S3 in a different environment and examined it, and it was indeed complete gibberish, but decipherable with the passphrase. Good stuff.

So, here’s my little script which will upload the encrypted contents of a folder to S3 – just the contents that have been added or updated since the last sync of that folder, and will encrypt them by default. I just run this on a cron schedule now and it seems to work fine. License is MIT, use at your own risk, no warranty is given that it won’t destroy every file on your machine or eat your children. Usage is like this:

s3putsecurefolder /my/source/folder my.s3.bucket

Edit: it was brought to my attention that Amazon have made it easier to create pseudo-folder structures in S3 buckets since I last tried to do it (I swear it used to throw out keys with forward slashes in them, I had to mangle my names last time I did this), so I’ve updated the script to allow nested folders too.

As I’ve talked about recently, as a background task, I’m setting up a new Ubuntu server to take over the main file server, mail server, build server, backup server, web server, and you-name-it-server duties of my home office. It will eventually be taking over from a venerable Debian server, which was built on some old hardware left over from retired machines (except with 2 new mirrored hard drives) and has basically sat in a corner being rock-solid for years without me touching it, at least until the PSU failed (and was rapidly replaced), reminding me that I’ve been meaning to upgrade it for over a year. This machine does more things than I care to remember half the time, so without a huge amount of time to spare it’s taking me a while to bring its younger, upgraded, more power-efficient replacement fully online.

One of the things I wanted to move away from was my manually scripted backups. Under Linux backups are a generally simpler affair than on Windows; just tar & compress the file system, skipping a few folders like /proc and /tmp and you’re pretty much done, so I wrote a few simple scripts and left it at that, which has worked ok for a while, but as I started to want more complex backup strategies (different subsets sent to S3, etc), manually scripting everything was becoming tedious. I’d tried setting up Amanda before but found it a little overcomplicated for my needs (and reverted to scripts), so I decided to try Bacula this time.

In all it probably took me 3 evenings to get it set up the way I wanted, of which 2 were spent reading the Bacula manual and experimenting, and 1 was solely spent trying to get around an issue with mounting a remote drive on demand. I don’t use tape drives, because I think they’re overpriced and an unnecessary hassle for a small office setup; instead I send all my backups directly to a separate (RAIDed) NAS box, and replicate them to another machine for added resilience. I also upload a critical subset (encrypted) to Amazon S3 for emergency off-site recovery purposes; a removable external HD would be another option, but a) I’d have to keep taking it off-site all the time, and b) you’d really need 2 copies, because removable HDs are just not resilient enough unless they’re at least RAID1).

The problem I had was getting the NAS box mounted on-demand for the backups; I do it over CIFS (Samba) – I could use NFS (since the NAS runs embedded Linux and has NFS support) but the nice thing about using CIFS is that I know I can redirect it to any machine in the office at any time if I need to, since everything supports it (including OS X and Windows), and I won’t start hitting new issues because of a protocol switch. Since we can’t rely on the NAS being mounted all the time (it may be taken offline from time to time), Bacula needs to mount it & unmount it on demand – this is what my manual scripts used to do. Bacula seemed to support this via the “Requires Mount=yes” option on the storage device, and being able to define mount and unmount commands, but I could never get this to work, despite trying for most of an evening (it would just complain about the device not being mounted, and seemingly not try to run the specified mount commands). In the end, I used a much better overall approach anyway, by using autofs to auto-mount the NAS box when a specific path is accessed, and unmount it after a period of no use. That solved the problem in Bacula (I could just point it at a path and let autofs handle the rest), and also meant it’s much easier to browse the NAS from this machine generally.

So, now I have it set up, I’m really quite pleased with it. It supports on the fly compression but does it per file (unlike how you would do it with tar, which is on the whole archive) which makes it a little more reassuring that you wouldn’t lose as much in the case of a limited data corruption. The backup schedules and volume recycling configuration are really very powerful, and they have features in there which make doing backups to disk systems rather than tapes very convenient. The visibility is generally a lot better than my manual scripts, restoring is easier, it’s easier to keep on top of the space used with the recycling, and it’s far easier to manage a ‘deeper’ full/incremental policy without making your restore process harder. Plus, I have a queryable log of everything (rather than just cron logs and notification emails) which feeds metadata into the restore process as you’d expect. Good stuff – all the kinds of features you’d expect from a commercial backup solution.

Since I don’t install X on my servers, I had to configure everything with a text editor rather than the GUI Qt tool (‘bat’), but really it wasn’t a big deal. Once you understood the concepts, the text configuration was really quite straightforward (and well commented), as most good Linux server apps are.  Of course, I can run the GUI on my Windows or Mac desktops too, and configure the scheduler remotely from there. I haven’t tried that yet.

So far, Bacula seems like a great solution for small office backups.

I’m busy, again. A ton of things just bunched up towards the end of the month, and I’m on-site with a customer in Cambridge some of next week, so I’m keeping my head down a little right now. Here’s a news-blast though.

I love Ubuntu server

I’ve been setting up my new server. I’ve probably said this before, but for servers, Linux rocks. I’m ambivalent about Linux on the desktop, where I believe consistency and usability are more important (the Mac floats my boat the most there, and Windows if only because of MSVC++), but for a server Linux really brings great things to the table. Rock solid server apps, ridiculously good performance for the hardware (a mere Intel Atom 330, goes like a greased whippet), easy and most importantly infrequent maintenance. When it comes to distros, I loved Debian for its sensible defaults and great package management, but Ubuntu server takes that and makes it even better.  The added bonus of a LTS version that I know will be supported with security updates until at least 2013 is welcome too, because I like to set these things up and mostly forget about them.

I’m glad Ubuntu’s default mail/IMAP servers are Postfix and Dovecot respectively – they’re just ridiculously easy to set up. I’d been using Exim4 on my Debian box, which was the default at the time, and learned to dislike it because of the over-complex configuration (I’d been used to Postfix when I ran a Gentoo server before that). I’m also planning on trying out Bacula as a replacement for my manual backup scripts this time around.

PSUs hate me

One of my jobs this week was building a machine around some customer hardware which I was testing an abberation on. Having built it, I realised I didn’t have a spare PSU rated highly enough, so I ‘borrowed’ one out of another GPU test machine I had. It ran all day, then decided to die – this just 2 weeks since my server’s PSU died and needed to be replaced. It’s just bad luck – my decent APC UPS should be providing ample power regulation. So, I’ve ordered 2 new PSUs to make sure I have enough stocked in future!

Excitement is infectious

I was happy to show off some shots of my new & improved core terrain system for Ogre, which isn’t entirely done yet but was usable enough to get some nice shots out of. I knew I had to move on to some other work for a while but I was still pleased to be able to show off some initial eye candy (which BTW, is still very early – I haven’t finished yet by any means). I was glad to get some positive & constructive feedback, but of course now people are rushing off an including it in their projects, since all the code is public in svn. Despite my slapping a big red warning sticker on it saying ‘handle with care – volatile material’  and that they shouldn’t assume it works properly yet, people are hacking on it already, with some nice results I have to say (such as Ogitor integration) – but of course with many questions and issues. Such is the nature of open source – it’s a blessing that you get instant, voluminous feedback, and it’s a curse that you get instant, voluminous feedback I hope to get more time to deal with the fallout from that if not next week (because of my travels), then the week after.

The OGRE Patch Mountain

Our community is always active, and it’s great to get patches. I do have a quite high validation standard for the core though, and processing patches can often take a fair bit of time. I try to spend a few hours per week doing this, but mostly that’s only just enough to keep the level static, rather than reducing the backlog, and it still spikes up sometimes (as it has this week) – that’s because even if I get an afternoon on it, to review and test things properly can eat that up very fast.

If there are any experienced members of the Ogre community who would like to assist me with keeping the patch mountain down to a small hillock in future, and are willing to adhere to our high standards of review, please contact me at sinbad AT ogre3d DOT org.

iPhone 3G / 3GS port coming soon

We’ve had a fledgeling GLES rendersystem around for a while, and obviously the iPhone / iPod touch are the highest-profile targets of that. I’d been intending to have a go at it later in the summer, but masterfalcon on the forums has beaten me to it and already has it running (with a few small issues remaining to be ironed out) on the 3G and 3GS. There should be a public release of that in the relatively near future.

3D Web Browsing With OGRE

I love this video. Nice work princeofcode (aka ajs15822)

That’ll do for now I think.

I just  assembled a new server machine, which in the end I chose to house in a shiny aluminium Thermaltake Lanbox, which is relatively compact but still roomy enough for two hard drives, a bog-standard power supply, and plenty of airflow, which is what I wanted. I also knew that the fans on this case were nice and quiet (I have a black steel version as a GPU test box, I wanted a lighter version this time!), which is important for a machine that will be on all the time.

As I said in my previous posts, I was determined not to put an optical drive in this machine. It really doesn’t need one, since all the system software will be downloaded anyway – the only possible use for an optical drive would be to boot the machine in the first instance, and that seemed a total waste. I know DVD drives are cheap, but why clutter up the box with one just for the rare occasion when I need to manually boot? The same goes for floppy drives, which are such dinosaurs I can’t believe some new machines still come with one present – the only possible use for a floppy drive these days is to provide a slot that you don’t mind a toddler feeding jam sandwiches into.

No, instead I wanted to boot from a USB flash drive. I’d never done this before, so I scouted around for the best ways to do it. Syslinux came up pretty quickly as the primary contender, but being lazy I hunted around a bit longer to see if anyone had a simpler way than configuring Syslinux manually. That’s when I came across UNetbootin.

What a fantastic little project! It took literally 5 minutes from downloading, to creating a bootable USB disk with the distribution of my choice on it (UNetbootin will download your chosen distribution automatically – or you can supply an ISO of your choice if you want), to booting up the new machine. I couldn’t believe just how simple it was! I chose to put Ubuntu 8.04 Netinstall on the disk, which clocks in at a tiny 9Mb because it’s just enough to boot up the installer to start downloading the real packages direct, but if you want, and you have a big enough USB stick, you can a complete distro on there too. But this way, I can use a crappy old USB stick I have lying around as my boot device.

A great little tool anyway. I love it when things are easier than you expect.

Not being the kind of person who would buy a netbook, I hadn’t really paid much attention to Moblin, Intel & Novell’s new netbook-targetted, Linux based operating system. However, Matt Asay posted about it today and that got me looking at it, and I have to say I’m very impressed.

I love that they’ve tried to rethink the operating system interface from the ground up rather than just follow in the footsteps of previous efforts. One of the reasons desktop Linux distros have never made much of an impression on me is that I often just feel like I’m using a slightly more technically-oriented facsimile of Windows, which is ok but tends to be more demanding of my time; in comparison the Mac gives me a usability boost and saves me time over using Windows, as well as having a solid back-end, and that’s why I like it. People need a reason to use alternatives to Windows, and just reproducing the user experience isn’t enough. I had assumed that Moblin would be another ‘typical’ desktop Linux in the usual vein, but they’ve done something much more interesting; a completely new interface designed around common usage patterns.

I’m not sure how it would be to use (I’d need to actually play with one, and I don’t intend to buy a netbook any time soon), but it certainly looks good, and I completely applaud their initiative. It’s about time more people experimented with usability like this rather than unquestioningly sticking to boring old operating system interface ‘standards’.

A small bit of musing while I wait for another back-up to run…

Reinstalling a server from scratch sucks. Obviously. Not being able to use direct dumps of the old system itself because of concerns of how far a malicious attack got, and how long ago (even though we’re running SELinux) means that everything has to be constructed afresh. How much fun I’m having.

But if there’s one silver lining here, it’s that at least Linux stores every shred of its configuration in a simple, plain text format, and in one dedicated subtree of the file-system. Even though the server itself had to be taken down, the old disk was mounted so that I could look at previous configuration files easily, and carry across relevant ones (checked manually, natch) directly. It still takes a lot if time, and the fact that I jumped OS versions at the same time has complicated it (but, if there’s any time to do that, it’s now), but it would have been much worse if I couldn’t reference the old system.

One thing I found annoying at times about doing admin on Windows servers (in a past life) was that they generally hid their settings away from you – the common assumption was that you use a GUI to edit everything, and accessing settings without that GUI was frequently difficult, if it was even possible at all. Although a GUI is friendly for many uses, it also does a pretty good job of hiding things from you. Sometimes that’s useful (drawing attention to the most important things), sometimes it’s very unhelpful (trying to find which tab / dialog a particular option is in). One thing it definitely fails at is making it easy to extract / summarise all the necessary information to audit it, or to recreate an entire setup. Even when you have the server still running its a pain, but if that server has been taken offline it’s extremely hard to extract information from it without booting the thing up again (which if it’s damaged or compromised, might not be desirable or possible). Settings were often scattered among the registry, proprietary repositories, application specific places, and sometimes in custom data formats. If you’re lucky you might be able to extract the settings some way, but usually you have to have thought of it before the machine was out of action, and the process is often specific to a given application – so even assuming you remember to do it for all of the different server apps you’re running, the results are disparate, hard to organise and very often not human-readable – something you really want when you’re auditing a machine or creating a variant. The result was, in my experience, relying heavily on binary machine images for reference setups, test servers etc. That works well enough, but it’s a bit opaque and doesn’t help you much when you want variations (unless you have MxN images, or a tree of derivative images).

In comparison on Linux, I know I just have to look at plain text, readable configuration files in /etc/, which I can do on pretty much any device without actually having to have any of the old software running – I can just mount the disk with minimal permissions. By and large the text files are extremely well commented and contain pretty much every option you might need, just commented out when defaulted. I can search quickly for settings just like I can in any text file, and search across the entire configuration if necessary. Being text, it’s very easy to create a standardised configuration template that you can roll out, in a much more configurable way than a raw machine image. The visibility of all the settings certainly helps, and you can do all sorts of nice things such as generating configurations from variable options, should you want to. Text configuration might look less friendly at a surface level, but over time, I’ve found that in practice it’s actually a considerably more productive way of doing things for many admin tasks – especially the more difficult ones.

Tweaking an existing installation is still probably easier with a GUI though, and less intimidating to beginners or occasional admins (and I actually count myself in the latter). The best solution is to have both – a GUI for casual admins and core text config storage underneath – and of course there are plenty of options  about to do that on Linux too.

I’m not sure if Windows Server 7 does anything different here – I haven’t administered a Windows server since 2003 so I may well be out of date. I just thought I’d break out some love for the often unappreciated plain text config file. Sometimes simplicity is the best choice.

I’ve had an Ubuntu 7.1 ("Feisty Fawn" "Gutsy Gibbon" – doh) desktop install for a while for testing purposes, and as usual they moved to a new version within a few weeks of me getting it set up. I don’t have a lot of free time and I’m still not a convert to desktop Linux, so I wasn’t in a rush to upgrade to the spanking new Ubuntu 8.04 ("Hardy Heron"). I actually configured an Ubuntu 8.04 server machine recently for a client, but that was simple & easy as Debian-based, command-line only servers generally tend to be. However, someone raised an issue with the Ogre build with some of the memory allocator changes on 8.04, which only occurred with the updated version of gcc it comes with, so that forced my hand. This morning I had a spare couple of hours so I thought I’d give it a go.

Luckily, Ubuntu (like all Debian derivatives) comes with a semi-automated way to upgrade to a new major version so it wasn’t going to be a fresh install. Some people like to start from scratch, but I’m busy and besides, I deliberately wanted to do an upgrade rather than a clean install to see how well it worked, since I’ve never done it before. I figure this is what a ‘regular user’ would do, given that the automatic updates are constantly prodding you about upgrading, and I’m always interested in putting desktop Linux through it’s paces in the way I think an average non-technical user would, because I hold out hope that one day, it might not be such a pain in the ass and will become a more realistic option for the masses.

Firstly, I was very conscientious and uninstalled Envy, since it makes changes to your kernel and there are very strict warnings about removing it before doing a distribution upgrade. That gave me my first problem, in that after returning to the default setup my screen was horribly corrupted, as I’m woefully used to seeing with desktop Linux. A quick flip to a console, changing the resolution to a basic VESA mode and restarting gdm sorted that out at least. So then I was free to install the new version via the regular software update wizard. That went pretty smoothly, and after restart I had the new default ‘heron embossed’ backdrop, albeit still at my low resolution and software drivers. Rather than install the new version of Envy (NG) right away, I figured I’d give OOTB Ubuntu a chance and let it install the proprietary drivers itself.

That didn’t go so well. It installed the drivers, but on reboot I could only see the top-left quarter of what should have been the login screen, as if I had a virtual window. It was still running at the VESA resolution, so I figured maybe it’s just that it’s gotten confused about the hardware driver’s preferred resolution and the monitor resolution. So, after logging in I tried altering the resolution through the standard ‘Screen Resolution’ widget, which I could just about get to within my tiny ‘window’ on the desktop. That worked insofar as the resolution of the desktop changed, but bizarrely now, only the top-left of the monitor area was being rendered, the rest was either blank, or sometimes it would have the desktop background but nothing else (no windows, pointers etc) except in that top-left area. Even Compiz worked fine, but only in that area, I had to pan other areas into view to see them.

So, I tried installing EnvyNG instead. Same result. Suspecting some borked Xorg configuration setting, I initially tweaked the setting I’d changed to VESA manually back to the native resolution and restarted gdm, but that resulted in a hard crash on ALT-F7. Doing some reading indicated that 8.04 has changed the xorg.conf rather significantly, so I dropped back to a console, stopped gdm and use dpkg-reconfigure xserver-xorg to recreate my xorg.conf from scratch. Restarting gdm afterwards and switching to it with ALT-F7 just brought me a hard crash. Lovely.

Rebooting, I was presented with a complete login screen this time, albeit at default VESA resolution again. Logging in led to a completely white desktop though – I could spin it about as a cube with Compiz and I could see the Compiz logo on the top, but all the other sides of the cube were white. It was also slow as hell, indicating it was running on mesa, as expected, but I couldn’t explain why the desktops refused to render. Dropping back to a console again with CTRL-ALT-F1, I re-enabled EnvyNG and got it to reinstall the driver. Another reboot later and finally everything works again. I looked at my xorg.conf and indeed it’s completely different in structure to the one that had been in place after the upgrade.

The moral appears to be that if you’re upgrading 7.1 to 8.04, reconfiguring the xserver so that it rewrites the xorg.conf should be the first thing you do, before trying to install any custom drivers (via Envy or otherwise probably). For whatever reason the upgrade doesn’t seem to do that, and that caused me quite a bit of hassle. Seems that no matter what, Xorg is always a thorn in my side when I use desktop Linux. At least I can assume that a clean install of 8.04 wouldn’t have suffered from this (I think), but still, it still gives me little faith that a non-technical user can rely on Ubuntu long-term without technical backup to call on, since they would have been funnelled through the upgrade route and had the same problems I had; once again it’s ‘so near, but so far’.

Unfortunately resolving this burned up all my time, and I also have to rebuild a bunch of Ogre dependencies which seem to have gone missing. I’ll have to look into the new gcc issues another time.

Yesterday’s Ubuntu install didn’t exactly go entirely to plan, but today I spent a little time trying to resolve things. My overall approach to this is to try to use the most user-friendly tools available first before starting to hack on the command-line – as a fan of running Linux servers which don’t even have an X server running this might seem odd, but I really want to know how well Ubuntu does as a user-facing OS while I’m doing this. For a server I just want something that does its job well, is resource-friendly and fast to admin remotely, hence SSH-only admin access is a perfect fit for that purpose. Desktop OS’s need to be configurable via their GUI alone to pass muster.

I had located Envy yesterday, a third party application for automatically configuring NVIDIA and ATI drivers, so I downloaded it and tried it out. And what do you know, it worked flawlessly, downloading its own dependencies and the drivers, modifying the Xorg config without ever having to touch any files manually – a swift reboot and my HD 2600 was purring along in accelerated mode – no upgrade to 8.04 required as had been suggested. I examined what it did, and it really just performed the manual steps I’d seen documented elsewhere for installing the ATI drivers, but importantly it wrapped it all up in a user-friendly package. Kudos to Alberto Milone for this work, the real question is why Ubuntu couldn’t do this itself, or isn’t packaged with Envy in the first place.

I had a little bit of fun with Compiz – the 3D desktop manager which is enabled by default on Ubuntu now. Most of the effects are of course shamelessly ripped off from either OS X or Vista, with the exception of things like the ‘desktop cube’, shown here on the right. It’s generally very attractive and very configurable though, so on the whole I like it. I do think the settings need to be exposed in a more friendly way in future versions though, it took me a while to figure out how to enable different plugins and configure the combinations of them appropriately.

Because Ubuntu’s package manager is apt based, it’s very easy to install new things and the Add/Remove applications UI is pretty intuitive – arguably it’s easier for a regular user to grab a bunch of extra software than it is on Windows and OS X because so much of it is right there in front of them. I’m used to apt on Debian and I must admit that it was hugely painful to have to use RedHat’s up2date and RPM-based tools after that; nothing is better than apt at resolving dependencies and tidying up after itself IMO. I liked that in a number of cases, Ubuntu realised that I needed new components to do something I wanted and offered to install them automatically, a nice touch.

A case in point is file sharing with Windows machines – opening the Shared Folders view immediately offered to install the NFS and Samba services. All well and good, and sharing a folder was very easy. But – and this is a big ‘but’ – it fell at the last hurdle because it fails to configure any Samba passwords by default, so while you can see the share, you can’t actually access it! You have to drop to a console and issue the usual ‘sudo smbpasswd -a <username>’. That was a huge disappointment because after the auto-install of the services it was really looking like it was going to be nice and automated.

So, I’m feeling a little better about Ubuntu now that Envy solved my driver issues, however it still has many rough edges which make it hard to recommend to non-geeks yet. It’s probably one of the friendliest desktop Linux attempts I’ve seen so far, but it still continues the tradition of stumbling at the last usability hurdle – like the failed driver install, and the missing final step of the shared folder configuration -  a less technical user would have just hit a brick wall and probably given up. It’s definitely getting there, but that last 10% is obviously still proving tricky.