OpenBSD Journal

New Ports of The Week (February 16)

Contributed by jason on from the pass-the-shiraz-for-I'm-out-of-port dept.

Maxime DERCHE was kind enough to arrange this week's NPoTW. There were 17 new ports for the week of February 9 to February 15:

Piwik

Editor's Note: and a big honorary mention for x11/scrotwm.

Some ports had updates that users should be aware of.

New ports, listed in the order they were committed to the tree:

  • net/ircd-ratbox
    • ircd-ratbox is an advanced, stable and fast ircd. It is the primary ircd used on EFNet, combining the stability of an ircd required for a large production network together with a rich set of features, making it also suitable for use on smaller networks.
  • sysutils/memtest86+
    • Memtest86+ is a thorough, stand alone memory test for Intel i386 architecture systems based on the well-known Memtest86 written by Chris Brady.
  • geo/gdal
    • Gdal is a translator library for raster geospatial data formats.
  • www/piwik
    • Piwik is an open source (GPL licensed) web analytics software program. It provides detailed reports on your website visitors: the search engines and keywords they used, the language they speak, your popular pages, and so much more. Piwik aims to be an open source alternative to Google Analytics.
  • games/gargoyle
    • Gargoyle is an IF player that supports all the major interactive fiction formats. Most interactive fiction is distributed as portable game files. These portable game files come in many formats. In the past, you used to have to download a separate player (interpreter) for each format of IF you wanted to play. Gargoyle is based on the standard interpreters for the formats it supports: Agility, Alan 2 and 3, Frotz (glk port), Glulxe, Hugo, Level 9, Magnetic, Scare, Tads 2 and 3. Gargoyle cares about typography! In this computer age of typographical poverty, where horrible fonts, dazzling colors, and inadequate white space is God, Gargoyle dares to rebel!
  • audio/mp3wrap
    • Mp3Wrap is a free command-line utility which wraps two or more mp3 files in one large playable file without losing filename and ID3 information.
  • audio/libmp3splt
    • Libmp3splt is a free digital audio splitter library.
  • Gyrus
  • x11/gnome/gyrus
    • Gyrus is a small tool for the administration of mailboxes in IMAP/Cyrus servers. The main idea behind it is to provide mail server administrators with a better way to do the daily maintenance than a command line or a plain and boring telnet client. The main features gyrus includes are:
      • Browsing, creation and deletion of mailboxes.
      • Mailbox quotas control.
      • Management of IMAP Access Control Lists.
      • Creation of printable reports with over-quota mailboxes.
  • geo/geoclue
    • Geoclue is a modular geoinformation service built on top of the D-Bus messaging system. The goal of the Geoclue project is to make creating location-aware applications as simple as possible. Geoclue defines a set of geoinformation APIs, but it also includes some providers that implement those APIs.
  • graphics/clutter
    • Clutter is an open source software library for creating fast, visually rich and animated graphical user interfaces. Clutter uses OpenGL (and optionally OpenGL ES for use on Mobile and embedded platforms) for rendering but with an API which hides the underlying GL complexity from the developer. The Clutter API is intended to be easy to use, efficient and flexible.
  • graphics/clutter/clutter-box2d
    • A glue layer between clutter and box2d that provides a special group where the actors can be set to be static or dynamic in regard to a physics simulation.
  • graphics/clutter/clutter-cairo
    • An experimental clutter cairo 'drawable' actor. Sucks a bit as renders cairo via an image surface and thus no real cairo rendering acceleration. Experiments with glitz and sharing GL contexts for such acceleration proved problematic.
  • graphics/clutter/clutter-gst
    • Clutter-GStreamer (clutter-gst) is an integration library for using GStreamer with Clutter.
  • graphics/clutter/clutter-gtk
    • Clutter-GTK is a library providing facilities to integrate Clutter into GTK+ applications. It provides a GTK+ widget, GtkClutterEmbed, for embedding the default ClutterStage into any GtkContainer.
  • graphics/clutter/pyclutter (non-working, hence unhooked to the ports build)
    • This package contains the Python modules that allow you to use the Clutter toolkit in Python programs. This doesn't fully work yet, but it's now in-tree in case someone wants to have a look at fixing it.
  • geo/libchamplain and geo/libchamplain/libchamplain-gtk
    • Libchamplain is a C library aimed to provide a Gtk+ widget to display rasterized maps.
      • Display a map (OpenStreetMap Mapnik, OpenAerialMap, Maps For Free Relief);
        • Tiles are downloaded and cached
        • Downloaded tiles fade in
      • You can drag to move (a la Google Maps)
        • without or with kinetic scrolling (a la iPhone)
        • with elastic edges (a la iPhone)
      • You can zoom in / out
      • You can center the map on coordinates (longitude, latitude)
      • Add markers on the map with a mixed Clutter/Champlain API
      • Add layers of markers
      • You can animate markers
    • Libchamplain-gtk is a Gtk+ widget that wraps around libchamplain's ClutterActor. A small demo application is installed as libchamplain-demo.
  • x11/scrotwm
    • Scrotwm is a small dynamic tiling window manager for X11. It tries to stay out of the way so that valuable screen real estate can be used for much more important stuff. It has sane defaults and does not require one to learn a language to do any configuration. It was written by hackers for hackers and it strives to be small, compact and fast.

Updated ports that users should be aware of:

Removed ports:

No port was removed this week.

(Comments are closed)


Comments
  1. By jasper (83.161.197.124) on

    no need to mention json-glib here, it was already imported back in january, but i forgot about it and imported it twice ;-)

    Comments
    1. By jason (jason) on http://www.dixongroup.net/

      > no need to mention json-glib here, it was already imported back in january, but i forgot about it and imported it twice ;-)

      Thanks for catching that. I thought something smelled fishy. Removed json-glib and replaced it with scrotwm so Marco would stop whining. :)

      Comments
      1. By neal (99.142.2.135) on

        > > no need to mention json-glib here, it was already imported back in january, but i forgot about it and imported it twice ;-)
        >
        > Thanks for catching that. I thought something smelled fishy. Removed json-glib and replaced it with scrotwm so Marco would stop whining. :)

        Just wanted to give my thumbs up to scrotwm! Thanks!

        Comments
        1. By Anonymous Coward (24.84.108.117) on

          > > > no need to mention json-glib here, it was already imported back in january, but i forgot about it and imported it twice ;-)
          > >
          > > Thanks for catching that. I thought something smelled fishy. Removed json-glib and replaced it with scrotwm so Marco would stop whining. :)
          >
          > Just wanted to give my thumbs up to scrotwm! Thanks!

          Do you have the balls to use scrotum as your window manager?

  2. By Anonymous Coward (206.248.190.11) on

    How exactly does not being written in C "cripple" xmonad?

    Comments
    1. By Pierre Riteau (131.254.15.116) on

      > How exactly does not being written in C "cripple" xmonad?

      Portability? Number of hackers able to understand and customize it?

      Comments
      1. By Anonymous Coward (80.37.248.67) on

        > > How exactly does not being written in C "cripple" xmonad?
        >
        > Portability? Number of hackers able to understand and customize it?

        And dependencies. I for one do not want to have to build a whole functional language compiler thing and its runtime libraries just to run a "minimalist" wm. It might make sense if you are a Haskell developer, but otherwise...

        I still like dwm the best.

        Comments
        1. By Anonymous Coward (206.248.190.11) on

          > > > How exactly does not being written in C "cripple" xmonad?
          > >
          > > Portability? Number of hackers able to understand and customize it?
          >
          > And dependencies. I for one do not want to have to build a whole functional language compiler thing and its runtime libraries just to run a "minimalist" wm. It might make sense if you are a Haskell developer, but otherwise...

          I don't want to have to build a whole imperative language compiler thing and its runtime libraries. But of course, you don't have to build either, we have the magic of binary packages.

          Comments
          1. By Anonymous Coward (210.138.60.53) on

            > I don't want to have to build a whole imperative language compiler
            > thing and its runtime libraries. But of course, you don't have to
            > build either, we have the magic of binary packages.

            xmonad is configured by recompiling it, so binary packages only help if you're completely satisfied with the defaults.

            Comments
            1. By Anonymous Coward (208.124.37.81) on

              which is completely and utterly retarded.

            2. By Anonymous Coward (99.238.253.240) on

              > > I don't want to have to build a whole imperative language compiler
              > > thing and its runtime libraries. But of course, you don't have to
              > > build either, we have the magic of binary packages.
              >
              > xmonad is configured by recompiling it, so binary packages only help if you're completely satisfied with the defaults.
              >

              You seem quite confused. He was complaining about having to build GHC. And you don't have to, you can just use the binary packages of GHC.

      2. By Anonymous Coward (206.248.190.11) on

        > > How exactly does not being written in C "cripple" xmonad?
        >
        > Portability? Number of hackers able to understand and customize it?

        Considering how vastly more people contribute to xmonad than any of the C minimilist WMs, I think the number of people able to understand it is not an issue. What platforms does ghc not support that openbsd does (and has X support)?

        Comments
        1. By Matthias Kilian (91.3.35.205) kili@openbsd.org on

          > What platforms does ghc not support that openbsd does (and has X support)?

          sparc, spar64, arm, powerpc, did i miss one? yes: vax!

          Comments
          1. By Anonymous Coward (206.248.190.11) on

            > > What platforms does ghc not support that openbsd does (and has X support)?
            >
            > sparc, spar64, arm, powerpc, did i miss one? yes: vax!

            Of those, vax is the only one ghc does not support. It does support sparc (32 bit and 64 bit), x86 (32 and 64 bit), ppc, arm, ia64, alpha and hppa. I'll give you that arm, alpha and hppa are gimped since they don't support shared libs (and hence ghci). But why exactly would you feel the need to lie and pretend sparc and ppc are not supported when they work just fine?

            Comments
            1. By Anonymous Coward (2a01:348:108:155:216:41ff:fe53:6a45) on

              > > > What platforms does ghc not support that openbsd does (and has X support)?
              > >
              > > sparc, spar64, arm, powerpc, did i miss one? yes: vax!

              sh4 (landisk)

              > Of those, vax is the only one ghc does not support. It does support sparc (32 bit and 64 bit), x86 (32 and 64 bit), ppc, arm, ia64, alpha and hppa. I'll give you that arm, alpha and hppa are gimped since they don't support shared libs (and hence ghci). But why exactly would you feel the need to lie and pretend sparc and ppc are not supported when they work just fine?

              All OpenBSD architectures except m88k and vax support shared libraries.

            2. By Matthias Kilian (91.3.23.30) on

              > > > What platforms does ghc not support that openbsd does (and has X support)?
              > >
              > > sparc, spar64, arm, powerpc, did i miss one? yes: vax!
              >
              > Of those, vax is the only one ghc does not support. It does support sparc (32 bit and 64 bit), x86 (32 and 64 bit), ppc, arm, ia64, alpha and hppa. I'll give you that arm, alpha and hppa are gimped since they don't support shared libs (and hence ghci). But why exactly would you feel the need to lie and pretend sparc and ppc are not supported when they work just fine?

              You call me a liar? Send me your fucking diffs to our ghc port or stop calling me a liar.

              And no: I don't accept diffs for anything else than ghc-6.10 nor any diffs that have to download a precompiled binary in addition to source tarballs and .hc file bundles.

              I've spent more than a year trying to fix the broken GHC build system, without success. Now the GHC folks are trying to fix their broken build system for about six months, with moderate success (something builds, but it isn't yet installable).

              You must be a real genius if you have diffs that make ghc-6.10 (or -head) portable again and working on all platforms. So where's your diff?

              Comments
              1. By Matthias Kilian (91.3.23.30) on

                > [...] with moderate success (something builds, but it isn't yet installable).

                I always forget to mention the most important facts, like in this case, you need of course ghc-6.10 to build the ghc-with-new-build-system. No bootstrapping without ghc yet.

    2. By tedu (udet) on

      > How exactly does not being written in C "cripple" xmonad?

      try running xmonad on your sparc sometime.

      Comments
      1. By Anonymous Coward (206.248.190.11) on

        > > How exactly does not being written in C "cripple" xmonad?
        >
        > try running xmonad on your sparc sometime.

        Ok? What problem did you have with that exactly?

        Comments
        1. By Matthias Kilian (91.3.35.205) kili@openbsd.org on

          > > > How exactly does not being written in C "cripple" xmonad?
          > >
          > > try running xmonad on your sparc sometime.
          >
          > Ok? What problem did you have with that exactly?

          Are you kidding?

          Haskell is an interesting language, but there's no real standard (beyond Haskell98), and all those freaking Haskell projects are using some extensions that are available in GHC-6.6, -6.8, -6.10. And they're all incompatible. Go and build the latest xmonad on ghc-6.6. or build darcs-2.2.0 on ghc-HEAD. And alex, happy, and all the other Haskell stuff.

          Haskell isn't ready for prime time. Nor is xmonad (which is implemented in Haskell^WGHC). Nor is darcs.

          Comments
          1. By Matthias Kilian (91.3.35.205) kili@openbsd.org on

            > > > try running xmonad on your sparc sometime.
            > >
            > > Ok? What problem did you have with that exactly?
            >
            > Are you kidding?

            Oh, and I missed the obvious: on OpenBSD, ghc is working on i386 and am64 only.

            Comments
            1. By Anonymous Coward (206.248.190.11) on

              > > > > try running xmonad on your sparc sometime.
              > > >
              > > > Ok? What problem did you have with that exactly?
              > >
              > > Are you kidding?
              >
              > Oh, and I missed the obvious: on OpenBSD, ghc is working on i386 and am64 only.

              On openbsd. But everywhere else ghc works fine on sparc. Hmmm, I wonder where the problem could be.

              Comments
              1. By tedu (udet) on

                > > > > > try running xmonad on your sparc sometime.
                > > > >
                > > > > Ok? What problem did you have with that exactly?
                > > >
                > > > Are you kidding?
                > >
                > > Oh, and I missed the obvious: on OpenBSD, ghc is working on i386 and am64 only.
                >
                > On openbsd. But everywhere else ghc works fine on sparc. Hmmm, I wonder where the problem could be.

                Let's see. One problem is that instead of emailing the author your original question, you posted it here. Another is that it's strange that someone so vested in the current state of ghc would not know its status on openbsd, but yet would read an openbsd forum ready to spring such loaded questions. Another might be by working fine, you mean interpreted only, as there's no code gen on sparc. Another may be that if it takes 12 hours to build ghc, there won't be a whole lot of interest in fixing it.

                So yes, xmonad is crippled, because it takes longer to sort out the build issues with its implementation language than it does to reimplement it in C. But I suspect you knew that all along.

                Comments
                1. By Anonymous Coward (99.238.253.240) on

                  > Another might be by working fine, you mean interpreted only, as there's no code gen on sparc.

                  Yes there is. Have you actually tried GHC before on a working OS?

                  Comments
                  1. By tedu (udet) on

                    > > Another might be by working fine, you mean interpreted only, as there's no code gen on sparc.
                    >
                    > Yes there is. Have you actually tried GHC before on a working OS?

                    I based that factoid on this page http://hackage.haskell.org/trac/ghc/wiki/Platforms though that may not be the best source as it contains a few other obvious lies. ghc loses another gold star for not keeping their working platforms page up to date.

                    Yes, I've tried ghc before on a "working" OS. Unfortunately it didn't work that well (ghci fails immediately on amd64, though ghc does work).

                    Comments
                    1. By Matthias Kilian (91.3.16.250) on

                      > I based that factoid on this page http://hackage.haskell.org/trac/ghc/wiki/Platforms

                      Don't let the term "mini-interpreter" mentioned on that page confuse you. That strange thing is just a short loop that help implementing tail calls; something like this:

                              void *(*fp)(void);
                              fp = the_very_first_one;
                              while (fp)
                                      fp = fp();
                      
                      In the "registerised" builds, that loop is optimized away by modifying the assembly code generated by gcc using a really horrible perl script (known as the evil mangler).

                      > though that may not be the best source as it contains a few other obvious lies. ghc loses another gold star for not keeping their working platforms page up to date.

                      Well, I don't expect anything better on wikis in general. Their often out of date within minutes.

                      > Yes, I've tried ghc before on a "working" OS. Unfortunately it didn't work that well (ghci fails immediately on amd64, though ghc does work).

                      ghci (or rather the dynamic loader that GHC implements) doesn't cope with 64 bit addresses very well. On Linux, they use some MAP_32BIT option to mmap(2). On systems that don't have such an option, they use some really cruel hacks to help ghci working (on amd64, ghc-head kind of works).

              2. By Matthias Kilian (91.3.23.30) on

                > > Oh, and I missed the obvious: on OpenBSD, ghc is working on i386 and am64 only.
                >
                > On openbsd. But everywhere else ghc works fine on sparc. Hmmm, I wonder where the problem could be.


                If you're too stupid to search the mailing lists or use google, you'll probably never learn what the problem is. I'm not going to explain it again.

              3. By Anonymous Coward (208.124.37.81) on

                > On openbsd. But everywhere else ghc works fine on sparc. Hmmm, I wonder where the problem could be.

                Probably in the amount of caring. I for one couldn't care less if Haskel went up in a ball of flames. Nothing that matters to me was written in it. Code should be written in C, config files in text. The end.

          2. By Anonymous Coward (206.248.190.11) on

            > > > > How exactly does not being written in C "cripple" xmonad?
            > > >
            > > > try running xmonad on your sparc sometime.
            > >
            > > Ok? What problem did you have with that exactly?
            >
            > Are you kidding?
            >
            > Haskell is an interesting language, but there's no real standard (beyond Haskell98), and all those freaking Haskell projects are using some extensions that are available in GHC-6.6, -6.8, -6.10. And they're all incompatible. Go and build the latest xmonad on ghc-6.6. or build darcs-2.2.0 on ghc-HEAD. And alex, happy, and all the other Haskell stuff.
            >
            > Haskell isn't ready for prime time. Nor is xmonad (which is implemented in Haskell^WGHC). Nor is darcs.
            >

            So your argument is "the openbsd port of ghc is outdated". I agree, it is. That is hardly xmonad or darcs fault now is it?

            Comments
            1. By Matthias Kilian (91.3.23.30) on

              > > Are you kidding?
              > >
              > > Haskell is an interesting language, but there's no real standard (beyond Haskell98), and all those freaking Haskell projects are using some extensions that are available in GHC-6.6, -6.8, -6.10. And they're all incompatible. Go and build the latest xmonad on ghc-6.6. or build darcs-2.2.0 on ghc-HEAD. And alex, happy, and all the other Haskell stuff.
              > >
              > > Haskell isn't ready for prime time. Nor is xmonad (which is implemented in Haskell^WGHC). Nor is darcs.
              > >
              >
              > So your argument is "the openbsd port of ghc is outdated". I agree, it is. That is hardly xmonad or darcs fault now is it?

              No. My argument that Haskell is not ready for prime time. Too many breakage, too many incompatibilities over time.

              Heck, it's even almost a miracle that you still can build ghc-head with ghc-6.6 (you can't build ghc with the new build system with ghc-6.6, btw). If I would update our ghc port to ghc-6.10 now, this would immediately break most of the ports built with ghc.

        2. By tedu (udet) on

          > > > How exactly does not being written in C "cripple" xmonad?
          > >
          > > try running xmonad on your sparc sometime.
          >
          > Ok? What problem did you have with that exactly?

          Not ok. Kinda hard to run a program when you can't compile it in the first place.

          Comments
          1. By Anonymous Coward (206.248.190.11) on

            > > > > How exactly does not being written in C "cripple" xmonad?
            > > >
            > > > try running xmonad on your sparc sometime.
            > >
            > > Ok? What problem did you have with that exactly?
            >
            > Not ok. Kinda hard to run a program when you can't compile it in the first place.

            Yes ok, it works fine. If ghc doesn't work on openbsd/sparc then perhaps there is something wrong with openbsd? It works fine on linux and solaris for sparc.

            Comments
            1. By Matthias Kilian (91.3.23.30) on

              > Yes ok, it works fine. If ghc doesn't work on openbsd/sparc then perhaps there is something wrong with openbsd? It works fine on linux and solaris for sparc.

              Deinstall your ghc. Download the sources of ghc-6.10 (or -head). Then build it from scratch.

              The hc-bootstrapping of ghc is broken since years. It wasn't important for the ghc people, because running on linux and windows was "good enough", and because "if you can't compile it, just download a binary".

              The ghc people now care again. I hope that ghc-6.12 will have the bootstrapping back.

    3. By Anonymous Coward (208.124.37.81) on

      > How exactly does not being written in C "cripple" xmonad?

      I'll bite. Haskel sucks as a language for X or anything OS related. Sure you can use it to do cute shit on shit that OS developers couldn't care less about. That is besides the point that to change a fucking color one needs to learn Haskel, that is not just stupid, that is fucking retarded. Every piece of OS code not written in C is crippled because the underlying OS was written in C and it always ends up being tardy (support wise) or a hack; often both. So stop defending something OS related being written in a language that isn't C. What's next? C++ is good for anything else than mocking people who use it?

  3. By Anonymous Coward (81.165.178.114) on

    Thanks for scrotwm!

    Comments
    1. By Mike Erdely (merdely) on http://erdelynet.com/

      > Thanks for scrotwm!

      indeed. it's great!

    2. By Nick Rivera (nrivera) on www.rootshell.be/~nrivera

      Any thoughts about adding scrotwm to the Base System?

      Comments
      1. By Anonymous Coward (85.25.152.185) on

        > Any thoughts about adding scrotwm to the Base System?

        No because it's not under BSD License. Package maybe but definitely not under base.

        Comments
        1. By Nick Rivera (nrivera) on rootshell.be/~nrivera

          > > Any thoughts about adding scrotwm to the Base System?
          >
          > No because it's not under BSD License. Package maybe but definitely not under base.
          >
          >

          <a href="http://www.peereboom.us/scrotwm/html/license.html">http://www.peereboom.us/scrotwm/html/license.html</a>

          <i>It was written by Marco Peereboom & Ryan Thomas McBride and it is released under the <b>ISC license.</b></i>

          I like cwm and fvwm, but cwm is not tiling and fvwm is under GPL and Base System fvwm version work bad with non-latin characters.

          What is why I dream about tiling wm in Base System.

        2. By Anonymous Coward (208.124.37.81) on

          WTF have you been smoking?

          Comments
          1. By Nick Rivera (nrivera) on

            > WTF have you been smoking?

            Explain your response.

            Comments
            1. By Anonymous Coward (208.124.37.81) on

              Learn to read before spouting horseshit. The code is ISC licensed; aka simplified BSD.

              Comments
              1. By Nick Rivera (nrivera) on

                > Learn to read before spouting horseshit. The code is ISC licensed; aka simplified BSD. > >
                http://openbsd.org/policy.html Learn it stupid troll!
                The ISC copyright is functionally equivalent to a two-term BSD copyright with language removed that is made unnecessary by the Berne convention. This is the preferred license for new code incorporated into OpenBSD.

      2. By tedu (udet) on

        > Any thoughts about adding scrotwm to the Base System?
        >

        There are enough in base already.

        Comments
        1. By Anonymous Coward (80.37.248.67) on

          > > Any thoughts about adding scrotwm to the Base System?
          > >
          >
          > There are enough in base already.

          But none of them are tiling. Maybe some could leave their place?

  4. By Anonymous Coward (81.165.66.77) on

    thank you for the Gargoyle port!

  5. By Anonymous Coward (70.173.172.194) on

    Since we have ircd-*, does that mean that someone is working on ircd-unreal? I'm not its biggest fan, but it is popular.

    Comments
    1. By Anonymous Coward (83.171.182.124) on

      > Since we have ircd-*, does that mean that someone is working on ircd-unreal? I'm not its biggest fan, but it is popular.

      Does ircd-unreal depend on ratbox or what is the problem?

    2. By Simon Bertrang (85.182.79.101) simon@openbsd.org on

      > Since we have ircd-*, does that mean that someone is working on ircd-unreal? I'm not its biggest fan, but it is popular.

      In fact i've started porting unrealircd and others like asuka, fqircd, csircd, ithildin, inspircd and snircd but ircd-ratbox was the only one that actually convinced me. It has a nice config, does secure connections with SSL and goes side by side with ratbox-services, which is running in production already and in my queue of things to import (after the unlock).

      Perhaps I should post the initial ports so others can finish them...

      Regards,
      Simon

      Comments
      1. By Anonymous Coward (91.37.145.131) on

        Why do I have to think of this:

        http://en.wikipedia.org/wiki/Scrotum

        any time I hear of scrotwm ???



        Comments
        1. By Anonymous Coward (87.194.34.157) on

          > Why do I have to think of this:
          >
          > http://en.wikipedia.org/wiki/Scrotum
          >
          > any time I hear of scrotwm ???
          >

          I think that was the idea

Latest Articles

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.]