Problems With Open Source (OpenBSD) Systems - 6/4/00

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 database modules 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 be different.

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 wasted time.

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.

In addition 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 - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). 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 cgi-bin/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.