I’m the maintaner of the gprolog package under OpenBSD. GNU Prolog stopped building correctly a few months ago and I’m trying to fix it. Some related ideas follow..

I suspect the problem is related to the changes in malloc(3):

> “..the userland’s method for allocating memory, has been rewritten to use the mmap(2) system call on OpenBSD. Traditionally, memory allocated to a system would be all together in one contiguous region. If an algorithm in a program behaved reliably but stepping slightly outside the area of memory it allocated, this was a bug gone undetected. With the release of 3.8, because of the way mmap randomizes the location in memory, this is no longer true.”

This new behavior seemed to break the compilation process.

**Update:** To those of you of saw the first version of this post you might have noticed I lost part of it. This was due to a problem with my internet connection while updating the post at the same time. Oh well, life goes on..

Last weekend, at an event in Portugal, OpenBSD .PT showed a redundant OpenBSD firewall working with two soekrises and two laptops. We had one laptop playing an mp3 that was physically on the second laptop, being shared via NFS, and then simulated a failure on the firewall. A second machine claimed automatically the firewall identity on the network and the music playing just choked a bit and recovered nicely. Kind of what Ryan McBride did at EuroBSDCon but without the axe part! Anyway, it definitely was fun to watch and it is also a good reminder of an OpenBSD based solution that companies can implement under a low budget. Some photos are also available.

Update: I submitted this story to the OpenBSD Journal and it got published.

OpenBSD .PT is running a collective donation effort for OpenBSD. We have gathered around 170€ till now (if you’re interested read here).

Btw, have you seen Theo De Raadt's blog?

OMG! My very first Wikipedia page is up. It’s about PM2, a software for distributed computing I’m using on work. I’ve deleted the local page I had, not that anyone should care.

Firefox gets a big bite out of your memory doesn’t it? So why not run it remotely?

That’s what I thought when I began my search on how to run firefox remotely. I also thought I was going in search of trouble and scary stuff but guess what, it’s easier than I could ever imagine.

Just do an ssh to the remote machine giving the options -Y and -C. The Y stands for X11 forwarding while the C requests compression of all data (including stdin, stdout, etc..).


ssh -YC


And then on the remote shell issue:


firefox -width 100


And you’re done! How easy was that? The “-width” parameter is necessary to trick the “firefox” shell script wrapper, but it won’t influence the width of the firefox window. Don’t forget to copy your .mozilla directory so you can run firefox with your profile and keep your bookmarks, etc.

For me, with my old 320 RAM laptop from 2001, this is great news :-) And as you might guess this isn’t limited to firefox, you can run any application you’d like.

Be sure to have this options on /etc/ssh/ssh_config:

Host *
ForwardAgent yes
ForwardX11 yes


And these ones on /etc/ssh/sshd_config:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no
TCPKeepAlive yes
Compression yes


And that’s it. I’m using firefox remotely now to write on this blog and it’s fast and smooth :-)

This month I will hold a contest. A contest with myself. The challenge is to live in Évora, Portugal, for a whole month with 250 Euros (house rent excluded). Since today is Mar 30, this is not my April’s barl joke but rather an excellent day to start this challenge. I will explain the reasons behind this later on.

Update: I will start in April 1, the beginning of the month.