It is worth noting that IPython, an enhanced Python interactive shell, is included in the standard XO builds. You can do all kinds of high-end wizardry with IPython, but the most immediately useful in this context are object introspection and syntax highlighting. When most of the system is written in Python, good object introspection makes IPython a quick route for figuring out how the parts fit together, particularly in the absence of a real IDE.

It is Christmas eve, so this isn't a good time to follow through, but what is needed is just a special config that automatically adds the relevant system libraries to the path of an IPython session and sets the highlight colors to ones that work with the Sugar Terminal settings.

Doug writes (in comments) of his XO:

It will be upsetting for techs not to have an "admin" user login. Hopefully it is not necessary. I would think a login screen for privacy purposes is critical, but then maybe kids don't have much to be private about?

First off, if you want to understand what's going on technically with security on the XO, you need to read about Bitfrost. I'm going to try to accurately represent things based on my understanding of the design, but further exploration on your part of the spec is recommended.

Essentially there are no logins on the XO (see the Bitfrost page for the rationale). It is a single user machine. It is almost like an Apple II or Vic 20 in that respect. Those were, in some ways, the good old days for educational computing. Here's one reason: remember how you booted the operating system? By sticking your DOS boot disk into the floppy drive (or cassette deck). The computer loaded the OS into memory and then you took the DOS disk out of the drive and stuck in the disk containing whatever program you wanted to load. One implication of this is that your subsequent work couldn't render your computer unbootable by screwing up your core OS, because your DOS disk wasn't even physically in the computer, and if it was, it should have had that little read only notch covered up, so the computer would refuse to write any changes to it. At least that's how I remember it. I was snorting a lot of Pixie Stix at the time, so my memory might be a little hazy.

Anyhow, while the XO doesn't have a boot floppy (thankfully), it does keep the core OS files on a read-only file system. Users are free to install software on the system, but there are multiple layers of protection to make it difficult for a rogue program to damage the system.

You can modify the underlying OS if you've got a developer key, which, if I understand correctly, can be obtained both by the user of a single laptop and by a site administrator for a whole range of laptops. So that mechanism probably functions close to what Doug is thinking of in providing an "admin login," since it will allow updating any software on the machine.

One advantage of this approach is that if you have an "admin" or "root" user, a common route for exploits is to crack a user account and elevate the permissions to the root user through a second exploit. Since you don't have a true root user, you can't take that approach (although there will be others, to be sure). Also, people often just use admin accounts as their personal accounts, which neuters that protection.

Regarding privacy in general, there was discussion on the mailing lists about whether or not all documents should be shared over the network by default. A surprising number of people, mostly from outside the core team, I think, seemed to think they should be shared by default. That's nuts, and in the shipped version, they're private by default.