OpenBSD Journal

[c2k10] (Part 6)

Contributed by mtu on from the bigmem dept.

P6280206s How leaders, managers, mentors and coaches motivate others towards a common goal is a very well researched topic. The methods typically used within entirely volunteer organizations center around exceedingly polite interactions, strong encouragement through accolades, and fairly gentle suggestions when mistakes are made. The way the OpenBSD project operates is vastly different from the accepted norms.

Read on to find out more about beck@ and learn why the OpenBSD project succeeds with their goals where others flounder:

[c2k10] Article Series: 1 2 3 4 5 6 (more to follow)

Bob Beck (beck@) is a developer who leads by example and codes the code, so to speak. He started using OpenBSD in 1995 with the first release. He's truly one of the real OpenBSD veterans. At that time, your choice was limited and he was working on networking and needed an OS with networking that really worked. OpenBSD was it.

After Bob settled on OpenBSD, he tried to send Theo a pizza to show appreciation, but couldn't do it for some reason, so he called Theo about not being able to send hacker fuel. That was the start of their friendship, and sending pizza has been a running joke ever since.

p1030471s "We improve OpenBSD for us, not for others," said Bob, "We're not as altruistic as you might think." If you've been around long enough, you have seen this opinion repeatedly voiced, so you may wonder why the developers continuously improve OpenBSD? --The common answer is, it's fun.

There are other unique aspects that set OpenBSD developers aside from the people working on other projects. They require high quality and voice their opinions very directly. A person needs to have the right mind set, right skill set, and a personal connection. Bob said, "Software quality wouldn't be the same if we were nice to everyone." Developers must be able to take criticism. Long before anyone gets a cvs account, there is the process of submitting diffs and getting criticism. A person with the right mind set, skill set and personal connection will try to improve from the criticism. Keeping people involved and software quality are often at odds with each other. Many projects try to be too inclusive and overly nice to everyone. In OpenBSD, the code must stand on its own merits.

p1040193s The hackathons are another unique aspect of OpenBSD. I've written a lot about them and how important they are. However, you may enjoy the following insights from beck@:

  • You start major design discussions at hackathons (this is an OpenBSD thing).
  • Things are either started or finished at hackathons, but almost never both.
  • You get dedicated time to concentrate on what you're starting or finishing.
  • The other people you need are there to keep you engaged and to tell you when you're wrong.
  • You also learn to back out stuff until it is right. This is easier said than done as people become vested in the code they've written and needing to back it out becomes more painful for everyone.

The OpenBSD community has a reputation of being very blunt and direct. They don't sugar coat anything or worry about hurting anyone's feelings. They don't have time or patience for such niceties. Outsiders or people new to OpenBSD often get the wrong impression with OpenBSD's no nonsense approach to communication. The developers know, respect and have a bond of understanding to facilitate very fast and direct communication.

Here's what beck@ had to say about c2k10:

What I did at c2k10: (hacking wise, as opposed to organising, cat herding, and food aquiring...)

p1040013s As I mentioned hackathons are places for starting or finishing things. I started two major things that are now nearing good stuff:

1) I rewrote the NFS server side attribute cache to use a RedBlack tree and timeouts on the requests. So far I want to tune this a little more but this is looking promising on my NFS servers. A version of this or something based on it is likely to be committed post 4.8 - Basically this is to address a problem we have running UDP NFS on servers where replies missed by clients cause errors. A cache that is both larger but more intelligently implemented than the current one will resolve these issues that I've been able to hit torturing NFS servers at home.

p1030553s
2) Along with Art and Owain who worked on some of the other pieces, I spent most of my time working on splitting the buffer cache into two LRU queues for buffers, tracking both buffers that are DMA reachable on a machine (using the new UVM pmemrange code) and elsewhere - the goal here is to allow pages to be flipped into "high" memory when only being read from, but allocated initially in DMA reachable regions, and moved into DMA reachable regions if IO is needed to be done from them. In the process, I tracked down a number of bugs. By the end of the hackathon, I successfully had an 8 GB AMD64 running with bigmem using 6 GB of buffer cache. My work still has some bugs I'm working out (with lower memory machines) but I'm confident I'll be able to get that sorted out relatively soon.

Bob Beck

Bob said hacking on file systems is a nightmare. If you break it, everyone notices and you hear about it. Changes must be carefully designed, planned and tested, with the implementation being done incrementally to always keep everything running correctly. The improvements currently being made on the file systems are very interesting and innovative. The multistage development process started during c2k10 with the design and planning bits being completed and first steps towards implementation being committed. When the time comes, we'll do an undeadly article specifically on file system improvements.

I would like to thank beck@ once again for hosting the general hackathon every year in addition to all of his coding. His efforts organizing the general hackathon enable the developers to get together at least once a year to have fun improving OpenBSD, so he is one of the main reasons the project keeps moving forward. Of course, your donations and financial assistance make the hackathons possible. Thank you for your continued support.

Mark T. Uemura

(Comments are closed)


Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]