STPPC2x Beta 2- GP2X port of Simon Tatham's Portable Puzzle Collection

I've just released Beta 2 of my port of Simon Tatham's Portable Puzzle Collection to SDL/GP2X. It is much improved and the only remaining "problem" is that mines doesn't work. The other 26 games run fine from start to end.

I think the problem with minesis due to endian/signedness differences between x86 and ARM within the puzzle code itself (which I don't change in order to port any of the games). The game compiles and works under x86 Linux and runs fine but the GP2X crashes with an assert on mines.

The beta 2 version of STPPC2x (and the associated source code) can be found here:

http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,25,2543

Or on the website where I keep all the released versions:

http://www.ledow.org.uk/gp2x/

GP2X port of Simon Tatham's Portable Puzzle Collection

Damn it's a long time since I programmed in C.

I've just spent the last few weeks porting the GTK/Windows/MacOS/Palm collection of games that are in Simon Tatham's Portable Puzzle Collection to work on the GP2X handheld game console.

That involved the creation of an SDL "frontend" for the existing puzzle infrastructure (which, I have to say was beautifully abstracted and documented from a programmer's point of view). It worked beautifully well on the whole. The puzzle framework is designed in such a way that it can be easily ported by just filling out the definitions of a few dozen functions. Basing my work off the existing GTK port, most of the simple functions were only a line or two to convert to SDL (using the SDL_gfx library helped a lot too). Even the font functions were quite simple, when using SDL_ttf. And because the GP2X is Linux-based, I was able to prototype all the functions using the GTK functions running simultaneously with their SDL equivalents on the same development PC, as you can see from the screenshot. Each game is running an SDL and GTK copy of the game and synching display and input between the two, while running on a normal Linux PC.

After they all functioned enough to give me a playable game in SDL, I started stripping out the GTK functions, libraries and dependencies and ended up with an executable that only needed SDL, SDL_ttf and SDL_gfx to run. That ran on any SDL-based architecture so I could compile the same code for either the GP2X or the Linux PC. For the GP2X it was the "simple" matter of cross-compiling them to the GP2X's ARM architecture, linking them against some ARM SDL libraries and then testing them on the machine itself.

But it has to be said that the hardest part of all was actually getting things to compile and link properly! I now officially hate Makefiles, gcc and linkers. I wasted more time trying to get code which I *knew* was working to compile and link in various ways without errors than I ever did coding! That really was the most horrible experience and half the time I had no clue as to what the problem was, even after analysing and googling the various weird and nonsensical errors I was getting. Programmers should really not have to play about with such convoluted and finnicky command lines just to get a simple C program with pre-compiled libraries to compile and link. Granted, wanting to compile a program for both x86 and ARM, with dynamic or static libraries should mean a little tweaking but it should never be as difficult as it was. I was actually *scared* to touch the Makefile each time in case I broke it and I kept more backups of that than I did the actual SDL interface code.

Anyway, I eventually got the puzzles to the point that they were mostly playable, mostly fun, mostly working and mostly pretty-looking. I've tested them all on GP2X and they are, on the whole, working (there is one that errors out in the actual game code, which I haven't touched, but only on the GP2X - a Linux machine with exactly the same code doesn't error. The other problematic one is just a bit too slow because it tries to do a lot in a short time on a slow processor). I was working my way through them one at a time to release them, because some of them exhibited subtle bugs, some of them required more work on input to allow them to "enter" numbers into the puzzles and at least one of them was (and still is) just being a pain in the bum. But now the vast majority of them work and I've built "beta 1" of what I have called (in a rare fit of originality) STPPC2x, or Simon Tatham's Portable Puzzle Collection for the GP2X. :-)

I'm surprised at how well and how fast they work, considering that the development 600MHz machine doesn't run them any faster than the GP2X at 200MHz and I'm not even using the hardware acceleration on the GP2X properly.

The first beta, with 25 out of 27 games playable, most of them near-perfectly, has been released on both the GP2X archive and at my website: http://www.ledow.org.uk/gp2x/ You can get the source code and toolchain that I used from my website too, because I find the most annoying thing about picking up other people's code is when you don't have the same compiler/libraries/filesystem setup as they do, so it's a problem to compile even before you start coding.

I consider it a good piece of work, considering that my last C excursion ended about an hour after starting it and I ended up writing the program I needed in something else instead. That was several years ago but I was able to pick this up and run with it. I estimate the total *actual* development time on STPPC2x to be approximately 48 hours for approximately 1000 lines of actual code (not including the Makefile), spread over a period of two and a bit months (it's hard to get in a mood where you want to fight with compilers, pointers and libraries). At least six of those hours was getting the Makefile to work properly. At least two were creating scripts to compile and link each file individually because I was sick of the Makefile not working properly and needed something that worked *here and now* so I could work on either the Makefile or the actual code at my leisure. At least ten hours on top of those 48 were things like "waiting for stuff to compile", "waiting for stuff to copy", "waiting for stuff to upload to my website/the GP2X archive", "preparing screenshots, instructions, proper licensing info, directory structure etc. for releases" and "waiting for the GP2X to finish writing to the SD card". A 600MHz development machine trying to copy megabytes of files over a USB 1.1 connection to an SD card isn't ideal, especially when you trying to write instructions, take screenshots, upload via FTP, etc. simultaneously. :-)



Anyway, it's been my first big programming project for a while. I'm always writing *something* whether it's a shell script or batch, a VB program to do a quick job etc. or something for my own entertainment but they all involve different standards of work - either I'm the only person to ever use the program at all, or it's for a limited technical audience, and it's very rare that the source code is ever looked at in either case.

In the first 24 hours, it saw 100 downloads from the GP2X archive alone and I haven't looked at my website's logs yet. At least I know that it was worth my while.

Useful Scripts, Part 2: Linux "file sorter" script

The following Linux-based script (which you can download here) is also one I find myself using on occasion. I've made versions of it that run in just about every OS I've used at one time or another. It's a script that takes a large directory full of files, creates 37 subdirectories (A-Z, 0-9 and "other") and moves all the files in the folder it is run into their lettered folder according to their first character.

This is great when you have a large folder full of files that takes forever to "ls" or access over a network or a folder that is unmanageable for quickly finding particular files in a GUI. It's case-insensitive (I'm sorry, but DOS got this bit right, case-sensitivity can be a real hindrance at times, no matter how careful and experienced you are) so "Afile" and "anotherfile" both get put into the a/ folder.

I've used this on emulator rom folders when they got too many files in them, I've used it (or a Windows-"port" of this script) in user-profile folders on servers to help narrow the users down a bit and even move portions of them to a different storage medium in a logical manner (it's better to move A-L to another drive than it is to move the first 1000 users, from a "I'm only human" point of view). I've used it in archives of zip downloads, photographs, instruction manuals, all sorts. I hope someone else finds it useful.

#!/bin/sh
mkdir other
for LETTER in a b c d e f g h i j k l m n o p q r s t u v w x y z
do
        mkdir $LETTER
        FILESPEC=$LETTER\*
        UCASEFILESPEC=`echo $LETTER | tr a-z A-Z`*
        mv ./$FILESPEC ./$LETTER/
        mv ./$UCASEFILESPEC ./$LETTER/
done
for NUMBER in 0 1 2 3 4 5 6 7 8 9
do
        mkdir $NUMBER
        FILESPEC=$NUMBER\*
        mv ./$FILESPEC ./$NUMBER/
done
mv ./* ./other/

Useful Scripts, Part 1: Linux "screen" wrapper script

A few people in the past have asked me for a few of the hundreds of scripts that I have made for myself. My life is a one long session of script/batchfile writing (I use the terms interchangably because a list of commands to run is a list of commands to run no matter what language, OS, etc. it is written for). There are school networks that are running on some of my scripts!

I'm not so keen on letting the larger, more tedious scripts out without me doing a proper licensing thing on them (open-source of course) but the little ones that are just convenient wrappers etc. I don't mind giving away. They are so trivial you can hardly claim copyright on them, even if the only intention of that copyright is to give them away but ensure you get recognition. Anyway, here's the first one, for Linux. It's a wrapper for the "screen" command. You can download the script from here.

Screen is a powerful command. It's ALMOST as good as when you first use a Unix-based machine and are taught to use Virtual Consoles (pressing Alt-F1, Alt-F2 etc. lets you have a variety of commandlines open at the same time even if you aren't in a GUI). Screen lets you run tasks in the background, with their output hidden, in such a way that you can "resume" or connect back to the screen that the program is displaying, from anywhere. It's a kind of VNC for the console. So, for example, if you want to run a program like IPTraf or HTop, but want to be able to see its "screen" from an SSH session later when you're at work, you can do this.

The script itself is quite simple, and I have a habit of calling it my "do offline" script, so I normally name it do_offline.sh:

#!/bin/sh
if [ -z $1 ]
then
        echo "First arg is screen name, rest is command to run"
fi
if [ ! -z $1 ]
then
        SCREEN_NAME=$1
        shift
        echo "Running commands ($*) under screen name $SCREEN_NAME"
        screen -A -m -d -S $SCREEN_NAME nice $*
fi

Basically, you run it as:

do_offline.sh "screenname" "program and arguments..."

e.g.

do_offline.sh htop htop

do_offline.sh lare_file_copy cp -R *.* /mnt/backup/

do_offline.sh kernel_compile make

And it will happily run those commands in the background while putting the output into an invisible "screen". This is useful if you are logged in via SSH... rather than having to fudge access to the F1-F12 consoles you can start jobs in their own screens and then disconnect and reconnect from their screens as necessary without interrupting the job. You can start an 50Gb download remotely and not have to interrupt it when you disconnect your SSH session (the program will just carry on running in its screen and you can "resume" the screen from the local console when you get home to see if it finished).

To resume the screens, you just use:

 screen -r 

e.g.

screen -r kernel_compile

And the one annoyance... to "disconnect" from a screen without interrupting the program its running, just press Ctrl-A and then D. Horrible keyboard shortcut.

For example,

# do_offline.sh htop htop
# do_offline.sh kernel_download wget 
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.3.tar.bz2
# screen -r kernel

Is it done yet? Nope?

Ctrl-A  D
# cd /

Go off and do something else, disconnect from the computer, go to work and log in to this computer remotely.

# screen -r kernel_download
There is no screen to be resumed matching kernel_download.

So it's finally finished and we can compile it. But I want the computer to have compiled it by the time I get home

# do_offline.sh kernel_compile make

Go home, log back into the machine at the local console

# screen -r kernel_compile

It shows up as still compiling, so I just watch the progress for a few minutes and then..

Ctrl-A  D
# screen -r htop

Have a look at the CPU usage, wait for it to dip

Ctrl-A D
# screen -r kernel_compile
There is no screen to be resumed matching kernel_compile.

My kernel is downloaded and compiled without me having to watch its progress, limit it's output to a single virtual console on a single physical machine, or keep the remote session connected constantly while it does it.

I hope it's useful to someone. It's already been useful to me and to at least a couple of people on the Linux Questions forum.

GP2X handheld Linux games console - A review

For Christmas this year, I managed to persuade my other half that a GP2X would be an ideal present to keep me quiet. For those who don't know, the GP2X is a handheld games console whose main selling point is that it runs Linux behind-the-scenes and has buckets of "homebrew" software, including ports of popular Open-Source games and emulators. As I've stated in a previous article, to me that makes it more valuable than any other games console I've ever owned - I can load it up with "fun" older games and play for thousands of hours rather than spend a fortune on a single modern game which I would play for about a day before I get bored or completed it. (Incidentally, thank you Nintendo for the Wii and bringing the fun back into gaming!)

Anyway, I am now the very proud owner of a "Mark 1" GP2X, called the F-100. This is the black version with the original "joystick" rather than the touchscreen and digital joypad. To be honest, I didn't specify which version and knowing what I know now, I'm glad that all the wife could afford was a second-hand F-100. It's personal choice but I can sacrifice the features of the sucessor F-200 for the features that the earlier model has. Other people would disagree depending on their usage.

Most of the people who are interested in the GP2X, or indeed it's predecessor the GP32, will know about the handheld's features but for a quick rundown...

It runs on two "off-the-shelf" ARM chips (940T and 920T), with variable (and software-controlled) clocking between 60MHz and 260MHz each, the default being 200MHz and the overclocking being quite "safe" overclocking that doesn't cause permanent damage unless you do it for very long periods of time and overheat something. In fact, more powerful games can only run at the higher speeds and will "overclock" the device themselves - all that happens is that it works or it crashes. All that is required to "recover" from a crash is a switch-on, switch-off to get it back to normal.

It comes with 64Mb RAM (32Mb is directly accesible, the rest can be used with some trickery and often is) and a 64Mb internal NAND permanent storage. This contains the bootloader, kernel, some built-in applications like the menu and maybe even some games depending on your particular purchase. This can all be replaced and customised but you won't gain much. The NAND allows people who forgot to get an SD card to use the console straight away, and also provides an avenue for the vendors to pre-load certain games if you buy their bundles. Also, because it has to be a deliberate act to affect the NAND bootloaders or kernel, you aren't going to be bricking your GP2X accidentally. NAND firmware updates tend to come in the form of a bootable SD card.

For main storage, you can use an SD card up to 4Gb (32Gb in the later F-200 model) formatted in either ext2 or FAT32 - most cards come with FAT anyway and if you want to use the connectivity features, you're better off with the more-prevelant FAT. This is where most of your games etc. will go and it's quite easy to have hundreds or thousands of games on a single large SD card. And, let's be honest, SD cards are so tiny that you could easily carry a handful with you and fulfill every gaming need.

The firmware runs uBoot to boot pure Linux 2.4 as the core OS (source and alternative firmwares are available but you don't gain much because GamePark Holdings, the manufacturer, did a good job in the first place) in around ten seconds, with a nice splashscreen and bingely-bingely-beep startup sound. All of the "menus", games, emulators are just ordinary Linux programs compiled on GCC against an ARM target. So everything is either open-source from the start or has many open-source equivalents, even the main menu, boot-up screens, built-in applications etc.

Because it relies on BusyBox internally, it's not even unusual to see wrapper-bash-scripts around games in the Games menu. It has a rather perfect and simplistic method of program execution - when the GP2X starts up, it boots and then runs the menu program (standard Linux binary). That lets you select a game/application to run. On termination, each individual application is responsible for making sure it exec()'s the main menu before it clears up. It's beautifully simple but works and prevents the menu hogging RAM while you're playing a game. And if a program ever crashes really hard, you just switch-off, switch-on and it boots the menu back up again. Programs have full access to NAND and SD storage for savegames etc. but they tend to only place things in their own folders. This does, however, allow you to have a collective "roms" folder and use several different emulators with the same roms.

It operates off two AA batteries, although they HAVE to be high-power rechargeables (preferably 2800mAh) - what do you expect for a dual-200MHz portable machine?! You can get a good couple of hours out of a set of two depending on what you're doing. There is also a mains-adaptor port for static use and you can easily carry enough AA batteries to last you all day if need be. The only minor point here is that the mains adaptor doesn't charge the batteries, but you can't have everything.

The screen is full-colour, 320x240 and is very good in virtually any lighting. It is covered by a plastic protective screen about 2mm above the surface, which protects the expensive bits against that pen you keep in your pocket. There are two speaker grilles on the front (I believe only one is an actual speaker(?) but stereo sound is present in the headphones) and the SD slot sits in the very middle at the top.

It also has a headphone socket, power socket (3.3v regulated), mini-USB socket and EXT socket (we'll get to those last two in a minute). The two AA's sit comfortably in a rear "bump". The game controls are (on the F-100) a "mini-joystick" on the left of the screen which works surprisingly well, A, B, X, Y, Start, Select buttons in their usual places, Vol+ and Vol- just underneath the joystick and L and R shoulder buttons. On the F-100, the joystick also "clicks" down to provide another button. Sadly this was removed from the F-200 model because the joystick was replaced with a 4-way D-pad and a touchscreen was introduced over the LCD.

The GP2X is comfortable to hold for long periods and the design is "flat" on the front, except for the joystick which can be controlled by a wiggly thumb or between two fingers for precision control. The batteries are tucked away from your fingers so it feels quite thin. You can't accidentally eject the SD card or knock the battery cover off while playing and all the other ports have rubber covers to stop you poking things in them accidentally. Headphones plug into the top, keeping the lead out of your way.

The mini-USB socket allows you to connect the supplied USB cable to access the GP2x from a PC - of any kind. No driver software is required and it appears as a standard mass storage device so Linux, Windows and Mac can all "manage" the devices files. Installing a game can literally be a drag-and-drop. You select what content you would like the PC to access each time - either the SD card or (F-100 only) the internal NAND - and it just pops up as a removeable disk.

You can copy your games to your GP2x without switching off by using this feature or you can just eject the SD card and use an SD card reader in your PC (not supplied). There are also a plethora of USB options on the earlier model - the F-100 runs what is known as a USB gadget interface so that it can appear as a "device" to normal PC's. This allows it to be seen as a USB network card, USB HID device (so you can control windows games with its joypad, for example), and it has built-in web server, telnet server and samba server for access over the USB-net. Sadly, these features are lacking from the later model F-200, which I see as a great loss, and were instead replaced with a touchscreen interface in addition to the normal control methods.

Because it's all just Linux, you get some fanatics do things like plug a wireless or Bluetooth USB adaptor into the socket and port a driver for the device. Strangely, they often work, although the practicalities of a handheld limit its usefulness. There are ports of games designed especially for accessing a Nintendo Wiimote over a USB-Bluetooth device, for example.

The EXT socket allows for a whole new range of options. First, TV-out. Yes, this little device can display on your TV! Some games can appear blocky in this mode but some make use of higher resolutions when they detect the TV-out cable. Either way it makes for much better "static" multi-player fun.

Additionally, the F-100 has a peripheral available called the Cradle - essentially a "break-out box" which connects to the EXT port to give you access to 4 USB ports, for connecting devices such as joypads, keyboards, mice, USB keys etc. Games have to support extra controllers but most popular ones do. The GP2x also directly recognises USB mass storage devices connected to it. The breakout box also features TV-out itself too, plus JTAG programming ports (for hard-core tinkering and "un-bricking"), additional audio-out, a power-supply connector and RS232. It's safe to say that the break-out box isn't really that portable because it is intended as a home-device for development, or for using the TV-out feature to turn it into a home console.

But the important thing is, how well does it play games? Well, the absolute best examples for "showing off" don't run to much if you're looking for 3D-power in your handheld, but considering the devices specifications they are very impressive. Payback is a GTA 1/2 clone (some might say a bit TOO close to the original) with 3D, dynamic lighting etc. and plays really well. It has to be said that this is the showpiece of the GP2x and little beats it in terms of hardware use, speed and visuals. On the homebrew side, a complete port (yes, port, not remake) of Quake is the best, in visual terms, that you will see - and it's compatible with virtually every Quake mod, including the official ones. However the little beast should not be underestimated - Quake running at full-speed on a device such as this is no mean feat when there is no dedicated 3D hardware.

The GP2X, it has to be understood, is not going to out-perform much at 3D. It's based firmly on 2D, from design to manufacture to software, and that's where it excels. There are ports of almost every 2D GPL Linux game available - SuperTux, Crimson Fields, LBreakout, Liquid War, GNU Chess, Quake, Hexen, Clonk Planet, etc. there are dozens. But that's NOT what the GP2X is for - I'm sorry but it's not! Neither is it to be used for it's built-in MP3 player, eBook reader or Video player (DivX compatible). Nope. This thing is an emulation machine, pure and simple. The "official" archive is full of games but emulators top the download charts every month.

ZX Spectrum, Amiga, Atari, Commodore 64, Gameboy, NES, SNES, Master System/Game Gear, Genesis/Megadrive, Arcade games, they all have emulators for them that run on the GP2X. Only the most demanding tax the little workhorse but for myself, that was more than enough. I can play all my old favourites, full speed, on a little portable device that I can put in my inside pocket comfortably. This is also the ultimate test of gameplay on the joystick - pulling off Ryu's special moves on a SNES emulator running Street Fighter 2 is flawless (I've heard the F-200 has more trouble because of its D-Pad?). The button layout is very well thought-out and lets you emulate SNES controllers virtually perfectly, and every other comfortably. You never feel that there's a button mapped into an impossible place.

The speed, graphics and sound for the above-mentioned emulators are perfect for the vast majority of games in default settings - it's always those ones with the special chips that give you performance problems. Gameboy games feel perfect, SNES games work perfectly if you have the "basic" chips, so Super Mario World and Mario All-Stars are flawless but things like Street Fighter Alpha, Starfox and Yoshi's Island will suffer. There is a port of MAME available with over a thousand games playable. Most 80's arcade games are fully playable and later ones are hit-and-miss depending on the specifications. I love Final Fight, Wonder Boy, Pang, Ikari Warriors etc. and was very glad to see that they all ran perfectly.

You can stretch the machine to higher-level games (there's even a PSX emulator for the very optimistic) using the built-in overclocking options in most emulators but you rarely go from "Aw, it's unplayable" to "Yay, it's perfect" by doing so. Also, as with all overclocking (of which I am a massive opponent when it is used on PC's), it varies considerably based on the particular manufacturing that went into your particular device. Some people can overclock their GP2X to 270MHz and beyond without problems, others can't get much past the 200MHz defaults. Oh, and it can kill your batteries much more quickly, so in fact what you find yourself doing is finding "sweet-spot" under-clocking limits for every game so that you can save battery power without sacrificing gameplay. Most emulators allow you to do this on a per-game basis, which helps you save as much as possible.

Emulators are definitely leading the software development on the GP2X - RAM timing and MMU hacks to vastly improve performance originated from a want to get every ounce of power out of the GP2X and are present in every emulator and in most homebrew games. MAME lets you access 4 USB joypads connected to the handheld for multiplayer action - a rare feature in other GP2X games, but has been copied into most emulators for the platform. There are a smattering of commercial games, none really priced higher than about £10, and their quality does show through but there are not many able to compete with "free" games coming out of the porting community. I thought that Payback was well-worth the money but I'm not sure I'd fork out for some of the puzzle games. I'd much rather give a homebrew-author the money for a particular favourite.

And with a 2Gb SD card, you can fit almost everything you'd want (including a couple of hundred MP3's and a video or two) onto a single card.

On top of emulation, the homebrew would be the next software "feature". If you can compile against ARM targets (easy with GCC and the various devkits available for the GP2X), base the game off Allegro or SDL or be prepared to write a little hardware-code, you can get games up and running in minutes. The hardware was designed to be accessible - it's all just Linux. You can get the joypad showing up in /dev/joy, you get sound out of /dev/dsp, you can do some memory mapping tricks on /dev/mem and /dev/fb to create double-buffered video in the slightly-trickier top 32Mb of RAM. Everything is just Linux 2.4 with some extra features here and there to let you tweak the LCD backlight, control the battery-low light, speed up either CPU etc.

There are versions of BASIC available which target the GP2x and are designed to create the sort of mini-games that can be more fun than commercial games - sites running nothing but Flash games are proof of this on the Internet, and on the GP2X you can knock up similar games in minutes using one of dozens of development packages - Fenix, Python, BASIC, all sorts of languages are available. There are hundreds of games available, some diabolical, some fantastic. There are even ports of SCUMMVM, Albion, Descent, Doom, Duke Nukem 3D, Ultima 7, Heretic, Hexen, Rise of the Triad, various DOSBox-based games, Frozen Bubble, Super Mario War, OpenTyrian and even the Graphical version of Nethack! (I'm sorry, you can't leave that game out of the list!). Every year there is a competition run for the best GP2X homebrew or ported game and the winners can be very impressive.

At the moment, when I'm not playing the "oldies" on an emulator, I'm playing Ghostpix (a very polished Picross/Nonogram/whatever you want to call it puzzle-game), SuperTux, Liquid Wars, Kuoles, FreeDroid, Frontier2x (an Elite-2-port), Quake, and a million other "five-minutes" games that are just fantastic for a handheld console.

And the most important thing - the GP2X makes gaming fun again. You plug it into your PC, download some stuff from the web or the official archive, throw it onto the SD card over the USB cable, then go to Games, GameName, GameExecutable and play. You can even use the eBook reader to read the instructions on the device itself (emulators tend to have a lot of instructions because, for instance, SNES emulation demands quite a lot of buttons to be mapped so you need to know how to get back out to the menu - usually this is some combination like Vol+ and Vol- simultaneously or R+L+Start).

A lot of thought obviously went into its design. It's sleek, small, comfy, durable and practical. It has plenty of connectivity and hacking potential (even the F-200). It works well and is sturdy. Controls are obvious (Vol+ and Vol- work in EVERYTHING, just about, even though they are software-controlled) and well thought-out. The built in applications are more than good enough and substitutes are easy to come by - there's even one that makes it look and work like the PSP interface.

It could benefit from an add-on battery pack like the PSP has, especially if you can get several hours out of such a thing, even on the highest demands. And it really needs an in-built charging circuit. But apart from that it's very, very good and it should really get more attention from hardware designers.

For the next model, a "hybrid" of the first and second models would sell much better - sacrificing old functionality for new functionality isn't a good choice to make. If you could upgrade its 3D capabilities without destroying backwards compatibility (the homebrew/porting scene is far too important to just discard and try to build another), that could only be a good thing. I don't see it being impossible, even if it's only in the form of a 3D accelerator chip and a custom OpenGL library to manage it. But on many fronts it's already perfect.

The capabilities are there for networked games (at least in the F-100), but it doesn't appear that many people have used them. Maybe a small wireless or Bluetooth chip could solve that problem in a backward-compatible way (especially with the Wiimote being Bluetooth-based, it looks set to be a standard for wireless games controllers) - it's not like the drivers for such things would be impossible to port. You could easily upgrade to a 2.6 kernel (some people already have!) for the next version and open up a whole new world of new drivers you could take advantage of. You would have to tweak it, though, to ensure power-use stayed as low as possible - embedded kernels aren't exactly rare, though.

But the best thing about the GP2X is the reputation that goes with it. Nobody knows what it is, so you get some strange looks when you produce it from a pocket on the train. Some even stranger ones when someone recognises the Mario "ting" from an obviously non-Nintendo device. It is absolutely fantastic for wiling away long journeys, it has to be said, purely because of its design for a short attention span... listen to some music, read an ebook, play a SNES game, listen some more, play some Megadrive, listen some more, carry on that campaign in Crimson Fields, etc.

All in all, the GP2X has managed to do what a lot of the larger handheld console developers haven't. It turns a profit, based purely on hardware. Software is especially prevelant even though there are few "launch" titles. It's great fun and well designed. And it has a community effect that's unmatched.

Here's to a GP2X sequel that's even better!

Why can't my computer...

There are a lot of things that annoy me about computers, or more usually, Windows in particular.

Why can't my computer:

1) Accurately gauge how long it will take to do something? (Prime Culprit: Windows)

File copies, program installations, downloads, no matter what it is, if it's got a progress bar it's not going to be accurate. Not only will it not be accurate, it won't even be close most of the time. Sometimes, granted, it'll be spot-on but that's just got statistical averaging written all over it. Why, in the middle of a file copy, does it suddenly decide that it's going to take 3 days, no, 10 seconds, no, wait, 18 hours, no, hold on, ... ?

Yes, not all things are predictable, but the computer could at least estimate (within a reasonable margin of error) and not blindly pick up random and wildly varying estimates without even flinching. It'd be much better if, when it gets confused or held up, it just gave up until it knew again! (KDE does do this, for instance, when copying files... it'll just say "Stalled" for a second).

2) Know where the drivers for a bit of hardware will be? (Prime Culprit: Windows)

Why do I have to point it to a driver that I've either had to insert myself or, a lot of the time, had to go to www.randommanufacturerswebsite.com/techsupport/drivers/windows/xp/driver/thingamajig/v8/revision2/setup.exe and downloaded myself before it will recognise the hardware I bought?

Why can't there be a standard for hardware so that everything USB or PCI-based contains some information that tells the computer roughly WHERE a set of drivers will be. Or, failing that, some website where it can automatically look up what drivers exist and where when given a PCI/USB id, even if it gets "Not Supported" or "Unknown" some of the time?

3) Know what I mean? (Prime Culprit: All OS)

When I type www.fredc.om into my browser, why can't it just correct it for me (maybe with a Google-style "did you mean?")? Some mistakes are hard to catch but it doesn't even catch the little ones. wwww.fred.com or www,fred,com , for instance. And when I have a file copy command, rather than just error at me because I mis-spelled or, in Linux, mis-capitalised a filename, have a small go at working out what I meant and ask me if it's right. (Yes, there are certain plugins etc. but I want it to be a standard feature. I can't be the only person who's done these silly typos!)

4) Protect me from others and myself?(Prime Culprit: Windows and Linux)

Now, I'd like to point out that this is almost exclusively a Windows problem for one part of the question (protecting me from others) and almost exclusively a Linux problem for the other (protecting me from myself). Windows just doesn't go far enough to stop other people getting into/onto/through my computer's defences. Not even after the 50th version which has promised to do so. But it has some fantastic features to protect me from myself, if they are enabled. File deletes are, on the whole, confirmed first and undoable later. Plus, it's quite hard to completely shoot yourself in the foot by, say, deleting your Windows directory accidentally. On the other hard, it's extremely easy if you are not careful to totally balls up your Windows installation just by clicking on the wrong website, the wrong email etc. or even disabling the wrong service.

Linux, though, protects you from outside elements a lot more. And even if they do get through, it is quite easy to recover from them and, additionally, their impact will be limited to the user accounts that are affected. However, even as a normal user, you can wipe out your home directory in one command without any confirmations and with little chance of getting it back unless you have specifically put into place procedures to recover it (such as replacing commands with safer versions, configuring user accounts so that they can't do that sort of thing, or just having easy-to-restore backups in place).

So it seems that Linux could benefit from a bit of Shadow Copy, a bit of System Restore or some kind of filesystem rollback and Windows could benefit from a bit more privilege seperation, a bit better programming and a focus on non-virus software rather than anti-virus software (i.e. before-the-event practices that stop the viruses getting on there so easily in the first place).

And this doesn't just apply to desktop environments. Humans make mistakes. Operating systems should be designed to take account of this fact and help where possible.

5) At least give me a clue? (Prime Culprit: All OS)

"mplayer: error while loading shared libraries: liba52.so.0: cannot open shared object file: No such file or directory"
(Note that this is an example only - when you compile mplayer from source, it does in fact warn you or leave out support when pre-requisites are missing).

Well. Lovely. Fantastic. So you know that you NEED liba52. You won't run without it. You were obviously written with it in mind. So why can't I instead get:

"Mplayer: Error: You haven't installed liba52. You can download this from http://liba52.sourceforge.net/"

Now, with modern dependency checking this sort of thing is getting rarer but even so, where's the error message that a human can parse easily? Windows does just the same with missing DLL's. And compile-time messages but not run-time messages are another bit of a bind. Fine, tell me gently at compile-time that I need libX and exit neatly. But why not do the same when I move that binary to another machine that doesn't HAVE libX, instead of erroring as above? More people RUN programs than COMPILE them. People compiling programs usually have the sense to sort such problems out for themselves (and such a trivial error is nothing compared to some of the doozies that you can get when compiling software for yourself!), ordinary users can't.

Similarly, dumbing down error messages too much is a major mistake:

"An error has occurred."

What error? Why? Whose error was it? Was it my fault? Was something wrong with the machine? Where did the error occur - in the program, in Windows, in something else? What can be done about it?

As a replacement, how about:

"An error has occurred in PartyPoker. [[Note the friendly program name]]This appears to be a problem with that program. You can try running it again, or checking for a PartyPoker update. If you still recieve errors with PartyPoker, the program gives the website address www.partypoker.com/problem as a source of help. Click below for a file which will help the program author to determine the cause of the problem."

Or:

"An out-of-disk-space error has occurred. Windows is showing you this error because it did not have enough room to create a 50Gb file on drive C: as requested by the program Nero Burning ROM. You have only 10Gb free space on drive C:. You can try:

- Clearing up 40Gb of space on drive C: and retrying the operation
- Instructing Nero Burning ROM to use a drive with more space (for example, D: currently has 100Gb free)"

6) Fix itself. (Prime Culprit: All OS)

Windows.
Windows Last Known Good Configuration.
Windows Safe Mode.
Windows Recovery Console.

Where's the "I need to get to my files" option - with a minimal desktop that uses NO programs, services or other information in common with the main Windows install and lets you copy your files off the computer before it dies completely? Where's the "Run Diagnostics" option to let Windows have a go at trying to find out what it actually wrong rather than blindly looping through a list of Windows "versions", each of which gets less and less drivers loaded? While we're at it, where's the "Check My Disks/Memory/Hardware" option in that list?

Where's the "Right, last time I crashed loading the graphics driver, according to these logs - this time I'll ignore graphics and just load a basic VESA driver and see if I can get further" logic?

And then we have the fantastic idea to include an option, which is usually the default, to automatically restart Windows on error (great, so you can't even SEE the BSOD when it whizzes past, and then Windows will blindly sit there trying to get into Windows every time it reboots until you come and fix it - it'd be better just to turn itself off!). Yeah, there sometimes a need for a watchdog on a high-availability server but on an OS designed for Home Desktop use? And what's the point of it just infinitely restarting at the same place unless it LEARNS from that mistake, especiallly if that place is before it evens gets to a desktop?

That's just the start of my list. Hopefully, I'll finish it off soon.

What does the Linux desktop need? Those who say "I want, I want..."

I've just read an article linked on LWN.net entitled "What does the Linux desktop really need?".

Let's veer slightly and ask a similar question: "What does my car need?". I'd say it NEEDED a lot less rust, a sunroof that isn't held in by parcel-tape, a new wheel-bearing (AGAIN) and something to make my lights turn on at least once in every ten tries.

Personally, I'd say it could also do with electric windows, heated front windscreen and a CD changer/MP3 stereo. But wait. Hold on. If we're saying that I can have anything I've seen on a car... I "need" braking-power reclamation, a hybrid engine, 0-60 in 5 seconds, a five-year warranty, finger-print recognition for starting the engine and GPS vehicle tracking.

Now, that's ridiculous, because my car doesn't NEED those last things, but that's basically what this article was saying. The Linux Desktop doesn't NEED anything else. It's there. It's a viable alternative to Windows. It can do anything that Windows can do (given the developer time investment). Years of development on the Windows side is now recreated in a matter of months on the Linux side - take drivers for things like newly-released wireless cards, some of which have to be reverse-engineered before a driver can be made, take some of the fancy graphical effects present in Vista, some of the desktop "features" of MacOS and Vista and there are already equivalents and copies available for Linux that can do just the same, most of which were started AFTER someone had seen those features elsewhere.

There isn't a type of application that can't be run natively, in theory. Given enough horsepower, we can even replicate the majority of Windows functions enough that high-power applications and 3D games can be run in a Windows-userspace recreation (Wine) at astonishing speed considering the technical problems of doing such things. Not only that, Linux can do virtually everything that Windows can do natively, and usually does a better job at it. There's nowhere to go from here apart from getting people to a) use the thing and b) develop for the thing, both of which are mutually dependent.

Reading LWN comments on the article are even worse... it "needs" Photoshop, Office, Games... No, it doesn't.

It's been proven - it's technically possible to write top-class 3D games and powerful image-editing programs for the Linux desktop. It's not even any "harder" than doing so for Windows. When Adobe want to do it, they can. In fact, Linux is more standardised for such things. You don't need to worry about ATI vs nVIDIA vs Intel - just let OpenGL sort things out for you.

The fact is that the desktop doesn't NEED anything, unless you are intent on recreating Windows on Linux. That's the problem - the Windows mentality isn't suitable, or compatible, with the way Linux works. Windows people want firewalls that don't disrupt their games and let any application request an open port via uPNP. Windows people want antivirus because they think they need it. Windows people want perfect connection to the heap of junk that is Active Directory. Windows people don't want to enter passwords or manually configure their hardware in order to do dangerous things, like overclock their graphics card or turn their firewall off. You can't change those people. Not without a big stick.

The way to get Linux onto a desktop is not to perfectly emulate every undocumented Windows bug and quirk when connecting to an Active Directory server for login so that some poor sap can run Outlook the way he likes, but to build a Linux equivalent that has clear advantages - faster, smaller, easier to manage, more transparent, easily portable, easily extendible and which can do stuff not seen elsewhere. The people who are more likely to make decisions based on those criteria? Large organisations. Who use networks. Which are run by a poor sysadmin somewhere who "knows" Windows but only "plays" with Linux. They don't care that Linux can detect and use 99% of all PC hardware - they care that it takes an hour to set up a new type of PC to the way they want it to be, rather than a five-minute copy of a well-known model's hard drive.

Imagine a Linux distribution. You install it in a "server" mode via a menu. Then you install it on a client machine via the same menu. At no time did you have to install drivers for monitors or some such rubbish. You don't HAVE to license it. You don't HAVE to spend days setting up the user group structure and policies to a safe default. Yeah, they'll be parts of the machine that won't work without proper drivers but that's not important. Really. These sorts of places SPECIFY the machines. They say what hardware it will or will not come with, down to the individual components. Compatibility with some cheap winmodem is not their problem - they buy a different modem, especially if it affects their security or technician's free time.

Anyway, you've started a client and server from barebones. Then imagine that you have automatic, cross-network authentication to that server, client logon, desktop settings and "policies", which allow the network administrator to change every single setting and restriction on the clients in almost every program via one directory interface. Imagine it works just as well over wireless, VPN, a Bluetooth interface or a USB cable. Just as automatic. Just as simple. Just as fast.

You can throw software across the network by just clicking on a machine in a tree-diagram on the server and deploying a package (so it'll be an RPM, not an MSI, but who cares?). Managing a thousand users on a hundred workstations becomes a cinch. And as a bonus, the machines automatically share work between them when they are idle. They automatically discover each other (with according administrator control) and use each other's storage as a mass-RAID for the network data, including encryption to stop people looking at other people's work. It does it all without needing a millions ports open. It does it all without major security problems. It works just as well from outside the network, when one of your staff takes a clieent laptop home - they plug it into their broadband, maybe they have to click an option to connect remotely instead of locally, and bam! - it's just like they are at the office.

Now imagine that you can do all that on lower-end machines than Windows could. And you can do more, stuff that just isn't possible on Windows. You can plug four graphics cards into each PC, four USB mice and four USB keyboards and now four people can use the one machine without even knowing. And their CPU power is being shared across the network, with all the other four-man machines, maybe even with the server itself doing some CPU work on their behalf when it's not busy with other things. And you wouldn't even notice that was what was going on. We're *not* talking thin-client - but you can do that if you want, too. You just tick the "thin-client" option when you install the client and the system does the rest for you.

Now imagine that not only does it do all that but you can also trust the server to backup those clients too, whether they are working locally or remotely. The server remembers individual machines and any quirks you've had to apply (that binary modem driver, that setting on boot that prevents the ACPI problems etc.) and when you rebuild them you can re-include those quirks too. Saving data to the network is transparent and not only does the server RAID all it's data, but it shares it out with the network. Server blows up? No probs. Stick the CD into any machine, create a server, maybe supply it with the old servers private key and bam - all the data feeds back from the clients to the server and the network rebuilds itself.

Well... the problem is that most of that stuff exists in one form or another. Certainly everything listed above is perfectly "do-able" and there's at least a few bits of software for every single component of that sort of system. They're not all tied into one distribution (that I know) but they are there. The most "together" distributions are the paid-for ones, Red-Hat etc. But there is nothing there that isn't possible, it might take a few months work and you could probably do it all without nothing more than existing downloads and kernel patches and a bit of bash-glue. But it's not around. You can't actually get it. And most Windows admin's won't even try it while it involves a lot of messing about. Have you seen some of the HOWTO's? Have you seen the number of steps needed to get Kerberos, LDAP, Exotic Filesystems, remote-control, VPN's, etc. all working your way? Windows is no easier, either, so you're left in the "what's in it for me" valley.

What's needed is not more and more replication of existing features but new and exotic uses. What's the most interesting part of Google? The Google Labs. What's the thing that people ALWAYS buy an OS for? The new, interesting features. Yes, when Samba can perfectly manage every aspect of AD integration, it'll be sought-after. But people scrambled to Vista "because". There wasn't anything complicated in it, there was little groundbreaking stuff and popular opinion now says that Vista is more of a pain in the backside to run for the average user than previous versions. But it was bought because it "could". It could do "new stuff" that Windows people hadn't seen before. Remember Windows 98SE that could "do USB".

People are already talking about the next version of Windows Server because of what it can do. Not about how well it does it. Not even about how easy it is to do, that's normally left until review copies appear in the hands of magazine reporters, but about what's new. And, stupidly, not even about what it doesn't do any more. The fact that every single version of Windows Server has had a hundred features announced that have never appeared is overlooked. The hype surrounding it by the time it comes out MAKES people want it. Vista was supposed to include database-style filesystems, a download manager, filesystem "filters" (Libraries), Palladium "trusted systems", integrated anti-spyware, UEFI support, PC-to-PC Sync, a full XPS implementation, to have a better UI, to perform better than Windows XP, and that's before you even get into all the capabilities that they physically removed from the OS that were there before in XP.

And the fact is that Windows Vista was just a small upgrade. If it had had ALL of those things, it could possibly be the best OS in the world. And Linux CAN have the majority, if not all, of those things. Most of them even exist for Linux right now. We just aren't using them.

People who "push" developers to make a Linux-Windows just don't get it - Linux is already in front in terms of features and technical details. We all know that. It wipes the floor with it's "main" competitor (although, to be fair, so do a lot of other operating systems). It's not that we're not "there". We are. Something else is holding Linux back. Firstly, ease of use. That's usually a big trade-off with not only compatibility and security but also with system performance. However, Linux has power to spare. And then it's just a matter of making things work without a million settings. I'm a big fan of command-lines and text-based configuration files - there is no reason to lose them. But they don't have to have vi as their only interface.

The main thing it's missing, however, is a short, simple, easy demonstration of powers that Vista and even future versions of Windows either can't or don't have. It's needs a show-distro to turn up, either from the depths of one of the established ones, or out-of-the-blue. It doesn't need that distro to say "Look at me, I'm just like Windows, only slightly better", it needs to say "Why on Earth would you bother to look at an OS that can't do X, Y and Z", where X, Y and Z are things that either have never been done before, or always been "promised" or "desired" and never materialised. And I don't mean a flashy-gui interface. The nearest we ever got to that sort of hype was the Kororaa Xgl Live CD and look at what it did - very little of any practical use. But it was NEW. It was even NEWER than what Windows could do at the time. So it got a lot of press.

Being able to access an AD domain isn't something new. It's not impressive to people. It's not even that innovative - there's a major OS that does it automatically and (fairly) reliably. What's needed is to play to Linux's strengths - flexibility, malleability, speed of development, freeform and accessible API's. That means coding quickly, easily, without barriers and restrictions and expensive SDK's. Just get in there and write stuff. In half the time it's taken Windows to get where it is, Linux has replicated and/or surpassed every aspect of Windows. Now it needs to overtake it - you can't do that by blindly copying features from Windows, or even other OS's.

Now, the article doesn't push Linux for anywhere near as much as the comments on LWN. To them I say: Just because Windows does something, doesn't mean that Linux should follow suit. It that were the case, Linux would BE Windows. I don't WANT my Linux desktop to have a built-in GUI firewall that's difficult to configure the way I want. I don't WANT automatic update dialogs that are a pain to turn off. I don't WANT something to automatically detect all wireless networks the second it sees a wireless card.

On the software front, what would be the point of "getting" Exchange, Adobe, Office as Linux-native versions or equivalents. By doing that, you would have to integrate a significant portion of Windows infrastructure, including Active Directory and DirectX. So what you've done is made a "free" version of Windows. Whoopee. Everyone who's currently using Linux is using it NOW while it's not a version of Windows... why? Because it's BETTER. It isn't bound by some stupid corporate decision or two decades of backward compatibility quirks.

Take a look at some edited highlights of Vista SP1:

Performance improvements
New security APIs
A new version of Windows Installer, version 4.1.[47]
Users will be able to change the default desktop search program
Support for the exFAT file system (FAT extended for USB sticks, basically)
Support for 802.11n.
Terminal Services can connect to an existing session.
IPv6 over VPN connections.
Support for booting using Extensible Firmware Interface on x64 systems.
An update to Direct3D, 10.1.
Support for the Secure Socket Tunneling Protocol.

What's there that Linux won't have by the time it comes out, if it hasn't got it already? What's there that Linux couldn't do? Nothing. And to be honest, as a changelog for a major upgrade to even a stable release of an OS, that's pretty pathetic. What about Server 2008? It's all pretty much the same. There's nothing in there that Linux doesn't already or couldn't do with a year or so's work.

Let's stop faffing about asking Windows users what they think they need from a Linux machine. Let's SHOW them. Let's just get stuff done and forget emulating Windows. We all know that Windows has it's death coming to it. The longer we give it credibility by attempting to copy everything it does, the more time we waste away from the interesting stuff, the stuff that will have people hooked. We have SELinux, we have file-server compatibility, we have directory management software, we have all of this but nobody cares. We need to show stuff that Windows can't do.

We need a five-machine network that can outperform the best Windows servers and individual desktops, when both are running 20 simultaneous clients (as in four people ACTUALLY WORKING on each of the five machines, locally). We need filesystems that "heal" (and not like self-healing NTFS in Server 2008 which is basically thread-safe Scandisk), network filesystems that can let Google do it's job without worrying and with which small companies no longer need to worry about tape backup (although, obviously, they still could) - which adds 50% to the price of any server.

We need perfect, logical, simple directory systems that can do stuff that Windows AD can't even dream of, in an easily editable/recoverable/backup-able format - it doesn't matter if it's Fedora Directory Server or Apache Directory Server - no-one cares. We need it all to run, automatically but securely. We need automatic secure communcations across a network to pick up new machines and integrate them directly into the Directory. We need systems that (with proper admin control over the process) auto-patch underneath systems that are still running. We need one-click Setup, Trusts, Backups and merges of entire Domains.

We need client systems that can repair themselves from known-good images (which, hell, should be stored in the cross-network filesystem) while they are still working - no, we don't acquire viruses but you still need to Ghost stuff back sometimes. We need machines that detect faulty hardware and compensate automatically - memory just failed in the server? Fine. Isolate the memory areas responsible (BadRAM), alert the admin, allow them to work-around the problem temporarily until they can get a replacement, restart and check all services and then carry on like nothing happened. And all the time you spotted it where Windows would have just crashed.

We need systems that can tolerate as much failure as possible. Primary hard drive or RAID array failed? Warn the admin, carry on as normal, read what you need off the network. Network failed? Route around it, over a USB connection if the admin only has a USB cable left, or FireWire, or wireless, or Bluetooth, or Serial, or Parallel, or... We need a real, "intelligent" help system. When it sees that admin hunting through menus looking at DNS settings, it tries to (unobtrusively) help. It brings up a checklist and works through things one at a time by itself until it says to the admin "The DNS server is fine. But you forgot to point that client machine at it." or "The DNS server doesn't have a reverse-DNS for that IP, that's why what you're trying isn't working".

We need systems that collectively monitor, detect and shutdown other rogue systems within their sight, a kind of distributed-IDS built into the system. We need systems that do all this 100% securely, with full certificate-chains and verification and let the admin control exactly what's going on if he wants. And when someone breaks that particular method of encryption? Ah, just choose one of the thousand-and-one encryption methods and do a one-time re-encryption to change every server, client and software over. Well, yes, do pick up local Windows systems and tie into them as much as you can but forget making that a priority. Set NEW standards. Make people say "I absolutely NEED a system that can do that." Let the other OS manufacturers play catch-up for a change.

Let's stop playing catch-up. We already won that one, there's no competition there any more, there's no more fun to be had. Let's start wiping the floor. Let's get JUST ONE feature in that people decide they absolutely NEED. And let's do it before Windows can even get a sniff. Let's do it so that, when the time comes for Microsoft to replicate it, they want to be able to read OUR code in order to get it done well enough. Let's stop playing about asking 90-year-old grannies why they don't like Linux when they know nothing BUT Windows... their answer will always be some variant of "It's not like Windows".... either that or "That penguin is scary". Let's make the people that are really scared of the Penguin be Microsoft and Apple. Because, at last and for once, they can't keep up with Tux.

Essential Linux Utilities

Ever since setting up three Linux PC's in a row, I've realised that I've grown dependent on a few pieces of software for Linux, above and beyond what comes with a standard distro (or, at least, Slackware).

Beep - a tiny util that can beep the PC speaker in a variety of ways, perfect for headless systems. I use it to give a warning tones inside boot scripts and also to provide a rising or falling tone on the start or end of certain tasks, such as booting or shutting down. Because it uses the PC speaker, it doesn't interfere with ALSA, works on even the oldest of PC's, doesn't necessarily require an external set of speakers etc. Beware using it, however, on multi-user installations - I tend to keep it restricted to the audio group of users only to stop people messing about with it.

Ether-wake (available from various places, originally by Donald Becker) - the ultimate power-saving util... this is a Wake-on-LAN packet broadcaster to wake up computers that support WoL from their deep sleep (i.e. turn them on so long as they are plugged into the net and have a power cable in them). With this I keep my home network largely turned off and "wake up" (i.e. turn on) particular PC's as and when I need them. And larger scale experiments have shown that there's nothing better than the sound of a room full of PC's all booting up simultaneously at the click of a single button / cron job.

HTop - a better version of "top" that I find easier to use. Shows processes and RAM usage in a nice controllable text-mode GUI that allows you to kill individual processes, scroll up and down etc.

rc.firewall (See this post for a mirror) - a perfect, simple, one-file iptables firewall that works well as rc.firewall in Slackware. Works for single computers, NAT'ing routers, multiple network cards, multiple-networks-on-a-single-card, and lots of other configurations. It uses a simple syntax for even multi-port port-forwards, has many simple options for various things such as allowing or deny ping's or cross-network traffic, has a very strong default configuration and can be reloaded at the drop of a hat at which point all the detected network interfaces are re-firewalled.

x11vnc - This is one of those utilities that few people ever use. It's a vnc server for X. But it has a vital difference... it's a VNC server for EXISTING X sessions. Most people are familiar with xVNC which allows you to spawn an entire X-Windows system where each "screen" is actually a VNC session (thereby providing instant-VNC-thin-client) but that's not much use to someone that has a single-user Linux PC who wants to log onto their home PC and click on that link that they left showing in their browser. x11VNC does just that - the command-lines get horrid very quickly, you have to pay close attention to the security of the thing (because now connecting to the PC on port 5900 is the equivalent of logging in as yourself on the local PC!) but it's a great piece of software. The author is also working hard to make VNC-wrapped-in-SSH a cinch, even from Windows PC's, by extending the TightVNC clients to incorporate SSL tunnelling. Yeah, you can now do this with some things like KDE's Remote Desktop functionality but I've been using this particular utility for so long that I have scripts which build-on to it and it also has some features that just aren't present in other imitators.

knockd - a simple port-knocking daemon implementation which can be triggered remotely using either a tiny utility that works on Linux/Unix/Windows or by simpler tools such as telnet. Perfect for securing a server for remote access (and incidentally the best way to stop random port probes to your machine - my SSH logs were filling up until I found this) as you can just put the portknock client on a usb disk or a website and download it from wherever you happen to be or you can even "bodge" one in a real emergency. Also, the configuration basically consists of port-sequences and names of scripts to run. This means that it's easy to configure it to see port-hits on ports X,Y,Z as an instruction to run an "open" script and then you can hit ports Z,Y,X to run a "close" script. And because you can have multiple port sequences running, it's very easy to have all sorts of different things happening. See my article here for a bit more background on my use of this utility.

Mirror of Projectfiles.com / lfw.sourceforge.net rc.firewall

Having just completed a set of instructions for a group of Linux newbies on how to set up a firewall, I then discovered that my favourite Linux iptables firewall script has all-but gone from the Internet. I checked Google, both "official" websites (including the Freshmeat.net mirror) and archive.org. Still no joy. Luckily I had kept a copy of this GPL script, which I have mirrored.

For those people who have had trouble finding the script that's been hosted at both ProjectFiles.com and http://lfw.sourceforge.net you can download the rc.firewall script at the following address:

http://www.ledow.org.uk/linux/

This is the 2.0 "final" version. I have the documentation mirrored too. Oh, and I assume that the reason that the archive.org site has no mirror is that the author wants no more to do with it. So be polite if you do need to contact them (the above file has their email address etc.) and don't bother me for support, either! (You probably couldn't afford me!).

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.

Slackware 11.0 RC-1

The next version of my favourite Linux distribution is on the verge of being released. Yes, Slackware has it's first 11.0 release candidate.

Normally, I don't chase the very latest versions of software until someone's tested them for me beforehand - for instance, my latest foray into the world of Opera version 9.0 was a bit dismal... most of the computers I installed it on had no problems at all but at least two showed severe random crashes that I could not track down for weeks. The funny thing was that both problematic installs were on different hardware and yet on two very-similar machines one version of Opera 9.0 worked flawlessly but another didn't.

Anyway, unusually for me, I've been closely tracking Slackware 11.0 since the last stable release, 10.2, which is currently powering my main desktop and a number of my servers and hobby machines (I always track updates to stable versions so my software is never vulnerable but I rarely use "beta" software of any kind). I've actually got an up-to-date mirror of the bleeding-edge -current version of Slackware (that will become 11.0) which I update every time the Changelog changes. I'm hoping in this way to not have to suffer traffic-lock when 11.0 is finally released - hopefully at worst a tiny update of a handful of packages will be all that's needed to create my own DVD-R instead of having to fight thousands of people trying to download all 4Gb of software swamping every mirror with traffic.

I have even gone to the effort of a test install of the RC-1 version on a seperate partition. Linux, and Slackware in particular, demonstrated its flexibility and user-focus once again - by booting from a Slackware DVD, I was able to install the full install to a blank partition without doing any more than a very basic check of the partition name (which I am always very careful to double-check by mounting the partition in question - never take partitioning or formatting of anything on a PC full of data lightly). Once it was installed to my spare partition, I was able to copy the kernel and modules directory from my "stable" partition to the new "current" partition and, with a little LILO magic, boot into the new version of Slackware without touching my previous installation in any way, but with the very latest 2.6 stable kernel and all the software of 11.0.

I have to say that it's not spectacular but it's not spectacular because it WORKS. It just does what you tell it. You boot it on your PC, it detects all your gear, you set a few options and you have a full desktop. You port your old settings and files over and everything just works again.

The simple fact was that, in under three minutes of the installation completing, I was in a fully kitted out Linux desktop with drivers for all my hardware without having to compile a single package - installation consisted of nothing more than an automated decompression of the packages to the partition in question and minor copies or edits of my previous configuration files (such as re-doing alsamixer settings, configuring X etc.). My old software worked (at worst requiring a recompile against latest headers), my settings transferred and my computer didn't crash or have to reboot seven zillion times.

New in Slackware 11.0 RC-1:

* Updated kernels (although the default still looks set to be a 2.4 kernel)

Obviously, although I would say that the kernel is the one thing not worth waiting for a Slackware package to come out for - just install the latest stable of 2.4 or 2.6 depending on your tastes... Slackware supports either seamlessly without needing any special setup (although you may find it convenient to stick with one of the two for compiling anything that reads from kernel headers). Don't forget that Slackware always comes with a .config for it's kernel that's fully modularised and ideal for "make oldconfig" when a new kernel comes out that you need to compile.

* Lots of init script fixes and features

* Updated hotplug / udev support

* X.org 6.9.0

* KDE 3.5.4

No more Gnome in Slackware unless you get it from somewhere else. Not a bad thing for me, given that Gnome always reminds me of the old Borland dialogs in Windows - it always looked clunky and out of place. You can still get Gnome for Slackware from many places but it was removed in the previous version because of an apparently horrid compilation rigmarole.

* Updated versions of just about everything else (Samba, Apache, MySQL, Java etc.)


The changes aren't massive - it's not even as if the previous version has software which is currently vulnerable (despite what some checkers may tell you if they only go by software version number rather than whether they've actually been patched!). The software isn't the very latest (but it is almost guaranteed to be the best tradeoff between features, security and code stability) but it's clean, it's quick, it's simple, it works and it's been designed to run on as many computers as possible by default.

Although not designed as a desktop distribution, it's easily subverted to that purpose by installing the right "extra" software but the fact is that you know what you are getting - a stable, safe system that works and is flexible.

I get to choose and keep my own firewall package - one I've grown to love and have integrated lots of my other scripts into, I get to keep my choice of kernels and even whether to go 2.4 or 2.6. Every piece of software has been updated but all my old settings port over easily (at worst requiring a diff of some sort). Every piece of hardware has modules ready-prepared for it so there's no need to keep recompiling to get support. The kernel is bog-standard kernel.org fare, so there's no vendor patches or compatibility problems to worry about. Everything is controlled by human-readable scripts, which upgrade cleanly over previous versions.

I'm planning on building some kind of workhorse headless server and it looks like Slackware 11.0 is going to be my choice, given it's proximity to release and its easy flexibility to be installed without X or other useless software. This server will be performing lots of tasks which I'm hoping to come to rely on - CCTV monitoring and other household security tasks, intranet web serving, firewall, NAT, printer server, transparent HTTP proxy, automated network antivirus scanner, email scanner proxy, Caller ID announcer, wireless gateway, network boot server and all manner of other custom projects. It will use relatively modern hardware, will require stability (as it will be expected to be running all day long), will not need any sort of graphics capability and have to be secure against attack. I don't want to have to compile anything from scratch or find out that I've forgotten package X, so a full install and then prune will be in order.

Slackware's reputation means that I'm quite happy to have waited nearly a year for this release - I haven't had a vulnerable system in that time due to strictly-monitored security fixes for the -stable version, I haven't had to fight with half-new features in things like udev and hotplug which would have caused me a lot of trouble and I'm going to a system that's just as stable albeit further updated.