Friday, March 1, 2013

Tartare Source - Progress

Geek speak warning... you have been warned.

So I've spent the last couple of months working on Tartare Source. It's got some really cool stuff going on.

Gherkin (what I had previously called the uninventive "initial-login") allows for entities to be set up to their needs at first log in. This means that each of the schools in the Manaiakalani project can have settings that fit them, individually. I've added a new feature where I can present a list of options to the user and have things happen based upon those choices. So if a user is taking music and electronics then the applications needed for each of those subjects can be installed automatically. Suddenly they've got MuseScore and whatever PCB layout software they need. This should mean there's less class time taken up in trying to get all of the learners installing these applications for themselves. It's just there.

Capers is the update system. There's something that feels a little... futile about it. If you give your users access to install their own applications, then all bets are off. They are the administrator to the system. So the goal is to at the very least slow certain things down. I was asked today why I wouldn't do a more infrastructure type approach - restrict the repositories down that they can install from (the less known chattrib could be handy here). There are a couple of reasons for this.

  1. They still have full admin rights. So it's simple enough for them to add their own repositories. Much easier than trying to figure out why those blacklisted applications aren't appearing in their software lists (assuming that they notice that something isn't showing up. You don't know what you don't know).
  2. The admin overhead is just not something I'd want to take on. Sure, for the most part it could be automated, but there's still a world of pain there.
Meanwhile, capers is more than capable of blacklisting applications. I've been a lot more thorough this time around. If an application is blacklisted then it no longer appears in the index files AND disappears from the Ubuntu Software Center as well as the good old mechanism that was in place last year which is using packages to conflict with those blacklisted applications. It's a bit like putting a chain on your laptop. It probably wouldn't stop anyone, but it will slow them down.

I was wondering if this particular restriction could be removed. If a user is able to install applications in their home folder for example. Unfortunately, given that most libraries are hardcoded into those applications, this wasn't a possibility (though something I think could be solved).

One of the problems I had last year was that one school wanted to blacklist applications which I didn't think should be blacklisted. With the approach I was taking, it was difficult to blacklist it for them and not for the entire cluster. I've addressed that in this build as well.

The other bits are going to have to wait. I have to start on the actual implementation. So taking a vanilla build of Ubuntu 12.04 and making it a bit more school friendly. Banners can be removed from the software center. Error reporting shouldn't default to on (what were they thinking?!?). I've got an issue with a learning tool that tries to sell things to kids so disabling things like music purchases from the music player and paid for applications in the software center. And then there's the whole stability testing bit. In the last couple of weeks there have been an incredible amount of updates to the kernel for Ubuntu 12.04. None of my computers are able to go into suspend mode at the moment - something that definitely has to be addressed on the netbooks as this would have a profound effect on battery life and the user's experience.

The browser is something else I'm going to have spend quite a bit of time on. While Chrome removes the pain of flashplugin (and it's perfectly legal to distribute Chrome browser with flash inbuilt as opposed to it being against the Terms of Usage to distribute the flashplugin) it brings with it a host of other issues. Chrome browser is as much of an application framework nowadays as it is a browser. Which means that extensions should be viewed as every other application on a system. This is terrible news in terms of safety and security as it means users can install whatever they want - things to circumvent security for example (though a poisoned DNS server on a network would probably solve this one by pointing known proxy servers to somewhere where they can't do any harm... The hosts file locally).

What this means for Tartare Source.... Capers will probably need to take that into account and actively remove known bad extensions (as well as any other measure that may further hinder the use of troublesome extensions).

So in a few months time I should have finished this implementation, been paid for it, and the code will then appear on the Internet under the GPL v3 license. Exciting times...


  1. gosh, i had to think twice on this post. couldnt figure out if you were talking about a salad or a computer progamme. was the creator eating a salad while they were compiling theres...gerkin..tartare..capers?

  2. :) I was thinking about a name and was having a moment of Raspberry Pi love... Tartare Source seemed perfect. Made up of lots of different parts - none of them, except maybe the mayonnaise, essential.