Slashdot Mirror

They are only called Bruce by eachother, and only to keep things clear. Their real names are Eric.

Just like the plural of ox is ices

That's why I got a Mac, which has great shift left / shift right performance!

This is a great time to sing the Programmer's Cheer:

Shift to the left!
Shift to the right!
Pop up, push down,
Byte, byte, byte!

Although "theory of programming" is rather weakly defined:
"The Art of Computer Programming" by Knuth
"Programming Pearls" by Bentley
"Godel, Escher, Bach: An Eternal Golden Braid" by Hofstadter
"The Tao of Programming"
Jargon File

Yes, what he said. Also, read the Jargon File. Anything it recommends is a good read. See the entries for Dragon Book for compiler design, for example.

So while 'porting an open-source Prism driver from Berkeley Unix to OS X' is an admirable task, it is not even close to being a hack, by any definition.

Sure, slashdot might post driver development news regularly, but that doesn't make it any less mundane.

"I've been super impressed by OS X having used it as my primary laptop for the last couple weeks. It really is a great unix box- and this is one of the important missing puzzle pieces."

For the n'th time, OS X != UNIX!!!


Tell Apple that.

http://www.apple.com/macosx/jaguar/unix.html

While you're at it, tell ESR too. BSD = "a family of Unix versions".

http://www.tuxedo.org/~esr/jargon/html/entry/BSD.h tml

Lame.

Why wouldn't I just copy the damned DVD myself, since, well, duplication wouldn't be illegal.

Cost and convenience. Unlike us slashdotters, many people don't have broadband, a DVD burner and time to spend downloading and burning.

That's what makes the net so much better than a music or software store, because bandwidth is cheaper than media

Perhaps some day, but not yet. Mass production of prerecorded media and shipping is still cheaper per unit than broadband and rewritable media. "Never underestimate the bandwidth of a station wagon filled with magtape"

Then let the people who want to make those large initial investments pay for it.

In the pre-copyright days, that was the normal way of funding - patronage or pay-per-opera.

That system is also possible today, but in addition you also have the system enabled by copyright - someone covers the initial expenses and hope to make their money back by selling copies in the marketplace.

I happen to think that copyright is fine as long as it serves the original purpose, "To promote the Progress of Science and useful Arts". However, the term of copyright should be sensible - life+70 or 90 years is just plain silly, there must be sensible "fair use"/"fair dealings" holes, and Digital Restriction Management is just crazy.

>Assembly: Listen to you young whipper-snappers whine. In my day we walked through 10 miles of printouts without any shoes, and we liked it!

Those in the U.S. who had cable TV in the early 90's probably recall TV Guide Channel's precursor, Prevue Channel. This channel used to be in my hometown's cable company's lineup, cycling through the program listings over and over. As it happens, the channel's video was fed from an Amiga equipped with a Video Toaster. How do I know? "Guru Meditation", of course; it happened at least once a week, flashing a bright red box over a black background around the error message, asking the user to "press the left mouse button to reboot".

As for the origin of that phrase, ESR kindly provides us with this explanation.

Depending on your opinion of the Jargon File, you may find this definition much more canonical.

The true canon, of course, would be Heinlein's novel, but I wouldn't wish that on anyone :)

Depending on your opinion of the Jargon File, you may find this definition much more canonical.

The true canon, of course, would be Heinlein's novel, but I wouldn't wish that on anyone :)

show me where in the GNU Free Software philosophy it says anything about market forces. I'm sorry, but you've got open source and free software mixed up thanks to the king of flatulence

Mel??? is that you?

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.1 BSD 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 that 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 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 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.

You don't understand how a company that sells something other than software might require a programmer? Then I sugest you read The Cathedral and the Bazaar by Eric Raymond.

If he does not like Torvald's kernal, then he can write a GNU one. What's the holdup? BSD?

He *does* like the Linux kernel, I think...that's why he's trying to keep it Free. And GNU *is* working on their own kernel: the HURD. It's been in development a long time. I do not know what the holdup is, but I can't imagine it has anything to do with BSD, which is a completely independent, non-GNU project.

RMS is a troll: not because he is wrong, but because he is annoying. (Hey, I can relate WRT OO bashing).

Whether he's annoying or not, I don't think you can really call him a troll. A troll is someone who says divisive or combative statements that they don't really believe, just to induce a flamewar.

Say what you want about RMS, but I don't think anyone would agree that he doesn't Really Believe what he says.

Really, I think that it is best to be language agnostic: happily use any language someone pays you to use.

Just take a look at the superstud you'll become afer ESR instructs you in the art of making sweet love.

Results are guaranteed or your money back.

Just take a look at the superstud you'll become afer ESR instructs you in the art of making sweet love.

Results are guaranteed or your money back.

Jargon Dictionary

Sysadmin? Hacker writing style. Don't quote the period, don't capitalise a name, never use italic when you can _underscore_.

Obviously, the developers at Peercast haven't read ESR's "The Cathedral and the Bazaar". It describes how the best time to open the source code is in the immediate stages of the product, so that it gets the bugs seen and fixed as soon as possible. If they have the code, and if they want to GPL it and make it available, then what's stopping them? Sourceforge is available and wouldn't cost them a thing.

No, more likely they're using the Mongolian Hordes Technique. It's much more appropriate in this sense

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 soon 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 dying 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 the 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 quickly 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 dying 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 an ugly 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 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 quite liked Ed Felten's idea to use the work 'tinker' to mean what we understand by 'hack' (as in 'Freedom to tinker').

I'm just still not sure what to call a hacker. A tinkerer, or tinker? It doesn't quite have the same connotations really.

It's insane how litigeous America is nowadays.

For example: There are currently 600,000 lawsuits involving asbestos - alone - in the legal system. Older doctors are retiring sooner because they can't afford malpractice insurance.

The very threat of litigation is enough to shut most people up, especially when you have SLAPP suits (Strategic Lawsuits Against Public Participation) and when your organization has the obvious ability to win a DSW.

yhl.

hand.

(Use the Preview Button! Check those URLs! Don't forget the http://! Don't forget to lick a dick a day!)

Don't make fun of poultry production. No poultry production experts, no food for geeks...

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.

Ender's Game (Great book by Orson Scott Card, btw)

That's one of my two favorite books. I guess Ender's Game resonates with a lot of Slashdot readers. It've seen it mentioned here a couple of times, but never anywhere else. For those who haven't read it, it's science fiction about a smart kid who doesn't fit in, and some awesome "war gaming".

An odd thing though, in my oppinion the sequels to Ender's Game sucked, as did everything else I've read by Orson Scott Card.

My other favorite book is Neuromancer by William Gibson. Also science fiction, it is the original cyberpunk novel. A must-read for any hacker.

-

Well, there's The Jargon File, a.k.a. The New Hacker's Dictionary, which the writers could presumably consult whenever they write anything with a geek factor greater than 0. However, even The File's contents can be tough to grok by non-geeks, so I've decided to condense it into a form more easily digested by non-geeks:

Hacker good, cracker bad!

Hopefully they'll get that one.

(I make no warranty of accuracy of my statements.)

Hmm... this sounds like an obvious troll, but since you've been modded insightful, I'll byte.

The term "hacker" has a lot of confusion tied to it. Where I come from it's a term of respect for someone's raw technical abilities. A hacker is someone who is so good at taking things apart and understanding them that they can make gadgets and software do things the original designers never dreamed of. If you think everyone fitting that description without "proper approval" belongs in jail you've got another think coming.

Maybe when you say hacker you mean someone who breaks into systems belonging to someone else without permission. Yes, that is a minor criminal act, much like trespassing. And there is no excuse for responsible adults doing such things without very good reason, but kids will be kids (Sometimes a system is so insecure this can happen by accident. )

The term hacker in general usage today usually covers both the system hacker who gains access to systems not belonging to them as well as the software hacker who takes apart software they have rightfully purchased on their own system. Classically system hacking has been seen as wrong or illegal, but software hacking has always been accepted, and only disclosure has ever been at issue. The DMCA attempts to deal with both in one fell swoop and does so very badly. I take your comment to mean we should just enforce the law to it's fullest even while it is changing in subtle and terrible ways.

White hats hide information. It seems they *never* disclose exploit code. Black hats hide information. They only use vulnerabilities for themselves. It would seem to be only Grey hats who hold the advancement of security important by sharing their code and knowledge fully. In fact, I'd say it is highly unethical for a White hat to get a vulnerability fixed without ever disclosing it. Perhaps we need criminal penalties for that as well? It also seems a tragedy that white hats will never be inclined to disclose their exploit code even after a fix has been made. They just don't seem to realize that information sharing really is a power positive good. (wasn't that the hacker eithic?)

Actually there are a whole host of other things White hats can and do that are wrong. Like implanting spyware in a product or being negligent in protecting customer information. I don't see criminal penalties for those...

We don't call burglars black hats and alarm system installers white hats.

Your post indicates that you think to earn the title "hacker" you have to break into other people's computer systems. Well, that's one definition I suppose (one I hate, and I'm not the only one ), but it is by no means the only definition.

Anyway, in order to answer to the overall theme of this thread - "why the coloured hats" - it is helpful to understand both the history of the term "hacker", and appreciate the prevalence of moral relativism. So, if you're sitting comfortably, then I'll begin...

The origins of the term "hacker" being used in relation to computers are described in the very detailed and entertaining book Hackers: Heroes of the Computer Revolution by Stephen Levy. From the Amazon editorial review:

Steven Levy's classic book explains why the misuse of the word "hackers" to describe computer criminals does a terrible disservice to many important shapers of the digital revolution. Levy follows members of an MIT model railroad club--a group of brilliant budding electrical engineers and computer innovators--from the late 1950s to the mid-1980s. These eccentric characters used the term "hack" to describe a clever way of improving the electronic system that ran their massive railroad. And as they started designing clever ways to improve computer systems, "hack" moved over with them.

So how did the meaning of the word change?

Well, this is where moral relativism comes in. It's human nature to justify yourself, and that's what people did. When mischievous computer users began entering computer systems without authorisation they justified (in their own minds) themselves by claiming that they weren't doing any damage - just satisfying their curiousity.

"I'm not a criminal, I'm a hacker", they'd say.

Hence you have an entire culture of people that rate each other according to technical ability and/or morals, spawning such terminology as "lamer", "elite", "black hat", "grey hat", "white hat", and "script kiddie"; but funnily enough, it all seems to come down to the fact that people don't want to admit that they are doing something wrong - there is always someone worse than them.

We don't call burglars black hats and alarm system installers white hats.

Your post indicates that you think to earn the title "hacker" you have to break into other people's computer systems. Well, that's one definition I suppose (one I hate, and I'm not the only one ), but it is by no means the only definition.

Anyway, in order to answer to the overall theme of this thread - "why the coloured hats" - it is helpful to understand both the history of the term "hacker", and appreciate the prevalence of moral relativism. So, if you're sitting comfortably, then I'll begin...

The origins of the term "hacker" being used in relation to computers are described in the very detailed and entertaining book Hackers: Heroes of the Computer Revolution by Stephen Levy. From the Amazon editorial review:

Steven Levy's classic book explains why the misuse of the word "hackers" to describe computer criminals does a terrible disservice to many important shapers of the digital revolution. Levy follows members of an MIT model railroad club--a group of brilliant budding electrical engineers and computer innovators--from the late 1950s to the mid-1980s. These eccentric characters used the term "hack" to describe a clever way of improving the electronic system that ran their massive railroad. And as they started designing clever ways to improve computer systems, "hack" moved over with them.

So how did the meaning of the word change?

Well, this is where moral relativism comes in. It's human nature to justify yourself, and that's what people did. When mischievous computer users began entering computer systems without authorisation they justified (in their own minds) themselves by claiming that they weren't doing any damage - just satisfying their curiousity.

"I'm not a criminal, I'm a hacker", they'd say.

Hence you have an entire culture of people that rate each other according to technical ability and/or morals, spawning such terminology as "lamer", "elite", "black hat", "grey hat", "white hat", and "script kiddie"; but funnily enough, it all seems to come down to the fact that people don't want to admit that they are doing something wrong - there is always someone worse than them.

So the online thing is great to a point. But you gotta have the real world behind it.

I use ESR's gif2png to convert my legacy GIF files to PNG for web use. I provide Solaris SPARC and x86 packages (Linux packages are available elsewhere).

http://www.tuxedo.org/~esr/jargon/html/entry/boxen .html

Welcome to Slashdot, where it gets to be 'Usenet in September' all year round. Boxen is a fairly standard bit of slang, but excuse me while I take my hissy fit outside now.

I carry all my logins etc. in my PalmOS device, encrypted in a Blowfish-protected database, and synched to my personal computer when I'm back in the office. I have to enter one decent password to get at my data, and if I lose the PDA I suppose someone could crack it if they *_really_* wanted to, but at least I know the data are NOT on a Microsoft/Sun/Liberty Alliance box where some disaffected BOFH can get to it.

YMMV.

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

And don't even get me started about the id10ts who make an artform of run-on sentences.