Slashdot Mirror
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."
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
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.
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.
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.
They have different philosophies. I really don't know where you're going with that post because isn't very accurate. You can't compare the "Linux Kernel" with OpenBSD's whole. A kernel is pretty much useless without a "userland." OpenBSD, FreeBSD, NetBSD are all operating systems. Linux, sorry to say, is not.
If you want to compare BSD versions to Linux versions, then you'd have to compare with (in no particular order): .... because I can't even keep track
-Gentoo
-Debian - Ubuntu - Xubuntu - Xandros - (how many more are there?)
-Slackware
-RedHat
-Ubuntu
So, you have a million confusion projects going on based on the code all, called "Linux". How many versions of "OpenBSD" are there out there? Umm, ONE. Sure, someone could go and make their own userland and such, but it cannot be called OpenBSD. So, before you go on a rant about how many times BSD has been forked, please get your facts straight.
Thanks,
Your post is off-topic from the video and the Slashdot article. This isn't a comparison about how Linux compares versus OpenBSD. The video, if you watch it, is about how the OpenBSD team manages their releases, meets their agreed upon release dates, and makes sure that each release is a quality product.
The points he discusses in his video revolve around conducting adequate testing of the product and having the developers use the to-be-released system rather than throwing something out as a release and moving on. His points about managing the release process are just as valid if they were applied to manufacturing and releasing cars, paper products, or skateboards as they are to operating systems.
Cory Doctorow talking about cloud computing makes as much sense as George W Bush talking about electrical engineering.
They have different philosophies. I really don't know where you're going with that post because isn't very accurate.
You just said it: They have different philosophies. I'm answering the question of why, and what's come out of those approaches historically.
OpenBSD, FreeBSD, NetBSD are all operating systems. Linux, sorry to say, is not.
I think you're confusing the terms "operating system" and "distribution".
So, you have a million confusion projects going on based on the code all, called "Linux".
No, I believe they call themselves things like "Redhat" or "Gentoo", etc.
So, before you go on a rant about how many times BSD has been forked, please get your facts straight.
Sir, a full exploration of all of the facts and an exhaustive comparison between all the Unix variants has been the subject of many books, panel discussions, conventions, and academic discourses, and has yet to be fully explored. I think that a high-level overview is both more productive, and better suited, for a humble posting on an electronic forum.
#fuckbeta #iamslashdot #dicemustdie
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.
I've never heard that referring to anyone in the BSDs but Theo himself. When was the last time you heard complaints about NetBSD or the FreeBSD core team?
They also tend to fragment, as noted by the number of variants, which further weakens their position. Linux, on the other hand [...]
...is even more fragmented. How many Debian derivatives are there? RedHat? What about Gentoo, LFS, etc.? There's probably more similarity (and shared code) between FreeBSD and OpenBSD than between Ubuntu and Slackware.
Cut the BSDs some love. They deserve it, and there's plenty to go around.
Dewey, what part of this looks like authorities should be involved?
I disagree. The "forks" from original BSD weren't really forks. They were Berkeley giving up on it and letting others take over.
Most of the various BSD's are "forks" because they have different purposes. OpenBSD is security oriented, NetBSD is intended to run on vritually everything that has a CPU, FreeBSD was intended for more mainstram use.
The only real "schism" I can think of is when Matt Dillon broke off and formed DragonFly BSD. Everything else was pretty much some guys saying "I'm gonna go off and do this instead".
There may not be any real Linux "forks", but that's because Linus has tried very hard to make Linux "one size fits all", and that has resulted in its own set of problems (see the various scheduler wars, for instance.. they were bloody). There are also any number of "branches" in which different patches are applied to the mainline kernel for different purposes.
If you need web hosting, you could do worse than here
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
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?
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.
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.