NOTE:The Rainbow is currently down for a bit, so this blog is now being served by a VAX 4000/200 minicomputer running NetBSD 8.0. More on that later...
This blog is served up via a winding chain of machines from a Rainbow 100 model A personal computer. Here's a bit more:
The Rainbow 100 serving this page is powered by an Intel 8088 and a Zilog Z80, both running at 4.77Mhz. The Rainbow is a dual CPU machine, and, when running MS-DOS (see below), the Z80 acts as an input/output controller for the floppy drives. This particular computer features 320KB RAM, a single RX50 floppy unit providing 800KB of storage (two 400KB SSQD drives), and a Suitable Solutions IDrive featuring a 360KB DSDD IBM-compatible floppy drive. This unit, since it is acting as a web server, does not feature a hard disk controller or graphics option.
The Rainbow is connected via a null modem cable to a Raspberry Pi model 3, which is using a USB-to-Serial adapter to provide a serial connection. The serial connection is running at 19200 bits per second, the fastest the Rainbow can handle without additional hardware. The Raspberry Pi is connected to a LAN over WiFi.
The Rainbow 100 is booting into Microsoft MS-DOS 3.10b, modified by Digital Equipment Corporation and Suitable Solutions to run on the Rainbow, which isn't even remotely IBM-compatible. Upon booting, the Rainbow starts the DECCOMM FOSSIL (Fido-Opus-Seadog Standard Interface Layer) driver and, subsequently, the uIP/FOSSIL web server. The web server attempts to connect to the Raspberry Pi over SLIP, the Serial Line Interface Protocol.
The Raspberry Pi, which serves strictly as a proxy, is running Raspbian with nginx to reverse-proxy web requests back to the Rainbow's web server.
Every web request requires the Rainbow to perform a floppy disk read and push the file back over the serial port. The performance is miserable since, as a best case estimate, the Rainbow can only serve 2.4KB of data per second. With IP overhead, that max value will drop considerably. With multiple simultaneous requests, which are entirely possible, the performance will be terrible.
Why is this server setup being used? The whole configuration is just plain inefficient and interesting. If the concept of a blog is to actually write posts, the whole procedure should be simple yet intriguing to the author. Generating a blog using GW-BASIC and then serving it with an equally outdated technology that is entirely secure (unlike Wordpress) makes life a bit more amusing.