Hacking Your First Hackathon

tomo — Sat, 08 Jun 2013 07:13:49 +0000

Today I'll be speaking, mentoring, then judging at Keewi's Hack Day event.

Over a decade ago I joined a group of "hackers" in developing an open source ultra-secure UNIX operating system called OpenBSD. As the most secure OS in the world, it was designed to keep out hackers, as in crackers, those seeking unauthorized access to computer systems. But we were also hackers, a type of "artisanal" programmer. OpenBSD hackers are spread across the world and they gather themselves together periodically into one place to be super productive on a common goal over the course of several days. OpenBSD invented the hackathon, even coining the word itself.

I attended my first hackathon back when I was still in school, which I graduated from over 10 years ago. It was organized by our university's open source club, the only extracurricular activity I was involved in. We got permission to use one of the classrooms overnight and even got funding to buy a couple pizzas and pop. That was it. There were no corporate sponsors. There were no spectators watching us code except for our confused girlfriends. There were no headhunters or suits looking for geeks they could make use of. And there was no prize money because we were just there to see what hacks we could pull off in a night and then show each other.

Nowadays, hackathons are more and more common and are seen by corporations as something they can take advantage of.

OpenBSD uvm_mapent_alloc: out of static map entries

tomo — Fri, 01 Apr 2011 20:02:59 +0000

Every few months, I've had remote OpenBSD servers die mysteriously, without any visible console messages, and still responding to pings, although higher level networking (http, ssh) are unresponsive. The crontab I setup to dump output from top (or systat) also stops. But before the kernel failure load was low and swap was unused.

After rebooting and checking dmesg, I see before the most recent reboot:

uvm_mapent_alloc: out of static map entries

Doing some research, it seems like it could be a problem with kmem_map fragmentation, possibly from long-running processes (like apache, which is being used more heavily now). The problem appears to have been fixed in recent releases of OpenBSD which dynamically increase kmem, but upgrading the server right now isn't feasible.

So the solution is to compile a custom kernel with an increased MAX_KMAPENT added to GENERIC config:

openbsd

Hacking Your First Hackathon

OpenBSD uvm_mapent_alloc: out of static map entries