Recently in NetBSD Category

I'm not saying I won't go back to using OpenBSD (or even try FreeBSD on the desktop), but I'm sufficiently busy enough and have had a sufficient number of configuration and upgrade instances either take lots of time or go horribly wrong in OpenBSD that I'm continuing to use Linux (these days Ubuntu) on the desktop if, for no other reason, than that upgrading, configuration and adding the software I need is a whole lot easier.

As I've written recently (OK, I probably "tweeted" it), a true BSD distribution, i.e. one that provided a reasonable installer, timely binary updates and a wide choice of desktop environments easily installed is what I think is needed to take BSD (either Open- Free- or Net- ... or DragonFly ...) to the proverbial "next level," meaning use on the desktop by less-than-qualified geeky types (and maybe even "civilians") like myself.

Linux in general and Ubuntu in particular is just so good at taking care of the less technically minded while still providing a powerful, extendable operating system that can be used at just about every level and for every purpose. That's why I'm using it today.

As an experiment, I decided to bring my Evolutionary Computing presentation on making the journey into free, open-source software — a slide show originally created in OpenOffice Impress 2.4 — into Google Docs, which happens to have a presentation app in addition to the better-known Docs and Spreadsheets components.

I revised the presentation — taking some things out, adding others and providing some updates on what I'm doing — and output it as a PDF.

Download that PDF for your reading pleasure by clicking on the image above or the link below:

Evolutionary Computing (revised July 2009)

Interesting note: I believe that no previous entry on this blog has been filed under so many categories. (And I've been considering dumping Categories entirely and just using tags ...)

I tried quite a few OpenBSD ports during my last run on the Sparcstation 20. None of them would build (Firefox, Seamonkey, Geany).

Curiously, when I ran NetBSD on the Sparc, the Firefox PACKAGE wouldn't install. Not a port that needed to be compiled, but a precompiled package built for the 32-bit Sparc architecture. That didn't give me a whole lot of hope for pkgsrc, which theoretically can be used to bring NetBSD packages into OpenBSD and other OSes. (DragonFlyBSD uses NetBSD packages, and that's a great way for the FreeBSD-derived DragonFly to have a huge package repository, and it makes me want to try it on my i386 hardware).

I spent the past few days installing Solaris 9 on the Sparc 20. (I got the OS super-cheap — $1 plus shipping — from eBay, unopened in the box).

Solaris is quite a bit different from OpenBSD and Linux. I'm still getting the hang of it. A lot of the trouble I'm having is due to my near-total unfamiliarity with it. I do have "The Complete Idiot's Guide to Solaris 9," which I found remaindered at Fry's for a few bucks, and it's a good resource. It's somewhat short — not "complete," but for the "complete idiot," which I am in this regard. There are quite a few other Solaris 9 books out there, including a "Dummies" book by Dave Taylor, who wrote a general Unix book I quite liked (here's everything Amazon has that he wrote).

Back to the Sparcstation 20 after the Solaris 9 installation: With 50 MHz of CPU and 128 MB of RAM, it's far from ideal. GNOME &mddash; which ships with Solaris 9 — is almost unusable, but the CDE desktop is pretty responsive. It reminds me quite a bit of Fvwm in OpenBSD.

StarOffice 6 is included among the many discs in the Solaris box. When I installed it as root, only root could run it, so I started over again in my user account. The answer to this mystery is probably somewhere in my "Complete Idiots" book.

I found a Firefox 2.0.0.20 package built for Solaris 8 at the great SunFreeware site. Again, installing as root meant only root could use it. Even after installing it through the user account with su didn't work all the way. I can still run Firefox as root, but I get errors relating to patches that I need to do when I try to run it as my user. I'll have to read up on Solaris admin and eventually find and install all the Solaris patches.

But I did get Firefox to run, and it's WAY faster than Netscape 4.7, which shipped with Solaris. Yes, I did just type the words "Netscape 4.7."

I could very well keep Solaris on the box, but one idea is to run OpenBSD and then try to use the Solaris binary packages for Firefox and OpenOffice (since none of the OpenBSD ports of Firefox or Seamonkey will install on the Sparc 20).

Running Solaris binaries in OpenBSD is supposed to work. And yes, OpenBSD is a better, faster OS, for my use anyway, than Solaris on this platform.

Sun Sparcstation 5 image from the OSIAH: Online Sun Information ArcHive.

This post began its life as a comment on the previous Sparcstation 20 entry, and true to the way I overwrite even a comment, it works well enough as a standalone entry.

And thus, here it is in that form:

I've discovered that NetBSD doesn't run so well on the Sparcstation 20 (50 MHz processor, 128 MB RAM). The install went fine, but the X configuration was less than optimal. Console messages continued to appear on the X screen, and I could tell that, among other things perhaps, the horizontal sync and/or vertical refresh might have been just a bit off. I imagine that if I take the xorg.conf information from OpenBSD and use it for NetBSD, all issues will be solved.

But when NetBSD's 32-bit Sparc packages for Firefox and Seamonkey (precompiled packages, NOT ports) wouldn't install, and then the Geany package did install but ran so slowly as to be unusable, I decided to go in a different direction.

Thus far, that direction is a reinstall of OpenBSD. I haven't tried any ports yet, but all the packages I have installed — a few GUI editors (nedit, which I quite like, and another I can't remember), plus the Dillo browser, which in all fairness ran great in NetBSD, too — did work.

Now that I'm running not the box's original, jet-plane-noisy 2 GB Seagate hard drive but a super-cheap-on-eBay 35 GB Hitachi SCSI drive that's pleasantly quiet, maybe the installation of an OpenBSD port of a "modern" Web browser will work. Maybe not. I'll also try to roll Abiword onto the box, as well as Geany (for comparison's sake, if anything else).

And there's always Solaris.

I know there are Solaris-compatible packages for just about everything, so if I can't manage to get Seamonkey or Firefox installed from OpenBSD's ports with the extra disk space, my next move will be installing Solaris 9 (I got an unopened box of the software for $1 — yep, that little, plus shipping — on eBay) and see how that OS runs on the box.

One thing: Sound on the 32-bit Sparc platform doesn't work in OpenBSD. It does in NetBSD. Of course it does in Solaris, since Sun's OS was written with the Sparc in mind.

It may be that Solaris is the best OS for desktop use on the Sparc 20. Probably the best thing to do is get a CPU module faster then the current 50 MHz processor I'm now running, and also upping the memory to the max of 512 MB (right now I have the 128 MB the box had when I got it).

But make no mistake, for sheer out-of-the-box configuration on a Sparcstation 20 (sound nothwithstanding), OpenBSD is way ahead of NetBSD.

My next line of attack is trying a few (or more) OpenBSD ports. Even if this experiment goes well, I'll have to roll Solaris 9 onto the Sparc 20 before I decide on any long-term OS for the box.

Before I finish this entry, it's worth pointing out that Debian Etch for Sparc boots but won't install. It hangs when trying to load the CD driver. I don't know if the Sparc port of Debian is broken for EVERY 32-bit Sparc model, but it sure doesn't work for the Sparcstation 20.

Image above right: This isn't my Sparc; it's a Sparcstation 5 from http://www.computermuseum.org.uk. They look exactly alike (and in many ways are).

I've had my $10 Sparcstation 20 sitting on the desk for awhile. I don't have a monitor, mouse or keyboard hooked up, so I've been running it over the serial port, which was surprisingly easy to do, via my Windows box and PuTTY, which provides for connections over SSH on the network or via the serial port. (I've also used Tera Term and Minicom (the latter in Linux), as well as the cu utility in Linux and OpenBSD to facilitate serial connection to this box.)

Thus far I've had trouble loading and running just about everything on this 1995-era Sparc. The easiest system thus far to install has been OpenBSD. It boots and installs from a floppy, with the filesets coming over the network, with little trouble.

The only problem with OpenBSD is that many of the apps I want on the box are not in the Sparc 32 packages repository, which has many fewer prebuilt binary packages than are available for 64-bit Sparc systems. Thus, for things like Web browsers that aren't Dillio (which runs great under OpenBSD on the Sparc 20, by the way), I need to use ports. And every time I try to install one of those apps (so far Seamonkey, Firefox and the Geany text editor) from ports, the build fails.

Maybe that's why these apps aren't in packages: They won't build in Sparc 32.

I tried to install Debian Etch. The floppies I made wouldn't boot on the Sparc, and the CD stalls at loading the esp driver for the CD. I've seen this in bug reports, but if you can't get the installer to work, who knows what else lurks in Debian for Sparc 32?

Now I'm trying NetBSD 4.0.1 on CD. I would've tried the floppies there, but I could barely understand how to make them. (You need two, and I couldn't get the first one to boot on the box.) As far as making a bootable install floppy, OpenBSD is the only OS with which I've been able to do that successfully.

But NetBSD for Sparc 32 had many, many binary packages, and I actually have a good chance of setting up a nice box ... if I can load the OS.

Once I got the CD drive hooked up, my first try with the NetBSD CD ended with read errors when pulling the filesets off the disc.

But since I was able to boot the system from the NetBSD CD and then start the install process (which is extremely clear and straightforward, by the way), I opted to pull the filesets over ftp.

That worked, and now I'm booting into NetBSD 4.0.1, still over the serial port.

The box works. I had trouble with the terminal type, which defaulted to sun. That doesn't play well with the PuTTY on the serial port.

When I installed the system, I chose the Bash shell for root. I probably should've used the ksh, which which I'm becoming more familiar with in OpenBSD, but since I had Bash, this is how I set the terminal type in the console:

# TERM=vt100 ; export TERM

After changing the terminal type at the Bash prompt, I was then able to use vi to get into /etc/ttys and change that terminal type from sun to vt100 without the whole file blowing up — something that has bitten me you know where in my previous OpenBSD install on the Sparc. Morale of story: If you have the choice to set a terminal type and aren't using the attached Sun keyboard and monitor (or another Sun over the serial port), DON'T CHOOSE SUN AS YOUR TERMINAL TYPE. Use VT100, VT220, or whatever it is your terminal software emulates.

Without this change, you might be OK at a prompt, but bad things will happen in vi.

Tomorrow I'll try to control the box over SSH instead of the serial port and see if I can run X over SSH (and maybe ... finally ... get my $5 adapter to hook up a VGA monitor to the Sparc).

Right now, if I didn't need any applications from the ports tree, OpenBSD would run very well on the Sparc 20. But if I can manage to get a "real" Web browser (Firefox or Seamonkey) and my preferred X text editor (Geany) on the box with NetBSD packages, I'll stick with NetBSD and hopefully have a little fun with my 50 MHz Sparc 20.

Photo at top right: Thanks to HolyCowPie! for the "Stack of Sparcs" image. If you're in Omaha, Neb., or near it, HolyCowPie! will fix your hardware for $35 an hour with a two-hour cap, meaning you won't pay more than $70 — a stake in the collective heart of the pricier, Best Buy-owned Geek Squad.

Above: The Alix1b board. Prices are low for both the board and the cases, the power supply is on board (plug in a brick and you're in business ...), but don't think about asking for more than 256 MB of RAM.

Focusing on the embedded market (and seemingly well-liked by users of both Linux and the various BSDs) are the boards from the Zurich, Switzerland-based PC Engines.

The company has some extremely compelling and relatively inexpensive offerings ... if you're willing or able to run your application(s) in 256 MB of RAM.

The Alix1d features a 433 or 500 MHz AMD Geode LX CPU, 128 or 256 MB SDRAM on board, CompactFlash socket, 44 -pin IDE header (fits a 2.5-inch laptop drive), 12V DC, DC-DC converter on board, 1 10/100 Ethernet port, 2 COM, 4 USB, 1 LPT, audio, with VGA support in a 6.7" x 6.7" miniITX-size board with an Award BIOS.

Prices for these kinds of things are generally too high, but a look at the PC Engines pricing page shows the Alix1d selling for $132 with an enclosure for an extra $10 and AC adapter for $5.25.

This looks like a much-cheaper alternative to the likes of Soekris, and I can see assembling a very nice box (for embedded applications at least) to run under either Linux or any of the BSDs for way less than $200.

The only potential stopper for me (aside from the memory issue) is potential shipping charges from Europe. There are distributors of the PC Engines products located around the world, including the U.S., but I'll have to look more closely at both the prices and how to properly configure the OSes to deal with CF cards (or how to mount a 2.5-inch spinning hard drive).

(I should probably keep quiet about this, get a few more CF cards and just run the silent PC I already have, The Self-Reliant Thin Client.)

On second thought: I looked at the 20-page manual, which I've linked to below, and it looks mighty hard to get an OS on these things. Since there's no mention of it, I'm guessing there's no provision for booting from USB and that you have to use the 44-pin IDE header and somehow get it connected to a 40-pin CD drive, with drive power coming ... let's just say my head's starting to hurt. But these boards sure are cheap.

I'm retreating to the friendly confines of Logic Supply, in my opinion the best mini-ITX provider around.

But if you really know what you're doing, know how to generate boot images on CF cards and are thinking of buying lots of boards for some embedded use, PC Engines' products can seemingly save a whole lot of cash.

Related:

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.