Why OpenBSD's Release Process Works
An anonymous reader writes "Twelve years ago OpenBSD developers started engineering a release process that has resulted in quality software being delivered on a consistent 6 month schedule — 25 times in a row, exactly on the date promised, and with no critical bugs. This on-time delivery process is very different from how corporations manage their product releases and much more in tune with how volunteer driven communities are supposed to function.
Theo de Raadt explains in this presentation how the OpenBSD release process is managed (video) and why it has been such a success."
Basically, they only allow developers who are willing to sit through a 30-minute video to work on their software.
I am the richest astronaut ever to win the superbowl.
but at least he is stubbornly consistent. Without it, openBSD would not exist in its current fine form.
That video can serve as a lesson to others on how to manage a project for an extended period of time and keep things consistent and predictable.
Feed the need: Digitaladdiction.net
While OpenBSD does have an outstanding security record, with good design & separation of privileges, they aren't perfect.
As they say on their website, "Only two remote holes in the default install, in a heck of a long time!"
Its not a success until Netcraft confirms it.
Taxation is legalized theft, no more, no less.
The slides are here: http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/
What I got out of it was that the core developers, not some other group, do the testing. Rather than hand the task of quality control/testing to some other group just prior to release, all developers are held to a high level of participation in this regard. Theo and other developers use nightly builds in their day-to-day work and the entire system compiles most every night.
Is it possible to slashdot youtube? I tried to watch but the video had these annoying pauses...
you should try a recent version (like the 4.6-current snapshots)
compatibility with most PC hardware is very good these days, even better than the 4.5 release
3d X acceleration (for slightly older cards) is out-of-the-box as well
Two points:
1) they do not create a separate branch for a release. The release stays in TRUNK until it is released. This has the advantage that ALL developers are working towards a release. Introduction of features is slowed as a release approaches. He does not address the disadvantage of this system: that many developers sit around idle when their work is completed early during this phase.
2) Everyone tests. There is no test team. All developers test things before a release. He does not talk about agile and how everyone should be testing their own stuff anyways.
Point 1) was interesting. It works for them because they are volunteer based. They are not paying the salaries of the idle developers during the release phase. It would not work in a corporate environment because those people are to valuable to be underutilized.
NOTE: I did not listen to him talk... just read his slides.
No wacky and nutty GPL kooks.
No screaming diatribes over 'purity' of ideology.
No foaming at the mouth tantrums that someone is using your code and not kissing your fat ugly ass in reverence.
Over the years I've learned that BSD developers are engineers while GPL developers are ideologues - ie. wackos and nutcases.
Thank god BSD is well on their way to ridding themselves of GCC and already have the amazing LLVM compiler tech building the system. The efforts the GNU crowd has done to keep open source developers locked into their compiler is sickening from anyone who likes to believe the open source world is some sort of technological marketplace of ideas compared to the Microsoft world.
Every BSD project I've followed or participated with has been a positive experience due to those types of licensed projects attracting engineers who just want to write good code and want their code to be available and free to everyone to make good use of it.
Let's compare --
Linux (1991--present): The code base has never forked. The release process has remained largely in the hands of Alan Cox and Linus Torvalds throughout its history, and except for some cosmetic differences, patch submission and integration has been handled the same way. Most people consider the two head developers and various major contributors to be, on the whole, pretty nice guys, though the snafu with loading binary blobs, and the driver architecture supporting 'non-free' elements in kernel-space was notable for the high level of frustration on all sides.
OpenBSD (1994--present): Forked from NetBSD (1993--present), who forked from 386BSD (1992--1994), that originally derived its codebase from BSD4 (1977--1995). The history of BSD is a blood-bath of politics leading to forks; Most of the developers of the *BSDs are variously referred to as "difficult, abrasive, etc.," although Theo, to his credit, has had a major change in reputation over the past several years.
Historically, the BSD variants have enjoyed a smaller uptake in the market and casual open source contributors find it difficult to get involved because of cultural/political differences. They also tend to fragment, as noted by the number of variants, which further weakens their position. Linux, on the other hand, likely enjoys a much broader userbase and more contributions due to its more relaxed community standards and the general approachability of its core team. I would say the "release process works", but by feature count, contributions, and hardware support, the process is full of fail. Does that mean it's a failed project? No--I'm just saying that the differing priorities and political/cultural values held by the core developers has had an overwhelming impact. Businesses might appreciate the consistency of the release schedule and the relatively bug-free nature of those releases, but looking at market share it's pretty clear those are not the priorities for most businesses.
#fuckbeta #iamslashdot #dicemustdie
That is the secret of its security! OpenBSD is carefully crafted to ensure it either won't run at all, or at the very least won't run long enough for someone to exploit the server. It's really rather clever when you think about it.
Not that that would be a bad thing. The majority of people in the world are average, by definition. When a truly extraordinary person tells them what to do, and they shut up and do it, the collective ability of the group is far greater than the mere sum of its parts. If the extraordinary person happens to be a bit of a knob, that's irrelevant if they are all focused on the desired result and not their own silly little egos.
"Oh noes, he told me my code was stupid and wants me to to it again! Cry cry cry!"
If Theo tells you your code is stupid, then it is. End of story. Do it again. Yes, there are better ways to deal with people, but seriously, Theo gets knocked for his personality not because it's really that big a deal, but more because ordinary people are jealous of his enormous capacity.
Get over it people. Theo's good at what he does, OpenBSD could and would not exist without him, and the world is a better place for it.
I hate printers.
If everyone tests, the developers who are "sitting idle" are spending that idle time testing, no?
Not a Twitter sockpuppet... but I wish I was.
To translate to the "agile" buzwords of the day, they use a 2 week sprint cycle, and at the end of each sprint, the features for that sprint are complete and working, and the product is stable. They ensure this by doing daily builds and testing on those builds. Everyone runs the current build (he implies they run the daily build, but I expect that is too much hassle to upgrade every day, so in fact everyone runs the last sprint build (which is less than 2 weeks old, and has had a brief stabalizaiton period).
:-) Kudos to them for having the discipline to make it work.
It's not rocket science, the notion of small "sprints" and a releasable product ready at the end of each sprint is fairly well known. All it requires is more discipline than 99% of development teams have.
I hate it when I make a joke and I get modded "+5 insightful". Mod the stupid comments "funny", not "insightful", pleas
It really isn't that big of a leap to implicitly assume that intelligence is normally distributed.
I think you mean envious .
Long story short: Theo rules with an iron fist and springs releases like pop quizzes.
How we know is more important than what we know.
mode != mean
first post getting -1 redundant mod == mean
If everyone tests, the developers who are "sitting idle" are spending that idle time testing, no?
It would be pointless to test prior to integration of all submitted components. From the time the first component is completed and submitted and the last, those developers can test, but it's not meaningful if the goal is to evaluate the integrated product as a whole.
#fuckbeta #iamslashdot #dicemustdie
1. code freeze happens every six months meaning you don't get to finish off features and fixes which might have been of huge benefit. it would make much more sense to base your release cycle around features and improvements, then some arbitary number of days.
2. openBSD EOL's it's releases so quickly, that only in the very rare instance that a business is willing to pay through the nose for inhouse support will you be able to see your system patched.
3. 6 months is way WAY too short of a time for a whole new release. 12 months (if you have to go with the retarded time based release) would be much less of a drain on resources as there is a certain amount of work that must go into a release wether it's got useful upgrades or not.
i've used openbsd in production environment, and it doesn't cut it in hardware support or speed. it's firewall was nice, but i've got that in freebsd now which is a far better OS.
If you mod me down, I will become more powerful than you can imagine....
He's not talking about MS, you tool. Fedora Core fits that description.
Hell, I'd say at least 80% of software projects (and a good many non-software endeavors) fit that description.
- T
Basically, they only allow developers who are willing to sit through a 30-minute video to work on their software.
...during which Theo tells them if they don't hit their release deadlines, he'll eat their children.
Life is short; think quickly.
As a developer, I think I'd work faster/better if I knew a quality product would let me work on side projects in the end. If I knew that I'd never have time to experiment and play then I'd just trudge along and get depressed. It would be a tremendous moral boost. Developing has downtime unless you work for a slave trade.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
No, but assuming you can operationalize 'intelligence', it's a testable hypothesis. And it's always better to explicitly and not implicitly assume. Otherwise people think you're hiding something, 644bd346996 -- if that is even your real name.
.sig withheld by request
That assumes that all developers are roughly equivalent. But if, says, the filesystem is basically in feature lock whereas active development is going on in the networking system, the fs developers are likely to be sitting on their hands. Sure they can test networking features, but that's not their expertise and their time might be much better spent working on the next generation fs, which is not going to be in the next release but might be a couple of releases away. A branch/trunk split would allow them to work on those experimental, too-rough-to-release features. That could make for a more efficient allocation of human resources in some respects.
.sig withheld by request
How exactly does GCC "lock in" anyone into using "GNU tech"? How exactly is GCC "not truly free"? The only way in which GCC limits you in licensing your code is that you can't build your own shiny new proprietary compiler on top of GCC, and that is a good thing. The "document format" in question here is C. GNU is not claiming ownership of C.
And yes, LLVM is nice, for many thing. By the same toke, it's no panacea, either.
Ezekiel 23:20
OpenBSD is as useless as a bag of rocks
**hits anonymous cowardon the head with a bag of rocks
**thinks that was actually pretty useful.
.sig withheld by request
The problem with your statement is that you assume that Theo is perfect. If he's not (and he's definitely not, just like all of us), then "shut up and do what I say, and I don't need you trying to explain me why I'm wrong, cause I'm never wrong!" mentality will lead to a disaster when he gets something wrong. You could say that it's alright so long as, on average, he's right more often than he's wrong; however, the real problem with mistake combined with arrogance is that mistakes often tend to become grave in such circumstances. It's the "fuhrer problem" - it's very tempting to put a brilliant guy in complete control with no backup, but it only works for limited time in practice.
Theo's good at what he does, OpenBSD could and would not exist without him, and the world is a better place for it.
Who knows; perhaps, if OpenBSD didn't exist, NetBSD would be better?
Why was parent modded down as flamebait/offttopic? That's not fair.
While there are uses for which video is king, video as a way conveying certain types of information DOES suck. I think most people on here can read MUCH faster and process information more comprehensively in written form than some talking head on a video. This vid has slides, so it's better but I'd still prefer to read the slides and attached notes than basically be lectured to at someone else's pace. It does more for my comprehension and it saves time.
Christ, you'd think people thought the parent post was personally attacking Theo or something.
If there is a human testing, it's already wrong.
Perhaps developers who feel "idle" (if they exist at all) should be writing automated tests or, at the very least, thinking on how to automate stuff like testing for real-time kernel concurrency problems or device-driver weirdness.
http://www.dieblinkenlights.com
but this is just plain wrong!
`` exactly on the date promised''
Lies! OBSD releases are regularly released a month early.
And, the canard that de Raadt is an asshole is plain wrong. To those who follow OBSD for anything other than a short period of time will know what his, the team's refrain is: We make this OS for us, not for you! Your benefit is an unintended consequence. We don't want to be the most popular, we make this OS for us, not for you! You want Linux. We don't talk, we code. We don't suggest bs features, we code. You want it, code it. But then you keep posting to the list, you've been told to help yourself, that we make this OS for us, not for you! So I will now tell you to fuck off, slacker.
It's simple, man. I've read Bruce Perens say he met the guy, extended his hand but the guy never acknowledged him, that he might be Aspergerish. I thought Bruce was off his rocker when I read that. He bats .400 most of the time, and some-times I say WTF is he drinking today?
Check out theo.c for a lot of laughs!!!
One list goodie went sort of like this years ago: Why are you posting to misc@. Why didn't you read the man pages, slacker. They're quality, this is not Linux. If you didn't bother you're an idler. If you read them and didn't understand them you're a lamer.
"you bring new meaning to the terms slackass. I will have to invent a new term." --Theo de Raadt
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c
Ummm ... they've measured IQs, plotted it on a bell curve, and defined average to be the peak in the curve plus some on each side.
Since that holds the majority of the population, it's entirely correct to say that the majority of the people in the world are average. It's defined to include the majority of the people.
What you're describing is, I believe, a double-tassel distribution -- which is what first year comp-sci classes tend to look like. You either get it, or you don't, there's no middle of the road.
Average human intelligence really does sit in the middle, and most people are average.
Cheers
Lost at C:>. Found at C.
A secure system is more than just not having vulnerabilities.
Secure systems, for a start, should have the ability to control and restricts information to a fine grained level. Unfortunately, Theo is stubborn that things like MAC and RBAC should not be included, as they are not necessary. Which is remarkably short-sighted. DAC has many problems, any any truly secure system should have an alternative. As much as I like OpenBSD for what it is, and as much as I respect the development team, a focus on quality is not the same as a focus on security. Secure by default is a good approach, but is somewhat meaningless, as you are limited in what you can do with it. A true metric would be to look at the vulnerabilities of software in the ports tree, of which there is still a lot.
At the moment, SELinux or RSBAC are far more secure systems, despite those platforms having more vulnerabilities. If you gain a root shell through Apache for example, you will not be able to do a damn thing. On OpenBSD, as there is no defence in depth, the system is yours. Even NetBSD and FreeBSD seem to have more of a focus on actual security, with efforts like SEBSD, executable signatures, PAX/NX support etc.
OpenBSD is quality, top not software. It is not however, a secure system.
If you ignore ACs because they are anonymous - you're an idiot.
Long story short: Theo rules with an iron fist and springs releases like pop quizzes.
Mod parent up. Successful organizations need strong leadership. FOSS' generally decentralized model (and that damn egalitarian hacker ethic) works against this. Not that that's a bad thing, but somebody needs to steer the boat.
Linux, you magnificent bastard, I read the fucking manual!
If only those that "didn't get it", got out...
Instead, too many struggle by and end up thinking someone should hire them to code.
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
That ability to eat your own dogfood for real sounds pretty crucial to the strategy. Unfortunately, if one is developing software that they don't actually need to use extensively and continuously to get through each day, relying on developers for testing "by using it" is likely less reliable and/or predictable
For example, developers of software for set top cable DVRs (Motorola developers who write the crap Comcast downloads to my DVR - you know who you are!) may not even subscribe to cable -- and, presumably, even if they do, they have little time to watch it at the very time when it most needs testing.
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
You lost me at Comic Sans.
I could be wrong, but I think the primary reason they release so fast is because the OpenBSD team does not attempt to bundle all of existing open source software with their OS like say Debian is trying to do. In *BSD distros, there is the core OS that includes essentially only the operating system and some utilities, and then there is the ports collection. I believe a serious bug in some port package will not halt the release process of a BSD distribution, at least for non-essential ports.
It would be pointless to test prior to integration of all submitted components.
Stay away, stay faaaaaaar away from my code and applications.
I find that in a corporate lifecycle, having two projects to work on helps.. as one project approaches release, another is just coming out of a release, and into a rapid bugfix push... alternating the primary focus of your development time... This works pretty well actually.
Michael J. Ryan - tracker1.info
In an ideal world, I suppose, 386BSD would have been managed better and there would be no forks.
In your "ideal world" I suspect we would all be rather less well off.
I've never understood the appeal of one-size-fits all. Why is it the premise of so many off-the-cuff comments in every venue of discussion?
So far as I can see, it accomplishes two things: makes it easy to criticize others for not getting along, and relieves the commentator of having to learn or understand systems theory, which is subtle and difficult. If only the whales had not split off from the carnivorous ungulates, evolution, in the ideal world, would have accomplished so much more. Put into a real context, the idea barely parses.
Within the prokaryote kingdom, there is a great deal of horizontal gene transfer. Within the BSD clade, there is a great deal of horizontal transfer (of ideas and code) whenever the need arises.
horizontal gene transfer
The most profound fork is probably the GPL from the long-standing conventions of public domain, which the BSD license more nearly mimics.
I don't see much difference between the scope of source code and the scope of human interpersonal relationships. In an ideal world, we would all be better off if either A) all information was private, or B) all information was public. Turns out, some people have information they don't wish to share (for a list of reasons which includes every human motivation) so the GPL lacks universal appeal. Turns out, some people have information which they don't wish other people not to share, so neither does the BSD license have universal appeal.
Having the two license camps puts a crimp on horizontal transfer, but it hasn't caused the world to stop turning. Is it fundamentally a bad thing to implement an idea twice, beginning from two different sets of premises? Only if your goal is world domination. For maximizing insight, diversity rocks.
I could continue, but I'm sure the choir has already figured this out, and the sinners are set in their ways.
At the end of the day, fork has become a term of social derision founded upon a monolithic Garden of Eden which never existed, and wouldn't have been a paradise even if it had.
If the only reason to fork is that two parties can't get along (X, libc are possibilities, but I don't know enough of the story) then forking is a mite unseemly, much like a failed marriage. Do open source communities fork more often than any other walk of life? I suspect not. And no, I'm not counting whiner attrition, where one or two guys copy a code base into their own tree, make a dozen patches, and are never heard from again. Does IBM fork every time a deadbeat is fired or quits?
Many of these projects have accomplished things through volunteer collaboration that twenty years ago few would have believed possible, yet they are mostly criticized in retrospect for the occasional loud public spat prior to a parting of ways, by people who are deeply in touch with their inner primate.
Those of us in the results oriented camp are less inclined to praise the false nirvana of pretending to agree when you really don't.
For an interesting comparison, consider the disputes over the years within NASA over the "smaller, faster, cheaper" engineering meme.
Small Is Beautiful, But Big Is Necessary
I suspect smaller, faster, cheaper might work, but it won't ever be NASA who consistently pulls this off. NASA is what you get when an agency never forks. Ideal leaves a lot to be desired.
SELinux and RSBAC don't necessarily provide any additional security. They certainly seem to suggest it, but the software you trust is just software like everything else.
But, I think the primary 'hmm' here is that you suggest that there aren't more granular levels in BSD. Of course there are.
* chroot
* privilege separation (root from an apache server? sounds like a linux box to me..)
* sysctls for kernel and other behavior (security level, immutables)
* built-in stack protection (isn't that half of why you'd need SELinux anyway??
* encrypted swap/fs
* randomized malloc()
There's a variety of standard, well documented features that anyone can use. Each element on it's own has it's own vulnerabilities, used in concert correctly they are very effective and predictable. Unlike SELinux for instance that will randomly just not let something happen emitting a cryptic error message. And, while we're at it.. why do you trust SELinux? Audited it's code?
Given the overall security track record of the Linux distros (Debian SSH RNG anyone?) -- I trust OpenBSD a tiny bit more.
Would any video do? Like, maybe pron or something?
mysql> SELECT * FROM `places` WHERE `place` LIKE 'home`; Empty set (0.00 sec)
Being pedantic?
In that case, you'd better specify to WHICH average you are referring and your exact definition of "most", because, mathematically, there are three averages which can be taken from the data given:
MEAN: sum the data and divide by the number: 30 / 8 = 3.75
MEDIAN: write in order, the one in the middle (or mean average of middle two if number of data is even): (3 + 4) / 2 = 3.5
MODE: the data item which appears the most often (has the highest frequency count): 1
[The last average is often stated as "the data item that appears the most", with "most" meaning "highest frequency count".]
So the error in the GP's post is to say that "'most of those numbers are 1' even though the numbers are not 1 on average" when in fact, using the MODAL average, the numbers ARE 1 on average!
In fact, using the data given, it is perfectly true to say that most[1] of the numbers are above average (when the average used is the MODAL average as 5 numbers are greater than 1, giving 62.5% greater than average).
[1]most here being defined by taking the numbers and dividing them into two sets: those larger than the modal average, and those not larger, and "most" being the size of the set with the larger number of elements.
A rose by any other name would smell as sweet;
A chrysanthemum by any other name would be easier to spell
As someone who had used Linux quite extensively for the past 11 years, I recently started rolling out OpenBSD servers at my job. Two OpenBSD firewalls power our production network (using CARP/pfsync) and they do it flawlessly.
In our office, an OpenBSD firewall connected to two DSL modems is able to load balance traffic out, and do proper asymmetric routing. All this thanks to the developers who make a lot of great, innovative code for pf, CARP, pfsync, etc..
I couldn't do any of this properly with Linux, especially not the asymmetric routing.
I've worked on OpenBSD ports to make them better. I've found the developers friendly and helpful. The code is quite solid.
If it's not a human testing, it's already wrong.
You do both. Automated testing is only as good as the people who write the tests. If you make assumptions in the code, and also in the tests, you won't find bugs until users actually use it.
I know all about how you can rearrange responsibilities and someone other than the developer writes the tests blah blah whatever, it never works 100%. After I get done with all of my testing I have a human try it and about a third of the time that user will try to do something that wasn't in the requirements and did not get tested because it wasn't expected. Maybe a bug comes out of that, maybe it's just documentation that needs updated, but you have to have people using it in real life situations to be called a true test. I've seen automated testing pass things and then users, because they operate more slowly, expose timing or deadlock problems. Real people are needed.
They do test their own stuff. They also test how their own stuff works with everyone elses changes rather than in a little sandbox on the side without interaction with all the other parts. This interaction is where you run into problems. Most developers can write small chunks of code that work fine when used exactly as expected, which is what the original developer will do since they know exactly how it was intended to be used. You get in trouble when I start using your code that you documented one way and I interpreted a different way, which you didn't bother to sanitize the input or properly error check, and I just assumed your code was going to work flawlessly. Now, through no fault of yours or mine directly, we've introduced a problem that neither one of us will notice when playing in our own little sandbox.
You point this out like its a bad thing, in reality this is the only way it should be done.
The developers who finish their work early are not sitting idle, they are testing. The sooner the testing gets done and everything is signed off on, the sooner everyone can move forward. It prevents you from just working on what you want to work on and leaving everyone else to do the dirty/unfun work.
Both of your points that you think are bad are just signs of selfishness on your part and a lack of willingness to be a team player. The world doesn't revolve around you or your code, sorry.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager