Recently in Opera Category

I laugh — LAUGH! — when a tech journalist writes something to the effect of, "for lightweight tasks such as Web browsing," when you know, and I know, that there ain't nothing light about using present-day Web browser on present-day Web pages filled with Javascript, Flash and enough CSS to fill a book.

I can edit images all day long in the GIMP and not tap out my CPU or RAM like I do when using Firefox to hit all the Web pages and software-as-a-service type sites (heavy, heavy Javascript) to get my work done.

And this is in Linux, specifically Ubuntu at present. I've run into the same problem in Windows. You start with Firefox or Internet Explorer, and before too long your machine is running like crap.

I spent a bit of time today running most of the browser I have on my Ubuntu 9.04 system, most of which are based on the Gecko engine (Firefox, Epiphany, Galeon), one of which is not (Opera).

And I kept track of how they use CPU resources and memory via the handy Htop utility (top works just as well but isn't nearly as pretty; and you know how I like pretty).

Firefox, no surprise hogs the most CPU on my 1.3 GHz Celeron system (with 1 GB RAM). It's often at 90 percent or more of CPU and rarely dips below 40 or 50 percent. The more pages and the more Javascript and Flash (that's a really killer), the worse it is.

I'm not going to talk so much about memory because with 1 GB, I'm fairly comfortable. With Firefox running, about 400-500 MB is in use; the other browser generally use 200-300 MB.

The other Gecko browsers — the GNOME-supplied Galeon and Epiphany — also spike up to 90 percent when "intensive" things are happening — new pages being loaded, scripts executing, but they quickly "settle" down to 20 percent of CPU and sometimes as little as 10 percent.

Not surprisingly, Opera fared better. The free yet proprietary browser can still use a lot of CPU (in the 90 percent range) during heavy operations. But the difference I see in Opera (I'm running version 10 for Linux and also recommend it for Windows and Macintosh) is that once that instance of heavy use is over, Opera is very quick to give up those CPU cycles and return to a very refreshing 3 to 10 percent of CPU.

However, once the Flash plugin is invoked, all bets are off and Opera is as doggy as anything. It's really Flash that does the damage ... but damage it is. Flash is just plain evil in a box, especially in Linux.

I haven't been as smitten with the Webkit engine, or more specifically the Google Chrome Web browser, as some. In Windows XP with 3 GHz of CPU and 512 MB of RAM, it starts out great but has quite a bit of trouble redrawing the screen in comparison to Firefox once I've been running it for awhile.

I'll certainly keep an eye on Webkit in Linux — Epiphany is supposed to be moving to that engine.

But what I'd like to say once again is that on today's Web, running a browser is quite an intensive operation that requires a whole lot of resources in order to cause as little relative pain as possible to your system — and your nerves.

And there's nothing light about it.

Coming up: One of the 63 dependencies involved in installing digiKam on my GNOME-based, previously KDE-free Ubuntu system is the Konqueror browser. I'll have to try that. And I just added the uber-minimal-GUI-browser Dillo. We'll see how that cuts said mustard.

It's not hard to figure out why the Flash plugin for the Opera browser in OpenBSD works with YouTube (no small thing) and little else.

That's because the port for the Opera Flash plugin hasn't been updated since 2006 and installs version 7 of the Flash plugin.

Version 7.

There's a newer version of Flash (version 9) at this master site, but I'm unsure whether or not that will work in OpenBSD.

To dig deeper into the Opera Flash plugin port, look at the CVS log.

Unsuccessful experiment: To make a long story short, I did find Version 9 of Flash for Linux in the same place as the OpenBSD port finds Version 7. I downloaded the tar.gz file, unzipped it, untarred it, dropped it in a directory and pointed Opera to the new plugin.

When I tried to play a Flash video, the plugin crashed after the first few seconds.

I didn't expect it to work and wasn't surprised when it didn't. I pointed Opera back to the old Flash plugin and went about my business.

I decided to get deeper into Puppy 4.1.2 on my Toshiba Satellite 1100-S101 laptop.

I'm always looking for platforms on which I can do all my Daily News-related work, which means I need the Java runtime and Flash video.

Well, there is a Java package for Puppy. I'm surprised Java isn't part of the base install, but it appears not. I installed the package, and I even brought in the Opera Web browser to augment Seamonkey.

Both browsers are performing well, but for some reason Flash doesn't work in either. I distinctly remember Flash working in all of the Puppy 2 and 3 releases I've used previously, and now I'm left wondering what happened.

Also, Java did NOT work in either browser, so easy use of the LogMeIn remote-desktop service is not something happening in Puppy. I'm getting to the point where I'll need to bit the proverbial bullet and install Java from source in OpenBSD on this laptop so I can get that functionality. I can live without Flash (and the Flash I do have in i386 OpenBSD via Opera is marginal at best; it works in YouTube but not in Brightcove). I can sort of live without Java.

But it's better for the work that I do to have both of these things working well.

Also, I was surprised to see not Pidgin or Gaim as the IM client in Puppy but something I'd never heard of. Pidgin is available as a package, so that's not such a problem.

The end result is that while Puppy 4.1.2. runs quite well at first blush, I need to look closer at why I was so unsuccessful at getting Flash and Java to work. It should be easier than this.

And while Flash remains somewhat of a problem in OpenBSD (I probably need to be running an up-to-date Linux such as Ubuntu, Debian, Fedora, Slackware, Zenwalk ... take your pick) I'll probably stick with it for the time being as my primary OS.

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.

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.

What role does the Internet Explorer Web browser play in your life? In recent days, new vulnerabilities in the flagship Windows browser have come to light.

Alas, the fix is in, but pundits continue to suggest that running IE is just asking for trouble.

I'm not ready to say IE is such a security risk that instead browsing the Web with Firefox, Google's new Chrome, the super-quick Opera or even Apple's cross-platform Safari is enough to save your digital bacon.

Nope, it's all about what you do, where you go and what computing platform you choose to do it with.

The fast is that i386-based Windows PCs continue to be the most vulnerable platforms out there because of both their ubiquity and relative lack of built-in security when compared to Macintosh OS X and the vast number of Unix-like OSes out there (including Linux, the BSDs and Sun's offerings).

If you make a habit of downloading executable files (they're easy to spot in Windows because they end in .exe) without being absolutely sure they're totally legitimate and then double-clicking on them, bad things may very well happen.

Don't get me wrong. Searching for free software for Windows computers is something I do, too. Not often, but I do it. That's how I found some of my very favorite applications on any platform, including the terrific image viewer/editor IrfanView, the fast AbiWord word processor and Notepad++, the best Windows-native text editor ever.

I brought my newly built OpenBSD 4.4 laptop to Starbucks in Tarzana/Reseda (actually the corner of Victory Boulevard and Tampa Avenue) to see how the free AT&T-powered WiFi would work in OpenBSD, which I've learned from my last OpenBSD laptop isn't a slam-dunk when it comes to getting logged in to Starbucks' not-open-to-the-world WiFi service.

What usually goes awry is that the laptop — in this case a 2002-era Toshiba Satellite 1100-S101 — picks up an IP address with no problem from the AT&T router. (I'm using my trusty, works-with-everything Orinoco WaveLAN Silver PCMCIA wireless card.)

But once I start a browser, I don't often get the login screen that actually tells AT&T's lovely router to start passing packets through my IP address.

I actually did have some luck months ago with the Compaq Armada 7770dmt running OpenBSD 4.2 with the Opera and Dillo Web browsers.

But today with the Toshiba running OpenBSD 4.4, I couldn't get anything going with Firefox or Opera. No Web pages would load. I couldn't get a login screen. Never mind that I forget my password every time I try to use this WiFi (that tends to happen when you do something every four months or so).

This laptop does have Windows XP on it, and I was ready to try it when I quit X and ran the Lynx text-only browser from the console.

I got the AT&T Wifi login page, was able to reset my password and log in to the service. Then I launched Firefox, somehow got to an AT&T WiFi page and changed my password.

One thing I'll be trying next time if I don't get a login screen in the browser is to go to this URL, which seems to be the root of all AT&T WiFi-ness in this corner of the country.

It should've come up automatically this way, but hopefully having this URL in my bookmarks will make all this jockeying a thing of the past.

By the way, I didn't have any of these problems using GNU/Linux (Puppy Linux 2.13, to be more specific) to connect to AT&T's Starbucks WiFi.

Bottom line: If Starbucks Wi-Fi isn't coming up in your browser and you're in California, go to https://secure3.sbc.com/ and try your luck there.
Next I'll be trying the Coffee Bean & Tea Leaf free WiFi, which unlike that at Starbucks doesn't require any purchases, registering of any cards, and hopefully not the entry of any logins or passwords.

Yep, I'll expect it to just work. Update forthcoming

(Yes, I do have the OpenBSD T-shirt with this design. It doesn't get more geeky.)

I'm getting ready to give the $0 Laptop (Gateway Solo 1450) to our daughter to run her educational games (Childsplay, Gcompris, TuxPaint) on Ubuntu Hardy with the non-crashing Xfce window manager instead of the crashy version of GNOME in this Ubuntu build.

To replace that machine for me, I pulled a Toshiba Satellite 1101-S101 laptop from the boneyard.

With a 1.3 GHz Celeron processor, 248 MB RAM (how it has this amount, I don't know) and a 20 GB hard drive, the specs are pretty similar to the Gateway, except for the Gateway's 1 GB of memory, which I'll probably split between the two machines.

The Toshiba came to me with Windows XP, and this time I wanted to preserve Windows and dual-boot it with a FOSS OS. The CD/DVD drive is extremely flaky. I think it's dying. It does better with "commercial" CDs, and I did get it to boot Partition Magic so I could shrink the NTFS Windows partition and set it up for Linux.

The only Linux CD I could boot was Debian's Etch and a Half. Something was squirrely on our network, and I couldn't get DNS working in the installer. I could've done a minimal install, fixed /etc/resolv.conf and then brought the rest of Debian into the box, but I took this opportunity to go in a different direction.

With all the CPU fan issue on the Gateway, I could never run OpenBSD (or NetBSD or even FreeBSD after the first boot) because I couldn't get the noisy CPU fan under control.

I powered up the Toshiba, which couldn't get networking in Windows either. Since I don't yet have the administrator password, I couldn't update the DNS settings.

I went to an OpenBSD mirror and downloaded a floppy image plus a DOS/Windows utility that helped me create a bootable OpenBSD install floppy. (Before anybody mentions this, I know I could've just as easily created a Debian boot floppy.)

The Toshiba successfully booted off the OpenBSD floppy, and I was able to plug in a mirror and do a full install over the network.

This was my first dual-boot install of OpenBSD, and after the install was done, the machine wouldn't boot at all. I hadn't installed a bootloader and thought the box would boot into Windows, where I planned to modify that bootloader to choose between Windows XP and OpenBSD. Instead I got a "no operating system" message.

And I don't have a Windows XP disc from which to "repair" the master boot record.

So I rebooted with the OpenBSD floppy, dropped down to a shell and added the OpenBSD bootloader at the prompt:

# fdisk -u wd0

Then I rebooted and was in OpenBSD. There is a GRUB package for OpenBSD, and I'll probably install that so I can easily dual-boot either Windows and OpenBSD or eventually Linux and OpenBSD. There are other alternatives as far as bootloaders go, but my familiarity with GRUB is what is governing my decision in this case.

I'm also going to add rsync as well. I have no skills when it comes to OpenBSD's dump and restore utilities, so having rsync is another plateful of Linux-like comfort food that will help me get along in OpenBSD.

Other packages I've installed thus far: nano, mc (the Midnight Commander file manager), Rox-filer (my favorite X file manager), Geany (X text editor) and the Firefox (I probably should've gotten the version with Java, but I'm going to try to add the Java developer's kit and get the Java runtime that way) and Opera Web browsers.

Opera came via a port and not a precompiled package, and it took a lot longer to install this time than the last time I installed it in OpenBSD (on the Compaq Armada 7770dmt), if I recall correctly.

When you download the ports tree and install from there, everything is fetched for you and compiled when needed. Looking at all the output in the terminal, it looks like these ports could never work, but in my experience with OpenBSD they always do. This time was no different. It took maybe 45 minutes to get all the dependencies plus Opera, but after that it worked immediately.

I've grown accustomed to OpenBSD's default window manager, Fvwm2, and I'll probably stick with it for at least awhile before adding any others. Unlike Debian, Ubuntu, Slackware, etc., installing an app in OpenBSD doesn't automatically update the menus, so you have to manage this yourself. Getting into the guts of the .fvwmrc file is more instructive than not, and once I figured out how to do it, it got less arduous.

I still don't like waiting for ports to download, compile and install, so having 4000+ precompiled packages for i386 is a very good thing.

After a year of strugging with and complaining about the Gateway fan blasting away under OpenBSD, I couldn't believe that I was running OpenBSD 4.4 on the Toshiba with no CPU fan problem whatsoever. Everything from autoconfiguration of my two network interfaces (one Realtek 8189 wired Ethernet, the other an Orinoco WaveLAN PCMCIA wireless) to a perfect xorg.conf made this OpenBSD install go .

I haven't checked audio yet, but I've never had OpenBSD fail to configure the sound card.

I've always read that most OpenBSD developers use laptops to code in the OS, and now that I have this Toshiba running OpenBSD better than anything I've tried before, I'm amazed at how well it installs and runs on this specific platform.

I've probably written a half-dozen posts about exactly why I'm running OpenBSD, and I'll probably write another one as time allows in the week ahead.

And I'll be either ordering a CD set or contributing directly to the OpenBSD project in the days ahead.

After setting up the mail-client portion of Opera, I haven't had much occasion to use it, since I am quite comfortable and happy with Thunderbird in Windows.

The Opera browser is fast in relation to other browsers, and its mail client is fast, too.

I have it set up with IMAP so I can access my mail from any number of places (unless you use one computer all the time ... forever, POP is barbaric). It's a fairly simple client, but it works great, and if you spend a lot of time in front of the Opera browser, it keeps your e-mail just that much closer to you.

Remember the last time I tried using the free Wi-Fi at Starbucks?

I couldn't get it to work with OpenBSD on the $15 Laptop (Compaq Armada 7770dmt with Orinoco WaveLAN Silver PCMCIA wireless card), but everything worked fine with Puppy.

Yesterday I tried again, but I couldn't remember my AT&T Wi-Fi login or password.

Today I have them, and upon first boot in OpenBSD 4.2, I got an IP, no problem, but DNS wasn't working. I finally got it jump-started by restarting the network:

# sh /etc/netstart

That started DHCP again, and for some reason the nameserver was working.

I started the Opera Web browser, logged in, and now I have free wireless working in OpenBSD 4.2 from everybody's favorite coffee chain.

I need to test this some more to make sure the DNS problem either doesn't persist or is easily corrected. Again, in Linux I've had no problems.

But it's nice to know that AT&T and Starbucks don't have anything against OpenBSD.

I've had a bit of a difficult time with my OpenBSD 4.2 installation on the $15 Laptop — a Compaq Armada 7770dmt with 144 MB RAM, a 233 MHz Pentium II CPU and 3 GB hard drive. I use PCMCIA cards for networking, an Orinoco WaveLAN Silver for 802.11b wireless and a TRENDnet TE-100PCBUSR 10/100mbps for wired Ethernet.

Since I upgraded the memory from 64 MB to the 144 MB maximum for this machine, things are running much, much better.

But I'm running out of room in the /usr partition. I'm not sure whether or not OpenBSD can be installed in a single partition, but since the install FAQ tells you to set up separate partitions for everything, that's what I did.

On this drive, I set aside about 600 MB for Linux filesystems to create swap and a place to store files for Puppy Linux, leaving 2.4 GB for OpenBSD.

At the end of the OpenBSD partitioning, I had 1 GB for /usr, which is where applications are stored in the system.

For awhile things were going fine. I had our daughter's Gcompris, TuxPaint and Childsplay games on here, Firefox, the Geany text editor, plus a few console apps like nano, mc and mutt.

But it's not console apps that are taking up all the space.

I pulled the games and their libraries in order to fit the Opera Web browser and the Linux compatibility package needed to run it. That was the best thing I've done for this install since I did it. On this old hardware, the Linux build of Opera runs much faster than Firefox.

That speed really shows up when blogging with Movable Type. For some reason, even in Linux, scripts keep timing out in Firefox and the Mozilla-based Seamonkey. Now that I have Opera installed in both OpenBSD and Puppy 2.13, I'm a lot happier on this old laptop, which is about as challenged as it gets when it comes to old hardware working with modern operating systems and applications.

Anyhow, I needed to do some more "formatted" writing, and I did have the Ted word processor installed. But Ted isn't great when it comes to centering type, print previews or generating PDF output.

I needed Abiword. But I didn't have enough space.

The only thing big enough: Firefox.

Yep, I got rid of Firefox. One thing about the OpenBSD package manager that isn't helping me out here is that when you install a package, all the dependencies are checked, and the additional packages needed are downloaded and installed. But when you remove a package, the system doesn't check its dependencies for whether or not they're still needed by other applications in the system.

I'm sure there's a reason for this, and there's probably even a way around it (like the great deborphan app that I use in Debian), but I know nothing about it.

Anyhow, I managed to get Abiword installed, and I have 500 MB left in my /usr partition. Unfortunately, the spell-check in Abiword doesn't work in the OpenBSD build. Abiword spell-check doesn't work in Puppy either.
The spell-check installs and works most of the time in Debian (especially when you install it with Aptitude and get all the packages you need, rather than with apt-get, where at least sometimes you don't).

I found an old OpenBSD mailing-list hack about how to fix Abiword's spell-checking capability, but it didn't have enough information, and it didn't look like it would work anyway.

But the good news is that with this amount of memory, Abiword 2.4.5 runs extremely well in OpenBSD 4.2. Additionally, for some reason the fonts in Abiword look better in OpenBSD than then do in most other Linux/Unix systems.

So now I have Abiword, Geany, Opera and the Dillo browser as my "main" applications on this system. I don't want to forget the Rox-filer file manager. I put that on the box awhile ago. I still need space to add the Flash plugin for Abiword, and Rox is a prime target for removal so I can get that space ... or the space to install Gaim/Pidgin for IM.

But I just can't do it. I've loved the Rox-filer ever since I first used it in Puppy, and I just can't give it up.

I probably should. I removed mc (Midnight Commander) for space reasons, even though it probably doesn't take up all that much space, and since I had Rox. If mc didn't have problems with the function keys in the console (it misreads the keys for some reason), I'd be able to fit one more app in. (Note: mc works perfectly in an xterm window, just not in the console).

What I'm going to have to do eventually is reinstall OpenBSD. I need a bigger drive so I can have a big /usr partition, install everything I want on it, as well as have room for a full Linux install as well, something I could use in addition to Puppy.

So the OpenBSD install is really tight, in terms of space for applications, but it's working extremely well. I now have the ability to share files between OpenBSD and Linux via an ext2 partition, and that has added tremendous value to this laptop.

I could be using my Gateway laptop a lot more. It's got way better specs (1 GB RAM, 1.3 GHz CPU) and runs Linux way faster. But it isn't so hot with OpenBSD due to the noisy, uncontrollable-by-BSD CPU fan. And its PCMCIA slot still isn't fixed, so I can't run wireless with it.

The Compaq may be underpowered, but it has a very clear, very bright screen, an excellent keyboard, working wireless, no ACPI issues (since it has no ACPI), and there's just something about getting it to work and keeping it working that I find compelling.

And there's also something about OpenBSD that keeps me coming back to it, even on the desktop.

I know that application startup time isn't everything. But it's definitely something.

Here are the numbers for Puppy 2.13 and OpenBSD 4.2 on the $15 Laptop (Compaq Armada 7770dmt, 233 MHz Pentium II MMX, 144 MB RAM):

OpenBSD
Firefox 2.0.0.6: 120 seconds
Opera 9.22: 37 seconds

Puppy Linux 2.13
Seamonkey (Mozilla-based): 30 seconds
Opera 9.02: 34 seconds

Analysis: Firefox/Mozilla is a fairly heavy application, but the Seamonkey version of Mozilla does quite well in Puppy, where it beats Opera slightly when it comes to start time.

But in OpenBSD, Opera is a standout for some reason, starting in about a third of the time that Firefox takes to start. Opera works with Movable Type much better in OpenBSD, with no stalled-script messages.

Question: Is there any way to run Mozilla browser code faster than Firefox? I need to test Firefox in Puppy (and, if I had the space, Seamonkey in OpenBSD) to fill out the data.

Conclusion: Application startup and response time is extremely critical with older machines. Since most of my computing time is spent in Web browsers, I welcome the speed and functionality of Opera in OpenBSD; it has pretty much given this OS a proverbial "new lease on life."