Slashdot Mirror

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

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

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

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents [theos.com] 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.

When searching for a suitable localization system for my robotics project, I found a few research papers which detail the methods used to determine the location of a wireless node to an accuracy of 1 meter. Here are the papers, and here is the site that contains both the papers.

When searching for a suitable localization system for my robotics project, I found a few research papers which detail the methods used to determine the location of a wireless node to an accuracy of 1 meter. Here are the papers, and here is the site that contains both the papers.

When searching for a suitable localization system for my robotics project, I found a few research papers which detail the methods used to determine the location of a wireless node to an accuracy of 1 meter. Here are the papers, and here is the site that contains both the papers.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents [theos.com] 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.

• No interactivity - Program can not be created for the user. Requested songs not played within the hour or at a specified time.
• No more than 3 songs in a two hour period from the same album/CD
• No more than 4 songs in a two hour period from the same artist or box set
• No advance notice (published) of music, unless the format is classical and you have a history, prior to 1998 of doing it.
• Archived programs must be at least 5 hours long and not available for more than 2 weeks.
• Webcasters can't allow user, if feasible, from scanning for a particular song.
• Webcasters can't encourage users to copy/record music. If webcasters use a system that helps to prevent recording of the webcast, webcasters must enable the copy prevention option.

There are others in the linked text, and in the law itself.

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

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

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

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

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

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

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

Here is that version of Wilkin's Lord's Prayer.

"Changes: Sat May 31 19:37:25 CDT 2003. Slashdotting. Make attack files gzipped. Also made the destionation points of the slashdot links point to holder pages. (Why oh why didn't they link to this page directly, which has the info people want, instead of the actual paper?)"

Yeah, and I'm sure DJB loves to see this:

I highly advise using a universal hashing library, either our own or
someone elses. As is historically seen, it is very easy to make silly
mistakes when attempting to implement your own 'secure' algorithm.

(from the paper written about djbdns, addressed to DJB)

Students? I suppose technically, but the paper's principle author is a PhD candidate at this institution.
This is a far cry from the implied 'student' moniker everyone has been going on about 'round here. :-/
These are exactly the sort of people that should be looking at security problems. Especially when their findings include ways to avoid the problem, as their paper did.

Students? I suppose technically, but the paper's principle author is a PhD candidate at this institution.
This is a far cry from the implied 'student' moniker everyone has been going on about 'round here. :-/
These are exactly the sort of people that should be looking at security problems. Especially when their findings include ways to avoid the problem, as their paper did.

I skimmed the Project Page and aren't a couple of the examples awefully obvious?

The following one line of code brings every UNIX system I've run it on TO ITS KNEES WITHIN MINUTES!! This is a major vulnerability in EVERY UNIX system! Something must be done!

main() { while (1) if (fork() == 0) while(1); }

The project page is http://www.cs.rice.edu/~scrosby/hash/ and actually has details about individual vulnerable applications and test files for several systems. (And is kinder on the server for those who don't want to download the whole paper.)

One of the more idiotic quips I've heard (more than once, I'm sad to say) from creationists is, "If humans evolved from apes, then how come there are still apes around?" I can't speak for the creationists' immediate ancestry, but mine runs something like this: one of my great-great-grandfathers was named Ross. Among his offspring, one married a Thompson and produced children who were Thompsons. One of those children had children of her own who were neither Rosses nor Thompsons, but Icenogles. An Icenogle daughter produced me, who am none of the above, but a Riggins.

Thus, Rosses gave rise to descendants who are no longer Rosses. Some have become Rigginses. But some Ross descendants are still Rosses! There are still Rosses around, even though some of their descendants "evolved" into Rigginses, and a lot of other "species."

This isn't biological evolution, of course, but the principle is exactly the same: an ancestor can produce descendants which are very like itself (of the same species), while at the same time having other descendants which have become something else. The existence of descendants which have varied widely doesn't mean the original type has ceased to exist, or that there wasn't, in fact, a common ancestor. That's as true of anthropoids and Homo as it is of your ancestors, you, and those third cousins who retain the ancestral name that your branch of the family no longer uses.

Actually, the creationist quip of "if humans evolved from apes, how come apes are still around?" has a much more serious flaw than the fact that a species can still exist after another has descended from it. Humans did not evolve from apes. Humans share a common ancestor with apes. So a better analogy is that both I and my 3rd cousin are around, regardless of the fact that we share a common ancestor (our great-great-grandparents).

I thought it was interesting when I learned how long humans have known the Earth is round. In relatively modern (non-prehistoric) history, Eratosthenes measured the circumference of the Earth as 25,000 miles, which is basically correct. He did this in 230 B.C. He also used the fact that the sun is really far away, so the rays coming from it could be treated as parallel.

Another test you can do is to stand at about sea level and observe a ship. Then travel away from the ship on the ground and it will slowly go over the horizon. Then keep moving away but go up a mountain, and it will reappear. The simplicity of this experiment suggests people have known the Earth is round for as long as they could reason well enough to come up with this experiment.

Of course, maybe the Earth is rounded on top but flat on the bottom, like a Nilla(tm) wafer? You could argue this wasn't known for sure until Magellan circumnavigated the globe in 1524.

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're right - enough stuff could be changed on Apple-brand motherboards to make it not-very-useful to get OS X running on "standard" hardware. However, short of a hardware lock, I still content some deranged individual would make it happen, solely for the hack value.

But I'd also say that Apple moving OS X to x86 boxes would signal the end of Apple-as-a-hardware company - which I mean from a corporate, strategic sense, as in Steve Jobs saying "we're getting out of the hardware business" Which would mean they wouldn't be designing their own motherboards. Which means this wouldn't be an issue. Of course, I also think that'd be a remarkably dumb thing for Apple to do.

Just as an aside - home brewed kernels are possible - despite your associates having failures. I'm thinking in particular of the instructions for getting OS X to boot on non-Apple supported machines using home-brewed kernels (still Apple boxes, of course).

Thanks - I learned something from your explanations.

Googling for my own state's (Texas) Super DMCA, I found this by Dan Wallach, an asst. professor at Rice University. He has some interesting things to say aout the bills before our House and Senate. So in the interest of fact checking, I looked at the Senate version.

Sure enough, by the letter of the law, NATs would be illegal. It prohibits owning or creating any technology that is used to knowingly modify a communications sevice in ways unauthorized by the service provider. The bill imposes a Class A misdemeanor for the first offence, except where five or more 'communications devices' are employed in the 'criminal episode'. In that case, the crime is a felony.

In my home, I have a wireless NAT setup. There are four desktop systems and a laptop that regularly access the internet via that network. Additionally, there is one more desktop that occasionally joins the network. That makes seven discreet communications devices, including the router, that are employed in gaining access. The definition of a communication device is very broad and includes single connectors,switches and connections (presumably between devices). Theoretically, the state could use each cat5 cable and external wireless nic as communications devices, upping my number of devices to 10 or 12. Since my ISP only grants authorized access to one communication device in my service contract, I would fall squarely under the stated definition of a felony under this bill. For running a freakin' home network!

I freely admit that I use my internet service connection in ways unauthorized by my provider. Sure. And they can cut my service at any time of their choosing if they find out. I accept that. I'm violating the agreement, therefore they have the right to terminate it. Simple, to the point, and effective.

But now I could become a felon as well. That's where I draw the line. In my opinion, the state has no business enforcing civil contracts with the criminal justice system. That's what the civil courts are for. If my provider cares to, they can try to get compensation for any perceived loss in a civil court. There is no need to make my activities a felony.

Somethings got to be done. I'm going to do my part and write a letter. Please do yours.

This is far from an original idea. The Pope and Roman Inquisition did the same thing back in the 1700's and 1800's. The Church published the "Index librorum prohibitorum" or "List of Prohibited Books".

Once the list got out, nearly every book on it became a best seller and eventually the list itself was put on the "Index librorum prohibitorum". So the Catholics arrived at the same point. The Catholics maintained a secret list of prohibited books but wouldn't disclose what was on the list for fear of promoting that which was prohibited.

Either this guy knows his history or it's a clear case of "There is nothing new under the Sun." I wonder if he also knows that in 1966 the Index was abolished. I suspect the list was abolished because the Catholics could no longer keep up with the volume of books being released and they had probably had their fill of p0rn too. So, if history does repeat itself, this list will fade away too. I just hope he doesn't start making claims that "heavy bodies fall faster than lighter bodies."

No one expects the Spanish Inquisition!

You may even want to consider another completely opensource J2EE app server called Jonas. Unlike JBoss, they don't use dynamic proxies, instead they do some pre-compilation techniques so they don't have to do dynamic proxies. Take a glance at the JBoss/Jonas comparison here:

http://www.cs.rice.edu/CS/Systems/DynaServer/perf_ scalability_ejb.pdf

It shows Jonas-Jeremie getting a significant improvement over JBoss-RMI even under jdk 1.4! In the past there have been major flamewars over the JBoss and Jonas crowds, but they all have their own good reasons. So if you really wanted flaming speed, check out Jonas. They've even completely re-written their own JMS/RMI implementation called Jonathan.

I've sometimes heard this as "most of the easy science has already been done", but that is also not very well worded. What it means is that it is no longer possible to make fundamental discoveries (or even any discoveries at all, apart from personal ones) by rolling balls down an inclined plane. Instead, you need either a large scale machine, say a particle accelerator, or even a small scale machine, say a STM machine or similar. Both of these are quite complex devices, which one person could not build and operate by themselves. But, I would argue the "easy" point though. In the 17th century, Galelleo's experiment was surely not "easy", although it is easy to reproduce with modern equipment.

No big words.

For example, with one of these, you could implement a truly distributed DNS system that doesn't use hierarchy or centralization, and thus would be much more immune to DoS attacks than the current system.

Here is the explanation of what anticipatory scheduling is. From what I have understood (please correct me if I am wrong, I am not a kernel hacker), 'anticipatory scheduling' means the following:

The I/O subsystem (the part of the operating system that reads/writes to/from the hard disk) waits a little longer before servicing an I/O request from an application other than the current one; if the current application issues another I/O request while the I/O subsystem is waiting, the overall system throughput is higher because the hard disk's head moves less.

Kennedy Kennedy said that we choose to do these things not because they are easy but because they are hard.
Not that I disagree with you about priorities. President Bush Sr. set the Kennedyesque goal of landing humans on Mars by 2019, the 50th anniversary of the lunar landing. I'd say that's on the back burner until we master putting people in Earth orbit and returning them safely to the ground.

Given that kerneltrap has "Too many connections", i don't know if they have this link: http://www.cs.rice.edu/~ssiyer/r/antsched

where it explains what anticipatory scheduling does.


(btw, it seems that freebsd had it for ages)

Wait till they start radio-tagging the tinfoil hats. Then you won't know what the hell to do, will ya?

There have been several research efforts to ensure security and prevent misbehavior in ad hoc networks.

The following papers address many of the issues:

The Ariadne System (for secure routing)

Mitigating routing misbehavior

There are several others that solve similar problems in the research literature.

My wife heard about Project Gutenberg a couple of years ago and thought of OCRing and editing an English translation of Machiavelli's 1518 Italian play La Mandragola. She briefly corresponded with PG Executive Director Michael Hart, who was extremely kind and helpful. Had that been all there was to getting involved, she certainly would have put in the weekend or less of work the project required. But to avoid copyright issues with a translation that might not be public domain, Hart asked my wife to snail-mail a photocopy of the title page or copyright page of her chosen translation, so that PG could legally verify the work's availability.

Fair enough. But we were flakes, the library was waaay downtown, her work deadlines loomed.... She let the idea fade. I wonder how many other volunteers lose interest in the same way? By the way, Gutenberg still doesn't show a text of Mandragola.

There are, believe it or not, beautiful pieces of Fortran IV out there --

My nomination for the Beautiful Fortran Award would have to be ARPACK. It is clear, concise, elegant, efficient, and TOTALLY ROCKS. Eigenvalue problems are not easy, which only increases the beauty of any solution.

An initial purpose for the highway will be to help lay a $250-million fibre-optic cable to the Scott-Amundsen base. The cable, which should be completed within five years, will revolutionise communications at the Pole.

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

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

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

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

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

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

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

To set the facts straight, simdesk was selected by bid rigging and conflict of interest of a software contract in Houston....
It's about to be thrown out and legal action pursued against the IT contractor.

The funny thing is that Mayor Lee P. Brown has overspent all of the reserve funds in Houston so that any 'savings' from non-MS software will be much more than wasted on higher government spending. This hits everyone regressivly since all of the costs are added to each homeowner's property tax and water bill. This applies to renters since rent is based on direct taxes and water costs.

The reason for the overspending is that Mayor Lee P. Brown wanted to fund/back several downtown sports stadiums (baseball, football, and basketball).

This all ties into the 300+ million 2 mile light rail project which goes from one sports stadium to another.

Ridership on the bus line for this route is under 150 people a day. This project was sold as a way to revitalize that area of town. Funny how the sports stadium built in the early 1960s in the same area was sold as a way to revitalize that part of town.

It is almost like a burecrat/politician wants to accomplish some big $$ government project so that they can go on to a job with another city with more pay and do the same thing again.

I am always amazed at how generous liberal politicians are with the taxpayer's money.

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.

,\

,\

This is version 0.6 of a troll HOWTO, sort of a companion piece to jsm's excellent troll FAQ. As a draft, comments and criticism are always welcome, if not appreciated :)

Section 1 - Trolling techniques

There are techniques used by successful trolls to elicit the maximum amount of responses from unthinking /.ers. This section is dedicated to explaining how to use these in the course of your trolls. Remember though, a great troll can break any or all of these and still be successful...

• Timing
  
  

  Because you're posting as an AC, your troll will generally be ignored in favour of posters using their accounts, and so getting in early is essential. A good guideline is to get into the first 20 posts, so that people reading the article will see the troll before it is swamped out. One way of increasing the speed with which you get your troll into play is to prepare them beforehand, and then quickly customise them for the current article. This is easier than it sounds since /. typically repeats stories with small variations and runs lots of similar stories.

  
  
  

  Note that this is why Jon Katz stories are pretty worthless as trolling material - by the time you've found the article and prepared a troll there's already 50+ posts on it, most of them flaming Jon Katz anyway :)

  
  
  
• Exposure
  
  

  Once you've got your troll in, you need people to actually read it. You also want replies - /.ers are more likely to read your troll if it starts a large thread. You also want to remember that some people have set their comment thresholds to values higher than 0 - to get the attention of these you either want to get your post moderated up (see Style, below) or get a reply which gets moderated up to 4 or 5, in which case your troll becomes visible to all.

  
  
  
• Accounts
  
  

  An alternative to the time-honoured tradition of AC trolling is that of creating a "troll" account. This gives you the advantage of posting at 1 rather than 0, and slashbots are more likely to take you seriously, especially if you at least sound reasonable. If you do this, try to avoid posting stuff where it is obvious you're a troll under the account - post it anoymously instead - some slightly more canny readers actually check your user info before they reply. Not many though :)

  
  
  

  The ultimate goal of the troll account is to secure the +1 bonus, which is currently received once you hit 26 points of Karma. To get there, employ the techniques of karma whoring that we see every day on /. and watch the karma roll in. And of course once you get the +1 bonus, the world is your oyster in terms of /. Posts made at a default of 2 hit even those people with the threshold of 2, are more likely to get moderated up even further if they are at all coherent, and people tend to lose their critical thinking abilities in the face of the +1 bonus. Milk it for all it's worth.

  
  
  
• Layout
  
  

  To get people reading it a troll needs to be easily readable. Make sure you break it down into easily digestible paragraphs, use HTML tags where appropriate (but always make sure you close them properly) and use whitespace appropriately.

  
  
  
• Size
  
  

  Generally a troll shouldn't be too short, otherwise it'll get lost in the crowd. A workable minimum is a couple of medium paragraphs. Conversely, it shouldn't be too long, or no-one will bother to read it. Keep it to a happy medium.

  
  
  
• Spelling
  
  

  Whilst spelling is important if you want the troll to be taken "seriously", key spelling mistakes can draw out the spelling zealots, especially if you mis-spell the name of a venerated /. hero, like Linus Torveldes or Richard Strawlman (thanks dmg). Related to this is the use of the wrong word, explaining an acronym as being something it isn't or making a word into an acronym even when it isn't.

  
  
  
• Subject
  
  

  The subject line needs to draw attention to your post without making it obvious that it is a troll. A simple statement of the main point of your argument can work here.

  
  
  
• Style
  
  

  Once you realise that most moderators don't bother to read past the first paragraph or two, you can use this fact to craft trolls that can be moderated up as "Insightful" (note that I mean this in the /. sense rather than the real-world sense). Start off fairly reasonable, making statements that are /. friendly and not being too controversial. As the troll goes on, make it more and more controversial, building it up for the coup de grace in the final paragraph.

  
  
  
• Linking
  
  

  As we all know, a post with links is considered "informative" by the /. crowd. Moderators love it, and they rarely check the links, so be sure to include as many as possible. And make them wrong - a link to the Perl website should instead point to the Python website instead, and vice versa. The other alternative to incorrect links is "useful" links to places like www.linux.org and www.microsoft.com i.e. places /.ers could never have found on their own :)

  
  
  
• Feeding
  
  

  The ideal troll requires no feeding - it runs on its own, generating flamewars between clueless /.ers for your amusement. But often a troll requires some help and so you should consider feeding it. Feeding is best reserved for people making either completely clueless responses, people making responses with holes in, or those wonderful people who write a 2000-word point-by-point rebuttal of your troll.

  
  
  
• Know your audience
  
  

  Always keep in mind the kind of things advocated on /. so that you can play on and against them. This is why anti-Linux, creationist, gun-loving, pro-corporation trolls work well - the vast majority of /.ers hold the opposite viewpoints. And if a few people agree with you, so much the better - it merely validates your viewpoint in the eyes of readers.

  
  
  
• Arrogance
  
  

  Be arrogant. You, as a troll, know that you're right. No other explanation could exist. The wronger the "fact", the more assertively you should state it. Make it clear that you are better than everyone else - you know the truth and they are just too stupid to realise it. Use plenty of sarcasm, and use "quotes" to show it to people too dumb to realise.

  
  
  
• Offensiveness
  
  

  Being offensive in your initial troll can be counter-productive - it causes moderators to mark you down as flamebait in general. But if you're feeding, then you can get away with calling /.ers all kinds of things. Make broad generalisations
  about /. readers - call them "long-haired Linux zealots", "socialist open-source bigots" or whatever. Stereotyping is encouraged - people always want to think that they're an individual, and will point this out to you given half a chance.

  
  
  
• Indifference
  
  

  Great for articles with a political or social bent, this kind of troll expresses complete indifference to the topic at hand, wondering who on Earth cares about it. An alternative method is to say that the topic only concerns a certain group of people - criminals, idiots, hackers (always use this instead of crackers) or whatever group you want to offend.

  
  
  
• Sympathy
  
  

  Appear to take the same stance as the people you're trying to troll - claim you're as much a fan of Linux as the next man, but... This way you can make all kinds of claims in the sure knowledge that you actually know what you're talking about. A great phrase to use here is "In my experience". Remember to act like all the things you're pointing out are unfortunate but true.

  
  
  
• The common touch
  
  

  Always accuse /.ers of being elitist. This is an easy thing to do seeing as a lot of them are. Claim that is their grandmother couldn't use it, then they are just into it to feel better than Joe Sixpack rather than "doing it for the average user". This is always great for working into anti-Linux trolls - attack command-line tools and poorly designed desktops.

  
  
  
• The 31337 touch
  
  

  The opposite of the above. Claim that technology or whatever is only for the elite of society and that any attempt to open it up for everyone is wrong, an attack on intellectualism and possibly even dangerous. If people were meant to
  understand these things then they would, and it's their fault if they're too stupid to learn.

  
  
  
• Contradiction
  
  

  Never be afraid to contradict yourself, even in the space of a single sentence. The phrases "I am a top programmer who codes in VB" or "I am a supporter of open source who uses NT at work and 95 at home" will be sure to get a response from some weenie smugly pointing out the contradiction. Confuse the issue more by engaging in contradiction when you are feeding - this will confuse /.ers who will then make even more stupid replies, leaving them even more wide open for response.

  
  
  

  Clues
  
  

  If you're feeling brave, give the reader clues that this is an obvious troll. The classic example here is dmg's stock phrase "I am often accused of trolling (whatever that is)", but also feel free to use phrases like "I have not read the article, and I don't know much about XYZ but I feel I must comment". If anyone responds to a troll with these kinds of clues in it, feel free to bask in the glow of knee-jerk /. responses.

  
  
  
• Denial
  
  

  If you're unlucky someone will accuse you of being a troll (surely not!) and try and ruin it for you. If you don't want it all to end there, then be sure to counter it by accusing them of being small-minded and petty, saying that it's easier for them to say it's a troll than to accept that people have different opinions. Be sure to say this in the subject line, especially if their subject was the infamous "YHBT. YHL. HAND."

  
  
  
• Claiming credit
  
  

  Given that /. has its community of regular trolls (hi guys!), it's only polite to publish your troll on one of the so-called "hidden" forums for all to see and admire. This way, you get to bask in the praise of other trolls, they get to contribute to your's if they want to, and you get an easy way to find the troll later on when you want to check on its progress :)

  
  
  

  As for when to post it, that's a matter of opinion really. You can either post it straight away or leave it will after people start biting. Remember that the troll forum is also frequented by non-trolls, and sometimes you may get a self-declared "troll-buster" try and expose you. But remember, /.ers always post before thinking, and often it doesn't matter at all.

  
  
  

  There is no real current forum at the moment thanks to various spammers hitting the sids, but try trolltalk, the original troll sid started by 80md and osm way back in the day. Generally all postings are done there as an AC, with your name at the end of the post. Include a link to the troll somewhere in the text, which ideally will be directly to the post and its replies - click on the #XX link in the thread to get there.

  
  
  
• Ending the troll
  
  

  Sometimes you just get bored with a troll, or people start posting genuinely thoughtful stuff in reply (it does happen). When this happens it might be time to own up to the troll with a helpful "YHBT. YHL. HAND." post. Sometimes people will carry on a discussion of the issue, and if you're really lucky (and it was a great troll) they will completely fail to believe you and carry on arguing. If that happens, pat yourself on the back for writing a great troll :)

  
  
  
• The cheap $3 crack
  
  

  Finally, when all else fails and your troll gets moderated down to (-1, Troll) within ten seconds of you posting it, the only honourable thing to do is to accuse the moderators of smoking the cheap $3 crack (again) and give up :(

  
  
  

Section 2 - Types of troll

1. The Maniac
   
   

   Probably the most popular kind of troll, the Maniac holds an opinion on something, and won't budge from that opinion no matter what evidence to the contrary is presented. If challenged, the Maniac will simply get more and more agitated and abusive, deriding his opponents as "idiots", "wrong-thinking", "dangerous" and "subversive". Generally the Maniac takes a position that opposes the prevalent /. beliefs, but a similar effect can be achieved by taking a typical /. viewpoint and pushing it to ridiculous
   extremes.

   
   
   

   Maniacs can be crafted for practically every article /. posts, although some are more obvious targets than others. Civil liberty articles, especially on things like censorship, DMCA, UCITA that really get /.ers riled up, are usually extremely fruitful grounds for a well-crafted maniac. The other obvious type of article is anything which could possibly involve religion, especially evolution :)

   
   
   

   Here are some fruitful avenues to explore:

   
   
   
   • The right-wing
     
     

     Always popular, the right-wing maniac (RWM) is a God-fearing, gun-toting, flag-waving American, and proud of it. They don't care about the rest of the world, unless it's to "prove" that America is better than everything else, and they cannot stand liberal whining over civil rights. They hate the moral decay of America and want it to revert into a nation of heterosexual, Christian whites like it was meant to be. Woe betide anyone that dares to suggest otherwise.

     
     
     
   • Religion
     
     

     There are two ways to approach this kind of maniac. The harder to pull off is the militant atheist, but this is quite common amongst /. posters and you would have to be very offensive to get this to work. Of course with religion trolls, the argument can go on for ever once it's started... The more common approach is the Christian fundamentalist. They are ignorant, intolerant and bigoted in the extreme. For them the Bible is the inerrant word of God revealed to man - it contains no flaws and no contradictions. Thus they are strict Creationists - mentions of evolution or cosmology will set them off on vitriolic rants. Flaming denunciations of anyone daring to contradict the "Word of God" are the way to go, and any kind of proof can always be ignored by appealing to "secular humanist brainwashing". And let's not forget, the USA is the greatest nation on Earth because it has the righteous power of Jesus Christ behind it.

     
     
     
   • Ideology
     
     

     Pick a philosophy, any philosophy. This troll is a troll with a cause - they have found some kind of ideological truth, and are out to expose every other philosophy as a sham. Whether it be libertarianism, objectivism, communism or capitalism, this troll will point out the obvious "flaws" in any other philosophies, whilst spouting dogma about their own. And the best thing is - you don't even need to know that much about what you're spouting - making doctrinaire mistakes will get both sides of the argument flaming you, adding to the fun.

     
     
     
   • Software
     
     

     This is an old favourite and crops up in many forms, covering the gamut from OS maniacs (Linux zealots, MS-apologists or embittered BSD fanatics), language maniacs (Pascal vs. C, C vs. C++, C++ vs. Java, Perl vs. Python, VB vs. everything),
     application maniacs(GIMP vs. Photoshop, Netscape vs. IE, vi vs. emacs) and also includes people who complain about how technology should only be for the 31337 hackers.

     
     
     
   • Guns
     
     

     Americans love their guns, and will always fight passionately for their Constitutionally guarenteed rights to bear arms and shoot people. Even the slightest hint of criticism of this will bring down the wrath of a thousand and one enraged gun-owners on you, so it's always a great point to work into a troll :)

     
     
     
   
   
   
2. The Expert
   
   

   The Expert is someone who is "savvy" in their particular field, and is perfectly willing to give their opinion on any topic even vauguely related to their field. The Expert is most likely to be from a field which /.ers as a rule despise - the classic example is dumb marketing guy, but try consultants, lawyers, politicians, lobbyists, executives, journalists (just think Jon Katz). With this kind of troll sweeping statements with little content are the norm, along wire dire portents of future catastrophe and dark hints of "insider knowledge".

   
   
   

   Some possible angles to exploit:

   
   
   
   • Industry knowledge
     
     

     The expert knows the computing industry from the inside - as a long-term pro, they can dispense knowledge knowing that they can "speak for the industry". Their smug self-satisfaction is bound to annoy, as is any suggestion that things aren't the way that /.ers would like it - saying "Linux requires the rock-solid guarantee of a trusted company like Microsoft" or "Apache cannot be trusted for mission-critical enterprise platforms" is guaranteed to get you denials explaining exactly why you're wrong, in excruciating detail.

     
     
     
   • Helpful hints
     
     

     With their tech-savvy (or law-savvy or whatever) experience, the expert is obviously the best person to point out what's wrong with things or to give out useful "factual" information. In fact this probably works best with lawyer trolls - for all that /.ers protest "IANAL", they certainly seem to think they could be, and any mistakes you make will send them rushing to prove themselves by correcting you.

     
     
     
   
   
   
3. Offtopic Trolls
   
   

   Not really a "troll" in the strict Jargon File sense of the word, but they certainly should be included here :) This category includes parodies, offtopic weirdness any all kinds of amusing stuff. Not really my area of expertise, this stuff is mainly done by gnarphlager and opensourceman. Thanks to gnarphlager for this section.

   
   
   

   Offtopic trolls, like any other, come in almost as many colours as an iMac, but generally not as cute. But then again, a good offtopic "troll" can affect more people than a repulsive little gumdrop on your desk, because you need to have someone SEE your desk before they can react. Simple? Moreso than even my overblown prose could indicate. Some basic examples:

   
   
   
   1. The serial troll
      
      

      Write a story. Keep expanding it. It doesn't matter what article you post it under, so long as it's high up. If you want people to recognize you, pick a couple themes or symbols, and carry them on throughout the story. Other alternatives include back linking or including the entire story, but adding more each time. Be funny if you want. Or if you don't feel like being funny, just be really weird. Someone will react.

      
      
      
   2. The random troll
      
      

      This has nothing to do with anything. Be it a stream of consciousness rant, or a description of the corner of your desk. Another favorite is a monologue, read as if spoken from any one given entity to another. The more outlandish, the better (a pair of socks talking to a mousepad, for example). If you really wanted to be artsy, work in an actual metaphor or legitimate meaning behind it, but it's not necessary.

      
      
      
   3. The vaguely related troll
      
      

      Start out with a comment about the article. Have a definite opinion of it. Then, after a little while, disintegrate into randomness. All roads eventually can eventually lead to cheese (yum), Natalie Portman, cannibalism, toasters, squirrels, futons, you name it. All it takes is a little bit of creativity. Oh, and feel free to use other trolls' motifs. Open source and all that ;-)

      
      
      
   
   
   

   General tips:

   
   
   
   • If it's funny for a fleeting moment, then it's worth posting.
     
     
   • Puns. Puns are only less vile than mimes, but it's hard to mime on /. So feel free/obligated to litter your offtopic and random bits with puns. Hurt the bastards. And if they're sick enough to laugh at them, then they'll eventually end up here ;-)
     
     
   • Obscure cultural references and injokes are always good. SOMEONE will get them eventually.
     
     
   • Several drafts of a serial or random post are common, but true elegance is being able to come up with something on the spot that still makes the top 40 posts (on a post-heavy article)
     
     
   
   
   

Section 3 - Useful trolling links

The following links contain background information useful for trolls needing quick quotes and "expert" opinions to include.

1. General purpose links
   
   
   • ddi.digital.net/~gandalf/trollfaq.html - How to deal with USENET trolls - learn your enemy :)
     
     
   • www.don-lindsay-archive.org/skeptic/arguments.html - A List Of Fallacious Arguments - Learn them and use them liberally
     
   • www.altairiv.demon.co.uk/troll/trollfaq.html - USENET troll HOWTO
     
   • www.baiting.org - Baiting.org
     
   • www.fieldingtravel.com/df/index.htm - Fielding's DangerFinder - A guide to what and where's dangerous
     
     
   
   
   
2. Religious links
   
   
   • www.godhatesamerica.com/ - God Hates America
     
   • www.chalcedon.edu/creed.html - The Creed of Christian Reconstruction
     
   • www.demonbuster.com - How to cast out your demons and do spiritual warfare
     
   • riceinfo.rice.edu/armadillo/Sciacademy/riggins/thi ngs.htm - Things Creationists hate
     
   • www.icr.org/ - Institute for Creation Research
     
     
   • www.xenu.net - Operation Clambake - The fight against Scientology on the net
     
   • www.hom.net/~angels/ - Citizens for the Ten Commandments
     
   • www.bju.edu/rcnbc.html - The difference between Catholics and Christians
     
   • www.geocities.com/prazske00/biblequotes.html - Bible quotes by category
     
     
   
   
   
3. Political/economy links
   
   
   • www.aynrand.org - The Ayn Rand Institute
     
   • www.reason.com - Libertarian site
     
   • www.freerepublic.com - Right-wing stuff
     
   • www.jbs.org - Excellent site for all kinds of right-wingery
     
   • www.dack.com/web/bullshit.html - Web economy bullshit generator
     
     
   
   
   
4. Crackpot science links
   
   
   • www.fixedearth.com - The Earth Is Not Moving
     
   • www.jir.com/index.htm - The Journal of Irreproducible Results
     
     
   
   
   

I work in the systems office of a fairly large UK university library, so I tend to keep a close eye on these things. Check out koha, a complete open source library catalogue system, which appears to be growing in popularity.
Also worth a look are the perl4lib and oss4lib mailing lists.

The almabench program spends a lot of time in library routines that the author has no control over, and aren't always written the same way that they are in FORTRAN/C/C++. For instance, almabench makes 5,844,000 calls to java.lang.Math.asin(D), which then calls java.lang.StrictMath.asin(D) 5,844,000 times. The same is true of the 11,688,000 calls to atan2()... they're also passed along to StrictMath (only abs() is called as many times as atan2()). The beauty of writing java code is *not* knowing that these sorts of things are going on, no? For best *performance*, however, we have to work a little harder.

I really enjoyed the following paper on using some OO programming-style optimizations coupled with a smart runtime to get almost identical FORTRAN and Java performance for linpack: linpack9.

A look there will validate the other comment about why OO designs can unecessarily kill performance and why the study's author should have used a JIT with identical libraries for math functions rather than Math.X(). Comparing otherwise is like comparing apples and oranges, or even Apples(r) and BillG.

Could you detail a real-world attack that would break the security of the network I described above?

As far as the SSID is concerned: "Some access-point vendors, including Cisco, offer the option to disable SSID broadcasts in the beacon messages. The SSID can still be determined by sniffing the probe response frames from an access point".

For a description of a real-world attack on WEP, I would recommend "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP" by Stubblefield, Ioannidis, and Rubin. They showed it was possible to recover a 104-bit key in a few hours...

It takes about 15 minutes to crack 64-bit WEP. A day to crack 128-bit WEP. I think that 256-bit WEP IIRC would in theory take about a month of non-stop monitoring.

As for your figures, they are incorrect. Fluhrer, Mantin and Shamir have shown it is possible to "recover an arbitrarily long key in a negligible amount of time which grows only linearly with its size, both for 24 and 128 bit IV modifiers".

Thus, doubling the size of the key will only double the time needed to recover the secret key! Stubblefield, Ioannidis and Rubin have shown that it takes as little as 1,000,000 packets to recover a "128-bit" WEP key. That's less than a day on a lightly loaded WLAN to recover a hypothetical "256-bit" key...

Who said that a picture has to use light? Anyway, we have taken pictures of individual atoms using optical photography.

Writing With Atoms

Imaging Atoms at Sub-Angstrom Resolution with a Corrected Electron Microscope

Bell Labs researchers invent technique for imaging single impurity atoms within silicon

Imaging Bose-Einstein Condensates

Trapped Atoms Photo

Single Atoms in a MOT

I wouldn't have made it out of the harbor in one piece, so I don't mean to criticize too harshly. :)

Someone must be burning to know that the Earth is about 8,000 in diameter, fatter at the Equator. There, that's as much showing off as I can muster. More.

Here is an exercise.

Four centures, thereafter, I take passage over sea
In the footsteps of McKenzie, but floating well above the scree
Watching icebergs melt before, and behind me fade away
All from the smoggiest Explorers driving in the USA

Here is some bio information on Christiaan Huygens for whom the Cassini probe is named after.

Christiaan Huygens, born on 14 April, 1629, discovered Saturn's largest moon, Titan, in 1655. He died on 8 July, 1695.

For more details, see the Bio of Christiaan .

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.

He is on the executive board of this project at Rice University over in the United States.

They're working on similar studies and experiments, and have been doing so since the late 1990s. From what I hear, it's going quite well and the funding is just extraordinary these days now that Republicans are in control of U.S. government policies these days.