Slashdot Mirror

L0PHT SELLS OUT

... to the original article. It's available here .

To sum it up, he speaks good things about both Free S/WAN (representing the IPSEC-is-good camp) and OpenVPN (representing the IPSEC-is-too-complex guys). Too bad neither one run on kernel 2.0 (still my preferred for security applications).

Like the original article, very well written and informative. A must read.

But hell, at least our offices come pre-equipped with plywood shelves on the wall. That makes it all worth it. No really. I can't wait.

But hell, at least our offices come pre-equipped with plywood shelves on the wall. That makes it all worth it. No really. I can't wait.

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

Like a lot of other people, this update seems to have completely screwed up ethernet networking for me. A lot of the reports I've read (Apple's site Slashdot comment, MacFixit article, MacSlash, etc) suggest that people with dual processor G4s running 400-500mhz are having a lot of problems, and a broken driver for the Intel gigabit ethernet chipset has been blamed -- though I haven't seen anything that conclusively says that this component is at fault. Other reports have come from people running faster G4s & PowerBooks, so if the Intel ethernet driver is a cause, it doesn't seem to be the only cause. All I can say personally is that my dual G4/450mhz is definitely messed up right now.

The best remedy I've seen so far is to restore the pre-10.2.8 version of the AppleGMACEthernet ethernet driver. If you can -- and for most people it'll be too late for this advice to do any good -- make a backup of the .kext driver before updgrading to 10.2.8, then use that to rebuild is things go awry. For everyone else, your best bet is to download it from Andrew McPherson's MIT site, either by establishing a dialup connection, by booting into OS9 and getting it from there, or by grabbing it with another machine and transferring it to your broken Mac by e.g. a burned CD, a Zip disc, etc.

Here are the repair steps, as slightly modified from McPherson's suggestion at Apple's site:

mkdir ~/enet_backup
cd ~/enet_backup
wget http://web.mit.edu/apm/www/AppleGMACEthernet.tar.g z
# note -- doing the above without network access is left
# as an exercise for the reader. i happen to have a flash
# card reader, so can transfer it that way, but I was
# getting pretty desperate before that occurred to me.
# others might want to try burning a CD, or getting
# online from OS9, or a zip disc, or...
# ...in any case, `wget` is about the only method that is
# almost guaranteed NOT to work right now...

cd /System/Library/Extensions
sudo mv AppleGMACEthernet.kext ~/enet_backup
sudo cp -r ~/enet_backup/AppleGMACEthernet.tar.gz .
sudo tar -zxvf AppleGMACEthernet.tar.gz
sudo chown -R root:wheel AppleGMACEthernet.kext
cd ..
sudo mv Extensions.kextcache ~/enet_backup/
sudo mv Extensions.mkext ~/enet_backup/
sudo shutdown -r now

This advice is close to that which McPherson suggested, but he recommended deleting the broken driver, and the commands I give above make a backup just in case. If all goes well you may remove that ~/enet_backup directory, but I have a hunch that somehow you're going to have to end up re-installing it, so keeping a copy around seems prudent to me -- and it's not like it even takes up that much space (well under a megabyte).

Other people have reported success with other solutions. One proposal was to run the command "ifconfig en0 media autoselect", but in my case that didn't work. Others have suggested rebooting, zapping the PRAM a few times, then letting the machine boot again; others have said that that didn't work either.

Replacing the driver, as described above, seems to be the remedy that has had the most success for the most users -- but even still, it isn't working for everybody. In my case, it has allowed me to reconnect to my PPPoE/

Like a lot of other people, this update seems to have completely screwed up ethernet networking for me. A lot of the reports I've read (Apple's site Slashdot comment, MacFixit article, MacSlash, etc) suggest that people with dual processor G4s running 400-500mhz are having a lot of problems, and a broken driver for the Intel gigabit ethernet chipset has been blamed -- though I haven't seen anything that conclusively says that this component is at fault. Other reports have come from people running faster G4s & PowerBooks, so if the Intel ethernet driver is a cause, it doesn't seem to be the only cause. All I can say personally is that my dual G4/450mhz is definitely messed up right now.

The best remedy I've seen so far is to restore the pre-10.2.8 version of the AppleGMACEthernet ethernet driver. If you can -- and for most people it'll be too late for this advice to do any good -- make a backup of the .kext driver before updgrading to 10.2.8, then use that to rebuild is things go awry. For everyone else, your best bet is to download it from Andrew McPherson's MIT site, either by establishing a dialup connection, by booting into OS9 and getting it from there, or by grabbing it with another machine and transferring it to your broken Mac by e.g. a burned CD, a Zip disc, etc.

Here are the repair steps, as slightly modified from McPherson's suggestion at Apple's site:

mkdir ~/enet_backup
cd ~/enet_backup
wget http://web.mit.edu/apm/www/AppleGMACEthernet.tar.g z
# note -- doing the above without network access is left
# as an exercise for the reader. i happen to have a flash
# card reader, so can transfer it that way, but I was
# getting pretty desperate before that occurred to me.
# others might want to try burning a CD, or getting
# online from OS9, or a zip disc, or...
# ...in any case, `wget` is about the only method that is
# almost guaranteed NOT to work right now...

cd /System/Library/Extensions
sudo mv AppleGMACEthernet.kext ~/enet_backup
sudo cp -r ~/enet_backup/AppleGMACEthernet.tar.gz .
sudo tar -zxvf AppleGMACEthernet.tar.gz
sudo chown -R root:wheel AppleGMACEthernet.kext
cd ..
sudo mv Extensions.kextcache ~/enet_backup/
sudo mv Extensions.mkext ~/enet_backup/
sudo shutdown -r now

This advice is close to that which McPherson suggested, but he recommended deleting the broken driver, and the commands I give above make a backup just in case. If all goes well you may remove that ~/enet_backup directory, but I have a hunch that somehow you're going to have to end up re-installing it, so keeping a copy around seems prudent to me -- and it's not like it even takes up that much space (well under a megabyte).

Other people have reported success with other solutions. One proposal was to run the command "ifconfig en0 media autoselect", but in my case that didn't work. Others have suggested rebooting, zapping the PRAM a few times, then letting the machine boot again; others have said that that didn't work either.

Replacing the driver, as described above, seems to be the remedy that has had the most success for the most users -- but even still, it isn't working for everybody. In my case, it has allowed me to reconnect to my PPPoE/

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.

He tears them a new one. Jesus Christ on a bicycle, these geeks need to find something else to do other than writing code.

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

Although I never got SF working (guess why? NATs), I'd always admired it for including encryption. Maybe now's our chance to write a portable clone of PGPfone.

Call it GPGfone... but more clever.

To: Dr. Oliver Smoot, President, International Organization for Standardization

They should have called it "Homer: A Space Odyssey". Two references in one!

Look forward to a lifetime of high cholesterol, kidney stones, osteoporosis and increased risk of bowel cancer. Not to mention the fact that the Atkins diet is so restrictive as to be completely unpalatable. Although eating only low-carb foods like meat and eggs sounds good in theory, in practice very few people have the willpower to stay on a "pure" Atkins diet. This is partly because carbs are an important part of the diet (and taste good) and partly because ketosis is an unnatural state for the body to be in for long periods of time (greater than 6 monhs) as the body is "digesting" itself to produce fuel.

You betray an astounding ignorance about low-carb diets with this here tripe.

There is nothing wrong with disagreeing with a plan, but to wax didactic about it; educate yourself.

Atkins is not terribly restrictive. It is not meat and eggs. It lowers dangerous cholesterol levels.
You mention a "pure" Atkins diet with an obvious lack of what that actually is.

One does eat carbohydrates on any low-carb diet. Ketosis is a early, short-term goal, and effects of non-diabetics remaining in ketosis have not been found to be negative. If one ingests enough fat, ketosis burns that fat and stored body fat as a fuel source, which is the objective early in the plan.

http://www.countcarbs.com/advice/LCG_Myth_Reality_ Ketosis.htm

http://www.immuneweb.org/lowcarb/faq/myths.html

Then individuals are encouraged to increase their carbohydrate intake as they move forward. Even in the beginning one is recommended to eat 20 grams of carbohydrates a day.

Dr. Atkins did not suffer poor health, and his death had nothing to do with his diet.

In terms of Fumento; I find his writings a joke. Taubes' article interested me in giving this plan a shot...not a diet, but a plan of eating for a lifetime. In hunting down info before starting, I cam across a rebuttal by Fumento of the original article. I had been ill-disposed towards low-carb plans prior to reading Taubes article, so I was not predisposed to believe anyone.

Fumento's article was terrible. I noticed it as I was reading. He uses colorful, reactionary language, but little logic, and little reference or attribution. Luckily, the place I read it also included Taubes answer to Fumento's article.

I suggest you (or anyone who is interested) read the entire dialogue:

Taubes' original article here.

Fumento's rebuttal:
http://reason.com/0303/fe.mf.big.shtml

Taubes' response (also linked from the previous page):
http://www.reason.com/0303/taubes.shtml

Try this!

Co-generation is quite common in industry. It involves the reuse of waste materials to generate heat, steam, or electricity, and can also be used to describe use of heat from one process to drive another. Many pulp mills and sawmills run cogen plants, most refineries and chemical producers also do this to some extent, and it is also called CHP, or combined heat and power. While it is good to turn a waste stream or unused resource into revenue, it is nothing new. I'm sitting within about 1km of a large woodwaste cogen plant at a nearby sawmill.

• MIT does it
• Cogen Europe
• EC / ASEAN Cogen site

You are either the biggest fucking dumbass ever or a troll. Mathematical fact??? Where's your data?

Learn to use the internet.

And I know soriety girls are braindead, but I think they would know if a fucking arab was using them as a mule for explosives.

1) You could get someone who looks like the "good" profile, even if they are just acting.

2) You could get a real person who doesn't even have to know that they are carrying anything.

Let me try to clue you in on a little thing we like to call "reality", big guy. Profiling does not mean that the gaurds will only stop dirty, turbin-wearing foreigners. Profiling means that the airport security has enough sense not to strip-search children and grandmothers just because some "random" sampling rule tells them to. Profiling means you fucking stop anyone that looks suspicious. It's common fucking sense, not an act of racism.

You only have a limited amount of resources at an airport terminal. The guard can't search everyone, right? If the guard is searching only "suspiscious" looking people, then it's trivial to get past him.

For example, if the guard only has time to search 10 people every flight, then you get 10 of your terrorist friends to dress up in super-suspiscous clothes, but carry NOTHING dangerous. Then you get your one white terrorist friend to dress in a business suit and carry a suitcase full of x-ray transparent machine guns.

The guard, who is profiling, will choose the 10 suspiscous looking people, and the non-suspiscous person will get in with ease.

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.

Thanks for the link

I would love to see an ISP use Oblivious Transfer when assigning an IP to each on of its customers..

That way, this situtation would never have happened since the information the RIAA wanted could not have been obtained from the ISPs since the ISPs wouldn't know who they assigned IPs too.

Simon

There are two distinct groups developing and commercializing similar technology.

The previously-posted story was about a walk-thru screen developed at Tampere University of Technology, Finland, demonstrated at SIGGRAPH 2003, which is being commercialized by FogScreen, Inc.

In the current story, the technology was developed at MIT, demonstrated for the media, and is being commercialized by IO2 Technology".

Both systems appear to use a particle wall or sheet, onto which video is projected. Neither is anywhere close to "holographic," so I'm afraid those late-night session "learning Vulcan" with Virtual T'Pol are still a few years off.

Check out MIT's Cilk, a language specifically designed for multithreaded parallel programming.

Memory is like an orgasm. It's a lot better if you don't have to fake it. -- Seymore Cray

What, like the Walkman and the camcorder? Like Microsoft's, Sony's "innovation" most often takes the form of acquiring and re-packaging existing inventions and leveraging a huge marketing machine.

There's a lot of innovation going on in Asia, but Sony might not be the right place to look for it.

Read the Diamond v. Diehr decision yourself if you don't believe me.

From this discussion of Diamond v Diehr, the answer does not support your contention. "The Diehr court left undecided the question of whether computer programs standing by themselves could ever be patentable."

I have not found citations for The last word from the US Supreme Court is that software is not patentable. as you state. Can you provide other citations that support your claim? Diamond v Diehr doesn't.

There is In Re Alappat, which is what is generally used when refering to the patentablity of software, but that is an opinion by a Federal Circuit Court of Appeals, not the Supreme Court.

From the lawfirm that argued the Alappat appeal:

"The decision in In Re Alappat No. 92-1381 (Fed. Cir. July 29, 1994) (en banc), clearly paves the way for the patenting of inventions that can be implemented in either hardware or
software"

and

"overturns a long standing Patent Office policy of denying patents on inventions that could be functionally implemented in software."

and

"The Patent Office has not yet determined whether to seek review by the United States Supreme Court. See Bart Ziegler, Court Upholds Patent for the Way Software Interacts With Computer, Wall Street Journal, August 8, 1994, at B4."

Damn, there go my mod points!

• MIT's RAW project
  
• Berkeley's Garp architecture
  
• CMU's PipeWrench

You apparently didn't get the reference.

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.

I would suggest you go down to city hall. Just being there will give you a bit more insight of what it is like. It's kind of like installing a new operating system. You can kind of figure out basically what it is like from pictures you have seen and properties you have read about, but you get a better picture from what is going on from trying it out.

Also, government is a huge hierarchy as you might already know, I guess like a filesystem. So you have your local, state, and country.

Cities
Pretty much all large cities have a website where you can download the city code or get information on various meetings and events that will allow you to get involved. Don't bitch about city decisions unless you don't take the effort to acquaint yourselves with current happenings every month or so. To visit your city website alter the "XX" in the following URL to reflect your state abbreviation (ie. ca - california, ny - new york)

http://www.statelocalgov.net/local-XX.htm

State
Your state government is the accumulation of all local governments within a set boundry. Do the same thing with the following URL as the one above.

http://www.statelocalgov.net/state-XX.htm

National
Here we have all those states to create a national charter of if...then statements governing your way of life. These are ultimate and cannot be evaded by each lesser government (local, state). It should be noted that those smaller governments can choose to enact various further restrictions that they see fit, as long as it does not interfere with the national charter.

Here are two portals for the huge national government.

Library of congress portal - Executive (links to the other two branches of government, Legislative, and Judicial are at top the top.)

Official Federal Gov portal site

A bit more on elections specifically
Relatively recently unveiled on slashdot , Project opengov contains a wealth of information. I would recommend spending much of your time here to acquaint yourselves with the people running your government.

Alternatively, enter your zipcode to get quick summary of who's working for you in government. Project vote-smart

There are a few other good sites, one at the tip of my tongue, it features detailed financial recordings of government election campaigns. I'm sure you have enough data to grok though ;)

Knowledge is power.

Or for a quick and free guide, you can download the secure programming faq from one of the oldest websites on the internet-
Securing Programming FAQ
--

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.

Wrong. Work-alikes DO violate patents but NOT copyrights.

The Lotus vs. Borland case was based on copyright infringement and that was why it was lost. Patents, on the other hand, apply to methods (which is why software patents are BAD) not actual work.

Also, I agree with you on the USPTO being fucked.

The US government has an effectively miniscule power to censor. An "expose" on censorship in the US is really an indictment of the media - a media which is generally considered to have a slant to the left.

Did you ever stop to think that many of the Internet's protocols were designed when there were no fuckwits running operating systems that are a virtual "petri dish" for viruses and worms?

Oh, and by the way, while we're waiting for Jon Postel to come to the phone, let's track down a kid named Robert Morris and get his thoughts on that particular point. I don't believe Morris was a big Windows user, but I understand he knew his way around sendmail.

Memory Glasses is what you're looking for:
It's a project involving Rich DeVaul at the MIT media lab wearable computing project
You can also watch some footage of it in action.

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

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.

Joseph Dvorak, a researcher at Motorola US, predicts the computers and technology we wear in four or five years time will not draw attention to ourselves.

such as: this...

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

http://www-tech.mit.edu/V123/N38/38riaa.38n.html

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 timely 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 most 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 generous 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.

But this guy was using a Times account to order outside services from LexisNexis and those guys ain't cheap. I suspect the victims will also be able to quantify how much it took to repair their system. However, I hope they're not counting the cost of closing the security holes since Lamo only exploited the holes -- he didn't make them.

Yeah, easy for you to say, whiteboy.

Profiling seems like a great idea when you look at it as an abstraction - sacrifice some rights of a very small group of people to improve everyone's safety. Sure, why not? It's a whole different story when you take it on an individual level. I'm an Arab, and an American citizen, and I've lived in the United States since I was two years old. Most people assume that I'm white just looking at me; shit, I don't even speak Arabic. I'm no more a terrorist than your theoretical elderly black woman. And let me tell you, getting searched at every. Single. Goddamn. Airport. starts to look a whole lot like racism from where I'm sitting. I'm not suffering because of anything I've done, or even any choices I've made; it's the way I was born that's the issue. Even the most hardcore politically conservative (i.e. pro-equality of opportunity) outlook can't support that. So if it doesn't fit the political doctrine, what could the motivations be? Notice how they didn't start profiling caucasians at government buildings after the Oklahoma City bombing?

That aside, racial profiling was recently proven not only ineffective at hampering terrorists, but actually counterproductive. It's an interesting paper, and a very simple proof, though I somehow doubt that it will change your mind on the matter.

Finally, asshole, your stance here doesn't brand you as a "radical free-thinker" or "defiantly anti-PC", no matter how you might try to paint it as such. It brands you as a fucking racist, and I hope that someday someone gives you the mighty clue-stick bitchslap that you so desperately deserve.

Thanks ESR. You've just put a team of mathematicians at SCO who were somehow related to MIT out of their jobs.

My favorite bug followed me from one system to the next!

I was writing Logo for the 512K Macintosh. The only programming environment supported for the Mac in 1984 and 1985 was Pascal on the Lisa, but we wrote our code in C on a 68000 running Unix and cross-compiled to the Mac using the SUMEX PCC compiler.

Anyway, I was changing something in the garbage collector, compiled on the 68000 running Unix, and got an assembler error that was something like this:

00800: #,1,$,g,a,q:2 Illegal Instruction

It was really weird -- I had no idea how the compiler could output an illinst. I narrowed it down to this line:
marked = 0x80000000 & addr;

I turned to a different computer, the Logo interpreter running on the Mac 512 behind me, and typed
2^31
and it printed out
Result: #,1,$,g,a,q:2

At this point I ran screaming down the hall.

When I came back, I looked at the source for PCC itoa() (if anybody still has this you can reproduce it and tell me the exact string) and it had
if (value
which of course fails on -2147483648. But the failure mode was pretty spectacular.

The Logo on the Mac had the same bug because it was running the SUMEX libc, which of course had the same bug.

I ust patched it with
if (i == 0x80000000) return "-2147483648";

Yow.

My favorite bug followed me from one system to the next!

I was writing Logo for the 512K Macintosh. The only programming environment supported for the Mac in 1984 and 1985 was Pascal on the Lisa, but we wrote our code in C on a 68000 running Unix and cross-compiled to the Mac using the SUMEX PCC compiler.

Anyway, I was changing something in the garbage collector, compiled on the 68000 running Unix, and got an assembler error that was something like this:

00800: #,1,$,g,a,q:2 Illegal Instruction

It was really weird -- I had no idea how the compiler could output an illinst. I narrowed it down to this line:
marked = 0x80000000 & addr;

I turned to a different computer, the Logo interpreter running on the Mac 512 behind me, and typed
2^31
and it printed out
Result: #,1,$,g,a,q:2

At this point I ran screaming down the hall.

When I came back, I looked at the source for PCC itoa() (if anybody still has this you can reproduce it and tell me the exact string) and it had
if (value
which of course fails on -2147483648. But the failure mode was pretty spectacular.

The Logo on the Mac had the same bug because it was running the SUMEX libc, which of course had the same bug.

I ust patched it with
if (i == 0x80000000) return "-2147483648";

Yow.

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