BrumCon 07 – Thin Clients

The first afternoon talk was on thin clients. You remember those tiny Sun Java Boxes? Or other weird, little, expensive boxes with no disks, that just ran on the network? Those are thin clients. But they need not be overpriced. An ancient pentium can become a thin client. It’s recycling and with no disks, it’s pretty energy efficient. Ergo, this is a green use of tech. And anything that resurrects useless hardware into a tool is fucking cool.
I forgot to save the notes I took. Um, ok, so thin clients obviously depend on a server. They do something called a PXE boot, where they ask for their OS across the network via DHCP and TFTP. After they figure out what servers they needed, they do some more TFTP until they get an adequate OS running on a RAM disk. So the operating system and an X server are running locally. (The terms “client” and “Server” are reversed in X, which is annoying. The server serves the graphics. (Don’t think about this too hard.)
When you launch an application, like OpenOffice, or firefox, that runs on the server, but is displayed on the client. These apps don’t have a lot of extra overhead if more than one person is using them at a time. There could potentially be security issues, because every keystroke is being transmitted across the network. Part of what you want to do is make sure that nobody bad can get between you and the server. Therefore, it’s best to run wires rather than wifi. Also, you want the thin client to have access only to the server. The server can get to the internet, but the clients cannot. Finally, risk is mitigated through ssh tunneling, which is now standard in many thin clients.
Edubuntu, an ubuntu distro does thin clients out of the box and is an easy solution. This whole setup is really great for NGOs since a lot of the hardware is findable via freecycle. Every edubuntu release gets three years of security updates, so you can set this up and not have to upgrade the server for three years. I want to help put together an NGO-ready-to-go set, and I think this model makes a lot of sense.
I wish I hadn’t lost my notes . . .
You can also do slightly thicker clients, where some apps are sent across the network to run locally, on the client. This is related to my plan to get cheap multi-channel audio for installation. What I want to do is get a bunch of motherboards that all have on-board audio. I want to stick them in a box together, with a giant power supply, where one of them would have access to a disk and the others would not. The disk-enabled one would be the server. I would hookup a screen, mouse, keyboard etc to the server, because in this case the clients are providing only the audio. They would PXE boot from the server, but instead of loading and starting X, they would load and boot the SuperCollider audio server (now you can see how the X windows stuff got to be backwards). The server would load the SuperCollider language. It would access all the clients (aka SC servers) via OSC. It would tell them when to play and what to play, load SynthDefs and Buffers, etc. Every client motherboard in this scheme is 2 channels of audio. So three motherboards is 4 (or 6) channels. Four provide 6 (or 8) channels. Etc. Ideally, all this hardware would be free (as in beer). I think I’m going to wait until my lease is up to start combing freecycle in earnest. But it would be so brilliant being able to drag a free box into a gallery or something and have all open source and a load of speakers. It’s not the most gigable solution, but yeah, brilliant for installations.
Um, anyway, if you want to get rid of p400 or better motherboards with on-board audio, drop me a line. I’ve got £0 budget, but I will generate a howto, so think of it as giving something to the FOSS community.