Slashdot Mirror

I think it's down to three things.

Firstly, Linux gained critical mass and became the "defacto" kernel for GNU. The network effect is not to be sneezed at.

Secondly, they started off with the Mach microkernel and then switched to the L4 microkernel, which meant lots of rewriting.

Thirdly, they seem to suffer from second-system effect - with the user-space utilities, they had to duplicate the workings exactly, but they had more freedom to do what they liked in the kernel internals.

I surely recomend python. its great for beginners and you will be very productive with it.and it should give you the 'coding itch' this book is great for beginners.. stay out of C and C++ as your first language though.

esr's how to become a hacker is the best advice I can think of.

Gambas does not try to be compatible with Visual Basic, and will never be.

Then it's just as useless to the original poster as Visual Fred.NET is.

No, Mono is for replacing Visual Fred.NET, not VB 6, which is a different language entirely.

Sounds like you came to our channel. I don't know about you, but when we get questions like "how do I install an irc server on my root?" we get pissed off. We get a half dozen people a day who try to use the l33t sk1llz on us that they picked up from #rohack, then curse at us in gibberish when it doesn't work and we won't help them with it. Not to mention the hourly trolls and so on.

Our channel has a policy. If you want someone to lead you gently by your dick, cry to your momma. If you've read ESR's How to Ask Questions The Smart Way and your question looks like you put a modicum of thought into it, then if someone's available who knows how to deal with it, it will get answered. That means if we get another loser asking us "bash: gcc: command not found, what this mean?????" (actual channel quote) you WILL be abused and removed.

Reverse execution? Are we finally going to see an implementation of the COME FROM statement?

(See also the entry in the jargon file.)

It's coming ... October 1st, 1993, shortly after AOL freezes over.

You might be interested in Eric Raymond's discussion of the subject, "The Magic Cauldron", which can be read online here

Cathedral and the Bazzar.

Death marches (as they're affectionately known) aren't "I'm in the groove and can't possibly stop" all night coding binges. They suck the life out of you. You're typically fighting lots of bullshit (the same BS that got you behind schedule in the first place) and your morale is drained because you're never, ever on time. You're asked to the impossible; not a "I'll just work really, really hard" impossible, but "even if I never take breaks to eat, sleep, or use the restroom I'll never make that dealine" impossible. This isn't cool and the sign of a vibrant programming population. Death marches are typically the the sign of large, beaurocratic, grossly mismanaged companies with terribly managers, a complete lack of plans, and no real hope of accomplishing anything.

If you're going to link to the jargon file, link to actual jargon file, not some page full of ads.

Have you noticed that, althought Apple's own operating system owes a lot to the open source movement, and the thousands of developers whose code they use for free, you and I still cannot run iTunes on our Linux desktop to sync an iPod? No money in it for them...

I've written this before, but haven't refreshed it for a while, so here goes: That kind of attitude is the direct opposite of the Open Source mindset. You're making the classic mistake of failing to distinguish between "sharing-as-giving-things-to-other-people" and "sharing-as-taking-things-from-other-people".

Open Source is a development philosophy that makes it easy for people to roll their own work back into the original project. It is not a crowbar to pry somebody else's work away from them, and every person who pumps crap like this into the air just proves Bill Gates right when he calls Open Source anticommercial, anti-property, communist, and any other nasty names he can think of.

NOTHING in any part of the Open Source manifesto says being part of one open project means you're obliged to open everything else you've ever made. Not even the GPL requires that. RMS personally feels that the world would be a better place if all distributed software happened to come with source code that any end user was free to use and modify, but even he tries to state that opinion in reasonably moderate terms.

If you want to know the Open Source attitude about when to open a project, try reading section 10 of The Magic Cauldron, specifically the case study of when it made sense to open Doom.

Whether you like it or not, it does make sense to keep some projects closed until the market matures enough for the benefits of opening the source to pay off. It took four years for that to happen with Doom, and let's face it, the gaming industry moves pretty fast, even for software. The bloom was pretty much off the rose by then.

iTunes/iTMS and the iPod are currently in a state where the benefits of staying closed still outweight the benefits of being open. They don't suffer significant reliability or scalability problems, they don't require independent peer review the way cryptosystems do, they don't create a significant communications infrastructure (though podcasting does create a comms network at the application layer), and they don't rely on standardized key methods at the software level. They have no meaningful competition, they're picking up market like hell, and the untapped market of Windows users and non-computer users is vastly larger than the "I refuse to participate unless I can do it on Linux" market.

In Open Source, 'paying your dues' means giving your modifications back to the original project. Period. Apple does that. And there's fairly good reason to assume that the Linux community would spend a metric fuckload more time and effort porting Apple's crown jewels over to Linux than 'paying its dues' if Apple were crazy enough to open those projects.

If the Open Source community wants business to take it seriously, it has to be deadly serious about adding value to the original project, not pillaging everyone else's technology in the name of Improving Linux like the anti-property assholes Bill Gates wants us to be.

This reminds me of that old Crunchly cartoon from the Jargon File.

My new invention, the computer!

What does it do?

It makes a million mistakes a second.

Computing is about what you run, not what you run it on.

This reminds me of that old Crunchly cartoon from the Jargon File.

My new invention, the computer!

What does it do?

It makes a million mistakes a second.

Computing is about what you run, not what you run it on.

[...]on the cache-miss and similar though. That's why itanium was good - less of the cpu trying to optimize its own code before running it.

But it doesn't seem to be good enough for the marketplace.

I'm not sure whether that's because it's ultimately suboptimal in theory (no compilers could ever work around such a design) or in practice (such compilers weren't buildable within the economic and time constraints necessary to make the system, as a whole, meet its original performance goals).

If you think that removing the gunk and having an OS based around from-source would let you compile in timescales similar to installing a binary package, then you're right and let's start working on it, but I don't think processors are quite fast enough yet.

I think that it's all possible.

I think a sufficiently-well-designed system would allow a distribution to consist of not just the raw source, and not the equivalent of today's executables, but of raw source plus something in between the two that allows a final optimization stage to focus optimization resources on the known "hot spots" and, otherwise, use cheap target-specific optimizations to generate the final code upon installation.

I think this sort of system could provide all sorts of advantages over the present architecture, be faster, more reliable, easier to debug, etc.

But, since I might well be wrong, or right but ahead of my time (or possibly behind?), I don't want to start working on it until I can satisfy at least one of the following two criteria:

• Create a small-scale prototype as proof of concept, demonstrate that it would actually work and produce better "numbers" than would be predicted by the old way (perhaps actually implement the prototype's design the "old way" as a separate track for direct comparison)
• Create tools that not only automatically generate much of the code for such a system, but much of the protocols, file formats, and APIs as well

(Asking a computer to do more work for me means giving it more power to decide how best to approach the task. For example, since I'm "asking" it to allow distributions of pre-digested source leading to faster generation of optimized code upon installation, either I have to design the format of those pre-digested files myself, or I can somehow teach the system to do it itself and maybe produce a better result.)

Accordingly, I've been slowly designing a simple, scaled-down replacement for the Unix OS that is intended to allow me to meet both criteria, or at least the first.

(But I haven't really written much up on it yet -- nothing online, certainly.)

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks ever deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

They can on properly configured systems, and wine implements the win32 API, it doesn't emulate it. You could say that wine emulates the Microsoft implementation of the win32 API. You do realize that the whole "wine means wine is not an emulator" thing is a big HHOS joke about how imprecise the word emulator is, don't you?

It's exactly the opposite for me. I upgraded from twm to WindowMaker to E15 and liked it. I switched to Gnome quite a while ago, though, and most recently to KDE. To me, it's superior to any other desktop I've ever used. Most of my long-time Unix friends have switched, too, so my anecdotal evidence is completely different from yours. I'm not saying that I'm more right than you - just that it's generally bad to draw such sweeping conclusions from only personal experience.

He keeps doing it over because he wants to get it right, a desire that is somewhat lacking from most projects.

That's often referred to as second-system effect, and not universally regarded as a Good Thing.

No, XForms is the "Second System Effect".

Worse really IS better.

That'd be a patent on being an asshat, not a trademark. But, offtopically, McNealy's asshatness is so far from that exhibited by any of the FOSS MIT alumni he's totally normal and generous.

Why the fuck is it that all of the MIT asses involved in FOSS are such wankers and aren't doing any real science? Of all the really smart graduates MIT produces, we get Dick "Hey, I wrote a version of emacs, once had an idea about an operating system, and my cleverness with self referential acronyms doesn't extend to personal hygene" Stallman, and Eric "I maintained the Jargon file; I'm a, self proclaimed mind you, member of the holy trinity of FOSS movement, and in all of my pictures I appear to have Down Syndrome" Raymond.

Come on, MIT, give us somebody with a brain instead of a personality disorder.

That'd be a patent on being an asshat, not a trademark. But, offtopically, McNealy's asshatness is so far from that exhibited by any of the FOSS MIT alumni he's totally normal and generous.

Why the fuck is it that all of the MIT asses involved in FOSS are such wankers and aren't doing any real science? Of all the really smart graduates MIT produces, we get Dick "Hey, I wrote a version of emacs, once had an idea about an operating system, and my cleverness with self referential acronyms doesn't extend to personal hygene" Stallman, and Eric "I maintained the Jargon file; I'm a, self proclaimed mind you, member of the holy trinity of FOSS movement, and in all of my pictures I appear to have Down Syndrome" Raymond.

Come on, MIT, give us somebody with a brain instead of a personality disorder.

Still, as previous news stories here have shown us, married, old staff are not as innovative or useful as young hopefuls, so perhaps this plan isn't so bad on Google's part after all.

Useful is an interesting word to use here. Are you suggesting that somehow a technology company should get rid of their "married, old staff" because they are no longer userful? I would venture to say they would be releasing nearly all of their experience and corporate knowledge.

Tell AC and ESR that they're useless and no longer innovative. I'm sure they'd agree.

Uhhhm, yes, the _crackers_ that crack viruses deserve no respect. Uhhhm, yes, the crackers that expose mal/spyware deserve no respect. Yes, the crackers that crack commercial drivers to find out how hardware should be programmed deserve no respect. Etc, to infinity.

Uhhhm, yes, the _crackers_ that crack viruses deserve no respect. Uhhhm, yes, the crackers that expose mal/spyware deserve no respect. Yes, the crackers that crack commercial drivers to find out how hardware should be programmed deserve no respect. Etc, to infinity.

Uhhhm, yes, the _crackers_ that crack viruses deserve no respect. Uhhhm, yes, the crackers that expose mal/spyware deserve no respect. Yes, the crackers that crack commercial drivers to find out how hardware should be programmed deserve no respect. Etc, to infinity.

Yes! You took the words right out of my brain. The FSF is useful; they code. OSI is nothing but talk. Why would we let them represent us? Then with near lethal levels of unintentional irony ESR tells stallman to shut up and show him the code.

OSI is a plague on the community. They've foobared free software memes and we need to do something about it if its not too late.

You might be refering to this:

[Usenet] "As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one." There is a tradition in many groups that, once this occurs, that thread is over, and whoever mentioned the Nazis has automatically lost whatever argument was in progress. ...

Usenet is still thriving and there still many very active groups out there, some of which actually have comments in them as opposed to "erotica", although there's still plenty of that too, of course. Better yet, now that October is nearly here at last, the signal to noise ratio should go up too. Sure, many ISPs might be giving up their own Usenet servers, but if they don't outsource to a dedicated provider like SuperNews or Giganews, you can always get an account with them yourself. Failing that, you can hunt around for one of the numerous free servers, and there's always Google Groups of course, but they often don't carry as broad a selection of groups.

In other news, BSD is dying!

Required javadoc/doxygen/VCS comments often result in "XXX: required for checkin" type comments.

True. This is why, in the topsy-turvey world of software development, it's often useful to have a nice, solid piece of wood in your hands...sometimes a LART must serve as a "Developer Attitude Readjustment Tool."

Rules for initializing and using globals, rules for maximum method length, code ownership, and small group code walkthroughs can do a lot to prevent the kind of problems you mention.

Well, a method should be as long as it needs to be and no longer; I disagree with artificial limits that end up breaking one subroutine into n plus one that does nothing but call those parts in sequence. But code walkthroughs/reviews, hell yeah. Not only do they make for better code, they're educational and thus make for better coders.

Are there any books or other reading material that I could read in order to manage a software project effectively?

No.

(Semi-serious. The evidence suggests to me that either you can do it (presumably with some practice) or you can't. If there is a group of people who can learn it from books, they are lost in the noise. Nor does there seem to be a way of knowing in advance whether you can. Like I said, semi-serious; I don't fully mean this but it's not fully a joke either.)

to a computer scientist, a hacker is someone who tinkers with access to a supposedly secure system

Hehe, it appears the word's meaning has been so lost and distorted that even those who would defend it and correct its misuse are confused.

The Jargon File defines hacker thoroughly for those who really want to know what it means. Or what it meant, anyway, before it escaped the obscurity of hackerdom and entered mainstream use as a label for someone who breaks into computer systems.

You are an exceptionally stupid Anonymous Coward. That original post was a false statement to produce a predictably opposite response: a Troll. While my response was not predictable, but exposed the post for the deeper drivel it really represents, beyond a facile troll. Now that's hip.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

The Jargon File seems to suggest that personifying software is a common tendency in Geek/Hacker culture. I imagine it has ESR's debatable fingerprints all over it, but it seems like a valid argument.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Obviously the answer is 42; I would never argue with you about that (though quite what the question is is another matter). But, in context, I was talking about answering the great-great-grandparent post (that you had just replied to) which ended in STR.

Just trying to figure out why admins call them "boxen," not supporting the strange practice.

It's a running joke. See also this.

Just trying to figure out why admins call them "boxen," not supporting the strange practice.

It's a running joke. See also this.

life=. (]+.&(3&=)]-[)(+1&|.+_1&|.)("@[.)1

(2=0+.=T∅.|T)/T←ιN

You're asking for legal advice from this crowd? That's like asking for dating tips

If you want good dating tips, read the Sex HOWTO by a hacker stud Eric S. Raymond.

You're asking for legal advice from this crowd? That's like asking for dating tips

If you want good dating tips, read the Sex HOWTO by a hacker stud Eric S. Raymond.

An AC gets modded down.

Sees no purpose in life.

Wants to kill himself.

Is a loser.

Whom no one loves.

And wants to have sex with.

Even after reading ESR's sexy-looking HOWTO.

Live sucks.

Badly.

The trailer text:
What is a girl to do?

Simple. It's a girl who wants you to do her.
Want to know such a girl? Read this HOWTO by Eric S. Raymond.

The trailer text:
What is a girl to do?

Simple. It's a girl who wants you to do her.
Want to know such a girl? Read this HOWTO by Eric S. Raymond.

Almost everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

The intro reminded me of the "Everything that can be invented has been invented" comment by Charles H. Duell in 1899 and the rest of it made feel like I was reading a hip-hop cover of Eric Raymond's Cathredral & the Bazaar with a few verses left out.