January 2009 Archives

This is a nice tip on how to use xrandr in a terminal window to change your X resolution in Unix/Linux:

http://howto.wikia.com/wiki/Howto_change_screen_resolution_while_in_X-Windows

To see avalable options set in /etc/X11/xorg.conf
Execute: xrandr --verbose
output:
SZ: Pixels Physical Refresh
*0 1024 x 768 ( 347mm x 260mm ) *85
1 800 x 600 ( 347mm x 260mm ) 85
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none
Setting size to 0, rotation to normal
Setting reflection on neither axis
To change the display resolution to 800x600
Execute: xrandr -s 800x600
An alternative way to change settings it to use the number presented by xrandr --verbose
Example: xrandr -s 0
For: *0 1024 x 768 ( 347mm x 260mm ) *85
other common display resolutions are
640x480
800x600
1024×768
1280×1024
1600×1200

ubuntu xorg for projector:

https://lists.ubuntu.com/archives/ubuntu-users/2006-August/089561.html

Solaris xorg for projector + multiple monitors:

http://solaris-x86.org/download/xorg/xorg.conf.toshiba.m2.projector.1280x1024

for openbsd, start here:

http://openbsd.org/faq/faq11.html#amd64i386

I haven't written a long, rambling editorial on why I do what I do in quite some time. Guess I lost the juice for it. But I just got rejuiced (perhaps it's my upcoming speaking engagement, for which I'll sound less rambling, I hope), so here's a lovely stream of geeky consciousness on why software freedom and/of choice is a great thing:

Much of what I write about here concerns how I aim to do everything I can to match up the best hardware and software to get a given job or jobs done.

That's why I don't advocate GNU/Linux or OpenBSD for everything, even though I spend most of my time using them on my systems.

There are times when Mac OS X is the best system for the job. That's especially true for me when it comes to editing video. I'm sure there are apps on Windows that are as good as Final Cut, but I sure haven't heard about them. And I'm pretty confident in saying that there's not much out their in free, open-source software world to match it.

There are also probably times when Windows is a reasonable system to use. I'd love to say there was an image editor for Mac or Unix/Linux that was as good as IrfanView at what it does. I haven't found that, either.

I'm not talking about servers at all here, just desktops. For the great majority of uses, a Linux or BSD desktop can run better and do just about everything you did on a proprietary operating system. And most Unix-like systems can do quite a few things your Windows box can't do, including (in my case) running the whole damn day without the apps robbing all of my memory and sending the box into a cascade of soul-killing swapping.

Right now, when I'm not cutting video, I can — and do — get just about all of my work done on a 2002-era 1.3 GHz Celeron-powered Toshiba laptop running OpenBSD 4.4. I have an identical laptop running Ubuntu 8.04 LTS that I set up when the Opera browser was acting up. I've since fixed up Opera in OpenBSD (putting the words opera:config in the URL window, then clicking open Performance and clicking the Synchronus DNS Lookup box) and haven't needed to use the Ubuntu laptop.

But if I suddenly needed access to an up-to-date Flash player (Opera's Flash player works, just not in all instances), I have the Ubuntu Toshiba. And if I wanted to experiment with video editing in Cinelerra, KDEnlive or any of the other up-and-coming video-editing apps for Linux, I could use Ubuntu, for which most developers seem all too eager to build a package of their app.

(If I needed sound, however, the OpenBSD laptop can't help me. The system configures sound fine, but the sound hardware itself broke. That's what happens when you pull a laptop from a pile destined for the trash and somehow get it working. The sound works in the Ubuntu Toshiba, and I could always swap the drives if I absolutely needed sound in OpenBSD ... if I could figure out how to extract the hard drives, that is.)

Say I really needed to edit video in a super-professional kind of way. I imagine that whatever employer was asking me to do just that would provide me with a modern-day Mac, Final Cut Pro (or Express) and a huge hard drive that could hold all that video. (You can't do much with 10 GB on an old laptop drive.)

(Another somewhat related aside: On my 14-year-old Sun Sparcstation 20, acquired strictly for masochistic hobbyist purposes, OpenBSD runs great, but NetBSD will probably win out due to a much-larger number of precompiled binary applications for the 32-bit Sparc platform. That and Debian's stubborn refusal to install ...)

Getting back to the bread-and-butter computing I do with Web browsers, text editors, anything I need an office suite for, most image editing (right now I'm trying to figure out how to best batch-process images in Unix), even audio editing, which is 98 percent of what I need to get done, I can do it in a FOSS operating system and the applications that go with it.

Why I use OpenBSD instead of Ubuntu, Debian, Slackware, FreeBSD or any number of other systems is both a decision for the moment (one that could change at any time) and a function of what I want to do with that system. Part of the whole equation is learning and having fun, and OpenBSD has certainly succeeded on that score. Not only do you have to get a bit deeper into the configuration files of the OS itself and of the apps to make things happen, but usually the documentation is good enough to guide you to the right solution.

And even if the systems aren't all that similar, what I learn in one OS is generally helpful and applicable in another. That's where the hobby portion of this whole thing enters the picture. I have a good time taking this old hardware and making it work as well as I can with whatever software tools are available to me, and my decision to use OpenBSD right now means that in my own personal/technical journey, this system seems to have what I want technically and philosophically. And the OS handles this hardware as well as anything else, sometimes better.

It's only been a few weeks since I made the decision to use my Windows box at the office less and less (due to ... Windows) and set up the laptop every day and use it not just to test new OSes and apps but to get 90 percent of my work done on any given day. To go from installs all the time, a bit of blogging and Web-browsing in FOSS OSes to coding and editing all day on them is a big evolutionary change for me.

And it's been going very well.

I've said it before: We're very lucky to have so much FOSS out there and not be forced in most cases to use proprietary operating systems and applications to make our computers useful. (Here's the point where I thank all the developers out there who have put this stuff together over the last many years.)

I don't know if we're at the point where every casual user can pick up a Ubuntu-equipped PC and be totally happy. That state of total happiness doesn't exist for Windows or Mac users, either.

But we're getting closer (and not just with Ubuntu). There's got to be the proverbial Malcolm Gladwellian "Tipping Point" somewhere in this realm, and while I'm not ready to declare 2009 "The year of" anything, you never know what's going to bring free, open-source software to the next level for an individual (or groups small, large and enormous). I could list a bunch of things, but I've got work to pretend to do ...

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

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

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

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

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

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

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

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

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

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

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

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

# TERM=vt100 ; export TERM

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

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

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

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

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

This photo of a cool vintage Bearcat scanner is only here because it looks so damn cool. If you want to listen to public-service radio traffic today, you'll probably want/need a modern radio with modern digital features.

Via L.A. Observed, I saw a great link from the Los Angeles Fire Department's equally great blog with tips and links on how to set up your scanner radio to receive fire radio traffic.

The meat of the LAFD entry (thanks Brian Humphrey!) is the list of LAFD radio frequencies and the CTCSS codes needed to open up the squelch on your scanner so you can hear the traffic. The list even goes so far as to link to Wikipedia's Squelch page so you can learn more about how all of this works. They should have linked to the CTCSS page, but since you can get there from here, everybody wins.

Come to the Jan. 27 meeting of TUGNET — The User's Group Network — and hear me speak to whoever shows up.

My topic: Evolutionary computing: Making the leap to free, open-source
applications and operating systems.

What I'll be trying to do is bring the worlds of this blog, which explores the inner reaches of my own geekiness, with that of my print column, Tech Talk, which is aimed at a more general audience.

Both the blog and column draw heavily on my own experience, and I wouldn't have gotten wherever it is I am now if I worried about what I didn't know. I've said on many an occasion that I'm hear to learn and to demystify the process of wading into the technological waters.

Enough of that. What I'll be talking about is my own journey from a garden-variety user of proprietary software to one who aims to use free and open-source solutions wherever possible.

While I burned and ran my first Linux live CD in January 2007, I first got my feet wet in the world of Unix way back in the 1980s through a free on-campus account at UC Santa Cruz, where average (read: non-technically inclined) students were encouraged to use Unix to write and print out (on a bona fide networked laser printer ... and this was right around the time Apple released its original LaserWriter at a cost of $6,995) our essays and anything else we did for our classes.

At TUGNET, I'll talk about the advantages of using free, open-source applications in proprietary environments like Windows and Mac OS and how that makes it all the easier to make the transition to FOSS operating systems that include a few hundred active Linux distributions and four key BSD projects.

I'll be providing tech tips, as well as book and Web-site recommendations on how to learn more about free software, and I'll talk about why I'm using OpenBSD these days more than Linux (and why that could always change because I'm a major proponent of choosing and freely changing both hardware and software to best do the task at hand).

I'd like to thank TUGNET president Marian Radcliffe for inviting me.

And dear reader (as I weakly invoke Jane Austen), I hope to see you there.

I've been accessing my main e-mail account via IMAP for years now. With IMAP, the mail stays on the server, and the mail client brings down the headers and then any messages necessary. That way I can go anywhere, use any computer and have access to that mail with another mail program, or use the same mail server's Web interface to check up on my latest messages.

My main mail client (or I could just say "program," like I did in the last paragraph to make it simpler) is Thunderbird. I can't say I'm deliriously happy with Thunderbird. One reason I use it is that it's available for Windows and Unix/Linux, so I can use it in any of the hundreds of GNU/Linux distributions, in any BSD system, on my Windows box at work, and even on Mac OS if I felt like it (I don't).

Anyhow, I'm not feeling so good lately about leaving my mail on the server. I generally filter quite a bit of it (Thunderbird is great with filters, by the way) down to the local drive anyway, and now I want all of my mail off of a server I don't control and onto a system (or systems) I do control.

Hence POP, or Post Office Protocol, which reigned supreme in the pre-broadband days when people didn't stay connected to their mail server all the time. Back in the day, a user would dial up with a telephone modem, grab their mail with POP, have any mail they composed offline sent, and then read new mail at their leisure, connecting again later to send additional messages.

I just POP-ped down (is it really POP-ped?) a few thousand messages, and for now I'll just say that moving a complicated heap of mail in folders down via POP is messy and nearly undoable. And the mail server in question, at any rate, isn't happy about mass downloads of mail all at once to the local drive.

I lost more than a few messages, I think (it's hard to tell), but I'm glad to have all of that mail off the server.

Meanwhile, I've been using Thunderbird heavily in OpenBSD 4.4, and whether due to the OS or the app, the mail client is running way better here than in Windows. Everything is happening very quickly with no glitches.

Truth time: All of this gives me a very warm feeling about the Web-based e-mail services I also use every day: Yahoo Mail and Google's Gmail. Both of these have given me way less trouble than IMAP, POP and traditional mail clients ever have. (And for the moment I'll forgive Yahoo for the problems I'm having with their "new" mail interface and Google's Chrome browser ... can't compose an e-mail that way; I hope they're working on it.)

Time's short, so I'll hit the high points:

• The fix for all the problems I was having in Opera 9.51 (the Linux version) in OpenBSD was easy. All I had to do was change from asynchronous DNS lookup to synchronous. I even reinstalled Flash for Opera. Regarding the fix, l'll elaborate later.

• Now that I can run Opera, I've been using this circa-2002-03 Toshiba Satellite 1100-S101 laptop (1.3 GHz Celeron) for just about all of my daily work. The laptop's running great, with excellent performance from OpenBSD 4.4 itself and its default Fvwm window manager.

• I wanted to change from IMAP to POP for one of my main e-mail accounts. I had been using Thunderbird in Windows with IMAP. That worked pretty well, but in OpenBSD, I wanted to use POP and have all the mail on the hard drive.

  Either Thunderbird itself, or the entire POP protocol, won't go into nested folders on an IMAP server and grab everything. At least it didn't in my case. So I tried to bring all those IMAP folders onto the local drive en masse. That didn't work so well. I suspect the server won't stay connected long enough to move many hundreds of messages at a time.

  I'm sure I lost quite a few messages, but I also have many hundred that I'll try to move from one Thunderbird installation to the other.

  Knowing what I know now, it would have been better to get EVERYTHING in order on the first Thunderbird installation and then move the entire "profile" over to the second PC. As it stands now, I'll have to figure out how to tap those exact folders/directories and move them over individually. The Thunderbird menus aren't much help with this. Thunderbird needs a robust backup utility built into it.

• In 768 MB of RAM, I'm running tons of apps at once. I can run Opera, OpenOffice, Thunderbird, the GIMP, Pidgin and Firefox and still not swap to disk. I don't think that's so unusual, but usual or not, it's pretty nice. In my world, 768 MB is a lot of RAM, and I'm glad to find out that it's more than enough to do my work.

• Before I figured out how to fix Opera, I rolled out an identical Toshiba laptop with Ubuntu 8.04. That installation went perfectly fine. No problems at all. That laptop has 256 MB of RAM at the moment, and during the 300+ package update after the initial install, there was a whole lot of swapping. Have you noticed in Debian and Ubuntu that the package management uses as many resources as you can throw at them? The machine was unusable during the long update (for which I ran the Update Manager in GNOME).

  You don't have to roll in 300 packages every day, month ... or just about ever, so that's an unusual circumstance.

  I'll keep the Ubuntu laptop at the ready in case I need it for video editing (a task I'm not sure can be done in OpenBSD; if anybody can point me to a package or port, I'd be grateful).

  But for now, the OpenBSD Toshiba is cranking along very nicely. Who knew you could squeeze so much computing goodness out of 1.3 GHz of processing power.

It turns out I'm not the only person experiencing problems with the Opera Web browser (version 9.51 for Linux, I believe) in OpenBSD (version 4.4).

Some say the browser crashes almost immediately on multiprocessor systems. That's not my problem. I'm running a plain ol' Celeron 1.3 GHz.

Some users think the freezes happen during DNS resolution of hostnames. On the OpenBSD-misc mailing list, David Coppa suggests the following:

as a workaround... Can you try to go to:
opera:config -> Performance
and check "Synchronous DNS Lookup"
to see if it freezes a little less?

After my 329-package Ubuntu 8.04 update finishes, I'll set up the OpenBSD laptop, make this change and see how it affects my own personal Opera problem.

This seems too damn simple to work. I'll report back.

Later: I found NO evidence of a Performance --Synchronous DNS lookup feature in Opera's menus. That's because it's not there.

But there's supposedly a way to toggle this feature in the config files. I just tried it. So far, so good.

Here's the deal. I've been using one of my two nearly identical Toshiba 1100-S101 laptops for a growing share of my day-to-day work, and not just at home.

The degradation of my Windows XP-running Dell box over the course of the day (OK, it's not that great in the morning after a fresh boot, either) has driven me to use my older, slower laptops, which under non-Windows OSes actually do things better and faster.

I basically resurrected both Toshibas from death in the form of recycling, which is what would have happened to them had I not pulled them from the haul-me-away pile. Both had XP installed. Until this point, I didn't have any personal machines running XP, and if you don't count the Windows 2000-running Pentium II box I rarely turn on, these are really my only Windows-running PCs I use besides my main work box — the one that barely works.

Think of that last paragraph as somewhat of an explanation for why I'm dual-booting both laptops, the first into OpenBSD 4.4 and the second, as of this afternoon, into Ubuntu 8.04 LTS. I really have little use for Windows, but in the course of whatever it is that I do in these blog entries and my print column, I just might need a Windows machine. Or not. Since I can't reinstall Windows XP whenever I wish due to not having an install CD, I'm leaving those now-shrunken NTFS partitions intact until I decide a) I really need the disk space or b) figure out how to get the hard drives out of the Toshibas and put them aside in the unlikely event that I absolutely need to run XP some time in the far future.

I took Ric Storms' suggestion to remove the Opera Flash plugin from my OpenBSD 4.4 installation to see if that will keep the Opera Web browser from crashing either itself or the whole of X and leaving between two and four errant processes running in its wake.

All I'm doing now is blogging, so that doesn't mimic my real day-to-day use, during which I use and abuse Opera, Firefox, Geany, the GIMP, OpenOffice (yep, I'm running OpenOffice on a limited basis to edit spreadsheets and text documents).

As I've written recently, it's the poor performance of my office-supplied Windows XP box — which is all but impossible to use by the middle of any given day, with the whole thing slowed to a constantly swapping crawl — that has driven me to switch as many of my computing task as possible in the office to my OpenBSD-running Toshiba laptop.

Right now, if I can get into and out of Opera cleanly, with no crashes and no errant processes, I'll be extremely happy.

That's because this more-than-six-year-old laptop runs great with 1.3 GHz of CPU under OpenBSD and runs both real and virtual rings around my 3 GHz Dell box running XP.

While I'll miss the ability to see Flash videos in Opera, there seems to be quite a bit of Flash that Opera in OpenBSD is not able to show, so that functionality isn't 100 percent by any means.

Sure I need to edit video and turn it into Flash, but since I'm even further in OpenBSD than I am in Linux from having adequate video-editing capability, but for the most part I can get my work done without Flash.

But as things stand right now, I can't get that work done without the Opera browser. And if I get it back in OpenBSD (without it or its plugins bringing X down), my work — and my mood — will improve.

Later: Opera sans Flash plugin hasn't yet crashed X, but it did hang things up for maybe 10 seconds at one point. I had a few tabs open and was switching between them rather furiously. If I can quit the app now and leave no trace in top, that will be quite the positive development.

Even later than that: Even without the Flash plugin, Opera crashed about four times in an hour, leaving a half-dozen processes running on the box. So it's not the Flash plugin; it's just Opera. Everything else in OpenBSD 4.4 runs exceedingly well; I can't remember an app ever crashing in this OS. Except for Opera. In order to get my work situation in order, I decided to roll out a Linux laptop.

I've sung the praises of the Opera Web browser many a time. It's a great deal lighter than Firefox, it renders most Web pages well, and most importantly for me, it enables me to use a critical Web-based application that is designed to only work with Internet Explorer, which I try to run as little as possible (and which isn't an option in OpenBSD).

In OpenBSD, Opera is run with the Linux compatibility layer, so it's basically a Linux binary when it comes into the system from ports.

And up until now, I've had no problems with it.

But lately, Opera has been either crashing itself or crashing X.

I can see in top in an xterm window that processes with the name operapluginw (or some other letter after "plugin") can eat 90 percent of CPU and bring the whole laptop to its knees.

Most of the time I can kill the processes in a terminal and then restart Opera right away. Sometimes I can restart the Fvwm window manager from the menu. Other times I have to kill X with ctrl-alt-backspace.

I don't know if the problem is with this specific build of Opera (version 9.51, build 2061), the many packages that allow OpenBSD to run Linux binaries in i386 (including fedora_base and fedora_motif), or something inherent to this hunk of hardware, a 2002-era Toshiba 1100-S101 laptop. It could even be something specific to the software-as-a-service type application I'm primarily accessing with the Opera browser.

Right now the problem is manageable, and I will be testing Opera again in Linux (preferably Debian) very soon.

Due to the inherently quirky nature of our particular development environment, many of my co-workers have been using Opera heavily. The problem I'm reporting here is in OpenBSD only. I haven't seen it in Windows (or previously in Linux). Again, it could be something with the Linux compatibility portion of OpenBSD (this is the only Linux app I'm running), or Opera itself.

In all likelihood, I'll continue running Opera in OpenBSD and see if the problem clears up in the next version of the OS.

And I didn't mention it until now, but my other "main" browsers on this OpenBSD laptop is Firefox 2. In OpenBSD 4.4 for i386, there are packages for both Firefox 2 and 3, but I chose FF 2 for no other reason than that it was still available, and in Unix-like environments I haven't really seen the need to go from FF 2 to 3 if I don't have to.

And Firefox 2 has been extremely solid in OpenBSD 4.4. If I could use it for everything (or could figure out what's ailing Opera), I'd be very happy indeed.

Frustration with my Windows XP box at the office has prompted me to do more and more work at the office on this Toshiba laptop, which happens to have OpenBSD as its primary OS. (I didn't remove Windows XP from the laptop, but I don't use it, either.)

I've never previously used/abused this hardware and OS to the same extent, and in a sense it's a test of the Toshiba, OpenBSD and the applications.

As I recently reported, the whole thing has the potential to run great. If I really needed constant access to Flash video and other such nastiness as Microsoft .NET (which unfortunately I sometimes do), I'd be in a bit of trouble using this platform. I don't even really need Java all that much, but I could install it from ports if things change.

Before I close out this rambly entry, let me remind the reader that one of the things that prompted me to run OpenBSD on this laptop was the balky CD/DVD drive that hates 9 out of 10 CDs I burn for it (and yes, those CDs work fine on other PCs). Even OpenBSD's install CD wouldn't work, so I was able to use the floppy image to boot the system and install over the network.

I'm very interested in Dag Wieers' recent post on why he chose a Lenovo Thinkpad X200s as his new laptop.

Using what developers use is always a good idea. Chances are that more things will work at the beginning, and then it will only get better as those developers start fixing what's broken.

Among the interesting features on the X200s:

• 80 GB solid-state hard drive
• Small and light, yet with full-size keyboard
• Complete hardware-maintenance manual available (VERY important, since laptops tend to break)
• Trackpoint instead of touchpad (I really like the trackpoint on my Compaq Armada 7700dmt; both the functionality and the saving of space with no touchpad) Wi-fi, Bluetooth, fingerprint reader, media-card reader (it would be great if this all worked under Linux)

A long thread at LXer about whether or not Debian should include unsourced binary blobs in its kernel had some commenters if not exactly singing the praises of totally free GNU/Linux distro gNewSense, then at least humming those praises.

The point was that if you really are bugged by blobs in the kernel, you should put your geek-boy money where your mouth is, eschew "compromising" distros such as Debian and Ubuntu, and instead use the Ubuntu-derived, blob-free, Free Software Foundation-approved gNewSense.

The question of the moment for gNewSense, as it is for any Linux distribution (or GNU/Linux ... since we're in FSF/RMS territory here) or BSD OS is, "Will my hardware work?"

When I first installed OpenBSD 4.4 on my Toshiba 1101-S101 laptop (Celeron 1.3 GHz), I kept the stock 256 MB of RAM.

Everything was running so well that I didn't hurry to add RAM.

But since I do have spare PC133 SODIMMs, I could've bumped it up to 512 MB, 768 MB or 1 GB.

I decided to go with 768 MB for now, which meant adding a 512 MB SODIMM.

Opening up the bottom of the Toshiba, installing the module, closing it up and booting all went fine.

And now I'm starting to look at how the system is using memory. Right now I'm running the Opera and Firefox Web browsers, the Geany text editor, the GIMP image editor and an xterm window. This is all in fvwm, OpenBSD's default window manager.

The top utility reports that I still have 289 MB of free memory, and I'm not using any swap at all.

I then opened a spreadsheet and document in OpenOffice (which happens mighty slowly, by the way). Free memory dropped to 190 MB. I realized that while I had the GIMP running, I didn't have any files opened. I cranked up one of the .jpgs I worked on earlier in the day, and free memory was now at 186 MB.

I still could pull the 256 MB module and replace it with another 512 MB SODIMM, but for now this is pretty good performance. I can imagine things going to hell if I started streaming video (on the sites that Opera's Flash plugin support), but in terms of getting work done on this laptop, OpenBSD and 768 MB of memory are doing very well.

When I set up an OpenBSD box, I generally use CUPS — the Common Unix Printing System.

I've had pretty good luck with CUPS and OpenBSD, even though it can be a bit more hacky than usual to get your printers and PCs to come to an agreement and actually print something.

The last time I set up CUPS printing was with OpenBSD 4.4 on my Toshiba Satellite 1101-S101 laptop (the best OpenBSD platform I've had the pleasure of using, by the way).

I had already set up this OpenBSD install to pull packages from my local FTP mirror, after which I installed CUPS using pkg_add.

I can't clearly remember whether or not the install script automatically modified /etc/rc.local to launch the CUPS daemon at boot, but if it didn't the script at least told me what to put in that configuration file to get CUPS going.

The only "local daemon" I'm using is cupsd. Here's what my /etc/rc.local looked like at first:

# $OpenBSD: rc.local,v 1.39 2006/07/28 20:19:46 sturm Exp $

# Site-specific startup actions, daemons, and other things which
# can be done AFTER your system goes into securemode. For actions
# which should be done BEFORE your system has gone into securemode
# please see /etc/rc.securelevel.

echo -n 'starting local daemons:'

# Add your local startup actions here.

if [ -x /usr/local/sbin/cupsd ]; then
echo -n ' cupsd'; /usr/local/sbin/cupsd
fi

echo '.'

CUPS worked. I was able to set up networked printers both at home and at the office.

But during the boot sequence for OpenBSD, the machine would take a few minutes to load cupsd. A check of the script above shows that /usr/local/sbin/cupsd is not running in the background.

I used the & switch to change that. Here's what /etc/rc.local looks like now:

# $OpenBSD: rc.local,v 1.39 2006/07/28 20:19:46 sturm Exp $

# Site-specific startup actions, daemons, and other things which
# can be done AFTER your system goes into securemode. For actions
# which should be done BEFORE your system has gone into securemode
# please see /etc/rc.securelevel.

echo -n 'starting local daemons:'

# Add your local startup actions here.

if [ -x /usr/local/sbin/cupsd ]; then
echo -n ' cupsd'; /usr/local/sbin/cupsd &
fi

echo '.'

See the &? That allows cupsd to load in the background, and now when I start up OpenBSD, I don't have to wait for the CUPS server to start up before getting to a login prompt.

There couldn't be an easier hack to make OpenBSD run better.

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

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

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

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

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

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

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

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

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

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

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

Related:

http://www.sumopaint.com/web/

There is an online photo-editing product branded as Photoshop from Adobe, but ....

Above, the SiCortex SC5832 High Capability System features 5,832 1.4GFlops 64-bit processors, each drawing 900 milliwatts of electricity.

From ZDNet's GreenTech Pastures blog comes news of Linux-based computers from SiCortex that offer between 72 and 5,832 processors each, with each CPU drawing less than a watt of power.

In other words, it's a green supercomputer. Prices go from $25,000 to $1 million, and according to the ZDNet post, the company has moved 54 boxes to entities that include big research universities and the Department of Defense.

Much intrigues me about SiCortex. The company is based in an old Digital Equipment Corp. building in Maynard, Mass, and its management team — they're not youngsters, in case you were wondering — includes co-founder and chief architect Jud Leonard began his career at DEC working on PDP and Vax architectures, while president and CEO Chris Stone worked on software at Data General and at Novell when the company acquired Suse Linux.

Why so intriguing? Glad you asked. The first book I probably ever read on the business of designing and building computers was Tracy Kidder's 1970s classic "The Soul of a New Machine," a gripping journalistic tale of the race between DEC and Data General to build a better 32-bit minicomputer. It's a tale of technological heroism and folly that gives new depth to the world of computer engineering and the creation of something (that's supposed to be) great.

Who wouldn't want to write a book like this?

Related: