This is a list of some of the programs I've written and given away. I put the "eye candy" at the top of list, so to programmers the most interesting bits may be at the middle and bottom.

  1. I did most of the "tube" mode in xlockmore
  2. I also did most of the "mandelbrot" mode in xlockmore
  3. . 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.

  4. 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:

  5. 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.

    In other words, it converts this:

    ...into this: (Ok, the actual appearance depends on the SGF viewer you choose, but you probably get the idea)

  6. 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 here

  7. 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.

  8. I reimplemented this, this time in python - the source is here. 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.

  9. 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.

  10. 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.

  11. And I wrote a program called "daemon". 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.

  12. I also wrote "limited-fingerd". 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.

  13. 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 security problems.

  14. And... I wrote "toaster". It's a security tool for people who don't care much about learning how to secure a system.

  15. 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.

  16. 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.

  17. I wrote a benchmark called working-set. It tests how much memory overhead an operating system has.

  18. I also wrote a go-playing program, based on machine learning, called "goo". It plays 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 that played 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.

  19. 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: 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:

  20. 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 here. 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 both O(nlogn). Anyway, as an example:
    network-stats-collector-1-strombrg> time classify * > /tmp/C
    
    real    2m39.318s
    user    0m4.640s
    sys     0m35.660s
    network-stats-collector-1-strombrg> time equivs * > /tmp/E
    
    real    0m6.197s
    user    0m2.580s
    sys     0m1.110s
    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)
  21. 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.

  22. I also wrote "replacebell", which can be used to give X windows a more interesting default bell sound. The source is here. Versions 1.03 and up fix the annoying defunct process bug. The current version is 1.04.

  23. Finally, I wrote ppmdist, which is a part of the netpbm 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 from ppmtopgm.



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. :)


2300

Back to Dan's tech tidbits

You can e-mail the author with questions or comments: