Recently in BSD Category

In addition to his first e-mail to me, David Gurvich adds more about his experiences with Intel i830m video in Linux and PC-BSD/FreeBSD:

I did think the problems with FreeBSD were due to using PC-BSD and installing a lightweight desktop on top. After testing with a bare install that turns out to not be the case and the issue is with FreeBSD and has nothing to do with the scripts that PC-BSD uses.

I have not tested OpenBSD but most of the wireless drivers on FreeBSD have been ported from there. I suspect there is a difference between the two that causes these drivers to crash the system on FreeBSD. The primary reason that I was interested in FreeBSD was ZFS support and wanted to setup a file server. The network issue stopped that in it's tracks.

There is a graphical network tool in the FreeBSD ports that seems to work ok but most of my settings were with wpa_supplicant and rc.conf. I believe that PC-BSD has it's own graphical network configuration tool but didn't use that.

Flash does have issues on FreeBSD and I don't recommend installing the linux compatibility to use flash. Instead, use wine with a windows browser. There is a memory leak in the linux flashplugin on FreeBSD that will eventually cause your system to freeze until you kill nspluginwrapper. The same technique may work on OpenBSD.

I have tried Fedora 12 on this laptop and that worked somewhat after tweaking a number of parameters. By somewhat I mean that I had random Xorg crashes and the tweaks simply mitigated the frequency. I gave F12 about 2 months but just could not take the crashes. Fedora 12 is working well on the other systems that I've installed it on but there was a problem with one that had ATI video which required building an xorg module from git.

I am currently using Arch linux on the X30 and, since configuring the boot parameters with 'nomodeset' and locking the xf86-video-intel driver to 2.9.1, have not had any issues with video. The main problem has been with the networking scripts and I am still not sure what the issue is there but installing wicd-1.7 seems to have worked around that. I am impressed with the speed vs Fedora 12. The reason I am impressed is that, prior to Arch, Fedora 12 had been among the fastest distributions on the X30 with a useable firefox in under 2 minutes. The X30 from startup to a working firefox connection takes 45 seconds in Arch.

The main issue I will have with Arch is likely the very reason Arch is so responsive. Rolling releases don't keep old packages around and new versions can cause random failures on working systems. That means that I will need to maintain a list of packages that should not be upraded and be careful on upgrades. Nothing new to anyone who has used Gentoo.

I've currently had Arch installed on the X30 for a month and have had no issues to deal with since the video and networking were fixed. The livecd boots to a text console and I recommend looking at the arch installation guide. Pretty much everything needs to be configured but the wiki makes that simple.

David Gurvich

David, you hit on a number of important points. I will definitely try Fedora 12 to see how it works with i830m, and I agree with you that Arch is an excellent choice. I've written many times about how the Arch community has been a great resource for me in solving my X issues with i830m all the way from Debian Lenny through now.

I neglected to mention ZFS in FreeBSD. That certainly is something to recommend in its favor. There's also a project bringing journaling to soft updates in FreeBSD's UFS filesystem that I heard about in this BSD Talk episode.

I'm not terribly happy about Flash being so problematic in FreeBSD. I forget all the trouble I had with the Opera browser in OpenBSD. That browser and its Flash plugin uses OpenBSD's Linux compatibility layer, and I was eventually able to stop most crashes by changing a parameter in Opera.

Here's what I'm hoping for:

• People smarter than me will figure this out and either make allowances in the kernel and xorg, or will create some other kind of mechanism that doesn't leave users of Intel 830m video chips out in the cold
• HTML 5 will sooner than later take hold with an open video codec and return Flash to what it's good at, which is little applications that I can safely ignore, and stop doing what it's bad at, which is delivering video that can better be handled by a plethora of other formats. The easiest way for this to happen would be for Google to open-source the on2 video codec it recently acquired. (Except that Google already converted the entire YouTube library to the loved-by-Apple patent-encumbered H.264.)

  I've run BSD before, and if Linux/Xorg throws Intel 830m under the bus, I'll be an enthusiastic user of any system that doesn't follow along.

I've been thinking about building my own very small machine around the dual-core Intel Atom processor with Nvidia graphics. Yes, I know that Nvidia is freedom-hating and all, but I think that for the small form factors such as Mini-ITX, Intel and Nvidia are heading in the right direction when it comes to compactness, power consumption and graphical sophistication.

I usually begin my search with my favorite Mini-ITX vendor, Logic Supply, but I have also begun looking at pre-assembled systems that ship with Linux. Both ZaReason and System 76 are building small boxes around the Intel Atom/Nvidia platform, some single core, others dual core — and I do recommend the latter.

The one stopping point for me, other than money, is that I'm not sure whether or not these pre-built boxes have CPU fans or use passive cooling from massive heatsinks. For years now I've been leaning toward machines with no spinning fans either in the box itself (on the CPU or elsewhere) or the power supply. With Logic Supply I can easily make this happen.

At ZaReason, the Ion Breeze 4220, starting at $399 for single-core, offers a variety of options, including the above-mentioned dual-core Ion CPU. I don't know if Earl, the ultra-accommodating chief technology officer at ZaReason, is offering the option of a fanless motherboard — I'll ask him.

System 76 offers its Meerkat Ion NetTop with dual-core Ion starting at $359.

One thing that ZaReason offers in the Ion Breeze that I like is an optional external fanless power supply.

I've been running my converted Maxspeed Maxterm thin client as a standalone Linux/BSD box almost since the beginning of my foray into open-source operating systems, with only a single fan blowing across the Mini-ITX motherboard and its heat-pipe-cooled CPU. The fan doesn't work when the box is upright, so for all intents and purposes this is a fanless computer, and I've never had a problem with thermal issues — in fact, it runs quite cool, if not quickly with its VIA C3 Samuel processor (that's supposed to be a 1 GHz model but for some reason only runs at 500 MHz), maximum of 256 MB RAM and woeful sound and video chips.

Right now the Maxspeed is running Debian Lenny from an 8 GB CF card inserted in the thin client's built-in CF-to-IDE interface. Yep, no spinning hard drives either.

System 76 does offer solid-state drives on the Meerkat Ion, starting at $110 extra for a 40 GB Intel drive.

If the Intel Atom Ion processor isn't what you're looking for, both System 76 and ZaReason have plenty of other desktop, laptop and server machines to look at.

The best thing about buying a computer from a shop that ships with Linux (in the case of these two retailers, Ubuntu) is that your hardware is pretty much guaranteed to work. You'll have audio, video, suspend/resume, all that stuff that sometimes is hard to get straight on the box that shipped to you with Windows.

In the times I've spoken with ZaReason's Earl, and the company will build, test and ship pretty much anything you want. They specialize in Ubuntu, but you can ask for a box to be loaded with Debian or CentOS, and I believe they'll do it.

Do ZaReason and System 76 charge more than your standard computer seller? Probably. You can't get the kind of bottom-of-the-barrel deals that are offered on the cover of the Office Depot circular, but those machines often do have bits of hardware that you'll tear your virtual hair out to get working properly.

When you get a machine from a company that specializes in Linux, not only will everything work, but you'll get support that will help you clear up any issues.

And for many people — and I'm getting more like this myself with less time available for banging-my-head-against-the-wall tinkering — it's worth a little extra money for somebody else to have figured out all the issues, or in the case of these companies, to choose hardware components that work well with free, open-source operating systems from the start.

And even if you are a tinkerer, chances are it ZaReason or System 76 have built you a machine, it won't just work well in Ubuntu but will be a great platform for other Linux distros you might want to run.

Not wanting to leave out BSD, you can get a pre-built and -loaded PC-BSD (based on FreeBSD) laptop as well as two workstations (prices unknown) from IXsystems, the company behind PC-BSD. They seem to specialize in selling servers running FreeBSD and ask that interested buyers request a quote to receive pricing info. They're also offering CD and DVD sets of FreeBSD 8.0 if you don't want to bother downloading the ISOs and burning your own discs.

Not to go off on a tangent or anything, I've been giving FreeBSD a lot more thought lately. I've run OpenBSD on the desktop as my primary system for about six months, and I'm considering FreeBSD instead for a future test for the following reasons:

• Easier upgrades and much longer cycle
• More focus on desktop users with hopefully better (and more meta-style) packages for things like GNOME
• Flash 9 and possibly Flash 10 support through the Linux compatibility layer
• Better performance
• I really don't need it for architectures other than Intel/AMD (although PowerPC and SPARC 64 are available; side note — on the various pages emanating from its platforms page, FreeBSD offers not only official manuals from the makers of the hardware in question but also links to other BSDs that run on the architecture. A very nice touch, I think)
• Community that actually cares about end users who aren't developers

I need to try some live images of recent FreeBSD/PC-BSD releases. (Is PC-BSD a live CD yet? I haven't kept up, but I did utilize the live environment of DesktopBSD back when I was testing it).

I never did the full review I promised of Dru Lavigne's excellent "The Best of FreeBSD Basics" book, but I find it to be an excellent reference for the FreeBSD and PC-BSD user. Dru is one of the best writers around in the Unix community, and even if you don't run BSD you can learn a lot about using Unix/Linux from this book. I got a whole lot about the shell, file permissions and other Unix sys-admin tasks, from "Basics," just as Michael Lucas' discussion of sudo in "Absolute OpenBSD" makes that now-way-out-of-date book extremely relevant and useful for anybody running any kind of Unix/Linux today who wants to make the most of sudo in their own environment (and especially on the server).

On the same tangentially arrived-at topic, Dru Lavigne's latest book, "Beginning PC-BSD: Frugal Unix for Power Users," is slated to be released three days from now. If past work is any indication, this will be an excellent book for anybody contemplating the use of PC-BSD.

I'd rather Dru write a book on using FreeBSD on the desktop — not necessarily PC-BSD but building out a FreeBSD-based desktop through ports or packages — but I can understand her focusing on PC-BSD given that the iXSystems-led project is a lot closer to what Linux users are used to.

Run the operating system and accompanying application software that ...

• Works best on your hardware
• That you feel personally/technically competent about (or want to get there)
• That includes the applications you want and need to use
• Which has an acceptable term of support from the project/vendor for your needs
• Which has an acceptable distance from (or to) the cutting-edge of software for your needs

Michael Larabel of Phoronix told me awhile ago that he was working on adding OpenBSD to his popular benchmarking application Phoronix Test Suite, and now he has an article benchmarking Debian GNU/Linux and Debian GNU/kFreeBSD snapshots of 6.0 Squeeze, Fedora 12, FreeBSD 7.2, FreeBSD 8.0, OpenBSD 4.6, and OpenSolaris 2009.06.

I don't think anybody expects OpenBSD to blow any doors off in terms of the usual Phoronix benchmarks. The whole mantra of the OpenBSD project is that it's not about raw speed, benchmarks, etc. Instead the focus is on correctness of code, security, cryptography and interoperability across platforms.

Here's what Larabel says in terms of his conclusion (emphasis mine):

There is a lot to gather from these benchmark results that directly compare the "out of the box" performance on Fedora, Debian GNU/Linux, Debian GNU/kFreeBSD, FreeBSD, OpenBSD, and OpenSolaris. If looking solely at the number of first place wins for each operating system, Fedora 12 and Debian GNU/Linux (2010-01-14) were tied with each having seven wins. Behind the Linux distributions, OpenSolaris 2009.06 and FreeBSD 8.0 were tied with each having two wins. Debian GNU/kFreeBSD and FreeBSD 7.2 each had one win. OpenBSD 4.6 had not won in any of our 20 operating system benchmarks. However, in this article we are just looking at some areas of the 64-bit OS performance and depending upon the system's configuration, tweaking, compiler changes, and other optimizations these results could certainly shake out quite differently. There are also features in some operating systems that make them more favorable than others depending upon your individual needs.

So in case you were wondering about performance across OpenBSD, FreeBSD, OpenSolaris, Linux (Fedora and Debian) and even the FreeBSD/Debian mashup, here are some answers.

All said, I remain interested in using FreeBSD and OpenBSD on the desktop as well as the server. I'm looking more closely at FreeBSD than I have in the past because of the project's willingness to support releases for what appears to be quite a few years. There's still a FreeBSD 6.x branch receiving updates, and that means that FreeBSD 8 has quite a life ahead of it.

The biggest stoppers for me with OpenBSD were the lack of binary updates to both base and packages during the life of a release (six months) and my general lack of ability to upgrade from one version of OpenBSD to another, either via an in-place upgrade or reinstall, without killing the whole installation in the process.

For those keeping score, I'm mostly running Debian Lenny right now, but I'm looking at the upcoming Ubuntu Lucid 10.04 as something I might want to move to later this year.

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.

I plucked this from the noise on Twitter:

A new project dubbed AerieBSD is starting, some say as a fork of OpenBSD (and from the looks of the planned architectures, I'd say they're right).

I'm not as enmeshed in the politics of the various BSD projects and their licenses as you might think, and the site isn't giving all that many clues as to WHY it's forking. Look at this (misspellings as they appear on the project Web site):

The ÆrieBSD project strives to produce a free, multi-platform UNIX-like operating system including the best possible free development environment. This includes (in adition to traditional BSD environment) free compilers, assemblers, linkers and other tools for various architectures as well cross-building capabilities.

The only name I can find on the site is that of a German guy named Michael Shalayeff, who's not hiding the fact that there's nothing to see yet ("we're working on our first release"). He is a (former?) developer of OpenBSD. I saw this reference to his work on the hppa port of OpenBSD and CARP.

I guess what Shalayeff is trying to say is that he doesn't want to use tools such as the GCC compiler or the GNU utilities that are not totally free in a BSD-licensing sense ... but I could be wrong. (And OpenBSD has this same goal, I believe.) So it's aiming to be BSD without the GNU (or the GPL).

To get somewhat of a picture of Shalayeff's involvement with OpenBSD and PCC, look at the mailing lists. (To be honest, I'm getting no clues there ...)

Look at the "about" page (emphasis mine, with my comments in footnotes, spelling theirs):

We are a group of individuals who like to hack operating systems. We are not driven by any kind of corporate agenda or market sales and thus can produce the best software ever, properly written. There is not any business or corporate backing (or even sponsourship) for the project. We even pay for it with our ice cream change! Since our time and resources are limited we use lots of software developed by other peoples and projects. Here is what our goals are (not necessarily in the order of priority):

* First of all hacking shall be fun and thus we resent any sort of political gaming and ego worshipping inside the project¹. If you want to be famous and naked -- here be a wrong place for you.

* Henceforth developers are the only real value that we have and this is who the project is for².

* Be open to the community and provide transparency of how the project works³.

* Provide free and functional best possible development environment. This includes free access to all source code, free development tools (compilers, assemblers, linkers, debuggers, text formatting tools, etc), various libraries and documentation.

* Support various hardware platforms (see Hardware page).

* Implement common standards.

* Pay attention to security and correctness⁴.

* Provide a stable release cycle⁵, although right now we are working on our first release (;

To keep the code free we prefer code licensed with ISC or 2- or 3-clause Berkeley style licenses. GPL is not really acceptable in the tree as through the years it has proven to be alot of trouble and counter-progressive.

OK, here are the footnotes (this is turning out to be easier to explain than I thought):

¹ I assume they're referring to what I call the "benevolent dictatorship" of OpenBSD, which was founded and now run by Theo de Raadt. The wording suggests "Theo doesn't like me/hates me/hates my code," or "my asbestos undies are wearing out."

² The "developers, developers, developers" mantra isn't just a Steve Ballmer thing. Everyone in the OpenBSD project is very open about that fact that the OS is coded by the developers, for the developers, and anybody else is free to use it as they wish, but if they want a certain feature or other, they best get to coding it themselves. And while everybody involved in OpenBSD thinks (and rightly so) that the OS is important to vast numbers of people, they as developers are pretty much scratching their own itch when it comes to their work. So ... I take this to mean, "We're just like OpenBSD, except we're in charge, and not Theo."

³ The whole thing about openness and transparency ... OpenBSD seems as open as they come. The whole tree can be seen by anybody at any time, everything is battled over in the mailing lists ... so it's more "we're just like OpenBSD minus Theo."

⁴ "Security and correctness (of code)" — again, right out of the OpenBSD playbook.

⁵ "Stable Release Cycle" means that, just like OpenBSD, we want it to be released like clockwork, every time ... so again, "just like OpenBSD minus Theo."

So what is AerieBSD and what will it become? I have no idea. If anybody out there knows anything, please post a comment on this entry.

Historical perspective: OpenBSD is a fork of NetBSD. Matthew Dillon's DragonFlyBSD is a fork of FreeBSD. I guess you could say that all the current BSDs are forks of the earlier BSD projects, principally 4.4BSD-Lite and 386BSD.

And you might not say that Linux is forked from Minix, it was certainly inspired by it.

Related:

• AerieBSD mentioned in the DragonFlyBSD blog
  
• AerieBSD mentioned in the Trivium blog

I'm a big user of the top utility, which provides a whole lot of data on what processes are running and how much memory and CPU they're using. I open up a terminal window and run top more than a few times every day.

I've seen htop before but haven't bothered to install it on any of my boxes in quite awhile.

I don't know what prompted me to do so, but I finally installed htop in Ubuntu 8.04. It's easy to do:

$ sudo aptitude install htop

And to run htop:

$ htop

The great thing about htop is that you can kill a process from the application itself. Just arrow down to the offending process and hit F9 to kill it.

It's a lot easier than opening up a new terminal window and using "kill" the old-fashioned way.

I just had to kill Firefox, which was pegging the CPU for some reason, and htop saved me a few steps.

Htop actually has configuration options, which can be accessed with the F2 key while in the application. I'm not at the point yet where I'm ready to mess with this, but I've known for awhile that the output of top can also be screwed with via command-line switches. Haven't done that, either, but it's nice to know that both top and htop have options.

And I really, really like being able to kill processes from within htop.

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 ...)

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:

Ah, the Linux (or BSD) distro review. They're relatively easy to crank out, they bring the traffic in a major way (especially when the excellent Distrowatch links to you).

But do they mean much? Not really, I think.

Most of the time it's the usual:

• "Here's what happened when I tried/failed/succeeded in installing Distro X on Hardware Y"
• "The installer is good/bad/barbaric"
• "Networking/printing/X was easy/hard/impossible to set up"
• "Package management is like Debian/Red Hat/Slackware and is good/bad/barbaric"
• "Repositories are big/small/good/bad"
• "My favorite apps are present/absent/broken"
• "The default desktop/menus/window manager are good/bad"
• "The community is active/nonexistant/helpful/hostile"

And the list goes on. I feel like writing a shell script that can pose questions and crank out automatic distro reviews.

What's harder to write — much harder than the quickie distro review — is a long-term review of a distro after a month or more of heavy use.

For one thing, most of us don't want to spend long periods of time running distros we don't like or aren't familiar with.

And for any given user, most of the 300+ active distros out there won't do anything for our hardware and work patterns that we don't already get from the distros we're currently using.

That's not to say that the many, many dozens of distros out there should just give up and stop trying to do something better and different (even though what they're doing is usually based on an existing distro and often doesn't add much, if any value to what they're already copying).

I'm just saying that after after a year and half of writing this kind of thing, I'm tired of both writing and reading quickie distro reviews that don't really tell the potential user of a given distribution all that much that they can use in making their decision.

I've already done tons of posts on Debian Lenny, and almost every problem has been fixed at some point in the project's long road from Testing to Stable.

So should I do another distro review on the installation, care and feeding of Debian Lenny when it finally does receive its Stable status?

Do I need to reinstall Ubuntu every six months and write about how that goes? OpenBSD?

Never mind that the development of OpenBSD is purposefully more evolutionary than revolutionary, or that a rolling release might be better/worse than one that comes out every six months or at some other regular (or not so much) interval.

I don't quite know how to end this tortuous post except to say that I reserve the right to change my mind. Maybe I'm purposefully shoving my own head in the sand by not embracing your favorite distro (usually Slackware or Mandriva) and sticking to what's been working for me (Ubuntu, Debian, OpenBSD, Puppy ... and that's about it these days).

Maybe it's part of the evolution (or devolution) of me as a writer about technology, but right now I'm convinced that that there's a better way to do all of this that doesn't throw out free, open-source software in favor of what the average guy/gal is using (Windows/Mac) but also does more than preach to the same creaky choir, of which I myself am a warbling member.

Being more truthful, I won't stop reading distro reviews, especially when they're written by writers who know what they're doing. But I plan to be a whole lot more careful about writing them. I've been thinking (and writing) for some time about why it's more than time for me to stabilize my herd of machines and stop the endless process of cranking one distro after another onto their partitions.

The freedom to change distros like underwear, at more than one level, begins to detract from what a computer operating system is supposed to be for, which is getting stuff done. I guess I want things to be more about ends rather than means.

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.

You might ask why I'm spending so much time figuring out how to best configure a Compaq Armada 7770dmt — a laptop with an ancient 233MHz Pentium II MMX processor, feeble 144MB of RAM and smallish 3GB hard drive.

For one thing, I almost never abandon a machine that can be used. And this one definitely can be.

Plus, I like the Compaq. It has a nice screen and keyboard, I like the fact that its power supply is totally contained in the laptop case. The thing's pretty solid.

And I remember my long search for a laptop. Just about everything I saw on the used market was overpriced and lacking essential parts (hard drive, power brick, CD drive, memory ...) but still selling for too much.

When I found this laptop for $15 and only had to add a CD-ROM drive that cost an additional $10 and a WiFi card I already had, I was hooked.

The build quality of this 1999 Compaq is much better than my 2002 Gateway, and I expect the Gateway to die long before the Compaq.

And with Linux, I've learned that a nearly 10-year-old PC can be quite usable. That means This Old PC, with a faster Pentium II processor (333MHz), more RAM (256MB) and which uses cheaper desktop IDE drives — and which at 11 years old is even longer in the tooth than the Compaq — is also still quite usable.

The fact that I searched long and hard for one laptop, came up with nothing from Craigslist and eBay, but then ended up with two laptops within months, getting each for next to nothing, was an opportunity to learn about hardware, software and what it takes to get things done in a variety of operating systems (I've run many versions of Linux, plus FreeBSD — including offshoots DesktopBSD and PC-BSD, NetBSD, OpenBSD, a couple of projects based on OpenSolaris, and yes, even Windows).

Even if I had $500 or so to buy new laptops every couple of years — and believe me, I don't, there's a lot of nobility, fun and plain old value in keeping these PCs running. And running well.

I guess you could call it a hobby.

I could do a lot worse, no?

Previously:
In search of the best OS for a 9-year-old laptop: Part I — Puppy or Damn Small Linux
In search of the best OS for a 9-year-old laptop: Part II — OpenBSD or Debian?
In search of the best OS for a 9-year-old laptop: Part III — Browsers and wireless
In search of the best OS for a 9-year-old laptop: Part IV — Wolvix Cub is surprisingly strong
In search of the best OS for a 9-year-old laptop: Part V — Where I'm headed
In search of the best OS for a 9-year-old laptop: Part VI — Younger Puppies
In search of the best OS for a 9-year-old laptop: Part VII — Debian with Xfce and Fluxbox calls

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.

I did a Debian Etch install on one of my test machine drives recently, and today I added the openssh-server package so I could play around with PuTTY and Xming.

Once I installed openssh-server (I used Synaptic, in case you were wondering), using PuTTY to start the connection, I was asked whether or not I expected the encryption key to change (I was, since this is the Debian install, not OpenBSD, which I've been using until now).

One bonus of using this Debian Etch install: The OpenBSD drive is noisy, which probably means it's gonna go. The drive on which I installed Etch is much quieter. I probably need to get some newer, bigger drives ... or a whole new test box, but that's another story for another time.

Quirks in Debian Etch with openssh-server: I can run X apps, no problem. When I run:

$ nautilus &

... I get a huge window with the entire GNOME desktop, minus the toolbars. And I can't close that window -- Xming won't let me, I think. X-ing it out doesn't work. I had to kill the process in my PuTTY terminal. (Note: $ startx & does not work ...)

Speaking of security: OpenBSD is known for its security above all else. Here's how using openssl openssh (which was created by the OpenBSD team) differs -- at my lowly level, anyway -- between OpenBSD and Debian Etch:

In OpenBSD: The sshd server is included in the standard install. But it can't be used until rootly powers are used to implement it. Running X over ssh is not allowed until the appropriate configuration changes are made. But root logins are allowed over ssh by default; the administrator, however, can choose to block root login (which I did).

In Debian: Debian installs without the ssh server installed. So without the administrator specifically installing openssh-server, nobody can ssh into the box. But once that package is installed, Debian automatically allows ssh logins -- and X logins as well. As with OpenBSD in its default state, root logins are permitted over ssh until that feature is turned off in /etc/sshd_config.

I don't understand all the lines in sshd_config, but I probably should get better acquainted with each and every one of them.

Speed? It could be the fact that this Debian Etch box has the GNOME desktop, and I've been running OpenBSD either from the console or the default Fvwm window manager, but everything happens a lot faster with the OpenBSD install (hardware is the same for both). I could modify Debian to boot to a console instead of GDM, and that might speed it up a bit (memory is 256 MB), but whatever the reason, thus far OpenBSD is a bit smoother. (Later, things seemed to run a bit better when I didn't log in on the Debian box and hence didn't have GNOME running).

More on security: If this box wasn't just something for me to play with on the local network, the stakes would be a lot higher. I suppose not having sshd is pretty good security when compared to having sshd installed but not enabled. And I also suppose that installing sshd (openssh-server) means that you want to actually use it. But in the case of both OpenBSD and Debian, I wonder why root logins over SSH are enabled by default. If anything, I'd expect OpenBSD to disallow them until the administrator of the box decides to turn that feature on.

And since you can always use su or sudo (Ubuntu has conditioned me to like sudo, and I always add myself to the sudoers list with visudo, there's really no reason for a root login over ssh.

Side note: Debian doesn't automatically add the primary user to the sudoers list, something I always do because on many occasions I'd rather use sudo than su.

Ubuntu, by default, disables root logins entirely and only offers sudo. It makes setting root's crontab a pain in the ass. I use sudo -i crontab -e to get into root's crontab in Ubuntu.

Side note to a side note: While I can fake my way around vi, I like it when nano is the default editor and crontab -e brings up nano instead of vi. The one thing I don't like about nano is that when you wrap text, actually linefeeds are inserted. At least in vi you can have the text break in the middle of a word without turning word wrap on (although you are able to do so if you want wrapped text). The one thing I like in X editors is the ability for text to look wrapped without actually being wrapped.

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.