Recently in NetBSD Category

Note: I originally wrote this post on 2/15/08. Today is 4/24/08. Since that time, I've looked into updating in the BSDs a bit further. In FreeBSD, it's certainly possible to update both ports and packages.

Anyway, here is the "original" 2/15/08 entry:

While it's pretty easy to install software from precompiled packages or from ports in OpenBSD, FreeBSD and NetBSD, I've hit a bit of a wall when it comes to keeping any of these systems up to date with periodic security and bug patches.

I don't know if such updates are either not as necessary in the BSDs, even though my Linux boxes have a dozen or so of them every week, or that it's just to hard to do for the average BSD user.

I see plenty of Web help on how to upgrade from one version of a BSD to another, but I don't see anything that covers searching for periodically updated packages and updating an installation on, lets say, a weekly basis as security and bug problems arise and are presumably updated in the repositories of packages and ports.

O, BSD users, correct me if I'm wrong -- and I do hope that I am wrong. But with apt/Aptitude/Synaptic in Debian-based Linux distributions, rpm/Yum in Red Hat- and Suse-style systems, and upgradepkg (and slapt-get/Gslapt) in Slackware (with security announcements going to the mailing list and the www.slackware.com/security page) ... need I go on?

The point is that almost all Linux installations are easily upgraded with precompiled binary packages. Gentoo ... well, I won't go there because I know it has its own BSD-like ports system, but I've never used it and don't know how it works.

Again, the point is that all of these Linux distributions have me conditioned to expect -- and to install -- updates on a regular basis.

But what do I do with BSD? In OpenBSD, for instance, I've never even downloaded the ports tree. Everything I've installed has been a precompiled binary package for the i386 architecture. It's very slick, works perfectly ... but am I exposing myself to undue risk by running Firefox 2.0.0.6 instead of the newer 2.0.0.12? Is all that extra OpenBSD security for nought if I'm running applications rife with security holes?

I'm being completely serious. Is there something I'm missing here? Since OpenBSD, at least, updates the whole system every six months, am I OK to keep the same packages running until the next release? What does this say about BSD vs. Linux when it comes to security and bugs?

But wait. I did run DesktopBSD for awhile, and I remember that system having a GUI package manager that not only fetched new packages but upgraded those already installed.

So that's what Matt Olander was talking about when he said that PC-BSD and DesktopBSD were working together to share technology when it came to package management.

As far as I'm concerned, I don't need to do my updates in a GUI app. I'm perfectly OK with using the console. Just being able to do that updating is enough. That is, unless someone out there can convince me that Linux has conditioned me to think I need something that I really don't.

Those on all sides of this issue, please enlighten me -- and quickly.

Quick notes because I've got time for no more:

Debian Lenny: I hadn't updated Debian Lenny in about a week. Bugs are getting fixed all over the place. The latest wave of upgrades includes a couple of fixes for the Epiphany browser, which as a result is running better than ever. Most of what I noticed was cosmetic, but it just adds to the excellent functionality that Lenny already offers users. If you've been worried about running Lenny instead of Etch, I think the time is right to move to Lenny as it makes its way from Testing to Stable.

Preload in Debian: After reading about preload in Linux Journal, I finally installed it. Preload is supposed to monitor what apps you use most and automatically load them into memory, adjusting if your application habits change. Since I tend to run the same apps a lot, and since I have plenty of memory, I'm anxious to see how well preload works.

FreeBSD and the need for speed: FreeBSD 7 is now beginning its life as a stable OS. It's supposed to be up 15 percent faster than the fastest Linux kernels, up to 350 percent faster than FreeBSD 6x under normal loads, and up to 1,500 percent faster under heavy loads. I'm anxious to see how the hardware recognition performs. So far, I've had quite a bit of luck with DesktopBSD 1.6, which is based on FreeBSD 6, and I can only hope for better things with FreeBSD 7, which I plan to test soon.

OpenBSD update: I've been having a lot of fun -- and learning quite a bit -- with OpenBSD. I have the box on the local network, and I've been playing around with the ftp server, Apache Web server and with SSH. First I installed the PuTTY ssh client on my Windows XP box so I could connect from the XP box to the OpenBSD box. I could run any console program I wanted, and while it may not be a huge deal to the more experienced of you out there, it's a huge deal for me.

I wanted to run X over SSH, so I made the appropriate changes in OpenBSD to allow X11 forwarding over SSH. Ahd with the help of my friends over at LXer, I found out about Xming, an X client for Windows.

It took me awhile to figure out that I had to enable X in PuTTY to make it work. Xming runs in the background on the Windows box, and when I open an X program from the PuTTY console:

$ rox &

... A window opens on my XP desktop with the OpenBSD X program in it (which, in the case of the line above, is the Rox-filer). Pretty slick. (The & after the app name makes the process run in the background. I had one snag: I couldn't run the Dillo browser over SSH until I installed all the X fonts for Xming. There's a way to just use Xming to enable the SSH session, but that hasn't worked for me thus far. But since the PuTTY/Xming combination is working, that's what I'm going with.

I'd like to run a full X session with a full window manager running in a window on my XP box, but besides being slower than running single apps, I get the feeling that such a thing isn't exactly looked upon lovingly by the hard-core Unix geeks out there.

But being able to run any OpenBSD (or Linux) app on a network-connected box from a Windows-only PC is so totally cool that I should be sated in my dose of geekdom for the next week at least.

The $0 Laptop and its CPU fan discontents: I've been working with controlling my Gateway Solo 1450's CPU fan for months now. In Linux, I've had it controlled pretty well with a cron job, and in the case of Puppy a few added kernel modules.

But since then, I've come to realize that the cron job, which checked the CPU temperature every five minutes and turned the fan on or off depending on that temperature, is unnecessary.

All you need to do is turn the fan off at boot, and then ACPI will manage it just fine. This revelation comes after considerable work in the console, checking the temperature, running commands, running scripts and generally seeing what happens during the course of a computing session.

So I turned off my cron jobs, and now all I need to do is add the following line to /etc/rc.local:

echo 3 > /proc/acpi/fan/FAN0/state

That turns the fan off. I initially thought that only this line -- echo 0 > /proc/acpi/fan/FAN0/state -- would turn the CPU fan back on, but that is most definitely not the case. Once the fan is turned off with the "echo 3" command (which you can run from the console, just as you can the "echo 0" line), when the CPU gets warm, the fan turns on and then turns off when the CPU cools down.

So that one line added to /etc/rc.local is enough to get ACPI management of the fan working, at least in the Gateway Solo 1450.

Now there's the matter of OpenBSD, FreeBSD and NetBSD and this same CPU fan. So far nothing has worked, but I will keep trying.

I haven't hooked up my OpenBSD 4.2 drive and booted it for about a week. The last time I left the box, I was playing around with Apache, and I thought all was well.

Today I hook up the drive and boot OpenBSD.

First of all, instead of a console login, I get an XDM login. That's strange. I don't remember XDM ever showing up before.

Then Internet networking doesn't work. I check all the networking settings. Everything is correct.

I can ping IP addresses on the local network, but nothing is working outside of that. Pinging google.com yields nothing. Since I can get local machines, I know it's not a bad cable.

Back to the OpenBSD FAQ. Instead of doing ifconfig, I check all the files that hold network configuration info. Nothing.

To start networking manually, the FAQ says to do this:

# sh /etc/netstart

An error message comes up. There's an error of some kind in /etc/rc.conf.

Now I know what happened. To start Apache automatically at boot, a line must be edited in /etc/rc.conf. I was trying it, and I must've screwed something up. As root, I edit the file. Sure enough, I had erroneously dropped a linefeed in the middle of the comment line to turn Apache on at boot.

I fixed the line, saved /etc/rc.conf and tried to start networking again from the command line.

It didn't work.

I rebooted.

This time, I got my usual console login. I started X manually. And Internet networking worked.

I also configured an anonymous FTP server. I had to manually change the permissions of the directory and files to root, but everything worked as advertised.

That's the strength of OpenBSD, as well as FreeBSD and NetBSD: the documentation is readable, comprehensive and up to date.

Over the past two days, I did a Debian Etch install in order to compare how all of this server configuration goes in Linux as opposed to OpenBSD.

And this is where the lack of documentation (even the man pages aren't all that up-to-date). At least the apache2 man page for Debian told me about the apache2 command. When httpd and apachectl start did nothing, I was in a bit of a quandary. Luckily I figured out that apache2 start and apache2ctl start would both work. Oh yeah, and the config files aren't where the Debian man page says they are. Instead of being in /usr/local/apache2/conf, they're in /etc/apache2.

I did figure out how to change the default directory for Apache in Debian (editing /etc/apache2/sites-available/default does it).

Part of the problem was that I started with Apache version 1.3 in OpenBSD (which doesn't include Apache 2 for licensing reasons) and had Apache 2.3 in Debian. And sure I don't know quite what I'm doing, but this is all on a local network, not the wide-open Internet, so I'm a bit more free to experiment.

All this underscores the value of good documentation. And when it comes to some distros -- Ubuntu, Red Hat and Suse -- there are doorstop-thick books available. And the good ones are worth their weight in any precious metal you care to name. Luckily the BSDs have great online FAQs to help get you started. And since integration between the kernel, userland and other packages is so tight in the BSDs, and the need for documentation is that much greater, I'm damn glad it's there.

Not that Linux doesn't need something similar, but I don't see any Linux distribution short of Gentoo providing documentation this comprehensive and finely tuned to its users.

Can anybody prove me wrong? I truly, sincerely hope so.

Getting my feet wet in OpenBSD has gotten me thinking about how different operating systems handle software updates -- and how important security patches and bug fixes really are.

I'm thinking most of you will say they're very important. If you have a Debian-based Linux system, for instance, there are updates available almost every day, both security- and bug-related.

Live CDs are different. Knopix 5.1.1 has been around a very long time -- over a year at this point -- and plenty of people are using it, even though it's had no update of any kind in that period of time. But live-CD distros like Puppy Linux and Damn Small Linux have a new release every two or three months, and while the developers don't patch every single conceivable thing, I imagine that quite a bit of upgrading is done over the course of, let's say, six months.

OpenBSD, FreeBSD and NetBSD all offer apps in the form of ports, which are source files that you download and compile on your own machine, as well as precompiled binary packages for a variety of architectures (i386, powerpc, sparc, etc.). And the method for updating these ports and packages is something I'm still investigating.

m no expert yet, but I think the bulk of the updating for these BSD systems is done with ports through a CVS server. Taking OpenBSD as an example -- especially because that's what I'm running at the moment -- there are precompiled binaries for OpenBSD 4.2 that haven't changed since the version's release. So if you point to the packages created for OpenBSD 4.2 in your PKG_PATH, you get Firefox 2.0.0.6.

But if you look in snapshots, OpenBSD has a 2.0.0.12 package for Firefox on i386 that was uploaded two days ago.

(A quick check of the NetBSD repository for binary packages yielded Firefox 2.0.0.11, as well as preliminary versions of Firefox 3, for NetBSD 4.0.

So is it better to stick with the 4.2 packages, or to use the newer "snapshot" packages?

I'll give myself the answer: RTFM. While much is the same in the various BSD projects when compared to the hundreds of Linuxes out there, much is different -- and in the service of user choice.

But when it comes to getting the latest versions of ... well, everything, thus far I haven't yet figured out if there's a prebuilt script for updating binary packages en masse in OpenBSD and NetBSD. I know that FreeBSD has an app called freebsd-update that accomplishes this task, and I'm anxious to try it, but I'd like to know if I'm missing a similar utility in NetBSD and OpenBSD, or if the absence of this sort of tool is intentional.

My question: Am I compromising my OpenBSD system by running older precompiled binary apps? Does it really matter?

I'm conditioned by using Debian, Ubuntu and Slackware to expect updates on a continual basis and I wonder if I need to have the same level of vigilance with the BSDs. And should I be using ports instead of packages? While I'm on the subject, here's a way to keep up with new ports for OpenBSD. And here's the listing for Firefox.

Helpful site for OpenBSD: From OpenBSDSupport.org comes this page on how to replace Windows with OpenBSD. While it's based on OpenBSD 3.7 instead of the current 4.2, and that makes some of the information out of date, there are more than a few tips that can be applied to the newer version.

Plugging into OpenBSD: I've just signed up for a bunch of OpenBSD mailing lists, but there's also the OpenBSD Journal to help you keep up with what's going on.

Summing up: So far I'm having a lot of fun looking into the BSD operating systems. I met networking and security instructor, as well as prolific author Dru Lavigne at SCALE 6X, and she's going to send me a copy of her new book, "The Best of FreeBSD Basics," which means I'll be doing some work in FreeBSD in order to evaluate the book. In case you want your own copy, here it is on Amazon.

Google "linux vs. bsd," and this comes up. Written by BSD user Matthew D. Fuller, there's a lot of information to absorb.

Here he is on "Chaos vs. Order":

One common generality is that the Linux methodology is the living incarnation of chaos, whereas the BSD methodology is far more about control. To a large extent, it's true. Linux grew out of a spare-time hacking background, while BSD grew out of a controlled engineering background. Of course, there's plenty of weekend tinkers writing BSD code, and plenty of full-time professional programmers sloughing away at various parts of Linux. But the feel of the systems still does reflect that sort of schism.

We've already discussed the construction methodology; BSD builds up a core system which is uniform, whereas Linux distributions takes pre-existing pieces and pretty much puts them together helter-skelter. Naturally, the BSD method is far more amenable to keeping things ordered, while the Linux method practically necessitates utter chaos. That's not to say that chaos is inherently bad, or order inherently good. They're just different environments.

Linux will also generally chase new versions of other programs much more closely, adopting particularly more major changes like Apache 2 much sooner than BSD will move that way. Now, the stricter separation of "base" vs "ports" in BSD, as well as the structure of the ports tree itself, make it easier to have multiple parallel versions of packages in BSD. Sometimes, it's even possible and easy to have multiple versions installed at the same time. Linux, by not having that sort of separation, makes it very difficult to have parallel versions, and instead almost requires a single "blessed" one.

And the primacy of source-compiling in packages also makes it easier to handle multiple versions. For instance, PHP must be compiled differently depending on whether you're using Apache 1.3 or Apache 2. With from-source packages like ports, I can define an environmental variable when I compile and install PHP to tell it whether to use Apache 1.3 or Apache 2. With binary packages, you'd have to have 2 separate packages available, which will lead to confusion sooner or later.

Followed by "Right vs. Wrong":

The difference can also be seen in the way core code is integrated. BSD tends to always shy away from hackish solutions when there's even a hint of a proper solution in the wings. The theory is that it's far easier to wait for the clean answer, than to integrate the dirty answer now, for several reasons. For one thing, if you integrate the dirty answer, that reduces the incentive to implement a better one. For another, once you dirty up the architecture to integrate something it'll never get cleaned up again. You know it as well as I do. Oh, sure, you'll say it's temporary. But you know there's nothing quite as permanent as a temporary stop-gap. And things grow. The only way to avoid giving a mile is to refuse to give the first inch. It's just like taxes; when was the last time you saw a temporary tax that ever went away?

You also see it in what is there. Traditionally (though not universally), Linux integrates support for a piece of hardware before BSD does. But when BSD integrates it, it works. It's solid. It's stable. Linux drivers tend to have a lot more variance, because they'll be brought in earlier. In many ways, this mirrors the add-on case above, but in reverse. BSD has a very tightly controlled base system, and can be very free with setting up add-on software, since it's all added on by the user independently. Linux has a very loose and fluid coupling between the kernel and the userland, but the userland as a whole, due to not having a base/addon separation, requires a lot more work to keep consistent, which places a much higher requirement for a central "blessing" of various versions of packages. The extensive use of binary, rather than source distribution just makes it that much more so.

There are plenty of other "BSD vs. Linux" items out there, but this is the most detailed and well-reasoned of those that I've seen.

My process goes something like this: If you're starting with the hardware, test everything and see what runs best, what you like best and what fits the task the best. It might be Debian GNU/Linux, Ubuntu, Slackware, even Damn Small Linux or Puppy Linux. It could also be FreeBSD, OpenBSD or NetBSD.

I'm reluctant to give up on the Linux distributions I've come to know over the past year and then some, but in the BSD projects I see an opportunity to learn something new and do things a little differently. And since that's the spirit in which I began use of open-source operating systems and software, it's just part of the continuum of what I'm doing, the path I'm on, if you would be so kind as to indulge such thoughts.

That there's more than one or two -- or more than a hundred -- ways to skin the proverbial cat is a very good thing.

Debian tip: Here's a way to speed up booting of Debian when you're not connected to a network:

If you ever wondered, why exim4 needs so long to start when you have no net access, though you were sure that configured as satellite for a smarthost it should have nothing to lookup as the smarthost in in /etc/hosts, you might just have forgotten to put a

disable_ipv6 = true

in your exim4.conf. (I'm not sure, but that might also help
to actually deliver mail to hosts which also have ipv6 addresses
on servers with outgoing smtp when you forgot to blacklist the
ipv6 module).

Thanks, Bernhard R. Link, who works on Debian, for the tip. And read all of the Debian developer/bloggers at Planet Debian. Ubuntu does the same thing here.

Ubuntu 6.06 LTS will be upgradeable to 8.04 LTS: I've made no secret of my admiration for the 6.06 LTS version of Ubuntu, even though it's over a year and a half old. I like the way it runs, I've never had a problem with it ... and I like the fact that it will have support for three years of life on the desktop, even more on the server (until June 2009 on the desktop, June 2011 on the server).

But now that a new LTS is about to be released -- April's Ubuntu 8.04 LTS (if you haven't yet figured it out, the 8 is for 2008, the 04 for FebruaryApril) -- it's a good time to give it a try. If it works well on one box or another, Ubuntu 8.04 might be a good OS to install and stick with for a year, two or three. Now I've learned that there will be an upgrade path from 6.06 to 8.04.

I recommend a separate /home partition so a full reinstall can be done easily (but don't do it without a backup of /home), and I will probably do a full install instead of an upgrade, but it's nice to know that 6.06-8.04 can be done without a full reinstall.

OpenBSD doesn't use the CUPS printing system by default, and while I've been successful in using Apsfilter in Damn Small Linux (but not in Debian), now that I've figured out all the quirks in CUPS and my office network-printing situation, I prefer to use CUPS to manage the many network printers at my disposal.

OpenBSD tip: Whenever installing software in OpenBSD, it's a good idea to save whatever messages the system prints on the terminal screen for later reference. Nowhere is this more important than in the installation of CUPS, which requires a bit more user intervention than I've experienced before. Who am I kidding? I've never installed CUPS before in my life -- it's always "there."

Anyhow, back to OpenBSD and CUPS. As is always the case, you need to use sudo or su to root to install CUPS:

$ sudo pkg_add -i cups
(enter password when prompted)

or

$ su
(enter password when prompted)
# pkg_add -i cups

The system then kicks out the following:

To enable CUPS, execute '/usr/local/sbin/cups-enable' as root To disable CUPS, execute '/usr/local/sbin/cups-disable' as root

Starting cupsd will overwrite /etc/printcap. A backup copy of this file is saved as /etc/printcal.pre-cups by '/usr/local/sbin/cups-enable' and will be restored when you run '/usr/local/sbin/cups-disable'

As I said above, SAVE THIS IN A FILE. You might need it.

This is not enough to get CUPS going. You must do this as root (or, again, with sudo):

# /usr/local/sbin/cupsd

Now you can open a browser (in X, I used Firefox, but I think you can even use Lynx in a console), go to http://localhost:631 and configure your printer(s) as usual. Since everybody's situation is different, I'll leave instructions for the rest of CUPS up to you, except for one thing:

In OpenBSD, chances are you will need to find the right driver for your printer. I went to the CUPS Web site, more specifically to the Printer Drivers page, found the driver for my printer (an HP Laserjet 2100, if you must know), downloaded it and used it when configuring my printer in CUPS.

That's not all. By default, OpenBSD doesn't tell your system to automatically start the CUPS server at boot. I'm sure there's a more correct way to do this, but I added the following line to /etc/rc.local (again, you must do this as root or with sudo):

/usr/local/sbin/cupsd

Looks familiar, doesn't it? It's the same way we started CUPS in the first place. And now it'll start without any intervention by you on your next boot.

By the way, with CUPS controlling my printing, I can both print in X and from a console. Just use the old lpr command (with the name of the file you'd like to print):

$ lpr filename

Your file will print to your default printer. You can also specify a specific printer, print a certain number of copies, and do all sorts of other clever things at the command line.

NetBSD: While I'm having a lot of fun working with OpenBSD, I'm itching to repeat all of this with NetBSD. I didn't expect the NetBSD Live CD to run on my Compaq Armada laptop, what with the CD using KDE and the laptop only having 64 MB of RAM, but after a lengthy booting process, I did get to a console in NetBSD from the live CD, and wireless networking on my trusty Orinoco WaveLAN Silver PCMCIA card worked out of the box.

But the laptop's doing so well with Debian Etch, I'm wary of making any change. Still, I might keep my data in a Linux partition, wipe off Debian for now and give some other things a try. I can always reinstall Debian if that's the way things go.

As far as my converted thin client test box that's now running OpenBSD, of its three hard drives (any of which can be easily plugged in to run different OSes at any time), I've got one drive that I use mainly for Ubuntu 6.06 LTS, and another one with Xubuntu 7.04, Slackware 12 and Puppy 2.17 that I use rarely. That will probably become the NetBSD test bed at some near-future time.

Again, why? In case you missed the last time I answered this question, I'm playing around with the BSDs so much ... because they're there. Just as I don't think it's a great idea for everybody to just run Windows, it's also not such a great idea for the free, open-source software world to be about Linux and nothing else. Even if there are 300 Linux distributions out there, there's only one Linux kernel (albeit in many, many versions). The BSD operating systems are developed differently, and while FreeBSD, OpenBSD, NetBSD and, yes, DragonflyBSD (sorry I haven't mentioned that one until now) all have specialized uses, there's plenty of software available -- at least in FreeBSD, OpenBSD and NetBSD -- to run them as any kind of server as well as a fully functioning desktop computer.

And while the FreeBSD project has spawned PC-BSD and DesktopBSD on the desktop (the last one's pretty obviously aimed that way, given the word "desktop" in its name ... but I digress), there's no reason these other operating systems shouldn't be tested, used and enjoyed in the same manner.

Yours in operating-system diversity,

s.

... but wait, there's more:

Interesting blog: Larry the Free Software Guy is looking at "Eight Distros a Week." I went quite far back into his blog, and I plan to return often.

Take once a day: You might have noticed that Click is now publishing once a day, usually at 5 a.m. Pacific time. Rather than pushing out five entries on some days, even more -- or none -- on others, I'm trying to get ahead of myself a bit and make this blog more predictable for both me and you. If "breaking news" intervenes and I have something to say about it, I'll post during the day, but for now, look for a new entry at every morning at 5 a.m. Pacific. And no, I'm not awake that early -- the magic of Movable Type enables me to schedule posts to appear at any time in the future.

The "L" in SCALE may stand for Linux, but each of the three major BSD projects has a table at the Southern California Linux Expo. While the FreeBSD booth was giving away PC-BSD CDs (they still have about 500 left, so have at it, people), the OpenBSD booth was selling Version 4.2 CD sets for $45, and the NetBSD people were selling T-shirts for $15.

But it's not all about stuff.

I spent a lot of time talking to Kevin Lahey, a developer for NetBSD who is also a programmer for the Information Sciences Institute under the auspices of the University of Southern California. His organization does work for the Department of Homeland Security, and in the past Kevin has worked for the NASA Ames Research Center, and he told me that NetBSD has a lot of uptake in both government and university settings.

The NetBSD project began in May 1993, and is edging closer to its 15th birthday. It was nice to see Kevin's IBM Thinkpad running NetBSD with a GUI desktop. I've been impressed by the way NetBSD both looked and performed in the 2006-era live CD I tried on Friday, and while NetBSD is increasingly aimed at embedded applications, I think it's a great candidate for desktop use.

Kevin told me that NetBSD has over 200 active developers, most of whom do IT-related work for companies, many of which use NetBSD as part of their business.

As far as the desktop goes, NetBSD is getting better all the time at supporting the ACPI standard for power management -- something that will also see considerable improvement in the forthcoming OpenBSD release, as I learned at that booth. The NetBSD kernel also supports gigabit and even 10GB Ethernet, so it plays very well in many networked environments.

While OpenBSD encourages users to use the precompiled packages for the various architectures, NetBSD users rely on ports for adding applications. Also at the NetBSD booth was David Maxwell, and he told me that thera are about 16,000 ports for NetBSD. It always amazes me that there is so many applications available for the BSD operating systems.

I didn't quite get how NetBSD handles software updates, and Kevin tried to explain it to me, but there is some mechanism at work that can bring the needed updates down to your box as needed. It's something I'll have to look into more. Luckily, every one of the three BSD projects includes excellent, comprehensive documentation on their Web site.

As far as that documentation goes, David told me that NetBSD takes extra care to make sure its man pages are up to date.

Again, it's great to see a worthy project and the very smart people behind it.

After whining over a dozen or so entries about how my VIA C3 Samuel-based test box would boot and install OpenBSD but not NetBSD, FreeBSD, DesktopBSD or PC-BSD, I've had a great time working in OpenBSD, and I was surprised to learn that the NetBSD 4-based live CD boots into a KDE desktop, looks great and runs pretty well, too.

I recently burned the latest DesktopBSD CD, which in its latest version boots as a live CD and will install the system. On my Gateway Solo 1450 laptop, besides the power management not working, there's an unattractive blob that follows the cursor everywhere it goes (it's a cute little program-dependent icon otherwise). But on a fanless desktop (there is a CPU fan, but it doesn't run and hasn't killed the CPU yet)

But my desktop test box has never been able to boot a FreeBSD-based CD until today, when I figured I'd give DesktopBSD 1.6 a try. It booted, configured the monitor for 1280 x 1024 (I prefer 1024 x 768 and will try it that way later) and is now up and running. If I had more time, I'd do a full install on one of my three drives that I rotate in and out of use (they sit atop a CD-RW drive, all outside the main box and connected with extra-long power and IDE cables).

The DesktopBSD KDE environment doesn't look as nice as the one in the NetBSD live CD, and I'm not a big fan of KDE mostly because my old hardware can use all the help and speed it can get, but running both of these live CDs gives me hope that I can do some work with all NetBSD and FreeBSD in addition to OpenBSD to see what fits my hardware and goals for a desktop system.

So I think I'm "discovering" the NetBSD live CD, but I learn that Distrowatch announced the damn thing in 2006. All I can say is that I'm very, very impressed.

It's NetBSD, it boots on my temperamental test box, and not only does it have X, it has a full KDE desktop with tons of applications -- the full KOffice, Konqueror, Firefox, Abiword, K3b, Krita, the GIMP, Inkscape, JuK, XMMS, -- hell, just say it's got a full KDE 3.5.4 setup and then some, and NetBSD autoconfigured for my monitor (with the VESA option) and looks absolutely gorgeous.

If the NetBSD people could someday, someway, make this an installable live CD, they'd really have something here. So far, this looks and works better on my computer than DesktopBSD and PC-BSD. I guess the one thing this version of NetBSD is missing when compared to DesktopBSD and PC-BSD is graphical package managment, but the rest of it looks and works so well ...

While the NetBSD live CD attempts to configure a static IP address for you (ignore this if you use DHCP), it didn't work. To configure a static IP in NetBSD at a terminal -- and it is slightly different than doing the same thing in Linux -- here's how to do it (adapted from my similar tutorial for the FreeBSD-based FreeSBIE live CD):

My Ethernet interface, usually eth0 in Linux, is called rtk0 in NetBSD. If you're unsure, run this command:

$ ifconfig -a

That should output the name of your Ethernet interface.

To set the static IP in NetBSD I either used the same terminal window or opened a terminal window (Konsole in the KDE menu works fine) and became root:

$ su
(When prompted, for a password, the root password is root. If you signed on as root, you don't have to su, since you're already root).

At the # prompt, do the following (substituting your own networking numbers, of course):

# ifconfig rtk0 192.9.200.20 netmask 255.255.255.0 broadcast 192.9.200.255

# route add default 192.9.200.254
(Note: don’t use route add default gw, like in Linux — gw is not needed. As above, enter your own router/gateway address)

I also set up my name servers in /etc/resolv.conf (I used vi because I knew it would be there. You can also use any of the other KDE text editors in the live CD environment. Use any text editor you wish in its place:

# vi /etc/resolv.conf

once in the file, I added these lines:

domain yourdomain.com
nameserver 192.9.200.4
nameserver 192.9.200.2

(as always, add your own search domain and name server IPs, then save and close the file; you should now be ready to start Firefox and begin browsing the Web. Note: my connection doesn't require use of a domain in /etc/resolv.conf)

And again, if you have a dynamic connection, ignore this completely.

Additional info: Look at this PDF, which looks like a PowerPoint presentation for some background on BSD live CDs.

Look under /pub/OpenBSD/doc/obsd-faq.pdf and /pub/OpenBSD/doc/obsd-faq.txt on your nearest FTP mirror. The thing's 227 pages long in PDF form.

The 998-page FreeBSD Handbook, compressed in its various forms (including PDF, Postscript, text and RTF), can be found under /pub/FreeBSD/doc/handbook
from your local FTP mirror.

It's especially nice to be told to RTMF when the manual in question is as good as these two. And these are free books. I do recommend, especially, Michael Lukas' new FreeBSD book as a very valuable addition to your cadre of references. I'd love to see an update to his OpenBSD book, which now is out of print but still available for sale in PDF format.

From reading the OpenBSD FAQ, I've already learned that OpenBSD has an interactive mode for pkg_add, invoked with -i:

$ sudo pkg_add -i dillo

So you don't need the exact name of the dillo package; using -i would give you multiple, or a single choice (depending on whether or not there's more than one package with the name in question) without having to know all the extra letters and numbers at the end of the file name. Like I've said before, package management is very strong in OpenBSD.

It's also possible to use multiple mirrors, or a mirror and a CD-ROM in your PKG_PATH variable.

Again, in most Linuxes, this kind of thing is more hidden from the casual user. It's not all that hard to have a greater hand in setting these things up, and the understanding you gain by doing so is very valuable. (And I'm more confident using this kind of package management than pkg_tool in Slackware, which does a great job of installing packages but doesn't handle dependencies. I've used slapt-get (via the Gslapt GUI), but I'm a little wary about dependencies there, too.)

Also: OpenBSD includes a screensaver by default in X.

And: NetBSD has a terrific Guide that numbers 376 pages in PDF form. And now that I'm running the NetBSD live CD -- which has been out since 2006 but which I've also never heard of before today, I'm anxious to give NetBSD 4.0 another try.

Why a desktop installation of OpenBSD?

It's a legitimate question. According to Distrowatch, among the three main BSD projects (they don't like to be called "distros"), FreeBSD is way out in front -- and is the base for PC-BSD and DesktopBSD -- followed by OpenBSD and NetBSD.

And even though there are two desktop-focused versions of FreeBSD, and it's possible to turn all three of the major BSD projects into a desktop-worthy system, the question remains: Why not just stick with Linux, with its usually superior hardware detection, vastly larger community of users (who in theory and often in practice can provide all the help you need to get a system up and running) and much larger choice of distributions?

For one thing, Linux isn't alone on the desktop, nor should it be. Apple has a hugely popular desktop operating system based in part on code from BSD. And another operating system derived from Unix -- OpenSolaris -- is also inching onto the desktop with its Indiana project.

I think the competition is enormously healthy for free, open-source software, and I support that competition and choice wholeheartedly.

And using OpenBSD to build up a desktop system is just plain fun. It's more of a challenge, and all the configuration that I've done and am doing just teaches me more about what makes operating systems tick, even in my technologically feeble state.

I'm no coder. I've never programmed anything. I just mess around with hardware and software and then write about it.

I'm pretty much compelled to do all the things I've done over the past year and a half. It hasn't gotten boring.

And while I'm not going to move away from Linux, if the hardware and software cooperate -- as they have on this test machine -- I see no reason not to spend some considerable time running OpenBSD and seeing what I can do with it.

Again, my thanks go to all the people behind OpenBSD as well as the bloggers whose experience has paved the way for me to consider running the operating system and then to install and begin configuring it.

Going forward, I hope all of the major BSD projects -- FreeBSD, OpenBSD and NetBSD -- will continue to grow, keeping their documentation of the same ultra-high quality and enabling users to get more and more hardware working to the point where both server and desktop users have a greater number of choices than ever with which to get things done.

I'm happy to see news about NetBSD, via Distrowatch, in the form of an exhaustive, highly technical interview with some of its developers in Ars Technica.

As you might know (or not), NetBSD's niche in the BSD and general operating-system world is its availability on a large number of platforms -- 54 (and counting, I presume.

"Of course it runs NetBSD" is the project's motto. I'll try it again on my VIA C3 Samuel-based machine that only runs OpenBSD and not FreeBSD. I do believe I tried an older version of NetBSD on it, and it wouldn't boot, but I will try again. Not that I need to run NetBSD, which is not exactly well-known for its use on the desktop, but I remain intrigued by the three major BSD projects -- NetBSD, OpenBSD and FreeBSD -- and their various offshoots (including DesktopBSD and PC-BSD, based on FreeBSD; and OliveBSD, which I recently tested and which is based on OpenBSD).

While I don't think any of the BSDs is a great choice for the desktop at this point, I see improvements all the time and hope that the BSD projects provide even more competition for Linux in the server and desktop worlds.

We all know that Linux is a kernel, an operating system, maybe even a socio-political movement (it depends on whom you ask), but in a sense, Linux is about people -- those who create, use and promote it.

One of those people is Orv Beach, publicity chairman for SCALE 6X -- the Southern California Linux Expo -- being held Feb. 8-10 in Los Angeles. Since I'm covering the convention for Click, I took the opportunity to interview Orv after hearing from him about getting press credentials for the event, which I wouldn't miss, by the way. And if you do plan on attending, Orv told me that using the promo code CAST when registering for SCALE can get you 40 percent off of admission.

Orv, where do you live, how old are you, and what do you do for a living?
I live in Simi Valley, California, with my wife Beth. I'm 58, and I have four grown kids and four wonderful grandkids. Professionally, I'm the IT director at Simi Valley Hospital.

How did you first discover open-source software, and what part does it play in your work and home life today?
I've been interested in technology all my life. I got my amateur radio license when I was 17, and enjoyed building radio equipment as much as operating.

I got my first computer in about 1979, and when amateur packet radio was authorized by the FCC, it was a natural to use a computer with it. A popular packet radio program at the time was TNOS, written by Brian Lantz. It ran under DOS, and was a communications program & BBS. Brian had an active users group and was happy to add features to TNOS. As it grew in size, the C compiler he was using had more and more difficulties compiling it (It was Borland Turbo C, I think). So he moved TNOS over to Linux to use GCC as the compiler, and a large percentage of his users followed him.

I got Linux from a programmer at work. At that time it was 16 floppies, and that minimal version didn't include X Windows. I ran it on a 40 MHz 386 with 8 Megs of RAM. I've been using Linux steadily ever since and moved my desktop computer over to it full time about six years ago, and my wife's about four years ago.

At work, while Adventist Health isn't a full-blown user of open-source software, they're edging that way. The web programmers at our corporate office seem to have fallen in love with Plone. Some of the programming groups are moving to Project.Net for project management, too. Locally, I use Nagios to monitor over a hundred devices on our hospital network, and we use ZoneMinder to monitor some video cameras.

Now that SCALE is in its sixth year, how big was the convention the first time around, and what kind of growth has it seen? How many exhibitors, speakers and attendees do you expect this year?
SCALE is an offshoot of the "LUGFests" that SCLUG (the Simi-Conejo Linux Users Group - http://sclug.org) held every 6 months where they met at the Nortel building in Simi Valley. They were miniconferences, with people demonstrating open source software and even a few commercial vendors. Even as limited as they were, they drew Linux users from all over Southern California. SCLUG held 4 of them before Nortel closed down that building. (There's an article on LUGFest III here).

The last LUGFest, LUGFest IV, drew 400 people over two days. Based on the response to the LUGFests, we knew we were filling a need for information and education on open-source software.

So after a hiatus of a year or so, SCLUG, UCLALUG and USCLUG jointly started SCALE. The first was held in the Davidson Conference Center at USC. It was one day, with two session tracks. We had 11 speakers spots and a panel, and it was a struggle to fill them. That first Linux Expo drew 400 attendees.

Contrast that with SCALE 6X, which will be held in February, five years later: The main Expo is now on Saturday and Sunday, has 32 speaker slots and two keynotes spread over four session tracks per day. You'd think that number of topics and speakers would be impossible to come up with. Yet we received over 105 submissions to our call for papers! Whittling them down was difficult, and it was painful, as we had to turn down lots of good proposals. We expect to have about 1,500 attendees for SCALE 6X. The Westin hotel will be bursting at the seams.

Image of OliveBSD from the project's Web site.

The blogroll at Denny's blog -- Denny being committed to running OpenBSD as a full desktop operating system -- continues to point me toward interesting spins on the various flavors of BSD. Since OpenBSD is the only one of the three major BSD systems (which include NetBSD and FreeBSD) to run on my VIA C3 Samuel-based test box, I wanted to try one of the projects to which Denny linked right away. I've spent quite a bit of time trying to run the three main BSD projects and their various offshoots -- more trying than doing, actually, but I always want to try what's new. And since I have not a prayer of managing my laptop's noisy CPU fan in any BSD (I can do it in Linux), I pretty much want to use my converted Maxspeed Maxterm thin client. I have actually done a successful OpenBSD 4.2 install on this box in the recent past, but the idea of going from a minimal X install to a fully usable desktop was more than I felt I could do. I'm hopeful that O'Reilly's recent PDF book on OpenBSD will be of help in this regard, but I'm loathe at the moment to part with the $9.95 for the book without a little a) proof that it will work or b) encouragement that OpenBSD is something I should pursue.

Anyhow, back to the matter at hand. OliveBSD -- a live CD based on OpenBSD 3.8 -- was created by France's Gabriel Paderni in February 2006, and it seems that it has only had this one release. It does have a Distrowatch page, which confirms the 2/18/06 release date, and the only review of the project (I know BSD people hate using the word "distro" to refer to their systems, so I will substitute "project" throughout) was a "first looks" evaluation in Distrowatch on Feb. 20, 2006.

I'm happy to say that my experience with OliveBSD was much more positive than that of the Distrowatch reviewer. I downloaded the ISO, burned a CD on my XP box with ISO Recorder and then started booting the Maxspeed box. I got a few error messages about disk sectors (?), but the CD continued to boot. It tried to get an IP via DHCP, but since I have a static IP in the office, that was predictably unsuccessful. Before I forget to say it, it took a long time for the live CD to boot. But when it did, I had a working IceWM desktop, albeit at 640 x 480 resolution (this box and monitor can do 1024 x 768). I eventually tried to reconfigure X with the command xorgconfig at a prompt, but I didn't get very far. I probably need to get the xorg.conf file from one of my "successful" Linux installs (or even OpenBSD, should I try it again) and work from there.

But I had X, so the next task was configuring my static IP. In OpenBSD, this was part of the installation, and it worked great then. Luckily there's a script for it under the menu in OliveBSD. The script worked, I set my static IP, and I had networking. I started Firefox. It took awhile (just about every action results in the CD being accessed, but it's nothing I didn't expect). But Firefox did open -- the home page is the French rendition of Google. That gave me a bit of a laugh, but I was able to open other pages in Firefox (version 1.0.6) with no trouble.

Another thing, which the Distrowatch review also noted. In OliveBSD, you are logged in as root. That's a funny choice for a security-conscious project like OpenBSD, but it seems to work, so I won't complain any more.

Generally, live CDs for BSD have fewer apps than their Linux counterparts -- I don't think they have the same compression (or any at all, but don't quote me), but the application mix in OliveBSD is fairly good. As I already mentioned, the window manager is IceWM. The desktop isn't as "snappy" as I wanted, but a lot of that was due to live CD issues. Since the hard drive connected to the machine is formatted for Linux, even if OliveBSD was able to access a BSD swap file, I don't have one, so it was working entirely in RAM. And running top in a terminal, I learned that OliveBSD was only recognizing 143 MB of my 256 MB of RAM. That might have an effect on performance.

Back to the apps. Besides Firefox for Web browsing, there's Thunderbird for mail, the GIMP for image processing, SciTE for text editing, Xmms for audio playback, Gaim for text messaging, ghostview and Xpdf, Axyftp, the Abs spreadsheet, the TightVNC viewer, CD-Rchive and a few more. There's enough for me to get my work done, and that's pretty much all I ask. Again, I really appreciate the Network Card Configuration script in the main menu -- for those of us with static IPs, it's nice to get a leg up in that regard, especially for those unfamiliar with OpenBSD (and if you're running OliveBSD, chances are you are just dipping your toe in the BSD pond). I almost forgot to mention that OliveBSD uses one of my favorite file managers, the ROX-filer. ROX is quick, intuitive and powerful, and it's a great fit for OliveBSD.

Like I said, the fact that OpenBSD runs at all on this box seems to be a minor miracle (and it raises my esteem for the project considerably). Ditto for OliveBSD, which I'd love to see updated (are you listening, Gabriel?).

Meanwhile, I just learned that Anonym.OS is also based on OpenBSD. Created by someone who goes by the name dr.kaos, Anonym.OS is designed to allow users to search the Internet with a higher degree of privacy than afforded by conventional systems.

I burned a CD of this back in February of last year, but I never even tried to boot it. That's my next mission, which I have decided to accept. And yes, I am ready for the tape to destruct in five seconds ... four, three, two, one ... (cue Lalo Schifrin ...)

Read all about it at LXer, and yes, I will be there.

I'm pretty excited about the variety. There will be a lot of commercial vendors, and BSD will be very well-represented:

The commercial booths have all been filled. Several non-profit groups have recently been added to the SCALE expo floor: Enlightenment, which will be showcasing the work going into E17. Enlightenment is rarely seen at conferences, so this is your opportunity to learn about the desktop that first defined the term "eye candy". Also added were OpenMoko and Damn Small Linux. And for the first time all three of the major BSDs, OpenBSD, NetBSD, and FreeBSD will have booths at SCALE.

Look for an interview with SCALE publicity guru Orv Beach coming up on Click.