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."
Is there a transcript? (Don't have time to watch a video...zzz.)
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
Geez, guys, it didn't take me even two minutes to find these:
http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/
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/
Here is the executive summary:
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...
Most of the respectable security consultants I've worked with have raved about OpenBSD. Unfortunately, all 7 of my computers have some kind of hardware issues with it. I suppose in a way that really puts the BSDs in a similar boat as Apple, regardless of OS X's roots. Less hardware support = stability? Suddenly I'm less impressed.
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
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.
...at least, in that Matz releases a new version at Christmas each year. For example, here's his Christmas post from Dec 2004 for Ruby 1.8.2. Way back when!
The Army reading list
Good point about their work towards the project being idle. However, I would also like to point out that although idle to the committed code, they do involve themselves with side-projects that will possibly be integrated into openbsd.
I'm not an openbsd pro, but I think a two of those recent examples would be opensmtpd and the improved malloc()
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
The majority of people in the world are average, by definition.
Excuse the pedantry, but you're making a big assumption when you're considering that the majority are in the average. For all you know half of people could be extremely bad and the other half extremely bright, leaving no one anywhere near the average.
You just got troll'd!
This sounds a lot like Debian's release process. Debian's primary release delays in the past have been infrastructure issues rather than software stability issues -- things like getting the right set of architectures on their mirrors, or getting security infrastructure set up for the new release.
I may very well be that the thing that makes this work is not only the release management practices, but also whatever they do to avoid security problems in the first place.
I couldn't finishing watching the video...(sorry guys...I bet there was some great info in there tho)...I'm not as developie. Anyways...Check the freaking art on their site! Developer Dudes...You change your marketing style just a bit...You'll get people asking for your disk...and then they might even install and try out your OS. Make the two forms of art work together. Developing + Painting...merge the right combination...then...\m/()\m/
The reasons, mechanics and social workings of our process have never been detailed outside the project, but now will be, hopefully providing some insight to others who face delays and quality issues with their own product lines.
He's clearly talking about Microsoft here, but why would he want to help them?
Village idiot in some extremely smart villages.
mode != mean
IranAir Flight 655 never forget!
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
Mod parent up.. please..
both with SSH. That's still damned impressive.
Hail Eris, full of mischief...
E pluribus sanguinem
quit being a trolling retard.
Summary: people who can sit through that video and can program well without crying if Theo thinks your code sucks are good enough for OpenBSD.
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
Shouldn't you be throwing a hissy fit about how much RMS sucks? Using 'bearded' as a slur? Saying BSD developers are better?
His joke was kinda funny. Maybe only GPL guys are funny?
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....
Not that that would be a bad thing. The majority of people in the world are average, by definition
I cringe every time I see this statement. Your statement may be reasonable, but it's not correct 'by definition.'
Let's take a small group of numbers:
1, 1, 3, 4, 5, 7, 9, 0.
If we average and round those numbers, we can say that that the average number is '4.'
However, only 1/8th of those numbers are actually 4, and MOST of those numbers are not 4. In fact, it would be more correct to say that 'most of those numbers are 1' even though the numbers are not 1 on average.
It would be technically correct to say 'By definition, most people are not exceptional.' I highly doubt that you'll find a lot of truly average people in the world.
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
Daarrin Reed, is that you?
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
Well, if we're being pedantic, there is no value held by "most" of those numbers, since "most" requires that at least half have the specified property.
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?
Clueless. Absolutely clueless...
If you've dealt with anything since GCC-2.95.3 especially regarding C++ code, it really *IS* a form of vendor lockin, and especially on linux, between it and glibc and the linux kernel, you run into all sorts of nightmares regarding how you HAVE to upgrade in order to get bugfixes, and keep your supporting software functional.
Way to go Hatta. You just made a fool of yourself.
Now everyone is actually reading you link and realizing what a pathetic Karam troll your post was. Hey, but at least you got a couple of knee jerk GNU fans with mod points to mod you up...
hahaha, what a farce, Solaris through version 9 could never be hooked straight to the internet in default install or it would be pwn3d. Who runs a Solaris router or firewall? no one, that's who. Not even Sun marketing droids are dumb enough to spout the shit you just did. VMS is slower than OpenBSD on a comparable platform running the same code because of the more complicated file system. And running DCL is slower than bash scripts.
makes me sad.
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.
7000 users? WOW, thats terrifically small :(
I KUT J00 M4NG!!!
Google agrees with you.
I KUT J00 M4NG!!!
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
Don't you have a release to do, Theo?
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
It's not about intelligence to begin with.
You just got troll'd!
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!
"does not talk about agile and how everyone should be testing their own stuff anyways."
Interesting how that idea suddenly became this cool new idea. When I was doing my undergrad in CS we just called that coding.
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
Isn't it likely that an fs developer who found themselves "sitting on their hands" might decide to go off and start working on the "big file system feature" so they can check it in a few days into the next release cycle (which is when checking of such "big" features seem to be encouraged)? I'd hope so. Although I have no first hand knowledge of OpenBSD's dev, I suspect a lot of short lived "branching" really does occur - but it's hidden out of sight of the cm system.
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
Average human intelligence really does sit in the middle, and most people are average.
Most people are within one standard deviation of the mean. Relatively few people are precisely at the mean.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
If they defined the avg like that it would be the mode. It just happens that IQs are normally distributed so mode=median=mean.
I did a quick google and found an 8 year old /. article saying how BSD is dying. If it's dying, how long is it going to take to finally kick the bucket?
Of course they all work in trunk. They still use friggin' cvs. Who really wants to branch in cvs?
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.
Who knows; perhaps, if OpenBSD didn't exist, NetBSD would be better?
Or would be better faster: the current version's performance appears to be quite impressive, matching FreeBSD and Linux.
Michel
Fedora Project Contribut
Which is why I qualified it and said:
I just hand waved around the specifics of the statistics. :-P
Cheers
Lost at C:>. Found at C.
> It would be pointless to test prior to integration of all submitted components.
It might not be as useful, but it is not pointless. You can find new bugs, even when you write just a single unit test for a single function in your code. Especially when your system is build up from small independent applications.
In which case it would be harder to collaborate on developing that feature, meaning that such branching work would tend to be individual. Sounds like a problematic model to me.
.sig withheld by request
Integration and functional testing are necessary, but unit tests are not pointless, either.
It would be pointless to test prior to integration of all submitted components.
I would think that continuously testing as components are submitted would be immensely valuable. Waiting for every component to be submitted only to find out that nothing works would be far less efficient that continuous testing of submissions that that problems are found (and fixed) early.
VMS is slower than OpenBSD on a comparable system? I haven't tried OpenBSD on Alpha but if you have run OpenBSD/alpha and OpenVMS on the same or similar Alpha server then well done sir, and do you have any metrics to show us?
The problem I have with your statement comparing (default) filesystem for each OS is that they have quite different feature-sets, for instance VMS has file-versioning, and quite extensive access control and access auditing capability. Bash is a very lightweight and simple shell that relies on a lot of (admittedly) standard Unix tools (such as grep, awk, sed, etc) to make it useful. DCL on the other hand has a significant payload of lexical functions. VMS has a batch and printer control system that is leaves unix job and print control way behind, VMS is more akin to a traditional mainframe in that respect. So don't get me wrong, I'm not knocking OpenBSD (I'm a great fan of the secure-by-default nature of OpenBSD) but I just don't believe one can easily compare it to OpenVMS...
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
1. There is one person making key decisions and so the decisions are made. The overhead of bringing your stupid team members up to speed does not exist. This is good and bad, and Theo couldn't last a week in a big company like mine.
2. A lot of unit testing by developers on the main branch - always a good idea, instead of some stupid self-appointed Chief Release Officer's decision while having beer with the Chief Information Officer the previous evening.
Locking out API or locking out problem developers is questionable and judgemental. Being the only decision maker helps here, but it won't always the right decision. The product's feature set and its completeness is what matters, and so no area of code is ever locked. In a company you have to deal with mistakes and have people learn from mistakes, but not punish them. You don't always have the luxury of experienced engineers and so some of the techniques about ensuring quality need to be changed.
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.
Congratulation on being totally ignorant of a) the IQ bell curve and b) statistics.
IQ can be defined because it's not a "small group of numbers" its graphed around sample sizes in the tens of thousands. With a sample size that large, it has been demonstrated that intelligence follows a normal distribution, which is a technical term, not what you think it means so don't be getting all individual upstartey on the word "normal".
mainly I was in the mood to troll at a troll, makes me feel young. But I have run VMS on VAX, Alpha and Itanium2 and OpenBSD on VAXStation 4000/60 and 4000/90. But alas, that was years ago, so no metrics as the VAXStations have given up the ghost due to cpu pin corrosion
Especially for the beastie daemon. I just had a rather odd mental image of him in a "naughty suit."
He who has no
http://en.wikipedia.org/wiki/Lucky_Charms
http://www.youtube.com/watch?v=mCcPRroLgzE
http://www.youtube.com/watch?v=9VALrCj8xhU
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.
If I'm right, their are definitly people ('senior developers') Theo does put trust in to atleast tell him to have an other look.
New things are always on the horizon
"""
that many developers sit around idle when their work is completed early during this phase.
"""
Developers *can* code new features during this phase. There is a difference between developing and committing those change to CVS. Developers don't have to be idle. If they don't want to do that, they can always help with the testing and bug fixing. Just saying that developers can do more than just one little thing.
You're assuming that the "integration of all submitted components" is required for testing. Are you sure that's a good one? Because, it really *really* isn't (in general). Especially, when such components are part of entirely different (sub)systems.
"""but I expect that is too much hassle to upgrade every day"""
Why? This is something that can be automated quite well. Something that could be run while one is sleeping for instance.
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
Bureaucracies seem to be scared of this agile stuff, because it doesn't pretend to be able to answer questions like, "given this enormous pile of features, how many developers do we need to get this project done in 18 months?" Of course, the various methods they use do give them answers to these sorts of questions, demonstrably and wildly incorrect answers. So really, all it requires is a fundamental shift in mindset, and a shift to managing projects with an agile mindset. That's probably not possible for most organizations. They prefer certainty and predictability, out into the range where it simply doesn't exist. They prefer to fail time after time after time, and are willing to live with occasional, accidental success for thirty years past its useful life. But of course you know this.
If you mod me down, I shall become more powerful than you could possibly imagine.
Linux and several large FOSS projects use custom GNU C extensions which are not supported by other compilers. This in effect locks them in to using the GCC. While this is not necessarily a bad thing, because the GCC is FOSS, imagine a scenario where the Microsoft or some other propietary compiler suddenly gained a huge and decisive performance advantage over the GCC, not likely but possible. FOSS projects couldn't use another compiler because many of them utilize these GNU extensions. This is lock-in. Unintended and innocent, but still lock-in.
OpenBSD could and would not exist without him
While I agree with what you say, that line worries me. What happens to a software project when its charismatic leader gets run over by a bus / is targeted by MS hitmen / falls in love with a female of the same specie and heads off to a deserted island ? Which of the following projects can survive easily without their leader: Linus ? Theo ? Larry ? RMS ?
Non-Linux Penguins ?
Seconded.
Writing automated test cases? Good on you.
I'm sorry if I haven't offended anyone
So... he says "New Release: 5.7!!", and everyone looks around to see who knows what he's talking about?
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).
It's maybe worth noting that the BSDs have been source distributions for a very long time and that rebuilding the world is ingrained in the being of BSD developers. There's no real reason why they wouldn't be upgrading daily.
I used to do kernel coding for VMS (original VAX/VMS, then VMS, then OpenVMS) way back. If you were on the VAX-L list (Bitnet...) or comp.os.vms then you know my name or Carl Lydick (Rest in peace).
I think it's cute that some OpenBSD accolyte thought this was a good time for a big public slasdot attaboy for OpenBSD. Sadly the "project" outlived its usefulness when it put *ALL* its eggs into the "The is our spokesmodel and ruler" basket.
VMS is still the operating system of choice for banks and hospitals. The "VMS vs. Unix" wars ended.
Market share - Microsoft won.
Uptime - VMS still has it.
Other - Linux has it.
OpenBSD - No such winner in any category.
If someone has a category in which OpenBSD comes up on top, feel free to bring it up.
Most reliable in terms of mean or mode uptime - no.
Most lines of code reviewed, corrected, maintained, or updated - no
Most hardware supported - no
Most non sociopath developers ranting on in public forums making asses of themselves - no
(I hope my use of the double negative doesn't confuse those same)
In short, OpenBSD, I wish you well. Your chosen prophet has taken you down a well from which you will not return.
E
Well, Windows has been dying for much longer, so who knows?
The most reliable estimate to date is
(remaining life of BSD) = (expected total life of Microsoft) * 2 years.
Sent from my ASR33 using ASCII
If you just wrote the freaking code to be compilable both for windows and linux in the first place, you'd end up with code that compiles fine under both gcc and msvc. The problem resides, as it often does, in users (developers, in this case) digging their own grave.
Video is for the english native too lazy to read. I want a quick scan through what he says and skipping his "ahhhh" "errrr"....
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
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.
That's "Agile Development" or "Extreme Programming" or whatever buzzwords people come up with next are just that: buzzwords. Most of what they espouse is essentially codified common sense. If your work process works, it works. If it doesn't, try to see what works for others and see if it works for you. I know, I'll call that "Pragmatic Programming", write a book or bunch of articles on it, do some conferences, and perhaps people will treat me as if I were some sort of guru because I said something elementary that makes sense.
Nah it's not that big an assumption. Just a statistical one. The population is way large enough to assume with BIGNUMBER% certainty that it follows a normal distribution.
If you do that, of course, you have to set upper and lower boundaries for your definition of average. Maybe that's the road you were going down.
No, your children are not the special ones. Nor are your pets.
In English we don't put a space.
But if dargaud is French, for example, that's the way he and every single one of his countrymen have always written question marks.
No, your children are not the special ones. Nor are your pets.
How can you claim that "FOSS' generally decentralized model (and that damn egalitarian hacker ethic) works against this." and insinuate that FOSS projects doesn't have anyone steering the boat when at the same time you base your accusations on the management merits and successful steering of a FOSS project?
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
The copyright notice wasn't the reason for Theo to go all Rita Hayworth and scream and shout and stamp his pretty little feet in a tantrum.
It was the code (who the copyright owner owned) was put in a GPL product and not dual licensed like the un-improved version.
They owned the copyright of the older version too.
And Theo doesn't mind being locked out of improvements of BSD code by closed source projects, but he went absolutely BALLISTIC over being locked out of the improvements of a BSD/GPL dual licensed code by a GPL project.
Tough shit, Theo. You still have the original BSD code, so you're still as 100% free by BSD lights as before.
What you AREN'T as free with this scenario is free-as-GPL-has-it. You know, that nasty GPL that forces coders to keep the code open so they original can be improved forever.
Didn't you find it strange that Theo wanted to be kept free-as-in-GPL rather than accept free-as-in-BSD?
I did.
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.
"When someone says they run OpenBSD, you have a very clear picture as to what kernel, compiler and userland they are running. "
What? OpenBSD from 1994? OpenBSD from 1996? OpenBSD from 1998? OpenBSD from 2000 ? ....?
What about the OpenBSD on a router?
You ignore differences from OpenBSD because you love the OpenBSD and don't see any problems.
Yet you detest people who love Linux and don't see any problems because they ignore the differences that seem irrelevant to them.
More importantly, there are no long code freezes and branches. Whatever is in CVS HEAD at a specific time is the next release. The tree is locked for 6-9 weeks during which time only bug fixes are allowed in, and then it's unlocked and development continues. You can contrast this with FreeBSD, where the release is branched and undergoes testing in that branch, while new features and bug fixes are committed into the main tree. Developers on FreeBSD tend to run -CURRENT, but that's not the branch that's actually released, so bug fixes need to be back-ported from the branch the developers are running to the branch that everyone else is using. Both approaches have advantages and disadvantages (as Theo says) but the OpenBSD approach seems to work very well for their project structure.
I am TheRaven on Soylent News
He's saying it's unusual. Which can be true.
and springs releases like pop quizzes
I think if you are surprised by having a release sprung on you, when releases happen every six months (give or take a week or two) with a 1-2 month lead period, you probably shouldn't be writing OpenBSD core code, you should be writing a calendar application.
I am TheRaven on Soylent News
Compiler extensions are generally how the C language standard evolves. WG14 recommends two independent implementations of an extension (or of semantically-similar extensions) before it will be considered for addition into the next version of the standard. Pretty much all of the GCC extensions are supported by Clang and a lot are supported by ICC and XLC. A number of the GCC extensions originated with other compilers and were added to GCC to remain compatible with code originally written for these compilers.
In short, this is how C standard evolution works: One compiler adds a feature. People use that feature. People complain that other compilers don't have it. Other compilers implement it. The C standards committee approves (a tidied up version of) the extension.
I am TheRaven on Soylent News
The majority of people in the world are average, by definition.
It's beside the point, but that's one of the wrong assumptions I just can't leave unchallenged.
The majority of people are not average. In many cases, you will not even find one particular instance of the average. In fact, only some methods of calculating the average guarantee that there's even one actual instance (e.g. the Median).
In distributions following the Bell curve or something like it, you will find a majority of people within a certain distance to the average, but depending on the form of the curve, that distance might be fairly large.
No, the majority of people are not average. They are below or above average, it only averages out in the sum total.
Assorted stuff I do sometimes: Lemuria.org
FIRST! I might not have a high IQ, but I have a really good EQ!
Can I vote for Theo to "help" manage X now?
http://blog.grcm.net/
... for an informative and subtle point about the universal nature of fanboyism.
You know, there is a difference between trolling and pointing out the flaws in your reasoning. Just saying.
Hey, Mr. "this was sent from an Alpha" himself! I remember you well from comp.os.vms in '89 thru '93 and a bit later, I used to lurk in that newsgroup daily. I still remember some of the (in)famous DCL scripts you posted that generated hundreds of replies in controversy. But this is not the time or place for such reminisces...
I'd agree with you that OpenBSD will probably never be a winner in any of those categories you listed, but I am still a (mild) fan nonetheless if not for any other reason than for evolutionary diversity. OpenBSD may never become mainstream but some of the code that the OBSD team work on often filter back to the rest of the open source community. Especially the code auditing they do for Apache and other key ports.
Well, OpenBSD does have its own version of X.org in the base system, which is periodically sync'd with the main tree but often has extra patches and fixes which haven't yet been merged upstream. There is also an OpenBSD developer on the X.org core team, so there's some close involvement there.
I am TheRaven on Soylent News
The Debian fanboys are really out in force in the comments on this article.
I'm tired of the refusal to acknowledge just how chronically Debian sucks. It is the worst Linux/BSD distribution in existence, by a mile; the over-engineered garbage they try and add to virtually every application/package they get hold of is beyond belief. I was wrestling with adding configs to both vim and apache in Ubuntu the other day, when I finally realised that the Debian idiots have tried to make their own conf hardwired in, and then have another file somewhere else (with God only knows what name, in most cases) for "user" changes.
The answer isn't simply to use another distribution if I don't like it, either. Debian offends me to the point where I want it stopped. The horrible mess of perl glue that they refer to as their custom kernel build framework is yet another example. Good luck trying to compile a custom kernel in Ubuntu; there's just so many minor perl snags that it can fail on, that it is virtually impossible.
I savagely, passionately hate Debian, and even more, I hate the system's developers and users continuing to insist on how wonderful it is, because as long as they continue to do that, the system's problems will not get solved.
Debian is suffering from the same fundamental issue that most alcoholics do. You need to be willing to acknowledge that a problem exists before you can begin solving it.
I am sysadmin for a number of boxes running some of the three Debian variants (mostly stable and testing in production).
Can someone explain what's the advantage of getting a new release exactly every N months (or days, or years or whatever time unit you like)?
I'm much comfortable with updates and security fixes that gets in my current system whenever the need for them dictates an upgrade for some piece of software (i.e. packages in Debian), in a non-disruptive manner and the most automatically possible, and complete new releases of the distro as a whole when something *really* different is going to get into stable. This barely occurs every six months, and not so frequently every year, in Debian nor in any other system I'm aware of.
This six month release cycle is artificial: what are the "milestones" in those 25 6-months releases?
I think this is only a marketroid artifact.
(Note for Debian haters and illiterates: if you're about to argue that stable release cycle is too long, and need backports for new software, drivers, etc., let me say that for a long time now testing has had security updates too; you're able to get backports or make your own, and even run a mixed stable-testing system if you want, but I don't think the scenario for such a need would be very common having testing with security updates available. If that's the case, you're probably in a situation where every distro or system will need hand tweaking and maintenance too).
Care to show us what you have ever done for anyone? NO EXPECTATIONS describes my thoughts very good.
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.
So we average people are just supposed to accept anyone that comes along and proclaims that they are brilliant, and then do everything they say?
I'm not knocking Theo. I'm sure he really is exceptionally bright. But we should be working on raising the average intelligence, not encouraging people to blindly follow anyone that appears to be substantially brighter than they are.
Watch the video deadshit.
How we know is more important than what we know.
This idea that computer science programs should weed out tons of people in the first years is ludicrous. Way back in the ancient 1990s, I started a college computer science program with no previous exposure to computers. I passed my first two courses by copying code from two friends who had home computers and introductory programming courses in their high school. After that, I was caught up enough not to need any help from anyone else. At graduation, my average in computing courses was equal to theirs.
Now, it's intuitive to most of the people on Slashdot that a lot of networking, system administration, programming concepts, and programming languages can be self-taught for a teenager. But just because it's intuitive to us doesn't mean every teen in all of the schools across the US (or the rest of the world) has exposure to the same concepts. Entry level computer science classes should be demanding, but they should bring everyone in the class into the field at the ground floor and give everyone plenty of time to get up to speed.
The idea that "you either get it, or you don't, there's no middle of the road" is ridiculous. It might take some people three times as long as others to get the foundation they need. But once they have it, they'll do fine and they'll learn new materials as quickly as most of their colleagues.
Thanks. It's an interesting idea, although I don't know how easy it would be to generalize it to other open source projects.
So the remaining life of BSD is in units of years squared?
Please excuse me for using the word "average" when I really meant "falls within a single standard deviation of the mean on the normal distribution of IQ bell curve".
But I suspect you know what I meant, you're just being obtuse. Either that or you're genuinely an idiot.
If Theo tells you your code is stupid, then it is. End of story. Do it again.
And Theo's never fucked up? Ever?
Bullshit. Call me when he starts walking on water and turns my MacBook into a Commodore-64.
You mean kudos to them for inventing the concept.
IQ is a measure of learning ability with a context, not a general thing like "intelligence".
I have a great deal of respect for Theo and his work on OBSD, however we need to be realistic.
He's not THAT good. One of my biggest complaints is the whole 'no exploits in XXX time!@%$!@%' bullshit. Which just changes each time an exploit is found.
My code has never been exploited by anyone ever, including myself.
(two weeks later, after you exploit my code)
My code has never been exploited by anyone who hasn't ran it.
This is the kind of shit that gets pulled with OBSD, and makes it FAR FAR less impressive than it sounds if you actually have followed his antics over the past 10 years. Everytime someone shows him to be wrong, he just changes the definition. Anyone can be great if you just change the definition to fit your purposes. Why people still treat him like a god is beyond me.
He's a good developer, but his ability to be an obtuse asshole far overshadows his ability as a developer. I've found its far easier to just use one of the other BSDs which are far less painful and while not 'as secure' by Theo's definition, they good enough for production work and feel far less like you're living in the 70s when you use them.
Let Theo go play in his little sandbox, I don't mind, because he stands by the BSD license it means that my prefered OSes get to be pretty much as safe has OBSD, without me having to deal with all the headaches of his holier than thou attitude.
With that said, I respect and appreciate his (and ever other OBSD developers) work. It is definitely good stuff. Their skills are far above my level, no doubt. He is still just a man and should be treated as such, sans pedestal or high horse.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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
No need to release often, but always release consistently.
From my experience, big industry (aerospace, power plants, mission critical apps) have been doing this since the 70's--with both average and exceptional developers working together...
Also, having no pressure (from competition) and a big backer (Apple via FreeBSD) does have its advantages.
Damn, beat me to it. Seriously. Who does that?
.there is enough of everything for everyone.
I know people here are obsessed with intelligence and seem to think of themselves as part of an intellectual elite (something about making themselves feel better about not fitting in with most of the rest of the population), but it's not about intelligence to begin with.
We're talking about people good at something precise such as coding. You can have an IQ of 173 and a special gift for statistics, that won't prevent you from writing shitty network code. Like me, I'm a great coder, but I went to school to become a sysadmin. Because of this, I'm a very mediocre sysadmin (and eventually abandoned the possibility of pursuing a career there), despite being an arguably bright individual and having certain technical skills.
IQs are one measure. Most people are average on that measure. But we're talking about professional skills, and for all you know most people may be excellent at what they're best, thus not just being "average". And again that has nothing to do with 'intelligence', I knew people excellent at driving vehicles or building houses who otherwise were utter all-around morons.
You just got troll'd!
No, the fact that there's a big population doesn't imply a normal distribution.
Consider personal wealth. Assuming that 99% of the population has wealth under $10 million, and it's normally distributed, there's no possible way to account for billionaires, as they're far too many standard deviations from the mean.
Consider individual height among US adults. If not bimodal, it's close. Consider individual weight. It's skewed. The average is maybe 150 pounds, but there's a significant amount over 350 pounds and none less than -50 pounds.
The normal distribution works great for sums of sufficient random variables. There's a whole lot of stuff in nature that just doesn't fit.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
You start bashing Anonymous Coward with uncursed +0 bag of rocks. You kill Anonymous Coward. Welcome to level 10.
Since when did you get bug fixes with any software *without* upgrading?
There's nothing stopping an interested party in cherry-picking bug fixes from newer versions and backporting patches. The fact that you haven't done so yourself means you either don't care enough, or are incapable (both of which turns your complaint into entitlement-laced whining).
And I'm not really sure how writing C++ code and compiling with gcc locks you in to gcc. My C++ code (on the sad occasion I need to use C++ for work) compiles just fine with both gcc and MSVC with a minimum of #ifdefs. If yours doesn't, perhaps you're just not a very good C++ programmer.
Xfce: Lighter than some, heavier than others. Just right.
To my understanding Linux would survive just fine. He's our "benevolent dictator" but he hardly makes day-to-day decisions and tells people what they're going to do. Last time I checked most discussions over something getting integrated or not are handled by a group of people who only defer to Linus if nobody can reach a consensus.
Someone please feel free to correct me if I'm wrong.
"Just a fox, a whisper."
Sorry, but "unintended and innocent" changes the meaning of "lock in" so completely that it's useless. The term "lock in" is almost always used to describe the intentional, malicious action of one party to prevent another from using a competing product/service/whatever. If you take out the malice and make it unintended and innocent, then it's hard to call it lock in with a straight face.
But if you still insist on calling it lock in, then I say... who cares? If it's unintended and innocent, you can usually fix this problem through gentle prodding and education. (Hint: there's a compiler flag for gcc that will make it not accept GNU extensions.) If a software maintainer doesn't want to accept a patch ("well everyone uses gcc, so why should I clutter my code with this patch?"), then that's the direct fault of the developer, not of gcc.
And hell, many GNU extensions are useful. I'd imagine that LLVM's compiler backends might want to borrow some of them. (And sorry, childish "we don't want to copy gcc" isn't a valid reason for not implementing them if the extension truly is useful.)
Xfce: Lighter than some, heavier than others. Just right.
I know perfectly well about the space before question mark rules (and yes I'm french). I chose to do so because it makes the text more readable. Same for ending a quotation before the "period". I've lived in 4 countries and I like to take what's best of each. Thanks for coming to my defense BTW.
Non-Linux Penguins ?
If you really meant that, you're the rare exception.
The too-simplified average assumption is one of the main problems in many design decisions. Systems are built for an "average user" that simply doesn't exist. The result is abominations like windos - stuff that nobody can use well, but everyone can use badly.
Assorted stuff I do sometimes: Lemuria.org
BSD forks: events and timeline:
UCB CSRG didn't want to create a bootable distribution.
FORK1: Jolitz went off and did 386BSD because he disagreed about the bootable distribution.
(1990) Jolitz releases 386BSD 0.0 to a smal group.
BSDI started.
Many of the principals in BSDI were from UCB CSRG, so there was some financial conflict of interest vs. 386BSD there.
(1991) Linux released Linux - there is no lawsuit incentive for him to have done a different code base at this point.
(1991 - October) Jolitz released 386BSD 0.1
BSDI used the trademark "UNIX" in their "1-800-ITS-UNIX" phone number and their advertising.
USL sends cease and desist use of UNIX trademark to BSDI - the lawyers are now awake.
Jolitz promises a 386BSD 0.1 "real soon now".
Time drags out... I write a 386BSD unofficial FAQ with a patch in it for the VM system for sytems with an option-base-0 BIOS base memory size so it'l boot.
People start sending me patches for the FAQ. Too many patches. I create the 386BSD "patchkit", with Jolitz's blessing, on the promise of a 386BSD 1.0 "real soon"
USL, sensing competition in the UNIX marketplace, sues BSDI, initially nominally over the trademark.
I convinced Jolitz to trademark "386BSD" to keep BSDI from claiming "BSD" was too similar to their trademark to avoid BSDI doing to 386BSD what USL was doing to BSDI.
The patchkit serialized application of patches rather than going for a full SCCS mechanism. As a result, only one entity could patch at a time, to maintain dependency ordering.
A group set up a bunch of patches at a really high ordinal value because they felt their patches were not being integrated quickly enough. These patches ignored the "one entity" conflict avoidance mechanism.
FORK2: A fight ensued over control of the "patch sequence number" integer. The patches of the first group and the second group moved to SCCS. NetBSD was born.
Jolitz had family issues and there was a flame war between Lynne and the patchkit people, who were still waiting for a 386BSD 1.0.
FORK3: Permission to use the 386BSD trademark was revoked. The original patchkit work moved to SCCS rather than throw away work in progress. FreeBSD was born.
BSDI hid from USL behind UCB.
The other BSDs got "ceases and desist" notices from USL because of that (not before we mirrored archives to non-Berne signatory countries, though).
UCB filed countersuit.
MIT offered to back UCB vs USL with their full patent portfolio, which would have shut down USL cold.
UCB declined MITs offer (no reason was given).
UCB, BSDI, and USL "settled" permitting BSDI to continue binary-only distribution of their products until they rewrote a number of critical files.
This appeared to be a "complexity" gambit, i.e. a way to freeze out the other BSDs by diking out code that USL expected could not be rewritten by "amateurs".
The other BSDs were not extended the same distribution offer.
A number of Novell employees, myself included, camped out in Mike DeFazio's office on the second floor of the building in Sandy, Utah, to get the same deal for the other BSDs (Novell owned USL at that point, and Mike Defazio was the VP in charge of the "UNIX Systems Division" of Novell). We got the deal extended.
UCB CRSG released 4.4-Lite2 (the sources for 4.4., minus the critical files).
The other BSDs rewrote the files that BSDI and USL thought couldn't be rewritten.
Theo, then an obnoxious know-it-all kid who had yet to prove his stones, pointed out a security hole in NetBSD.
NetBSD ignores them.
Theo locks the NetBSD folks out of their project systems using an exploit based on the security hole he had previously pointed out.
FORK4: Theo is booted out of NetBSD. OpenBSD is born.
FORK5: I was around for the DragonFly fork from FreeBSD, as well, but it had a lot to do with design philosophy, and the practical unwo
You seem to be laboring under the belief that I'm suggesting that computer science should be weeding people out heavily in first year.
I was merely pointing out that if you plot the test scores on a curve, you end up with a double-tassel distribution instead of a normal curve. It's more of a statement than a value judgement.
The reality of it is, it falls on a double-tassel distribution because in real life, you either do get it, or you don't. I've known brilliant mathematicians who never really understood writing code. Some people just never get their head wrapped around the specifics.
Trust me, I'm not being elitist or anything ... it's merely a reality that it's a subject matter which doesn't land on a bell curve.
Personally, I'm in favour of as many people as possible "getting it" -- the notion that computers should be some spooky voo-doo that only a select few can be taught is absurd. It doesn't change the fact that you can measurably demonstrate that it's not something everyone gets. I don't know if other subjects generally don't land on a bell curve or not.
To some people, it still ends up being voo-doo and something they can't figure out.
Cheers
Lost at C:>. Found at C.
Alone, right? Surley you do not mean to suggest that a FEMALE would go along? This is, after all, SlashDot. News for nerds, and all that. Women chase after politicians, actors, rock singers, and piano players. Never computer geeks.
BTW, the Squeak developers list has been engaged in the same debate for the last week or two, leadership by committee vs. single strong leader. The moon is not full, or new, but it is in Taurus. Coincidence?
Gary Dunn
Open Slate Project
I wasn't talking about IQ, because if I had been, I would have commented on the statement that "most people have an IQ of 100," which is also completely incorrect.
Yes, most people have a normal IQ. No shit. But wile people with an IQ of of exactly 100 might be the largest individual group of people with a specific IQ, they will be far outnumbered by the total number of people who have a normal IQ in he 90-110 range. If you take a random person and test their IQ, chances are it's near 100, but not exactly 100.
If you'd like, I could explain the difference between being 'an average person' and 'a person of average intelligence.'
Thanks for this post. I'm surprised by how poorly my original post was received.
Which number would you say appears the most often in that group?
While we are being pedantic...
Main Entry: most
Pronunciation: \ËmÅst\
Function: adjective
Etymology: Middle English, from Old English mæÌst; akin to Old High German meist most, Old English mÄra more â" more at more
Date: before 12th century
1 : greatest in quantity, extent, or degree
2 : the majority of
The OS to run for utter reliability from HP isn't VMS, it's NonStop. And for those not-from-HP products from IBM mainframe OS can beat VMS reliability on a single machine. VMS is just a minicomputer OS from the past, fairly good uptime if cluster as a whole considered, but for any individual machine not so quite so great. File-11 filesystem is prone to fragmentation too.
And OpenBSD does have distiguishing characteristics among the BSD, unlike FreeBSD, which put out unreliable SMP locking that siezed up under load for years, OpenBSD emphasizes correctness, and so was a better choice (and I'm still skeptical if FreeBSD team has fixed their shit). DragonFly looks promising, they forked from before the point FreeBSD went down the crapper.
You dislike Theo because of his insistence on excellence, you think of him as "socialpath" because you're threatened by his accomplishments. but he's just a tough boss. You can see what happens in inverse relation to toughness of boss, Hurd went nowhere, Linus made a kernel but GNU tools had to provide the rest, while Theo has a whole distribution to head.
> The OS to run for utter reliability is...
I'll stick with the proven winner. My post already indicated not only why that is, but showed the evidence. Just naming something different with no comparison, criteria, or any evaluative points is just a strawman argument.
> File-11 filesystem...
I know it's hard to research things that you can't google, but trust me -- you should research before you speak -- especially if you're going to be judgmental about something not being as good as something else, and you have no knowledge of one of them. There is no such thing as what you said.
> You dislike Theo because of
You have no clues as to whether I dislike Theo (I do not dislike him) nor why.
I care nothing about him.
> you think of him as "socialpath"
Yes, because he's met the standard for being a sociopath. It's not what "I think". It is what it is. DSM is now online. Feel free to use it.
> You can see what happens...toughness of boss...Hurd...Linus...Theo...
I'm sorry I disrupted your church. I was discussing operating systems, not people. It so happens OpenBSD is associated with a known sociopath. That has nothing to do with Linus, Hurd, or anyone else you care to bring up.
Best regards,
Try not to froth at the mouth when your religion or prophet are painted in the colors they selected themselves.
Ehud
http://en.wikipedia.org/wiki/Files-11
So you don't know name of VMS filesystem, tsk, tsk.
Any real VMS admin such as myself knows Files-11 is prone to fragmentation, and it's such a problem this product has been making money for a couple decades: http://www.diskeeper.com/products/vms-vax/about-diskeeper.aspx
OpenBSD isn't my religion, I like many OS.
I do work at an HP Elite VAR, most OpenVMS is running on Alpha, the last of which was sold new in 2007. Whether they go to Integrity platform remains to be seen.
> I like many OS.
So do I.
> Any real VMS admin such as myself
Sorry to disappoint, but unlike admins, engineers (or a kernel coders) have to understand the internal workings, and if you get there, you'll be more apt to see what I'm saying. Still, I don't want you to think I'm talking down to you, and Slashdot isn't about you and I having a conversation.
ODS - On Disk Structure - defines how a structure (you could think of this as a file if you were so limited) is stored. It includes extents and lists of extents. Disk defragmenters like that ripoff product diskeeper attempt to make use of ignorance of how this works to get people to buy software that does not help. In reality the extent windows are cached by the filesystem so having parts of the structure on different platters/heads/cylinders doesn't do ANYTHING to performance on reads or writes. ("Doesn't do anything"=does not affect performance of reads or writes.)
Glad you work at a VAR. It's good to have a job these days. If you want to know more, study up on ODS, extents, windows, caching, and don't read any more wikipedia on FMS, Files-11, RMS, or anything else which is not low-level.
There's nothing wrong with being an admin. Best not to confuse it with being an engineer.
Best regards,
Ehud
The population is way large enough to assume with BIGNUMBER% certainty that it follows a normal distribution.
Yes, because everyone knows that distributions in large populations are ALWAYS normal.
I'm being sarcastic. Maybe you should have went beyond Statistics 101.
You just got troll'd!
Funny, the experts of VMS, HPs engineers who are still writing the stuff, say differently in the hp openvms forums, that excessive fragmentation can kill VMS performance and so HP themselves also sell defragmentation tools. They must know something you don't?
any caching obviously only helps in certain cases, when what is being sought is available in the cache.
as a real degreed engineer of things electrical and nuclear who has designed and built real things, I find the use of "engineering" by those in the software realm a little humorous, as they are not nearly so rigorous, and push things out the door with built in causes of catastrophic failures, read the vms patch comments sometime. At least in the last 5 years the thing looks pretty stable and good, finally.
You do realise there's such a thing as a skew normal distribution?
Your examples might be skewed bell curves but they're still bells, not inverted bells as 4D6963 was hypothesising. Their cumulative probability is still a nice smooth S curve.
Does their being skewed change how many people fall within the limits you've set for your definition of average? Nope. The majority of people are still average and that applies to all walks of life.
No, your children are not the special ones. Nor are your pets.
I still disagree.
If you arrived at a college course "Introduction to Ancient Mayan" and the professor announced that starting 10 minutes into the first day, every spoken and written word in the course had to be in Ancient Mayan, most people would drop out or fail the class. Only a few people with spectacular innate linguistic talent would succeed
If the professor made the introduction to the language more gradual, a significantly higher portion of his students would handle the transition. Many would still be unable to handle it, but not as many as if there was a hard switch to pure Mayan a few minutes into the first class.
That's exactly the problem with most instruction in computer science. Most of the students in a Computer Science 101 course have some raw talent in math and maybe some amateur programming under their belt. It's realistic to expect that many can never be skilled software developers and designers. But many others who could do fine with a good introduction to the field will fall behind because the professor hits day one and takes off like a rocket.
Again, this is a subject near and dear to my heart because I struggled like crazy to barely past my first few courses, and now I have many tens of thousands of lines of code in production and generally good performance reviews from both other developers and the QA team.
But here one important thing to point out is that the GCC people (for C and C++ at least) seem less fond of adding GCC-specific language extensions to their compilers these days, and lets you easily avoid them. You no longer get the feeling they're saying: "here is a new operator you might want to use -- it will never be standardized, but you will never again use some other compiler anyway, will you?"