A static image like this doesn't really do it justice. The colors sort of slide
along its length, giving the illusion of motion. I just did rectangles; then someone else came along and added other shapes, like the hexagon you see here.
I also did most of the "mandelbrot" mode in
. This is a subregion of
a "power 3" mandelbrot set. Actually, I have no idea if this is officially
called a "power 3" mandelbrot set; I just took the mandelbrot set equations
and changed the exponent from 2 to 3. The mode does a variety of exponents,
with a random-but-interesting subregion selection. It also slides the
colors along; the code for the color cycling is derived from the color cycling
in the above "tube" mode.
And I did the "ellipse" code in xlockmore. Strangely, this is the
only code of mine that got ported into
xscreensaver, even though I
personally like tube and mandelbrot better. This is very basic
trigonometry. Here's a picture:
I also wrote newstosgf. newstosgf is a python program that reads a
usenet article from rec.games.go on standard input, and outputs an "SGF"
file suitable for use with an SGF viewer. This makes the ascii diagrams
found on the group much easier to read. You can get the program
here. If you
use trn to read news, viewing an ascii diagram is as simple as typing
|newstosgf. If you use a lesser newsreader that can't pipe, you'll
probably have to save the article in a file and say newstosgf < filename.
(Ok, the actual appearance depends on the SGF viewer you choose, but you
probably get the idea)
Here's a picture of Kentou 1.09:
Kentou is a program that reads an SGF file, and lets a student of go
play back through it, trying to guess the next move in the game.
After 10 (by default) incorrect guesses, it gives you the right answer, and
it keeps a running average of how many guesses it took across the
moves you've looked at so far. It marks near misses and distant misses
differently, and plays a sound for correct guesses. Many people say
studying pro games is
a good way for an already-strong go player to advance, and a few
think this is a good method of study even for less advanced players.
You can get the source code
This is a picture of gquiz.
It's for drilling yourself on questions and answers.
It's set up pretty generically, so you can use it to quiz yourself about
almost any subject, but I wrote it to facilitate studying
go problems for myself.
I reimplemented this, this time in python - the source is
I think it makes kind of an interesting "eggcartonish"
background for your computer's background/wallpaper. It looks pretty 3D when
you set of bunch of them side-by-side - it even makes some people a little
dizzy to look at it. :) It'll probably look banded, and hence less
3D, if you're using an old 8 bit display.
The program that generated this is a small application of
the inverse square law - like gravity.
I also wrote a program called "IQS". It's a coarse-grained scheduler.
It's sort of like a batch queuing system, except you don't have to
run a special submission program - if you run something CPU intensive,
IQS is supposed to notice and start managing it automatically. Here's
a snapshot of an xload taken over an interval in which IQS was
detecting and assuming management of four CPU intensive programs.
I also wrote a program called "cobble". It just looks for a .tar.gz (or a part01, &c), extracts it, and tries to build it by xmkmf'ing or configure'ing and making - or whatever. I like to think it influenced the debian .deb package format, which in turn influenced the redhat .rpm package format.
And I wrote a program called
It takes an arbitrary program, and runs it as a daemon. Note that it
doesn't close filedescriptors; some people consider that part of running
as a daemon.
I also wrote "limited-fingered". It's a very simple finger daemon, that allows users to
turn off finger requests for themselves, and also allows the administrator
to turn off all inspecific finger requests. It's written in python, so it's
relatively likely to be secure, unlike programs written in C.
And I wrote plpd. It's a very lightweight print system, clearly inspired by the BSD printsystem, but much simpler. It too is written in python, making it relatively unlikely to have
And... I wrote "toaster". It's a security tool for people who don't care much about learning how to secure a system.
I modified the linux yppasswd command - to add a decent password
check, so users are unlikely to unknowingly choose poor passwords. You
can get the source code here.
I wrote maxtime. It's a program intended to ensure that a command won't take longer than a specified interval of time to complete. If the command takes too long, it is killed. If the
process is unkillable, it is backgrounded with lots of deadly signals pending, so the foreground can continue on with other things.
I wrote a benchmark called working-set. It tests how much memory overhead an operating system has.
I also wrote a go-playing program,
based on machine learning, called "goo".
pretty badly; I wrote it at a time when I didn't understand go even as much
as I do now :), and the program's strength unfortunately reflects that fact.
It was a very ambitious project - even though I was just hoping for something
at a level stronger than I was, so I could learn from it, but alas, it didn't
even do that. Really,
the implementation of my chosen approach went fine; the problem was that
the approach was quite simplistic, while go is extremely intricate. The source
code is available here.
And I wrote a symbolic matrix manipulation program called "symmat".
It allows you to use matrices with both numbers and variables, and get
a reasonable matrix multiply (for example) out of it. I wrote it when
I was taking a computer graphics course, long before I'd heard of anything
like "matlab" and clones; the idea actually seemed novel at the time. You
can get the source code
here. Sample input
looks like this:
push 4 4
1 0 0 0
0 c s 0
0 -s c 0
0 0 0 1
push 4 3
d 0 -t
0 1 0
t 0 d
0 0 0
As you can perhaps tell, it's stack-based (uses reverse-polish notation). "pop"
displays the matrix on the top of the stack on stdout. Output for the above file looks like:
d 0 -t
s*t c s*d
c*t -s c*d
0 0 0
I also wrote a collection of programs for dividing files into equivalence
classes. There's another program that does something pretty similar, called
"classify". In comparison, classify has more flexible options and is more
user-friendly, but equivs is much faster on large collections of files.
You can get the source code
Algorithmically speaking, classify is O(c*n^2), while equivs
is O(d*n^2), but c>>d. Then there are equivs2 and equivs3, which are
Anyway, as an example:
network-stats-collector-1-strombrg> time classify * > /tmp/C
network-stats-collector-1-strombrg> time equivs * > /tmp/E
network-stats-collector-1-strombrg> ls | wc
329 329 6324
So as you can see the difference in speed is
fairly dramatic, even just for equivs 1. (All the files were in the
buffer cache at the time of both runs)
I guess I should mention some of my contributions to Linux in the early
days. This was around 0.13 or so, when Linux was still distributed on
two floppies. I did the first
port of Julie Haugh's shadow password suite, and
a couple of things required for that, including an m4 port (not the GNU
m4, a different one), a tweak to the kernel to allow a /bin/login to
not echo passwords, and sdbm. The shadow
password suite historically hasn't been
well-integrated with Linux because Linus felt Linux should stay light-weight,
and he didn't consider the shadow password suite light enough.
I also wrote "replacebell", which can be used to give X windows a more
interesting default bell sound. The source is
1.03 and up fix the annoying defunct process bug. The current version is 1.04.
Finally, I wrote ppmdist, which is a part of the
package of graphics utilities. ppmdist isn't all that different from
ppmtopgm in that it converts from color to greyscale, except that if you have
a color image having (just for example) three colors - the background, and
some foreground stuff in a blue and a green of equal brightness, then with
ppmtopgm it'll be hard to tell the blue from the green in the resulting
image. With ppmdist, the contrast between the blue and green is maximized,
making it relatively easy to tell them apart in the B&W image. ppmdist
works best with low-color computer-generated images; if you use it on
something with a lot of colors, it's pretty hard to tell any difference
I hope you'll enjoy one or more of these.
I've written other things too of course, but some were for dead systems
(atari 400/800/1200, apple II, commodore pet and 64, ms-dos), and some I
can't give away. And of
course, some just aren't interesting enough to mention. :)