Now that it has been possible for some time to run an Internet-only BBS (accessible through SSH instead of analog modem), I've thought that there is a great opportunity for me to create my own old-school BBS community as an alternative to the overly commercialized world of Twitter and Facebook. This post is the story of the path that I took to create a BBS of my own design, one that I hope will be enjoyed by many people in the years to come.
Let's start with the basic definition of a BBS, courtesy of Wikipedia:
A Bulletin Board System, or BBS, is a computer system running software that allows users to connect and log in to the system using a terminal program. Once logged in, a user can perform functions such as uploading and downloading software and data, reading news and bulletins, and exchanging messages with other users, either through electronic mail or in public message boards. Many BBSes also offer on-line games, in which users can compete with each other, and BBSes with multiple phone lines often provide chat rooms, allowing users to interact with each other.
So those are the basic services that I want to provide, but I have taken a somewhat unusual path to get there, at least by 2009 standards. There are many off-the-shelf BBS packages for a wide variety of OS's, but I decided to start with an OS that provides a foundation for security and reliability that is unmatched by anything outside of the IBM mainframe world, and IBM mainframes and their menagerie of OS's are so expensive and weird that they go on my short list of technologies that are too weird and broken for me to even consider using for any purpose (along with Windows CE, MUMPS, and programming the x86 in 16-bit mode).
This OS has been in production since 1977, has influenced countless other OS's in large and small ways, and is currently used in so many different truly mission critical applications that it's unfortunate that it is not more widely known and doesn't get the respect that it deserves. That OS is VMS, aka OpenVMS. A weird OS, but one that is in my opinion, neither "too weird" nor "too broken" to use, and in fact is close to ideal for the purpose of running a BBS with support for hundreds of simultaneous users and 24/7 uptime, if you're willing to take the time to acquire the necessary hardware from eBay and elsewhere, and to learn how to properly sysadmin it, both of which I've done.
My first exposure to VMS was in college. At Cal Poly Pomona, all students were issued accounts on the Academic VAX Cluster, or ACVAX for short, a cluster of two refrigerator-sized VAXen (the plural of VAX) and associated peripherals, tucked away in a server room that none of us were privileged to visit (I heard from a professor that the machines were extremely loud). There were several large labs filled with VT220 terminals for students to log in to the ACVAX, or you could dial in with a modem and later connect over Telnet. As a Computer Science student, I also had access to a cluster of 8 or so VAX workstations in the main CS computer lab, the CSVAX cluster.
The VAX was an extremely popular minicomputer manufactured by DEC (Digital Equipment Corporation), a company that was acquired by Compaq in 1998, which in turn merged with HP in 2002. VMS is the OS that DEC designed to run on the VAX, although many institutions purchasing VAXen in the 1980's did so to run UNIX on them instead of VMS.
When DEC introduced the Alpha CPU in 1992, an extremely powerful 64-bit RISC CPU to replace the 32-bit CISC design of the VAX, they also ported VMS over to it, renaming it OpenVMS to emphasize that it was no longer constrained to the VAX architecture, but primarily for marketing reasons (to emphasize its compatibility with the emerging "open systems" world of TCP/IP, POSIX, and other networking and programming standards not tied to a particular vendor). In the case of VMS, that was stretching the definition of "open systems" quite a bit since it normally referred to a UNIX or UNIX-like system, and while VMS's UNIX compatibility has improved over the years, it is still quite a different beast. At any rate, I'm glad for the name change to OpenVMS if only because it makes Google searches for technical info on VMS a lot easier, as there is no ambiguity or confusion with discussions of "VMs" (virtual machines) and other completely unrelated topics also using the acronym "VMS".
As a student, I found VMS a bit quirky and strange, but it impressed me that two VAX CPU's, extremely pokey by today's standards, could serve several hundred simultaneous users with relative ease and only a little lag. It also impressed me that the sysadmin for the CSVAX cluster was always cool and collected, in control of everything, and seemed to have a very stress-free existence in comparison to the stress, chaos, and confusion of the typical UNIX sysadmin, which included myself at the time, since I was managing a small network of Sun workstations as a part-time employee at JPL, and got to experience the mess that was the SunOS -> Solaris transition firsthand.
It's hard to believe now, but Solaris was Sun's "Windows Vista" and the transition from the previous SunOS 4.x series was handled about as poorly as Microsoft's transition from Windows XP to Vista. In both cases, the corporate message was, "this is the new OS, we've stopped working on the old one so you don't have a choice, get on board the Solaris/Vista train or get left behind." Unfortunately for both Sun and Microsoft, users and sysadmins didn't particularly want to deal with the performance hit, the numerous source and binary compatibility problems with software written for the previous OS, and the completely rearranged UI.
In the case of Solaris, this included gratuitous renaming of config files and changing of their formats, completely different command-line options for common commands like "ps", and other commands renamed or missing altogether. There was also NIS+, a naming service (a way to enable a network of machines to share the same account information so that a user could use a single password to log in to any of them) that was intended to replace Sun's previous NIS naming service, but which was so unusable that I was forced to revert back to the original NIS configuration after only a day or two of trying to make NIS+ work for our small network of a handful of users and workstations. Other Solaris subsystems such as printing were similarly broken and slow back in those days.
For a funny and irreverent critique of the Wild West days of commercial UNIX during the days of the UNIX wars, I recommend The UNIX-HATERS Handbook, which I owned in print form and is now available as a free PDF download. If you haven't read it in a while, it's worth rereading to see how much better things have gotten in certain aspects, and yet how little has changed in others.
I certainly don't hate UNIX. In fact, I strongly prefer it to Microsoft Windows for most applications, and am very grateful that Apple has included such strong UNIX compatibility in Mac OS X. It's interesting that the Mac and Linux running on PC's have now taken the place of much more expensive UNIX workstations from Sun, SGI, IBM, and others, and even Microsoft Windows is much better today than it was back then, and therefore also an acceptable choice for many high-end applications.
So, why VMS? Well, the first reason is that it's so good at time-sharing, or multitasking that provides acceptable performance to many simultaneous users, which is not a requirement for a single-user BBS, but since I have ambitions to scale up to hundreds of simultaneous users, I want people to have a great experience, and I know that VMS, with proper tuning, can provide this on the Alpha hardware I've purchased for the project, even under conditions of extreme load.
VMS is also an extremely secure system, with many layers of security not present on any other OS. It's essentially "unhackable" for all practical purposes (Kevin Mitnick was only able to hack into VMS systems by stealing usernames and passwords through social engineering), and I plan to offer a significant monetary reward or other prize to anyone who manages to hack the test user account that I will set up for the purposes of the contest, and read the contents of a file that I will place in the test user home directory. I'm willing to bet at least $2000 that no-one will succeed, but cash is a boring prize, so if anyone can think of a more appropriate prize in terms of geek bragging rights, please let me know so that I can offer something cool in addition to the $2000. As I said, I don't expect anyone to win the prize because I have so much confidence in the robust security of a properly configured VMS system, so I don't expect to ever have to pay out!
The most important thing, though, at least from a CS perspective, is that VMS is pretty unique and so it is quite educational to compare it with the better-known OS's of today in order to understand more deeply the design decisions that we take for granted as the only way to do something. Just because Windows and UNIX do things a certain way doesn't mean that's the only way to do it, or even the best way. Learning more than one OS is like learning more than one language: if you only speak English (or your native language), you won't understand its strengths and weaknesses as a language as well as someone who learns a second or third language.
On the other hand, there are certain areas where VMS is clearly inferior and the other OS's are clearly superior. For example, on UNIX, Mac OS X, and Windows, if you run multiple copies of a program, the OS will automatically share a single copy of the read-only program code among all the copies, mapping the same physical memory pages into the virtual address spaces of each process. The same thing applies to shared libraries (DLL's). On VMS, however, only the executables and shared libraries which the sysadmin has "installed" into shared memory will be shared among multiple users, which puts the burden on the sysadmin to decide which programs and libraries are likely to be used by more than one user at a time, or are small enough to be worth permanently locking that code into RAM.
In general, VMS is a difficult OS to learn how to sysadmin, with many settings to tweak and tune, and yet it's extremely easy to admin once everything has been set up properly. That's why it took me 10 years to get to the point where I finally feel confident enough, and have collected all of the necessary hardware, software, and skills to set up my own highly reliable server configuration for running this BBS, which I've named (and registered) as Alpha1BBS.org.
Fortunately, while VMS is normally a fairly expensive OS to license, DEC/HP has been running a hobbyist program since 1998 so I can legally run the latest version of the OS and all of the layered products (compilers and other useful add-on features) for free, for noncommercial purposes. The only catch is that I have to renew the license keys every year, but it's a simple automated web form and DEC/HP has been running the hobbyist program for so long now that it's almost inconceivable that they would decide to shut down the program and lose all of the goodwill that they have gained over the years from the VMS hobbyist hacker community. Of course if they did, I could always roll back the system clock, or otherwise try to hack the license manager, but I don't think it will come to that.
In addition to being a BBS, I also want to encourage people to use the system to hack on VMS stuff, should anyone be so inclined, so I have installed all of the DEC layered programming languages: Ada, BASIC, BLISS, C, C++, COBOL, FORTRAN, MACRO, MACRO64, PASCAL, as well as the DECset tools (the LSE text editor and other stuff), both Vim and Emacs 21.2 editors (I was quite fortunate to find a VMS port of a recent vintage Emacs that is reliable and appears to support all of the functionality that hard-core Emacs users have come to expect, including the ability to open a DCL command-line as a subprocess for shell-mode, TCP/IP support, and other stuff that is hard to port over from UNIX to VMS), and other tools including the GNV environment of ported GNU/UNIX software that includes the bash shell, GNU make, etc.
So not only does this do all the regular BBS stuff (more on the menu system and other features I'm adding to turn it into a proper BBS in a future post), but it's also a way for interested folks to log in and play around with an influential high-end server OS that is a slice of living history that also happens to be quite difficult to configure properly and also doesn't run on PC hardware. For those of you who missed out on the VMS experience, you might find it as interesting as I did when I first used it at Cal Poly for my Ada programming assignments, email, etc. And for those of you who saved the source code from your student projects, or anyone who has any old VAX or VMS code lying around that you think would be fun to resurrect, now you'll be able to do just that.
All of the VMS documentation that used to take up an entire bookshelf in printed form is now available for free in HTML and PDF formats on the HP OpenVMS web site. In addition, the online help is very good, and I am working on a quick getting started guide to bring interested users quickly up to speed on the quirks and differences as well as the similarities between VMS and other OS's with which users are likely to be familiar.
I have a lot more to say about the project, starting with a description of the high-end Alpha hardware that I have painstakingly accumulated over the years to provide the ultimate in performance and reliability for this task, as well as details about the games, chat, forums, and other features that I will be offering on the system, but I'll write about it tomorrow since this post is long enough already.
In the meantime, if you are interested in getting one of the first accounts and helping me to beta-test the BBS stuff, just email me (firstname.lastname@gmail.com) with the username you would like (up to 12 characters, all uppercase) and the contact email address you'd like me to use in case you ever need to have your password reset or something like that.
BTW, I won't be forcing users to change their password every 90 days, which is the default configuration for VMS. IMHO, forcing users to change their passwords regularly doesn't add anything to security, and it just makes it that much more likely that you'll forget the new password you chose when you were forced to change it. After all, this is a hobbyist project, and I won't be offended if you log in a few times and then don't come back for a year or longer. I want everyone's account to be there and for the BBS to be in operation for at least the next 10 years with no loss of any user data, and I have planned accordingly (more on that tomorrow).
I will be making new user accounts all next week, though it will take another week or two to get all of the functionality up and running. I would have had it ready as a Christmas present for all of you, but I delayed things by a week in order to set up the system as a cluster of two machines instead of a single server. I had been under the impression that you really needed three machines for a cluster to be worthwhile, since you can't have a cluster of two independent machines without jumping through some hoops to set up a shared "quorum disk" to decide which of the two will be the owner of the cluster if they lose communication with each other. However, what you can do is make one machine a voting member of the cluster and the other a satellite node which can enter or leave the cluster at any time, but which can't operate as a cluster on its own (more info here).
Since I've connected the (high-end 15K RPM SCSI) hard drives to the larger of the two Alphas, I'm now running the second Alpha entirely diskless, sharing the system disk of the big Alpha with only a few megabytes of disk space required for the node-specific configuration files, along with an extra gigabyte or so for the new node's pagefile and swapfile (the swapfile is for swapping out entire processes, while the pagefile is for swapping individual pages in and out; other OS's use a single file or raw partition for both functions). The best part is that, although it took me a bit of effort and added complexity to go from 1 to 2 machines, and from a standalone to a cluster configuration, it's now trivial for me to extend the cluster from 2 nodes up to the maximum of 96 nodes.
I'll finish up my comments on clusters, OpenVMS, Alpha hardware, and related topics, tomorrow, as well as to announce a spin-off open-source programming project based around MINIX that I came up with while thinking about this stuff that has applications to many OS's and CPU's. I had to put it on hold in order to finish up the BBS project, and then I expect to spend most of my hacking time on the MINIX project rather than the VMS-specific hacking that I've been doing.
P.S. I forgot to mention in my original post that VMS also supports, and I have installed, or will shortly, Java 1.5.x, Perl, Python, PHP, Ruby, and other popular languages. It also runs Apache, Samba, MySQL, and various other open-source projects that you wouldn't think would run on VMS, including an old version of Mozilla and even a port of Firefox that currently only runs on Itanium but could theoretically be recompiled for Alpha with a little effort.
I'll also be running Process Software's MultiNet, a superior TCP/IP stack to DEC's offering, based on the latest 4.4BSD TCP/IP, OpenSSH, and related Internet client and server code, and another piece of normally expensive commercial software that is fortunately available to me for free under the same hobbyist terms as VMS itself.
