Now our hypothetical trusted and open computing platform needs applications so you can get real work done. Text editors, scripting languages, officeware, and probably a desktop of some kind. To stick with our security practice of keeping systems as spare as possible, I recommend only installing applications and their dependencies as you need them. In the last post I suggested picking a package management system of some kind if one isn't already a core component of the OS that we recompiled and installed. If you get in the habit of building and using packages now you'll save yourself a lot of heartache later. Trust me on this.
So, we need a user interface of some kind. Just about every operating system comes with a text-mode shell of some kind, be it Windows' cmd.exe, tcsh on MacOSX and FreeBSD, or bash on Linuxes of all kinds. It's the bare minimum to accomplish anything, and chances are when our recompiled OS was installed a basic shell came with it, probably bash. However, seeing as how we're living in the second decade of the twenty-first century chances are you're going to want a GUI of some kind - a desktop, in other words. I am now going to pull out of my ear the statement that the OS the trusted open computer we've been discussing has a framebuffer capable of supporting reasonably high resolution graphics. This implies that Xorg has a good chance of running on it. Thus, it should be possible to install X, a basic graphical toolset, and a desktop environment onto the trusted computer. My advice to you is to pick something relatively lightweight, doesn't require 3D acceleration, and doesn't have much in the way of dependencies. GNOME and KDE are great - they certainly get the job done and they look pretty. On the other hand one has to consider just how much RAM is available on their system of choice and plan accordingly. These two desktops may be too much for the trusted and open computing platform we've been talking about.
In the past couple of years I've fallen in love with LXDE, which is not only easy to learn but lightweight and doesn't have much in the way of dependencies. It works quite nicely on the RasPi and it's more than sufficient for use on some LiveCDs. I haven't used Cinnamon before but it bears a stong resemblence to GNOME v2's user interface. I don't know what its dependencies look like so I can't speak to them. I've also used Razor-QT a fair amount (it's the default desktop in Byzantium Linux these days) and while I don't use it normally neither am I opposed to it. It's certainly lightweight enough to serve as the default desktop of a LiveCD. Whether or not one considers libQT lightweight is not something I plan to address. I don't have a whole lot of experience with XFCE, either, but it's designed to be fairly lightweight so I think it's worth investigating if nothing else.
When picking a desktop environment, choosing application software comes along with the deal. In the end, it's all software that you have to interact with. By application software I'm mean native development toolkits, scripting languages like Perl and Python, office software, web browsers... you know, pretty much everything you need on a day to day basis. So long as there is sufficient RAM and our trusted computer has sufficient processing power (and/or enough CPUs - just because I don't know of any open multiprocessor cores doesn't mean that there aren't any) this hardware stack should be able to operate day in and day out as a replacement workstation, capable of most anything that a store-bought machine, or computer built out of untrusted commercially available modules is. You will probably have to compile everything yourself, if not on the system you bootstrapped from with the trusted compiler than on the computing platform we've been talking about. My advice to you is to keep things as lean as possible so you won't be compiling until the heat death of the universe. You may wish to consider compiling very large packages (like LibreOffice) on larger systems with the trusted crossdev toolchain but smaller packages natively.
I'll say it again: If you're not using package management of some kind start before you compile anything other than the core. Seriously.
Some distributions offer the opportunity to compile software from scratch if you're not installing from pre-built binary packages. For example, Portage, which is the package management system of Gentoo Linux allows for the creation of binary packages after compilation that can be copied to like systems and installed, so you only have to compile once. The BSDs have the ports collection, which makes installing third party software (and dependencies) incredibly easy even though you're compiling from source. Along the lines is pkgsrc, which is very similar to the BSD ports collection but pkgsrc as a whole is intended to be portable across multiple OSes and platforms, including Linux. So, you could install pkgsrc to your newly installed (and very basic) trusted and open computer and compile stuff from it with the more-trusted compilation toolchain, and in addition to getting lots of very useful software you'll get package management included for free. I've worked with it a little bit in the past and there's a learning curve if you're used to installing packages from your distro's repository, but if you take the time to read the documentation you should be okay.
It takes time to compile any reasonably complex package, but the nice thing is that if you do it you'll only have to do it once because you can usually have OS or distro-native packages built at the same time that you can then copy to other machines of the same platform and running the same OS and install them. It's a much quicker prospect, to be sure. Or if you're trying to compile something as large as X or as elaborate as Metasploit, it is possible to install pkgsrc on a reference platform and cross-compile to our trusted platform with the trusted crossdev toolchain, which means that you could throw your eight-core 64-bit everyday machine at the task and have a set of installation packages in much less time.
Now, something that I've been wondering since I started writing this series. How long would it take a relatively small group of hackers to actually make this happen?
I'll be honest with you, I have no idea.
I'm going to highball it and say that the first couple of iterations of the open trusted computing platform would probably take experienced hackers weeks or months of work to get off the ground. Designing the hardware (or finding decent designs), sanity checking them, and building the hardware would probably take weeks. I'm not very good with electronics, my experience is barely what one would expect of a ham radio operator, so that's undoubtedly influencing my estimates. Finding the right components at a good price just takes legwork, though it might be necessary to set up a group buy to get good prices on some of the ICs. Good designs for hardware tend to propagate rapidly through communities, and as they're built and improved upon writeups tend to help less skilled hackers build their own. Certain aspects of the software compilation process could be scripted to speed things up, which would help with the software side of things. Moreover, this seems like the sort of thing that not a few hackerspaces would be likely to attempt, even if only as part of an ongoing computer architecture class.
Well, that's about all I've got. I've undoubtedly made some serious mistakes along the way and also probably outright said some dumb stuff. So it goes. This series of posts has been a learning experience for me almost from step zero. I don't think it's a fully fleshed out plan but I do think it makes most of a good skeleton for such a project. I would love to hear from people who know more about any aspect of this discussion; please leave any helpful insights or suggestions in the comments. I'll answer any questions as best I can (unless someone else gets to them first). At the very least I hope that this text inspires someone who wouldn't otherwise have done so to learn more about the lower level workings of computers and maybe try their hand at programming or electronics.
This work by The Doctor [412/724/301/703][ZS] is published under a Creative Commons By Attribution / Noncommercial / Share Alike v3.0 License.