It's now Sunday and I'm back in the office. Beginning of the year - new image to be made. Deployment method to be sorted out. Things that hopefully make my life just a little easier this year.
So what's changing. I feel like I've talked about it all before. It's stuff that I've wanted to do, been meaning to do for a while.
The upgrade mechanism.
It hasn't been broken exactly... I originally wrote it in bash. It's intent was to make the upgrade process less obtrusive. I'd suggest this would be something that most businesses could use if running Ubuntu on their desktops. It's a system process, so it starts on it's own regardless of the user's credentials.
It's now been completely rewritten in python. This has proved a little trickier than I thought. It turns out that the python-apt libraries in lucid are woefully out of date. So it uses a combination of python-apt and subprocess calls. At some point I want to update those libraries to something more recent and rewrite it so that it's using as few subprocess calls as possible.
So here's what it does. It updates the index files. It then goes through a blacklist and uninstalls anything that's on that blacklist. It then goes through a priority list. This is a precaution for slow connections. It's beneficial to be able to tell the system to install a couple of vital packages before any others. Then it fetches packages. It's important for the fetch process to be split off from the installation process as downloading packages can take a hellishly long time and can be interrupted without fear of breaking the packaging system. And finally, it installs the packages.
The blacklist also has a package that just provides "conflicts" for each of the packages on the blacklist. This means that if a user shouldn't be allowed to install a package, if it is installed, it'll uninstall it and if they try to install it, the packaging system will just give them an error.
The system also now features a lock. So the system can not be shut down or rebooted without fear that it will interrupt something that will break the packaging system. This is a little bit risky in that it could, for some unexpected reason, not unlock so this is something I'm going to have to watch closely. If it works as it should though, it should make my life a hell of a lot easier.
Due to this, I've had to change the flashplugin-installer package. The flashplugin-installer provided by Ubuntu deletes any file that has been downloaded and then tries to download it as part of the installation process. On a slow connection, this can make an upgrade process, which should only take a couple of minutes, take an hour or more. So the package (called flashplugin-installer-resume) doesn't delete the downloaded file and allows resuming of the download.
This script is typically only run once. It sets up the system for the first user. That's pretty much it. It had a couple of bugs. It wasn't setting up permissions properly. So that's now been fixed. And that last post? The one about how to change the defaults for the Ubuntu Netbook Launcher... Well the real intent was to include an exclusion for maximus.
Maximus is a program that maximizes windows when they first open. It causes chaos with some programs.... such as the initial login script. The script's windows would lose focus. In UNE (Ubuntu Netbook Edition) this makes the window completely disappear except for a small icon in the top left. Not the best first impression of the interface or my efforts.
So that's what's new with the image. The next big thing on the agenda is the imaging process. Can it be altered to make use of larger hard drives? Can provisions be put on there to use the same image with EFI-BIOSes (which need a different bootloader). Network configuration, given the nature of Pre-Shared Keys, needs to go in there as well. It needs to happen seamlessly. Last year it was a month or so of chasing down kids and their netbooks to put the key on there and test that they work. This year, if the key is thrown on during imaging (and thus re-imaging), hopefully it'll mean a hell of a lot less manual intervention.
And after that, during the next holidays, I'm hoping to do something with the network manager applet. It's a very cool tool for connecting to networks BUT has way too many disruptive options. For example, the kids are able to make their own ad-hoc networks. This hasn't been used for anything good thus far and so, removing the option from the applet should make this a little less disruptive.
At some stage, I'd also be able to tell nm-applet that one network is the equivalent of another network - so go for the strongest of those two and treat them as if they have the same ssid rather than what was last connected to. Given that the kids take the netbooks home and connect to the Tamaki Learning Net network, the next day they find that the connection is slow. The problem is that a weak signal for TLN can still be seen within the school, so the applet connects them to TLN taking it as a preference.
So that's where I'm at at the moment. About to build the new image and then start on the deployment method... The question is, what other little issues am I going to see this year? And what are the smart ways of solving these issues?
I have been having discussions about learning opportunities vs. convenience. These are kind of at odds with each other. The netbooks must be better than a book - which they aren't if learning time is lost trying to fix problems.
Have you heard of Raspberry Pi? I, like everyone else, want to get my hands on a couple of these to have a play. The problem with it though is it's intent. It's not really meant to be an educational tool in that it isn't intended to help teach reading/writing/math. Rather, it's meant to be used to teach computer sciences - thus it's an educational tool... And I think here in lies my issue with the debate around learning opportunities. What sort of opportunities are we looking at?
A geek nowadays could be someone who knows how to get a 2 column layout in a Google document rather than someone who can open up a terminal and bash away at fixing various issues... So the learning to learn is probably a lot more important than trying to teach people not to be mystified by the shell.