Auto-indentation in Geany: made for programmers, great for writers

Not that anything approaching brain-surgery-level thinking was in any way involved here, but I figured out why and how it’s easy to get paragraphs to automatically indent when writing in the Geany text editor.

First of all, it’s not called automatic tabbing or paragraph inentation. The correct term for what I’m enjoying so much is auto-indentation and it can be turned on and off under the Document menu in Geany. The defaults for auto-indentation can also be set in the Edit menu under Preferences–Editor.

When writing for print, where I don’t need — and can’t stand — having two returns between paragraphs. After transferring the file from this laptop to my newspaper’s print publishing system, those double-returns demand that I delete one of them. That’s because in most non-Web publishing, indented first lines make paragraphs distinct from one another, not extra linefeeds.

So having the indents on the first line of every paragraph helps me seen where each paragraph begins.

I know that programmers use indents to help structure their code. But when something so right for coding in C also helps hacks like me, making traditional word processing applications less needed, everybody wins.

How I lost (and subsequently found) 32 MB of RAM on my Compaq in OpenBSD

My inability to do more-than-simple mathematics at times has really put a cramp in my computing style.

In the case of OpenBSD and the $15 Laptop — the Compaq Armada 7770dmt — it has cost me 32 MB of RAM ever since I upgraded from 64 MB to the maximum 144 MB.

The reason is that in some Compaq’s OpenBSD will not address more than 16 MB of RAM without some intervention on the part of the user.

This intervention is described in OpenBSD’s installation FAQ. In order to have the system recognize the additional memory in the affected Compaqs, you must create a file called /etc/boot.conf containing one line, which tells the OS about your additional memory.

The example in the OpenBSD FAQ is for a system with 64 MB of RAM but with the aforementioned 16 MB being recognized.

To get the additional 48 MB recognized by the system, the following line should be in your new /etc/boot.conf file:

machine mem +0x3000000@0x1000000

That worked perfectly when I, also had 64 MB of RAM.

But when I added 128 MB to the 16 MB on the motherboard (removing the 48 MB of RAM that the laptop had when I originally got it working), I had to change the value in /etc/boot.conf.

And I didn’t do my math correctly. This is what I had:

machine mem +0x6000000@0x1000000

I suspected that the machine wasn’t using the entire 144 MB, but I’m not conversant enough in OpenBSD as opposed to Linux to a) figure out exactly how much memory the system was recognizing (a number available in the dmesg output) and how much the system was using and how much was still “free” (which can be seen in the output of the top utility.

I’ve been looking at OpenBSD’s installation FAQ again recently because I’m eager to try the OS on my new/old Power Macintosh G4/466, and I looked at the section on Compaq memory again and realized my error.

I realized that if 48 MB is recognized with +0x3000000, then each +0x1000000 represents 16 MB of additional memory. And following that logic, 48 MB is 16 MB times three, yielding the FAQ example of +0x3000000.

And since I was adding 128 MB, that was 16 MB times … how many? Eight is the answer. So instead of the +0x6000000, I needed the following line in /etc/boot.conf:

machine mem +0x8000000@0x1000000

I booted OpenBSD 4.2 (I don’t have enough space in /usr to upgrade to 4.3 — such is the problem with making that partition only 1 GB in size when it needs to be, as the FAQ says, 5 GB). Then I changed the value in /etc/boot.conf, rebooted and saw the dmesg roll by during the reboot with the entire 144 MB being recognized.

Missing 32 MB all this time represents a very large performance hit, and I’ll be anxious to see how gaining access to that memory changes performance under X.

For those keeping score, here’s the relevant part of my OpenBSD dmesg AFTER doing the /etc/boot.conf fix:

real mem = 150564864 (143MB)

avail mem = 137732096 (131MB)

Long-lost Click: 64 MB to 144 MB — will it make a difference?

(This post was originally written on May 22, 2008; since that time, I’ve added the RAM, and it does indeed make a difference. It’s still not easy to live with 144 MB of RAM and 233 MHz of CPU, but it’s easier than having less than half of that M. What I can say is that 500 MHz of CPU and 256 MB of RAM is positively picnic-ish. Also, I finally did the OpenBSD 4.2-to-4.3 upgrade on the VIA box. It wasn’t easy, but I did get it done.)

If the question is “how low can you go” in terms of computer memory, it’s all about applications.

If you stayed in the Linux console and never ran X, just about anybody could be happy with 32 MB of RAM. It might be hard to actually run Linux or a BSD in 16 MB, but I’ve heard of Linux distributions that will do it, Damn Small Linux, Tom’s RtBt (is that the right spelling?) and DeLi Linux among them.

But as much as the hard-core users talk about how they stay at the command line all the time, it’s hard to get much done strictly in a console when you’re a regular person. Sure you can use Lynx for text-only Web browsing, you can set up Mutt (and Postfix/Sendmail/msmtp/esmtp, Procmail and whatever other helper apps are needed) with highly customized configuration files designed to handle and filter multiple mail accounts, use Vi or Emacs for text editing and all that.

But the bottom line for me is that I need a Web browser. A “real” Web browser, something that works with Movable Type and Google Docs, and that pretty much means Firefox or some Iceweaselish derivative.

I don’t tend to use OpenOffice very much (although it runs better in Debian with 64 MB that you’d think), I barely even use AbiWord these days. I’m not saying that I won’t need OpenOffice in the future, but at present I’m most comfortable using various X text editors, including Geany in most Linuxes and BSDs, Gedit when I’m in GNOME, and Google Docs half the time just for the easy portability of my copy.

And while Geany doesn’t load super quickly from a “traditionally” installed distribution (but is quite quick when loaded into memory as it is in Puppy Linux, once it’s loaded it runs very well indeed.

And the Dillo Web browser — which looks better in its OpenBSD incarnation than it does anywhere else — performs quite well in 64 MB of RAM. The only problem is that Dillo can’t do everything I need to do on the Web. At least the Dillo in Puppy and DSL has https support. That’s not turned on in OpenBSD, and the app needs to be recompiled to add it. I can manage to turn on cookies in OpenBSD, which helps me with some sites, but for anything remotely complicated, Firefox is essential.

And while Firefox will run in 64 MB of RAM, it does so very poorly. There just isn’t enough memory to keep the program from swapping to the drive incessantly whenever doing just about anything.

In this very 64 MB, I’ve run just about everything that will load on this Compaq laptop: Puppy, DSL, Debian (the Xfce install, plus a “standard” install with Fluxbox), Slackware (without KDE) and OpenBSD.

Truth be told, Almost all of these OSes run just about the same. Damn Small Linux has a bit of an edge, and if DSL 4.3 ran as well as 4.0, its inclusion of Firefox 2 would put it over the top. As it is, I’ve lost my desktop wallpaper, and I can’t figure out how to display the menu in Fluxbox (even though I prefer to run JWM).

Puppy definitely needs more memory, especially to run the Mozilla-derived Seamonkey Web suite.

Debian Etch was OK. While the Xfce install is odd in many ways, as I say, I was surprised to see OpenOffice run at all — and not too badly at that. Iceweasel was, again, an exercise in frustration. But Debian remains a distinct possibility for this machine.

It’s main OS for awhile has been OpenBSD, with a partition set aside for the Linux files generated by the Puppy and DSL live CDs.

OpenBSD runs pretty well, but as I said, Firefox remains an issue.

The question: Will things improve with the boost of RAM from 64 MB to the Compaq Armada 7770dmt’s maximum 144 MB? From my past experience, I know that Puppy can run in 128 MB if you have swap space, and DSL is certainly comfortable with 128 MB.

To answer the question, I could reduce the memory in my Via test box from 256 MB to 128 MB and see how OpenBSD (now version 4.3) runs in that configuration. But I’d have to pull the cover from my converted thin client and find a 128 MB SIMM. I’ve probably got one … somewhere.

Better to just wait for my Compaq memory to come in the mail (luckily it’s cheap).

I’ve know for awhile that 256 MB is a significant sweet spot for Linux, but I’d love for 144 MB to be just sweet enough to give this laptop a new lease on open-source life.

And while I managed to upgrade my VIA box from OpenBSD 4.2 to 4.3, it takes a lot more work than a simple apt-get, and I’m reluctant to do it

Long-lost Click: Thanks for the memory (almost)

(This post was originally written on April 24, 2008; since then, I’ve bumped the system up to 144 MB. This entry should set the scene for how much better things are working with the additional memory).

When you’re not running X, 64 MB of RAM is plenty. In OpenBSD, or just about any version of Linux for that matter, you just don’t need a lot of memory to use the console. Of course, you can’t do a whole lot either.

I know, I KNOW, that real geeks use the command line as much as possible. E-mail with Mutt or Pine (and fetchmail, procmail, sendmail, procmail … did I miss anything (maybe msmtp, which I prefer, or esmtp, exim, postfix …), text entry with vi (or nano, joe, emacs), text-only Web browsing with Lynx or Elinks.

OK, I do all this stuff, though I did give up on Mutt; it just didn’t work for me as well as I needed, and while I put in plenty of time on the configuration, I needed to be way more of an expert than I’ll probably ever be). But I really prefer to run X. I get the apps I want, real Web browsing, and a whole lot more overall productivity.

But X takes memory, and while OpenBSD with the Fvwm window manager can run in 64 MB, things take forever and a day due to all the swapping. Unfortunately, my 1999-era laptop — a Compaq Armada 7770dmt — maxes out at 144 MB. That’s 16 MB on the motherboard, plus two 64 MB EDO SODIMMs.

The memory is on the way (I hope). Right now I have two smaller SODIMMs, a 16 MB and a 32 MB, in the laptop. And yes, I had to do the Compaq memory fix from the OpenBSD FAQ to make the OS recognize the “extra” memory. But it does work.

Anyway, I’m hopeful that OpenBSD will perform dramatically better in X with 144 MB. Since this is a pre-ACPI laptop, I don’t have the problems that plague me with my Gateway Solo 1450, on which only Linux, it seems, will turn the fan on and off in response to CPU temperature. In OpenBSD, it’s all on. In FreeBSD, it works for a day, and then that’s the end of it. Can’t figure out that one.

But I’d love to have a laptop devoted to OpenBSD (I’m using vi now … but I miss Geany, Firefox and the rest of the junk I’ve got loaded on here). And if OpenBSD can work well on the desktop with only 144 MB, that will be a significant achievement for all of us with hardware in the 10-year-old range.

I’d love to roll OpenBSD onto my 10-year old PC that now runs Windows 2000. It would Do OK with Linux, for sure, but getting OpenBSD on there would be really great. And I have a full 256 MB of RAM on that box. I’m already running that much memory on my test box in the office, and I have no complaints there when it comes to running X apps in OpenBSD.

I started X to finish this post. First I ran Firefox, even though this laptop has only wireless 802.11b networking (and no wired Ethernet, although I’ve been meaning to get a PCMCIA Ethernet card). Yep, still takes a dog’s age to start Firefox, and it’s not all that responsive when it’s running.

Again, I would love for that NOT to be the case after the memory upgrade.

I started Geany to continue writing. Geany runs pretty well with this 233 MHz processor and 64 MB of RAM.

So does the Dillo browser. And everytime I write about Dillo in OpenBSD, I like to mention that, for some reason, the Dillo menus and buttons look way better in the OpenBSD version of the app (I’m using the package, not the port) than they do in any other operating system in which I’ve tried it. And I’ve tried many.

Installing Fedora 9 on the Power Mac G4/466 — Part 2

When we left off, Fedora was taking quite a long time to install over the network on this Power Mac G4/466.

I returned to the office to find the Fedora 9 install finished. I rebooted.

No X.

After Debian Etch installed with no problems whatsoever, I don’t know why I expected Fedora 9 to do the same thing, but I did.

I didn’t think to save the xorg.conf from Debian to help me configure X in Fedora. I thought, if they can’t autoconfigure X on a Power Macintosh G4, which likely represents a huge chunk of all PowerPC machines that might try to run Fedora, what can they autoconfigure?

I found some of the information I needed online, and I was able to get X to work with 1024 x768 resolution.

I didn’t take the extra time needed to flesh out the meager xorg.conf to get my monitor’s native 1600×1200 resolution.

Why?

Fedora 9 was really choking on the G4/466. Yes, the 466 stands for 466 MHz. And yes, I only have 128 MB of RAM.

But Debian ran so comparatively well, I couldn’t see staying with Fedora longer than the half-hour it took me to finally get X to work.

In Fedora, everything was slow. Getting menus to open, apps to start.

Before I reinstalled Debian Etch — which I did do, by the way — I tried to install OpenBSD 4.3.

The OpenBSD instructions for MacPPC were less than stellar. It’s pretty much just a rambling supplement to the i386 instructions in the FAQ.

I went through the install, but when it came time to boot from the hard drive, that didn’t happen.

Otherwise, it was a typical OpenBSD install, whatever that means. I must’ve neglected to make the proper partition bootable.

I’ll have to study both the regular FAQ and the MacPPC instructions and see what I did wrong.

Part of this is a lack of understanding on my part regarding how the Mac boots, i.e. with yaboot and not the i386 bootloaders GRUB and LILO.

I could install OpenBSD on the same drive as Debian, or I could swap in another drive. I don’t think I’m confident enough to dual-boot OpenBSD as yet.

Anyhow, I wanted to actually use the box, so I reinstalled Debian Etch, and once again everything works perfectly and acceptably fast. Not super-speedy fast, but remember, this is a 466 MHz/128 MB box. If I could somehow find a couple of memory sticks that would work in this thing, I’m sure I could improve the performance immensely.

And I’m not giving up on the OpenBSD install, either. I don’t know how well OpenBSD will run on this box, but I really need to find out. I could always throw NetBSD or FreeBSD on it; both have PowerPC ports.

Huge stopper for PowerPC: I never thought about it before, but I’m sure thinking about it now: There is no Flash player for Linux (or any BSDs, for that matter) on PowerPC.

I tried swfdec, but I have yet to find a single thing it will work with.

Gnash is not in the Etch repositories (although it’s probably in Backports), but it is in Lenny. I’ve never previously gotten it to work, but maybe it’s getting better. That’s a potential solution for Linux and OpenBSD.

In my shop we work with Flash quite a bit. I’m going to leave this loveliness right now and go to a Mac to create something in Flash. The fact that Flash is resource-heavy, doesn’t run on all platforms and is basically a pain in the ass doesn’t appear on the radar of most people.

Getting some kind of open-source player, whether it be Gnash or something else, is essential if Flash is going to continue dominating the online video space. Having a way of creating Flash in open source is another thing that we sorely need.

If Sun figured out that we all need the tools to create and run Java, maybe Adobe will eventually feel the same way about Flash. I’m not holding my breath.

Back to the box: So I’m running Debian Etch again, and it’s quite a testament to everybody behind Debian that it runs so much better on this hardware than Fedora.

This box is a pretty good candidate for Lenny. I don’t know if I’ll do an upgrade yet because I’m getting tired of having to constantly download and install so many new packages every few days on my Lenny laptop. If Etch ran better on that Gateway, I’d be using it, but it doesn’t.

I have a good feeling about Lenny and this G4, but I’m going to wait until it goes stable, and then maybe wait some more, before doing an upgrade.

Installing Fedora 9 on the Power Mac G4/466 — Part 2

When we left off, Fedora was taking quite a long time to install over the network on this Power Mac G4/466.

I returned to the office to find the Fedora 9 install finished. I rebooted.

No X.

After Debian Etch installed with no problems whatsoever, I don’t know why I expected Fedora 9 to do the same thing, but I did.

I didn’t think to save the xorg.conf from Debian to help me configure X in Fedora. I thought, if they can’t autoconfigure X on a Power Macintosh G4, which likely represents a huge chunk of all PowerPC machines that might try to run Fedora, what can they autoconfigure?

I found some of the information I needed online, and I was able to get X to work with 1024 x768 resolution.

I didn’t take the extra time needed to flesh out the meager xorg.conf to get my monitor’s native 1600×1200 resolution.

Why?

Fedora 9 was really choking on the G4/466. Yes, the 466 stands for 466 MHz. And yes, I only have 128 MB of RAM.

But Debian ran so comparatively well, I couldn’t see staying with Fedora longer than the half-hour it took me to finally get X to work.

In Fedora, everything was slow. Getting menus to open, apps to start.

Before I reinstalled Debian Etch — which I did do, by the way — I tried to install OpenBSD 4.3.

The OpenBSD instructions for MacPPC were less than stellar. It’s pretty much just a rambling supplement to the i386 instructions in the FAQ.

I went through the install, but when it came time to boot from the hard drive, that didn’t happen.

Otherwise, it was a typical OpenBSD install, whatever that means. I must’ve neglected to make the proper partition bootable.

I’ll have to study both the regular FAQ and the MacPPC instructions and see what I did wrong.

Part of this is a lack of understanding on my part regarding how the Mac boots, i.e. with yaboot and not the i386 bootloaders GRUB and LILO.

I could install OpenBSD on the same drive as Debian, or I could swap in another drive. I don’t think I’m confident enough to dual-boot OpenBSD as yet.

Anyhow, I wanted to actually use the box, so I reinstalled Debian Etch, and once again everything works perfectly and acceptably fast. Not super-speedy fast, but remember, this is a 466 MHz/128 MB box. If I could somehow find a couple of memory sticks that would work in this thing, I’m sure I could improve the performance immensely.

And I’m not giving up on the OpenBSD install, either. I don’t know how well OpenBSD will run on this box, but I really need to find out. I could always throw NetBSD or FreeBSD on it; both have PowerPC ports.

Huge stopper for PowerPC: I never thought about it before, but I’m sure thinking about it now: There is no Flash player for Linux (or any BSDs, for that matter) on PowerPC.

I tried swfdec, but I have yet to find a single thing it will work with.

Gnash is not in the Etch repositories (although it’s probably in Backports), but it is in Lenny. I’ve never previously gotten it to work, but maybe it’s getting better. That’s a potential solution for Linux and OpenBSD.

In my shop we work with Flash quite a bit. I’m going to leave this loveliness right now and go to a Mac to create something in Flash. The fact that Flash is resource-heavy, doesn’t run on all platforms and is basically a pain in the ass doesn’t appear on the radar of most people.

Getting some kind of open-source player, whether it be Gnash or something else, is essential if Flash is going to continue dominating the online video space. Having a way of creating Flash in open source is another thing that we sorely need.

If Sun figured out that we all need the tools to create and run Java, maybe Adobe will eventually feel the same way about Flash. I’m not holding my breath.

Back to the box: So I’m running Debian Etch again, and it’s quite a testament to everybody behind Debian that it runs so much better on this hardware than Fedora.

This box is a pretty good candidate for Lenny. I don’t know if I’ll do an upgrade yet because I’m getting tired of having to constantly download and install so many new packages every few days on my Lenny laptop. If Etch ran better on that Gateway, I’d be using it, but it doesn’t.

I have a good feeling about Lenny and this G4, but I’m going to wait until it goes stable, and then maybe wait some more, before doing an upgrade.

Fsck errors in the Linux filesystem on my OpenBSD laptop NOT caused by OpenBSD

I’ve been able to have OpenBSD’s /etc/fstab automatically mount the ext2 filesystem on my Compaq Armada 7770dmt’s hard drive with no difficulty lately, but every couple of days or so I get a message while booting OpenBSD that says the Linux filesystem is not clean and that I should run fsck on it.

I then boot Puppy Linux 2.13, run e2fsck on the partition, the errors are cleared up, and all is well until a few more days pass.

I haven’t lost any data, but I’m going to do a few experiments.

First, I added noauto to the /etc/fstab line so the Linux filesystem will not be automatically mounted. Then I’m going to run Puppy for a few days and check the filesystem with e2fsck.

It could be that the errors are coming from Puppy alone. I think that’s unlikely, but it is a possibility.

Then I’ll experiment with manually mounting (with mount) and unmounting (with umount) the Linux filesystem while in OpenBSD.

That way I can see whether or not automounting and unmounting the ext2 filesystem in OpenBSD is what’s causing the problem.

Hours later: Looks like OpenBSD is NOT responsible. I ran Puppy totally in RAM (using the puppy pfix=ram boot parameter), than ran e2fsck to clean up the filesystem on my ext2 partition. Then I ran Puppy the “normal” way, in which the system mounts the partition to access the pup_save file. I then rebooted and once again ran Puppy without mounting the partition. At no time did I boot OpenBSD or mount the filesystem in that OS.

Once I was back in Puppy, running pfix=ram to keep the partition unmounted, I ran e2fsck and got this message:

/dev/hda3 was not cleanly unmounted, check forced.

I had one more test to do.

Now that I had run e2fsck on the ext2 filesystem, I needed to boot OpenBSD, mount the filesystem, write a file to it, then unmount it. After that, it would be time to boot Puppy Linux again, using the pfix=ram boot parameter again so as not to mount the filesystem in Linux, and then run e2fsck again to check the filesystem and see if mounting, writing to and then unmounting it caused any errors.

So I booted into OpenBSD 4.2, mounted the ext2 filesystem, modified a few files, added a few, then unmounted it. I rebooted and did the same thing again.

Then I booted into Puppy, again with the pfix=ram boot parameter so as not to mount the Linux partition.

I ran e2fsck. After two boots of OpenBSD, during which I modified files in the Linux filesystem both times, there were no errors in the ext2 filesystem.

I said it was “unlikely,” but in fact it’s Puppy Linux, NOT OpenBSD that is not “cleanly” unmounting the Linux filesystem. I truly expected it to be the other way around.

I’ll have to test this with Damn Small Linux, Wolvix and maybe even Slitaz to see if this is a Linux problem, or just a Puppy (or Puppy 2.13, to be more specific) problem. But right now, OpenBSD has absolutely nothing to do with it.

Mounting the filesystem in:

Damn Small Linux 4.3 caused no errors

Starbucks WiFi does work with OpenBSD

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.

OpenBSD on the $15 Laptop: The application shuffle

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 bring OpenBSD and Linux together

I’ve been trying to mount a Linux filesystem in OpenBSD 4.2 for awhile, and finally I figured out how to do it (and do it automatically at boot) without screwing up either my OpenBSD or Linux partitions.

I have a tutorial on this about 1/2 of the way done, but this was another situation where the excellent OpenBSD FAQ and man pages, as well as a couple of good general Linux/Unix online tutorials gave me all the help I needed. (I can never remember quite how to make chmod do what I want without looking it up.)

Since I installed OpenBSD on the Compaq Armada 7770dmt’s hard drive without fully setting up the Linux partitions (all I have is swap and an ext2 partition for my live CD files), OpenBSD didn’t know how to properly mount the ext2 partition.

Briefly, I needed to run fdisk in OpenBSD, transfer the Linux information to the OpenBSD disklabel, create a directory in which to mount the Linux filesystem, give the wheel group write access to that directory, then edit /etc/fstab to properly mount the ext2 filesystem at boot.

Once I was sure the Linux filesystem was properly mounting and was writable from OpenBSD, I booted Puppy Linux without mounting the partition and then ran e2fsck to clean up any errors (there were some).

Since then, the filesystem has been error-free, and I can easily exchange files between my OpenBSD and Linux installs on this laptop.

It’s nice to solve a problem for a change.