Slashdot Mirror

But this isn't enough, by itself, to classify a message. Messages do not solely consist of one or two words; they consist of many. And collecting the statistics together requires calculating a "relevance factor," based on all the words.

The one used for Naive Bayesian Inference is as follows: Rf calculation , and you'll notice it involves doing a logarithm-based weighting.

The formula doesn't care what words are used, or that you think one folder contains "spam" and that another contains "gold."

In my corpus, the word sex is used in 65 different mail folders, mostly probably pretty "innocently."

Drawing conclusions based on one or two words is, unfortunately, pretty incomplete. It might well be that the one use of "sexy" in a particular message doesn't force it into the Spam/Phonesex folder because it makes even more extensive mention of Enlightenment and WindowMaker and GTK Themes and winds up being very strongly tied to the X/WindowManager folder because there are several other words not related to sexual activity that make it (correctly) appear relevant to a discussion of window managers.

Graham is drawing an analogy based on two words (words likely to grip adolescent attention!); reality involves adding everything up, and those two words certainly don't tell the whole story of the whole corpus.

Consider:

• It's doing FULL TEXT word search. The HTML is looked at.
• Are they really going to generate different "innocuous" messages?

  If they are REPEATED innocuous messages that match against PAST "innocuous" messages that I decided were spam, that is going to pick this up.

• Fool me once, shame on you.

  Then your message goes into the corpus as "spam."

  And messages that are written as multipart/alternative with statistically similar "innocuous" messages will be matched as spam.

• The only "Wealth Of Evidence" that you can provide in an email to me that you aren't sending spam is for you to send me messages that have similar statistical parameters to those messages that I did not consider to be spam.

  You don't know the parameters. The parameters essentially involve the subjects I discuss with my family, or with friends, or with business associates, or with technical associates.

  How can you possibly construct, as a "spam-meister," messages that resemble those without being someone that I regularly communicate with?

No, this "defeat" represents nothing of the sort.

I think you're misreading the advisory. The bug in xdr_array.c does not stem from the calloc() bug. It's just that the same mistake caused both bugs.

I don't know about "original", but I can go back as far as RPC 3.9. They didn't even have a copyright notice. The license was almost entirely a disclaimer.

On patents, I think the most sensible argument against them was presented in a letter to the US Patent Office by Donald Knuth, where he points out that software and the algorithms used therein are mathematics, and mathematics have previously been exempted from patents.

Regarding copyrights, while I would be quite happy with a short limitation on the life of a copyright (5 years would suit me just fine... 10-15 would be ok, anything longer is ludicrous in the technology field), I think his presentation is quite a bit more radical than most professional programmers might agree with after putting some thought into it.

Some of us don't particularly like working as employees of companies which we do not own, but without the protection that copyright provides it would be impossible to make a living by creating consumer software products. Yes, you could write custom software under contract to a corporation for money, or write software as an employee of a company, but to write a product for consumers? Who would pay for that? The average person who'd want to use a word processor certainly isn't going to cough up enough money to pay my rent for the amount of time I'd need to write one...

Without copyright, if I write a cool app and want to sell it, I'd only sell it once before anyone who wanted it could just get it for free... This is absolutely great for code I write in my spare time for fun, or tools and libraries I write to help me do my work where they might be useful to others, but *something* has to put food on the table.

However, I do think that once you buy something, at least the copy you own should be able to be used by you in whatever manner you wish. So his speech seems misguided... The real threat is that with recent legislation, that is less and less true.

I support the EFF and donate.... but the presentation is off target. I hope his arguments before the Supreme Court are less radical and stay based on the fact that 100 years is way too long for a copyright, rather than implying that copyright is bad.

Think he used a pirated copy of PowerPoint? ;)

The whole point of the Theremin is that you only need to use your bare hands, since the tone is a function of the distance between you and the pitch rod. I think a Powerglove would just complicate things. However, this could be a real boon for MIDI artists on a serious budget(PD/Jmax). There is a rich history of glove interfaces to other Midi instruments. The MAX programming environment has a 'glove' object that interfaces with the new defunct Gold Brick interface. Plus, for the ultimate in coolness, there's Laetitia Sonami's Lady's Glove , which rocks my world. Check out the video .

Like this, you mean?

I think the appropriate language to program rats would be LOGO.

Others have already pointed out the open source Autopilot project.

The Draganflyer is limited to 5 minutes because it's so small and light, and runs on batteries. If you go with one of the more established conventional helis, you can get longer flight times. The longest times are still achieved by combustion engines, using either model fuel or regular gasoline, and it's quite easy to achieve more than 15 minutes with one of those.

However, I don't think it's any accident that the Draganflyer has an unconventional four-rotor design - this allows it to avoid many of the instabilities that a regular helicopter suffers from, and probably makes the job of programming an autopilot for it much easier.

Still, computer-controlled regular helis, even fully autonomous ones, are possible and have been done. There's even an annual International Aerial Robotics Contest. The site doesn't seem to be responding right now (secondary /. effect?), but here's one of the previous entries, the MIT/Draper Autonomous Helicopter Project.

In the past, these have been pretty expensive devices to put together. Nowadays, as the Draganflyer proves, it's not as expensive as it used to be. The piezo gyros are pretty cheap - in the $100 range for a decent one. Building your own computer-controlled helicopter is definitely doable. The Sourceforge project is probably a good place to start, especially since it'll be a lot easier if it's not a one-man project.

You've not been reading enough of the articles then. See eg this one. The Myna pager is definitely a 'consumer market' device. I'm sure I read Ivan Sutherland say somewhere that there are asynchronous islands on the latest SPARC chips, but I can't find a reference.

However you're right, takeup is minimal, see eg this talk for a description of the state of play.

Another approach that may have gone the way of the dinosaur (havent seen it make headlines on /.) is reversible computing - the notion that by not discarding information within a chip you can run chips cooler (though apparently we won't reach the level where this much thermal loss becomes significant for another few years). E.g. a nand gate loses one bit of information, resulting in an energy dissipation of at least ln(2)kT, about 3x10^-21 joules. These links are 4 years old; I have no idea if reversible computing is now mainstream?

What gave you that idea?

I dunno what gave him that idea, but I thought it was a well-known fact.

According to the first link, the thermal conductivity of copper (in W/cm-K) is 3.937. Room-temperature diamond: 6.299. And an isotopically pure room-temperature diamond: 50. The last link claims a conductivity of 2000 W/cm-K for CVD diamond and talks about using it to cool stuff.

So I guess the more interesting question is where you got the idea that diamonds wouldn't work well for cooling.

you know, it doesn't hurt to have the ridiculously inadequate, but-still-going-strong-as-head-of-iCampus (MIT/Microsoft alliance), Hal Abelson as your advisor when you have a problem with the great Evil.

Hal probably had to bend over quite a bit to get this past the MS ppl.

or perhaps this was why the woefully pitiful SQL Server 2000 was nearly forced upon me in a web/DB class he co-"taught". blech.

Excepting serious research; a student from MIT is about a serious as they come.

Excepting serious research; a student from MIT is about a serious as they come.

If you are interested in the mind numbing details of the chemistry of gasoline, how oxygenates such as ethanol work, etc., I suggest you check out the rec.autos.tech Gasoline FAQ. It's a bit dated (96?) so some of the programs described as "future" are really current or past trends. But it's still a pretty good read if you want the low-down on what's actually in gasoline, what octane is all about, and why we have these pesky oxygenates. Here's the table of contents to whet your appetite.


3. What Advantage will I gain from reading this FAQ?
4. What is Gasoline?
4.1 Where does crude oil come from?.
4.2 When will we run out of crude oil?.
4.3 What is the history of gasoline?
4.4 What are the hydrocarbons in gasoline?
4.5 What are oxygenates?
4.6 Why were alkyl lead compounds added?
4.7 Why not use other organometallic compounds?
4.8 What do the refining processes do?
4.9 What energy is released when gasoline is burned?
4.10 What are the gasoline specifications?
4.11 What are the effects of the specified fuel properties?
4.12 Are brands different?
4.13 What is a typical composition?
4.14 Is gasoline toxic or carcinogenic?
4.15 Is unleaded gasoline more toxic than leaded?
4.16 Is reformulated gasoline more toxic than unleaded?
4.17 Are all oxygenated gasolines also reformulated gasolines?
5. Why is Gasoline Composition Changing?
5.1 Why pick on cars and gasoline?
5.2 Why are there seasonal changes?
5.3 Why were alkyl lead compounds removed?
5.4 Why are evaporative emissions a problem?
5.5 Why control tailpipe emissions?
5.6 Why do exhaust catalysts influence fuel composition?
5.7 Why are "cold start" emissions so important?
5.8 When will the emissions be "clean enough"?
5.9 Why are only some gasoline compounds restricted?
5.10 What does "renewable" fuel or oxygenate mean?
5.11 Will oxygenated gasoline damage my vehicle?
5.12 What does "reactivity" of emissions mean?
5.13 What are "carbonyl" compounds?
5.14 What are "gross polluters"?
6. What do Fuel Octane ratings really indicate?
6.1 Who invented Octane Ratings?
6.2 Why do we need Octane Ratings?
6.3 What fuel property does the Octane Rating measure?
6.4 Why are two ratings used to obtain the pump rating?
6.5 What does the Motor Octane rating measure?
6.6 What does the Research Octane rating measure?
6.7 Why is the difference called "sensitivity"?
6.8 What sort of engine is used to rate fuels?
6.9 How is the Octane rating determined?
6.10 What is the Octane Distribution of the fuel?
6.11 What is a "delta Research Octane number"?
6.12 How do other fuel properties affect octane?
6.13 Can higher octane fuels give me more power?
6.14 Does low octane fuel increase engine wear?
6.15 Can I mix different octane fuel grades?
6.16 What happens if I use the wrong octane fuel?
6.17 Can I tune the engine to use another octane fuel?
6.18 How can I increase the fuel octane?
6.19 Are aviation gasoline octane numbers comparable?
6.20 Can mothballs increase octane?
7. What parameters determine octane requirement?
7.1 What is the Octane Number Requirement of a Vehicle?
7.2 What is the effect of Compression ratio?
7.3 What is the effect of changing the air-fuel ratio?
7.4 What is the effect of changing the ignition timing
7.5 What is the effect of engine management systems?
7.6 What is the effect of temperature and Load?
7.7 What is the effect of engine speed?
7.8 What is the effect of engine deposits?
7.9 What is the Road Octane Number of a Fuel?
7.10 What is the effect of air temperature?.
7.11 What is the effect of altitude?.
7.12 What is the effect of humidity?.
7.13 What does water injection achieve?.
8. How can I identify and cure other fuel-related problems?
8.1 What causes an empty fuel tank?
8.2 Is knock the only abnormal combustion problem?
8.3 Can I prevent carburetter icing?
8.4 Should I store fuel to avoid the oxygenate season?
8.5 Can I improve fuel economy by using quality gasolines?
8.6 What is "stale" fuel, and should I use it?
8.7 How can I remove water in the fuel tank?
8.8 Can I use unleaded on older vehicles?
8.9 How serious is valve seat recession on older vehicles?
9. Alternative Fuels and Additives
9.1 Do fuel additives work?
9.2 Can a quality fuel help a sick engine?
9.3 What are the advantages of alcohols and ethers?
9.4 Why are CNG and LPG considered "cleaner" fuels.
9.5 Why are hydrogen-powered cars not available?
9.6 What are "fuel cells" ?
9.7 What is a "hybrid" vehicle?
9.8 What about other alternative fuels?
9.9 What about alternative oxidants?
10. Historical Legends
10.1 The myth of Triptane
10.2 From Honda Civic to Formula 1 Winner.
11. References
11.1 Books and Research Papers
11.2 Suggested Further Reading

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

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

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

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

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

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

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

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

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

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

This result, if true, is very interesting from a theory standpoint.

As far as practice, it's fairly irrelevant. Probabilistic primality testing can be done in constant time with bounded error.

The Miller-Rabin test will tell you if a number is prime with at most 1/4 probability of error. That sounds ridiculous, but the catch is that you can iterate it using a random parameter. Do the test twice and your probability drops to 1/16. Do it fifteen times and your chances of being wrong are about one billionth.

If you're truly paranoid, do it 50 times. That'll bring the error rate of the algorithm magnitudes below the error rate of your hardware.

---
Dum de dum.

I found it refreshing because it's very easy to get down, or confused, about the state of affairs today. A maniacal humorous take is just the right subjective approach. In Terry Gilliam's Brazil, there's like 10 lines of serious social criticism.. but the whole work is extrememly effective as a warning.

I think the people here, esp. the coders, didn't like the message because it involved so many threads that they can usually ignore. The idea that the inequity of software relationships can be seen from a much larger perspective, and somehow tie in with all of this messy political stuff, like diamond miners in South Africa... well, it's just frightening. Coders aren't diamond miners, after all! We're powerful important people. We aren't used by the man! The man loves us.. he gives us better TV to watch and dental plans.

Just this weekend on /. a great piece was posted, called "Reclaiming the commons". It was long and mainly about non-geek issues. Yet one of the /. editors highly recommended it. Why? It's not News for Nerds. It wasn't about the Sony P3's new chip. Why was it posted?

Bruce Sterling hit the nail right on the head. The geeks, he is telling us, along with everyone else are going to have to become dissidents, and then activists.

Because this is a real time of reckoning about freedom and how we may want to change the way we govern ourselves; we all should be prepared. Bruce Sterling's speech is a humorously contrarian introduction, aimed at geeks. But don't stop there.

Go and eat at an urban McDonalds, get a copy of US News & World Report, watch some MTV skin-flick or FOX News, or try not using your ss# for a while, or try tracking your vote to any actual political action (or comparing your vote to a company dollar), and top it all off with a visit to the local garbage dump, 'cause it's gonna smell better there.

Then go and read the commons article. Then read opensecrets.org, or cryptome.org, or the books "Understanding Power" (Chomsky) or "Empire" (Hardt & Negri) or the Declaration of Independence. Not that you have to sign-up with any political party, but these things will change your mind about how the world works, and your role in it.

At the end of doing all of this myself, I didn't needed to be preached to anymore. It's not just the software debate. It's not just the music debate. It's not just the accounting debate. It's the way of the world that is systematically confused. "The American Dream": this Ad sponsored by Pepsi and Brittney Spears' bouncing boobs. Is this really what it's supposed to be like?

I'm reading all I can and planning for a better way of life.

• We live in physical space and can be much more expressive in it
• Computers need to learn how to integrate into human social contexts (which are physical),rather than humans squeezing into computer models of interaction
• Comptuers currently demand direct physical attention through keyboards, mice, and monitors "chaining" us to our desks. Physical interfaces should make computers transparently integrated into our environment; especially important for engineering professions, construction work, etc.
• Physical computing is more adaptable to people with disabilities, since it's goal is to express information with more physical senses.
• The GUI's already been done and I need a research grant ;)

• We live in physical space and can be much more expressive in it
• Computers need to learn how to integrate into human social contexts (which are physical),rather than humans squeezing into computer models of interaction
• Comptuers currently demand direct physical attention through keyboards, mice, and monitors "chaining" us to our desks. Physical interfaces should make computers transparently integrated into our environment; especially important for engineering professions, construction work, etc.
• Physical computing is more adaptable to people with disabilities, since it's goal is to express information with more physical senses.
• The GUI's already been done and I need a research grant ;)

• We live in physical space and can be much more expressive in it
• Computers need to learn how to integrate into human social contexts (which are physical),rather than humans squeezing into computer models of interaction
• Comptuers currently demand direct physical attention through keyboards, mice, and monitors "chaining" us to our desks. Physical interfaces should make computers transparently integrated into our environment; especially important for engineering professions, construction work, etc.
• Physical computing is more adaptable to people with disabilities, since it's goal is to express information with more physical senses.
• The GUI's already been done and I need a research grant ;)

Last thing we will need though, is smell feedback.

Well, it's being done anyhow.

(although the criminals have no problem finding them),

Justify this statement. Put up or shut up.

I could say that the US media is one of the most censored media in the western world. Can I justify that? No I can't.

I can say that the US media is heavily censored, and one sided. Can I justify that, yes I can. (Read Naom Chomsky )

I'm not form Europe, or the US, and as an observer I'ld have to say I'l much rather live in Europe.
Something about a country when LESS THEN HALF the population bothers to vote some years scares me, and I dare anyone to come up with a good reason to have a M16 in their home.

You have a defence against excesses in government, its called a vote.
In my opinion, the idea that a small militia armed with handguns can defend their communities against a government in this age of jet fighters and saturation bombing is a joke. Notice that this is my opinion, so I'm not claiming it as a fact, and so I don't have to present evidence. I do think that there is room to argue this however.

I'm just feeding the trolls, and I should know better. My point still stands, If you want to make a claim, back it up.

If you have simply heard something, and can't site a source, say so.

Don't make statements that you have simply seen somewhere and present them as facts

Fact: I live in a country with more gun control then the US.

Fact: I have never seen a gun (outside a museum) that wasn't in the possession of a police officer or a security guard.

Fact: I'm 24 years old.

Anecdotal, but compelling.

Needless to say, companies that pull this kind of crap piss me off. They probably aren't even aware what damage they are causing to this particulary field of technology.

(ObOntopicUrl: League for Programming Freedom)

that would be pointless, the MIT guy didn't even attempt to break MS's 128 bit RC4 encryption in the first place.

their weakness was that the data actually travels un-encrypted along a high speed bus on the mainboard for a very short run, and is checked after that run for a 32 bit "magic number" at the end of their plaintext stream... that is the spot he watched, he made a lil device that plugged into that bus and read the data as it streamed unencrypted.

unless they encrypted traffic on that bus it would be totally pointless, and the MIT guy who did the research also points out all the complications that doing so would cause (latency, power consumption, reliability)

his research (pdf warning) really is a good read if you havent gone through it yet.

why not allow the teams to equip their subs with short-range torpedoes? [...] This would be even more badass if they used this instead

But, if I had a sponsor, I might reconsider...

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

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

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

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

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

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

To spice things up, why not allow the teams to equip their subs with short-range torpedoes? This would be fun to bet on. Also, it would serve as a more practical simulation of where modern warfare is headed. This would be even more badass if they used instead.

It's so conclusive that there was no need to bother us with the reply to the rebuttal, David Bollier Replies , I suppose.

Also, let's not confuse communism with the idea that some things should be jointly owned -- some natural resources, the military, the electromagnetic spectrum, etc.

I initially thought this story would be about defending the freedoms we've come to know and love. However, on deeper examination of comments such as this, it becomes clearer that the true motive is one of passive neo-anarchy. In a post-911 society, we cannot be swayed by such non-patriotic views. If this was the message they were conveying all along, they should be forthright about it, instead they masquerade as a "personal freedoms" advocate while subversively touting a nearly communistic viewpoint.

BTW, since when did Slashdot start openly shilling for Communism?

At 35,000 volumes, that donation certainly makes the Calgary collection larger than the MIT Science Fiction Society's collection. The MITSFS Collection has approximately 25,000 volumes, and is growing. I guess when the Gibson Donation is processed and shelved, it would take away the MITSFS's status as the world's largest open-shelved science fiction collection.

The size of the Gibson Donation is quite astonishing. The MITSFS Collection supposedly has 90% of all english-language science fiction ever published, and we have deals with the publishing companies to get a copy of every new SF book that comes out - often before the bookstores get them. I guess the Calgary donation has a lot of stuff that we totally overlooked (the Saturday Evening Post stuff), or else a lot of foreign language stuff (MITSFS isn't so strong on Japanese science fiction manga, for instance). If anybody is ever up in Cambridge, check the opening times, and stop by.

Patiwat Panurach
patiwat@sloan.mit.edu

At 35,000 volumes, that donation certainly makes the Calgary collection larger than the MIT Science Fiction Society's collection. The MITSFS Collection has approximately 25,000 volumes, and is growing. I guess when the Gibson Donation is processed and shelved, it would take away the MITSFS's status as the world's largest open-shelved science fiction collection.

The size of the Gibson Donation is quite astonishing. The MITSFS Collection supposedly has 90% of all english-language science fiction ever published, and we have deals with the publishing companies to get a copy of every new SF book that comes out - often before the bookstores get them. I guess the Calgary donation has a lot of stuff that we totally overlooked (the Saturday Evening Post stuff), or else a lot of foreign language stuff (MITSFS isn't so strong on Japanese science fiction manga, for instance). If anybody is ever up in Cambridge, check the opening times, and stop by.

Patiwat Panurach
patiwat@sloan.mit.edu

At 35,000 volumes, that donation certainly makes the Calgary collection larger than the MIT Science Fiction Society's collection. The MITSFS Collection has approximately 25,000 volumes, and is growing. I guess when the Gibson Donation is processed and shelved, it would take away the MITSFS's status as the world's largest open-shelved science fiction collection.

The size of the Gibson Donation is quite astonishing. The MITSFS Collection supposedly has 90% of all english-language science fiction ever published, and we have deals with the publishing companies to get a copy of every new SF book that comes out - often before the bookstores get them. I guess the Calgary donation has a lot of stuff that we totally overlooked (the Saturday Evening Post stuff), or else a lot of foreign language stuff (MITSFS isn't so strong on Japanese science fiction manga, for instance). If anybody is ever up in Cambridge, check the opening times, and stop by.

Patiwat Panurach
patiwat@sloan.mit.edu

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

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

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

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

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

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

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

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

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

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

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

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

>prices are in 1982 dollars, so let's say roughly double for 2002 dollars?

Don't worry, services were still charging exorbitant rates well into the 1990's...

I remember paying those rates just to enjoy access to their encyclopedia. :-) Fun calling up "page numbers" in Telix. It was like a giant interactive phone book!

• There is a [PDF]Pedal Powered Electricity Generator in the MIT Thinkcycle).
• There are small personal windgenerators (cheap?) used for yachting, caravaning,... (<100 watts) (by example Rutlands)
• There are small watergenerators (low head (2') or low stream (10gal/min)) like these from microhydropower.

The link I gave to SICP includes the full text in HTML. How much more free do you need it to be? It's accessible by clicking the link on that page which reads "Full text! The complete text in HTML". Unintuitive, I know, but that's the kind of thing you'll learn to understand as a computer scientist...

though many of the critics are ineed covered in the book: naming of variables, abstracting and not hardcoding stuff, making it readable, making it generic, wrapping code, etc.

These things have very little to do with computer science, with the exception of abstraction (which has very little to do with "not hardcoding stuff"). What we have here is a situation where people who know absolutely nothing about the current practice of computer science are using the term to mean whatever they imagine it means.

Variable naming, readability, wrapping code etc. all involve techniques which any good programmer should understand, academic or otherwise. But calling that computer science is like calling hammering a nail "civil engineering" or "materials science". The Python book, at best, could be described as an intro guide to software engineering, but even that's a stretch. It's really "how to program in Python", with a few technical terms introduced along the way.

If you actually look at the book in question, you'll see that the original poster was correct: it's not about computer science at all. It's a Python programming book with a marketing angle relating it to computer science.

If you really want a book which teaches "How to Think Like a Computer Scientist", try SICP. For a good summary of the book, see this comment from the recent "Best Computer Books" article.

(Further to my previous post) Quoting from the preamble of the GPL:

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

Now you think that would be pretty clearcut, wouldn't you? Nonetheless, in the case of RTLinux, RMS did publicly state the patent holder could enforce his patent against users of non-GPL applications running under a modified Linux system containing code subject to the patent, without violating the GPL. Go figure. That doesn't sound like 'everyone's free use'.

In the case of the RTLinux patent, luckily a workaround was found, which is even superior to the patented method, so the question of whether the patent holder really was violating the GPL became moot. But, not too surprisingly, here is almost the same thing come up again. RMS needs to take a position.

This is the introductory computer programming textbook used at MIT, and had been featured on slashdot here. However it is very different from what you would expect from such kind of books, with Scheme as the implementation language, it really does not teach readers how to code in a specific programming language, but how to program computers in a large variety of paradigms, what are the trade-offs in program design, how to manage complexity, and how the basics of computing works, by stretching the flexibility of the Lisp family of languages to the maximum. I first read it four years ago as a freshman, and it was a real eye opener. And it never ceased to amaze me through all these years, as I continue to discover new insights in the passages.

You can almost find a full undergrad CS program concentrated in this book, with topics including language design and computing paradigms (object-oriented, functional, imperative, non-deterministic and logic programming, as well as lazy evaluation), operating systems (issues of concurrency), architecture (the design of a register machine), and compiler construction (the reader is asked to build a Scheme compiler in the end). Instead of being filled with buzzwords, here you are shown how the basics of everything works, in ways that you can really understand. Working through this book will teach you concepts that many people with a CS degree had never heard of.

Hell, if I could only save one CS book when the world comes to an end, this would be the one. And the best part is: you can get the full-text online here at MIT Press. Definitely a must read.

SICP.

(Structure and Interpretation of Computer Programs, a fine book that'll teach you more about programming than should be allowed by law)

So I suppose MIT beat all the other ivy-league schools with respect to not getting hacked but then again what should you expect from the home of "hacks".

This one is good.

I wonder if this recent act violates those rules?

Fortunately MIT does this a little differently and slightly more hacker proof. They don't rely on any publicly (to any admissions office) available information but assign you with a unique 9-digit id number from the beginning of the application process and all of your online information is tied to this id.

I should point out that you can only view your status (summary of received documents and final decision, nothing else) if you have this id and a last name but to actually update and change information on their information system you require a kerberos identity, the passphrases for which are sent (regular mail) after you're confirmed and accepted admission. I recall that the initial id-number is sent to you via regular mail with a confirmation that they received your application and assigned an interviewer etc.

Basically as long as you're not a complete moron (I think it is safe to assume this if you have been admitted to MIT) you're probably not going to give out your ssl-certificates or give out your id/uname/pw-combo plaintext over internet (and if you do you're totally responsible for all the misuse - they're not going to clear your name).

So I suppose MIT beat all the other ivy-league schools with respect to not getting hacked but then again what should you expect from the home of "hacks".

Quite similar to Image Mosaics, a project we did in the Image and Video Processing class with Prof. Sclaroff. Here's my take on the project (inluding the source code), with a pretty good explanation of how to do this: Go here...

It was first seen on the night of 5 July, picked up by the Linear Observatory's automated sky survey programme in New Mexico, in the southern US.

I work at Lincoln labs and acutally know the people running the LINEAR project (they are so proud that they are the best in the world, let me tell you). But for the rest of you, here is their website.

They find more than half of the new NEO (Near earth orbit) asteroids each year that are found. They have a telescope down in New Mexico and have the largest CCD (2560x1960 res) in the market. That's the thing that takes a digital image of the sky and compares it to past images to see if any "stars" have moved...i.e asteroid. The higher resolution you can get, the further out you can see. From their webpage, you can see they have found at least 951 NEO's. So there are a LOT of asteroids comming near us. But in space, near is still very far away. So unpack those bunkers and return to Real Life, we're still safe for a while. Also, the rate of finding new NEO's is decreasing, so that means that we've (humans) found most of the asteroids that can endanger us.
(most of that was taken from this post of mine from a while ago)

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

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

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

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

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

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