This is an amazingly random collection of, mostly technical, documents, and self-contained postings to various, private or public, mailing lists and usenet newsgroups. They are published here in the hope that others might find them interesting or useful. Comments, corrections, and suggestions are always welcome; send them to:
Nick Patavalis <npat [at] efault [dot] net>If you are boggled by the randomness of this collection, at least keep in mind that it has precedent: Back in 1972 the legendary group of MIT AI hackers circulated a text under the name "HAKMEM" (from "Hacking memorandum"). It contained an amazing, and amazingly random, collection of stuff. Articles in hakmem spanned an unbelievable range of topics from simple display hacks, to mathematical riddles, questions, theorems and games, to schematics for building RF receivers and transmitters. An online version of HAKMEM is now available (and be assured, it's vastly more interesting than my collection!)
Still with me? Fine!
Hunter S. Thompson had a thing about motorbikes not much unlike the thing he had for drugs. Once he found himself with a Ducati super-bike and he had to write a review about it for the CycleWorld magazine. The result is a very characteristic document (classic in the HST style), which I attempted to translate to Greek. These are the results of the attempt...
Simple instructions for using the Greek dictionary of aspell through Emacs's ispell interface. This text assumes that you already have a working aspell installation and that you can process Greek documents with it.
In which the author tries to make his home-network accessible from the outside. The fact that the network is connected using a dynamic ADSL account, and the presence of an erratic ADSL IAD, thicken the plot considerably.
A non-hacker friend of mine read an entry in my weblog about a guy trying to implement a Lisp-CPU---inspired by the famous Sussman / Steele, AIM-514 memo---and asked the obvious question: "What's a Lisp CPU?". While there are many ways to explain this to someone with a bit of mathematical background, there seems to be no easy way to convey to a non-hacker the meaning and, most importantly, the multiple cultural and "religious" (so to say) connotations this term has for certain hackers. Instead of muttering some gibberish about lambda calculus, I decided to write this. Well... I wanted to write something like this anyway.
These are detailed instructions on how to build from scratch a cross GNU-toolchain hosted on ix86-based linux machines and targeting sparc-based embedded systems, plus a GNU standard library for the target architecture. Very similar procedures can be derived from this text for building cross toolchains and standard libraries for other host and target architectures. The term "from scratch" above refers to the fact that absolutely no sparc cross-development tools, no pre-compiled sparc system libraries, and no native sparc development environment, of any kind, are assumed already available. Apart from the host-native (ix86) tools, everything else will be built from sources. This is a very common case if the cross-toolchain is to be used for embedded-systems development.
Originally published: Posted to the gnu.gcc.help newsgroup, 09 May 2003.
A detailed description of some of the net_device features found in "SoftNet" (linux 2.4 networking stack) that can be used by device-driver writers. Focuses on features that can be used by DMA devices, and scatter-gather DMA capable ones. Also discussed are features relating to "checksum offloading" in the upstream (receive) and downstream (transmit) directions.
Originally published: Posted to the linux-net mailing list, 17 Sep 2003.
A document presenting guidelines on how and where to install stuff in a Linux or Unix system. Covers the installation of packaged software (e.g. RPMs or DEBs), installation from source-tarballs, as well as installation of software that doesn't follow the "Unix tradition" very well. These guidelines have been checked against and comply (almost fully) with the FHS (Filesystem Hierarchy Standard) 2.2, used by many Linux distributors. Please keep in mind that this document presents only suggestions on policy and not a description of the underlaying mechanics; that is, it assumes that the reader is already familiar with package installation and management tools. Written after the realization that, at inAccess Networks (the company I'm working for), entropy had started to take over the structure of one of our older development servers ("orion"), and was seriously threatening a younger one ("dmz").
Originally published: Never published. Distributed among the inAccess Networks se-group members, on a private mailing lists. First posted: 21 Jul 2002
An unfinished document intending to describe the mechanics and to present a detailed methodology for tracking 3rd party sources using CVS. The "mechanics" part is reasonably complete. The "methodology" has been removed, since it was in no way complete enough to be generally useful. Published here because---even in this unfinished stage---it contains some nice figures and a useful discussion on how CVS versions and branches work.
Originally published: Never published or circulated, written: Oct 2002
This posting contains a SPARC assembly code snippet that calls a C function to handle a trap (interrupt). Since SPARCs use a windowed register scheme, special care must be taken in order for window-overflow and window-underflow traps to be handled correctly when running the C ISR code; this is a bit tricky. Though this was originally posted as a question ("is this the right way to do it?") it has since been used extensively, and is, I think, correct. I dealt with this issue when porting micromonitor to a LEON2-based platform, for an inAccess Networks project. The micromonitor port has not yet been published, but I expect it to be soon.
Originally published: Posted to the leon_sparc mailing list, 4 Jun 2003
How can one write a function that appends to a shell (Bourne or BASH) variable? This posting contains a suboptimal solution proposed by your's truly, and the correct one by Stephane Chazelas. If you come to think of it, it's quite a tricky problem!
Originally published: Posted to the comp.unix.shell newsgroup, 9 May 2003
A musing about an obscure property of the C language, namely about "sequence points". This issue has haunted many a C projects, including several parts of the linux kernel. It basically boils-down to what happens with an expression like: "a = i++ + i++"
Originally published: Never published. Distributed among the inAccess Networks se-group members, on a private mailing list. Posted: 4 Sep 2003
This is a short review I've written for the adventure game (interactive fiction title, if you prefer) "For a Change"; a game written by Dan Schmidt, and considered one of the most experimental interactive-fiction works. "For a Change" presents such a playfull and irrational approach towards language, that directly reminds us of the works of postmodern, or absurdist playwrights.
Originally published: Appeared at SPAG (Society for the Promotion of Adventure Games) issue 22, 15 Sep 2000
Another short adventure-game review. This time it is for "Curses", a game by Graham Nelson. Nelson is the author who contributed more than anyone in revitalizing the medium, after its seeming demise at the end of the "commercial era", and the rise of "graphical adventure games". "Curses" is the game that epitomizes the history of text adventures, and opens the door to the new interactive fiction era. If there is such a thing as a "modern classic" in the world of text adventures, then "Curses" is definitely it.
Originally published: Appeared at SPAG (Society for the Promotion of Adventure Games) issue 22, 15 Sep 2000
Have you ever considered how nicely, or how badly, the C-compiler treats your carefully-crafted C code? How the assembly it produces looks-like, and in what extent it reflects the structure of your source code, especially when inlined function calls are involved? This posting discusses the code produced by GCC for a simple linked-list operation (a node addition). Don't expect a lengthy and well researched analysis; this is a simple FYE musing showing how close C can sometimes be to assembly.
Originally published: Never published. Distributed among the inAccess Networks se-group members, on a private mailing list. Posted: 12 May 2003