Linux

Linux is a free (GPLed) POSIX-compliant kernel that runs on 386-based PCs (including 486s, Pentiums, Cyrix 586s and what have you), and DEC Alphas, and is being ported to other platforms including SPARCs and m68k machines. Together with the freely available software base that GNU and other people have written, it provides a complete Unix-like environment. It's small(ish), fast, neat, really very nice, and comes with complete source code, but go and look at a more official site for the hard sell and general information. This page just advertises my bits. Ahem.

Which distribution? I don't run any recognisable distribution on my own machine, (though it started life as MCC, it's been chopped around more than a little bit since). I do recommend Red Hat, though, and will install it on anyone else's machine given half a chance. Debian is also reputed to be quite nice, though I haven't actually tried it.

HOWTOs

are the preferred documentation form for a lot of linux information (don't ask me who prefers them; they're just `preferred', ok?). Of the thirty-odd now in the series, I wrote the ELF one, and butchered Mitchum DSouza's fine GCC FAQ to create the GCC HOWTO. The latter is new; any and all comments on it would be appreciated.

For the rest of the HOWTO collection, try Manchester Computing Centre if you're in the UK, or SunSite if you're not.

GCC/libc development

The developers of the Linux C library have a mailing list on which they discuss these things. Following the other fine linux tradition that `you're not a real hacker unless you get lots of junk mail you can't understand', two hundred other people also subscribe to it, and tend to make their presence felt by asking questions. Often the same questions as each other. In an attempt to reduce the need for this, I keep a gcc/libc development web page. Because I'm basically nice, and because it gives me an excuse to ask exactly those questions under the pretext of benefitting other people.

See also the list archives.

Kernel stuff

As soon as my proper net connection comes back, I'll again be playing with kmalloc, the in-kernel memory allocator for small amounts of memory.

Minor league hacks

Anything else I've done that I feel like sharing with the world:

1. autoconf. Autoconf 2.4 and later versions look at a small script to set up things like CFLAGS, --prefix and the rest, which can also be used to make it preserve a shared cache file over multiple invocations in different directories. On a slowish machine like mine, this speeds it up dramatically. Here's my /usr/local/share/config.site. Note also the stupid things it does if it spots that the current directory is under /opt. This is intentional.
2. ded is a command line editor for programs that take a lot of input and don't have their own. It's pretty trivial (the difficult bits are all done by GNU Readline), but you might find it useful.
3. install. Like many Linux and free software bigots, I like to have the source code for everything on my system. However, simply untarring all the packages in /usr/src/ is messy and renders the shell's filename completion a bit pointless. What I do is unpack them more or less anywhere (the current strategy is to group packages by configuration mechanism --- all autoconfed programs go in one directory, all imake programs in another, etc etc), then use this install wrapper to set up links for each installed command from /usr/src/usr.bin (or wherever else it installs into) to the source directory.
4. kernel installation. Not a lot of people know this(tm) but if you write a script /sbin/installkernel, `make install' in the kernel source directory will run it. This is mine, and this is the Perl script it uses to recreate lilo.conf. The latter can also be used when you get bored of all the accumulated kernel images in / -- just delete them and run it again. It will require editing for your setup.
5. talkd. Talk is possibly the most stupid program that ever came out of Berkeley, and if everyone using it could be persuaded to switch over to some newer thing that was actually compatible across the net a Good Deed would be done. Actually, if even a third of the people currently using talk would switch, this would ensure as high a degree of interoperability as is currently the case... This patch doesn't attempt to fix any of the above or other world problems, but does add the feature from write to follow the user around ttys instead of always using the first one that it finds in utmp. This means for example that you get talk requests in the xterm you're using instead of in the textmode tty you started X from, and if you leave your screen locked when you go home then dial in you'll get the talk requests on the tty you dial in on instead of them going to your X display in the office. Whatever. Apply it to more or less any NetKit-B-0.0x (the kind with the version number), available from all good linux ftp sites. It includes an update to the talkd manual page, which makes it marginally less lousy. It's still pretty lousy though, frankly.