A Love Letter to the Super Dimension Fortress

The more I learn about the web, the more appreciative I become of what came before. We truly are standing on the shoulders of giants. In the past week, I've had the pleasure of (finally) becoming an ARPA member on SDF, a non-profit public-access UNIX system and online community that has been in continuous operation since 1987.

But what is SDF? Well, to answer that, we need to go back four decades and talk about the BBS era.

Bulletin Board Systems

It's June 16, 1987. Ted Uhlemann ("iczer") plugs an Apple IIe's 300-baud^[1] modem into a phone line his mother had just given him for his birthday, running Magic City Micro-BBS (written in Applesoft BASIC). He names it SDF-1 after his favorite anime, hoping to attract fans of "anime, industrial music and the Church of the SubGenius," per a 30th-anniversary retrospective by Stephen Jones. The original hardware is one 1200bps modem and two floppy drives holding 280 kilobytes each.

This was the very beginning of SDF.

SDF is self-described as "a community platform for inspiring, facilitating and implementing new ideas". It's a multi-user NetBSD machine, funded solely by its members as a 501(c)(7) nonprofit, where tens of thousands of people hold accounts. The name comes from the anime Super Dimension Fortress Macross (known in the West as part of Robotech), and the system began as a BBS for Japanese anime fans. The BBS-era of SDF was can be witnessed in the eight-part 2004 documentary on YouTube titled BBS: The Documentary, which includes a recorded interview with Stephen Jones, SDF's longtime sysadmin.

Bulletin board systems predate the modern Internet, and arguably turned personal computers from expensive novelty kits into far more popular machines. BBSes were what changed PCs into essential gateways for global and local communication during the 1980s and early 1990s. They were proof the computer was for connecting with other people.

There were no search engines at the time, so you had to look through computer magazines or text files from other boards to find a BBS. A "website address" was a local 7-digit phone number. You opened a terminal program on your computer and typed a command to make your modem dial the BBS phone number. Because it used your home phone line, nobody in your house could use the phone while you were online. You would listen to the computer physically dial the number, followed by the iconic, harsh screeching and static hiss of two modems talking to each other.

At its peak of popularity, there were over 150,000 BBSes operating in North America. By 2005, there were only a few hundred.

In a 2006 bsdtalk interview, one longtime member summed up what makes the place stick around:

"SDF is more than a shell account, it's a community of people who communicate with one another via the various methods that SDF provides... What makes SDF special is that it is run like a computing environment in the early days of the Internet. It's not corporate at all."

A university researcher's 2019 survey of public-access UNIX systems, History, Evolution and Future of Public Access UNIX, hosted on SDF itself, describes the modern system as "a fully articulated social community," and adds that SDF supports special interest groups for ham radio (SDFARC), Python, Gopher enthusiasts, and Minecraft players alongside "digital artists, computer historians, web developers, gamers, and of course many, many programmers." SDF's own pictorial tour documents the hardware year by year back to 1985, including a stint at a telephone museum and the machines running today.

Today the network includes NetBSD servers on DEC Alpha and AMD Opteron hardware, plus live retrocomputing environments: a TOPS-20 system (twenex.org, running Panda Distribution TOPS-20 on two XKL TOAD-2s), a Symbolics Genera machine, and an ITS system. Free accounts are available on all of them.

In the past four decades, SDF has survived hardware failures, countless DDoSes, a termination by its own ISP, and multiple relocations across the United States. It has never gone commerical, nor lost its userbase in that time. Jones, still running SDF decades in, wrote in his 30th-anniversary letter:

"Some people today may come here and see us as outdated and 'retro.' But if you get involved, you'll see it is quite alive with new ideas."

Services Offered by SDF

SDF has come a long way since its BBS days, though it's still one of the last places offering free dial-up access. When you become a member on SDF, you get a lot of services—rather similar to getting a Tildeverse or omg.lol account, and predating both.

You begin in the shell. Running the command ssh you@tty.sdf.org puts you in NetBSD with typical stuff like bash, ksh, tcsh, rc, and zsh; editors from ed to emacs. And ping, traceroute, dig, whois, and finger, etc.

You get your own web page, running mkhomepg on the shell will create a ~/html folder, and asks which URL you want. You add your files in ~/html and the site is live immediately at you.sdf.org. ARPA members can pick a vanity domain from ~60 choices (pdp10.org, twenex.org, chaosnet.org, freak.net, multics.org...). See wiki.sdf.org for the list. CGI works out of the box. Shell/awk/sed for everyone, and full php/perl/python/ruby for ARPA members.

The Gopher and Gemini protocols are typically more used by SDF users. Run mkgopher in the shell and choose setup. It'll create ~/gopher (a symlink into /ftp/pub/users/you) served as both gopher://sdf.org/1/users/you and gemini://sdf.org/users/you. One directory, two protocols! Write a gophermap or add .gmi files. See gopher setup and gemini setup.

And that's just the tip of the iceberg:

How to Join

Originally, the only way to join SDF and get verified was to physically mail one dollar to their PO box in Seattle with your username. This was a clever way of preventing spam and abuse.

Nowadays, thankfully, you can just donate via Paypal, making the entire process a lot easier.

I think one of the coolest things about SDF is the lifetime ARPA membership. For a one-time fee of $36USD, you get:

• Outbound tools: telnet, ssh, sftp, ftp, snarf, wget, ytalk, external IRC. Free accounts are inbound-only; ARPA opens the network both ways
• File transfer: scp/sftp and non-interactive SSH: ssh-copy-id is enabled
• Development: gcc, perl, php, python, ruby, elisp on the box
• Full CGI: php/perl/python/ruby on your site
• VoIP: internet calling, voicemail, conferencing (PSTN calling is a $15/quarter add-on with a real DID option)
• UUCP + ClariNET: mail and newsfeeds via TCP or dialup
• Voting rights: on system features and policy
• Quotas: ~150 MB / 5000 files each for home, mail, webspace, gopherspace

Not only do you get all of the above for life, but you're supporting a networked community that's been around longer than I've been alive!

Bonus: Making a Perl CGI Guestbook on SDF

Back in the day, to add functionality to your website, you wrote scripts that interacted with a web server via the Common Gateway Interface (CGI) protocol. In the late 1990s and early 2000s, it was the primary technology used to transition the World Wide Web from static HTML pages to dynamic, interactive websites.

Sadly, they're not used much in modern-day web development, and are considered obsolete and discouraged. You see, traditional CGI spawns a brand new operating system process for every single visitor click. So on busy websites, they consumed massive amounts of server memory, and slowed performance down to a crawl.

But when you're making a little personal website, things like "scaling" and "efficient resource usage" can be thrown out the window! Who cares? Since I have access to Perl CGI as an ARPA member, I decided to make a simple guestbook on my little SDF webpage. Here's how I put it together.

1. Understanding SDF directories

In SDF, the root of your webpage is the ~/html directory, but that isn't your home directory. Rather, its a symlink into /www/<a>/<b>/<username> (the parent directories come from your username, so mine is /www/af/b/bren). Your real home directory is somewhere like /sdf/arpa/af/b/bren. Now, you don't want your data file living inside the publicly-served ~/html folder, where a visitor could request it directly. Instead, keep it one level up, outside the web root:

/sdf/arpa/af/b/bren/guestbook.dat   <- data file, NOT web-accessible
/www/af/b/bren/guestbook.cgi        <- the script itself, lives in ~/html

Also, $ENV{HOME} isn't set when your CGI script runs under suexec, so you can't rely on relative paths like ~ inside the script. I just hardcoded the absolute path to the data file.

2. Writing the script

For this, I use core Perl and Fcntl for file locking (if two visitors ever signed at the same time), but that's pretty much it. The script reads $ENV{REQUEST_METHOD}, parses the POSTed form body by hand (no CGI.pm, it's deprecated), validates the name/message length, and appends a line to the file:

#!/usr/pkg/bin/perl
use strict;
use warnings;
use Fcntl qw(:flock);

my $DATA_FILE = "/sdf/arpa/af/b/bren/guestbook.dat";

sub add_entry {
    my ($name, $message, $url) = @_;
    my $ts = scalar localtime;
    my $enc_message = $message;
    $enc_message =~ s/\\/\\\\/g;
    $enc_message =~ s/\n/\\n/g;

    open(my $fh, '>>', $DATA_FILE) or return;
    flock($fh, LOCK_EX);
    print $fh join("\x01", $ts, $name, $enc_message, $url) . "\n";
    flock($fh, LOCK_UN);
    close($fh);
}

Every entry is a single line, timestamp \x01 name \x01 message \x01 url, using the otherwise-unused \x01 control character as a field separator, as this ensures names or messages containing regular punctuation don't break parsing. Newlines inside a message escape with a literal \n on write and unescaped again on read, turning multi-line messages into single lines as well.

There's also a honeypot field, website, that's hidden from visitors with CSS. If it's filled in, the submission is ignored, but the robot will still see a "Thanks for signing!"

3. Locking down the data file

Since the data file has to live somewhere Apache can access (in my case, I didn't want to think too hard about symlinks), add a .htaccess in ~/html:

<Files "guestbook.dat">
    Order allow,deny
    Deny from all
</Files>

4. Uploading and make it executable

SDF requires CGI scripts to (1) end in .cgi and (2) be executable. There's no cgi-bin directory requirement, so it can be put anywhere in ~/html:

scp guestbook.cgi bren.sdf.org:html/
ssh bren.sdf.org
chmod 755 html/guestbook.cgi
mkhomepg -p

mkhomepg -p will correctly reset your homepage permissions to SDF's expected secure defaults.

5. Visit it

That's it! guestbook.cgi renders the same page for both GET (showing the form and the last 50 entries) and POST (validating and saving a new one). There's no database, framework, or build. It's a little janky by 2026 standards, and I love it. Sign it if you want: bren.sdf.org/guestbook.cgi (note the http, not https).

Bonus: Making a Dillo-compatible Website

Finally, I was rather inspired by Sunny's blog post on positive, human-made software, which listed the Internet browser Dillo.

Way back in the day, when my only computer was a painfully slow Intel Core 2 Duo, I remember trying to find lightweight browsers that would make websurfing a less painful experience. Dillo is certainly one of them! The "code base is currently 0.2% the size of Chromium's" and has ridiculously low memory usage.

Unsurprisingly, that comes with a price. There's a lot of the web that doesn't render or function properly with Dillo because of its limitations. But to me, that's a feature. One of the best ways we can ensure our web pages honour smol web principles while also having source code that's easy for beginners to read is by making our sites Dillo-compatible.

What does this actually mean, though?

Well, Dillo supports a subset of HTML 4.01 with some HTML5 elements layered in, and a subset of CSS 2.1 with some CSS3 layered in. No JavaScript, at all.

<script> and all inline event handlers (onclick, etc.) are discarded. frameset/frame/iframe have no rendering support. No <canvas> or video, audio, source, embed, object playback support, either.

Regarding CSS and styles, there's no support for CSS variables (var()). There's also no flexbox and no CSS grid. Grid rules are just ignored. You'll have to do your layouts with (gulp) table and float, instead.

There's also no custom webfonts with @font-face, as fonts resolve to the five CSS generic families: serif, sans-serif, monospace, cursive, and fantasy, all of which are set in the user's dillorc config (font_serif, font_sans, etc.). Dillo doesn't have the ability to load specific webfont files.

Take this with a grain of salt, as I couldn't actually find a canonical compatibility table. The Dillo devs communicate through the manual, changelog, and bug tracker.

Conclusion

It's funny, the more I learn about web development, the more simple and back-in-time I go. I think this makes sense—good code is unbloated code. The closer you can get to no interface, the better the interface. It's a wonderfully paradoxical aspect of programming and working with computers. These are always going to be machines with finite limits—no different than us—and we need to not only be mindful of that, but lean into it.