Problems With Open Source (OpenBSD) Systems
This page was written in early June 2000 when my practical
experience with OpenBSD was still very limited. Since then
OpenBSD has become my preferred system for some applications, in
particular firewalls. I haven't checked (Feb. 2001) the new
installations of 2.8 to see if the GDBM_File that was not
included in 2.6 is now part of the standard Perl install. OpenBSD
might be the best OS on technical merits but still lacks
widespread application support characteristic of comparatively
obscure operating systems. Except for this paragraph, the page
has not been updated since it was written.
I'm continuing the discussion from site searching
from the point that I realized that GDBM_File was not included
with Perl on my OpenBSD system. While the details are specific to
Perl and OpenBSD, the kinds of problems encounterd and choices faced
are representative of problems frequently encountered when using open
source products. The advocates of open source systems sometimes seem
so fervent in their beliefs that they do not acknowledge these
problems exist or how serious an obstacle they can be to the adoption
of open source systems by those who are not already believers.
I might consider upgrading from OpenBSD 2.6 to 2.7 but it's not at all
clear that will get GDBM_File. 2.6 came with Perl 5.0503 and it's pretty
clear the standard distributions of that version included GDBM_File.
Since the creators of OpenBSD appear to have removed GDBM_File from 2.6
there is no reason to assume that it will be in 2.7. That raises another
potential problem that may occur in the future. If OpenBSD is for some
reason not including GDBM_File and I succeed in installing it, will a
subsequent upgrade of OpenBSD remove it?
I went to http://www.cpan.org to get GDBM_File. The more common
now appear to be included in the current release of Perl 5.6 and do not
appear to be available separately. I ended up downloading the 5.2MB Perl
file but the download did not complete successfully. The next day I
tried again but instead of going through the module documentation I went
straight to the source area to download stable_tar.gz. No file size was
supplied and when the download completed, it was 22MB, a rather tedious
download via modem. Further gunzip said it wasn't a gzip format and
PowerZip on Windows said the archive might be corrupt.
Next I went to a CPAN mirror, www.perl.org and got another copy, this one
named stable.tar.gz. This was only 5.2MB. When it was gunzipped the
resulting file was identical to the "corrupt" stable_tar.gz downloaded
from CPAN. It seems that despite its .gz extension someone forgot to
gzip the CPAN file but how is any user supposed to know that until they
do what I did and find another copy, download and uncompress it.
This is a big waste of time especially on modem Internet connection,
assuming that you do eventually find and uncompress the right file.
Once I started thinking about upgrading the entire Perl installation I
needed to know what was on the current system related to Perl. I don't
want to change Perl until I have the complete current install backed up
in such a way that I can revert to the original if the upgrade is not
successful. In looking at the current directory structure I found an
i386-openbsd/5.00503/CORE directory which contained a significant number of .h
files with compile directives that appear to be specific to BSD and/or OpenBSD.
Some or all of these same filenames are present in the central directory
of the newly downloaded version of Perl. That directory has a number of
OS specific read me files but none for any version of BSD (or Linux either).
What do I do next? I can think of a couple of options and as I consider
them it may become clear which is better. The fact is that I am faced with
an upgrade to an important part of my system with no system specific
instructions. If I don't go forward, I know I can't make an important
feature work on the OpenBSD system. One option is to ignore the Perl
upgrade issues right now and to go to OpenBSD newsgroups or list servers
and ask if 2.7 includes GDBM_File. Since I'm not a participant in such
a group that means finding the newsgroup or list. Posting a message
(ignoring the recommended lurking period) and hoping someone answers.
Of course there is always a question of how good the answers are in
newsgroups and lists, though this is a very simple question. Even if
I get an answer, if my previous conclusions are correct, it's likely to
be that it's not included leaving in exactly the same place I'm in
now. For an non critical system like mine this is not a big deal but
if this were a live system and the missing capability essential, it would
Going forward with Perl I can see several choices. One is to try a
"standard" Perl install using only what is included in the Perl just
downloaded. This raises the issue of what are all the system specific
directives for. I can try to figure out what's in the different .h
files. (A preliminary investigation suggests config.h is likely to
be a key file.) Though it's been a long time, I've done C development
in the past. What chances would someone without a programming background
have of figuring this out. Hell, what are my chances? The fact is
that I'm faced with a number of very uncertain options with no
indication of how much time this is likely to consume or whether
I'll eventually manage a successful upgrade or just spend a lot of
The safe approach is to spend a *lot* of time figuring out all the
differences between the standard install and the OpenBSD install and
individually moving these system specific changes into to the standard
files. This could be a huge waste of time. There is no way to know
in advance. I could try pointing the Perl system to the OpenBSD specific
files but this is for an older version of Perl. Presumably there are some
significant changes between 5.6.0 and 5.05.03 or they wouldn't have
changed the numbering. Will the older header files work with the new
Perl or will the be missing needed pieces?
The truth is that I'm enormously frustrated with OpenBSD at this point.
Though it was one of the easiest base OS installs that I've done, it's a
crippled system as the base install doesn't include a GUI. If I had to
choose between a GUI only system with no command line and command line only
system, I'd choose the command line only. In 2000 though, I don't have to and
won't choose. Only systems that include both are worth serious consideration
as desktop or general purpose server system. It shouldn't be surprising
that the systems I've gotten furthest with are Linux and NT.
to no GUI, OpenBSD's security orientation has denied me telnet access as
well. Until I find and install ssh on both Windows and Linux I don't
have any remote access. After I wrote this, it occured to me that telnetd
might be installed but disabled. Some checking showed this to be the case.
Also FTP runs at a small fraction of the network
speed I have. It doesn't matter whether I run the client locally or
remotely ftp transfers to the OpenBSD system are only around 200 - 400kbps.
OpenBSD may be a fine choice for certain specialized applications such as
firewalls and limited function servers but it's not ready for use as a
general purpose development or server system and surely not as an end
user desktop system. Some of OpenBSD's security has come from disabling
certain functions. Doing so certainly makes a system more secure
but it's also like comparing apples and oranges.
Top of Page -
Copyright © 2000 - 2012 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or terms.pl) from the time of the distribution.
Distribution of substantively modified versions of GeodSoft content is
prohibited without the explicit written permission of George Shaffer.
Distribution of the work or derivatives of the work, in whole
or in part, for commercial purposes is prohibited unless prior
written permission is obtained from George Shaffer. Distribution in
accordance with these terms, for unrestricted and
uncompensated public access, non profit, or
internal company use is allowed.