Slashdot Mirror

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.

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

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 ever more market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

You mention the interfaces in Minority Report...

That stuff was done by this guy. His non-movie work is perhaps even cooler,
given the constraints of building things that actually work:

Luminous Room

Speed is in fact important. Human level intelligence is not a symbolic mathematical problem just can just simulate. Instead you have to "do it", that is replicate it in a real environment. A brain without a body makes no sense (even though I liked that Steve Matin movie). During evolution the brain and body of the human co-evolved and they remain totally dependant on each other. Unfortunately those clasically symbolic manipulators, among who you can count Dr. Richard Wallace, who calls their research Artificial "Intelligence" are still stealing headlines. What they do might be interesting from a matematical point of view but has no interest if you want to understand human level intelligence. The brain doesn't work by manipulating rules to infer an answer. Wheater you do that on a pocket calculator or a supercomputer makes no difference. You won't get it right. The brain needs a body which interacts with a physical environment in order to show intelligence. A physical environment follow the laws of physics which is why speed _is important_. You can't speed up the physical laws. In 1986 Rodney Brooks published a paper called A Robust Layered Control System for a Mobile Robot in order to get AI research on the right track. He was only partly successful, but at least at MIT where he is now the leader of the AI lab, people are doing interesting research now. Another good pointer is his resent book Flesh and Machines: How Robots Will Change Us. More information on embodied intelligence - a brain needs a body - can be found in the very good by Rolf Pfeifer (leader of the AI Lab in Zurich) called Understanding Intelligence". Please stop making a fuzz about talkbots and stuff like that, it's really not that interesting.

This article has presented hermeneutics primarily as a philosophy of understanding rather than as a set of technologies for interpretation in specific domains. As such, the hermeneutic tradition seems able to speak to AI researchers in two distinct ways. First, hermeneutics provides some basis for arguing against the feasibility of the AI project, at least under its present dispensation. Whether represented by Dilthey's idea of empathetic understanding or Heidegger's idea of situated understanding, hermeneutics seems to have discovered a quality in the human situation that is vital for knowledge of others and oneself but has not yet been simulated mechanically. Because these doubts are generated from a ongoing
intellectual tradition and because they refine some fairly common intuitions, they cannot easily be dismissed as ``irrational technological pessimism.'' On the other hand, these doubts should stimulate attempts by AI researchers to overcome them, as were some of the doubts raised by Dreyfus (1972). At the very least, then, the insights of the various hermeneutical camps can be expected to receive increasing attention in the artificial intelligence community.

Hamlet, Act I, Scene III

Pollonius is giving a fatherly speach to his son Laertes (the brother of Ophelia):

...
Neither a borrower nor a lender be;
For loan oft loses both itself and friend,
And borrowing dulls the edge of husbandry.
This above all: to thine ownself be true,
And it must follow, as the night the day,
Thou canst not then be false to any man.
Farewell: my blessing season this in thee!

For the full scene, see this MIT site.

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.

I am just curious. Would the way an asynchronous chip worked dictate anything about the instruction set of the chip? Would it be possible to use today's instruction sets in an asyn chip? Would you have to come up with something different? Would someone writing an asyn compiler have any special issues or optimisation techniques they would have to be aware of that would be inherent to the concept of the asyn chip itself?

Are there any "features" related to the asynchronocity of the chip that it would be possible to add to the assembly language of an asyn chip? Becuase individual sectors of the chip can function independently and not have to synchronize, can you kind of get a multiprocessing-within-a-single-chip effect? I.E. can you create a singular asyn chip split up into separate sectors, each of which functions as if it were an autonomous processor? Can you have one chip concurrently execute single threads?

If the answer to this last question is "yes", do you have to do this by organizing the chip such that the different sectors are basically seperate chips on the same cast, or can you just have it so that the exact borders of the the chip area working on a certain thread at a certain moment is reconfigured dynamically? Would it be possible someday to create a microchip whose internal execution model is somewhat like that of Cilk?

How does asynchronous design fit in with atomic-execution technologies like VLIW and EPIC?

Even wearables are struggling to get 640x480, which is the smallest screen I would use for anything 3D.

On the upside, Nokia has a very good history of being innovative in the mobile market, more power to them. If they can get a usuable 3D device to market, I'd buy it.

This is not to say that I didn't enjoy playing Doom on a Nokia 9210

I enjoyed Quake on my iPaq too =)

I know what you mean, since I've picked up a lot of theory in similar ways over the years. Along those lines, Lambda the Ultimate is a good place to get pointers to a variety of current research. It's worth getting at least some of the theory closer to its source. Have you read SICP, for example? That was one of the books that got me back into theory after many years out of CS at university (the CS I did was pretty lame - mainly learnt Pascal, very little real CS theory).

If you're into that sort of thing, though, SICP is just a gateway drug. Lambda calculus, type inferencing, type theory in general, and much, much more follows, and pretty soon all the mainstream languages are looking pretty pale... It all does give some good criteria by which to compare languages, though, and helps avoid being limited in one's thinking by the language one happens to be using.

BTW, I agree about not teaching closures in Perl to newbies. Perl and Python both have enough hardcoded ways to do things that you don't need to rely on closures, except to be perverse. The more important concept for useful programming is higher-order functions, since they provide a capability that's directly useful in Perl (or any language), and closures can be introduced in that context.

You've probably come across this before, but here's a nice piece about ML's type system from a partly Perl perspective.

I can't wait for the Yattabyte to come into common usage..

Just think of all the stuff I could put on one of those discs!

And as a bonus, an original Tetris download is available too...

Here's a Cnet article dated back to 4/2000. If you want to relive those glory days (err, day, night, something), click here. (Requires Java) I thought the idea was pretty good, at the time. My mother broke my Gameboy playing that a few years back. She was that into it. Now she plays a whole bunch of Tetris clones online. And she thinks I'm bad with RTCW and NWN... =)

This would also mean they are using Interactive C (a stripped down version of C) for their programming.

Though, yes, handyboard would normally imply something C-like...

It's still up at MIT. MIT just uses http://web.mit.edu for their main site--the egg is at http://www.mit.edu/404.html.

It's still up at MIT. MIT just uses http://web.mit.edu for their main site--the egg is at http://www.mit.edu/404.html.

Ever hear of Flirting with Nazism?

The Cambridge is what drew me online.

We got these cool computers at school which had this cool thing called html... then I found things like telnet and wow! (before then I had only used lame AOL at my friends house-it was fun, but not functional)

Then I could finger coke machines and it was great... I knew we had to get on the internet at home! Of course then it didn't take long to browse all Yahoo! had to offer and I was on-line at a blazing 9600 baud.

Connected devices have always been my favorite things, and it's what I've used to this day to get people excited about the internet.

But, I think this is the coolest thing I've seen (text version) besides this.

I was addicted to my garden!

The Cambridge is what drew me online.

We got these cool computers at school which had this cool thing called html... then I found things like telnet and wow! (before then I had only used lame AOL at my friends house-it was fun, but not functional)

Then I could finger coke machines and it was great... I knew we had to get on the internet at home! Of course then it didn't take long to browse all Yahoo! had to offer and I was on-line at a blazing 9600 baud.

Connected devices have always been my favorite things, and it's what I've used to this day to get people excited about the internet.

But, I think this is the coolest thing I've seen (text version) besides this.

I was addicted to my garden!

Okay.... let's go over this clearly.

Source for info on what Air and Silicon is: MIT

Air is an insulator with incredibly high resistivity
Pure Silicon is a semiconductor with reasonable resistivity

Now if we introduce air bubbles into Pure silicon or chicken feathers. We introduce resistivity. Which is the number one thing, we _don't_ want in an electrical circuit (especially a small one) because resistance = heat = melting wires.

Sure, electromagnetic _waves_ travel faster through air, but electrons don't travel at all through the air, that's why we aren't being electricuted on a daily basis.

I really think the writer of this article needs to hire a science advisor so he understands basic current electrics.

application server: here and here

IDE: here, here, here

Oops, you really mean, written in Perl? Sorry, apparently all those tried, failed.

Exactly. And as long as the truth gets out, there should really be nothing to worry about.

There are still two possible problems.

• Patents. Nothing new here, just the usual problem of software patents being inherently evil.
• Legislation. As long as the so-called "content industry" has nitwits like Sen. Hollings in their pocket, general purpose computing faces the threat of being outlawed.

As long as you can continue to use your general purpose computer without going to jail, the free market will dispose of ill-concieved notions like Palladium quite nicely.

So what's the ultimate if OSX is the penultimate? I'd much rather use the ultimate. :P

Maybe if you get in contact with these people, you could help them with their research and get a free headset out of it? Just a thought.

I bought a kinesis after I got low-grade carpal-tunnel syndrome from too much programming, and decided that since it was going to take me a while to get used to I might as well switch to Dvorak too. After about a week I realized Dvorak had some serious problems:

• It didn't take finger strength into account
• Commonly used programming symbols (brackets, semi's, >'s, <'s) are a pain to get to
• Your fingers rest differently on a kinesis
• Some other things I can't remember anymore

The first one was my biggest concern because my main goal was to be comfortable while typing. Under Dvorak your little fingers rest on the extremely common "a" and "s", the uncommon "u" is right under the index finger and is thus easier to type than it needs to be, etc. etc.

I found some letter usage charts online but didn't trust them so I made up my own with a simple perl script, the Linux HOWTO files and a bunch of and coding (in java and perl mostly) that I'd done. The raw results are here. I found my letter usage to be slightly but importantly different, so I spent a few hours designing the above mentioned keyboard layout with comfort as the goal. I targeted it towards programming java and perl in Emacs on a kinesis by putting the most common letters within easy reach of the strongest fingers, making common two letter combos easy to get to, and making common programming chars and emacs commands easy to type.

Let me know if you try it, I'd be interested to hear if it helps.

I bought a kinesis after I got low-grade carpal-tunnel syndrome from too much programming, and decided that since it was going to take me a while to get used to I might as well switch to Dvorak too. After about a week I realized Dvorak had some serious problems:

• It didn't take finger strength into account
• Commonly used programming symbols (brackets, semi's, >'s, <'s) are a pain to get to
• Your fingers rest differently on a kinesis
• Some other things I can't remember anymore

The first one was my biggest concern because my main goal was to be comfortable while typing. Under Dvorak your little fingers rest on the extremely common "a" and "s", the uncommon "u" is right under the index finger and is thus easier to type than it needs to be, etc. etc.

I found some letter usage charts online but didn't trust them so I made up my own with a simple perl script, the Linux HOWTO files and a bunch of and coding (in java and perl mostly) that I'd done. The raw results are here. I found my letter usage to be slightly but importantly different, so I spent a few hours designing the above mentioned keyboard layout with comfort as the goal. I targeted it towards programming java and perl in Emacs on a kinesis by putting the most common letters within easy reach of the strongest fingers, making common two letter combos easy to get to, and making common programming chars and emacs commands easy to type.

Let me know if you try it, I'd be interested to hear if it helps.

I bought a kinesis after I got low-grade carpal-tunnel syndrome from too much programming, and decided that since it was going to take me a while to get used to I might as well switch to Dvorak too. After about a week I realized Dvorak had some serious problems:

• It didn't take finger strength into account
• Commonly used programming symbols (brackets, semi's, >'s, <'s) are a pain to get to
• Your fingers rest differently on a kinesis
• Some other things I can't remember anymore

The first one was my biggest concern because my main goal was to be comfortable while typing. Under Dvorak your little fingers rest on the extremely common "a" and "s", the uncommon "u" is right under the index finger and is thus easier to type than it needs to be, etc. etc.

I found some letter usage charts online but didn't trust them so I made up my own with a simple perl script, the Linux HOWTO files and a bunch of and coding (in java and perl mostly) that I'd done. The raw results are here. I found my letter usage to be slightly but importantly different, so I spent a few hours designing the above mentioned keyboard layout with comfort as the goal. I targeted it towards programming java and perl in Emacs on a kinesis by putting the most common letters within easy reach of the strongest fingers, making common two letter combos easy to get to, and making common programming chars and emacs commands easy to type.

Let me know if you try it, I'd be interested to hear if it helps.

Yes, it is interesting to see the secrecy labels and warnings on the old Apollo Guidance Computer documents. Wouldn't want everyone building Moon rockets...of course, at the time a guidance computer was dangerous due to competition to engineer nuclear missiles. (Now there's more computing power in a handheld GPS unit than is needed by a simple ballistic missile)

Design patterns for human-computer interaction are nascent but document well the common metaphors used in nearly all GUI computer applications today:

http://www.mit.edu/~jtidwell/interaction_patterns. html

For a few of the european hosts, we use GPS time receivers, primarily the Motorolla Oncore UT+ kits. You can get eval units of these, google around. They're nearly as easy to use, but do require a kernel config change.

It's really kind of addictive playing with time. :-) And you get spoiled by never having any clock weirdness on any of your machines...

Read a few college math course syllabus (syllabi? ) and buy the books that the class would be using.

I suggest a good college as your baseline.

http://www-math.mit.edu/undergraduate/class-textbo oks.html

Are you referring to this?

And now bills were passed, not only for national objects but for individual cases, and laws were most numerous when the commonwealth was most corrupt.

When there's something you want to change in your hardware-based rendering, what are you going to do, re-fab the silicon and solder it in?

You could start with an architecture similar to Andrew Huang's five-or-so-year-old Tao reconfigurable computing platform, with pipelining de-emphasized. system speed approximately doubled, and (possibly) multi-ported memory added.

-jhp

multi-threading is why, for example aolserver can do with one process what apache needs a bunch of processes to do. (though i digress, aolserver only has to run tcl interps, where apache is much more versatile.)

meanwhile, both FreeBSD and NetBSD are trying to get SMP and scheduler activations into their kernels. this would improve their support for multi-threading substantially. there's a paper which explains this better than i ever could.

I was in Japan for two years, and did extensive programming on the iAppli (Java that runs on iMode phones) and J2ME platforms. I even wrote a web browser for J2ME. You can see it all and get the source at http://www.ai.mit.edu/people/hqm/imode and also at sourceforge, look for the http://bearlib.sourceforge.net/ bearlib libraries.

Absolutely. I wrote a client/server jukebox program a while back to get me this functionality. The server stores the playlist internally and uses mpg321 (mpg123 gave me some problems) to play the music. Any number of clients can connect and modify the playlist, and then disconnect without disrupting the playlist. It would be very nice to be able to use XMMS as a client for my server.

The code is not particularly great, but it works well on our mp3 archive, which is stored on a headless machine with only 32 MB RAM and a 200MHz processor. I never released it to the public before, but if anybody wants to check it out, it's at http://locust.lcs.mit.edu/cgi-bin/viewcvs.cgi/flyn n/. It is written in Perl.

Before trying to make XMMS able to talk to it, it would probably make sense to change it to use TCP instead of Unix domain sockets. Right now the client has to run on the same machine as the server.

noah

The most hilarious part of that whole Beijing news story was the initial statements from the editor:

"How do you know whether or not we checked the source before we published the story?" Yu demanded in a phone interview. "How can you prove it's not correct? Is it incorrect just because you say it is?"

Goes to show that some people in power over there really do have a different mindset about things.

daypop is another good blog scourer, with searching functionality too.

One of Slashdot's downsides compared to blogs is that it's really pretty slow. Usually by the time one of the editors makes the decision to post a story to the front page, the story is several days old.

Google ratings are only a side benefit of blogs. Many actual humans actually read them.

One thing that I wonder about is Slashdot's searchability, how it's rated by Google and other search engines. I've never once been directed to a Slashdot thread as a result of a search which is a pity because there's such excellent information and insight here at times. I wonder if Slashdot have taken steps to improve the searchability/URL indexing of Slashcode-based sites.

BTW, thanks for pointing out Blogdex, looks very interesting; I'm one of those who haven't yet developed the blog habit.

One of Slashdot's downsides compared to blogs is that it's really pretty slow. Usually by the time one of the editors makes the decision to post a story to the front page, the story is several days old. By this time, many bloggers have spread the story among them, and many more people have read the blogger's entries. This is one of the reasons I often visit blogdex, because I usually read a story on there before the slashdot readers at work do.

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.

It's been the most blogged about issue in blogspace for the last 24 hours.

Bloggers are strong and growing, perhaps more so than ./?

I don't think it makes sense to say we have to wait and have technology advanced enough to stop a large asteroid/comet before we begin to compile a list of dangerous objects.

Everyone knows bout BSD's failure and imminent demise. As we pore over the history of BS, 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.

This PDF is a paper by Rodney Brooks, a brilliant (if somewhat obsessed) man who runs the AI lab at MIT, and was featured in Errol Morris' "Fast, Cheap and Out of Control", the title of which was taken from this piece. The robots described herein are, IMO, the really exciting development... no real internal representation of the outside world was involved; rather, the robots have some set goals, and some set abilities, and essentially fend for themselves without any direct "instructions" other than "Achieve the goal". There has been a lot of work done in this area in recent years - building robots modelled on biology and evolution rather than mechanical representations of the world - and the results are consistently fascinating. A favorite story involving such robots was of an "ant" that was built, whose sole goal was to seek light; it learned to walk on its own, and then somehow (don't recall if the researchers did this intentionally or not), it busted a 'leg'. Soon, after fumbling around a bit, it re-learned how to walk with a busted leg. Amazing stuff. Quite a fascinating read, this.

-d

eweek is linking to a report (PDF format) from a student at MIT detailing how Microsoft is using a hardware-based encryption key in the Xbox. The bad news? The key is identical in every unit.

O'Reilly Open Books Project
Bruce Eckel's "Thinking in..." books
Data Structures and Algorithms books
MIT's Structure and Interpretation of Programming Languages
Numerical Recipes series
Handbook of Applied Cryptography
The Art of Assembly Language Programming
Object-Oriented System Development
GTK+/Gnome Application Development
GNU Autoconf, Automake, and Libtool
Effective Perl (partial)
Programming Pearls (partial)

I guess what I'm looking for is 'visual excitement'. Or rather, output that enables a lay user to pick out patterns and clusters on his/her own, using the brain's built in visual processing mechanisms. I've seen some work on this, but nothing quite mature, and much of it not released even in binary form (one thing I took particular interest in, for example, is in academic copyright limbo).

However, there were quite a few things at that link I hadn't found before, and one or two seem somewhat useful to my purposes, though the visual design and interface are somewhat lacking. Those were probably judged as not ever relevant by those writing the programs, but I find it hard to understate the importance of those aspects for something as explicitly visual as information visualization.

Thanks.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncovr 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.