The Slashdot Capable i486

EDIT: I started to write this post on 2008-06-21. Blogger says that I posted then, but I actually just posted this yesterday: 2008-06-30.

Since well over a year ago I have had a dream to setup a 486 capable of being Slashdotted, Dugg, Reddit'ed, or being put on any major news site. I wanted it to have some useful dynamic content, be accessible over IPv6, and have as few hacks as possible, while running Icadyptes.

**Long post warning!**
This post is a long read, though I think it would be worth reading. However, here I will try to summarize my adventure:
foureightysix.go-beyond.org is powered by a Intel 486 DX/2 Overdrive capable of 66Mhz but running at 40Mhz due to motherboard limitations (it also does not have any L2 cache), and 16MB of 60ns 72 pin SIMM memory. The harddrive is 631MB (original 428MB harddrive died), and gives 1.5MB/s of read speeds with 10MB/s to the IDE controller. The site displays the top 20 hits by referrers, and has a bottom 30 FIFO for hits by referer to enter the top 20 (better explained below). The script used by the 486 is written using the WebLua FastCGI API for Lua that I hacked together. The server uses Lighttpd as its HTTP daemon, and is only connected to the IPv6 internet. To connect with the rest of the world, my go-beyond.org server proxies IPv4 requests over IPv6 to the 486. This post may be a little bit confusing for those who are not technically inclined, but in layman's terms, I put together a computer equivalent one from 1992~ which hosts a dynamic website that is (theoretically) capable of withstanding Slashdot, Digg, Reddit, etc.

The Slashdot effect is often considered one of the most brutalizing tests any webserver can bear. This site gives a good summary of the Slashdot effect, along with the results that other highly used news sites can bring. One person whom had his site Slashdotted received approximately 100,000 hits in 12 hours. I prefer to bring this down to a more benchmarkable requests per second amount. 100000/(12 hours*60 minutes*60 seconds) = only 2.314 requests per second. But how many are at the peak seconds? Forty or more?

Most websites that participate in this phenomena usually have lots of useful data; many times dynamic. Dynamic websites are quite often written with heavy PHP and SQL backends; my testing shows that a 3.4Ghz P4 can only push around 11 requests per second of a (non-optimized) very basic Drupal 6 site with no caching enabled. With caching, that figure is about 6-9x higher (though caching has its limitations). However, most dynamic sites have features that use far more CPU cycles than just the front page; which is where I am guessing most sites die. Another issue is that of hosting. Many sites could stay up without any problems if they did not have CPU quotas on their (many times low-end) hosting. In order to get any server on Slashdot, you must have something worth people's time, and more so, worthy of Slashdot. Bandwidth is a large issue as well, but generally CPU time seems to be the bottleneck. However, many hosts have stingy monthly bandwidth limits that may look impressive, but total up to be a sustained speed of a fraction of a 56Kbit dialup over a months time.

I have been hacking at lfcgi and the CGI-only WebLua. My goal is to have a working Lua+FastCGI setup released as a new WebLua version. I have a few ideas for a new shared-memory-based database system, but for now will use the tabledb that I put in WebLua.

I have created a site that shows a few basic things to the users, such as their IP address and browser information, but also log hits by the referering host (however, referrer-less hits are also logged underneath a total hit count). It can act as a way to compare sites such as Digg, Slashdot, Reddit, and whatever else links to the 486. This could be a contest of sorts between news sites to see who gives the most hits. The site could also show the percentage of IPv6 hits. Also, the fact that the site would run on a 486 may generate quite a bit of interest in itself.

While the plausibility of this working seems grim, I am sure that it can be done. But regardless, it would be quite a bit of work to achieve.

Now, onto the technical side of things:

I am using a Packard Bell (NEC) 2555CD as my platform to build the server. I have always liked NEC's older equipment; most of it has a tremendous amount of innovative features and quality design. I once owned a Pentium NEC that had a built in 4 channel audio amplifier (4 channels out, stereo in); which I later turned into a guitar amp and gave to one of my friends (the amp was not the best, but that sort of innovation is hard to come by). You could even save two different profiles with equalizer settings and all, right on the unit itself. NEC screens are also usually quite crisp, but I have had little experience with their newer equipment. Hopefully they are not dissolving into cheapness as many computer hardware companies have been doing lately.

I have forgotten what the 486 came with originally, since I have swapped out the processor and ram a couple times, but I will try to keep the specifications and components as close to that era as possible. Perhaps its biggest statement of age is the double speed CD-ROM drive (double speed basically means it can read a full CD in half of the time in minutes of music it can store; so 1x is 80 minutes, 2x is 40 minutes, etc) most now-a-days are 48x or 52x (a full CD in less than 2 minutes, if that speed can be sustained). However, NEC put two PS/2 ports in this model over the massive DIN-5 (for keyboard) that even many Pentium-era systems shipped with. The old Aditi server (for eleutherNet) had one PS/2 mouse and a DIN-5 connector; it was a AMD K6-2, but I think it was upgraded from a Pentium (both fit in the same socket).

The 486 has a DX/2 overdrive specified to run at a whopping 66Mhz. Originally, I assumed that it was running at 66Mhz, but I later found out that it was jumpered to 33Mhz and that the motherboard only supports 40Mhz at the most. Keep in mind that more modern processors are much more efficient clock-for-clock; especially (in most cases) if the more modern instruction sets are used when compiling. Once I get the box going, I will benchmark it for reference. I may need more ram initially when setting up the 486, but I plan to have to it Slashdottable on either 12 or 16MB of ram. I will keep the original 428.1MB harddrive.

Now, for some pictures:













The case is rather sharp in places:


While the 486 does have a CD-ROM drive, it appeared to be dead from the few tests that I did. The CD-ROM drive also kept it from POSTing if it and harddrive were daisy-chained (there is only one IDE and one floppy connector). I also tried working on the master/slave/cable select settings, but with no avail. The BIOS did not seem capable of using any other half-modern CD drives, and I later discovered that it was not even capable of booting a 9GB HD due to the head count (according to GRUB's error message). I installed Icadyptes on to the original 428.1MB harddrive using one of my spare boxes. I stuffed all of the space I could into a single partition for / with ReiserFS (I've had a great experience with ReiserFS and have never lost data because of it). And yes, that means no swap :-); I'm not very fond of swap files for a few reasons that I won't mention here. It was a close call; the harddrive only had 8MB left, but in the event that the installer installed too much, I had even not yet implemented any package selection setup for Icadyptes' installer (though I certainly could have improvised if needed):



A few of my computers have more storage in RAM than this disk can hold:


I was greeted with an endless GRUB GRUB GRUB GRUB message after installing it to the 486's harddrive from the spare box (and booting it from the spare box). I found that this was due to the harddrive's incompatibility with the BIOS; and changing the BIOS settings for the device did not help. I successfully booted the drive on the i486, which at the time I had removed all sticks of RAM, leaving only 4MB of embedded RAM. Incredibly, it decompressed the kernel, though it seemed unable to go further with so little RAM. I stuck the harddrive back on the P4 and used the Icadyptes installer CD's GRUB in place of the incompatible GRUB setup on the harddrive's MBR. I updated, set the locale to ANSI (anything lighter would help a lot for this 486), removed base-devel (GCC, Perl, and such, saving 100MB), and installed a few extra packages.

I then journeyed through my large collection of SIMM RAM to add to the 4MB embedded in the 486's motherboard (I have 19 sticks scattered around half of my room):



I found four identical 32MB sticks; forgot that SIMMs so large were ever made. I settled on an utterly massive (physically speaking) 16MB Kingston stick, which I could downgrade from once I could reinstall the kernel package (Icadyptes uses Arch's initramfs generation system which utilizes only the modules needed in the installed system, but creates a fallback image with a full set of modules). Reinstalling the package would make booting with less RAM much easier, and should make the booting itself somewhat faster (noticeably, in the case of a 486). I tried booting from the harddrive, but it was not inserting the PATA controller driver for some reason. My original thought was that perhaps libata did not support the controller, so I tried rebuilding the kernel with the original IDE driver set. I also managed to downsize the vmlinuz from 1237KB to 1205KB at the same time :-).

The huge 16MB stick (notice the 1991 copyright date, and yes, I should have put another object next to it for a size comparison):


1MB stick of 72 pin SIMM RAM:




Long-ish story short, I went back and forth about 6 times changing defaults in the kernel package, and initramfs would not load the IDE controller module automatically. Finally, from inside the barebones klibc-based initramfs I inserted the deprecated (maybe not officially, but libata supersedes it) ide_generic module, and got lovely printk messages about HDA. I figured that libata would work, but by loading ide_generic, it would conflict with libata. I rebooted and found that pata_legacy (aptly named, isn't it?) held the keys to the 428.1MB harddrive I had been dieing to mount. A little while later after a few more problems, I booted Icadyptes on the 486 with 20MB of RAM. Reinstalling the kernel package took 47 minutes, but this was back when the processor was running at 33Mhz. I was pleased to find that there were no errors, and the system's only quirk is that the BIOS clock gets reset at each reboot (I presume that the clock battery is dead), and requires user input to continue booting.

You may have been wondering about network connectivity, on two stages. First, this box somehow needs to connect to my LAN, and somehow my home connection needs to hold it up. Well, a while back, a Zenserver user got on the Zenserver IRC channel and thanked me. Somehow we got onto the topic of 486's, and he offered to send me a 10Mbit ISA ethernet card (my 486 only has ISA slots). I happily accepted and gave him my address; though it never came. However, as with all people that have thanked me for working on Zenserver, his meant a lot as well. One of the greatest joys of Linux distribution development is seeing that someone is using something that was assembled by you when they could be using something else. More so, when they get on your IRC channel and thank you for it :-).

Months later, I still have not obtained an ISA ethernet card. So how am I supposed to get this box accessible by my LAN; let alone the whole of the internet? A great wonder with 9 pins should be able to do this without problems. Yes, I will connect it to another box (the screenless, keyboardless laptop I mentioned earlier) and bridge it to my LAN over serial. I should be able to get a whopping 115200 BAUD; though an ethernet card sounds nice when I think that 115200 BAUD will probably only give me about 9-11KB/s (and remember, its not full-duplex like ethernet usually is). I tested SLIP between two computers (the 486 was not one of them), and had about a 28-35ms latency with an average speed of 10KB/s. However, I found out that SLIP only supports IPv4, so I tried PPP since it supports IPv6 amongst its rich featureset. PPP gave me the same speed, but with only about 10ms of latency; so I was quite pleased. Note that 0.2ms is a fairly average latency for an ethernet network. This of course will be added directly to the internet latency when people connect externally; but 10ms won't affect things too much (in most cases).

After reinstalling the kernel package a second time while forcing inclusion of pata_legacy, I tried rebooting with less RAM. Unfortunately, it seemed that I needed an additional module that I had not forced inclusion of. I had to revert back to 20MB of RAM to load the fallback image and rebuild the image with the sd_mod module. After throwing it into the bunch, all was well.

I tried PPP over serial, but found that the serial port was only capable of 19200 BAUD; a sixth of what I was hoping for, and a third of the bandwidth that 56K dialup offers. This would simply not be plausible, so I looked for an ISA ethernet card. I found a great deal for 5 ISA ethernet cards on Ebay for only $12 USD with shipping. During the few days I had to wait for the ethernet cards I wrote most of the webapp that the 486 would run.

The ISA ethernet cards:



An Intel Pro, two Intel 8/16's, an Intel 8/16 with BNC connector, and a no-name brand with a BNC connector.


The Intel Pro had a copyright date of 1994 on it, so I went with an older 8/16 to start with.


I booted it up and did not automatically have the module loaded for the ethernet. I figured that it was due to Icadyptes' kernel missing some ISA support, so I rebuilt the kernel with PNPBIOS support, but despite my original guess, it already had ISAPNP support aswell. Normally with Icadypte's/Arch's/any modern Linux distribution's setup has no problem loading modules for almost any hardware setup automatically, so I am guessing that it is either a udev bug or a hardware inability to be probed in the same manner. I put the harddrive back to my spare P4 box, used the Icadyptes installer CD to boot, and began upgrading the kernel. Part way in to the updating I noticed that it had stopped. I let it sit for a little while longer then received ReiserFS journal write error messages. I rebooted but it took ages to start from the harddrive, so I tried it on the 486, hit it a little, but ultimately realized that its time had come. Luckily I had a spare 631MB harddrive sitting around that *should* possibly boot on the 486:



I installed Icadyptes via the P4 onto the new harddrive, and fsck'ed the other harddrive. It gave all sorts of errors with the blocks being out of order (I forget what it said exactly), but I was able to mount it and copy over the old /etc for the old config files. I updated, installed extra packages, and then tried booting on the 486. GRUB gave me an "Error 16", which seemed to indicate that the partition had been unmounted uncleanly and was giving problems. I tried mounting and umounting the harddrive multiple times from the spare box, and changing BIOS settings. The BIOS showed all of the sector/head/cylinder amounts properly, but the total size of the drive was displayed as 601MB as opposed to 631MB. This was strange because back when I tried a 9GB drive in the 486, I was given "Error 18", which is best described as "Selected cylinder exceeds max supported by BIOS". So it seemed like it was incapable of accessing the whole harddrive, but for some reason GRUB was giving a different message. I read somewhere (I think the Linux Questions Wiki) that this can be bypassed by creating a smaller boot partition within the size limitations of the BIOS. So, I reinstalled Icadyptes with a 64MB /boot partition, mounted the dieing 428MB harddrive and copied over /etc, updated, and stuck it back in the 486. I was presented with the lovely GRUB menu, and continued with my network card adventures.

Before delving back into the ethernet ordeal, I found that I could disable the 4MB of onboard RAM, so I did so hoping that perhaps it would let me run the RAM at 60ns instead of 70ns, and to lower the total amount of RAM. I settled on a 60ns stick of 16MB RAM to use. I also tried booting with 8MB of RAM, but it hung at udev in init, so it almost made it :-). The ethernet card was not automatically detected again, and I gave a few attempts at locating the module needed. I read that the ethernet card I had used did not support ISAPNP, so it looked like I would have to manually set the IRQ and such. /proc/interupts showed noting seemingly relevant, and I have hardly used ISA in the past, so I decided to just try the Intel Pro (which supports ISAPNP). The Intel Pro did not come up automatically, but I found the module it needed (eepro). However, it said that no such device was present, and the module insertion failed. I tried aliasing it with eth0 and enabling the autodetect option in modprobe.conf, and lo and behold, it came up :-). A few seconds later it obtained a stateless IPv6 address, and I ran rdnssd from the ndisc6 package to setup the DNS server broadcasted by radvd (I wrote a Lua script to replace the Perl script used in the original package for actually rearranging the existing entries in resolv.conf). So, at that point the 486 was connected to my LAN at 10Mbits, and the IPv6 internet. I was fairly impressed that it could download at 350KB/s from my Icadyptes repository (which is in my LAN). Now, for the software setup.

I also released a new WebLua version that runs on FCGI while I was waiting for the ethernet cards to arrive. With WebLua, Lighttpd, and OpenSSH's SSHD running, and a Bash session, the 486 used less than 7.3MB of RAM, but some may be used and not accounted for. Innorder to finally reinstall the kernel package (this harddrive's install had not yet had the kernel reinstalled) I needed 20MB of RAM (process would run out of memory about 20 minutes in with 16MB), but I think that it may be due to a memory leak in Pacman (the package manager). The webapp that I wrote adds each hit by referer and shows the top 20 referers. It also counts the total hits (with a referer and without), displays the percentage of total hits that each referer has, and the percentage of hits from IPv6. Referers are simply an HTTP header, basically a typical GET request looks like this:

GET /file HTTP/1.1
host: www.domain.tld
(line feed)

Under normal circumstances, if you are linked to another site your browser will add another header:
referer: http://thissite.tld/that/referered/me.html

I first noticed a potential vulnerability with cross site scripting due to the fact that you can set any referer you please, so I added a filter for characters needed for HTML and such. I'm not 100% sure if it is completely secure, but it was certainly more secure than what I started with. I also realized that each unique referer used more RAM and would slow things down. The current setup at the time wrote the "database" to disk and loaded it for each request.

At first I rewrote it to only allow a maximum of 50 referers, but realized that it could become problematic. Only allowing the top 50 would "lock out" any other referers from entering the "queue". I then devised a plan to have a top 20, and a FIFO that would allow for 30 unique referers. Once the top 20 is filled a new unique host enters the FIFO. Each time a user hits the site with a referer in the bottom 30 FIFO, it is incremented just as if it would be if the referer was in the top 20. Each unique host to enter the FIFO would push each one along the chain. so fifo[1] would become fifo[2], and so on, up to 30 where it stops (30 is the last one, and overwritten). If a referer in FIFO becomes greater than the #20 referer, they are "swapped" (quite literally). Once if a referer in the FIFO is pushed off of the stack they no longer use the 486's precious resources, and have to start again. I also have the refering hosts shortened to 32 characters to save resources against such potential attacks, and keep the page proportions in line if such a referer were to enter the top 20.

I then went on to do some benchmarking on the 486. I wrote the webapp on the silentgnu, and used a single process to prevent race conditions to the database files (which also means it will generally only use one core instead of the two available), it would get about 1200 requests per second on a "clean" database, and around 550 on a "full" database. That is also not when overclocked; the silentgnu kept crashing when building the kernel package, so I down clocked it to stock speeds (it was almost at a 50% overclock, and had ran 100% stable before then). Perhaps it was the summer weather making my room warmer? While writing the webapp I compared the speeds mathematically, and considered the 486 to be about 150x slower than a single processor of the silentgnu.

[root@icadyptes nbench-byte-2.2.3]# nice -n -19 ./nbench
 
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
 
TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          10.123  :       0.26  :       0.09
STRING SORT         :         0.74795  :       0.33  :       0.05
BITFIELD            :      2.2329e+06  :       0.38  :       0.08
FP EMULATION        :          2.3121  :       1.11  :       0.26
FOURIER             :          230.15  :       0.26  :       0.15
ASSIGNMENT          :         0.23452  :       0.89  :       0.23
IDEA                :          28.539  :       0.44  :       0.13
HUFFMAN             :          24.832  :       0.69  :       0.22
NEURAL NET          :         0.09996  :       0.16  :       0.07
LU DECOMPOSITION    :           4.812  :       0.25  :       0.18
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 0.517
FLOATING-POINT INDEX: 0.219
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : GenuineIntel 486 DX/2
L2 Cache            : 0 KB
OS                  : Linux 2.6.26-TUX
C compiler          : gcc version 4.3.1 (GCC)
libc                : libc-2.8.so
MEMORY INDEX        : 0.099
INTEGER INDEX       : 0.158
FLOATING-POINT INDEX: 0.121
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38#
* Trademarks are property of their respective holder.#
[root@icadyptes nbench-byte-2.2.3]# exit#
 
Script done on Fri Jan  1 03:10:27 1993

Notice the script end date. January 1st 1993 is what the BIOS resets the clock to :-). The Pentium and AMD K6-2 indexes are how many times faster the box you are comparing is to those processors (for the most part). So the 486 at 40Mhz is about 35% of a Pentium 90; I think that the extra floating point speed is a software difference, and not accurate. You can see the benchmark for the silentgnu two posts back.

I was originally hoping for 10 requests per second, but mathematically it looked like it would get between 8 and less than 4 under a full database. The real world benchmarks said otherwise. The 486 pushed 5.5 requests per second under a light database, and less than two under a "full" database.

Under a Slashdotting, the referer database would easily get flooded. and two requests per second is far too slow for even a sustained average speed; let alone a peak second. This would just not work, so I originally thought of storing the FIFO in the WebLua FastCGI daemon's RAM, but ended up moving it all to RAM and writing to disk every 250 hits (loading from disk if it did not exist from WebLua already). At first I thought that I would have to write my own input/output mechanism for the "virtual machine"-like setup to communicate back to the daemon. The Lua IRC channel on Freenode was a huge help in pointing out how I could access the state after it ran. At first I wrote a module, but realized the methodology was completely wrong and would not work. I modified WebLua directly to store a certain table if the config file had the persistant variable set, and give it back to the next request. Initially it was not working, but I accidentally tried it with the persistant variable disabled, and it worked! I was puzzled for a while, but realized I had an unintended feature of the whole wl table being persistant. While this should be changed somewhat, I decided to exploit the simplicity. After coding this all in, the silentgnu server gives a respectable 1344 requests per second under full database (this figure is slightly higher under a light database) with a referer set (for the benchmark), and about 90 more requests per second with no referer set. I encoded the webapp into Lua bytecode (this could be doable WebLua-side with a caching mechanism in the future) for about a 30% performance gain on the 486 (this percentage was much less on the silentgnu; to do this simply run luac on a Lua script). I was pleasantly suprised to see that the 486 can take about 7 requests per second under a full database, and 10.5 under a clean database. Seven requests per second totals out to be a total of 302400 requests in 12 hours, so 3x the number of requests that the site I mentioned earlier received. In size terms, 300K requests should be only about 138MB (for a full database); but if the 486 gets that many hits, my other sites would certainly be hit quite a bit. The page produced by the script checks out as valid XHTML 1.1, and has valid CSS 2.1 embedded. #css of the Freenode IRC network helped lighten the CSS a bit, but under a full database the 7 requests per second only totals about 23KB per second (my upload bandwidth can easily do twice that speed), so I have no worries about my internet connection being the bottleneck.

The 486 is actually only connected to IPv6, and I have explicitly disabled IPv4 as much as I know how to. I edited OpenSSH's config file to only open on a IPv6 socket, set net.ipv6.bindv6only to 1 to prevent Lighttpd (the HTTP daemon) from listening on an IPv4 socket (server.use-ipv6="enable" must also be added to the Lighttpd config file), and even remove 127.0.0.1 from lo after it is brought up. So how is it reachable over IPv4? I have my go-beyond.org server proxying requests sent over IPv4 to it with the foureightysix.go-beyond.org hostname to the 486's IPv6 address. The webapp on the 486 determines if it is being hit from IPv6 if the hit is not from my go-beyond.org server's address (since proxied requests will have the address used by the proxy server). To do this I had to patch Lighttpd's mod_proxy with this patch from Gentoo; mod_proxy in Lighttpd 1.4.x does not normally support IPv6. I had no worries about the go-beyond.org server, since mod_proxy is designed for load balancing in the first place, and its hardware is surely capable enough to withstand 10 requests per second at the most, since the 486 is the bottle neck (though if the go-beyond.org server were overloaded, it would be a very sad story for the 486). I am connected to IPv6 via Hurricane Electric's excellent Tunnel Broker service (currently the Ashburn, VA PoP), but link IPv4 hits to sixxs.net due to its mass of information useful to someone considering connecting to IPv6 (I have heard good things about their tunnel service too).

I realize that this is a riddiculously long post, so thank you so much for reading it :-). This whole adventure has been incredible, and I truly think that the 486 will get on Slashdot, Digg, and other sites, and live to tell the tale :-). At this point, I ask to everyone who reads this to link to foureightysix.go-beyond.org and this blog post, from their favorite news site. However, please don't DOS it beyond what you would do normally (but don't be too gentle either :-) ).

foureightysix in its potentially Slashdot, Digg, Reddit, etc. ready state:



Many thanks and kudos to: Madhat for doing the manual labor (I guess it could have been scripted) of replacing sysvbanner's "486" output with a "special" number sequence. To Freenode's #html, #css, #lua, #ipv6, ToxicFrog, lanthas, Google, Hurricane Electric, Arch Linux, to Borromini, Larhzu, aliverius, and Zeqadious for all of the encouragement, to my neighbor in Holy Springs who gave me the 486, to Google Blogger for hosting this horribly long post (though eventually I will probably move to my own hosting), to my awesome parents for believing in me, encouraging me, and paying for Mediacom to give us a 8Mbit/512Kbit line over cable, to whoever wrote the CGI script used in WebLua 0.2, to
garyng2000 for his work on lfcgi, to TorrentFreak for all of the excellent informative blog posts, and to the countless other who have made this possible with encouragement, support, ideas, criticism, and just general chat :-).

And many thanks to you, as a reader of this text, you have helped make one of my dreams possible.

Thank you all so much,
Teran McKinney (sega01)

PS: If you would like to help keep my work on open source possible, a donation of hardware, mirroring, development help, or money, would be a tremendous help. Also, I may be available for hire as a consultant, for web development (I would use Drupal for most sites, but want to continue to work on WebLua too), for IPv6 migration/integration, networking, or almost anything open source related.

I would love to publish (under the GPLv3) the source code for the script that the 486 is using, but do not want someone to try undermining all of the time and effort I have put into this by putting it on one of their own boxes. Once the 486 receives 250,000 hits or I receive $1,000 USD in donations I will release the source.