Recently in Slackware Category

I didn't have high hopes for Wolvix on the $15 Laptop — a Compaq Armada 7770dmt built in 1999 — since previous attempts to load the live CD resulted in an X configuration that needed a little work.

Since then, I've had quite a bit more experience working in the xorg.conf file, and I was able to get a halfway decent X configuration going so I could test Wolvix Cub (the smaller of the two Wolvix distributions, with fewer packages than the larger Wolvix Hunter).

As I've written on many occasions, I consider Wolvix to be one of the best Slackware-based distributions available. Both the graphical configuration utility and the very flexible installation utility — also an X application — add considerable functionality to a solid Slackware 11 base.

And with Wolvix (and the rest of the Slackware-derived distros such as Zenwalk and Vector), all of the helpful Slackware console utilities are still there. Xwmconfig, netconfig, mouseconfig, even pkgtool can be used in any of these Slackware-based systems. You might not need them as much as you would in a standard Slackware installation, but they do come in handy.

Wolvix also includes slapt-get and Gslapt, the Debian-apt-like utilities that changed the way I look at package management in Slackware.

Before Wolvix, when running Slackware I dutifally downloaded updates from the Slackware FTP site, then used updatepkg to install them. One by one. By one.

One time I figured that using pkgtool for updates would enable me to save time and avoid all that typing of long filenames, or the almost-as-long procedure of copy/pasting them in the file manager for each and every package than needed updating.

I ended up with "doubles" of every updated package, since pkgtool didn't know I was doing an update and just installed the new packages without removing the old ones. So when you're talking about doing updates of Slackware packages with Slack's default tools, it's updatepkg or nothing.

All it means is that slapt-get and Gslapt, which are included in Wolvix and easily added to Slackware itself, are essential for the person whose life doesn't revolve around using the updatepkg utility.

Just the fact that Wolvix — which can operate as a live CD with a Knoppix-like save file, or in "frugal" or traditional hard-drive installs, can be brought up to date in minutes with Gslapt in much the same way that apt and Synaptic work in Debian continues to be a revelation.

Put it this way: How many longtime Slackware users don't have and use slapt-get/Gslapt? I bet not many.

Once I had Wolvix Cub running as a live CD with X properly configured on the 144MB/233MHz Compaq Armada 7770dmt, I used xwmconfig at the console to switch between the Xfce and Fluxbox window managers.

Not surprisingly, both WMs ran quite well, even with only 144MB in the live CD environment.

What astounded me were the extremly quick application-load times. In previous tests of Wolvix, it was quick but not so quick as to beat Debian Etch or Slackware 12 under Xfce and Fluxbox.

In Wolvix Cub running on live CD on the Compaq, a number of text editors, the lightweight Abiword and not-so-light Firefox all loaded relatively quickly. I need to do more tests, but Firefox seemed as responsive or more so than the Mozilla-based Seamonkey browser is in the ultra-fast Puppy Linux.

I wouldn't want to run Wolvix, even the Cub edition, as a live CD in the same way as Puppy or Damn Small Linux — especially in only 144MB of RAM, but when it comes to a traditional install, Wolvix Cub or the more application-rich Hunter would seemingly make an excellent candidate to permanently run on the Compaq.

In contrast to Debian and Slackware, Wolvix installs with just about every application and utility I like, from Abiword to Bluefish, Dillo to MtPaint, and with extremely well-organized menus in both Xfce and Fluxbox. In fact, the Fluxbox menus even include little icons next to each category of applications, something I've never seen before.

I'm "sure" I could replicate all of this goodness in standard Slackware of Debian, but the former's KDE focus and the latter's devotion to GNOME mean that it would take quite a bit of work on my part to have as good an experience in Xfce and Fluxbox as I already enjoy in Wolvix by simply loading the live CD and doing an easy installation from what I consider to be among the best installers of any Linux distribution.

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

Coming up:
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
In search of the best OS for a 9-year-old laptop: Part VIII — Final thoughts (aka "Why?")

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.

If you've been reading this blog for awhile (or spent a few hours back in the archives), you know that I run Debian, Ubuntu, Puppy, OpenBSD and Damn Small Linux a lot.

I have had a Slackware box in the past, but I didn't stick with it. Still, one of my very favorite distributions is Wolvix, which is based on Slackware 11.

While I'm generally a GNOME fan, especially on faster boxes, and not a big user of KDE, even on faster boxes, there's a lot of software in the full Slackware installation. Since I'm OK using KWord (and not OpenOffice Writer or Abiword) for the few times I need to kick out a .doc file, I don't feel the need at this very moment to install one of the GNOME add-on projects for Slackware.

If I could, I would install Dropline GNOME, but since the box I'm using is NOT i686 compatible, I can't do that. GNOME Slackbuild looks like it will work, and I might install it, but since the default Slackware installation is working so well, I'm loathe to mess up a good thing.

Here's what I like about Slackware:

In the default installation, just about everything works

Easy-to-use console utilities make managing the box relatively easy. I'm talking about:

xwmconfig
netconfig
mouseconfig
pkgtool (surprisingly helpful when adding or removing packages)

A bunch of window managers, easily selectable before starting X with the xwmconfig utility. It may not have GNOME, but a full Slackware installation does have:

KDE
XFCE
Fluxbox
Blackbox
WindowMaker
Fvwm2
Twm

On occasion, I do use Fvwm2, which I grew to like from OpenBSD, where it's the default WM. Things really speed up on slow boxes when you use Xfce, Fluxbox or any of the window managers that are not KDE.

Other things I like about Slackware:

Long-term support. The Slackware team keeps the security patches coming for many of its releases. I still see updates for Slackware 8.1, which was released in 2002. Six years is pretty impressive. It's up there with the "enterprise" releases from Red Hat and SUSE.

Slapt-get. After using Wolvix and now Slackware itself with slapt-get, I'm a total believer. It makes maintaining a Slackware box much, much easier. Get it here.

Lots of editors. Slackware may not include my favorite (Geany) but nonetheless has tons of editors built in:

Vi
Vim
Gvim
Nano
Xedit
Kwrite
Kate
Kedit
Emacs
Jed
Joe
Mousepad
(and some I probably missed)

Three major Web browsers:

Firefox
Seamonkey (which also features a mail client and HTML-generating app)
Konqueror

I've grown fond of Seamonkey, which is the main browser in Puppy Linux. I usually use Firefox, but it's nice to have Seamonkey there in case I need the Composer app to do some HTML, or to use the mail client (even though I'm pretty much accustomed to Thunderbird).

I like a lot of choices, and while I'd really like Slackware to include Abiword and maybe even OpenOffice, I can add these packages later if I decide I really need them. But I probably don't and won't.

I haven't made the leap to Slackbuilds yet, but I have had success with Robby Workman's precompiled packages.

Great projects derived from Slackware:

Wolvix
ZenWalk
Vector
Slax

I'm VERY partial to Wolvix. If I need to set up a box quickly with all the software I want/need, Wolvix Hunter is the way to do it. Wolvix has one of the best, most flexible installers I've ever seen. You can run Wolvix as a live CD, or in a "frugal" or full hard-drive installation. All are easy to do.

Default fonts in Slackware look better than default fonts in Debian

I like to gave good-looking fonts right out of the gate. Slackware is as good as any modern distribution in this regard. Debian fonts look OK on an LCD screen, horrible on a CRT. I've gotten used to them, and I no longer change them, but I still prefer nice, smooth fonts.

If you're going to run KDE, Slackware's the fastest way to do it

SimplyMepis with KDE is simply unusable on this 2002-era box. It's too slow by far. Slackware makes KDE usable on this old PC.

Granted, KDE is just as fast in Debian, so that's another good choice for the KDE fan who wants to use their favorite window manager on an old box.

A little advice: If you use KDE in Debian, save yourself a lot of trouble and use Aptitude or apt; Kpackage didn't work for me. And conversely, in Slackware use pkgtool/installpkg/upgradepkg or slapt-get/Gslapt, not Kpackage. Maybe some of you have had a better experience with Kpackage. For whatever reason, I don't like it.

Coming soon: Things I don't like about Slackware

Here are a few quick tips to make Slackware work a bit better.

Groups for your primary user account

When creating your first user account, make sure you pick the right groups.

Slackware is a bit unusual as far as Linux distributions go in that it doesn't create a user account during the installation process.

After the installation is complete, you need to log in as root with the password you chose during the install. Then create an account with adduser. I do this before starting X:

# adduser

It's pretty simple. Just fill in the information requested.

The key is to add the right groups. In order to have control over the CD-ROM, plug-in USB drives and audio, I type in the following additional groups for my first user account (i.e. my account:

audio,disk,floppy,video,plugdev,cdrom,wheel

If and when you create additional user accounts, you can either add them to these groups or not. It's up to you. I'd probably leave out a few of these for my additional users; I don't think they'd need disk or floppy, and I wouldn't want them to have wheel.

And if you forget to add your user account to a particular group, go to /etc/group as root and add your user to the appropriate group or groups.

Note: I could do this in the console with vi, but when I'm in X, I use Mousepad. Feel free to use your favorite GUI or console editor.

I open a terminal, su to root and do this:

# mousepad /etc/group

When I'm done, I save the file in Mousepad and close the window.

Want to use sudo?

I've grown accustomed to using sudo, so I add my user account to the sudoers file *— for which you MUST use visudo and NOT a direct edit on /etc/sudoers — while logged in as root (either directly or by su to root:

# visudo

the sudoers file comes up in vi. You do know enough vi to get by don't you? I can hack my way through vi well enough, and this is one of those cases where a little experience with the default text editor in Slackware and most other systems comes in very handy.

Unless you are already somewhat proficient in vi, look for an online tutorial and figure out the difference between the edit and command modes and how to move your cursor around, delete text, etc.

Back to the sudoers file. Many Unix/Linux gurus may cringe at my advice, and I'll just say that I'm concerned here with a desktop system, not a server. For a server, especially an "important" one, permissions must be finely grained and mostly restricted, with some users getting more permissions than others.

But for a desktop box, if you as the sole or primary person maintaining the box wants to use sudo, just add yourself to the sudoers file right below root:

ROOT    ALL=(ALL)    ALL
MYUSERNAME    ALL=(ALL)    ALL

Use your user name, not MYUSERNAME, of course.

Save the file in vi (in command mode, which you reach with esc, type :wq and hit Enter), and you will be able to sudo.

I guess Ubuntu got me in the habit of using sudo, even though lots of things require su to root (like using visudo), and I like to have it at my disposal.

Get your wheel mouse working right

Even though the Slackware installer asks me what kind of mouse I have — it's a wheel mouse (you know, with the scroll wheel), it is never properly configured.

I dutifully enter IMPS/2 during the installer, but the wheel never makes the screen scroll.

So I edit /etc/X11/xorg.conf to fix the problem:

# sudo mousepad /etc/X11/xorg.conf

Then I change this:

# The available mouse protocols types that you can set below are:
#    Auto BusMouse GlidePoint GlidePointPS/2 IntelliMouse IMPS/2
#    Logitech Microsoft MMHitTab MMSeries Mouseman MouseManPlusPS/2
#    MouseSystems NetMousePS/2 NetScrollPS/2 OSMouse PS/2 SysMouse
#    ThinkingMouse ThinkingMousePS/2 Xqueue
    Option "Protocol"    "PS/2"

to this:

# The available mouse protocols types that you can set below are:
#    Auto BusMouse GlidePoint GlidePointPS/2 IntelliMouse IMPS/2
#    Logitech Microsoft MMHitTab MMSeries Mouseman MouseManPlusPS/2
#    MouseSystems NetMousePS/2 NetScrollPS/2 OSMouse PS/2 SysMouse
#    ThinkingMouse ThinkingMousePS/2 Xqueue
    Option "Protocol"    "IMPS/2"

The line I changed is in bold for emphasis.

Slapt-get

I used to update my Slackware box the old-fashioned way, by bringing down the security patches from the Slackware site by FTP and then using updatepkg to install each one individually.

Now I do two things differently: First, I use a faster mirror — anything is faster than Slack's main FTP site — and second, as of yesterday, I use slapt-get.

I got slapt-get from the GNOME Slackbuild site, and after my first attempt at installing GNOME didn't go so well, the second time I installed Slackware this go-round, I commented out the GNOME Slackbuild mirror (I can always uncomment it later) and updated my Slackware packages only. (I recommend that you get slapt-get from ... the slapt-get people, as I detail below).

Once you find and install the proper slapt-get package for your version (mine is 12.0), go into /etc/slapt-get/slapt-getrc as root to select a Slackware mirror, and, if you used the GNOME Slackbuild version of slapt-get, to comment out the GNOME Slackbuild mirror until you're ready to install GNOME, if you (or I) ever are.

At this point, I'm pretty happy with Slackware the way it is, especially with slapt-get, so I'm holding off on adding GNOME.

You could always get slapt-get from its "official" site. The easiest thing to do is to find the precompiled slapt-get package for your version of Slackware, download it and use Slackware's pkgtool utility to install it.

I haven't yet installed Gslapt, the GUI for slapt-get, but I plan to do it in the future. It's also at software.jaos.com

I've said in the past that I feel a little squirelly about using slapt-get to install NEW packages, the only reason being that I don't know enough about it, but for updating official Slackware packages, I feel really, really, really good about it.

The last time I used Slackware, I fell behind in my security updates, mostly because you need to use upgradepkg and can't make it easier by using pkgtool directly. (Believe me, there are a lot of EASY Slackware console utilities that, in some ways, make Slack a cakewalk to configure).

Once I used Wolvix, which is based on Slackware 11, and which includes slapt-get and Gslapt, I saw how easy it was to update a Slackware box. Slapt-get levels the playing field vis a vis Debian quite a bit.

I didn't really need Geany, but I wanted to try Slackbuilds.

The instructions are too brief. I only say this because I can't make it work.

I extract the Slackbuild script, download the source to the proper directory, run the script as root and then get an error message.

The output says: "tar: This does not look like a tar archive," or "bzip2: (stdin) is not a bzip2 file."

I'm sure I'm missing something, but what?

Not one to wait, I went to LinuxPackages.net and got Geany for Slackware 12.0. I used pkgtool to install it. Worked perfectly.

Still, I'd like to figure out Slackbuilds. I'd love to know what I'm doing wrong.

I sent Slackware expert Willy Sudiarto Raharjo an e-mail asking for help. I've exchanged e-mail with Robby Workman before, and he's responsible for many Slackbuilds scripts, but I figured I'd ask Willy first and see what he comes up with.

Now that I have a working Slackware installation on my test box, which has seen Slackware before, everything is working so well that I'm reluctant to install one of the GNOME add-on projects just yet.

A lot of this is due to the fact that while Slackware is KDE-centric, it also installs with the XFCE, Fluxbox and FVWM window managers, among others, and I'm content to use XFCE at the moment, along with Firefox for Web browsing, KWord if I need it, and Mousepad for text editing.

I haven't even added Abiword, which I've done in the past in Slackware.

What I did add was slapt-get. The apt-like package manager for Slackware seemed like a very good idea due to the relatively large number of updates since Slackware 12 was first released. It worked great.

The box upgraded overnight, and everything came up fine in the morning.

I would like to be running Slackware 12.1, but as I wrote previously, none of the install kernels would boot on this VIA C3 Samuel-based machine. I got a message about not having enough memory, even though I have 256MB — more than enough.

I'd like to try an upgrade from 12.0 to 12.1, but it looks as hard or harder than the OpenBSD 4.2 to 4.3 upgrade I did recently, except with instructions that are less detailed.

But as always, Slackware runs as fast as anything, and everything pretty much works.

After participating in a huge thread on LXer about the pros, cons, highs, lows of Slackware, ye olde Linux distribution with rabid fans and equally rabid detractors, I decided to give Slack another run myself.

This very box — a VIA C3 Samuel-based converted thin client with 256 MB of RAM — installed and ran Slackware 12.0 without complaint several months ago.

But it won't even load the installer of Slackware 12.1.

With both the hugesmp.s and huge.s kernels, I get the same error message:

Not enough memory to load specified kernel.

What gives? If 256MB isn't enough to install and run Slackware, then we've got a big, big problem.

I cranked a Slackware 12.0 install disc into the box and the huge.s kernel booted just fine (hugesmp.s wouldn't boot on this CPU).

I'll do a 12.0 installation and try to upgrade to 12.1.

But why won't 12.1 even boot the first install disc?

Any ideas?

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

What version of Linux has been at the top of the Distrowatch rankings for months now that I've never tried until today? PCLinuxOS.

Everybody I know who has runs PCLinuxOS has good things to say about it. Scott Ruecker of LXer and the Los Angeles Daily News' own City Hall reporter Rick Orlov are among those who have used and liked it.

I couldn't boot the CD on my test machine (VIA C3-based converted thin client), but on the $0 Laptop (Gateway Solo 1450) it's booting just fine.

To start with the live CD, I selected the "copy2ram" option because I have 1 GB to play with on this machine. It takes quite a while to copy the system files to RAM, but once that's done, the system should run very fast.

The 2007 version of PCLinuxOS has received continual updates and is a sort of rolling release -- the coders behind it don't create new ISO images on a continual basis like we get from Ubuntu, for instance. Once you install PCLinuxOS, it's easy to bring it up to day. Actually, I prefer it this way. I'd rather do a bunch of updates than continually burn new CDs.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here he is on "Chaos vs. Order":

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

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

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

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

Followed by "Right vs. Wrong":

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

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

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

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

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

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

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

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

disable_ipv6 = true

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

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

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

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

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

If you gripe about a console-based installer, even those as relatively "easy" as Debian, the alternative disc for Ubuntu or even Slackware, then doing a BSD installation isn't for you. (Actually, it is, because DesktopBSD and PC-BSD, both of which I've also installed, make it much, much easier.)

That's because everything in BSD -- OpenBSD included -- is different from Linux. Everything from network devices to floppy drives has different names than in Linux -- and the names aren't even consistent across BSD flavors. For instance, my Ethernet interface on this computer, eth0 in Linux, is rl0 in OpenBSD, and I've seen it configured as fxp0 in another BSD install.

But all three of the major BSD projects have outstanding documentation, from the 900-and-something page FreeBSD Handbook (yes, it's also free for the downloading) to the extensive FAQ and Man pages on OpenBSD's Web site that expertly guided me through the installation and configuration of this OpenBSD system. The OpenBSD FAQ is so good, I wish I had the whole thing in PDF form, just like the FreeBSD Handbook, as an easily printable reference. But having the information online is good enough. I've already gotten X configured and added about 10 applications.

Another good thing about OpenBSD: package management. The pkg_add command takes care of all dependencies. It appears that you have to type in the exact name of the package, with all the numbers and punctuation before the .tgz in the file, but the list of packages is right there on the OpenBSD site (as it is on the many FTP mirrors).

And you can chose to install precompiled packages for your architecture (which I'm doing) or compile your own with ports. I like the flexibility -- and in the OpenBSD documentation, it clearly says that you won't gain any speed advantage by compiling your own packages. And so far, things have worked pretty damn well.

However, I haven't yet figured out how to get my new applications into the Fvwm menu. I do appreciate how most Linux distributions add those menu entries as part of their package management, but if I do figure it out, I can live with making my own menu entries. And while Fvwm is growing on me, I probably will add Fluxbox at some point. I don't yet have a boot manager. Again, just like Slackware, the OpenBSD system boots to a shell, at which point I can continue there or use startx to start the GUI.

OpenBSD installs locked down. I'm not sure what the ramifications are for security, but one of the things that happens very early on in the OpenBSD installation is the generation of PGP keys from your root password. Another thing OpenBSD is known for is installing with everything as secure as possible. (Believe it or not, it reminds me of Slackware, the Linux distro in which I had to turn more thing on than in any other LInux installation I've done before or since.)

I did choose to implement SSH, even though I won't be using it for the time being. You start out in OpenBSD with a root account (just like in Slackware) and then you create a user account.

When I created my user account, I found that I could only add packages when logged on as root. I coudn't su to root or use sudo. I was going to add my user account to the sudoers list, but a check of the the OpenBSD documentation told me that adding my user account to the wheel group would, in the default configuration of the system, give me sudo and su privileges. It worked.

So far, as I said above, I'm very impressed with the console-based package management in OpenBSD, as well as the number of packages available from the repositories. And again, while ports are a great thing, I really like the option of using precompiled packages to get things working that much more quickly.

Coming next: Why am I doing this?

I've been toying with removing Debian Etch from the $15 Laptop -- the 1999 Compaq Armada 7770dmt with a 233 MHz Pentium II MMX processor and 64 MB of RAM. When most computer users -- even those partial to Linux -- talk about "old" hardware, they mean either things in the 1 GHz range, even 3 GHz single-core CPU computers with 512 MB of RAM.

For me, a 1.2 GHz Celeron laptop with 1 GB of RAM is good enough to run just about any Linux distribution out there. And my main Windows machine at the office -- a 3 GHz Pentium 4 with 512 MB of RAM is way more than adequate for desktop use.

As far as the 233 MHz Compaq laptop goes, I'm probably going to bump up the RAM from the current 64 MB to the maximum of 144 MB, but that's pretty much besides the point.

When I first got this laptop (yep, it cost me $15, though I had to shell out $10 for the CD-ROM drive on eBay) I ran into a lot of luck, because it wasonly supposed to have 32 MB of RAM but had double that. It wasn't supposed to have a hard drive, but not only was the hard-drive casing intact, but there was a 3 GB drive inside it. It was loaded with Windows 98 but wouldn't boot. Once I had the CD drive (the incoluded floppy drive doesn't work, and I could get another one for $10, but I really don't need it), I was able to run Puppy Linux and Damn Small Linux from live CDs.

At first I loaded Windows 2000 just to see how it ran. Win 2K ran alright, but I'm not in this to run Windows. I had pretty good luck with both Puppy and DSL, but Damn Small Linux is really the more suited of the two for a computer with 64 MB of RAM.

Anyhow, I eventually wanted to try Debian Etch on the Compaq. I've done at least four installs of Debian on this computer, but my first began was the "standard" install, which means no X. After that, I added X and Fluxbox, plus all the apps I though I'd need. ROX-filer, AbiWord, Leafpad, Dillo, Lynx, Elinks, Sylpheed (which didn't work), MtPaint for image editing, and eventually even Iceweasel (aka Debian's renamed Firefox).

I was able to actually get work done on the laptop, which can connect to the outside world only through the Orinoco WaveLAN Silver 802.11b wireless PCMCIA card I had previously bought for This Old Mac (aka my 1996 Powerbook 1400cs). And since the PCMCIA slot in the much-better $0 Laptop (Gateway Solo 1450) is inoperable ("busted" is the technical term), the wireless card has remained in the Compaq, which has no Ethernet port or USB capability (though it does have a serial port, parallel printer port, built-in telephone modem and a power supply fully enclosed in the case -- yes, a 120-volt power cord plugs right into the back). They made these Compaq's well -- this one still runs great.

Anyhow, my "roll-your-own-X" Debian install did OK. The display was a bit slow in Abiword, but I had everything running fairly well. Just not well enough.

Since then, I spent quite a bit of time testing DSL 4.0 on the Compaq. Damn Small Linux runs great on this thing, that much I can tell you. And I even ran Puppy 2.13 for a couple of days this week.

But I always had Debian on the hard drive. Just not the original Debian. I had wiped the drive and experimented with Debian Etch and the Xfce desktop install (desktop=xfce as a boot parameter in the installer) as well as Slackware 12.0 without KDE (Xfce and Fluxbox).

Well, Slackware without KDE means you don't even get an office suite, and I still had barely any disk space on the 3 GB drive. (I know, I just need to get a bigger drive ... I know.)

So I went back to Debian Etch, again the Xfce desktop. Surprisingly, this install includes the full OpenOffice suite and I still have about a full GB of space left on the hard drive. I have a separate /home partition with 800 MB in it, and a root partition with 2 GB, with about 150 MB left. The rest of the space is swap -- about 120 MB.

And while on the Gateway laptop (1.2 GHz Celeron CPU) I cannot detect a performance difference between the Xfce and Fluxbox window managers, on this 233 MHz CPU, there's quite a difference. I was about to give up on Etch altogether when I decided to again install AbiWord (I tried Ted ... again ... but the RTF word processor still doesn't work, at least in any Etch install I've had), as well as Fluxbox.

Fluxbox makes it a lot snappier. I still have all the Xfce apps, including Thunar, Mousepad and the great Xfmedia.

In fact, I finally got sound working tonight. I don't think it'll survive a reoot, so I'll have to run this line on startup, but for today it did work:

# modprobe sb io=0x220 irq=5 dma=1 mpu_io=0x330

I can't run alsamixer, but I can play an MP3 in Xfmedia, and it sounds great even on the built-in speakers on this 9-year-old laptop.

I didn't think I could get sound working in Debian Etch, but since I did, Etch will definitely live to fight another day on this laptop.

Before I close out this entry, let men emphasize that the Xfce install of Debian is a quirky distro, to be sure. It's nowhere near as complete as Ubuntu's Xfce variant, Xubuntu.

Etch in its Xfce incarnation includes the full OpenOffice suite, but not Abiword or Gnumeric (which would be good substitutes). There's no Synaptic or Update Manager, so I've been doing what Debian aficionados always tell me to do: use Aptitude. I was running aptitude in a terminal for awhile, but it's much easier to just run it at the command line:

# aptitude update
# aptitude upgrade
# aptitude install abiword

Yep, just like apt-get and apt-get install, but Aptitude is supposed to do an even better job with dependencies and it keeps track of your changes to the system, should there be any problem.

I also need to do a dist-upgrade -- without moving away from Debian Etch -- to get a couple of packages that have been held back, including a new kernel image, but I'm holding off until I repartition the drive somewhat to put more space in the root partition (taking it away from /home):

# aptitude dist-upgrade

Final note: The fact that Debian Etch -- a modern, up-to-date Linux distribution -- can run so well in 233 MHz of CPU and 64 MB of RAM is something truly to behold. Again, my thanks to everybody at the Debian Project, past and present, for all they've done for the rest of us.

Post-final note: If Debian continues to perform so well, I just might blog the SCALE 6x convention with this 1999-vintage laptop.

Positively the last note: Iin case I only mentioned it once above, Fluxbox is really flying on this setup ... but the ROX-filer is only a bit faster than Thunar. And since the 1999 Compaq with Debian Etch and Movable Type 4.0 are playing nicely, I think this laptop is definitely going to SCALE 6x ... unless I succeed in getting wireless working over USB on the $0 Laptop (more to come on that).

Sorry, just one more note: Look for a SCALE 6x feature on Click in the days ahead.

I've complained numerous times in the past about the Ted word processor being broken in Debian. On my many Debian installs, I could neither create a new file in Ted nor open an old one.

But on my Gateway Solo 1450 (the $0 Laptop), after doing my big Debian Lenny update yesterday -- which fixed an annoying Nautilus bug by updating to Nautilus 2.20 -- I decided to give Ted another try.

It works.

I can create new files in Ted and open old ones. I tried Ted again on my Compaq Armada 7700dmt (the $15 Laptop), now a Debian Etch machine (with Xfce and, since last night, Fluxbox) that could really benefit from Ted working. No go.

I figured that it was maybe a Lenny-only thing -- some other dependent package got updated and magically made Ted work. Here's Ted's bug status in Debian. I remember trying this "transcoded fonts" solution and having it not work.

So this morning, on my desktop Debian Lenny install, I tried Ted again, and it didn't work. I even installed the transcoded fonts. Nothing.

Yes, I have three Debian installs (two Lenny, one Etch), and Ted works on one (Lenny) of them. That's better than Ted working on none ... but.

I'm wondering if I should even be running Debian on this 233 MHz Pentium II MMX, 64 MB RAM, 3 GB hard-drive laptop. The Compaq performs OK with Puppy Linux and a bit better with Damn Small Linux. And while on my faster, 1.2 GHz laptop I detect almost no difference in response time between Xfce and Fluxbox, on the 233 MHz box, Fluxbox is much snappier, so I take back my previous assertion that Fluxbox doesn't give you much of a performance edge. When you're running really old hardware, Fluxbox can really help.

The problem: I want to have a "full" command-line system in addition to X, and that's harder to do in Puppy or DSL. And I like the fact that Debian and Slackware stay on top of security issues and frequently issue patched packages. And Debian (or Slackware, for that matter) makes it relatively easy to install any console app I want. However, I put a lot of stock in doing as little modification as possible; in my experience, things can get mucked up pretty quickly. And while both Puppy and DSL offer command-line features, neither is a full, modern, updated Debian or Slackware.

And just to provide a little background, Debian, Slackware, Puppy and Damn Small installed just fine on this old Compaq. I can't say the same for Xubuntu, which I did try.

And while I'm mentioning Xubuntu and Debian with Xfce in the same post, let me just say that of the two, Xubuntu is way more ready for prime time. Debian's default Xfce install is missing too many things; I stick by my assertion that Debian is great with the default GNOME, less so in the Xfce and KDE installs that you can do with the Xfce and KDE Debian disks (or desktop= boot parameter in the netinstaller).

Back to the Compaq. Both Puppy and DSL are way better at recognizing and configuring the hardware of this old Compaq laptop. At this point, I'm considering running both Puppy and DSL as live CDs with no OS on the puny hard drive, which would only be used for swap and storage (I could even replace the spinning hard drive with a Compact Flash chip or disk-on-module).

I hate to give up running Debian or Slackware on this laptop -- I've tried both. But when I try to build up the apps on my own, I can never do as well as Puppy and Damn Small Linux -- both of which I've used extensively over the past year and which I value very highly. The people behind Puppy and DSL really know what they're doing.

And while I'm grateful to get Ted running on my Lenny laptop (where I don't really need it), can't Debian just make Ted work everywhere, all the time? Like I've said before, there's probably a good reason that Ubuntu doesn't have Ted in its repository, and I'd say the package not working is a pretty good reason.

I haven't even complained about Ted not showing up where it should in the menus and my not being able to figure out how to put Ted where I want it in GNOME (yes, I used alacarte (here's the Debian bug situation), and no, it didn't let me add menu items (another Lenny bug, perhaps?) -- it almost makes me want to run straight toward Xfce and Fluxbox ... or Ubuntu).

Moral: Debian giveth and taketh away, but it remains damn good.