When Max first got his computer for his 7th birthday I installed it with Debian and since Sarge hadn't been released then it ended up running Sid, and occasionally getting updated. Since it was 'unstable', of course from time to time things would stop working and he would complain and I would fix it and so on.
That computer then went to his younger brother this year when I got him a slightly better one. With Max we were all careful parents, rationally deciding that he was not going to get one until he could read and understand what he saw on it. All very nice. With Fraser the decision came when we could no longer stand all of the arguments and screaming that happened when he wanted to use Max's computer. The reasoning is always different for the second child, and I've heard it evolves even further for subsequent ones.
Anyway, Fraser got Max's old computer running Debian unstable, and Max got a new one. Since I'm generally using Ubuntu for desktop PCs where I don't want to get too bogged down maintaining them I installed Dapper on it, but this has proved problematic. I still occasionally update Fraser's computer, and it sits in the living room so inevitably ends up being used by both of the boys and Max has been getting green recently with all of the new software appearing on Fraser's machine while his has been completely static. He also complains that he likes to see all the text scrolling past when it boots - not that fancy boot loader screen that Ubuntu comes with, so in the end he persuaded me to upgrade it from Ubuntu to Debian.
The upgrade from Ubuntu to Debian is something I have done before, and I knew it was a non-trivial exercise. I think I got it roughly right this time, and I'll add any further gotchas to this story as I discover them from time to time in the coming days.
The first thing to note is that it can take a long time. Although it took only 20 minutes to download the 1000 packages that were going to be reinstalled (since the nice man came and fixed my internet connection yesterday :-) the actual installing of them was slow.
Significant untangling of dependencies was needed. I firstly did something like:
dpkg --purge `dpkg --get-selections | grep ubuntu | cut -f1`
which got rid of all of the Ubuntu meta packages and sounds and themes and so forth which were going to make life impossible if I left them around for too long.
I then downloaded all of my replacement packages, attempting to just 'dist-upgrade' to Sid. This was probably a mistake. I think a better approach would have been to purge masses of packages, down to some bare minimum, upgrade that bare minimum and then build it back up - possibly using Fraser's computer as a template package list.
Oh well. This is about what I did, not what I didn't :-)
So I found myself in a loop of:
apt-get -fuy dist-upgrade apt-get -f install dpkg --configure --pending dpkg --purge this-package apt-get install this-package dpkg --purge `deborphan`
for some time. Quite a lot of time, in fact. I would gauge my progress by periodically counting the packages with 'ubuntu' in their version number:
COLUMNS=200 dpkg -l -O | grep ubuntu | cut -c5-94
and eventually my dist-upgrade appeared to have succeeded, although there were still over 100 packages with 'ubuntu' in the version number. Past experience told me that this meant the job was not complete, and indeed the other computers around here running unstable all had around 0-1 packages like that.
The next trick was to:
apt-get --reinstall install `dpkg --get-selections | cut -f1`
which doesn't work, in fact, because some things have circular references and so on. A better solution was to:
dpkg --get-selections | cut -f1 >to_upgrade.lst vi to_upgrade.lst (delete all the ones that can't be handled) apt-get --reinstall install `cat to_upgrade.lst`
and that worked reasonably well, but I think that last line would have been better as a loop:
for PKG in `cat to_upgrade.lst` ; do apt-get --reinstall install $PKG done
One thing was still mystifying me, and that was "why is 'lsb_release -a' still telling me this is Dapper"? Well, it looks like Ubuntu's lsb_release sticks a file in /etc/lsb_release containing this information, and that Debian's lsb_release honours the presence of that file, but doesn't manage it's existence. Once I deleted it that looked better.
Believing everything was working now, it was time for a reboot. This proved to be a bad decision. During the install I had been upgraded to a 2.6.18 kernel and something got lost in the translation so that modules were not being loaded correctly. Or something.
So I built a new kernel on another box, this time making sure that the ide drivers were built-in to the kernel and it would be able to mount it's drives. I then booted from a live CD, installed the kernel and tried again.
It all worked now, except that I needed to compile some binary drivers for the video card, and I'd built that kernel on Heather's system (because it's a dual core AMD64 :-), which is running Dapper and now I needed to build it again on Max's computer so we could build the modules there against the right packages and so on. On a PIII 900 it just takes a bit longer.
A little more mucking around and everything seems to be kind of working, or getting there. I've warned Max that it might be a day or so before everything is working correctly, as he expects it to be. I know sound isn't fully correctly working quite yet but he said that's not important as he doesn't use the sound anyway, which was interesting.
However his 'killer app' is now caught up with the version on his brother's computer and all is right in the world.
He spent the next few hours checking out all the cool new features in the latest TuxPaint, while I got back to what I would rather have been working on all along.
My Really Simple CalDAV Store moves on apace. I have rewritten several of the libraries to use a more consistent structure, and have now implemented a fair subset of the PROPFIND command - to the extent that Mulberry now works with it as well as Sunbird/Lightning and Evolution.
I've also started developing a regression testing framework, and I believe that the database structures around the calendar resource data are now basically correct. From this point I will provide patch scripts to allow upgrade of resources.
It is interesting to see the different approaches that client software has taken to dealing with CalDAV, and I have to think that this has something to do with the long process of evolving the specification. It will be nice when it is complete, and people can develop against something that isn't moving. I believe that the CalDAV specification is actually quite good and straightforward, but I don't feel nearly as happy about the iCalendar spec.
The iCalendar definitions of timezones, on the other hand, have to be one of the best examples of overachievement out there! It is not surprising that none of the software I have come across actually includes more than the most recent timezone definition information within events. The full definition of the New Zealand timezone comes to around 15k, and it would be ridiculous to include that with every event! In an even more bizarre twist, there is no field within the VTIMEZONE which references the timezone with a standard name! No doubt that is not problematic when most people are arranging things within a timezone, but for global events it really is a significant flaw. Evolution uses an X-LIC-LOCATION property to reference the Olson timezone name, which seems to be an industry standard of sorts, but the standard should define such a thing. Even better, having defined a standard way of referencing the timezone name there would be no need to schlepp the full timezone redundantly along with every event.
Well, enough ranting :-) Improvements in this version of RSCDS include:
- Fix some bugs in caldav-REPORT, which was not working with Lightning.
- Complete work on PROPFIND so that Mulberry now works.
- Add MKCOL, which is based on MKCALENDAR, to support hierarchies of collections better.
- Rewrite REPORT to use the new XML libraries.
- Commence support of relationships and permissions.
- Write new ics.php which allows export of the full repository (for an admin), or a subset of the repository.
- That new ics.php allows webcal presentation of the calendars also, so that even if evolution can't support tasks as CalDAV, it can at least refer to tasks someone else puts there with (e.g.) Sunbird.
- Started development of a regression testing framework.
I think I'm now at a reasonable stage to have a Debian package repository for this project. Anyone interested can browse the Git RSCDS repository or Andrew's Web Libraries repository to see my progress in more detail, it's still better to provide a place where it can all be downloaded from, so you can now add this to your sources.list:
deb http://debian.mcmillan.net.nz/debian unstable awm
For those unenlightened folks running on systems that aren't based around the Debian packaging system I've provided some .tar.gz files for RSCDS and AWL that you can download as well.
I know that I gave a list of goals for my "Really Simple CalDAV Store" (RSCDS), but of course I did something completely different...
Well, maybe not completely different. One of my goals was to "find some non-Evolution CalDAV clients", and I found Thunderbird + Lightning in the form of a nightly build which worked in many ways. What it definitely did do was point up some of the over-simplification I had taken in my first cut, so I went right back to basics and redesigned tables, renamed columns and rewrote objects.
Another thing that I did, which provided a good bunch of background information was to add CalDAV support to WRMS. This was an incredibly useful thing, because it familiarised me further with the structure of iCalendar entries and so forth, and although the implementation is not really usable, it shows me the real value of storing the iCalendar entries natively and keeping the parsed values separately. That's the way that RSCDS does it, and it seems to work very reliably.
I also did at least start to develop the admin interface, and to improve the database setup scripts. I just didn't get incredibly far down this path, although I probably will now that I've got what I consider a releasable starting point.
The first of the files below is a Debian package of my standard web libraries, libawl-php, which is a bunch of useful routines I've developed over the years. The other file is, of course, the RSCDS application itself.
Updated 2006-12-19: these files have been removed as they are out of date!
arewere some files for you to play around with:
Here are some really basic Really Simple CalDAV Store instructions.
I've now spent some time writing my "Really Simple CalDAV Store". I've got it to a point where it:
- Accepts uploaded events
- Reports on events
- Handles updates to events
- Handles deletion of events
- Uses "Basic Auth" to identify the user
- Is Debian packaged (in a very basic form)
- Parses the event into a PostgreSQL table
Further goals now are:
- Provide a simple admin interface for users and groups
- Re-present events in free/busy format
- Find some non-Evolution clients to try to handle
- Write a better process for setting up an initial DB
- Re-present sets of events as an iCalendar URL
- Add support for MySQL (no, just kidding :-)
If anyone wants to play with the Debian packages of this "as-is" I will make them available, but at this stage administration is through SQL queries directly against the (PostgreSQL) database.
From our work today the Nokia 770 is definitely looking like it will do what we need. There are still lots of challenges, and it will be a real miracle if everyone manages to get their act together to get our client's application up and operating on these by early November.
Meanwhile I'm even more impressed with it today than I was yesterday, I think. Right now it just told me (for the first time) that the battery is low. This is after Heather had another go at it so the thing has been used continuously for the last seven hours, including Heather about two hours listening to downloaded audio while browsing.
Right now I'm SSH'd into it while it's playing a stream (with mplayer) and I have now found a bunch of repositories that have the 'armel' packages (including the one with DropBear for armel along with a bunch of other useful stuff. The Maemo.org site seems to be really useful, although some pages in the Wiki perhaps need reviewing - it seems that quite a number of the enhancement possibilities have been followed through on.
Finally, a couple of minutes ago, the device informed me it has a low battery, and shortly over that it dropped the wifi connection and my stream connection (and SSH connection) died as a result. I guess that 7.5 hours is a pretty good deal, especially for such intensive use.
That intensive use included things like re-flashing the device when I tried to upgrade to the Sardine distribution (without an SSH connection into it) and some package was killing the X server during upgrade, and eventually killing it on boot.
So if it's gone to sleep, I guess I should to!
My previous efforts to purchase a Nokia N770 finally came to fruition this morning when two of them were waiting on my desk when I arrived at work. I was very happy, although if these do the job we'll have to go through that all over again to buy the next 20 or so...
For the curious, these were ordered through the Nokia UK website, delivered to the relative of a workmate passing through England for a conference who then collected them and posted them to us. We might have to find a simpler way for the next lot...
Can it really do what I want it to do? Is it usable? Although I've played with these before (in Helsinki before they were released, and in Mexico earlier this year) I have not had one in my hands long enough to really get to grips with the user interface.
Now I have one that I can play on without restriction, I can see that it is all really well-designed for the form factor. Nokia do seem to do this sort of thing very well, and the software all integrates very nicely, and be very stable. So far I've only managed to crash one application (the browser) when trying to resize the screen while viewing the UI from Hell. Hardly unexpected - that particular bit of Flash (Crash ?Trash?) seems to break most browsers in this household.
To try and gauge the battery life I handed it over to Heather for the evening. She found it fascinating and didn't put it down for about five hours - with the battery icon still indicating a full charge. The battery icon did suprise me, in that you can't click on it, or mouse over it to get more information. In fact the oddest thing I have found so far is that there was no 'Power' item in the control panel and the only control over power seems to be under "Display" where you can set screen dim / blank timeouts. No separate adjustment for when you have it plugged in, or for how long before the WLAN chip times out, but perhaps the battery life is such that I won't find myself doing it regularly and my desire to fiddle with such settings is foolish.
Hacking In ...
Well, I didn't manage to stave off my desire to fiddle for very long at all... maybe an hour after I got the device I had downloaded a backup image, in case I have to reflash it back to a known state! First up was the need to install an XTerm, which proved relatively straightforward after adding an APT source pointing at http://maemo-hackers.org/apt/ (although you do this through an Application Manager of course :-).
Once I had the XTerm installed I can get into the Linux installation, but to get root I need to do something more complicated. The Wiki suggestion was that I install an SSH server and ssh in as root so I downloaded the Dropbear from my laptop and saved it directly onto reduced size MMC in the N770, mounted as USB storage on my laptop - very easy. The installation of a downloaded version of Dropbear failed though, and unfortunately the "Application Manager" didn't display the error messages. So I proceeded to use the "flasher" tool to "enable R&D mode" which eventually succeeded after many unsuccessful attempts. I seemed to need to:
- power the N770 off
- hold down the "Home" button
- press the power button
- insert the USB cable as soon as the screen lit up
It seemed that it wasn't possible to power on the device while the USB cable was inserted.
Reading the documentation further, it seems that it should be trivial to create a Debian package which could be installed to replace (or edit) the "gainroot" script so that it doesn't check for R&D mode, and I think I will do that if we are going to be getting a bunch more of these.
Anyway, now I had root access I could see that the Dropbear packages wouldn't install because they were the wrong architecture. It seems that I must have a slightly newer model than the documentation (and many of the packages, I guess) apply to, and that the architecture is 'armel' rather than 'arm'.
I suppose this means that next up I will need to download scratchbox and set up a build environment so I can build that SSH server, and probably so we can build all sorts of other things to go on there.
I'm looking forward to it, although it has somewhat distracted me from my CalDAV investigations, which were really starting to get somewhere useful.
Following on from some failed attempts on Friday, it seems that Andrew Ruthven has had some success getting Apple's Calendaring Server going on Debian. Great! I managed to duplicate Andrew Ruthven's success after five minutes by applying his PyKerberos patch so I now needed a calendar application that talks to this...
One of the reasons I had been trying to get this going in the first place is that Evolution has a CalDAV plugin. Andrew had told me that this didn't work for him though, and after quickly failing myself and not finding a lot of help from debugging information, or from sniffing with WireShark, I decided to try Chandler.
Trying to use Chandler
I tried to roughly follow the build instructions from the Chandler website to build Chandler on Debian unstable. The downloadable builds strongly suggest that they won't work except on Ubuntu Breezy, so I didn't initially go to them. Unfortunately (or perhaps fortunately) the builds.osafoundation.org server appeared uncontactable and this is where a vast raft of stuff seems to want to be downloaded from.
So I went for the .tar.gz binary download that the Chandler folks currently build on Breezy and in spite of all of their caveats it seems to work just fine on Debian Sid.
Well, maybe "just fine" is exaggerating, but this is 0.7 alpha 03 release, after all:
- Pressing 'Today' showed me the past week.
- Trying to edit the date/time of an appointment made it rapidly and wierdly move into the past
- It didn't appear likely that I would use this application even if it did work for me.
- It seemed to be about as usable and stable as Evolution was pre version 1.0
That made me really sad. I had got Chandler to connect to the CalendarServer, even if I couldn't see that it was writing any appointments to it. The URLs used and so forth were enough of a clue bat to point out that I needed to connect to
Getting Evolution Working
It turns out to be pretty simple to get Evolution to work with the existing 'admin' user:
Adding a new user
OK, so lets add ourselves as a user...
Edit the file conf/repository-dev.xml and look for an element called '<accounts>' near the bottom of the file. You need to paste your user in something like this:
<user> <uid>andrewmcmillan</uid> <pswd>password</pswd> <name>Andrew McMillan</name> <calendar>calendar</calendar> </user>
Then configure your new calendar with the "URL" set to "caldav://localhost:8008/calendars/users/andrewmcmillan/calendar/" (because we told CalendarServer to put the calendar into the 'calendar' folder. The "Username" should be set to whatever you chose, of course.
Where to from here?
Well, I think that I probably need to read the docs for this now :-)
I want to try and create a bunch of users, resources and the possiblity of other's sharing calendars. Creating resources looks easy enough from the repository-static.xml example, and I seem to have done that, but I think I need to get together with some of the other guys at work fiddling with this and see if we can do a shared installation.
After that, of course, I will be looking for some Debian packages of it all. Especially since it was this Debian ITP message that got me (re-)started on all of this. Good luck Guido!
I must admit, I am proud to have gotten a free ride from a London Cabbie.
My first visit to London, or indeed anywhere in Europe, was in July 2005 when I got to spend a day there on my way to Helsinki. Just time for once round the Eye, a quick glance around Piccadilly and a half-day meeting with the good people from the Open University.
I was in a hurry, of course, and I fully believed that I was arriving in a developed nation where things would be fairly normal. I was even prepared for them to be more advanced than we are here, in some ways. What I was completely unprepared for was the generally low level of acceptance of credit cards.
I first encountered a credit card in 1979, when my parents used their new VISA to buy me a bunch of furniture to get me into my first flat. I think I got my own card a couple of years later, and these days I use it for pretty much everything from buying the weekly groceries to buying those air tickets to Helsinki.
So when I got off the plane at Heathrow, I immediately headed for the cabs. That's what I've done every time I arrived anywhere in Asia-Pacific, and it's worked just fine. Several times I've been to Australia for a week without handling any cash at all.
Then I got in a London Cab, assuming these guys would take credit cards. You can't choose a cab at Heathrow - you have to take the assigned one - and the whole procedure appears to be so much trouble that you don't want to inconvenience them by requesting one that takes credit cards. Not that the though of doing so even entered my mind. Surely they're supposed to be the most with-it cabbies in the world aren't they? If the propaganda is to be believed they practically need a degree to be allowed to drive, so surely they'll be doing it all with the latest technology! Well no. These 'famous' London Cabbies aren't a patch on Corporate Cabs for quality of service, although they no doubt exceed them on price.
Once I got into the cab, we started to negotiate the destination, but the cabbie appeared never to have heard of Teddington and at about that point I also noticed the distinct lack of credit card company logos and tendered the question about credit cards.
Since he appeared never to have heard of these things either, and he wanted not a bean of any of the other currencies that I did have floating about in my wallet, this was clearly not a match made in heaven. He dropped me off near an ATM a few minutes drive away, possibly wondering if all New Zealanders were barmy, wanting to use a plastic card instead of carting fuckwads of mugger bait around with them. How odd.
I have been reminded of this strange cultural difference in the UK recently a couple of times. Firstly because I went to the UK Moodle Moot in Milton Keynes recently and was once more forced to fill my wallet with more cash than I normally see in a year.
More recently though, I've been trying to buy a Nokia 770. Apparently Nokia think that "New Zealand" is somewhere in Europe, because that link definitely redirects to europe.nokia.com. On the other hand they must be pretty sure it isn't, because it's not one of the countries listed when I click on the "Buy Online" button - that only shows a bunch of countries that really are in Europe. And the US of A, of course.
None of those sites will let me ship the darned thing to New Zealand though. Of course I knew this, and I thought I'd try and buy one in Los Angeles when I went through there earlier in the year. I was only there for seven hours though, which is barely enough time to get through customs and check your baggage in for the next flight in these paranoid times.
My next chance was a trip to London. This time I even planned ahead a little! I found a retailer in the UK who was selling the Nokia 770 over the web. I worked out their physical address and plotted myself a little map so I would know how to get there and then I e-mailed them to ask if I could buy one and pick it up while I was there?
Well sure I could. I just had to fax them a copy of my grandmother's birth certificate or something first. They accept credit cards, but it seems that somewhere in their office they make the paper that they turn into credit card slips, each one lovingly hand-inked and beautifully crafted in gold leaf. They couldn't accept credit cards, even if I visited in person and signed the slip in front of them. Those US of A paranoids have got nothing on these guys. They're so distrustful that I find myself starting to distrust them! Clearly they also don't have computers, or dial-up connections to the bank, or they would be able to validate all of the credit card can-the-bastard-pay stuff while I was there, and before I ducked out the door with the merchandise.
OK, I'm stupid. I should have ordered them the day before I left, to arrive at my hotel. Duh. I've never actually got something shipped to a hotel and I must confess to being somewhat disorganised from time to time (if you've read this far you are probably wondering how I ever manage to get out of bed in the mornings). Of course once I thought of this it was too late - I wasn't going to be at the hotel for long enough for that to work.
And anyway: I was going to be in London. Surely there would be some shop in London that would have one on a shelf somewhere that I could just pick up and carry out? Well, no, actually. It seems that these devices are so well marketed by Nokia that nobody has actually heard of them. Nobody (barring wierdos like me) wants to own one, and nobody in their right mind would be seen dead trying to purchase one in the Nokia store in London. Or in one of those electronics places down Tottenham Court Road.
So, I returned to New Zealand Nokia-less again.
We still want one of these things though. In fact we want four of them, so I return to my original website where they will sell them on-line. Albeit, to people from third world countries like New Zealand they will only sell them one at a time on credit card. I no longer trust these guys, because they don't trust me, but I decide to have another attempt to get them to ship the thing to me directly. So far my first order has been screwed up because my shipping address has to match my credit card address, which has to be the credit card billing address, and their website forced me to choose a different credit card at the end, from what it had said was acceptable at the beginning. It took a few days to work that one out.
Who knows, maybe my second order will work? In a couple more days, when they've had a cuppa or two and telephoned the bloke at the bank to find out if my card is real, maybe they'll get back to me and ask me to send them an autographed picture of myself or something.
Meanwhile, I just realised while writing this that we have someone visiting England for a conference at the moment. I realised it because I was chatting with him on IRC, so I can order them through the Nokia website, so long as the credit card address of "New Zealand, England, NewZealand, United Kingdom" is valid enough to scrape by.
So now we have MPhone:1, Nokia:2. I'll be disappointed if the ones ordered through the Nokia website get to me first though because that conference hasn't even started yet. Maybe I should find a non-paranoid USAian and see if I can get one shipped from there as well.
I'll give the London chaps another day to run their atomic force microscope over my credit card details, I think, and if I don't get any action from them I'll get my auntie onto the job from Pennsylvania.
Hopefully they'll take AMEX on the Nokia on-line store in the US of A.
Updated 2007-04-10: This post was written in August, 2006 and has been superseded. Here are some pre-built eAccelerator packages for Ubuntu, you could also build your own from my Debian source for eAccelerator or you could use my pre-built eAccelerator packages for Debian Etch.
... back to the original post...
PHP script caching has been flavour of the week for me here. First I tried out APC (the APC docs are here), because it seems it is The Coming Thingtm (somewhat belying it's name as the "Alternative PHP Cache"). Unfortunately at present APC does not cope with Gallery2 although it is just fine and dandy with Drupal.
No doubt that will be fixed in due course, and I will probably switch to it, but in the meantime I am using eAccelerator which works just fine with both Drupal, Gallery2 and as much of my own code as I have tried. I'm now running it on my development environment, so I guess everything will work with it eventually, even if it doesn't at the moment :-)
As a result, I now have packages of eAccelerator for i386 / PHP5 / Apache2 / Ubuntu Dapper and for i386 / PHP5 / Apache2 / Debian Sid, and it is time to share the love.
While these aren't exactly raw packages (e.g. they add the line to your php.ini file) they aren't polished either. At this point they don't build php4-eaccelerator packages, and I haven't tried to build them against apache 1.3.
The Deb for Sid should verify thusly:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.0 Source: eaccelerator Version: 0.9.5-rc1-1 Binary: eaccelerator Maintainer: root
Architecture: any Standards-Version: 3.7.2 Build-Depends: debhelper (>= 5) Files: 6234c7a3f463c9a982e89a038841a04f 154119 eaccelerator_0.9.5-rc1.orig.tar.gz a472af17d7992012c5eee077579c858a 3807 eaccelerator_0.9.5-rc1-1.diff.gz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE4vQgjJA0f48GgBIRAjp1AKCWwOTgQKZZ2cxqAuBRWFmU5I9yBACePDbW gslWRtUeasGAhu1YmLgoUxg= =OFZL -----END PGP SIGNATURE-----
Assuming you munge the name the way I have.
If you want more, send me a request and I'll see if I can build them in other environments (like Sarge, AMD64, PHP4 with Apache 1.3), or add stuff to them to support that. Unfortunately I believe there are licensing issues somewhere in the dark past of eAccelerator, so I probably can't upload them to Debian.
Attachments removed since they are no longer current
Tonight, in the process of setting up this blog, I've had some very different software experiences...
Firstly, I used an internally developed application, written in PHP against a PostgreSQL database. It looked OK, and it worked sort of OK (I filed a couple of bugs) but one particular feature of it's operation really pissed me off: it went all bouncy and redirect-ish on me whenever I submitted a page.
I think that the point of the redirect was to be able to display something to the user before returning them to the page they originally came from. While that may be a noble objective there are a couple of flaws with doing it that way:
- It's too slow
- It's too fast
It's too fast because you can't go back and see what it said if you slipped into that momentary zone that I often do when I click submit, and I think I know what's going to happen. Or any of the million or so distractions around me do happen.
It's too slow because when you are awake and watching you know what it's going to say and you want the next page so you can click on. Now. Dammit!
It is bad usability design and I also think it would be very bad from an accessibility viewpoint.
How would a screen reader cope with that? I don't know. I suspect it would sometimes catch them out, but to be honest this sort of crap is all over "teh intarwebs" and they've probably written them to cope.
So tonight I was installing some software so I could write a blog because someone at work decided that work blogs would be a good idea. I wasn't originally going to blog about why redirects suck, but that application miscue got me riled.
I then had to install Drupal. People have been mentioning Drupal to me a lot recently, so I downloaded it and installed it. Disappointingly the Debian package is version 4.5.8, but the only apparently stable versions of Drupal are 4.6.2 and 4.7.2, and 4.5.8 wanted me to uninstall PHP5. Oh well, I can rip open .tar.gz files with my bare hands, fly faster than an RFC1149 packet and so forth, so I downloaded 4.7.2 and installed it.
This is a beautiful install experience. The bits that aren't working are very quietly and clearly presented as not working. When something needs to be tested to see if it works, the option is greyed out until I test it and prove it does work. Slick. Very slick.
And when I change a setting and submit the page, I get a nice box near the top of my page that is bordered in green when it all worked, and in red when it failed.
Super slick. And way better than a redirect.
Looking at the list of categories on Eduforge.Org I think there are a few others that would be reasonable as well: "Real Life" and "Moodle" both seemed to be missing, so I've added them. "Debian" is conspicuous by it's presence in the list, and no doubt I will be using that one in due course...
In fact why not talk about Debian now. And Ubuntu. And how the two projects are having interesting effects on each other. At Debconf5 recently Mark Shuttleworth gave an interesting talk where he tried to present his view of the interaction between the two projects.
There are interactions happening between the two projects on a number of levels though, and I don't think Mark was covering all of them (there wasn't time - even with the talk going over time we still had many other non-recorded sessions at Debconf where the interactions were discussed). Some other things that I find interesting are really obvious things: Debian can be a great system, but the effort to polish it for naive users can sometimes be unexpectedly haphazard. I installed Ubuntu "Hoary" onto an old laptop for my wife yesterday and I could see the extra polish on things. The street appeal that Ubuntu adds to Debian is really powerful, and I think that it must concern RedHat to see the reverse of their Fedora approach sneaking up. Debian has always been a great server OS, and for some things (like the really superb upgrade-in-place capabilities) have really benefited from being a distribution crafted from the ground up by an organisation comprising many experienced systems administrators.
Fedora's community has had a somewhat rocky road to gain credibility, with people necessarily finding reason's to mistrust Red Hat's motives and to be uncertain as to whether there really is separation between Fedora and Red Hat. Of course in Debian "There Is No Cabal" and even if there were, they wouldn't all be Canonical employees, would they? It's nice that Mark has indicated that Canonical will never employ the Debian Project Leader, although I imagine that SPI will eventually have to. The project is only going to increase in scope, if it's success is to continue, and it will need to move to have full-time staff - fairly soon, I should think, if it isn't already the de-facto situation, with the DPL's employer effectively paying the salary with only limited control over what that person is achieving during their term of office.
It's nice to see the Ubuntu Foundation launched, although it is interesting to see a comment on the press release that suggests that Canonical's focus is "commercial support and certification programs". Does this warrant paranoia? Mark is undoubtedly an astute businessman, and certification programs will be useful to the future of both Debian and Ubuntu (I can't see how one that would apply to one would not apply to the other, either).
Commercial support is also an interesting proposition to me. Of course many people (me included) provide "commercial support" to Debian (and Ubuntu), but few have the resources behind them that Canonical does, which could mean there is a significant concentration of the people who really do power Debian employed full-time by Canonical, and necessarily the goals of Canonical will affect Debian's direction.
In the end I don't think this matters though. Debian has got where it has through the personal energy and leadership of some very driven individuals who have provided a framework of standards and policies which guide people in the right paths (is it any wonder that most of them seem to violently disagree with each other?). Combine this with the strong (if unusual) society of Debian and the consequent normative effects, and I can only believe that Debian will be strengthened by these things.
Just as it is hard, sometimes, to give away the fruits of your labours, giving away significant amounts of money without retaining substantive control over its use is also hard. This means that Ubuntu is very well funded (at least USD$10 million) compared with Debian (SPI holds around USD$60 thousand or so). I imagine that this has been thought through in a lot of detail though, and it is hard to see in what way Mark could successfully donate to Debian through normal channels. If he gave SPI even USD$100k it would overbalance the pot completely, and would probably only really mean that something which Debian currently gets donated would begin to get paid for. Not a desirable side-effect.
When all is said and done though, and as Mark so forcibly points out in his talk: Ubuntu could not have come into existence without Debian, and neither can it continue without it. Debian will need to stand on it's own, and will in some circles be eclipsed by this shiny public-facing edifice, but early reports of it's impending demise are greatly exaggerated.