Wednesday, July 25, 2012

Manaiakalani Shininess Part II - Initial Login

Just a note about the title of this post... "Shininess"... This is stuff that has been made for the Manaiakalani programme (I heard that it's no longer a project as a project implies some sort of end) - it's not THE programme.

Initial login is exactly what it sounds like - something that runs the first time a user gets on the netbook. Basically a set up program. It started as a way to create a user account but turned into something quite... well... versatile. It's nowhere near complete - I have all sorts of plans for it - but it's starting to show it's promise.

So basically, to set a up a "site", you put a bunch of packages in somewhere (those you would want to install for that site - this leads to a bunch of sins. I'll describe that particular issue in a minute) and write a definition file. The definition file describes what you want to happen. As an example, consider the following:

 get USERNAME text "Username" "Please enter in your username."  
 get PASSWORD password "Enter a password" "Please enter in a password.\n\nThis should be at least 8 characters long and should be something you can remember."  
 add_user USERNAME PASSWORD dialout,cdrom,plugdev,adm,lpadmin,admin  
 install /usr/local/packages/school/*.deb  
 install /usr/local/packages/geogebra/*.deb  
 remove xterm  

Basically, this definition file asks for a username and password. Adds that user and makes them administrator. It looks inside /usr/local/packages/school and installs any packages in there and does the same for /usr/local/packages/geogebra. And then removes xterm (or whatever else you may need to remove).

So all pretty basic stuff. Those sins I was talking about... There's an incredibly strong temptation to package up deb files. For geogebra for example., there's a package called "initial-login-geogebra" - which contains the packages needed to install geogebra. The approach works but it feels a little... wrong. It gets worse when the packages needed for something are packages that I've made (rather than just downloaded) and packaged up in this manner. It works but it's ugly.

Okay - so all very cute... but not shiny yet... Not really. Except... due to how I saw this working, I'm able to do whole conversions of the image. The same image that is used for Manaiakalani can be used elsewhere. The branding can change. The applications that are included can be changed (removed from and added to). Configurations (each of the school's have their own bookmarks for example). In fact, there are a couple of sites that deal with completely different concerns i.e. "entity" owned machines.

The only real drawback to this is the time needed to make the conversion when the user first logs on. i.e. child gets brand new pretty netbook. They put in their username and password, and then have to wait... That wait is what I refer to as a perceived performance issue. i.e. it doesn't really matter what's going on there. What feels important is how long it's taking before being able to explore the machine.

There are bits that I really want to clean up. Inputting text - I have no checking on it as of yet. So the plan is to be able to specify a regular expression in the definition file. The program asks "Are you sure you have gotten all of your details right?" but doesn't show the user the details. This is because... well... it's complicated. The definition file can insert parameters without user intervention and doesn't really keep track of what it's asked. This isn't insurmountable. It just means there needs to be a "confirm" flag somewhere.

So, basically, one of those things that started as a really simple idea and became really complicated as I realised how powerful it could be. Despite it being a bit of a mess, I have to say I'm horribly proud of it. This is the component I can see evolving to quite a large degree. I'm already planning a successor to Keys to the Castle. For this part, I'm only seeing ways of improving it.

No comments:

Post a Comment