The key to learning (and teaching) Programming

The subject's come up many a time in my life about how people program computers. A lot of the time it's seen as a mystical art and some lay-people even confuse "programming" with "operating a computer", or even just "changing some settings".

The question always comes up about how to "learn programming". Besides the obvious problem with the wording of that phrase, it seems that people still haven't found an effective way to teach children how to program computers properly... and more and more teachers are skipping every bit of the subject that they can. My interest was caught by this subject again recently by a story on BBC News and by a subsequent appearance of the same story on Slashdot concerning a graphical programming language specifically aimed at younger children.

Programming is quite a strange discipline. It is the laying down of logical, unbreakable rules and actions to arrive at a predictable and reliable answer. However, it also requires, more often than not, ingenuity and creativity in order to achieve those aims. In some respects, it is similar to the cutting-edge of mathematical research (and, in fact, mathematics is probably the most complementary subject to computer programming, with the possible exception of electronic circuit design).

The problem with teaching programming is not that children cannot be brought to understand the subject, or even that the tools aren't available for them... most children of an age where they can comprehend what programming is are capable of actually programming. The problem is, in fact, the established complexity of the systems that they use each day and the over-simplification of their given tools. Additionally, the fast change of consensus on a "suitable" language stifles the teaching of programming, when in fact every programming language proposed has problems whether they be from an over-simplification of programming or a steep learning curve.

Also, the program which dumbs down programming to the point where children can "understand it" is probably one of the more complex programs to write. The abstraction required to allow a child to just drag-and-drop items into a graphical interface and thereby create a set of instructions for the computer to follow relies on decades of other people's code in order to display itself, allow the child to manipulate the mouse, and do so in a high-performance manner on a modern machine.

This is, in some way, similar to mathematics again... we all get told that it's pi-r-squared but finding out WHY takes more advanced mathematics to discover. Unfortunately, the modern consensus is that we have to assume that "it just is" for several years before we can get to the stage where we can work out exactly why. This doesn't present a problem in teaching, however, as almost all teaching comes from the concept of "good enough for now" or "lies for kids".

Teachers are also drawn into the same trap that stops children from being able to grasp programming: You can teach children for-loops and variables to your heart's content... the fact is that they will not be able to effectively link those concepts with the word-processor that loads in a fraction of a second with a thousand different features or their favourite 3D game that simulates realistic physics without a complete understanding of some quite complex mathematical principles. Most teachers, if pressed, will happily explain that "it all gets turned into 1's and 0's" (thereby introducing even more questions about how 1's and 0's can look like Mario running across a platform in time to their controller movements) but few can explain to a child's satisfaction just how it does that.

And when the children attempt to reproduce that 3D game in BASIC or Logo, they will be sadly disappointed that the best they can manage is a few hundred lines of code to make some circles appear at random locations on the screen (but it would only be pseudo-random, which is based on polynomial iteration, which requires advanced mathematics... and the circles would be only grid-based representations of the formula for the graph of a circle, which requires trigonometry to grasp completely... the traps are always there). Yes, there are such things as Dark BASIC, but again we're just abstracting away absolutely everything into a black box that "just works", rather than letting the children find out for themselves in due course.

That's not to say that there isn't some effort being put into teaching children programming, or even that that effort is failing. There are some very effective tools to demonstrate programming in a context where even the youngest child can interact and play with a system that they can understand. The best example would probably be the Lego Mindstorms kits - some building blocks and motors can be turned into anything once a child has learned how to make the control blocks do what he wants them to do. A common first foray into the programming world for many primary school children today is a Lego Mindstorms kit that they first build and then program to achieve an aim - whether it be controlling the traffic lights at a busy "junction" or raising and lowering a gate on a railway crossing.

Unfortunately, some of the Lego software is abysmal to understand on first glance, even for a seasoned programmer. Clunky interfaces, unintuitive icons and "settings" and an extremely limited instruction set, all of which are supposed to help the child understand.

When all you have to work with is "Output X on", "Output X off", "Wait X seconds", "Wait for input X to reach Y" arranged in blocks where the syntax is horribly restrictive and forces you (from a logical and interface point of view) to do things such as "wait for input NONE to reach NONE" on dozens on instructions where it would just be more intuitive to introduce some concept of our old friend IF instead, programming starts to lose its fun.

Rather than forcing the logical equivalent of null IF statements onto every line of code, a much better idea would be to merely teach the children how to program the old fashioned way - groups of english-like instructions, executed strictly in order. Unfortunately, the languages of today all have syntaxes which require pixel-perfect placement of semicolons, parentheses and quotation marks in order to write even a simple Hello World program. And although there are ways and means around that (such as seriously relaxing the syntax), people seem to have the idea that having to use WORDS is somehow dirty, when it comes to programming.

As a youngster, I was only ever officially taught (in this order) Logo, BBC BASIC and Java. Bearing in mind that the first was in infant school (early 80's) and the last on my degree course (early 00's), that's a huge and slow gap to a programming language of practical use (i.e. one that I would have available at home, one that I could make useful programs in that I could use each day, one that I would be able to swap, create and share programs with other people). It was only by my own experimentation that I was able to learn other languages myself and I was programming competently in the last two of those languages before my teachers even mentioned them. For my A-level's, I actually taught my own classmates for several lessons because the teacher believed I could do a better job than he, having been programming in the course language longer than he had been programming.

Logo provided graphical (or physical) response, but all code was textual. BBC BASIC *could* be graphical but was mainly textual and all code was textual. Java, again, *could* be graphical but all code was, again, textual. However, a lot of modern-concept educational programming revolves on getting away from actual words (the Lego Mindstorms "language" being a perfect example). Textual code is not something to be scared of. In fact, in other subjects, we treat textual lists of instructions as vital. And isn't that, when you get down to it, all a computer program is? We need to bring back the old-fashioned text languages, without the historical baggage of text-mode editors, strange delimiters and line terminators.

To clarify, I'm not seriously suggesting that learning C++ at a young age would have helped me or any child. That's a ludicrous assumption, similar to saying that being taught quantum mechanics as a child would help me understand Newtonian physics - of course it would but the complexities of teaching at (and learning at) that sort of level would far outweigh the benefits of such an education. My own teachers struggled with every language I had to be taught, until I hit university. There's no way on Earth that we could expect teachers to teach at the levels required in order to allow that to happen, at least not in the forseeable future.

What's needed is not a *primarily* graphical system. What's needed is a way to easily construct lists of plain-English instructions without needing to worry about perfect spelling, excellent grammar (the absence of which is, in programming, a vital learning experience) and lots of typing. Drag-and-drop keywords are a good start.

The language itself, however, needs to be less strict or, at a minimum, not allow beginners to make most of the classic mistakes. You can't mispell a dragged-and-dropped keyword and with proper graphical interfaces you are able to show scope, loops etc. effectively without having to worry how many invisible tabs you have inserted on the left of the screen.

Data-types, although important, do not need to be set in stone. Children SHOULD learn the difference between a string and an integer variable as it is of critical importance at each stage of programming. Visual Basic's "Variant" does an excellent job of masquerading as multiple types simultaneously but introduces new problems in itself because certain distinctions are not made. However, a simple indicator of Constant vs Variable, String vs Number, should always be included.

The programmer should also be responsible for creating the variables that they are going to use. Variable scope is vital knowledge. If this means clicking a new button and selecting a type, be it "Number" or "Animated 3D Penguin Character", the kids should be the ones who create him, the ones that drag him in each time he's needed and the ones who (critically) should remove him from the project if he's no longer necessary. This means not only in whatever GUI the programming language is set in but into the actual program itself. They should insert the Animated 3D Penguin not only into the project but also into the correct parts of the program to "create" and "destroy" him at the right times.

[[ On a side note: They should also be able to name him whatever they like first... they are kids after all. In fact, he shouldn't be able to be created without being given an assigned name by the programmer. No "Animated 3D Penguin Character #1" etc. ]]

Ideally, his birth and death should be graphical each time the program is run. This will teach correct construction/destruction techniques (because Pingu just popping into the screen half-way through the game isn't good but creating him at the start and just keeping him off-screen until needed is a good way to learn - similarly this will also show the brighter kids that you don't need to create everything at the start and slow the whole system down, if you manage the entrance and exit of data effectively).

Abstraction of complex functions, e.g. 3D libraries etc. also help the programming become interesting much more quickly (I can remember the wow-factor of my first coloured circle on a black background but children today would hardly be impressed with that). However, many of these can, in fact, be expressed in the language itself (albeit complexly).

Most importantly, a language should be complete and self-hosting... that is that each part of it should be capable of being written in itself. The beginners will wonder how this is possible but this is true for almost all programming languages. Except, strangely, the educational ones. By hiding the complexity within the language itself, you strip away the hard work into black boxes.

For instance, the "Create a new penguin called Bob" instruction should not be the end of the matter. You should be able to drill down. That instruction should have the capability to be broken into several hundred parts, each of more complex and primitive instructions, but all in the same "language". The hidden properties of him should be there somewhere... accessible to the more advanced children who want to do something that the basic levels of the languages don't allow.

A multi-tiered GUI is the perfect way of doing this. On startup, you have your "Penguin Bob" buttons but if you "break" them, they split into the code that creates Penguin Bob, in a simple-enough set of further instructions. And you can break them multiple times, into ever-more-complex code until you hit some equivalent of assembly language... most probably some sort of sandboxed, interpreted code similar to Java. Why? Because this is how ALL code works... the BASIC interpreter is probably written in C. The C code would be executed as machine code. Everything is based on an more complex underlying level. And as an extra added bonus, this means that the language that kids learn in Year 5 to make Penguin Bob run across the screen and giggle is still the same language when they hit Year 11, 12 or 13 and have to submit an independently produced program of a highly complex nature (for instance, their own word-processor).

It doesn't have to be fast... in fact it SHOULDN'T be, for the basic levels. This teaches the users quickly that unnecessarily looping ten thousand times over a hundred lines of code is bad practice. And when they grow up and are able to break the code down to it's components they will not only see WHY but be able to generate a much more efficient code that is functionally equivalent.

With widespread use, it would also encourage the greatest principle in programming that has been present since the first line of BASIC hit our eyes... collaboration. Libraries of code. Open source. Those BASIC listings in ancient computer magazines. All of them were about collaboration and sharing of code. Imagine if your GCSE project in Year 11 was to create a documented, stable, fast set of replacement functions that the kids in Year 7 would use to make Penguin Bob do a somersualt.

There also needs to be real, physical feedback. A coloured square on a screen means nothing anymore - especially when it takes £2000 or computer to do it, from a child's perspective. Logo (and some of its later clones, such as RoamerWorld) knew this... many a British child grew up by slamming a glass-domed turtle into the teacher's ankles. Lego Mindstorms spotted this. To incite enthusiasm for programming, there needs to be a response... not just from a computer screen. Things such as PIC-chips and simple robotic circuits make this a breeze.

And, with something along the lines of RoboWar, where students could compete in a school-wide championship to generate the "best" robot by programming him, you could involve the whole school. In one fell swoop, you could have programming on multiple levels (from all levels of AI to sandboxing), electronics, control, communication and design (by applying the "Robot Wars" principle to a full-scale, physical version of each robot), competition and publicity.

Each educational language seems to have one or two brilliant ideas and then to fall flat on it's face in all other aspects. Considering the computers are ever-more complex, ever-more prevalent and are not going to be going anywhere in the foreeseable future, our children should have an understanding of exactly the principles that underly them.

They will learn WHY computers cannot be trusted to run the world without an awful lot of testing (because of the absence of "intelligent" computers so often seen in Hollywood), they will have the ability to not have to rely on multinational companies to write a simple letter. ICT is already compulsory in many aspects in almost every school lesson, and it creeps into our lives more and more each day. Unfortunately, nobody is being educated how to make all this technology do our bidding, instead relying on a few good people to do everything for us.

Retro-gaming value for money

Take one old PC (considered obsolete by its previous owner and consigned to the scrapheap), add a lashing of a spare operating system (Linux is fine but, in all honesty, Windows is easier for this project). Mix in some random game controllers chosen by lucky dip into your "parts" box (anything from an expensive Playstation joypad with a USB adaptor through to an old two-button gameport joystick is fine). Add a dash of emulators for older games systems that you knew and loved. Sprinkle with a hefty swig of configuration, plugging in and cursing. Decorate with a lashing of ROM downloads of games that you still currently own but can't be bothered to play because the setting up of the games console that runs them takes longer than completing the game.

Finally, download lots of popular freeware games, give them a try-out, then have a retro/freeware-games party with anyone that has a favourite old game they haven't played in years. A TV-out capable card will help matters immensely, allowing you to play them on the telly in the front room, just like the old days. If not, a nice monitor will do just fine. Or for those lucky enough to have a projector, this would be the best way to keep a room full of big-kids happy.

Seriously. I've just done the above with my own ingredients... a 1GHz PC with 512 MB RAM (although you could probably get away with even less). I slapped a spare copy of Windows XP Home on it (I always end up with a little collection of Windows XP licenses from the various computers that I repair or, if they are beyond repair, recycle). I "upgraded" the onboard graphics to an ancient and obsolete AGP 4x card because I wanted TV-Out (the less said about that the better - old TV's that can't display the refresh rates you want without flickering can ruin hours of careful planning and playing with settings).

I threw in a spare 4-port USB card and as many reliable games controllers as I could find. A cheap cable to connect the sound through the television, a few extender cables for the various controllers (because in the heat of a gaming party someone WILL tug on them) and a cordless keyboard/mouse set to control the system from the living room sofa. A little utility called Joy2Key also came to the rescue, especially if you do what I did - I made a tiny Visual Basic util to turn the machine into a primitive "who pressed first" quiz buzzer - more on that later.

The emulators available to such an "obsolete" machine cross all sorts of systems (but only those ones that I ever played on or still have... I have somewhere a CD with Commodore 64 emulators and ROM's but I don't think I've ever even loaded it because I never used to have that particular piece of gaming history, so I have no interest in seeing the games it used to play.) Currently, my particular setup has (in order of age), ZX Spectrum, Sega Master System, Nintendo Gameboy, Sega GameGear, Philips CD-I, Sega Megadrive, Super Nintendo and Nintendo 64 emulators, all of which have several popular games (everything from the previously mentioned JetPac through to Super Mario 64) loaded and ready to play, full screen, full speed, on this old relic of a PC. Anything of the Nintendo 64-era or less is fully playable on such a machine, given the right emulators, and more powerful machines will laugh at them.

It even has DOSBox running several old DOS games that I've only just consigned to the "cupboard of slow, ageing death" where games live that are no longer easy enough to play on modern systems but which I still have a fond memory for (Syndicate, Cannon Fodder, Command & Conquer, Settlers etc.)

And it plays them all fantastically. The foresight of using my best two games controllers (a USB PC joypad made to duplicate a Playstation Analog Dual Shock and an actual Dual Shock with a Playstation -> USB convertor) even allows precise analog control of Mario in Mario 64, or while driving in Mario Kart. And with a press of a button and a change of emulator, it's suddenly a Kempston joystick in a ZX Spectrum.

It's been great to play all the classics. JetPac just isn't JetPac unless it's played on a TV and is emulated so accurately that all it's little palette flickers happen just right. And Target Renegade is still a fantastic game for picking up for only a few minutes for a quick bash. Super Mario 3's Battle Game (the version from the SNES remake) is a great party game.

So every game I've ever owned on a games console is now sitting on one easy-to-manage, quick-to-boot, no-fiddling-with-TV-tuning PC with gamepads enough for a four player battle in any emulated system that supported it. When I originally had this system set up, it was on an equivalent laptop and that was even more fun... there's nothing better than being able to whip out your laptop at someone's house and launch into four-player frenzied gaming of some of the classics.

And I also loaded this PC up with some other games that I had lying around or had downloaded previously...

- Slicks 'n' Slides
An old DOS racing game that I was a registered user of, way back when. With a utility like Joy2Key, you can play four-player with ease (beats having to cram four of us around a single keyboard like we did when we used to play this in Maths lessons in school!).

- XQuest 2
A marvellous freeware game that requires precision control of the mouse

- SCUMMVM
An emulator for various point-and-click adventure games, which comes with Beneath A Steel Sky as a freeware game

- OpenTTD
A remake of the classic Transport Tycoon Deluxe

- Abuse-SDL
The dark and fantastic Abuse from Crack dot Com.

- Rocks 'n' Diamonds
Another remake, this time of Rockman.

- PySolitaire
A card-game to wipe the floor with all the rest (but you can still add Solitaire and Hearts to your PC "console" if you want) - hundreds of customisable card games in one program.

- Liquid Wars
A brilliantly original game, part strategy, part fast reactions.

- Battle Painters
A wonderful game to leave the kiddies with - each player has to paint as much of the screen as possible before the timer runs out. I use Joy2Key on this as well, for the same reason as Slicks 'n' Slides, though this is a Windows game.

- Super Mario War
The best Christmas present I ever gave my mum - she is a massive Mario Battle Game fan and this gave us a night full of entertainment. Mario-themed but the number of games alone is enough to keep the most ardent Mario-hater busy. And such four-player mayhem is incomparable.

Not to mention TuxRacer, Pingus, Gate 88 and all those other great freeware or open-source games.

It's the best games console I've ever had. I even ended up naming the PC "CONSOLE" in it's configuration. It doesn't have network or anything else set up - it was worth sacrificing an old PC for and, as far as I'm concerned, the best use of a Windows XP license ever.

I turn it on. Within about 30 seconds it's in Windows (no net = no need for lots of utilities / services that slow it down) and ready to play. That 30 seconds would be taken up by switching to the right SCART socket, untangling the joypads etc. anyway, so you don't even notice it. Then, when you're in, you can play some old ZX Spectrum game while you wait for your loved one to settle down with a controller that they don't mind using, then you can both have a blast on Mario Kart 64 or play some silly freeware game without having to switch machines. When she goes to bed, you can load up a bit of Syndicate or finish off that Red Alert campaign.

You can have "Mario nights"... Start with the original NES versions, then do the Gameboy ones, working your way up to Mario 64 and filling in the time with some Battle Games, a quick blast of Mario Kart or a four-way battle in Super Mario War. And when anyone comes over and says "Do you remember ?", you can just load it up and play it.

It's great and it's the best investment of time I've ever put into a Windows system. I was going to download one of these menu systems that they have for multi-emulator setups but they were all pants and I found that a desktop folder called Games with a shortcut for each machine type is more than good enough. When you have a lot of games on the system, you would spend longer setting up a menu system and then selecting them than you would just loading up an emulator and typing in the name anyway. You can assign shortcut keys to each shortcut and, if you want, use something like Joy2Key to load up particular ones from the joypad!

Joy2Key is a bit of a fiddle but it's only really necessary for comfort on old games or emulators that can't reassign keys to joypads easily. Do it right and you have the "best" joypad be the controller - the one that can pause, open games, exit emulators etc. by pressing the right buttons on it. Or you can just delegate the keyboard to someone who knows the shortcut keys for each emulator.

I found that the Playstation-style joypad controllers were the best to use. Enough buttons for almost any game system (with a few spare for vital functions like Pause etc.), digital and analog controls, cheap, comfortable, easy to get hold of and easy to find adaptors for (in the UK, Game sell them in all their shops). They're also especially close to the original SNES controllers that I end up playing more than other types of games.

The most time-consuming bits were:

- Making it boot fast
Don't install anything that you don't need to (networks etc. included). Clear out all your startup entries. Set all BIOS options etc. to be as quick as possible. Make your desktop as plain as possible and completely empty your system tray. Make sure everything is plugged in each time you use it. You don't care that the system looks ugly, but if it jerks in the middle of a four-player game you'll be regretting putting that large theme on your desktop.

- TV-Out
My own fault really, because I was trying to use what I had to hand. Only when I was several days into getting it to work did I realise that all my problems stemmed from a television that just wouldn't support non-standard refresh rates at all, not even by the slightest degree, but didn't moan about them. I have an external D-Sub -> SCART convertor that just wasn't up to the job of changing refresh rates without having MASSIVE jerkiness (single screen games worked fine but anything that scrolled horizontally or, worse, vertically looked absolutely crap).

So I tried a video card with TV-Out which was perfectly smooth at doing that job, but which had BIG problems with colour display on my TV. Turns out that the old TV just doesn't support colour over a S-Video connector, even if it's connected via SCART. That wasted HOURS of fiddling, soldering, setting-tweaking etc. and on any other TV it just worked fine... so I used a different TV. My next step will be to get a nice flatscreen for it. The most important thing is that everyone can see it, so a small flatscreen with a limited viewing angle is a no-no unless you have some kind of dual-head setup and run one screen for each "team". (P.S. A very brief experiment showed conclusively that playing Jetpac on a 10-foot-wide projector image connected over S-Video is the coolest thing ever, but a very expensive way to run a games machine, so it's just not practical).

- Emulator configuration
Every one had it's own idea of what was Joypad 1. Every one had a different set of buttons on it's emulated controllers. Quite a lot have some weird options or programming that make them totally unsuited to the task. Some quit out if you pressed the same button on the joypad as selected the menu too many times (highly annoying when in the middle of a game). I had Gameboy emulators that couldn't emulate 4-colour Tetris as fast as a Nintendo 64 emulator could emulate Mario 64 on the same setup. I had Megadrive emulators that ALWAYS tore the screen no matter what VSync/Resolution/Buffering/Refresh options you chose. I had a CD-I emulator that will only accept mouse input. I had DOS emulators that needed settings tweaked for each and every game to get the best out of them (and even then at least one of them needed Joy2Key to make it easily playable). ZX Spectrum emulators offer emulations of so many different types of joystick (some of which conflict) that it's a pain to configure them all. Some I fixed, some I persevered and did it the hard way, some I ditched and replaced with other emulators, some I set up with certain limits (i.e. no more than four players, etc.)

- Distractions
Every time you set up an emulator, you just HAVE to test the games several times to make sure that they are all right, don't you?

- Programming
Yep... I did a bit of programming. It's a party machine, it's obvious from the outset. This thing is great at parties. And the best bit is, it's multipurpose. The hardest thing in the world to get is a decent Quiz Buzzer - one of those "who buzzed first" things. So I wrote one. I misused Joy2Key so that any button on the first joypad "typed" a 1 on the keyboard, second joypad 2 etc. and then I wrote a small VB program that just waited for input after the quizmaster had "opened the question" and then whatever character was typed first was declared the winner. It probably wasn't perfectly accurate but it did the job and took about twenty lines of BASIC code and a freeware Joy2Key to do it.

It's a good project to do. It requires limited resources compared to other PC projects (office and schools are throwing out PC's that can do this, TV's are perfect for playing old games on because you don't need the high-resolution of a monitor, any gamepad or joystick will work etc.). It is immensely fun and can be as simple or as complex as you like. It brings people together.

And I guarantee you that, if you are of the age that you can remember playing these sorts of consoles and not just Playstations, you will get ten times more play out of it than spending the equivalent amount of money on the newest games console. For the price of a new games console and a single game you can have every game you've ever played on in full better-than-the-original glory.

Jetpac

Seeing how I've been looking back at some of my older games recently, having been disillusioned with most modern ones and without a computer to play them on for a while, I was horrified to spot this bit of news:

Take a 16 kilobyte game, of classic nature, with fast, simplified gameplay, clear objectives, simple controls, that used to run on a processor of only a handful of MHz.

"Upgrade" it for modern machines, in the process making the screen hideously difficult to see what's going on, full of fancy unnecessary effects, several of which do nothing more than make the ENTIRE gameplay field obscured from the player's view, add extremely primitive multiplayer into a game never designed to have it and only release it (online) for one of the most powerful modern games consoles.

And in the process remove years of good game-playing memories.

Linux - Good enough, Easy enough, Supported enough, Common enough.

I was recently sitting on a bench on the platform of a local train station when a large man, who was sitting next to me, started talking to me for no apparent reason. This isn't unusual - I must attract local nutcases - but I worked out who he was when he asked if I was "into computers". Seeing as I had no indications on me that would suggest I worked with computers, I quickly realised that he must work in the school that I had just finished working at.

I was right, he was a maths teacher there, and once I had realised this, we introduced ourselves and got talking. First, my answer to the question whether I was "into" computers was a little understated. You can't move in my house for flashing lights and humming fans and it's been that way for nearly ten years. It's my hobby, my job and most things that I do in some way tie back to computers.

Anyway, he started to demonstrate his knowledge of computers, a trait that I find common among people who discover that I "know" IT. The first words out of his mouth took him above the average Word-letter-writer and placed him into the "geek" bracket - Java (in terms of programming environments and not just "that bit in IE that makes fancy websites"), LaTeX and Linux. For those unfamiliar with LaTeX, it's a typesetting language designed for hard-to-typeset symbols, usually used with mathematical formulae. Tying this together with my earlier discovery that he was a mathematics teacher at the school, I quickly realised that he a) actually knew more than average about IT, b) he was researching things to help him work and that c) he was already aware of free and open-source OS's and software.

(Incidentally, he was shocked that I had a degree and further shocked that it was in Mathematics and Computing - he hadn't expected that in a lowly computer technician. That made me into "someone he could to talk about mathematics without having to dumb down")

This mention of Linux and LaTeX further elevated him to "person that *I* can communicate with on a technical level". The fact was that he was using Linux, LaTeX and Kile to do his job, without anyone "making" him doing it, without anyone even knowing he was doing it and without any sort of help from other people got us talking all the way to our station.

He had a Linux desktop (although his technical knowledge hadn't quite reached the level of compiling his own software, so everything was RPM-based), he had found a Linux-based program that he found interesting and useful to his own work and he was trying his best to get things running as smoothly as possible. He asked if I would mind if he popped into the ICT office the next time he was around in order to ask some more questions to help him get enough things working that he could demonstrate Kile to the rest of the Maths department in the school. Immediately, I said "of course not". And why not? Because not only was he POLITE, not only was he TRYING to do as much as he could understand (the two main determining criteria on whether or not I go out of my way to help somebody), but he was also trying to use Linux to get stuff done, which isn't the easiest thing for a relative novice to do.

Similarly, my brother has recently had to help the local Scouts complete their IT proficiency badges. My brother is quite a Linux fan but has never really "run" his own Linux system. He has a router/firewall/storage server/print server/emergency-desktop system that I set up for him some years ago and is capable of using it and managing it himself, so long as there is someone like me or a Google result that helps him find the command he wants, once he's discovered he needs to do something.

The Scout IT activity badge is remarkably well-designed, unlike some computer-based achievements for children, in that it does not make mention of ANY particular computer or operating system. Criteria such as "Create a simple website" or "Take part in a video conference" are worded so that, although they may suggest examples for possible software, they are not heavily biased in terms of the platform on which the activities must take place. Most, if not all, requirements could be completed on something as antique as DOS or CP/M!

This is especially good given the average budget of a small Scout group who would be required to arrange such activities on a fairly regular basis. A few old, obsolete machines loaded with even FreeDOS would be able to complete enough criteria for most of the stages of the IT badge, without unfairly hindering the children required to complete them.

It was with this in mind that my brother, a born-educator, wanted to provide a challenge to the more "cocky" Scouts. Those who have been trying to show off that they "know" computers when in fact all they have ever used is a Windows XP PC which was already installed and set up for them would, on the day, be faced with a Linux-KDE desktop. To the experienced, and genuinely talented, children this would be little more than a cosmetic hinderance. To those who have just memorised that they click the "Blue W" or the "Blue e" to get things done, it would be an awakening.

By the time these children are in the workpool, it's possible that the OS's that are commonly in use today would be completely obsolete and not just from a versioning point of view, but from the methodologies and techniques used. As an example, when I was at school, for my "official" education, I was taught to use BBC Micros with 5.25" floppy disks, followed by Amstrad PCW512's with 3" floppy disks with integrated CP/M, moving onto Windows 3.1 machines (with MICE!), which meant drag-and-drop, windowing metaphors, multi-tasking etc., and finally onto Windows 95 (which introduced me to the world of computer crashes and diagnosis like never before). By university, we were introduced to Linux, Apple Mac and SGI UNIX workstations.

So, if I had "learned" computers only from those that were taught TO me from my school days and then been thrown into the workplace, I would have to relearn everything that I knew. The only way that I was able to keep up and still stay ahead of the class (and the teachers) was to not "learn" specific operating systems, terminology, methodology or icon locations but to spot the patterns and learn how to operate any generic computer. This was mainly aided by the fact that I was exposed to lots of different OS's and architectures before I had left secondary school. Since then I have applied these skills to operating systems that I had never seen before. I have managed networks that I have never had any formal training on with only a few seconds in which to "learn" the system. And I haven't managed to blow anything up yet.

My brother learned the same way, that a broad, general education is far better than a targeted, by-rote education, and wished to convey this to the children at the same time as doing their ordinary badges but without hindering them in such a way that it would interfere with their actual results.

Thus, he wanted to trial a small Linux desktop system to use on the day.
He set aside an entire evening for installation, not including hardware setup (inserting hard disks etc.), plus an old 833MHz computer with 128Mb RAM.
It took us less than an hour to install, from a blank harddrive and 2 Slackware CD's.

The next thirty minutes he spent marvelling about how easy the setup process was, how much of the hardware it supported, how much stuff was "pre-installed" with the basic system (enough to do everything that he intended to do, even though he had initially wondered about installing OpenOffice, the built-in KOffice was consider more than adequate), how "obvious" the setup questions were (although he is more than computer-literate, he still loved the explanations given for options that he was unfamiliar with - most of which told him exactly what each option did, why it did it and what he should choose if he was unsure), how customisable the whole thing was, how secure (when running as an unprivileged user) it was and how quickly and smoothly it all worked. The step-by-step instructions held his hand just enough (although he doesn't really need it and isn't put off by reading a HOWTO or asking on a forum or even just experimenting) at every single stage and I usually made him make the decisions about what option to choose - if in doubt, he chose defaults.

Considering it was Slackware (a server-based distro, really, and an older version at that), on an old machine, using more swap to get stuff done than real RAM, with the default 2.4 kernel, with the default VESA drivers on a crappy 16Mb graphics card, without any sort of real configuration, turning features off or having to fiddle, he was impressed at just how fast and usable a desktop system could be created so quickly. There were some rough edges, which was the main reason for my presence as he was perfectly capable of trialling this himself.

For one thing, he had to type "startx" at one point! And then later edit inittab to make it always boot graphically. He had to select hdb in one place instead of hda despite there only being one drive present (weird ancient BIOS assigned the first hard drive to hdb when hda was empty?!) and I advised him to install LILO to MBR instead of the other locations. That was about it. And none of those problems would be present on any desktop-targeted distro.

However, once in the GUI, he created his own, locked down users (i.e. normal users other than root). He had office suites ready and they were trialled at the touch of a button. He was able to change the clock that was out of date - although he was asked for a root password as he was logged in as one of his restricted users at the time. At no point was he asked for driver CD's, Windows updates, or to reboot. Nothing took over his hard disk or wiped out boot sectors without asking. Functionality that could only be enabled with the addition of extra software on his Windows was there by default - multiple desktops, multiple clipboard entries, etc. Everything ran smoothly without any knowledge of the hardware involved (although, admittedly, we didn't do anything more complicated than join the local Ethernet).

And I know from experience that sound (had this computer had possessed even a built-in soundcard) would work flawlessly without "drivers", printer and scanner support would be the work of a few seconds even on Slackware, never mind an auto-detecting desktop distro, wireless would be just as easy and well-supported. The only problems that MAY have appeared would be with exotic or entirely obsolete hardware - and hardware that exotic or obsolete would either not work at all in Windows or certainly not work without installing lots of drivers. With that effort, they could almost certainly be made to work on Linux just as quickly.

We seem to have reached a plateau. Linux is "good enough" for most tasks, "easy enough" for most people (technically-minded or not, especially if pre-installed for them), "supports enough" to make it run on virtually any hardware no matter what its vintage, "common enough" that even relative novices are hearing of it and using it (and in fact most places are using it whether they know it or not in the form of in-house black boxes, routers, TomTom kits, ISP's, webhosts, firewalls, etc.), "supported enough" in that the simplest of Google searches will throw up hundreds of places to find help (whether by yourself, directly from other people or from somewhere that will sell you support).

And it seems increasingly true that Windows is fast becoming "not enough". Not secure enough (Let's not even get into that debate - I'm taking Windows + supplied software + latest updates against Linux + supplied software + latest updates). Not fast enough (with modern Windows' hardware requirements). Not forgiving enough (of sloppy users, old hardware, etc.). Not usable enough (with more restrictions, problems, confusions, distractions and idiosyncracies). Not simple enough (seven different versions of Vista, difficult to install from scratch on "unusual" hardware, harder and harder to get simple stuff working, more and more complex to secure). Not cheap enough.

The only question remains, how long until you've had enough?

Slackware 11.0 - first experiences and upgrade process

Well, Slackware 11.0 is officially out after an exhaustive batch of release candidates and (due to some hideously attentive monitoring of the ChangeLog in recent weeks) I've already upgraded to this system. In fact, I've been downloading each new package for the last few weeks as and when they changed the Changelog, and about once every few days, I'd create a DVD and install it onto a copy of my primary partition to find problems before I took the plunge and actually started using it as my primary desktop (replacing an up-to-date, clean Slackware 10.2).

The upgrade, as ever, goes like a dream so long as you follow instructions *very* carefully - don't omit any steps. We won't mention my moment of idiotic forgetfulness where I forgot to upgrade the rc.udev file once I'd installed it or even failing to copy the initial /dev from my existing partition to the "mirror" partition that I was upgrading, both of which caused Slackware to fail to boot... One of those is mentioned in the upgrade.txt (transfer ALL the .new files across! In a moment of blindness, I omitted rc.udev.new), however the other was just common sense if you intend to work from an accurate copy of your existing system! Those installing onto a clean partition should have no problem at all.

After many, many tests (I was, after all, performing a major operating system upgrade on a system that was still being used for "real" work), I copied my Slackware 10.2 main partition to a blank space, freed up 1.5 Gb on it (as leeway for new packages, upgrades, temporary files etc.) and installed the upgrades over the top of this copy. Once I'd followed the upgrade.txt (which, at the time, was the 10.1->10.2 upgrade.txt but still the principle is the same), all I had to do was recompile my kernel (Slackware 11.0 now ships with GCC 3.4 which means you also have to recompile any custom kernel or kernel modules that you may have had from Slackware 10.2, which only used GCC 3.3), reinstall lilo and it all just worked.

However, be very careful if you have extra modules in your kernel (e.g. nVidia/ATI drivers, out-of-tree wireless drivers etc.) as they *will* need recompiling. When you are using the same compiler and kernel on two different machines, the modules are usually transferable between the two machines, but Slackware has changed the default compiler so this time-saving trick no longer works. Failing to recompile them *will* crash your machine, maybe not immediately - for instance, in my initial testing on a blank partition, failing to recompile the nVidia modules and instead "copying" them from a previous installation crashed the machine hard as soon as OpenGL was used, but had functioned perfectly until then (even accelerating X and video flawlessly).

The crash was so hard that the (journalled) filesystem stopped halfway through a write and corrupted the partition - proof, if ever it were needed, that the use of proprietry modules removes any guarantees of stability and also that journalled filesystems and RAID are no substitute for adequate backups. That's also why you should always backup and/or test on a copy of your primary partition before you do stuff like this - I did it out of academic interest and was surprised that X or the kernel didn't throw up more warnings.

Applications, however, should not require any re-compilation at all, unless they are very tightly integrated into the kernel or statically build from the supplied libraries (something that they shouldn't do for most purposes). I haven't found anything that I've needed to recompile except for kernel modules but I'm sure I will find something that will have stopped working - a lot of stuff uses the kernel as the definitive source of information on things like kernel structures etc.

KDE was neatly upgraded to 3.5.4 in the process, all my old settings just ported over without any hassle (although a few KDE-specific tweaks, such as what the taskbar looks like and how multiple-desktop thumbnails work had reverted to a new default - easily changed and they were the exception rather than the rule). And it still runs like a dream.

Given a 1Ghz, 512Mb RAM machine, there is no significant detrimental performance difference between Slackware 10.2 and 11.0. In fact, because of both the KDE and X.org upgrades, programs under X run noticeably smoother - this is an old machine and small optimisations make a big difference when you don't use eye-candy like transluceny and anti-aliasing. Even code like a static-QT installation of Opera 9.0 is seeing responsiveness improvements compared to before. Given that Slackware is not designed as a desktop OS, it functions admirably under such circumstances and the system requirements are minimal.

Because it's Slackware, most desktop software will require, at some point, extra libraries or installations (for instance, mplayer codecs and OpenOffice.org are not included) but everything will usually compile cleanly from source without any patches or there is always Linux Packages.net for packages of any extra software you may need. Slackware's main install is only around the 3-4Gb mark when installed (depending on filesystem and block size) so on a modern hard disk, there's plenty of room for extra software. My main partition (not including personal files in /home directories) rides comfortably around the 10Gb mark and there's always plenty of space for a full install of Slackware plus Wine, Crossover Office, Microsoft Office, OpenOffice and many, many other large pieces of software.

One word of advice - take upgrade.txt's suggestion to just "install the rest of the packages" lightly - in fact the best method, especially if you are short of disk space, is to go through each package directory one-by-one... e.g. upgradepkg --install-new /root/slackware/a/*.tgz etc. Not only does this make it easier to omit the KDE/Koffice internationalisation packages for languages you don't speak (e.g. upgradepkg --install-new /root/slackware/kdei/*en_GB*.tgz), or to omit those packages that you don't need installed anyway (TeX or emacs for example), it saves a lot of time and diskspace and prevents you upgrading to a 2.4 kernel (hiding in slackware/k) and then having to reinstall the 2.6 kernel packages from /extra.

In terms of the final product, hotplug/udev is greatly improved and detects most peripherals and uses them automatically - nothing new or exciting unless you've not run any other recent Linux distro, but being able to plug in a USB drive, joystick or mouse and have it instantly recognised and have X/KDE start using it is a welcome return to the ease of a typical Windows installation. This does require a relatively modern 2.6 kernel though, but the scripts are still designed to take account of older kernels (2.4 or 2.6) that are not able to do this. And yes, 2.4 kernels are still the default for the time being.

One other change to the install process is that the sata.i bootdisk is now set as the default for any bootable CD or DVD (even the text on "how to boot in an emergency" on the boot screen reflects this), allowing direct installion on a old-style-PATA or shiny-new-SATA harddrive without having to select a different bootdisk - apparently a code conflict between the modules for the different hardware has now been resolved, making this possible. It's a welcome simplification to the install process.

All in all, the installation was fairly flawless but be careful about your kernel - unless you stick with the default 2.4 or 2.6 kernels (which will be out-of-date within a week or so, if not already) you are going to have to recompile the kernel and any modules and then reinstall LILO or GRUB. The only other thing to remember (and it's in upgrade.txt) is to ensure that all the .new files that appear on your computer have your settings transferred into them and then rename *them* to replace your original configuration - this way you won't miss any new config options that might have appeared.

I suppose the biggest disappointment would be for Gnome users - there isn't a sign of Gnome left in Slackware (the distribution cited ease of compilation/packaging as the reason for its removal in the last release) although you can still get Slackware packages for it from various third-party sites. To me, this went unnoticed as when I first started off installing Linux with X desktops, I tried both of the major window managers at the time and KDE came off best every time. Gnome felt clunky, old, out-of-place, like the Borland Windows dialogs used to back in the early days of Windows... nothing WRONG with them, they just didn't fit.

They are both now skinnable and in fact either can look like the other, so it's not a win-win situation - however, because of that there's also little reason to claim Gnome's loss is devastating... KDE can be made to work just the same and in fact the two projects are collaborating on just about everything these days. The GTK libraries etc. are still installed by default and, in fact, some ancient Gnome-based software that was left on my setup from its previous Slackware upgrades still functions perfectly.

People say that KDE is full of bloat but, I'm sorry, 3Gb for an entire OS including X and an office suite? That's well within the realms of convenience on a modern computer and most packages can be omitted if you really want (you can get a X installation down to less than a Gb if you really try and omit all the rubbish - I'd hate to imagine what the absolute minimum would be - I should think it would be amazingly small). And a 512Mb system showing only 100-200Mb in use when I have several applications open (and a few dozen background processes including Apache) under X/KDE is perfectly acceptable. And with KDE4 currently in development, the introduction of QT4 is supposed to make everything so much faster and leaner. But let's not get ahead of ourselves.

Altogether, Slackware 11.0 is another flawless upgrade of a "clean source" distribution - there are very few patches to the software included on the disks and the kernel is always "pure"... making upgrades, recompiles and troubleshooting simplicity itself. I should also imagine that it makes the lives of the software developers much easier as the bug reports are directly relevant to the software, rather than patches that the distro has tried to add itself.