Recently in FreeBSD Category

I always seem to have trouble with Ubuntu. On the $0 Laptop — the Gateway Solo 1450 — there comes a time in every Ubuntu install when the thing either won't boot or runs so slowly that I have to wipe the thing off the drive and start over.

It could be something particular to this laptop, the hard drive in it, or my constant dual- and triple-booting of Linux and BSD operating systems in a constantly shifting array.

When I use recovery mode to boot Ubuntu 8.04 and see the messages scrolling across the screen, I can see the point where it stalls. Something about ATA 2.01 is pausing for 5 seconds to look for devices. This pause used to be only 5 minutes, but today it appeared to stretch forever.

I had (and have) work to do, so I ctrl-alt-deleted out of there and booted Debian Lenny. I'll take the annoying screen artifacts problem in Lenny any day over not being able to boot at all in Ubuntu.

The Ubuntu problem began after an aborted installation of FreeBSD about a month ago. And even though I wiped that partition right away and have reformatted it a few times, Ubuntu still stalls during the boot sequence.

Now that I sort of, kind of know how to use rsync to backup my /home files, I need to delete the Ubuntu partition and start again. I have a funny feeling that I'll still have a problem. It could be the hard drive. I have an old 30 GB Toshiba drive in here that I bought on eBay, and it's probably not the ideal drive for daily use, it being old and all, but it's what I've got, and I've never had a problem before. ... Except for these Ubuntu problems (7.04 and 7.10 didn't fare too well in this respect; I thought that 8.04 would be OK, but that hasn't turned out to be the case).

Anyway, gotta get back to work, so I'll be auditioning distros soon enough to see what's going to work for me. I'm almost at the point of throwing CentOS on the box. I'm worried that I'll be missing packages and codecs that I need, and I'm nowhere near good enough with RPM repositories and packages to figure it all out. That's what I count on the people from Debian and Ubuntu for ...

I've really enjoyed using Ubuntu this go 'round. Everything has worked better than ever ... except for this not being able to boot. That's quite an "except," don't you think?

Update: The Ubuntu partition does boot; it just takes a long time.

My advice is to avoid dual-booting, and especially triple-booting (or even more than that).

If you set up a box to dual-boot with two Linux distros, Linux and Windows, or even a BSD (OpenBSD, NetBSD, FreeBSD) and Linux, and you leave it alone, you'll probably be OK.

But me, I'm testing things all the time, and lately I've been playing around with triple-booting on my Gateway Solo 1450 laptop. I've done this a lot, and I generally know how to do it so I don't hose one partition or another.

But I slightly hosed something on the laptop last night.

I've been playing around with FreeBSD, trying to figure out why it sometimes manages my CPU fan extremely well but usually not at all.

I have FOUR primary partitions on the 30 GB hard drive. The first is Linux swap, the second is Ubuntu 8.04, the third Debian Lenny, and for a long time the fourth was just an empty Linux ext3 partition where I could stash files large and small.

I started throwing new OSes on it about a week or so ago. I had PC-BSD on there, FreeBSD, Debian Etch ...

And last night I did another FreeBSD install. Now remember, I had FOUR primary partitions. As far as I know, no BSDs will install on a secondary partition. And in Linux, — again, as far as I know — you can only have four primary partitions. If you want more than that, you need to make one an 'extended' partition, and then you can fill that with a much larger number of secondary partitions (I'm not sure of the total number in Linux, but it's a lot).

When I was installing FreeBSD to the fourth primary partition, I veered from my usual practice of installing it in a single FreeBSD partition and instead let the installer auto-partition the portion of the drive set aside for FreeBSD.

Long story short, I think I screwed something up.

I deleted the screwed-up FreeBSD partition and replaced it with another Linux ext3 partition, but that didn't seem to "fix" whatever problem it is I'm having.

Debian Lenny boots fine. But Ubuntu 8.04 stalls in the middle. It eventually does boot, but there's a stall of a few minutes in the boot sequence. I booted in recovery mode to see what was going on, and it does appear to be disk-related, but I'm not quite sure what to do about it. I already deleted the "offending" partition, but maybe I shouldn't have replaced it (or so quickly before testing the other partitions)?

It's been over six months since I hosed a whole box, so in the grand scheme of things I'm not doing too badly.

But I should really start following my own advice and stop dual-booting on what, for me at least, amount to "production machines," which I rely on to get work done.

When experimenting, I need to swap whole drives instead, like I do with my VIA C3-based converted-thin client test box, which has three drives that are easily swapped via power and IDE cables that extend well outside the thin client's small case.

I didn't hose things so badly that I either lost files or can't boot either of the two Linux distros on the box, but I really need to be more careful, especially when mixing BSDs and Linux.

When doing just that, incidentally, I've had a lot more success by installing the given BSD FIRST, then throwing Linux on the box after that.

What I think I'm going to do, when it comes to Linux anyway, is to have the first partition be swap, the second partition for the distro itself and the third partition for /home. That way I can theoretically swap in new distros and keep the same /home file (backing that up, of course).

Now I'm going to think of what to install on the Gateway Solo 1450 to single-boot it for awhile.

I know that the Opera Web browser is not a free, open-source application — which I almost always prefer — but the browser itself is a free download for Windows, Mac and in precompiled packages for many flavors of Linux as well as FreeBSD.

Question: Why another Web browser? While Windows and Mac users overwhelmingly use Internet Explorer and Firefox, with a smattering using Apple's Safari, there's plenty of room for other entries in the browser space.

I don't know about you, but I'm in a Web browser about 80 percent to 90 percent of the time, both for the traditional task of looking at Web pages but increasingly to use Web-based software.

And for something so important, choice is key.

Users of Linux and other Unix-like operating systems are used to having lots of browsers to choose from, among them Firefox (and its non-copyrighted Iceweasel offshoot in Debian), Epiphany (the GNOME browser created from Mozilla's Gecko engine), Konqueror (the KDE browser/file manager from which Apple took code to create Safari), Seamonkey (the Mozilla-created Web suite that's modeled after the now-dead Netscape Communicator, offering browsing, e-mail and Web design in one application), Dillo (a very lightweight browser), Netsurf (also lightweight), a few more that I'm probably forgetting, plus text-only browsers that include Elinks, Links, Lynx and W3m.

I'd never used Opera before, mostly because of its closed-source status, although I have been "forced" to use Internet Explorer -- also closed source (hey, it's Microsoft -- what do any of us expect?), and besides, IE runs only in Windows and not in Linux (without difficulty, meaning use of WINE or a virtual machine) or Apple's OS X.

And our main Web application insists on IE not for all, but for the most "advanced" operation.

Imagine my surprise a few weeks back when I saw staff artist and Flash guru Jon Gerung using the Opera browser for the very task that usually demands IE.

Since then, I've downloaded Opera and have begun using it to work on Dailynews.com -- and for everything else, too.

There are a few instances where the CSS drops out, one situation where a link won't open, but for 99 percent of my work on this task, Opera does it as good as IE, often times better -- and always much, much faster.

That's the best thing about the Opera Web browser -- it's very fast. And that matters a great deal when doing Web-intensive work. You want to wait as little as possible for the software to do its thing so you can ... do your thing.

The company that makes Opera -- called Opera Software -- provides versions for many platforms. It's a pity you can't get the source and compile it yourself for Linux/Unix, but the speed and functionality of Opera is too good for me to pass up at the moment.

I'll still use Firefox -- probably a lot -- since it's the go-to browser for just about everybody out there, and I need to use the Web Developer add-on, but there's no denying that Opera is simply one of the best applications I've seen lately.

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.

I've been shuttling CDs in and out of my Gateway Solo 1450 laptop, just seeing what works and how well.

I've also been fiddling around with the BIOS settings, trying to get the CPU fan under control in both Linux and the various BSDs. A select few Linux kernels do this automatically ... most don't. I can control the fan with a cron job, but I've never, ever been able to do this with any version of BSD.

Until today. For some reason, I ran DesktopBSD 1.6 as a live CD, and the fan fell silent, turning on at various intervals, then off.

Like it's supposed to do.

I rebooted.

It worked again.

A couple of boots later, it stopped working. I changed nothing between boots. It could've had something to do with going from Debian Lenny to DesktopBSD ...

So while ACPI fan control is possible with FreeBSD -- upon which DesktopBSD is based -- I've got nothing in the bag. And it may never work again.

I tried PC-BSD 1.4 and FreeBSD 6.3 (just booting, not installing) ... and the fan roared as always. I thought I could control it from a console, but that didn't work.

But for two brief, shining moments, I had a FreeBSD-based system running with CPU fan management working perfectly.

If only it would happen again.

I've taken a few days off from OpenBSD, and in the interim I ran the NetBSD live CD for the first time on the Gateway Solo 1450 (the $0 Laptop). Again, it looks great, but I'm so far from figuring out how to manage the CPU fan in any of the BSDs that I'm not optimistic about running any of them on this laptop. I wish it were different, but until the heavens open and the path forward is made much more clear, I'll stick to desktops (and my old 1999-era Compaq Armada pre-ACPI laptop) for BSD.

During that time, I booted into Debian Lenny on the Gateway and installed 141 updates. Debian Lenny is moving along very quickly. I'm ready to put an Etch install alongside it for comparison's sake during the wait for Ubuntu 8.04 ... which is two months at this writing.

The best text editor for the job: The other day, I needed to do some work at home, and I wasn't having a great time with the Gedit text editor in Lenny. I somehow thought that Gedit had a way to change the case of words, but the Lenny version (Gedit 2.20.4) didn't seem to have it. Was I imagining it, or did the Gedit in Ubuntu 7.10 have this feature? (See below for the answer.)

Anyhow, I need a better editor ... so I went into Synaptic and installed three: Geany, Bluefish and Scite. I'm going to try them all out. So far I can't seem to change the case of letters automatically in Bluefish, but there are so many features that can help with Web development that it's probably worth using. But for the level of work I'm doing, I'm relying on Geany the most at the moment. I haven't used Scite much, but I do plan to give it a try soon.

But ... GEdit does have the ability to change the case of words/letters. Under Edit -- Preferences -- Plugins, there's a Change Case plugin. I enabled it, and now I can change case via the menu with Edit -- Change Case. I prefer to use the keyboard to do this ... so I'll probably keep the other editors in contention.

Foresight Linux: The Foresight Linux booth at SCALE 6X was fairly busy. I could barely get near it during the show, and since I didn't really put 2 and 2 together and remember that Foresight is dedicated to presenting the latest in the GNOME desktop environment, I didn't linger. But I do want to give Foresight a try. It has separate install and live images, so I downloaded the live CD image and am m going to see what it's like.

I'll be your server: I've never set up a server, and all this work with OpenBSD makes me want to roll one myself. I'm going to try to do one on the local network with NFS, Samba, FTP and Apache. I'll probably try in OpenBSD and Debian as well as Damn Small Linux.

Two excellent Linux books: Since I'm not made of money, I got both of these from the library. The "Linux Administration Handbook, " by by Evi Nemeth, Garth Snyder, Trent R. Hein and an army of more recent contributiors, is a hefty tome that's long on advice, Unix/Linux history and what people like to call "best practices."

While much of the book is flying right over my head, and I don't think you could really administer a system without a secondary reference that's specific to the Linux distribution you're using, this is a very valuable book that every serious Linux user should have. Especially when it comes to servers, there's a lot of information here.

"Linux Administration Handbook" is heavy on the philosophy of how to set up and maintain a system, and amid a sea of distro-specific how-tos that expire with every six-month release, that's a good thing to have. Still, what books like "Linux Administration Handbook" make evident is that at one level, most Linux systems are more alike than they are different, and the skills you develop using one distribution are very much transferable to the others. However, there are pointers everywhere in the book to specific instructions for Red Hat/Fedora, Debian/Ubuntu and Suse.

And if you want to see how professional sysadmins (or at least the good ones) go about their work, this is the book to get. It can't be the only book on your Linux shelf, but "Linux Administration Handbook" pairs very well with a doorstop-sized distro-specific how-to (like the "Unleashed" series of books, or Mark Sobell's "Practical" guide series) to help you get a handle on making Linux work for you.

The other book I got from the library, "Linux Administrator Street Smarts: A Real-World Guide to Linux Certification Skills," by Roderick W. Smith, is a great book for anyone who wants to figure out how Linux works from the command line. The book doesn't assume a vast knowledge of Linux or Unix. It offers many tips, instructions, and again, "best practices" on how to configure and manage a Linux system. This book is also not distro-specific; instead, it's one of the best command-line-centered books I've seen when it comes to basic system administration.

I don't know how good "Linux Administrator Street Smarts: A Real-World Guide to Linux Certification Skills," in helping you get actual "certification skills," but it will definitely help with the basics of setting up and maintaining a server or desktop.

Smith's style is clear and concise -- a rarity in these kind of books, which often leave me more confused than not. I definitely recommend taking a look at this "Street Smarts" volume.

So I had two winners here. I would probably buy both of these books, but that said, I still turn to Carla Schroder's "Linux Cookbook," which I'd love to see updated, and Michael Stutz's same-name-but-different "Linux Cookbook," which could use an update even more.

If I was in a buying mood, I'd get a more recent O'Reilly book, "Linux System Administration," by Tom Adelstein and Bill Lubanovic, and I really like Chris Negus' new "Toolbox" series of distro-specific books. They're fairly cheap and filled with good, timely tips, emphasis on the "timely" part. If only all of these great books were updated every couple of years instead of five years ... or never.

Click frequency: The "publish every day at 5 a.m." thing hasn't been working out so well of late. I just haven't had all that much time to do entries in advance, but I have had an entry every day ... just not prewritten to publish at 5 a.m.

One man's FreeBSD: I admire this guy, William Denton, for chronicling eight years of personal use of FreeBSD.

Debian ... ah, Debian: In case it's not evident, I still really enjoy using Debian. While I'm a great believer in the slimmed-down application mix in the default install of Ubuntu (which is based on Debian) -- with less indeed being more, on many levels I've had a whole lot more success with Debian.

I've done the default GNOME install of Debian, the Xfce and KDE installs, a "standard" install to which I've added X, and a few "standard" installs that were console-only. The flexibility of Debian is legendary, as is its stability and usability.

Some of my hardware has been supported better by Ubuntu at times, but I keep coming back to Debian. I'd love for Debian Lenny to support the Alps touchpad as well as Ubuntu Gutsy does. I'm hoping it'll happen before Lenny is frozen, and I will be trying Ubuntu Hardy when it comes out, but I'd love for Linux in general to get everything right for my Gateway laptop.

But since fan management has gotten worse, not better, over the past six months in the Linux kernels I've used, I'm only cautiously optimistic.

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.

When users say the documentation is excellent in the BSD operating systems, they're not lying. Besides the excellent handbook/FAQs available for download or online browsing for NetBSD, FreeBSD and OpenBSD, the man pages are way more valuable than I ever though.

In OpenBSD, they're up to date -- and they have plenty of plain language throughout.

I've been looking for the file that enables me to modify the menus in the default fvwm window manager in OpenBSD, and I was having a little trouble. Here's where I went:

$ man fvwm

And besides an exhaustive explanation of every feature in fvwm, the man page told me the exact location of the file: /usr/X11R6/lib/X11/fvwm. (The exact file name in that directory is system.fvwm2rc.) The man page also told me that fvwm looks first for .fvwmrc in the user's home directory and then looks for the systemwide file in /usr/X11R6/lib/X11/fvwm.

I met Dru Lavigne at SCALE 6x: I plan to write more about it in the near future, but I did meet author and BSD expert Dru Lavigne at the FreeBSD/PC-BSD booth at the Southern California Linux Expo on Saturday. We chatted for a good 10 minutes before I found out her name, and I really should've written down more of what we talked about. At any rate, she is a powerful advocate for running any of the BSD operating systems, especially FreeBSD. She has a new book out, "The Best of FreeBSD Basics." Given how smart and well-spoken she is, I have high hopes for the book.

Also at the FreeBSD/PC-BSD booth was Matt Olander, the CTO for iXsystems, the company behind PC-BSD. He also does PR for FreeBSD, the system behind PC-BSD (and DesktopBSD). Like Dru, he's enthusiastic -- and way smarter than I am. Among the things he told me was that the next version of PC-BSD will be a live CD/installer combo -- just like the latest version of the FreeBSD-based DesktopBSD.

Matt also said that while it's early in the process, the teams at PC-BSD and FreeBSD are working together to bring DesktopBSD's graphical ports interface to PC-BSD so users of the latter can make use of ports without using the command line. I don't know whether or not PC-BSD's PBI files -- applications that can be installed with one click -- is something that DesktopBSD will adopt in kind, but it's nice to see these two desktop BSD projects work together to benefit all of their users.

Among the things Matt and I talked about were the inclusion of Sun's ZFS filesystem in FreeBSD 7. And Wikipedia also says that ZFS is coming to NetBSD as well.

Dru, Matt and I talked about more than this. I'll write up the rest in the days ahead.

More BSD: I really like the new "toolbox" series of books by Christopher Negus. Looks like there's going to be one for the three BSD's soon: "BSD UNIX Toolbox: 1000+ Commands for FreeBSD, OpenBSD and NetBSD." Release date is May 12, 2008.

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.