OpenBSD Journal

The VAX platform is no more

Contributed by tj on from the vaxinating-the-tree dept.

After much internal discussion, OpenBSD has officially discontinued support for the VAX architecture. In a series of commits, Theo de Raadt puts the platform to rest.

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2016/03/09 09:28:50

Modified files:
	.              : Makefile.cross 
	sys            : Makefile 
	distrib        : Makefile 
	distrib/notes  : Makefile 
	distrib/sets/lists/comp: mi 
	distrib/sets/lists/man: mi 
	distrib/special/disklabel: Makefile 
	distrib/special/installboot: Makefile 
	etc            : Makefile 
	etc/examples   : remote 
	etc/mtree      : 4.4BSD.dist 
	include        : Makefile 
	lib/libc       : Makefile.inc 
	lib/libc/gdtoa : ldtoa.c 
	lib/libc/rpc   : xdr_float.c 
	lib/libm       : Makefile 
	lib/libm/man   : Makefile 
	sbin/disklabel : Makefile 
	sbin/newfs     : newfs.c 
	sbin/reboot    : reboot.8 
	sbin/wsconsctl : Makefile 
	share/man/man4 : Makefile 
	share/man/man8 : Makefile 
	share/mk       : bsd.README bsd.own.mk 
	usr.bin/gprof  : gprof.c 
	usr.sbin/installboot: Makefile 
	usr.sbin/wsconscfg: Makefile 
Removed files:
	distrib/notes/vax: contents features hardware install prep 
	                   upgrade whatis xfer 
	distrib/sets/lists/base: md.vax 
	distrib/sets/lists/comp: md.vax 
	distrib/sets/lists/etc: md.vax 
	distrib/sets/lists/game: md.vax 
	distrib/sets/lists/man: md.vax 
	distrib/vax    : Makefile Makefile.inc install.md 
	distrib/vax/cdfs: Makefile 
	distrib/vax/common: Makefile.inc list 
	distrib/vax/iso: Makefile 
	distrib/vax/ramdisk: Makefile.inc list.local 
	etc/etc.vax    : MAKEDEV MAKEDEV.md Makefile Makefile.inc 
	                 disktab fbtab login.conf sysctl.conf ttys 
	lib/csu/vax    : md_init.h 
	lib/libc/arch/vax: DEFS.h Makefile.inc SYS.h 
	lib/libc/arch/vax/gdtoa: Makefile.inc arith.h gd_qnan.h hdtoa.c 
	                         strtof.c 
	lib/libc/arch/vax/gen: Makefile.inc _setjmp.S fabs.S 
	                       fpclassify.c frexp.c infinity.c 
	                       isfinite.c isinf.c isnan.c isnormal.c 
	                       ldexp.S modf.S setjmp.S signbit.c 
	                       sigsetjmp.S udiv.S urem.S 
	lib/libc/arch/vax/net: Makefile.inc htonl.S htons.S ntohl.S 
	                       ntohs.S 
	lib/libc/arch/vax/string: Makefile.inc bcmp.S bcopy.S bzero.S 
	                          ffs.S memcmp.S memcpy.S memmove.S 
	                          memset.S strchr.S 
	lib/libc/arch/vax/sys: Ovfork.S brk.S cerror.S fork.S sbrk.S 
	                       sigpending.S sigprocmask.S sigreturn.S 
	                       sigsuspend.S syscall.S tfork_thread.S 
	lib/libkvm     : kvm_vax.c 
	share/man/man4/man4.vax: asc.4 autoconf.4 cons.4 de.4 dhu.4 dz.4 
	                         fwio.4 gpx.4 ibus.4 intro.4 lcg.4 
	                         lcspx.4 le.4 led.4 legss.4 lkkbd.4 
	                         lkms.4 mbus.4 mem.4 mscpbus.4 mt.4 
	                         mtc.4 ncr.4 qe.4 qsc.4 ra.4 rx.4 sii.4 
	                         smg.4 uba.4 uda.4 vsaudio.4 vsbus.4 
	                         vxtbus.4 ze.4 
	share/man/man8/man8.vax: MAKEDEV.8 Makefile boot_vax.8 
	sys/arch/vax   : Makefile 
	sys/arch/vax/compile: .cvsignore 
	sys/arch/vax/conf: GENERIC Makefile.vax RAMDISK files.vax 
	sys/arch/vax/dec: dzcons.c dzinput.c dzkbd.c dzkbdvar.h dzms.c 
	                  files.dec lk201_ws.c lk201reg.h lk201var.h 
	                  sii.c siireg.h siivar.h vsms_ws.c vsmsvar.h 
	                  wskbdmap_lk201.c wskbdmap_lk201.h 
	sys/arch/vax/if: if_de.c if_dereg.h if_le.c if_qe.c if_qereg.h 
	                 if_uba.h if_ze.c sgec.c sgecreg.h sgecvar.h 
	sys/arch/vax/include: _float.h _types.h asm.h atomic.h bus.h 
	                      cca.h cdefs.h clock.h cpu.h cvax.h 
	                      db_machdep.h disklabel.h endian.h exec.h 
	                      frame.h intr.h ka410.h ka420.h ka43.h 
	                      ka46.h ka48.h ka630.h ka650.h ka670.h 
	                      ka680.h kcore.h limits.h 
	                      loadfile_machdep.h lock.h macros.h mtpr.h 
	                      mutex.h nexus.h param.h pcb.h pmap.h 
	                      proc.h profile.h psl.h pte.h ptrace.h 
	                      reg.h reloc.h rpb.h scb.h setjmp.h sgmap.h 
	                      sid.h signal.h spinlock.h stdarg.h tcb.h 
	                      trap.h uvax.h varargs.h vaxfp.h vmparam.h 
	                      vsbus.h 
	sys/arch/vax/mbus: dz_fwio.c files.mbus fwio.c fwioreg.h 
	                   fwiovar.h if_le_fwio.c legss.c mbus.c 
	                   mbusreg.h mbusvar.h sii_fwio.c uba_mbus.c 
	sys/arch/vax/mscp: files.mscp mscp.c mscp.h mscp_disk.c 
	                   mscp_subr.c mscp_tape.c mscpreg.h mscpvar.h 
	sys/arch/vax/qbus: dhu.c dhureg.h dl.c dlreg.h dz.c dz_uba.c 
	                   dzreg.h dzvar.h files.uba qdreg.h qevent.h 
	                   uba.c ubavar.h uda.c 
	sys/arch/vax/stand: Makefile Makefile.inc 
	sys/arch/vax/stand/boot: Makefile autoconf.c boot.c conf.c 
	                         consio.c consio2.S data.h devopen.c 
	                         if_de.c if_le.c if_qe.c if_ze.c mfm.c 
	                         netio.c ra.c rom.c vaxstand.h version 
	sys/arch/vax/stand/common: romread.S srt0.S str.S vaxstand.h 
	sys/arch/vax/stand/xxboot: Makefile bootxx.c genassym.cf start.S 
	sys/arch/vax/uba: uba_common.h uba_dma.c uba_ibus.c ubareg.h 
	sys/arch/vax/vax: autoconf.c bus_dma.c bus_mem.c clock.c conf.c 
	                  cvax.c db_disasm.c db_disasm.h db_machdep.c 
	                  disksubr.c emulate.s findcpu.c genassym.cf 
	                  gencons.c gencons.h ibus.c in4_cksum.c 
	                  in_cksum.c ka410.c ka43.c ka46.c ka48.c ka49.c 
	                  ka53.c ka60.c ka630.c ka650.c ka660.c ka670.c 
	                  ka680.c led.c locore.S machdep.c mem.c mutex.c 
	                  opcodes.c pmap.c scb.c sgmap.c softintr.c 
	                  trap.c udiv.s unimpl_emul.s urem.s 
	                  vm_machdep.c vxt.c wscons_machdep.c 
	sys/arch/vax/vsa: asc_vsbus.c dz_ibus.c gpx.c hdc9224.c 
	                  hdc9224.h if_le_vsbus.c if_ze_vsbus.c lcg.c 
	                  lcgreg.h lcspx.c maskbits.h ncr.c smg.c 
	                  vsaudio.c vsbus.c vsbus_dma.c 
	sys/arch/vax/vxt: if_ze_vxtbus.c qsc.c qsckbd.c qscms.c qscreg.h 
	                  qscvar.h vxtbus.c vxtbusvar.h 
	usr.bin/gprof  : vax.c vax.h 
	usr.sbin/installboot: vax_installboot.c 

Log message:
We are done providing support for the vax.
lots of agreement.

Rest in peace (or pieces, more likely) old Vaxen. It appears 5.9 will be the last release to support these machines from the past.

And rumor has it that another platform may not be far off from discontinuation...

(Comments are closed)


  1. By Just Another OpenBSD User () on

    Goodbye VAX, kids never knew thy. Let's see how far they go before it's worth the spin-a-SIMH-ulator. Stay off my x86's!

  2. By Anonymous Coward () on

    Which? Alpha I suppose?

    1. By billy larlad () on

      > Which? Alpha I suppose?

      If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...

      1. By Anonymous Coward () on

        > > Which? Alpha I suppose?
        >
        > If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...

        it is a pity. that f... up endianess was a good way to find potholes.

        @sparc: still running the openbsd on 21 of them, from 25mhz to 175mhz. anyone else ?

        1. By Anonymous Coward () on

          > > > Which? Alpha I suppose?
          > >
          > > If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...
          >
          > it is a pity. that f... up endianess was a good way to find potholes.
          >
          > @sparc: still running the openbsd on 21 of them, from 25mhz to 175mhz. anyone else ?

          I have a handful of SPARC machines (sun4c/sun4m/sun4u) that I mess with from time to time, and have run OpenBSD on them in the past.

          I should fire these up.

          1. By Anonymous Coward () on

            > I have a handful of SPARC machines (sun4c/sun4m/sun4u) that I mess with from time to time, and have run OpenBSD on them in the past.

            sun4u is SPARC64, not SPARC.

        2. By Chas () on

          If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...

          Which ARM platforms are in danger?

          1. By Billy Larlad () on

            > If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...
            >
            > Which ARM platforms are in danger?
            >

            "OpenBSD/armish is the 3rd OpenBSD port to ARM based machines, after cats and zaurus. It is intended to support a variety of rather similar ARM-based machines:

            * Certance CP3100
            * Thecus N2100 (plus rebadged versions: Allnet ALL6500, Evesham SilverSTOR M-Box)
            * Thecus N4100 (plus rebadged versions: Allnet ALL6400, Evesham SilverSTOR XS)
            * IO-DATA HDL-Gxxx, HDL-GWxxx, and HDL-GZxxx series"

            1. By Chas () on

              All the same, I've been toying with the idea of an OpenBSD microserver for some time. The Jaguarboard looks significantly less concerning at this point.

          2. By Anonymous Coward () on

            > If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...
            >
            > Which ARM platforms are in danger?
            >

            ARM is a relatively recent architecture, and extremely popular in the mobile and embedded space due to its power per clockcycle efficiency. The port of ARM is also considerably newer, I would not consider it at risk.

            Sparcs, 68000s, DEC chips and such have not been kept current even in the hardware space in quite a long time.

            Moreover, there are still new CPU architectures being developed: Power8 and RISC-V both come to mind, so there will be other viable future architectures to port to for the future (FreeBSD is actively porting to both of these platforms, even though RISC-V has not even finished tape out yet and is primarily being done in Qemu for the time being).

            If you are a vintage hardware enthusiast, it also becomes obvious that the capacitors on equipment 20 years or older are starting to fail, and while there are a handful of individual globally who will replace the capacitors on such systems, the level of soldering work is painstaking and a really touchy skill set to maintain.

            Moreover, if you have seen recent hardware design in mobile devices, small SoC systems and such, the capacitors have primarily moved to ceramic, which while more resilient, are also much smaller SMT parts (rather than the previous SMD iterations) so doing aftermarket soldering work on such systems is extremely challenging without specialized costly soldering robot workstations.

            The hardware industry is, to some degree, designed to make itself obsolete. Languishing too far in the past is not necessarily deeply meaningful or useful, when there are still a variety of currently produced chips from a variety of vendors, which can still serve as useful cross-platform platforms for testing and finding the sorts of bugs which may not be easily exposed by merely cross compiling for other architectures without testing them (as NetBSD does for the most part; indeed, just earlier this week, I helped someone on an Amiga forum, troubleshoot a NetBSD install where the video signal was not being synced properly [turns out, his LCD could not handle the RGBHV output NetBSD was outputting after the bootloader stage properly, while resorting to an older CRT served as a workaround. That sort of glitch probably would have been caught by OpenBSD back when they still supported the Amiga platform, as they did testing on hardware; but they deprecated that hardware architecture long ago, even though it is more recent than the Vax, it was less impactful in the Unix world 「despite also running a variant of unix, and Vax systems being used in their design, it was decidedly a more consumer focused system and had a much more lightweight OS than anything that exists today」]).

            1. By Anonymous Coward () on

              > Power8 and RISC-V both come to mind, so there will be other viable future architectures to port to for the future (FreeBSD is actively porting to both of these platforms, even though RISC-V has not even finished tape out yet and is primarily being done in Qemu for the time being).

              In fact Qemu is a rather new (re)addition to the tools being used with RISC-V. After the new specs came out about a year ago, the modified Qemu could no longer be used and it took until February or so until somebody jumped at it and made it work again. So far primarily the "SPIKE ISA simulator" was used for development.

              For those who haven't heard about RISC-V: It's basically a new ISA originally developed for research and teaching over at UC Berkeley. It was open-sourced under a license well known to each of us and will allow for fully BSD-licensed processors in the future. And no, it's unlikely that it will share the fate of the GPL'ed OpenRISC. There are already organisations adopting it which will build RISC-V chips. One of them is lowRISC founded by people who made the Raspberry Pi a global success.

              The platform has the potential to become "the better ARM" some time in the future. Hopefully it'll run OpenBSD, too, one day.

              1. By Anonymous Coward () on

                > it's unlikely that it will share the fate of the GPL'ed OpenRISC.
                

                What was the fate of OpenRISC? According to Wikipedia

                https://en.wikipedia.org/wiki/OpenRISC#Commercial_implementations
                

                OpenRISC has multiple hardware implementations for several different commercial applications. Are you only complaining about the (lesser) GPL that OpenRISC is licensed under?

                1. By Anonymous Coward () on

                  > OpenRISC has multiple hardware implementations for several different commercial applications. Are you only complaining about the (lesser) GPL that OpenRISC is licensed under?

                  There are commercial implementations of OpenRISC, yes. However it never gained much traction and it has basically remained a Linux-only platform, not even NetBSD supports it, as far as I know. It may work well for what it is but it is very likely to remain in a narrow niche.

                  1. By Anonymous Coward () on

                    > There are commercial implementations of OpenRISC, yes. However it never
                    > gained much traction and it has basically remained a Linux-only
                    > platform, not even NetBSD supports it, as far as I know. It may work
                    > well for what it is but it is very likely to remain in a narrow niche.
                    

                    I'm skeptical of these sorts of predictions. I don't see any evidence that explains why OpenRISC should "remain in a narrow niche". But I don't see any evidence why RISC-V should be a resounding success, either. There are all sorts of attempts to create open source hardware architectures nowadays, including OpenSPARC, OpenPOWER, Loongson, and SuperH. But it's very unclear whether any of these attempts will be long-lived.

                    1. By Anonymous Coward () on

                      > I don't see any evidence why RISC-V should be a resounding success
                      
                      

                      Looking around, I discovered one reason why RISC-V may succeed:

                      
                      http://www.eetimes.com/document.asp?doc_id=1328561
                      
                      

                      A lot of industry leaders, such as Google, HP, and Oracle, are contributing to RISC-V. Nevertheless, it remains to be seen whether their "zero-royalty RAND license" will truly be "open".

            2. By Anonymous Coward () on

              > Moreover, there are still new CPU architectures being developed: Power8 and RISC-V both come to mind, so there will be other viable future architectures to port to for the future

              There might be some interesting stuff happening with POWER hardware. Raptor Engineering are supposedly working on ATX form-factor POWER8/9 boards with fully open firmware.

            3. By Just Another OpenBSD User () on

              > > Which ARM platforms are in danger?

              All of them (ARM). Start with the licensing:

              https://en.wikipedia.org/wiki/ARM_architecture#Licensing

              and continue with makers of chips and their policy for hardware docs release to developers, and then move on to compiler tools. Then check platform lifetimes and general chip availability time frames if you even have a chance to get this info in the open.

              > ARM is a relatively recent architecture, and extremely popular in the mobile and embedded space due to its power per clockcycle efficiency. The port of ARM is also considerably newer, I would not consider it at risk.

              Consider it at risk of getting any chance of completion before being thrown out by manufacturers due to obsolescence by newer fast iterating generations waiting on the production cycle. A considerable waste of scarce developer effort gone to garbage. Better used on lively platforms that don't suffer the phoenix self-incineration syndrome designed to keep small developers off the platform into the apps market.

              > If you are a vintage hardware enthusiast, it also becomes obvious that the capacitors on equipment 20 years or older are starting to fail, and while there are a handful of individual globally who will replace the capacitors on such systems, the level of soldering work is painstaking and a really touchy skill set to maintain.

              The electrolyte caps fail much much faster ~3-5 years, especially if running hotter than by design, even within capacitor ratings. Search online for the capacitor plague for a major fuck up industry wide (affects bulky electrolyte caps found in SSDs too):

              https://en.wikipedia.org/wiki/Capacitor_plague

              Degradation in quality everywhere, from universities to electronic components. Run for the cheapest, it's obsoleted by the manufacturer with software support withdrawal before the hardware fails ~1-3 years. Hooray for expensive to the consumer cheap to the producer electronic junk impossible to program and maintain at OS level for teams outside non disclosure agreements.

              > Moreover, if you have seen recent hardware design in mobile devices, small SoC systems and such, the capacitors have primarily moved to ceramic, which while more resilient, are also much smaller SMT parts (rather than the previous SMD iterations) so doing aftermarket soldering work on such systems is extremely challenging without specialized costly soldering robot workstations.

              Ceramics generally don't fail, if they have gone bad the board is usually toast elsewhere. This simply does not hold true, SMT re-soldering is trivial for plain discrete components. It's their value before failure that's harder to guess, especially without service and/or engineering docs. And when you have to replace chips, you better abandon the task at a small lab as you can't program them or will run into other complex problems.

              > The hardware industry is, to some degree, designed to make itself obsolete.

              No, not true. This statement only applies to fake consumer devices. Measuring equipment runs ~10-30 years almost maintenance free. This applies however to ARM even on chips licensing, so consider ARM in danger of adoption for real OS outside embedded / mobile hand-held devices or special use in controller boards.

              https://en.wikipedia.org/wiki/Planned_obsolescence

              Unless you have too many developers to throw at the miniature about to be obsoleted device, am looking at you lifeless ARM platform.

      2. By Anonymous Coward () on

        > > Which? Alpha I suppose?
        >
        > If you look at the thread 'VAX - are we dropping support in 5.9?' on misc@, a number of platforms -- armish, socppc, sparc -- are said to be near death. Also, in a post about dropping Vax, it was mentioned that one of the SGI build machines has died...
        >
        >

        Oh crap, not SGI or SPARC PLEASE!

  3. By Anonymous Coward () on

    So now the effort needed to keep the platform alive is officialy greater than the benefits of doing so are for other platforms? It would be nice if somebody knowledgable in this field prepared a kind of final write-up about what bugs could be found (and fixed) due to dragging the old Vaxen along as OpenBSD evolved.

    And more platforms are about to join the discontinued ports? That's interesting news! I guess that while this might affect just a few users directly, it could have indirectly effect on all of us. With each elderly/obscure piece of hardware retired, chances increase to have things like a C11 compiler in base, finally replacing the ancient and GPL'ed GCC. (LLVM is missing support for platforms like hppa and sgi among others, I think)

    Yes, I know, hoping for this to happen is probably a bit optimistic. But ever since the native hypervisor for OpenBSD was announced, almost nothing seems to be impossible anymore! So one might actually dare to dream a bit.

  4. By Chas () on

    The SRI Charon emulator for the VAX is quite expensive (>$100k) and I've seen several deployments. With all the cash that changes hands, it's a shame that OpenBSD could not find a productive niche in that ecosystem.

    The "baremetal VAX" commercial product quietly runs on Linux, likely due to both familiarity and drivers.

    1. By Ralph Siegler () on

      > The SRI Charon emulator for the VAX is quite expensive ($100k) and I've seen several deployments. With all the cash that changes hands, it's a shame that OpenBSD could not find a productive niche in that ecosystem.
      >
      > The "baremetal VAX" commercial product quietly runs on Linux, likely due to both familiarity and drivers.

      running on an emulator is easier compared to the issues on real hardware with timing and other quirks of real world devices. Reading what Theo and others OpenBSD devs have written the OpenBSD project has zero interest in running on emulators, only building, testing and running on real hardware. So the claimed support for various models of each hardware is legitimate and not a wishful hope. That is wise choice.

      1. By Anonymous Coward () on

        running on an emulator is easier compared to the issues on real hardware with timing and other quirks of real world devices. Reading what Theo and others OpenBSD devs have written the OpenBSD project has zero interest in running on emulators, only building, testing and running on real hardware. So the claimed support for various models of each hardware is legitimate and not a wishful hope. That is wise choice.

        I'd actually see a better fit with OpenBSD/AMD64 as the emulator host. Running Charon on Windows (the normal configuration) exposes you to demands for the quarterly patch/reboot pressures, misguided as they might be when running VMS as a client.

        A great benefit to "baremetal VAX" is the removal of said pressure, but the host OS is quietly Linux, which has had some showstopper bugs (i.e. your offshore operations staff runs towelroot). OpenBSD is a much safer host, but SMP performance would likely suffer somewhat.

  5. By Just Another OpenBSD User () on

    You do understand it's just salt saturated fat to expect an emulator to make up for the missing hardware? Losing a platform is like dental matter, it never goes back in original state. While you still can, try to keep as much platforms alive as possible, and get over the fact that life moves on forward. Do the right thing now, to not have to cry over it later. Start with the compiler and hardware spares sent by mail to the developer team. If you can't find spares, start packing software for portability.

  6. By deus VAX machina () on

    We uh, retired our last old VAX/VMS system about 4 years ago. It was 17, not even old enough to vote. A model 200, with a number of huge huge 2,000 MB disks, that ran DSSI. You could log into your disks in those days. Disks would last 18 years, in those days.

    HP, who bought Compaq, who bought Digital, could no longer find power supplies for the little gem. They searched worldwide. So much for annual support fees.

    The benefits to OpenBSD were of course all the upside of little-endian machines with a beautiful but slow ISA. The downsides are basically that they've been out of production for decades.

    SPARC killed VAX. Alpha was a poor ghost, unevenly supported with some killer glitches in implementation. HP finally delivered, then killed, a scalable SMP Alpha about 10 years after SGI did MIPS.

    You know what still worked in VAX? The interfaces: AC power (a hundred years old); serial ports (decades upon decades); Ethernet (decades!); VGA of a sort; even SCSI in some models.

    Some lessons are never learned: Digital tried proprietary BI bus and failed. HP tried proprietary 100 megabit Ethernet and failed. Hello, Docker.



    1. By Just Another OpenBSD User () on

      > HP could no longer find power supplies for the little gem. They searched worldwide.

      implausible: check your facts again

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]