Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mountain Biking Helps Squash Bugs

timothy posted more than 9 years ago | from the so-do-big-grins dept.

Bug 82

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."

cancel ×

82 comments

Sorry! There are no comments related to the filter you selected.

openntp (-1, Troll)

flok (24996) | more than 9 years ago | (#10228750)

Ah, the openntp daemon. That program that always says that it is stratum 2, potentially creating loops (that is a bad thing).

RTFB (5, Funny)

Anonymous Coward | more than 9 years ago | (#10228753)

Ride the fucking bicycle.

Re:RTFB (1)

Tagren (715283) | more than 9 years ago | (#10233786)

Innovation.

really stupid (0, Troll)

BillyBurrito (312277) | more than 9 years ago | (#10248645)

Can we get original?

Re:really stupid (2, Funny)

sgant (178166) | more than 9 years ago | (#10279236)

sheesh, lighten up...

Re:really stupid (2, Insightful)

BillyBurrito (312277) | more than 9 years ago | (#10280808)

ok

works for anything (3, Insightful)

Anonymous Coward | more than 9 years ago | (#10228791)

if you can't figure it out, stop trying so damn hard and just do something else.

Re:works for anything (1)

nusratt (751548) | more than 9 years ago | (#10228839)

"if you can't figure it out, stop trying so damn hard and just do something else"

Ditto.
This is news?
EVERY half-decent dev or tech has these kinds of down-time epiphanies.
(For me, it's the shower and commuting.)

This IS news (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10246683)

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.

Re:works for anything (1)

GoksinAkdeniz (651310) | more than 9 years ago | (#10233981)

I do agree! Better step aside and rest than drowning a sea of problems! :)

road bike.. (5, Funny)

MoOsEb0y (2177) | more than 9 years ago | (#10228794)

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!

Re:road bike.. (1)

JMS-Web (662292) | more than 9 years ago | (#10236290)

wider tires would allow one to run over more ants. Oh, the dillemmas! And running over ANT is good? I thought it was all about the Bugs.

This is news? (4, Informative)

agent dero (680753) | more than 9 years ago | (#10228844)

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.

Re:This is news? (1, Flamebait)

ezzzD55J (697465) | more than 9 years ago | (#10228919)

Indeed.. Experts? Show us how it's done? The guy may very well be a guru, but this story isn't evidence of it.. Although it's always easy to comment from the sidelines (and with 20/20 hindsight), the guy says it himself:
when maintaining counters for list/queue/... entries, don't fuck with either the counter or the list directly anywhere; use wrapper functions that take care for both (not using a counter/list pair is not an option in many, including these two, cases). Not that this is really news, but very well worth recalling...
No kidding it's not news not to fuck with abstractions, that's the fucking point!

Re:This is news? (0, Flamebait)

ezzzD55J (697465) | more than 9 years ago | (#10257218)

Flamebait? Overrated? May the metamods roast you moderators for this.

Re:This is news? (4, Insightful)

Anonymous Coward | more than 9 years ago | (#10229576)

Many of the problems I deal with, I get that Eureka moment while on the toilet.

Re:This is news? (1)

bigbadbuccidaddy (160676) | more than 9 years ago | (#10314019)

That is just because those are the most common breaks you take from work. I work really well when I'm hungover and have to take more frequent bathroom breaks.

Re:This is news? (1)

bhima (46039) | more than 9 years ago | (#10232899)

I find that I have to get much further from the problem, in fact it happens to me so often that I hike with an ultra-portable, just in case.

Re:This is news? (4, Funny)

c13v3rm0nk3y (189767) | more than 9 years ago | (#10234932)

It's not the bike riding, it's the act of "taking a break from the problem."

I'll second that. I do some of my best coding in the bathtub, sans the dangerous electronics, of course.

not difficult to spot at all (5, Insightful)

jeif1k (809151) | more than 9 years ago | (#10228862)

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.

Re:not difficult to spot at all (4, Informative)

Homology (639438) | more than 9 years ago | (#10228958)

The OpenBSD developers does not fool themselves into thinking that they don't make mistakes. Several of the techniques they use, like privilege revocation and privilege separation is to lessen the impact of programming mistakes, including their own. Theo de Raadt recently gave a talk on Exploit Mitigation Techniques [openbsd.org]

As for not using C, I've read that Theo de Raadt likes the compiler and language that is used in Plan 9 [bell-labs.com] . Can't use it due to license problems, though.

Re:not difficult to spot at all (1)

jeif1k (809151) | more than 9 years ago | (#10229045)

As for not using C, I've read that Theo de Raadt likes the compiler and language that is used in Plan 9. Can't use it due to license problems, though.

You mean Alef? I don't think there are licensing problems with the language, and writing a compiler for it wouldn't be hard. I'm not convinced, though, that Alef is a good systems programming language.

But safer systems programming languages are a dime a dozen, people just have to use them.

Re:not difficult to spot at all (4, Informative)

Homology (639438) | more than 9 years ago | (#10229216)

Most likely the C-dialect compiler that Plan 9 uses. But the AT&T license is too restrictive for Plan 9 code to be imported into BSD, as far as I know.

Re:not difficult to spot at all (2, Interesting)

jeif1k (809151) | more than 9 years ago | (#10234039)

The C dialect in Plan 9 is not very different from ANSI C; it doesn't address safety or security issues. Alef, on the other hand, looks pretty similar to C, but I believe is considerably safer than C.

Re:not difficult to spot at all (3, Informative)

ufnoise (732845) | more than 9 years ago | (#10229776)

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.


There are debugging tools out there which reliably find these bugs in C/C++ and FORTRAN. For example:
purify (not free)
valgrind (free)

Tools such as these help to find problems, while avoiding the inefficiency of array bounds checking on each access.

Re:not difficult to spot at all (5, Insightful)

Xenophon Fenderson, (1469) | more than 9 years ago | (#10230814)

How is bounds checking inefficient if it protects you from nasty off-by-one errors and evil buffer overflows? Or are you one of those short-sighted programmers who believes cheap CPU clock time is more important than very expensive human time (i.e. time wasted dealing with crappy programming languages and debugging stupid bounds problems, or worse, money lost because a critical bit of information was destroyed, altered, or disclosed due to a buffer overflow vulnerability)?

And yes, those were both rhetorical questions. I am sick and tired of crappy, bug-ridden software that doesn't do proper input and bounds checking. As far as I'm concerned, it's the programmers fault, either because she didn't write the bounds checks in manually or because he's not using a modern programming language (where "modern" == "not a glorified assembler"). You all aren't Mel, who can write practically perfect programs while sleepwalking, so don't give me a load of crap about how bloated your program would be if it was actually written properly. As a computer security guy, I am sick and tired of cleaning up after the exploits you all apparently work so hard to code into your software.

</rant>

Re:not difficult to spot at all (0)

Anonymous Coward | more than 9 years ago | (#10231148)

You can run all your programs under Valgrind if it concerns you that much. I can't even recall the last time I've had a memory leak/overrun, thanks to Valgrind and strlcat/cpy().

Re:not difficult to spot at all (0)

Anonymous Coward | more than 9 years ago | (#10244273)

Valgrind won't spot all overruns/underruns -- only those on the heap, not those on the stack or in static memory.

Re:not difficult to spot at all (1)

ufnoise (732845) | more than 9 years ago | (#10231226)

You are right. It is the programmer's fault. But it is also the programmer's fault if the program is so inefficient, it is useless. You would then be complaining about how slow the program is, rather than about the exploit. I don't know who Mel is, but I assume he has debugging tools which would allow him to diagnose the errors found in this article. In addition, there is no reason array bounds checking could not be performed in debug versions of the code, but left out of the final optimized version. As far as all this stuff about security, it did not appear that the off by 1 error would have resulted in a security exploit, but a crash. The security exploits you worry about have been reduced with the advent of additional functions in the C standard library which make sure that strings cannot overrun their buffer.

Re:not difficult to spot at all (2, Informative)

setagllib (753300) | more than 9 years ago | (#10232695)

Mel: http://www.catb.org/jargon/html/story-of-mel.html

No debugging tools there, if any tools at all.

Re:not difficult to spot at all (4, Insightful)

tedu (647286) | more than 9 years ago | (#10233034)

have you used purify/valgrind? as far as "avoiding the inefficiency of array bounds checking on each access" they pretty much suck. performance is nowhere close to what could be considered "production" level.

Re:not difficult to spot at all (2, Informative)

ufnoise (732845) | more than 9 years ago | (#10233087)

Yes I have. I only use them when I am debugging. Then I don't need to implement array bounds checking on the "production" version of the code.

Re:not difficult to spot at all (1)

insulanus_hailstorm (804238) | more than 9 years ago | (#10300502)

have you used purify/valgrind? as far as "avoiding the inefficiency of array bounds checking on each access" they pretty much suck. performance is nowhere close to what could be considered "production" level.

This is only because the C runtime does not help in this regard. This can be done very efficiently in other environments.

Re:not difficult to spot at all (1)

jeif1k (809151) | more than 9 years ago | (#10234082)

There are debugging tools out there which reliably find these bugs in C/C++ and FORTRAN.

No, they don't find them "reliably", they only find them if you happen to have a test case that triggers the bug and you run the software under valgrind or purify when you execute the test case. For security problems arising from buffer overflows, the probably is usually that developers don't even think of the case.

Tools such as these help to find problems, while avoiding the inefficiency of array bounds checking on each access.

The "inefficiency" of array bounds checking is a few percent in real code, hardly a big cost. But it's wrong to look at that cost by itself anyway--the question is: if you don't have array bounds checks in the compiler, what are you going to do instead? And pretty much everything you are going to do instead is going to be much more costly. Using languages in which unsafe array access are the default is penny wise and pound foolish.

And in really performance critical code, you can selectively turn it off in most languages.

Re:not difficult to spot at all (2)

jeif1k (809151) | more than 9 years ago | (#10237280)

Yes, if you use C++ with a decent class library and good programmers, you get good runtime safety. The problem with C++ is that if you have a large project with lots of ex-C programmers, they sneak in unsafe code everywhere and usually don't even understand that they are doing so.

Nevertheless, it would probably be a big step forward if Linux and BSD allowed C++ code in the kernel.

Re:not difficult to spot at all (2, Informative)

Profound (50789) | more than 9 years ago | (#10232276)

You can use use C++ STL vectors with at() when you want bounds checking or use a direct index when you don't. Thus you can keep the backwards compatability with C and have the choice of sacrificing safety for speed when you need it.

Re:not difficult to spot at all (0)

Anonymous Coward | more than 9 years ago | (#10234537)

You can use use C++ STL vectors with at() when you want bounds checking or use a direct index when you don't. Thus you can keep the backwards compatability with C and have the choice of sacrificing safety for speed when you need it.

That's the ticket. C++ offers (almost) everything that C does, plus some high-level stuff that keeps you from having to write "glorified assembler" all the time, so let's start using it!

Re:not difficult to spot at all (1)

gokeln (601584) | more than 9 years ago | (#10235126)

The biggest problem I have with the STL is that many debuggers don't have nice support for it. Thus, it's very difficult to observe what's stored in that nice vector or tree, when you hit the breakpoint. A few newer ones are adding automatic display of STL structures, which will be very nice, but for now, I'm stuck with VC++6, which is horrendous WRT these kinds of data structures.

I'd certainly welcome any ideas people have on how they actually debug code using the STL.

Re:not difficult to spot at all (4, Insightful)

tedu (647286) | more than 9 years ago | (#10233049)

no amount of "error checking" would have helped. this wasn't a buffer overflow off by one. it was ref count.

yeah, garbage collection would help, but C with GC is not a "systems programming language with error checking".

Re:not difficult to spot at all (1)

jeif1k (809151) | more than 9 years ago | (#10237079)

Same problem: C is a language that makes it difficult to write correct code, for numerous reasons.

A systems programming language with error checking needs to handle both automatic storage management and array bounds checking (plus a few other compile-time and runtime tests that are missing from C). Users should also be able to turn off either/both selectively and explicitly.

Re:not difficult to spot at all (1)

chaos_echo (792310) | more than 9 years ago | (#10237069)

... 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.

I don't think you understand the "low-level" appeal of C, error checking and other useful security features like strong typing are not low-level. The ability to break abstractions and treat memory as memory instead of data is both the cause of C's problems and the force behind C's use. The problem isn't C being included in Unix (dozens of languages are included in most modern Unix environments), the problem is that C is genuinely useful for the same reasons that it is hard to secure.

Re:not difficult to spot at all (1)

Mr. Slippery (47854) | more than 9 years ago | (#10240281)

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.

The best check for such errors is other eyeballs.

It's not the language. It's development procedures. Code reviews will catch these things, and other bugs besides (as well as making people write neater, more easily understandable code, and giving coders and opportunity to learn from each other), but reviews take development time - never mind all the time they save in debugging and maintenance, management cares only about that ship date.

bounds checking gcc... (1)

bani (467531) | more than 9 years ago | (#10279282)

...would have found this immediately.

use it [nl.net] .

SAVE BETAMAX! (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10228886)

Do your patriotic duty! http://www.savebetamax.org/ [savebetamax.org]

Not new... (2, Insightful)

HawkingMattress (588824) | more than 9 years ago | (#10228912)

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...

Re:Not new... (1)

lphuberdeau (774176) | more than 9 years ago | (#10229360)

I guess everyone has it's own way of taking... fresh air. Depending on the time of the day, I do different things.

If it's the second half of the afternoon,
I just go back home.

During the evening,
Off for a beer.

Any other moment,
Walk, coffee or walk to coffee...

And yes, it does work. I usually find my bugs within 10 minutes after sitting back to my desk, which obviously includes reading slashdot.

Re:Not new... (1)

mattgorle (807823) | more than 9 years ago | (#10229668)

Very well, I order you to relax!

Re:Not new... (1)

vrt3 (62368) | more than 9 years ago | (#10233751)

Another thing that helps is explaining the problem to someone else. It also makes you look at the bug from another point of view, and very often you find the solution without the other person even saying a word.

Re:Not new... (2, Funny)

bondjamesbond (99019) | more than 9 years ago | (#10239856)

...and having sex works well - if you can get it, that is.

Re:Not new... (1)

Gauchito (657370) | more than 9 years ago | (#10246144)

Something that I have found to be very, very useful is describing the problem to somebody else. Just having to reorder your thoughts about the issue in order to get the message across puts everything in a different light. Plus, you consider things that your brain usually just skips over without a second thought. I can't count how many times I've been telling a coworker about a problem and halfway through the explanation it hits me ("Well, then when we're iterating through the list the code... Oh, crap, found it.").

Re:Not new... (1)

fgb (62123) | more than 9 years ago | (#10265523)

Usually, if I'm working on a problem late at night, I find it more productive to just go to sleep. You wouldn't believe the number of times I've woken up in the morning with the solution being blindingly obvious to me.

Re:Not new... (1)

HawkingMattress (588824) | more than 9 years ago | (#10266064)

Yes me too. The only problem is that even if i know this, usually when i'm coding at night i'm "zoning", in a state which pushes me to go on. So i'll search a solution for several hours generally for nothing, and i'll discover in the morning that I was doing stupid obscure things while the solution was indeed obvious...
I'm now trying to restrain myself from doing this, as sometimes you can furthermore do stupid things which will cause you to spend even more time later on, solving problems which should have never been here. Never do too much of one thing, they say... so true.

Yup. (0)

Anonymous Coward | more than 9 years ago | (#10228976)

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.

Bake Cookies! (4, Interesting)

maskedbishounen (772174) | more than 9 years ago | (#10231012)

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.

Re:Bake Cookies! (1)

drinkypoo (153816) | more than 9 years ago | (#10242165)

This also provides the side benefit that you can tell how good someone's code is the first time by how fat they are...

*BSD is dying (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10229052)

It is now official. Netcraft confirms: *BSD is dying

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 [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin [amazingkreskin.com] 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

taking a crap (4, Funny)

endx7 (706884) | more than 9 years ago | (#10229421)

Hmm. Well, I did figure out how I wanted to implement a portion of my code when I was taking a crap recently.

Re:taking a crap (4, Funny)

r_j_howell (519954) | more than 9 years ago | (#10234847)

I had a good friend at school remark to me that ALL his best programming ideas came to him in the bathroom. Mine generaly don't. But you couldn't tell that from looking at some of the stuff I've churned out.

Re:taking a crap (0)

Anonymous Coward | more than 9 years ago | (#10251345)

core dump, anyone?

Re:taking a crap (0)

Anonymous Coward | more than 9 years ago | (#10254206)

As opposed to "memory" leak?

I found the first reply most revealing (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#10230011)

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.

Re:I found the first reply most revealing (0)

Anonymous Coward | more than 9 years ago | (#10234748)

Hey, that IS the first reply. Now that is funny!

Developer laments: What Killed FreeBSD (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10230142)

The End of FreeBSD

[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's when you get distracted by the politickers that they sideline you. The tireless work that you perform keeping the system clean and building is what provides the platform for the obsessives and the prima donnas to have their moments in the sun. In the end, we need you all; in order to go forwards we must first avoid going backwards.

To the paranoid conspiracy theorists - yes, I work for Apple too. No, my resignation wasn't on Steve's direct orders, or in any way related to work I'm doing, may do, may not do, or indeed what was in the tea I had at lunchtime today. It's about real problems that the project faces, real problems that the project has brought upon itself. You can't escape them by inventing excuses about outside influence, the problem stems from within.

To the politically obsessed - give it a break, if you can. No, the project isn't a lemonade stand anymore, but it's not a world-spanning corporate juggernaut either and some of the more grandiose visions going around are in need of a solid dose of reality. Keep it simple, stupid.

To the grandstanders, the prima donnas, and anyone that thinks that they can hold the project to ransom for their own agenda - give it a break, if you can. When the current core were elected, we took a conscious stand against vigorous sanctions, and some of you have exploited that. A new core is going to have to decide whether to repeat this mistake or get tough. I hope they learn from our errors.

Future

I started work on FreeBSD because it was fun. If I'm going to continue, it has to be fun again. There are things I still feel obligated to do, and with any luck I'll find the time to meet those obligations.

However I don't feel an obligation to get involved in the political mess the project is in right now. I tried, I burnt out. I don't feel that my efforts were worthwhile. So I won't be standing for election, I won't be shouting from the sidelines, and I probably won't vote in the next round of ballots.

You could say I'm packing up my toys. I'm not going home just yet, but I'm not going to play unless you can work out how to make the project somewhere fun to be again.

= Mike

--

To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt

*yawn* (2, Insightful)

Estanislao Martnez (203477) | more than 9 years ago | (#10231592)

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.

Would a more modern language madea difference? (1)

CaptainPinko (753849) | more than 9 years ago | (#10232794)

It turns out they were both off-by-one errors that were easy to fix but notoriously difficult to spot

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...

Re:Would a more modern language madea difference? (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10233222)

It was not a "pointer arithmetic" problem, it was a counter problem. You don't even need a computer for that to happen, try counting the runners passing the finish line at a marathon... Miss one, and you'll be waiting forever for the last guy to come in.

Re:Would a more modern language madea difference? (1, Insightful)

NickHolland (91075) | more than 9 years ago | (#10235185)

Curiously, the people who know OSs the best have been sticking with C. The people talking about "modern languages" have been mostly doing just that: talking. The fact that nothing has been done beyond "talk" says more then all the talk.

Someone who believes this can be done has to prove it by reimplementing an existing OS in one of these "modern languages", and demonstrate that it is maintainable, performs sufficiently, and actually works better than a C implemented OS. Implementing a "whole new" OS isn't going to work, as the barriers to entry in this business are just too high -- you would have to implement an entire software library as well. And note: having to have a multi-processor P4 or AMD64 to do what is currently done with a Pentium 90 isn't going to fly...

I really doubt any programming language can make programing "intrinsically safe". In fact, if past experience is any guide, it would probably lower the bar to entry into OS programming, and probably end up with a net REDUCTION in quality. All it takes to prove me wrong is ...well, do it. :)

Re:Would a more modern language madea difference? (1)

Ashtead (654610) | more than 9 years ago | (#10244312)

Off-by-one errors are possible in almost every language. Wherever there is some kind of list or set of objects, however expressed, there is the potential for such an error. The actual implementation language doesn't matter here.

Re:Would a more modern language madea difference? (1)

norkakn (102380) | more than 9 years ago | (#10245942)

System programming is done with C because it is a pretty lcean abstraction away from the hardware. Assembly is the cleanest, but C maps pretty well onto assembly that maps pretty well onto what the processor actaully implements.

This is important because the programmer has some idea of what the program is actaully doing, and a good programmer has a great idea of what the program is actually doing.

Anything that is pretty close to the hardware should be done in C or soemthing similar. Computers have been fucked up enough by people who don't actually realize how computers work and just right code that works rather than being sleek or taking advantage of the tasks that computers are good at.

As a hardware person, any time someone talks about using higher level languages for system programming, it makes me want to go postal.

hard-to-find bugs are often the easiest to fix (2, Interesting)

cpeterso (19082) | more than 9 years ago | (#10232908)


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! :(

Re:hard-to-find bugs are often the easiest to fix (2, Interesting)

Detritus (11846) | more than 9 years ago | (#10233882)

This class of bug, and some others, can be prevented if the free routine checks the to-be-freed memory chunk for validity. I've done this in some embedded systems by setting a hidden magic number in each memory chunk that is allocated. The free routine checks for the magic number before it touches it. If the magic number isn't there, it generates an alarm message and returns an error code to the caller. Unique magic numbers can be used for each class of buffer, and to indicate whether the buffer is free or in-use.

Re:hard-to-find bugs are often the easiest to fix (1)

darweidu (530107) | more than 9 years ago | (#10251747)

If you're on windows using MS tools, you can get your compiler to do this automatically. Why reinvent the wheel?

http://msdn.microsoft.com/library/default.asp?url= /library/en-us/vsdebug/html/vchowRuntimeChecksAPI. asp [microsoft.com] Only in debug mode, of course.

Re:hard-to-find bugs are often the easiest to fix (1)

Detritus (11846) | more than 9 years ago | (#10252083)

Not everyone is using MS tools.

Only in debug mode, of course.

I've never understood this philosophy. Let's put lots of error checks and consistency checks into the system, then rip them all out when we ship the software or transfer it to operations.

If it doesn't have to be correct, we can make it run as fast as you like.

Valgrind and/or GCC boundschecking (1)

Bluelive (608914) | more than 9 years ago | (#10233965)

The tools are there, why not use them. Or just use java.

You are a moron. (0)

Anonymous Coward | more than 9 years ago | (#10277807)

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.

Yes! (2, Informative)

agentk (74906) | more than 9 years ago | (#10234962)

First, when maintaining counters for list/queue/... entries, don't fuck with either the counter or the list directly anywhere; use wrapper functions that take care for both (not using a counter/list pair is not an option in many, including these two, cases).

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!

Just taking a break is helpful, but ... (1)

Dr. Mu (603661) | more than 9 years ago | (#10243177)

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.

Hummm.... (2, Funny)

utlemming (654269) | more than 9 years ago | (#10243760)

I guess that means that there is actually a Bikeshed. Who would have figured? And I thought that it was just proverbial...

Lazy programmers produce bugs (-1, Troll)

samberdoo (812366) | more than 9 years ago | (#10249456)

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.

You're missing the best part!! (-1)

Anonymous Coward | more than 9 years ago | (#10249829)

The first thing he does is immediately blame the hardware - before even looking at it!! Wish I was that l33t!

Off by one error (1)

pcjunky (517872) | more than 9 years ago | (#10330243)

I beleive that the hackers dictionary calls these Obi Wan Errors.

Bugs? (0)

Anonymous Coward | more than 9 years ago | (#10335537)

What about the bugs between your teeth on such a bike ride?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>