Recently in OpenBSD Category

As soon as I'm able to begin posting them, my eight-part series on finding the best operating system for my circa-1999 Compaq Armada 7770dmt will begin unfolding, one part a day, on Click.

I've been working on this series for about a month, working with everything from Damn Small Linux and Puppy Linux to OpenBSD and Wolvix Cub, with a lot of thoughts about past use of Slackware, Debian, Ubuntu and more.

So starting — again, as soon as I can get the entries lined up — look for a long meditation on the best way to make old hardware work in the 21st century.

I hooked up my Starbucks card with AT&T today to draw on the free Wi-Fi now available at the coffee giant, and was pleasantly surprised to have good broadband speed in Puppy Linux 2.13 on the $15 Laptop (Compaq Armada 7770dmt).

I was even able to sign on using the Dillo browser. I started Seamonkey after that, but just being able to log in with Dillo was a surprise.

Even more of a surprise, however, was that the AT&T Wi-Fi didn't work in OpenBSD 4.2, which I have installed as the primary OS on the laptop.

Now I know that wireless works fine in OpenBSD, because I use it at home and at the Los Angeles Public Library. When OpenBSD booted, I got an IP, and I could ping that IP. I should've written down the location's IP and tried to ping that. Otherwise, I couldn't ping anything, and as a result could not get any services to work. That means I couldn't get data into or out of the laptop.

Why does AT&T Wi-Fi work in Linux but not OpenBSD? That's a good question

What I'm saying, basically is that if you're running anywhere near 64MB of RAM and you, say, want to run Firefox, you need more memory.

The $15 Laptop -- a Compaq Armada 7770dmt with 233 MHz Pentium II MMX CPU -- ran a Linux console with no problem and even did an X session, provided no "heavy" apps like Firefox were used.

But how can you get along with just Dillo as a Web browser?

It's not easy if you want to do any kind of blogging, which a) uses the more-memory-intense Firefox and b) demands much more out of Firefox and the whole system as well.

Well, I can safely say that a 233 MHz CPU and 144MB of RAM are enough to run Puppy Linux (currently version 2.13, for which I continue to have a soft spot), Damn Small Linux 4.3 and even OpenBSD 4.2.

I'm going to reboot into OpenBSD right now to see just how well the Compaq is doing with it.

(I'm now back with OpenBSD 4.2)

Things appear to work pretty well with OpenBSD as well. Though certainly more secure than almost every other operating system out there (though I miss Debian and now also Ubuntu's ability to encrypt an entire drive with LVM) and as stable as anything out there, OpenBSD is in no way faster than the fastest Linux distributions.

And speed is a bit of a problem on hardware this old.

I'd have to try Debian again. Puppy and DSL are quite a bit quicker when it comes to screen refresh time in Firefox (and generally in X). I don't remember Debian Etch as being all that sprightly in comparison.

(Changing to DSL 4.3)

There's no doubt that DSL runs the graphics in X faster than OpenBSD. The screen does a much better job of keeping up with my keystrokes in Movable Type, and if the main purpose of this laptop is to crank out blog entries, that is an important consideration.

Of course, before I pull OpenBSD off of this drive, I'll have to make sure I have the xorg.conf saved, as well as a number of other configuration files as well as the output of pkg_info so I can remember all the software I have in this install.

I should probably just get a few swappable hard drives for the Compaq. Maybe even something bigger than 3GB. Just a thought.

Other problems with using DSL as the sole distro: no Flash (but OpenBSD doesn't have it either).

... (two weeks later)

I've been running the $15 Laptop a bit more. Having a good wireless connection helps immensely. I've been most happy with Puppy 2.13 thus far, since it has Seamonkey — a very acceptable Mozilla-based browser — and all the graphics work as they should.

I still have OpenBSD 4.2 on the hard drive, and as I say above, I'm reluctant to remove it, even though I can and will save the various configuration files in case I want to do a reinstall.

I'd like to try Wolvix again, just to see if the additional memory makes any difference in loading it. I could — and probably should — try Debian again. I don't know if it'll be as fast as Puppy or DSL, but it is worth trying.

What I'll probably end up with: I might leave OpenBSD on the laptop for awhile, but I can see myself ending up with a hard drive or Compact Flash chip with IDE converter completely devoted to storage and either running Puppy Linux off of the Live CD or as a frugal install on the hard drive or CF card.

It's nice — really nice — to see via Distrowatch that development is continuing on low-spec favorite DeLi Linux. Here's the release announcement.

I've been able to install DeLi on my VIA C3 Samuel converted thin client, but not without a few tricks that I picked up from the forums (here and here). And I also recently did an entry on some good DeLi-related blog entries from others.

I never was able to get my static IP configured in DeLi, but I think I could do it now.

According to the DeLi site, you need 32 MB of RAM to run the GUI version. The Web browser is Dillo, I believe, and that runs great in 64 MB and looks like it can run about as well in 32 MB.

Probably the biggest change is a shift from GTK+1 to GTK+2, which accounts for the memory requirements rising for this release of DeLi.

When you're trying to resurrect and make an old computer useful, DeLI is a great distro to have in your arsenal, along with Puppy, DSL and even Debian (the Standard install with X and a lightweight window manager and your favorite apps added manually).

I just upgraded the $15 Laptop from 64 MB to 144 MB of RAM, and before the upgrade, OpenBSD, Puppy and Debian ran well on it with X ... unless you try to run a "big" application like Firefox. That's where Damn Small Linux leaped ahead of the pack for that low amount of memory.

Now with 144 MB, I hope that I will have more choices as to what will run on that Compaq Armada 7770dmt, but if you do have a box stuck with 32 MB (I used to run Windows 98 in that amount of RAM, and let me tell you, it was pure hell), DeLi is a great distro to try out.

I wasn't able to boot Damn Small Linux 4.4 RC1 on the machine I really need it to run on — the $15 Laptop (aka Compaq Armada 7770dmt) — so I booted it on my VIA C3 Samuel test box, the machine that ran my two Puppy Linux torture tests.

I've already written about how the inclusion of Firefox 2 (renamed Bon Echo) in DSL 4.3 has breathed new life into the live-CD distribution as far as I'm concerned.

Two things I like:

Unlike in 4.3, Fluxbox seems to work. I can easily get a menu in the Fluxbox window manager, something I couldn't do running DSL 4.3 on the Compaq.

The DFM file manager is less confusing. It doesn't come up with a right-click, as it did in previous versions, but it is there when you use the folders on the desktop. This way, it should be less confusing to new users. The EmelFm file manager is still there, and since I've gotten used to it, I'm glad it has stuck in DSL.

One thing that was a bit surprising was the length of time it took for Firefox/Bon Echo to start for the first time, even when all of DSL was loaded in RAM. I expected it to be a little quicker, although the speed is more than adequate when reloading it.

I love running low-spec live-CD distros like Puppy and DSL in what I call "torture test" mode -- booting it, running it without any hard drives and leaving to to run for days or weeks at a time. Since I already had DSL 4.4 RC1 loaded entirely into RAM (done by entering dsl toram as a boot code), I decided to disconnect the hard drive that was spinning when I first booted.

I pulled the drive's power plug, then the IDE cable. The drive went silent, and DSL 4.4 continued to run.

Now the box was super quiet.

I had already set a static IP, which was extremely easy to do with DSL's built-in utility.

X was configured perfectly at 1024 x 768 with no intervention on my part.

Nothing new on that count, thankfully. On this hardware at least, DSL really does "just work," as they (and I) say.

My VIA-based converted thin client has, shall we say, "problems" with audio. Many audio applications skip their way through an mp3. Luckily XMMS, the default audio player in DSL, works very well with the shoddy sound chip on this ECS motherboard. I downloaded a few mp3 files, and they played with no problem whatsoever.

I tried to add the Flash plugin by going to a page with Flash on it and clicking the "install Missing Plugins" button that usually comes up in Firefox. Everything seemed to go OK, but Flash didn't work.

While I don't consider a lack of ability to run Flash to be a deal-breaker in a distro, it can be ... inconvenient. I realize all the problems with Flash in the open-source community (principally that it's not open-source), and while I agree in principal, in actuality we all need Flash at various times, and I consider it a necessary evil. And I wish DSL would consider adding it, even as a MyDSL extension.

Speaking of MyDSL, I opened it up to confirm that the Flash plugin was unavailable, and while that turned out to be the case (as far as I can tell), I'm quite impressed with MyDSL itself.

In the process of playing around with MyDSL, I killed the box. Disconnecting the hard drive during the session was what (eventually) did it.

I'll just have to run DSLnthe "normal" way, with the hard drive running. I can seem to boot Puppy from CD without a hard drive connected, but not DSL. Once again, this has no bearing on the actual running of DSL. It's just a point of comparison with Puppy Linux that I always seem to make in the course of these reviews.

But where I really need DSL 4.4 to run is the $15 Laptop, the Compaq Armada 7770dmt. I'm just about to boost the memory from 64 MB to 144 MB, and while I'm not sure whether or not the change will make Debian, OpenBSD or Puppy usable with X (really with Firefox some small X apps work well in all of the distros above), DSL is already quite usable -- with Firefox -- in a measly 64 MB, and it'll only get better with 144 MB.

So even if I have to stick with DSL 4.2, one distro -- and one distro alone -- is at the top of the heap when it comes to running X in low specs. And that distro is, and remains, Damn Small Linux.

I've blogged a bit recently on how hard it is to install Movable Type and have it actually work on your own server. After getting and configuring Apache and MySQL (or PostgreSQL or SQlite), making sure you get the static files in the right place and the CGI/Perl files in the other right place, then making sure everything has the proper permissions ... I found it to be way beyond my capabilities.

And the instructions are rudimentary at best. I think the people at Six Apart pretty much want you to hire time to configure your Movable Type setup. In a way, I don't blame them, but they've also got to think about WordPress breathing down their necks.

To be fair, I haven't yet tried to install WordPress, but I recently found out something very interesting:

There are WordPress packages available in many of the major Linux and BSD distributions, including Debian, Ubuntu and even OpenBSD.

Luckily, the same thing is now happening for Movable Type.

So if you're using the Debian GNU/Linux distribution -- and I strongly suggest you do -- you can now install Movable Type as a Debian package.

Read about it at the Movable Type site, and find out more about the package at the Debian site.

And for those using -- or about to use -- Debian, since the Movable Type package is new, it's not in the Stable distribution, which is named Etch. Instead, you need to install or upgrade to the Testing distribution of Debian, named Lenny. I'm already using Lenny in one of my desktop installs, where it happens to work better than Etch, but my Debian server still runs with Etch, and I'm loathe to change that.

I'm not sure how either of these packages -- WordPress or Movable Type -- handles dependencies as far as Apache and MySQL are concerned (e.g. whether or not you have to install the Web server and database software before you install the blog software), but I plan to find out very soon.

After two unsuccessful attempts at rolling out my own MT installations, I'm cautiously guarded about these packages actually working without a lot of post-installation tweaking (and I hope the man pages provide considerable insight).

I said I was wary, the instructions were detailed but not complete, the process was far from instant, and I killed X for a few minutes when I tried to fill in the blanks, but I eventually was able to upgrade my VIA box's existing OpenBSD 4.2 installation to 4.3, packages and all.

The hardest part: dealing with /etc, for which the old settings must be merged with the new files, and not hosing X but managing to replace xbase42.tgz with xbase43.tgz.

The easiest part: Upgrading each and every binary package I added to my original installation with a single line of code.

Like I said, the instructions aren't of the "for dummies" variety. There are ways to make this understandable and doable for mere mortals. I have notes.

Would it have been easier to preserve my /home partition and totally reinstall from scratch? Maybe. Maybe not. I had a whole bunch of applications installed, and I didn't want to redo all of that. I saved all my configuration files just in case, but I didn't necessarily want to hack into xorg.conf again if I didn't have to.

Long story short, I now have a working OpenBSD 4.3 box. Aside from a few points in the upgrade instructions that are less than clear or totally unclear, I was able to follow along and do it "right." Like I said, I have notes and will be either writing a supplemental on how to do the upgrade -- something you can keep with you as you go through the official upgrade FAQ, or I'll do a full OpenBSD upgrade recipe of my own.

It's not like doing an apt-get dist-upgrade in Debian, that's for sure.

Next on the block: Doing the upgrade on the Compaq Armada 7770dmt laptop.

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'm starting with the sensorsd.conf and sensorsd man pages. And this page from Calomel.org has some tips on what /etc/sensorsd.conf does, how to start the sensorsd daemon.

I'm not holding my breath, but if I could run OpenBSD (or FreeBSD or NetBSD) on my Gateway Solo 1450 laptop with the fan properly managed, I'd love to be dual-booting it with Debian.

Debian Lenny note: While many bugs seemingly got fixed in the Epiphany Web browser in Lenny, one new bug unfortunately has crept in.

Whenever you start the Epiphany browser, the check box to "work offline" is automatically checked. And the result is that you get versions of Web pages that you looked at the last time you were working "online." It's like a freaky time machine. Right now, you have to go under the file menu and uncheck the "work offiline" box to get Epiphany to pull up real live Web pages. I did see a bug report for this, sort of, but it doesn't seem current, and it seems to say that the problem is with the network manager (gconf??) rather than with Epiphany itself. This Ubuntu report is exactly what is happening. Whatever's causing the problem, I hope it gets resolved soon; I'm partial to Epiphany when using GNOME, but I've switched over to Iceweasel (aka Firefox) just to be rid of this bug.

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.

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 just read that Debian is removing Flash from its repository:

Flashplugin-nonfree has been removed (see below), as this is closed source and we don't get security support for it. For security reasons, we recommend to immediately remove any version of flashplugin-nonfree and any remaining files of the Adobe Flash Player. Tested updates will be made available via backports.org.

Since adding Flash from the repository never seemed to work for me in Debian -- I always have to get it through the browser dialogs -- it's kind of a moot point. I haven't yet investigated Gnash -- the free, open-source Flash clone -- but I'd sure like to do so. Flash is a resource hog, and I wish it would go away, but that's probably not going to happen. I just hope that Gnash or some other open-source alternative can replace it -- and quickly.

Back to Debian: The Flash news is part of Debian's main announcement that there's a new netinstall image for Etch:

The Debian project is pleased to announce the third update of its stable distribution Debian GNU/Linux 4.0 (codename etch). This update mainly adds corrections for security problems to the stable release, along with a few adjustment to serious problems.

Please note that this update does not constitute a new version of Debian GNU/Linux 4.0 but only updates some of the packages included. There is no need to throw away 4.0 CDs or DVDs but only to update against ftp.debian.org after an installation, in order to incorporate those late changes.

Those who frequently install updates from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.

So you don't really need it, unless you don't already have it, in which case you need it.

I've been running Debian Lenny (testing) on the $0 Laptop (Gateway Solo 1450), and it's making significant progress -- it works way better than it did a month ago. I'm dual-booting with PCLinuxOS 2007 at the moment.

The older, weaker $15 Laptop (Compaq Armada 7770dmt) is still running Debian Etch (Stable), with the Xfce build's software, but now set to use Fluxbox as the window manager.

I can't decide whether or not to install Etch again on the Gateway just to see if any other bugs were fixed. For me, Lenny has resolved most of my issues, and I'll be happy to stick with it as it goes Stable.

And while I'm considering building an experimental server with OpenBSD, I might make it easy on myself and use Debian Etch instead.

My advice: If you're worried that either Debian or Slackware is too hard to figure out, don't be so worried. The not-so-hidden secret out there is that Ubuntu isn't that much easier. If you've got Ubuntu figured out even a little, you can handle Debian (and it's a bit faster, with more in the default install, besides). Slackware, you can probably figure out with a little hand-holding. Adding software and doing updates isn't as easy as in Debian/Ubuntu, but it's still fairly easy -- and you'll definitely learn something; actually quite a few somethings.

The flexibility of Debian is legendary. With one little netinstall CD, you can roll out a GNOME, KDE or Xfce desktop, a minimal console-only system (from which you can build what you want), plus any number of server configurations.

Slackware is also very flexible, but in a different way. It can't compete with Debian's 20,000+ packages, but there's a lot in the full Slack install. A full KDE desktop (with Xfce and Fluxbox, too). And if you want to spend a lot of time on the install process, you can pick and choose each individual package before committing to the final install.

Both put a lot of power in the hands of the user. And you do want power, don't you?

Flash update: Sander Marechal provided this very illuminating bug report (in this LXer thread) about the discussion in the Debian community over whether or not (and if so, then how) to include Flash in Debian.

At this point, it looks like the flashplugin-nonfree will be available to Debian users via Backports.org.

In the bug report, Ramond Wan says:

As a Debian user, but someone who isn't related to how Debian is run...I think you are correct and more importantly, what makes you think that Debian isn't political? Every time I visit a web site with Iceweasel and the server pops up an annoying message saying that Firefox is supported but not my browser, I sense only a part of the overall politics in Debian. In this case, I blame the server developers, too, for having such a message (how about if I used lynx?).

Anyway, there is a lot of politics within Debian and it stems from them
drawing a line that forms the basis of what Debian is (i.e., "free").
If they start making exceptions, then that line has no meaning.
Backports is a patch that helps make it easy for many of us. We give up
some things to be able to use Debian (rather than one of the many other
Linux distributions).

Carlo Wood says:

I'm sorry, but it doesn't seem to make much sense to let the debian users of stable and testing suffer like this. It's not like Adobe is going to be like "Oh My God!" and change their ways. They clearly don't give a damn.

I can't help but sense a political reason not to
support flash, just because it's "non-free", the
maintainers of debian WANT it to be broken, almost,
and certainly don't look hard for a way to give
their users an easy way to use flash. Just as long
as the result is that the users blame Adobe, and
not debian, it's ok - regardless of how much the
users suffer because of it.

And Timo Jyrinki says:

YouTube already works with Gnash the free Flash player, so that in particular should not be a problem. Many other sites are not yet working, but Gnash could be possibly defined as working "well enough" in time for the Lenny. At least I'm using it exclusively anyway, and I'm just using the 0.8.1 version, which lacks development for the last four months. But I don't find it problematic to skip sites that don't work with Gnash, so I'm not an average user.

In summary, Gnash works rather well for Flash 7 sites, but quite a large
portion of sites has moved to Flash 8 and 9 which are only a
work-in-progress with regards to Gnash, and most do not work properly.
Time will tell how fast Gnash will progress.

And here's what I say: I'm ambivalent about Flash. Some sites -- yes, even some that I personally help maintain -- use way too much Flash. You can barely navigate a site when you have two to four Flash apps running on a given page. The people who are all hot to use this much Flash obviously don't spend much, if any time using their own sites.

As far as video goes, Flash just seems easier than the alternatives. I know that QuickTime, for instance, runs like an old, three-legged dog on non-Apple hardware. It's just a lousy app.

So as far as video goes, I'd love to see some alternatives to Flash, especially open-source alternatives.

But as I say above, it may be a security issue, but on Debian I've always just gotten the Flash plugin straight from Mozilla through the browser itself.

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.