Contributed by mtu on from the surfs-up dept.
In all of my interviews at c2k10, there were many things that kept coming up over and over again. One of those things was the release of 2.7 in June of 2000 and 2.8 in November. It was a period when many of the developers, tedu@ included, started to use OpenBSD. There is a reason for these two releases being so popular and a tipping point, so to speak, that attracted many thereafter.
Read on to find out more about tedu@ and learn what this attraction was all about:
Back in those days, there were massive security holes found in all operating systems. Oh wait! Things haven't changed other than there are more attack vectors that lead to the same thing. OpenBSD's security efforts and focus on correctness (see presentations in 1999) started to pay dividends in the following year in the form of new users and developers with similar security concerns.
A college friend knew that tedu@ was interested in exploring the UN*X world and recommended that tedu@ try OpenBSD. He even facilitated that interest by giving him a 2.7 Release CD. Since then he has contributed a lot to that security effort when he became a developer in March of 2003 after being invited by Artur Grabowski (art@). He worked on file system bugs, virtual memory performance, took part in another huge security auditing effort that replaced all the strcpy and similar functions in userland, and then worked on crypto support and more recently rthreads. tedu@ said that his involvement with this developer community has always been fun and the hackathons were always a big part of that fun.
When I first saw tedu@ at c2k10, my first impression was that perhaps he made it to the wrong beach party and just left his surfboard outside out of courtesy. Well, the reality is, he looks just as cool with a laptop in hand as he would with a surfboard. You may be interested in knowing that tedu@ also works for a pretty cool company called Fog Creek Software based in New York City, far away from any good surfing beach that I am aware of. There are an incredible amount of articles written by Joel Spolsky, his boss, that are very interesting and informative. One in particular caught my attention: The Joel Test: 12 Steps to Better Code. After reading that, I just had to put OpenBSD to the test.
I'm not sure that the test was designed to be used on operating systems and maybe it's not quite fair to OpenBSD as this is really such an extreme case. An Operating System is non-trivial software and I am using an Open Source OS to boot. Well, despite the odds, I was pleasantly impressed with the results. OpenBSD has been putting out a product every six months since June 1997! Snapshots are created almost daily going back to 1995. If that wasn't impressive enough, OpenBSD is in a league of its own in terms of their security track record. Oh, and as Bret Lambert (blambert@) would say, "the developers enjoy removing 20 odd years of bad Californian ditch weed from the kernel" and they seem to have fun adding functionality too. Appropriately enough, the c2k10 hackathon T-Shirt theme was "Turd shining".
There was something else that I learned at the BBQ when speaking with tedu@: at his day job, he works on Windows applications. What's special about that you ask? Well when you read this article, The Perils of Java Schools, it all comes together. We all know that tedu@ is a hard core OpenBSD kernel developer but it was through this article by Joel Spolsky and talking to tedu@ that I realized that C programmers can easily learn to program in other languages but going from Java or VB to C may not be so easy. I'm a good example of the latter. I started off programming in Windows and I still can't program in C to save my life. Fortunately, I have a lot of good C programming mentors to help me when I get stuck. Henning Brauer (henning@) also says that OpenBSD is one of the best communities to learn C. Should you want to dip your toes a bit then style(9) is a good place to start.
Here's what tedu@ had to say about c2k10:
I spent most of the hackathon deleting files, many relating to various binary compatibility layers. The primary motivation to removing them is to reduce the number of files that need auditing and editing when making some of the big rearrangements we have planned for improved threading support. While the concept of running programs compiled for other operating systems is appealing and probably helped the early adoption of OpenBSD, the accuracy of many compats is uncertain, and there's been very little interest in testing or maintaining them. Not all of the compat code will be deleted at this time, but facilitating the continued use of proprietary programs is not, strictly speaking, in line with the project's goals.
The introduction of mandoc(1) also revealed that one of the last required uses of groff was to build various extra documentation. Much of this was outdated and could also be deleted. We're still not sure what to do with the rest of the docs long term, but narrowing down the candidate set will help later.
In terms of new code, I am investigating new ways to arrange the userland address space, particularly on i386. Various segments of the address space are sized and located according to the #defines in $arch/include/vmparam.h. Our current layout policy generally reserves space for each segment, even if it's not being used. One area is the traditional heap area used by the brk system call. From man brk(2): "The brk(2) and sbrk(2) functions are historical curiosities left over from earlier days before the advent of virtual memory management." OpenBSD rarely uses the brk(2) call, almost exclusively using mmap(2) instead (or malloc for most programs), but still reserves space for it. This has the unfortunate effect of limiting the space available to mmap(2). We could reduce the size of this reservation, but there are, well, "historical curiosities" still in use today. The goal is that with a little shuffling of the uvm code, we can allow brk(2) and mmap(2) to coexist and overlap more efficiently. Of course, i386 itself is soon to be a historical curiosity, but I suspect people will be using it, and hoping to get the most of out its limited address space, for years to come.
I also spent a day working out a new method of cpu throttling. We have for many years exposed a hw.setperf sysctl that presents an abstract means of controlling cpu frequency (and hence, power and heat). We also have an option in apmd that monitors system load and adjusts the speed in response. There are two well known problems with the existing solution. First, the current algorithm doesn't account for mulitple cores very well. Second, the polling interval is a little slow. While it works well for long tasks like compiling, interactive tasks like scrolling a browser feel sluggish. Your cpu doesn't get kicked into high speed until after the operation is already done. Frequent polling from userland is a problem because it creates additional load itself (observer effect!).
To solve this problem I moved the adjustment code into the kernel, so we can run it frequently without incurring the cost of multiple userland/kernel switches. We're also tweaking the algorithm to be a little more responsive to each cpu. While the current patch uses the same information available to apmd, another advantage of moving this code into the kernel is possibly tighter integration with the scheduler in the future. For instance, one can imagine a scheduler that immediately switches the cpu into slow mode whenever it runs the idle loop.
Well, what can I say, aren't you glad that tedu@ prefers hacking on his holidays than surfing the Hudson River! He's been a favourite of mine over the years reading misc@ and I was happy to finally meet him in person. He's done some great work and is a true inspiration to me and many others. Thank you very much for your great and continued contributions to OpenBSD. I hope that others are now either inspired to try submitting patches and/or at the very least submit a donation as a small contribution to help support upcoming (mini-)hackathons. We appreciate your support and consideration.
(Comments are closed)