Slashdot Mirror

Education is going online. MIT is pioneering this trend with OpenCourseWare, which aims to make all course materials available on the Web, free of charge.

Why is it important? Because it will turn the joke "Try finding some porn on the net (if you fail kill yourself inmediately)" into "Try finding some info about -your asignature here- (if you fail..)". And this is not just about "free information", it's a better way of learning.

Example: Have you ever been in class with 50 students writing down nearly identical notes? how often did you find enlightment there? I believe everyone should be able to learn at his own pace. That means grabbing the info, studying it, and then spending class time in a more valuable way. Plus it's more rewarding when you are in control of your own learning process.

Anyway, the opportunity is writing software to manage and play with that information. I'll give you an example..

Right now Im having fun feeding a chatterbot with my papers (just a matter of xml+xsl=aiml) so any student can go to my page and just say:

More valuable examples are left as an exercise for the reader.

It always surprises me that people treat Marc Andreessen as a "visionary". As I see it, he's a programmer of some talent who happened to be in the right place at the right time to be tapped by Jim Clark (the REAL visionary) to take his browser (which he did not invent, but merely polished the creation of Tim Berners-Lee) and try and make a new industry with it. Without Jim Clark (not just his money, but his business sense and entrepreneurial spirit), nobody would know Marc Andreessen today.

Out of curiosity, were you around on the Internet in 1993-1994? Marc was the lead developer who came up with this incredibly addictive toy whose usage was doubling every month and generating a huge stir. I avoided it for six months in late 1993 and early 1994 having heard how cool and addictive it was, lest I further neglect my studies. It was really the first piece of software that blended three elements: hypertext information retrieval, GUI ease-of-use, and layering that on the worldwide Internet infrastructure. (A decent account of what he did, and which elements were new, can be found at MIT's Inventor's Dimension.) Don't underestimate that GUI component, which was Marc's main contribution; it's what made the Internet accessible to the masses.

Clark was a techie turned capitalist who, having failed to figure out how to take the 3D graphics technology he had pioneered at SGI and make money in the upcoming PC 3D graphics revolution (which he foresaw, but ducked: full 3D on a chip costing $20 and selling on PCs for $30-200) was looking for some new arena where he could 'win' and turned his attention to how to make a buck on this new "Mosaic" thing. He succeeded brilliantly, but as with SGI, he never figured out how to take a technology he had pioneered and turn it into a business with a defensible end-game. Clark has some business sense but I think his virtues are a lot more a shrewd sense of timing and trends than an ability to build a sustainable business. This might be too harsh on him; perhaps it was an impossible task given his "competition": the leverage of Microsoft. But the failures at SGI and Netscape were failures of business vision and strategy, his responsibility, not failures of the technology guys, Mark Andreesen (or, say, Kurt Akeley).

I'd agree with you that Jim Clark was responsible for giving Marc the name recognition that he has today... Clark did this I presume since he recognized that anyone could go build a browser, but only one company would have the "inventor of the browser" on their staff and the insight, marketing, and recruiting advantages that would bring. Without that, Marc would only be as famous as, say, Tim Berners-Lee. You've heard of him, I notice. And I'd agree that Marc Andreesen noticed the missing pieces in part because he was at the right place at the right time, developing software at a university that was a supercomputing center hooked into the physics community of Tim Berners Lee, etc. But it was Marc who saw how to turn a hypertext system for publishing physics papers and linking footnotes into a mass medium.

Marc's vision was innovative and technical and it succeeded. Jim Clark's vision was business-oriented and capitalistic (which is no crime) and it failed after making a few rich. Now who deserves accolades as the visionary?

--LinuxParanoid, who didn't have enough vision to accept that offer to attend University of Illinois in the early 90s...

You might also look at The New Turing Omnibus: 66 Excursions in Computer Science by A. K. Dewdney from W. H. Freeman & Co. (ISBN 0-8050-7166-0) which is a good source for important and interesting CS topics, though it may be more work to construct concrete projects.

You might also look at The New Turing Omnibus: 66 Excursions in Computer Science by A. K. Dewdney from W. H. Freeman & Co. (ISBN 0-8050-7166-0) which is a good source for important and interesting CS topics, though it may be more work to construct concrete projects.

Not to start a GPL-free v. BSD-free flamefest, but the Tux, real-time, and secure Linux patents harm BSD, which is part of the free software community.

A patent is least harmful as part of a patent pool, as described in "Mutual Defense Against Software Patents."

Since Scheme is so simple, this is surprisingly easy to do, and it's a great learning tool. It helps students understand what's really going on when they run their program.

See Abelson and Sussman's classic computer science text, Structure and Interpretation of Computer Programs (aka The Wizard Book), for details. This book is also an excellent introduction to the basic concepts of computer science.

This is not just some whacko, this is one of the most respected Intellectuals in the US. He's not making it up, though he might be emphasizing certain aspects to make a point. His homepage at MIT (where he is a professor of linguistics) is here. Don't just dismiss him, his writing carry a lot more weight and respect then, for example, yours.

Do you think stories could use fewer links so readers can just focus on the specific article instead of having to sort through every link under the sun? Most stories should have just one link (additional cool pictures excepted, of course).

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 filure 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, BS 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.

Let's save time and say that the human genome is a round 750 MB (it's about 3 gigabases, each base is two bits, so it's 750 MB.)

It cost about US $300 million. The project cost of 3 bil, bandied about, is the amount we expect to spend in the period from about 1990 to 2005 (reference, search page for "billion") on projects related to Genomics, which is the study of biological sequences, not just the human genome but a wealth of other information (including information about protein structures and the like - I generated four gigs of analytical information just this afternoon.)

Regardless, if you say that the fruit of the $300 million spent directly on the human genome is ONLY the human genome, and not all of the other data (such as correlations with other genomes which is what I was evaluating today, or the information about the number of genes, etc.) it still works out to about $US 0.40 a byte (300 bil over 750 MB). Dear, but not even in the running for most expensive data ever.

A pricing problem - do you pay for the source code, or the binary? If you're paying for the source code, I'm sure somebody, sometime, charged a full years salary to develop a Perl program 70 or 80 ASCII characters long. It could run hundreds of dollars a byte, easy.

The total cost for Phase One ("working draft") is approximately $300 million worldwide, with roughly half ($150 million) being funded by the US National Institutes of Health.

The Human Genome Project is sometimes reported to have a cost of $3 billion. However, this figure refers to the total projected funding over a 15-year period (1990-2005) for a wide range of scientific activities related to genomics. These include studies of human diseases, experimental organisms (such as bacteria, yeast, worms, flies, and mice); development of new technologies for biological and medical research; computational methods to analyze genomes; and ethical, legal, and social issues related to genetics. Human genome sequencing represents only a small fraction of the overall 15-year budget.

Thank you for providing no factual information whatsoever. While his results may be true, telling us that he is a "left-wing sympathizer who is vegetarian because he does not want to kill animals" is entirely useless. 1) He may be saying this to make people more likely to believe he is an impartial researcher, 2) acceptance of his theories should be based on their reflection of the facts, not what kind of food he eats, 3) giving lectures/debates at famous places does not make a theory true - this is similar to saying, "If it's on TV, it must be true." And remember, Gene Ray of Time Cube fame lectured/debated at MIT.

Remember: Everyone is biased. That's why you need to look at the facts instead of trying to find someone who can justify your views. But then, you have to be able to overcome your own biases for this to happen.

Thank you for providing no factual information whatsoever. While his results may be true, telling us that he is a "left-wing sympathizer who is vegetarian because he does not want to kill animals" is entirely useless. 1) He may be saying this to make people more likely to believe he is an impartial researcher, 2) acceptance of his theories should be based on their reflection of the facts, not what kind of food he eats, 3) giving lectures/debates at famous places does not make a theory true - this is similar to saying, "If it's on TV, it must be true." And remember, Gene Ray of Time Cube fame lectured/debated at MIT.

Remember: Everyone is biased. That's why you need to look at the facts instead of trying to find someone who can justify your views. But then, you have to be able to overcome your own biases for this to happen.

Thank you for providing no factual information whatsoever. While his results may be true, telling us that he is a "left-wing sympathizer who is vegetarian because he does not want to kill animals" is entirely useless. 1) He may be saying this to make people more likely to believe he is an impartial researcher, 2) acceptance of his theories should be based on their reflection of the facts, not what kind of food he eats, 3) giving lectures/debates at famous places does not make a theory true - this is similar to saying, "If it's on TV, it must be true." And remember, Gene Ray of Time Cube fame lectured/debated at MIT.

Remember: Everyone is biased. That's why you need to look at the facts instead of trying to find someone who can justify your views. But then, you have to be able to overcome your own biases for this to happen.

Incidentally, for those who are interested in more normal approaches to game tree search, the second issue of the ICCAJ which I've referenced above contains one of the most important papers in computer chess history, by Chrilly Donninger.

Incidentally, for those who are interested in more normal approaches to game tree search, the second issue of the ICCAJ which I've referenced above contains one of the most important papers in computer chess history, by Chrilly Donninger.

if they would have developed this 20 years ago, i had probably found it advanced cutting edge technology as what regards a.i.

from today's research perspective, the concept of "expert systems" in a.i. is just old-fashioned nonsense. expert systems will never be able to produce or simulate intelligent systems. instead, the concepts of new a.i. might offer a perspective to do this.

for information about "new ai", take a look at unizh ai lab (switzerland) or mit ai lab (usa). they both teach it.

Ralph's agenda is long term. We'll get there eventually, but before we do, we'll spend a lot of time puttering around with simple bacteria. Tom Knight is already starting that effort, which he calls microbial engineering. This is very cool, commendable work.

But there are limitations. You can make cells do logic operations, but they do them very slowly. Each cell has a very limited number of usable state variables. As long as we are starting with life, we are stuck with the limitations of cells. Cells can easily be programmed to make proteins, which don't have very desirable material properties, but to make more interesting stuff like tooth enamel or spider silk you need much more cleverness.

What's nice about cells is that they are inexpensive replicators that work today. What's bad about them is that humans never got a vote on the basic design, simplicity was never a design goal, programming them is hard, and the range of things they can be programmed to do is limited.

Ultimately we want a human-designed replicator that comes with a manual, is easy to program, and can do lots of different things.

There was a pretty good article about the "blogosphere" a week or two ago. Very long, and relatively interesting, especially if you are interested in blogs, journalism, news, and that sort of thing. If you have a blog, you might like it too. If you are interested, I've got interview questions sent off to John Hiler, the author of the blogosphere article. I think he'll be getting back to me in a few days. I'll have the interview posted on WebWord.com soon after that.

There was also another story making the rounds about a week ago about making a living from blogging. I was expecting a lot more from it, i.e., some real details on "how to do it", but it was still a reasonable article. It might give you some ideas. Mileage may vary.

Last link whore comments: If you haven't seen Blogdex or Daypop, you might want to check them out. Very nice tools to see what it hot in the world of weblogs.

In 1996 Paul Krugman, MIT economics professor and wirter of the Dismal Scientist column in Slate, wrote this column about a look back at what happened to content providers from 2096. Krugman's overriding point is that in a digital environment content ends up being free, and people that actually make tangible non-digital things (blue-collar-type jobs) will get the benefits of the future.

His model for music in a post-Napster environment is that music is delivered free to promote attendance at live concerts.

I particularly enjoyed the part where he predicts the demise of economists' perk jobs and he's writing part-time from a vet clinic.

I weep not for the end of Madonna and her ilk's excess. It's far more important what happens to the average plumber then it does for these pampered poodles.

You may want to check out MIT's project Athena (Academic Computing at MIT). They have been using UNIX machines for the student-wide computing environment which includes all different kinds of applications (word processors, spreadsheets, CAD software, scientific applications, programming environments, instant messenging). There is also a Linux and a NetBSD version of the Athena environment.

I haven't been following the developments but I believe they were looking into introducing more Linux machines in the computer labs and enriching the Athena environment by adopting GNOME.

Perhaps some current MIT student can provide more information.

Here's some links:

An overview

A dated article from the MIT student newspaper.

An FTP server where you can download the Athena software (MIT license)

You may want to check out MIT's project Athena (Academic Computing at MIT). They have been using UNIX machines for the student-wide computing environment which includes all different kinds of applications (word processors, spreadsheets, CAD software, scientific applications, programming environments, instant messenging). There is also a Linux and a NetBSD version of the Athena environment.

I haven't been following the developments but I believe they were looking into introducing more Linux machines in the computer labs and enriching the Athena environment by adopting GNOME.

Perhaps some current MIT student can provide more information.

Here's some links:

An overview

A dated article from the MIT student newspaper.

An FTP server where you can download the Athena software (MIT license)

You may want to check out MIT's project Athena (Academic Computing at MIT). They have been using UNIX machines for the student-wide computing environment which includes all different kinds of applications (word processors, spreadsheets, CAD software, scientific applications, programming environments, instant messenging). There is also a Linux and a NetBSD version of the Athena environment.

I haven't been following the developments but I believe they were looking into introducing more Linux machines in the computer labs and enriching the Athena environment by adopting GNOME.

Perhaps some current MIT student can provide more information.

Here's some links:

An overview

A dated article from the MIT student newspaper.

An FTP server where you can download the Athena software (MIT license)

MIT's Athena computing environment runs on Dell Linux boxes, Sun workstations, and a few IRIX machines, and accounts are granted to all students. These *nix machines, with the exception of a small media cluster, are the only public machines available.

It was paid for out of the budget for the group that I work for within the Lab for Computer Science. There are quite a few good mirrors here. Check out xyz.lcs.mit.edu for a bunch more.

Is this really just a protocol I can compile into my kernel, configure a few things and just punch in a ipv6 link? Or is it much more complicated than that, requiring special network hardware and access. I'd love to play around with it, I'm sure we'll all make the switch one day, I'd like to be ready.

You don't need to do anything special at all to be on Internet2, except be in the right place. You don't need to speak IPv6, either. Most I2 traffic is IPv4 generated by people who don't even know they're going over I2. The only thing is, you pretty much have no choice but to be at a US university in order to access I2. Chances are, if you're at one, and communicating with another, you're going over I2 without even needing to know about it.

On the other hand, if you want to play with globally routable IPv6, there are tons of resources for that and you don't need anything that you can't download. I posted some links in a recent Ask Slashdot article on IPv6. Check them out. You will be able to speak IPv6 on the Internet using 6-to-4 translation, which Linux and *BSD can do just fine. Or you can get a free tunnel via Freenet6, though I've not played with that at all.

Have fun.

noah

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.

Starting with Eric Raymond's groundbreaking work, "The Cathedral and the Bazaar", open-source software (OSS) has commonly been regarded as work produced by a community of developers. Yet, given the nature of software programs, one also hears of developers with no lives that work very hard to achieve great product results. In this paper, I sought empirical evidence that would help us understand which is more common - the cave (i.e., lone producer) or the community. Based on a study of the top 100 mature products on Sourceforge, I find a few surprising things. First, most OSS programs are developed by individuals, rather than communities. The median number of developers in the 100 projects I looked at was 4 and the mode was 1 - numbers much lower than previous numbers reported for highly successful projects! Second, most OSS programs do not generate a lot of discussion. Third, products with more developers tend to be viewed and downloaded more often. Fourth, the number of developers associated with a project was positively correlated to the age of the project. Fifth, the larger the project, the smaller the percent of project administrators.

Starting with Eric Raymond's ground-breaking work, "The Cathedral and the Bazaar", open-source software (OSS) has commonly been regarded as work produced by a community of developers. Ghosh's cooking pot markets, similarly, point to a communal product development system. Certainly, this is a good label for some OSS products that have been featured prominently in the news. For instance, Moon and Sproull point out that by July 2000, about 350 contributors to LINUX were acknowledged in a credits list in the source code of the kernel.

However, my goal in this paper is to ask if the community-based model of product development holds as a general descriptor of the average OSS product. I systematically look at the actual number of developers involved in the production of one hundred mature OSS products. What I found is more consistent with the lone developer (or cave) model of production rather than a community model (with a few glaring exceptions, of course).

This is not to say that there is no community in the OSS movement. For instance, the findings of Butler, Kiesler, Sproull and Kraut (2002) point to participation by individuals other than the creators of OSS-program-related mailing lists. My contention is only that communities do things other than produce the actual product - e.g. provide feature suggestions, try products out as lead users, answer questions etc. Formally separating software production from other steps in the development of OSS programs will provide greater clarity to the discussion of the OSS phenomenon.

Curious about it, I googalized "Structure and Interpretation of Computer Programs". Guess what came up as the first hit?: http://mitpress.mit.edu/sicp/full-text/book/book.h tml It appears to be the full text online!

Or use this one, if you must

SICP online (my god that background is ugly)

Not to be confused with the Society for Invasive Cardiovascular Professionals, mind you.

Nonsense. This book has nothing to do with IT fundamentals, OO or otherwise. As many people have pointed out, at best it can be regarded as a roll-your-own appendage to cover the flaws of current mainstream languages. This situation does not apply in academia - they can use any language they like.

• Scheme
• Programming:
  • Recursion and iteration
  • Continuation
  • Debugging!
  • Types and type hierarchies
  • Infinite data types!
  • ...
• Time complexity
• Abstract models of computing
• Functional programming
• Object-oriented programming
• Logic programming
• Memoization
• Interpreters
• Compilers
• Language design
• ...

Just the "Table of Contents" should be enough to set any red-blooded programmer on "DROOL".

Scheme has trivial syntax. This lets the authors explore semantics in amazing detail. Scheme's semantics are explained using progressively finer (and more accurate) "models". Eventually these models are implemented, in the form of interpreters and compilers for interesting subsets of Scheme. Meanwhile, various data types are presented. Unlike the vast majority of programming textbooks, arrays and array-based types are given little space. Meanwhile, lists, trees and various (potentially) "infinite" data structures are examined.

Models are also given for other types of programming, including a machine code, a logic programming language, and the pure functional style. Functional programming is used extensively (assignments are deliberately rare) but not fanatically.

An amazing introduction to the subject (even if you already know it).

I found this book online here if anyone is looking for it.

The best introductory computer science textbook is "Structure and Interpretation of Computer Programs", also known as the wizard book because of the wizard on the cover. I've also heard good things about "How to Design Programs." Both of these books avoid the pitfall of focusing on syntax by using Scheme, which has very little syntax. I haven't read HTDP, but SICP is the best introductory computer science textbook I've read, and many computer science educators agree.

It's the standard MIT intro text. Philip Greenspun called it the "one great book on the subject of computer programming". It's even online!

The only caveat is that students reportedly find it hard to absorb on the first pass--even at MIT. (This is second hand information--I didn't read SICP in a class, nor did I go to MIT. I read it after programming professionally for a few years, and loved it.)

I'm sure many people here are already familiar with it, but if you're not it's worth a look.

I'm sure many people here are already familiar with it, but if you're not it's worth a look.

BTW Amazon has Cable Modems from $49.99!

There is also this list of electronics flea markets for the North East

I imagine there are a few someplace near silicon valley as well as CalTech, etc.

;-)

There is also this list of electronics flea markets for the North East

I imagine there are a few someplace near silicon valley as well as CalTech, etc.

;-)

Microsoft needs to change its attitude towards Open Source for the same reason that the dinosaurs needed a near-earth asteroid search.

Unfortunately for them, they are as likely to understand Open Source as the dinosaurs were to understand the technology necessary for a near-earth asteroid search.

Unfortunately for us, the analogy is also likely to work in that it took the dinosaurs hundreds of millions of years to go extienct, and similarly Microsoft is likely to be around and dominating the planet for some time to come....

-Rob

He does far more than reverse-engineer the XBox. Read this guy's project list. He's cranked out an incredible list of hardware projects. His own RISC CPU. A DES cracker. A controller for a midget submarine. An all-new design PBX for his frat house. Keyboard pedals for EMACS. A Linux-based computer that fits in a Star-Tac phone case (in progress.) Plus he's in a fraternity, plays guitar and violin, and has a blonde girlfriend. And all this while doing a thesis at MIT.

Here is a link to a recording of the call he recieved from MS
xboxedited.mp3

(poor mit's server...)

OK, I've skimmed the PDF, and while the words "security holes in the XBox" in the article may lead you to think about traditional software buffer-overflow-I've-r00ted-your-box types of security holes... this article is about HARDWARE!! The PDF talks about hacking the hardware and getting around the encryption on the bootloader to be able to load your OS of choice, for example.

Meanwhile I'm reading posts from people who are nearly soiling themselves afraid to plug their XBox into a network for fear of being r00ted. What a joke. I bet when michael saw the words "XBox" and 'security hole' in the same sentence, he became so excited and nervous that he could hardly move his finger to click the button on the mouse. Sheesh.

• Bunnie's XBox Hacking Site (he's the guy that wrote the paper)
• XBox Linux Project
• XBawx.org
• XBox Linux Mailing List
• XBox Hacker Forum
• Xtreme XBox

He frequents the Xbox hacker msesage boards. Heres what else he had to say about Microsoft in this post...

"To answer some specific questions:

no, I will not publish the encryption key or the boot block. That's Microsoft copyright material, and I respect their copyright.

Microsoft is not particularly happy about the paper, but they seemed to concede that well, reverse engineering is protected by law, so there's nothing they can do about it. Let's hope they don't change their opinion...they've been known to go back on their word before. "

also, from his website...

"You are actually allowed by law to reverse engineer copyrighted code so long as it is necessary to discover the ideas or functional elements behind the code (still, I'm not allowed to post copyrighted code for free distribution). Hey, microsoft...what are the ideas and functional elements behind your BIOS ROM? ... hmm...patent search turns up nil on the Xbox...guess we'll just have to reverse engineer it. (FTR, Nintendo has patented what looks to be the entirety of the N64 console, thus perchance making reverse engineering an N64 illegal--not yet court tested.)"

I like this part about MS guy:

The speaker at this talk also indicated that the kernel on the Xbox is a much-stripped-down Win2k derivative (from 12 MB to around 23kB).

(from their website)

Here is the guys website (bunnie), with a ton of other hacking information not in the whitepaper.

He also has an alternative link to the paper.

Here is the guys website (bunnie), with a ton of other hacking information not in the whitepaper.

He also has an alternative link to the paper.

What We Can Learn From BSD

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