Slashdot Mirror

You do realize, don't you, that there is a word for that kind of activity?

sounds like marketroids were at work here. i think reading brainwaves would fall under "products that violate laws of physics"

What I find interesting are the people who insist on saying UF is shite... If they really hate it, and if they aren't willing to have an open mind on the subject, why read this review?

Consult the jargon file.

Sorry to single you out but it's sad how many posters on /. feel the need to insert an acronym or two just for the hell of it...[w]ould the fifteen seconds that it would have cost you to provide a little clarity kill you?

When's the last time you heard someone here speak of the American Standard Code for Information Interchange? Discussions on the Digital Millennium Copyright Act (or worse, the Consumer Broadband and Digital Television Promotion Act) would get unnecessarily verbose were it not for the various abbreviations and acronyms that are in common use.

Abbreviations to refer to the various Star Trek movies might confuse in a forum with a more general audience...but in a forum (such as this) that's visited mainly by geeks and with Star Trek as the subject, it's not unreasonable to expect a certain minimal knowledge of common jargon used by that group of people.

(Besides, a simple Google search would point a n00b in the right direction. If you're not willing to do a minimal amount of fact-finding on your own, maybe you'd find this service more to your liking.)

I believe that the technical term for this kind of situation is called "gorilla arm". Named after the ape-like stance that eventually develops after using a touch-screen kiosk for a long period of time, primarily as a result of fatigue from holding your arm up while doing input.

Never ascribe to malice that which could merely be incompetence

PLEASE, PLEASE don't say "boxen." The plural form of "box" is boxes. Saying "boxen" makes it seem like you played too much D&D.

Now, if he was talking to you personally, then you might have a case, as people want to settle on a specific ontology when speaking directly to one another. In fact, he is more-or-less on target with his jargon with respect to this public forum. You are off target and intolerant of those unlike you, so perhaps you should think about going somewhere else. Just a thought...

Sorry, dude. I invoke Godwin's Law.

You lose. ;-)

Not a troll. Not a flaimbait.

I know, I know... YHBT . YHL. HAND.

Though I suppose it doesn't strictly apply in this case, as nobody is arguing the counter-case in support of the RIAA.

Parkinson's Law of Data: Data expands to fill the space available for storage

Asimov's corollary to Parkinson's Law of data: Backlog expands to overfill planned extensions.

I'm sure we'll find a way to use it...

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.

7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations.

Or perhaps the M.I.T. definition fits:

At MIT, a "hacker" is someone who does some sort of interesting and creative work at a high intensity level. This applies to anything from writing computer programs to pulling a clever prank that amuses and delights everyone on campus.

Both definitions fit the Phantom Edit pretty well. (You might also want to take up the issue with michael, who called the Build Your Own Cityscape project a "nice hack job," yet there's not a computer in sight.)

Larry Niven, author of the Ringworld books, among others is hardly obscure. He also coined the term flash crowd. Google, as always, turns up a wealth of information.

On a related note, due to the inherent instabilities of a ringworld, I would suggest looking for signs of jets (or other methods of in-space propulsion) around the peripherary of the disk. That should provide significant evidence as to whether it's really a ringworld, or "just" a belt of dust, as the article indicates.

Check this out for more info on the hacker culture, especially the OpenSource types. It looks like the HTML got eaten, but there's a postscript file there.

from the jargon file:

Godwin's Law: [Usenet] "As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one." There is a tradition in many groups that, once this occurs, that thread is over, and whoever mentioned the Nazis has automatically lost whatever argument was in progress. Godwin's Law thus practically guarantees the existence of an upper bound on thread length in those groups. However there is also a widely- recognized codicil that any intentional triggering of Godwin's Law in order to invoke its thread-ending effects will be unsuccessful.

How has 'building|making' been/is confused/missused/associated with 'destroying|demolishing' things?

Case :

I think before publishing material publicly, one should do some research and confirm sources/results with other relevant people on that subject.
(eg. confirm "hack[er|ing]/crack[er|ing]" with (a) guru[s] in computers, like ESR).

This goes aswell to the slashdot editors for their (subject)postings; and all other form of publishing (you know who you are).

Reference :
http://www.tuxedo.org/jargon/
http://www.tuxedo.org/jargon/html/entry/hacker.htm l
http://www.tuxedo.org/jargon/html/entry/hacker-eth ic.html
http://www.tuxedo.org/jargon/html/entry/cracker.ht ml
http://www.tuxedo.org/jargon/html/entry/cracking.h tml
http://www.everything2.com/index.pl?node=hacker
http://www.everything2.com/index.pl?node=dark-side %20hacker
http://www.everything2.com/index.pl?node=cracker
http://www.cs.berkeley.edu/~bh/hacker.html
http://home.planet.nl/~faase009/Ha_hacker.html
http://www.plethora.net/~seebs/faqs/hacker.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci212220,00.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci211852,00.html
....and many more are out there, on the World Wide Web.

How has 'building|making' been/is confused/missused/associated with 'destroying|demolishing' things?

Case :

I think before publishing material publicly, one should do some research and confirm sources/results with other relevant people on that subject.
(eg. confirm "hack[er|ing]/crack[er|ing]" with (a) guru[s] in computers, like ESR).

This goes aswell to the slashdot editors for their (subject)postings; and all other form of publishing (you know who you are).

Reference :
http://www.tuxedo.org/jargon/
http://www.tuxedo.org/jargon/html/entry/hacker.htm l
http://www.tuxedo.org/jargon/html/entry/hacker-eth ic.html
http://www.tuxedo.org/jargon/html/entry/cracker.ht ml
http://www.tuxedo.org/jargon/html/entry/cracking.h tml
http://www.everything2.com/index.pl?node=hacker
http://www.everything2.com/index.pl?node=dark-side %20hacker
http://www.everything2.com/index.pl?node=cracker
http://www.cs.berkeley.edu/~bh/hacker.html
http://home.planet.nl/~faase009/Ha_hacker.html
http://www.plethora.net/~seebs/faqs/hacker.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci212220,00.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci211852,00.html
....and many more are out there, on the World Wide Web.

How has 'building|making' been/is confused/missused/associated with 'destroying|demolishing' things?

Case :

I think before publishing material publicly, one should do some research and confirm sources/results with other relevant people on that subject.
(eg. confirm "hack[er|ing]/crack[er|ing]" with (a) guru[s] in computers, like ESR).

This goes aswell to the slashdot editors for their (subject)postings; and all other form of publishing (you know who you are).

Reference :
http://www.tuxedo.org/jargon/
http://www.tuxedo.org/jargon/html/entry/hacker.htm l
http://www.tuxedo.org/jargon/html/entry/hacker-eth ic.html
http://www.tuxedo.org/jargon/html/entry/cracker.ht ml
http://www.tuxedo.org/jargon/html/entry/cracking.h tml
http://www.everything2.com/index.pl?node=hacker
http://www.everything2.com/index.pl?node=dark-side %20hacker
http://www.everything2.com/index.pl?node=cracker
http://www.cs.berkeley.edu/~bh/hacker.html
http://home.planet.nl/~faase009/Ha_hacker.html
http://www.plethora.net/~seebs/faqs/hacker.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci212220,00.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci211852,00.html
....and many more are out there, on the World Wide Web.

How has 'building|making' been/is confused/missused/associated with 'destroying|demolishing' things?

Case :

I think before publishing material publicly, one should do some research and confirm sources/results with other relevant people on that subject.
(eg. confirm "hack[er|ing]/crack[er|ing]" with (a) guru[s] in computers, like ESR).

This goes aswell to the slashdot editors for their (subject)postings; and all other form of publishing (you know who you are).

Reference :
http://www.tuxedo.org/jargon/
http://www.tuxedo.org/jargon/html/entry/hacker.htm l
http://www.tuxedo.org/jargon/html/entry/hacker-eth ic.html
http://www.tuxedo.org/jargon/html/entry/cracker.ht ml
http://www.tuxedo.org/jargon/html/entry/cracking.h tml
http://www.everything2.com/index.pl?node=hacker
http://www.everything2.com/index.pl?node=dark-side %20hacker
http://www.everything2.com/index.pl?node=cracker
http://www.cs.berkeley.edu/~bh/hacker.html
http://home.planet.nl/~faase009/Ha_hacker.html
http://www.plethora.net/~seebs/faqs/hacker.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci212220,00.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci211852,00.html
....and many more are out there, on the World Wide Web.

How has 'building|making' been/is confused/missused/associated with 'destroying|demolishing' things?

Case :

I think before publishing material publicly, one should do some research and confirm sources/results with other relevant people on that subject.
(eg. confirm "hack[er|ing]/crack[er|ing]" with (a) guru[s] in computers, like ESR).

This goes aswell to the slashdot editors for their (subject)postings; and all other form of publishing (you know who you are).

Reference :
http://www.tuxedo.org/jargon/
http://www.tuxedo.org/jargon/html/entry/hacker.htm l
http://www.tuxedo.org/jargon/html/entry/hacker-eth ic.html
http://www.tuxedo.org/jargon/html/entry/cracker.ht ml
http://www.tuxedo.org/jargon/html/entry/cracking.h tml
http://www.everything2.com/index.pl?node=hacker
http://www.everything2.com/index.pl?node=dark-side %20hacker
http://www.everything2.com/index.pl?node=cracker
http://www.cs.berkeley.edu/~bh/hacker.html
http://home.planet.nl/~faase009/Ha_hacker.html
http://www.plethora.net/~seebs/faqs/hacker.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci212220,00.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci211852,00.html
....and many more are out there, on the World Wide Web.

How has 'building|making' been/is confused/missused/associated with 'destroying|demolishing' things?

Case :

I think before publishing material publicly, one should do some research and confirm sources/results with other relevant people on that subject.
(eg. confirm "hack[er|ing]/crack[er|ing]" with (a) guru[s] in computers, like ESR).

This goes aswell to the slashdot editors for their (subject)postings; and all other form of publishing (you know who you are).

Reference :
http://www.tuxedo.org/jargon/
http://www.tuxedo.org/jargon/html/entry/hacker.htm l
http://www.tuxedo.org/jargon/html/entry/hacker-eth ic.html
http://www.tuxedo.org/jargon/html/entry/cracker.ht ml
http://www.tuxedo.org/jargon/html/entry/cracking.h tml
http://www.everything2.com/index.pl?node=hacker
http://www.everything2.com/index.pl?node=dark-side %20hacker
http://www.everything2.com/index.pl?node=cracker
http://www.cs.berkeley.edu/~bh/hacker.html
http://home.planet.nl/~faase009/Ha_hacker.html
http://www.plethora.net/~seebs/faqs/hacker.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci212220,00.html
http://searchsecurity.techtarget.com/sDefinition/0 ,,sid14_gci211852,00.html
....and many more are out there, on the World Wide Web.

Everyone now 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.

That's a bang path.

I know this is a week old, and nobody'll ever see it, but...

Assuming that's really true, it is a pretty stupid and contradictory law

No, it's a very cleverly contradictory law, which, presumably deliberately, pretends to provide this exemption, but in fact ensures that the exemption is useless for its stated purpose, in a manner that I can only describe as Kafkaesque.

Also, I seem to recall that it's actually more complicated than what you quoted: actually, you are allowed to build the tool to look under the hood, provided that you are only doing it for the stated purpose, but you still can't give the tool to anyone else, even if they only want it for the same purpose. I.e., the rule against building such tools is precisely what it's an exception to, but the exception fails to extend to the rule against distribution, which would be necessary for it to be of any use.

As a result, only those very few people who have the technical skills to build the tool are actually capable of exercising their rights under this exemption, leaving everyone else in Kafka-land. Honestly, how many of us would have been capable of creating DeCSS on our own? No, I said honestly?

Then again, recognizing that such tools are necessary in order for people to exercise their rights, and letting this override the restrictions, would basically nullify the whole law -- there'd be no point to it then, since using the tools for other (i.e., infringing) purposes was already illegal under regular (pre-DMCA) copyright law. But then, the fact that the DMCA infringes on our right without serving any legitimate purpose has been our whole point, all along, now hasn't it?

In sum, I don't think Hanlon's Razor applies -- this is a case where it really is malice, not stupidity.

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.

Recompiling the compiler doesn't do anything to rid you of trojan code/back doors. If you need to ask why, take a look at "Reflections on Trusting Trust" by Ken Thompson, and the description of a back door in the jargon file.

The short story is, that the compiler decides what to output. So you have to trust your compiler.

The reason for the recompiling of gcc is something else entirely: It is to allow the source code of gcc to rely on gcc, and to allow an optimized compiler to be created.
For additional information consult a good book on compiler writing.

Gmanske.

Those weren't made by Winchester, rather they were called Winchester disks because the IBM 3340 (an early model) featured two 30MB volumes -- thus, 30-30, like the rifle. See the Jargon File for the reference.

Stop flicking my lights off and on!
You're scaring Mabel!

At least it has kept our government from forcibly disarming its citizens, making them into subjects instead of members of the government "of, for, and by the people." Note that your crime rate climbed after the confiscation that was supposed to stop all that crime. Guess what? Your crooks now have free rein to rob and pillage, since they're the only ones with firearms. You've fallen for the old liberal crap that disarming everyone will prevent crime. Here in the US, when the states passed "shall issue" laws that required states to issue concealed carry permits to anyone who was eligible, the liberals predicted blood running in the streets. In fact, in every single state that enacted such laws, the crime rates dropped, while the rates in other states continued to climb. Don't give me your holier-than-thou liberal bs - look at the facts before you spout rhetoric.

From the Jargon file: However there is also a widely- recognized codicil that any intentional triggering of Godwin's Law in order to invoke its thread-ending effects will be unsuccessful.

No. As even the slightest bit of research would have told you, Linus is Finnish, but his native tongue is Swedish. http://www.tuxedo.org/~esr/faqs/linus/

Quicktime, Windows Media, RealWhatever. They always appear in the task bar and the little icon tray thing at the bottom right. No matter how many times I try to remove the startup items it's guaranteed they will have returned on reboot. Aarrgghh! They even have Control Panel entries. This is software at its most rude and obnoxious. Why does RealWhateverItsCalledThisTime need a goddamned 'Start Center'? What's so special about low quality streamed audio and video that ot needs this special treatment? If every application did this I'd need a 3rd monitor for all the itty bitty icons. No wonder I need 2Gb of RAM!

Whiner. Back in the day we had to remove our startup entries by hand... Since I've got a Win98 box beside me:

1. Start in Startup; remove everything
2. Fire up regedit; HKLM -> Software -> Microsoft -> Windows -> CurrentVersion -> Run*; remove everything that shouldn't be in there
3. If you want to be double-paranoid then check WIN.INI, AUTOEXEC.BAT and CONFIG.SYS

I suppose a certain amount of judgement is needed to determine what can be safely deleted or not. But then again, you've got to learn somehow, eh? ;)

If that doesn't help you then STFW

Apparently it didn't. A quick Google came up with this info on foo and foobar.

In short, "it now seems more likely that FUBAR was itself a derivative of `foo' perhaps influenced by German `furchtbar' (terrible) - `foobar' may actually have been the original form." "Foo" seems to have a pre-war history, its "earliest documented uses were in the 'Smokey Stover' comic strip published from about 1930 to about 1952."

Apparently it didn't. A quick Google came up with this info on foo and foobar.

In short, "it now seems more likely that FUBAR was itself a derivative of `foo' perhaps influenced by German `furchtbar' (terrible) - `foobar' may actually have been the original form." "Foo" seems to have a pre-war history, its "earliest documented uses were in the 'Smokey Stover' comic strip published from about 1930 to about 1952."

Does this mean that Lintel (jargon file reference) is out?

Programmer time is expensive; conserve it in preference to machine time,

In the early minicomputer days of Unix, this was still a fairly radical idea (machines were a great deal slower and more expensive then). Nowadays, with every development shop and most users (apart from the few modeling nuclear explosions or doing 3D movie animation) awash in cheap machine cycles, it may seem too obvious to need saying.

Somehow, though, practice doesn't seem to have quite caught up with reality. If we took this maxim really seriously throughout software development, the percentage of application written in higher-level languages like Perl, TCL, Python, Java, and Lisp that ease the programmer's burden by doing their own memory management would be rising fast.

And indeed this is happening within the Unix world, though outside it most applications shops still seem stuck with the archaic Unix strategy of coding in C (or C++). Later in this book we'll discuss this strategy and its tradeoffs in detail.

One other obvious way to conserve programmer time is to teach machines how to do more of the low-level work of programming. This leads to...

Please see hack mode in the Jargon File.

This isn't exactly what you're looking for, but have you checked out The Art of Unix Programming by ESR? Only the first four chapters are written (plus the preface and TOC), but it looks like it covers a lot of what you're thinking of.

Eric Raymond has had the DeCSS source code on his page for a loooong time now. So its not like no one else is doing this.

http://www.tuxedo.org/~esr/css-auth.tar.gz

Eric Raymond has had the DeCSS source code on his page for a loooong time now. So its not like no one else is doing this.

http://www.tuxedo.org/~esr/css-auth.tar.gz

Billy The Adolf

:)

How many times have people here wailed at the non-tech press for using the word "hack" to describe what most would technically term a "crack"?

Sorry, but the press is right and all of you are wrong. From the Jargon File, sense 8:

[deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence `password hacker', `network hacker'. The correct term for this sense is cracker.

The problem with this is that the user of "hacker" as someone who breaks into computer systems WAS one of the original uses of the word. I don't recognize ESR's authority to "deprecate" the meaning of the word for his or anyone else's little ego reasons.

That's one of the word's original computer uses. Get over it.

If the linux kernel had been released using the BSD license it would still be popular
Why do I mention this? The point is that *how* the project is run has a lot more to do with how the development is managed than the details of the license. BSD *could* just as easily be run as a bazaar and I've seen plenty of GPL-licensed projects whither on the vine because for one reason or another the founders don't allow adequate control to the 'troops'. And OSS troops have a way of voting with their feet when projects don't meet their needs.

Many of todays license 'zealots' are seriously misinformed
I have read opinions on /. that BSD is somehow beholden to GNU because because "most of BSD is GPL code" Of course this is nonsense, yes lots of GPL code runs on BSD and some (e.g. gcc) is indeed part of the *BSD variants. However people who actually use the BSD's have probably observed that most of the OS tools are not the GPL variants; ls, cat, more ... are all quite different on BSD vs Linux. Hell, OpenBSD (the only current BSD I use) provides csh, and it's /bin/sh is a POSIX shell, not bash.

For all the "idealism" RMS and FSF are practical in what they do
Myth would have us believe that Linus is the king of practical and RMS will sacrifice no practicality on the alter of the GPL. I'm sorry but facts do not bear this out.

In '93 when I chose to push a little corporate $$ at FSF I purchased tapes for GCC, emacs, X11 and various GNU utilities. FSF was as happy to accept their $150 fee for X11 as the GNU pieces. Later, when Linux had quite enlivened the opensource arena RMS (in '98 I think) decided that the X license was bad (I think this is the same timeframe as he started in on the GNU/Linux rants).

I think it's notable that RMS/fsf have redoubled their efforts on the Linux kernel at the time that Hurd is finaly ready for prime time. I wish them well in yet another attempt to balkanize the landscape, I'm sure the Debian folks at least will be on the bandwagon ...Ho-hum ...

Now it's time for the ad-hominem ??
I'm sure RMS is a fine guy, and there are things about him that I find admirable. However, I truly find the tune he dances to to be all about RMS. Over the years he's used whatever tactic seems best to push his personal agenda. Honestly if I want to play power games I'd far prefer to do it in a context of leathersex or BDSM, which is a helluva lot more fun way to play power games imo.

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