Just realised I haven't written anything here for a while, which is remiss of me. I seem to have talked quite a bit previously about the virtualisation setup I'm using at work, so I figure I'd better do a quick update. Right, first thing: it works! I have proof! Our main file server's power supply went "Fzzzt!" and made a big green flash and (I'm assured) a nasty smell on Thursday, stopping our server working. It also managed to fuse the plug connected to the UPS. So, that's our main file server out of action in a way that implies it'll need to be taken apart and have melted bits and bobs removed, ordered and replaced over the course of a week or so. Not good. Not to worry, though! All our servers are running as virtual machines, and all those virtual machines are being mirrored between separate bits of physical hardware, i.e. we have two machines with a copy of each virtual machine on. So, all we had to do to get the file server back online was to start the virtual machine up on the physical server that was still running. Well, actually, we had to sort that fused plug and UPS out first, but the whole thing still took under half an hour.
This quick turn-around was enabled by DRBD, a Linux kernel module that allows you to mirror a block device over an ethernet connection to another machine. This is the nice thing about Linux, the way its various sub-system tend to work as "stacks" of protocols. There's the network stack, obviously, that's the one that everyone's used to thinking of. But there's the "disk protocol stack" too that allows you to swap bits in and out as you like to accomplish what you need. We now have a disk stack with physical disks at the bottom, then software RAID (mdadm) on top of that to provide some resilience to harddrive failure and some performance gains, then Linux Logical Volume Management to allow for easy partitioning and resizing of disk space and, importantly, snap-shot backups of volumes, then DRBD on top of that to mirror volumes between physical machines to provide more resilience to hardware failure. We might slot in some encryption there, too, over the summer break to keep our important data safe, probably using dm-crypt.
The above setup means that your machines need to be able to communicate with each for DRBD to be able to do its thing, which proved to be much simpler if each server had a fixed IP address, so the previously discussed setup where each physical machine simply appeared on the network and reported to a central server hasn't quite come about. No worries, I can now get a server up and ready to run virtual machines in a couple of hours flat. That's the other thing - we've now moved to CentOS 5.1, as Xen on Ubuntu 8.04 simply kept on crashing.
But wait - aren't you meant to use a fancy (and costly) SAN setup for ensuring virtual machine up-time? Well, maybe, but I don't think think so in our situation, and I think our situation holds for many others, too. We're a school, not a business as such, and we don't have stacks of money to spend on IT equipment - we spend money on people, teachers, not equipment. A single SAN device would allow us fail-over if a processing machine went down, i.e. if one of your processing servers conks out you simply switch its virtual machines to another one and carry right on. However, this doesn't cover you for failure of the SAN server itself - a power supply blow-out, for instance. So you wind up wanting to have two SAN devices, mirroring between them, and you want those in separate physical locations in case of fire/flood/etc, and all this necessitates a fancy (and definitely costly) networking setup between said separated physical locations, probably involving fibre channel connections. And all, when you think about it, for the privilege of being able to have a loose coupling between your processor(s) and harddrives. That's all a SAN actually provides, generally at the expense of some performance over what you could get with a processor local to a decent RAID 1 controller and a stack of harddrives. And look at today's processor and memory prices and a typical machine's actual processor usage. In our school, most of our servers' jobs are basically file serving, there's hardly any actual processing to be done. Shifting files around and squirting them down network connections hardly takes up a processor's time much these days, especially one of your fancy quad-core jobbies. So, basically, a decent quad-core processor (or two) and, say, 8GB of RAM isn't going to set you back more than around £500 these days, and would easily handle the processing requirements of half a dozen virtual file servers. No need to bother spending stacks of money de-coupling the processor and harddrives, just spend the money on a really decent RAID controller.
My day job involves managing a bunch of servers. I don't really want to be fiddling around making sure bits of hardware are working okay as I figure I could be doing something more interesting and worthwhile - I want to get around to actually getting some stuff done (that blasted email server, for one...). Hence I'm thinking of ways to make the whole hardware management thing easier (after I get the email server sorted, obviously). So, I'm sitting there thinking, and looking back over my thought-process I can see how many people must have thought of this before: instead of running the servers we need (email, web servers, database, MIS, Wiki, etc) on physical servers, virtualise those servers and run the services we need on top of a bunch of identical virtual machines. That way, if something conks out we can shift it somewhere else and continue running it.
Great! So I slap together a bunch of machines out of whatever bits I can find lying around the place, stuff them into a cupboard and painstakingly install FreeBuntu and compile Xen on each of them, then create a bunch of virtual machines on each server. This works. However, it's not that reliable and still somewhat fiddly (in fact, probably more fiddly as now I have another layer of abstraction to deal with). Hold on! Why don't I automate that layer of abstraction - create a CD/USB bootable Linux distribution that'll run Xen. Something minimal, no GUI needed, maybe the excellent Slax or similar. Then all I have to do is write a bit of script that looks at the hardware available to it on startup (number of disks, number of processors, etc), checks to see if there's any Xen VMs floating around for it to run, then reports to a central server. USB is probably best - have a config file in the root folder that you can edit on Windows to give it IP address of the server to talk to, maybe stuff like its own IP address and how to manage disks (does it assume the available volumes are already hardware-RAIDed, or does it run software RAID over them?).
Yay! Instant utility computing from random bits of commodity hardware. I've even got my eye on some bits of hardware to buy - I've got one of these turning up from eBay for my home server soon. I figure an internal version of that RAID box, a small 2-slot mini-itx case from the same company, a quad-core mini-itx motherboard and 2GB+ of RAM, couple of SATA-300 harddrives and a USB stick should make a nice little computing unit. Stuff a couple of dozen in a rack with UPS and a decent switch and air-conditioning and you've got a virtual supercomputer of sorts.
But hang on... this has all been done before! I've just come accross the Amazon Elastic Computing Cloud, which does this exact thing but lets me pay for it 10 US cents at a time. Only problem is that it's away On The Internet someplace - not really where we want it for fast local access. So how do I make my own Amazon-compatible elastic compute cloud - something that I can manage, and maybe swap machine images in and out of between Amazon's service?
A remarkable number of people would have you belive that computer programming is something that is difficult, something that takes hours of training, a degree, and is only for the smarter sort of person. Then the software industry criticises our education system for not turning out people who know how to program computers. I both completly agree and disagree with their sentiment.
Let's seperate "computer programming" and "software egineering". "Computer programming" is dead easy. No, really. The whole of "computer programming" can be summed up as "know what a function is". You can write any computer program from that (you can - there's mathematical proofs and everything). Computer programming is a basic thinking skill, like knowing how to do division or how to draw a mind map. Computer programming is the skill of being able to specify an algorythm that describes a problem that you want to solve. You don't even have to be good at maths to do computer programming. Every schoolchild should learn computer programming, not as a part of "ICT skills", but just as another tool they'll have available to help them figure stuff out.
Software egineering, on the other hand, is the somewhat tricky stuff. It's the stuff you go and spend a three year degree learning about, and then half a decade getting decent experience at. Software egineering is the often dull and tedious process of providing computer programs that solve other people's problems. It requires you know a bunch of stuff about how comnputer programs operate, some mathematics, development methodologies, common tools and APIs. You get practiced at debugging, and "experience" basically means you know a heap of APIs and tools, and you know which methodologies actually work for you.
Every child needs a basic idea of computer programming. Someone going on to do software egineering at degree level needs a really good idea of computer programming - they need to really have the idea of just how easy and simple computer programming is, and know that it's an incedental part of what software egineering is about.
The last thing such a student needs, though, is an A-level in ICT. It'll bore them rigid, and won't teach them anything useful. A-level ICT is for people who are likely to go on to do a degree in anything but computing, and who are likely to at some point after that to be working with IT staff - either helping to specify problems to be solved with computer programs, or as managers. To be honest, an entire A-level is probably overdoing it - an AS-level should be enough to give them the idea, leaving time over for something more interesting.
The new AS-level syllabuses seem to have exactly this idea. There's no coursework involved in the AS part of the new A-level ICT syllabus, instead you do several shorter in-class projects which you then take into the exam with you to refer to. This would seem to be pitched at the kind of people who'll find it handy to know what's involved in ICT, but who'll actually being doing something else.
"I have just seen some schematics looking at floorspace in our BSF school. What was interesting was the fact that there are no ICT rooms planned; according to the consulting architects ICT rooms are old-hat, relics of a bygone era..."
This post attracted several replies, and then seemingly got picked up by some reporter asking around. So, my take on the matter: I think I can see both sides of the argument here. From a teaching point of view, ICT suites are generally horrible places. Overcrowded (there's never quite enough of the expensive, bulky machines to go around, some are always out of order), stuffy (unless you install expensive air conditioning), noisy (PC fans and harddrives whizzing away), scruffy (printer paper littering the place), pupils have large monitors to lurk behind, etc, etc. Ideally, you would have a normal classroom in which computers could simply appear and disappear as needed - this generally means either laptops (expensive) or hinged desks with flat screens embedded in them (even more expensive). Having computers available on demand in the classroom (ICT "embedded in the curriculum" is the phrase used by those in the know) makes for a far better teaching experience - no more traipsing your class down to The Computer Room to wrestle with systems that you're unfamiliar with because you don't get to use them enough.
But from a network management point of view, ICT suites are seen as good - machines can be chained to desks to stop thefts, alarms can be installed, you have mains power instead of batteries, reliable wired networking instead of wireless, machines are grouped and it's easier to manage what software is installed on them, big ugly machines are cheaper and more robust than ultra-slim laptops, etc, etc. Laptops can be stolen, broken, and batteries wear out over time.
Okay, so there's the two sides of the problem, so how to best provide ICT access?
You could fix desks to the floor, letting you run power and networking to each one. This is going to get pricey unless you can do this kind of thing yourself. It also means you can't move the desks. This is a problem in, say, English classrooms where drama is sometimes done, or if you just feel like moving the tables around. However, science classrooms generally have fixed benches, and seem to manage okay.
You could fix computers to the wall. Screens these days are flat, and only take a couple of centimeters of room space if nailed flat to a wall. A fold-up cover/keyboard and mouse table isn't too difficult to imagine - just a hinged bit of wood with a keyboard glued to the top. All wiring can be tucked away in some stick-on wall conduit. Problem: unless you have large classrooms / small classes, you won't be able to fit enough computers in to cover a one-to-one usage ratio. It should defiantly, help, though.
Build a better laptop. Ah ha. This is where the OLPC comes in. Who knows whether it'll be any use in Africa / Asia, but it sure looks perfect for UK classrooms. Low power consumption, robust design, decent wireless networking (er, hopefully - some reports are a little disparaging) - well on its way to looking like the BBC Microcomputer of the modern age.
Use second-hand laptops. Cheap. Doesn't matter (too much) if you drop a few. You can "retro-fit" a standard school desk with an under-desk tray to slide a laptop into. You'll need to supply mains power to all machines - you can assume all the batteries will be worn and will have different models of power supply. Wired networking would also be a good idea. Under-powered processor problems can be solved by using the machines as thin clients - keep the server in the classroom, as the teacher's computer (nice fast local networking, plus the teacher can view pupil screens).
The best solution would seem (as is so often the case) to be a combination of the two approaches. In classrooms where you don't need to move the desks around a whole lot, provide power and network to each desk and use a cheap laptop as a thin client to a local server.
So, MetaPlace. Neat sounding idea - some kind of web-based system/toolkit/API for creating massivly-multiplayer games. The website itself is rather short on technical details, though. This is particularly annoying as this sounds exactly like what I want - a system to create a multiplayer-game for children to play. I want something that emphasises cooperation and puzzle-solving rather than dodging enemies and shooting things - nothing wrong with those sorts of games, but not really appropriate for a school. I was thinking of something web-based, maybe Flash or maybe DHTML, with minimal graphics (easier to draw, easier to program, and easier to view on OLPC screen), mouse controlled (point-and-click on the screen to tell your character to do an action at a particular location). The advantage would be that game logic would be computationally deterministic, you'd only have to send x,y coordinates back to the server ("user a did action b with object c at screen location x,y"), making for very low bandwidth needs.
The laptop: designed for (Western) Business Users. Business Users: well-presented types who work in offices. They sit in office chairs, send each other inter-office memos and use office productivity software to do productive stuff like make presentations to help each other drift off to sleep. They aren't children. Children have different needs from a laptop. They need it to be robust, easy to use, and if someone asks them to do tedious stuff with it they have a right (because they're children) to get bored and do something else with it.
Unfortunately, pretty much every laptop in the world, ever, has been designed with the western business user in mind. The one exception that I know of is the XO Laptop, from the One Laptop Per Child programe. Follow the link there, take a look at it. See how it's put together, and the software that's designed to go with it. Now take a look at the contrasting Intel Classmate PC. Look at the differences between the two.
The Intel machine is still designed with Business Users in mind. It's a cut-down laptop PC, with a bunch of standard laptop I/O ports on the back. And look at the way is presented and marketed. It's a sub-project from Intel, brought into being because their marketing department calculated it should be. Software Vendors - big, important Business Users clever enough to be able to write Programs - are the people who will be providing software for it.
Compare this with the XO. It's a machine designed to do exactly what it's supposed to - be robust, usable in places with no mains power, easy to use. And program. That's the biggest, bestest thing about it - whoever wants to can write software for it.
People have criticised the XO as being too much like an under-powered "gadget", unsuitable for real tasks like writing inter-office memos and presentations. You can see the thinking - given these devices, how are children the world over ever going to grow up into proper Business Users? The general idea has also come in for such criticism as "who will maintain the computers one distributed?". Maybe the people using them?
The new changes to the national curriculum sound like a good idea - proscribe less, allow teachers more flexibility. Just the ticket. I hope, though, that the teach-children-about-climate-change bit doesn't get too superficial. The 11-14 curriculum should still be about education, not training. The idea should still be to teach them the basic science of the matter first and leave them to figure out the details themselves. Constantly telling children "carbon is bad!" isn't going to give them much by way of an understanding. Same goes for the teach-children-about-mortgages idea - teach them about percentages and compound interest, how to use a spreadsheet. Mortgages are simple after that - a mental image comes to mind of a generation of savvy borrowers turning up at the bank, laptop in hand, saying to the mortgage broker - "About this variable rate that you reckon will save us money. Prove it.".
The tallest order, however, is going to be getting past the tits-and-bums aspect of the British sense of humour. Cows produce methane. Yes, we're talking about cows farting. YOU AT THE BACK! Stop giggling, this is serious - your average cow has the same daily greenhouse gas output as a 4X4 doing the school run. YES, I said fart, stop gig... oh, forget it...
I'm currently employed as a network administrator at a school, looking after bits of computer hardware. This isn't my real area of expertise - I'm a computer programmer, I want all the grotty hardware stuff (and believe me, in schools some of the hardware truly does get pretty grotty...) to be abstracted away so I can get on with the fun programming stuff. And now I've found the perfect solution - server virtualisation. Yay! Hardware administration for software people! Your physical servers all become simple application servers with one function: to provide a platform for virtual servers. You then go about setting up virtual server for whatever you want. The general idea seems to be to set up a seperate server for each function on your network - so a seperate server for DNS, LDAP, gateway, database, etc. The fun part is when you get things set up so you can migrate virtual servers around physical hardware - move, say, your DNS server from one machine to another without any downtime.
The first task is, of course, to pick a virtualisation system to use. After a days investigating, I've decided to have a go at using Xen. It's open source, so it looks like I'll be able to deploy it system-wide at no cost. It's performance is good - I saw one claim that virtualisation processor overhead is around 3%. However, the technique it uses to achive this performance means that it has to run specially modified operating systems - i.e. Open Source ones only. That is, however, unless you have a processor that supports virtualisation in hardware, then you can run (seemingly) Windows XP / Server 2003. We don't happen to have a server with such a processor yet, but eBay has them at around £250 for a motherboard with processor and 4GB of RAM.
Seemingly, to make sure we can use the snazzy live virtual server relocation system, I'll also need to make storage available as iSCISI devices - SCISI over IP, i.e. SCISI over a network. Looks like there's going to be a bit of a learning curve ahead...
The Reaction Time widget now supports visual and audio stimulus from the one interface and random display of a number of stimuli - you can now select all four stimuli and the computer will pick a different one at random each go.
Still to do: translate the text into other languages (all text strings have been arranged so this is possible), make this into a Moodle module and integrate results into Moodle's database, sort out the horrible mangled mess of code that this has become (see the zip file if you don't believe me)...
Recent news suggests that take-away coursework is going to be ditched in favour of coursework done at school, in lessons. This is to stop pupils cheating by simply downloading coursework from websites.
It strikes me that we might as well go ahead and ditch coursework altogether and reply entirely on exams. No, seriously - here's the idea: the above solution won't stop people being able to cheat. They'll be able to download material from the web just as easily at school as at home (no, blocking websites won't help much - children will simply email themselves material from home). Teachers can't monitor every child every moment, and if they can't spot copied coursework already (although I might suggest that most teachers will be able to spot a suspiciously well-worded piece of work from a less-than-steller pupil a mile off) then they're not going to be able to in an hour's coursework lesson split between 30 pupils.
Better to split each course into half-termly modules and have an exam at the end of each one. No big exam at the end of the year - do completly away with the whole panic at the start of summer as people revise for exams. This should allow for much more flexible courses - if a pupil muffs up a module they can retake it next half term. If a pupil is bright enough to take the module exam without the tedium of having to do the lessons, let them and then they can move on to the advanced module.
You could even have modules count for more than one qualification - have modules that earn you 1/12th of a GCSE in maths and physics, for instance.
I'm fortunate in actually having had some experience of this kind of teaching as a pupil at school. I was one of the first years to do AS-levels, back when people didn't quite seem to know what to do with this new qualification they'd just invented and mostly saw them as "extra" qualifications. Hence the curriculum of our AS further maths course seemed to be pretty much made up as we went along, with the course split into modules (including "coursework" modules) that we were examined on at the end of each term or so. No panic or fuss was involved in any of these exams, and they mostly turned into a friendly competition to see who could get nearest to 100%.