Slashdot Mirror
Mountain Biking Helps Squash Bugs
Dr.Milius writes "Henning Brauer of the OpenBSD project recently made an interesting post to the openbsd-tech mailing list about how a mountain bike ride helped him relate two baffling bugs in their new BGP and NTP daemons. It turns out they were both off-by-one errors that were easy to fix but notoriously difficult to spot. Always great when the experts show us how it's done."
Ah, the openntp daemon. That program that always says that it is stratum 2, potentially creating loops (that is a bad thing).
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
Ride the fucking bicycle.
if you can't figure it out, stop trying so damn hard and just do something else.
I wonder what effect a road bike would have upon bugs? I mean, one could go faster in the flats where bugs are likely to reside, but at the same time, wider tires would allow one to run over more ants. Oh, the dillemmas!
This is something well known to work. It's not the bike riding, it's the act of "taking a break from the problem." Think back to the origins of "Eureka!"
I, for example, will often go grab a Coke, talk to people, etc, and somewhere along the line, by _not_ focussing so hard on the problem, I come up with the answer.
Error 407 - No creative sig found
It is ironic that people, on the one hand, fool themselves into thinking that these things don't happen to them, and on the other hand, have to go off bug hunting for days to find "baffling bugs". How much more productively could that development time have been spent?
Face it, memory corruption bugs, off-by-one-errors, and all that, happen to even the most experienced and careful programmers. The way to deal with them is to use programming languages that detect them reliably. In different words, we need to retire C or fix C.
And, no, "retiring C" doesn't mean switching to Java or C#. Instead, it means switching to a systems programming language that has error checking by default but still gives you all the low-level features you need when you need them. There have been a number of such languages over the years, but, unfortunately, they were all killed by C, not because C was better, but because C shipped with UNIX.
Do your patriotic duty! http://www.savebetamax.org/
Every developper knows that... ;)
It happened to each of us, no need to be an expert or something: the bug drives you nuts, and you end up saying "fsck that" and go out, totally out of ideas. Then you smoke your cigarette of whatever, or go for a walk. And because you've sort of given up, you start to look at the problem in a different way, probably also because you're not in front of your screen and your brain is more "free", you realize that there are some obvious things that you didn't checked... And 5 minuts later, there is no more bug. That's why i go out to smoke a cig every hour (well not really, but still, it's a nice excuse
Besides, if you look at the well known "eureka" moments, it seems they all happened when the person was relaxing. Maybe we should be forced to relax each time we're facing an intellectual difficulty, really...
Sometimes cracking your head open works, sometimes a quick ice cream run works, and sometimes a 6 month (year) hiatus works. Either way, it eventually works.
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be the Amazing Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save *BSD at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dead
Hmm. Well, I did figure out how I wanted to implement a portion of my code when I was taking a crap recently.
List: openbsd-tech
Subject: Re: Anatomy of a bug
From: br1an
Date: 2004-09-10 11:28:02
Message-ID:
so basically what you're saying is that we have some fuck who can't
code for shit - proven across two daemons you wrote - commiting code
both to the userland and kernel of an OS we all rely on for various
missions?
great... thanks for keeping us posted.
-b.
Extremely well-said.
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It
On the food aspect, whenever I run into coding problems, I go bake cookies. Helps if you have a near by oven and supply of dough, of course, but it gives you a good 30 minutes to stop and focus on something else. I usually end up pacing around while they bake, looking out the windows, looking around the kitchen, and more oft than not have a viable solution in addition to some fresh cookies when I go back to coding.
"An infinite number of monkeys typing into GNU emacs would never make a good program."
Extremely commonplace sort of phenomenon. You work on some problem really hard, then at some point where you're not working on it, the solution comes in a flash. Happened to me last week with a mysterious bug.
Are you adequate?
I was wondering if this is the kind of thing that most likely would ahve been avoided in a more "modern" language, like pointer arithmetic problems could be avoided by not using C? Not a trool -really- I was just wondering. I RTFA but can't tell from reading it...
Your CPU is not doing anything else, at least do something.
I often find that the bugs that are most difficult to find are the easiest to fix. They are often some tiny corner case in one line of code that someone never thought of.
In the last product I worked on, we had a killer crash bug that different developers spent WEEKS investigating it, giving up, and then "hot potatoing" the bug to another developer. About two months later, I finally fixed the bug. A BSTR allocated using SysAllocString() should have been freed using SysFreeString(), but it was being "freed" using COM's CoTaskMemFree(). This would corrupt COM's heap causing random COM crashes in unrelated code much later!
cpeterso
The tools are there, why not use them. Or just use java.
Yes! This can make tweaking your overall algorithm or approach so much easier as well, if these wrapper functions are there, and well defined in their actions. You can never have *too short* a function!
VOS/Interreality project: www.interreality.org
The most productive breaks for me are those that force oxygenated blood to my brain, e.g. running, hiking, biking, etc. Of those, the best are the ones that don't require concentration but allow the mind to wander freely.
I guess that means that there is actually a Bikeshed. Who would have figured? And I thought that it was just proverbial...
The views expressed are mine own and do not express the views of my employer.
This is news?
In any other field you would be correct. But this is *BSD, where the common way to deal with a problem is to throw a tantrum on some mailing list and tell people to STFU.
He actually calmly went and did something else! This is a light year leap in *BSD related psychology, hence deserves its own news item.
Can we get original?
I am tired of the C language bashing. If a programmer is diligent in coding and tests the code thoroughly, then there are fewer bugs. "A poor workman blames his tools." Programming in C is not for sissies. The problem is the same fool can really screw up a C program but only moderately mess up a java program. Lesson: Have the fools program in java.
The first thing he does is immediately blame the hardware - before even looking at it!! Wish I was that l33t!
Neither of those would have helped dipshit, learn to read or shut that big gaping hole that stupidity constantly pours out of. It was a ref count off by one, no magic compiler or dev "safety" tools would have caught it.
...would have found this immediately.
use it.
I beleive that the hackers dictionary calls these Obi Wan Errors.
What about the bugs between your teeth on such a bike ride?