Slashdot Mirror

Worked at the MIT Media Lab a few years back, and we had a system there that gave similar 3D display off of an LCD screen, but without a fixed head position (using a digital camera to track user position and adjust viewing locations accordingly). I reworked a 3D game engine to run on the system...deathmatch was a lot of fun.
Check out the overview.

Linux has no useful apps or games

Are you kidding me? Linux has lots of games. For instance, Linux has XBill (shoot the evil computer crackers), Tux Racer (snowboarding), Tetanus On Drugs (a tetris clone with a twist, literally), all of the GNOME Games and KDE Games, and several id Software games. For more, go to SourceForge Gaming Foundry or Freshmeat's games section, both brought to you by OSDN Keiretsu.

And through emulation and virtualization, you can run even more games. Most of the 2D games run on WINE. Older PC games should run on DOSEMU, plex86, or Bochs with FreeDOS installed. If you have an NES cart reader (hard to find), Linux has every NES game ever produced, through FCE Ultra. If you have a GBA cart reader (easy to find in online stores; look for the Visoly Flash Advance Linker), Linux has every GBA game ever produced, through VisualBoyAdvance.

On the hardware side, Linux supports game port joypads, USB joypads, and even game console joypads connected through a parallel port adapter.

because it was written by a bunch of stupid communists.

One of the most popular video games in the world, Tetris, was written by citizens of a Communist country as well.

i would've thought that more important than explaining bombardier beetles' butts would be its relevance to the theories of stephen jay gould and richard c lewontin. sadly, mr gould is no longer among us.

if you want to read more about their theories start here.

Have you actually read the theory of intelligent design at all? It's the most utterly ridiculous thing I have ever read.

Here is a site refuting the idea of intelligent design.

Here is an essay by William Dembski expaining the theory behind ID.

If you read both and still think that ID is a good thing (tm), you're either

A. Not very good at math or
B. Gullible

My apologies to your crackpot professor.

I am still responding to this because you are insulting everyone who has chosen Linux as their daily desktop OS (myself and most of slashdot) by saying that it shouldn't even be considered as a choice.

Since you had a rather long post, let me see if I can sum up your points, and provide a brief response to each.

1. The least computer savy person you know needs to be able to get images from her digital camera and manipulate them. This can be done in Mac/Windows, but not in Linux.

The least computer savy person may not have the least demanding needs, but rather advanced needs (like friend); a very computer savy person may not have the most demanding needs, but instead rather basic needs (like myself). So your example of what "the least computer-savy person" you know needs to be able to do on a computer isn't representative of the basic needs people have of a computer, which everyone who buys a computer today will want to do. The most basic computer needs are document presentation/preparation (i.e., MS Office / Open Office), e-mail checking, internet browsing, DVD-watching, and MP3-downloading. You say "no-one downloads MP3's" because that's illegal; well, forgetting about the legality of it, there's at least 60 million nobodies who used Napster to download MP3's. Must be alot of nobodies in your world.

But anyways, lets run with your "least computer-savy person," who needs to get images from a digital camera and perform simple manipulation to them. For the manipulations you mentioned and any other simple manipulations which a typical user of PhotoShop would perform, the GIMP would work fine; its only for the more advanced manipulations which professions would need to do where the GIMP wouldn't suffice. In that case, PhotoShop runs fine via Wine or VMware in Linux. Any major application like such (i.e., MS Office, Quicken, Photoshop, etc) will run fine under Linux via Wine; if not, VMware can always be used. Games or anything which requires intensive reiterated calculations won't work well under Wine or VMware, but such applications are usually only for scientific and professional special effects, of which there are many in Linux.

So, your friend can in fact manipulate the image using either GIMP or PhotoShop in Linux. She also use the tools provided in gPhoto, or Agfa. I'm sure there are many more tools, but that's beside the point.

You also seem to imply (if I read you right) that there's no way to get images from a digital camera to your computer using Linux. At first, I thought that would be hard as I figured it'd require specific drivers; however, one can simply mount the digital camera's hard drive like any other device. Though the explanation of how to do it in this article is a very tech-savy, I'm sure there's easy-to-use UI interfaces which simplify the process.

2. GNUcash is inadequate for the typical home users financial needs. Home users need something like Quicken.

Lets just say that your description of what the typical home user needs is correct; big deal. Run Quicken through Wine or VMware. As I said before, applications which don't require reiterated runs of a complex number-crunching algorithm will run fine under Wine.

3. Because the majority of the many software packages included in Linux are useless, their sheer number is irrelevant.

Really? Have you looked any of the some 7,000 packages in Debian? I'd suggest you check out Debians' Editors, Electronics, Graphics, Ham radio, Mail, Mathematics, Newsgroups, Science, Sound, and WebSoftware. There are many useful packages that come with (for example) Debian. gPhoto is one of them. Please do care to check out your facts before stating something patently false.

On that note, I must say that's one big flaw in every Linux distro I can think of. None of them let you know all of the applications on them. There are tons of useful packages, but the user isn't made aware of them (i.e., gPhoto for digital cameras). There should be something like a graphical menu which lists a bunch of things you want to do, where you select one and then it lists all the tools for that and descriptions of the uses of each. I'll admit its little good having all these packages if the average user (like yourself, obviously) is completely unaware of them.

4. There's nothing one can do in Linux, scientific or otherwise, that can't be done in Windows or Mac. If there is, one can recompile the program for Mac or Windows, or port it.

Well, to name one app which you doesn't work as is on OSX, LightSpeed. You say you can recompile it for Mac or Port it to MacOSX; true, but the average user doesn't even know what the world compile means (let alone recompile) or what the word port means, except in reference to the left side of a ship.

5. The ability to customize software to one's needs is irrelevant; all that matters is having an easy-to-use default configuration, which can be intuitively understood.

I'll agree that an easy-to-use default config is needed in order to help orient a user new to the software. However, default configs are necessarily inefficient for every user. Different users use software in different ways, and will work more efficiently if they eventually can adjust it to meet their needs. For example, I like things best when I can for all programs to make F1 the first menu, F2 the second, F3 the third, and so on, as was the case back in the old DOS days; I really feel that's a much better way of doing things than Alt-F for file menu. F1 is one button, and always the first menu -- rather convenient.

6. The license under which an OS is sold/given away is irrelevant to the user.

A rather naive statement. What happens when MS raids your company and you can't find documents proving you bought every copy of Windows running? A million-dollar settlement, in which you effectively agree to whatever terms MS dictates; that's what happens. Same thing for Apple, though we haven't heard as much about that. What happens when you post or want to download an improvement to an application, which is prohibited by its EULA? Well, if you post an improvement, your legally liable. Same thing if you download one, though there's little way to enforce that. I can go on and on. In short, its the difference between enslavement (MS/Apple in the GUI) and freedom (BSD/Linux); namely, the enslavement or freedom of the user. There's a good reason why Richard Stallman created the FSF.

7. For Linux advocates, it all comes down to "you should use Linux because of politics"

An invalid simplification. For people who believe as Richard Stallman and the FSF do, the main reason one should use Free Software is because it gives one freedom; another good reason is that, in general, they think its better. For people who believe as Linus Torvalds and the OSS does, its just the oppostie: you should use Linux because in general its better, then because it gives you freedom. In short, I'd say that about half of the Linux community believes in using it because of its technical superiority, as they see it (this is verified by the fact that Linux outperforms, for example, Win2k and *BSD in server performance tests).

Now, I realize that you probably have one more objection to my post: still, why use Linux? You can accomplish all the same stuff in Mac OS X and Windows.

Well, regarding Windows, there are no powerful Unix commands unless you get Cygwin or something like it, which is not an adequate solution; also, you don't benefit from the superior performance, security, and stability of Linux. Despite XP's stability improvements, its still not as stable as Linux; and its, as Steve Balmer of MS says, "just not built with security in mind".

Regarding MacOSX, it is true that it basically offers alot of the functionality of Linux through the terminal. But its based on BSD and Mach; and performance tests have shown that Linux outperforms BSD, though not being as secure out of the box. However, Apple's OSX is not shipped secure out of the box, as is OpenBSD, so that's a non-issue.

Performance aside, basically MacOSX basically offers all of the same powerful UNIX applications that Linux does. So why use Linux over MacOSX? Simple: cost. Do you really expect PC users to buy much more expensive Macs when essentially the same performance is available from a PC at a lower cost? Do you really expect them to dump their PC w/c they paid for just to buy a Mac with OSX on it?

What about for people who already have Mac hardware or like Mac hardware better? Linux is still a better cost option. OSX is some 120 or so dollars. Linux can be free if you download it, and if you want to buy the CD, ranges from $60 dollars for personal RedHat t o $15 or so for Debian. For that money ($0 [or the cost of downloading it] to $60) you get a OS with functionality equivalent to MacOSX. Additionally, you get tons and tons of useful software packages, which had you bought proprietary equivalents of would probably cost you tens of thousands of dollars. For example, just think about how much it would cost you to buy the proprietary equivalents of all he compilers that come with Linux for "free" or nearly so.

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.

Kerberos? It was never designed to resist attacks in which a listener can capture packets.

Aroo? That's exactly what Kerberos was designed for. It was created to provide security over MIT's (physically pretty much wide open) network.

From the web site (emphasis added):

Kerberos was created by MIT as a solution to these network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.

I've had the pleasure and opportunity to be involved in the Web development side of MIT OpenCourseWare (OCW), and just from coding up all the sample exams, lecture notes, handouts and problem sets I've learned an amazing amount without even intending to. Today, for instance, I'm delving into the world of Linguistics and the intricacies of Tagalog and Athabaskan Slave-Hare.

It is not just the usual course syllabus and general course information going up on these sites.

It is important to keep in mind that Sept. 30th is the "public beta" of the pilot site for the MIT OCW project. We are making our first batch of course sites available to the world, while we continue to work out the kinks and bugs in anticipation for the full launch a year from now.

For someone who is self-taught in Web development and research (like many others here), MIT OCW is not just a valuable tool for teachers and people already knowledgeable of the subject matter on the site, it's an incredible resource for everyone who has access to it -- from the very basic programming skills taught in "Introduction to Computers and Engineering Problem Solving," to the complex mathematics of nonlinear dynamics and chaos theory.

Definitely check out the site on Sept. 30 and let us know what you think. Your feedback will help us as we continue to improve.

I'm not saying routing dynamic mesh network is impossible, it's just very hard

Yes, it is, and I'd have to say that I don't think the routing is "there" yet. By far the best resource I've found on the topic is Perkins's Ad Hoc Networking which describes several types of protocols. Some of the work on overlay networks (e.g. Resilient Overlay Networks at MIT) and P2P is also applicable, though much of it tends to underestimate the importance of geographic locality and little of it deals with issues like routing-related power consumption.

I think the main reason I'm bitter is I would like to have put something on the dome, but $100,000+ over four years to put something on the dome is a little much. Besides that, I have no regrets of completing my undergraduate studies at a public institution, debt-free. In fact, I think it is smarter to save on one's undergraduate expenses by going to a public institution than to go to a private institution, no matter how prestigious, and incur a mountain of debt. And I know many of my college friends agree with me, because a lot of them turned down offers of admission for MIT, Caltech, and the like. After all, you can always go to those places for graduate school, and in computer science or engineering, they will usually fully subsidize the cost, regardless of financial need. Which begs the question: why not do that for undergraduate studies, too?

This is probably the article you were referring to.

It makes perhaps the most damning case against the proposed profiling: it won't catch more terrorists. The crux of the argument is that a terrorist cell can probe security multiple times with multiple people to determine who the system will flag. They then carry out their operation using the people not flagged by CAPPS.

The authors mathematically model this proposition, and conclude that security is best increased by focusing on "administrative measures" that apply to all passengers, such as better metal detectors and El Al-style passenger interviews.

Spammers don't care about people who receive email and don't respond, so they won't try and change their signatures to get past the system. Terrorists, OTOH, are smarter than that, and have different goals.

"What may be more alarming is that evidence from the September 11 investigation shows that Atta already knew the kernel idea behind this algorithm. Newsweek reported[21] that in the weeks before September 11, Atta and his conspirators practiced their attack by boarding the exact same target flights they intended to later hijack (same planes, same times, same origins and destinations). They wanted to ensure that they didn't raise any suspicions or red flags. This is a clear demonstration of Atta's cleverness. Like Atta, terrorists are smart. They already know this algorithm. And they are already using it."

This is part of a paper about defeating the system written by Samidh Chakrabarti and Aaron Strauss over at MIT. You really should read it.

Samidh Chakrabarti and Aaron Strauss developed the Carnival Booth Algorithm to defeat CAPPS I. They proved that any profiling system is less effective than searching passangers at random. In fact, the more consistent a profiling system works, the easier it is to defeat. If CAPPS II is an 'improvement' over CAPPS I, it will simply make the airlines an easier target for terrorists.

No kidding. Did you watch Junkyard Wars with the curly-haired MIT fairy? I had to be told twice and I had to check three times to be sure it was a guy. I still don't believe it. I don't care if he can etch his own CPU on a grain of sand, that's still the gayest guy I've ever seen.
He must be real happy to be surrounded by guys like that.
FAG

In exactly the same way that you claim a videogame is, by definition a "degenerate imitation" - so is a textbook.

I'm not claiming that there are any videogames that are textbooks. I am claiming that there should be, could be and one day, most probably one day soon, will be.

I find it hard to believe that no-one in this thread has referenced Henry Jenkins and his games to teach project.

If anyone is wondering, the link is http://web.mit.edu/ocw/ . It can also be found at www.mit.edu just press the OpenCourseWare link.

If anyone is wondering, the link is http://web.mit.edu/ocw/ . It can also be found at www.mit.edu just press the OpenCourseWare link.

One 26 inch home-brew subwoofer, coming right up!. They built it with the driver from an ancient hard drive. For those not up on Norse mythology, moljnir (several spellings seen) was the unstoppable hammer of the gods, carried by Thor himself. I'd say a building-shaking sub comes pretty close to that description. ;-)

Just take a gander at the king of all subwoofers they made out of an old hard drive motor at MIT!

Single Sign On (SSO) works within a limited realm under the same control, such as within the scope of a government agency, a corporation, or a school. These bodies already exist deal with issues of various policies including privacy policies within the scope of the "realm" (i.e. the laws of the nations a multinational corporation is functioning within).

Universial SSO, such as this plan and Passport, breaks that and cannot be consistant since different companies want different privacy policies, are governed by different government legistation, yet are suppose to "control" and use the same information (the online identity credientials).

So the goal of only needing one online identity, whether a username/password, or a PIN and smartcard, within a given controlled realm such as your university does make sense. This is possible through sensible use of existing services like directory services and secure network authentication. The use of directory services such as X.400, RADIUS, and more recently LDAP (and LDAP perversions like Active Directory) can help towards this. As well as secure network authentication like Kerberos.

Universial SSO does not make sense, because of the shift of power and control is not carefully thought out in the contexts of legal issues (privacy, evidence, children online protection), contractual issues, limited and total revocation, ownership, and other issues.

Universial identities for an unlimited number of purposes does not make sense, it is a nightmare of management logistics, a total lack of correctness, legal quandary, and telemarketing hell.

This is an improvement on an idea from the 1980s called "quantum subway tokens". There have also been a few schemes involving 2D speckle patterns as unique, hard to forge data items. But they're not challenge/response, like this. Challenge/response devices exist (Sun's Java-powered jewelry, the Dallas Semiconductor button) but they're more complex. On the other hand, their readers are simpler than this optical system will require.

The useful advancement in this thesis is in section 5.3.4, where the authors demonstrate that the registration of the scanning beam doesn't have to be extremely tight. You'd think this scheme would involve optical-bench precision, but it doesn't. (Well, actually it does, but not wavelength-precise optical bench precision. Still, it involves micrometers driven by computer-controlled stepping motors and a very rigid fixture. It's not a "just swipe the card" system.)

The trouble with this system is that there's no public key associated with the object - only a huge number of possible challenge/response pairs. Validation at an untrusted reader is done by probing the object using challenges previously performed at a trusted reader. Those challenges are "used up" as the object is validated, because otherwise, they could be replayed. This is much less convenient than a public/private key system. It's more like one of those systems where you have a wallet card with a long list of challenge/response pairs for logging in. The only advantage here is that the object isn't copyable. It's still stealable, of course.

It's kind of neat, but probably not commercially useful.

Your comment uses the poetic device of parallelism to equate video game production in Russia with video game production in Japan. The difference here is that the North American console gaming population is much more familiar with Japanese video game culture than with Russian video game culture (excluding one particular Russian game).

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 far 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 will 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 for 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.

Here is a very nice history of Logo which answers many of the criticism express in come of the comments.

Indeed, if you have read through the different Folio and Quarto texts you will find a great many variations of the spellings of common words. You'll also find a great many variations of lines and scenes. Quartos are named such because the scribes would write on paper that was then folded in quaters into a book form. Folios have a similar naming origin that I can't remember off the top of my head (something like a collection of loose paper sheets).

Quarto 1 of Hamlet is many many lines / pages shorter and more visceral than what we consider Hamlet today. The Hamlet that Mel Gibson and Kenneth Brannagh put on is actually a conflation of the Quarto 1 text and the Folio. What's interesting about this is that the Q1 Hamlet is much more direct. Many famous lines are different in Q1. For example:

To be, or not to be, I there's the point,
To Die, to sleepe, is that all? I all:
No, to sleepe, to dreame, I mary there it goes,
For in that dreame of death, when wee awake,
And borne before an euerlasting Iudge,
From whence no passenger euer retur'nd,
The vndiscouered country, at whose sight
The happy smile, and the accursed damn'd.
[...]

Recognize that one? Read more of it here: Quarto 1 of Hamlet.

You see it also scans as a regular iambic pentameter line. The usual first line we all think of:

To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer [...]

is 11 beats, or a feminine ending (the word "question" could be allided I guess to make it 10 beats), which is an interesting switch.
See the usual version of Hamlet.

In Q1, this soliloquy also comes in much earlier in the play (plotwise, things are rearranged). This makes the Q1 Hamlet much more decisive, and only shows him wavering in his resolve for a moment in comparison to the ponderous Folio Hamlet we all know and love.

Also we misspell some of the "old letters" used in these texts. For example "ye olde shoppe" would really be "the olde shoppe" because what we take as a letter "y" is really something called a "thorn" and represented the "th" combination.

What's interesting about these texts to which I refer is that they were almost unilaterally NOT written by Shakespeare. Some were written from the cue scripts he wrote (or had written), some were written from people who remembered seeing the shows, and some were altered by the actors like Burbage. Anaphoratic constructions in Hamlet are often attributed to Burbage (I think). He liked to repeat what he considered powerful lines, over and over and over (3x). These appear mostly in the Folio version.

Take some time one day and pull out a Variorum edition of your favorite play and start reading the footnotes. You'll see scholars bickering about what's "more correct" etc. It's pretty fascinating.

TTFN...

Since you're in the NY area you might want to check out the MIT Swapfest, it's about 3.5 hours from NY in Cambridge, MA. There is usally a good selection of junk, er...rare items from the computer and ham radio arena. Info is here

Starlogo is not just another Logo version. It's a tool for experimenting with descentralized models. See the homepage, for more information.

Taken from there:
StarLogo is a programmable modeling environment for exploring the workings of decentralized systems -- systems that are organized without an organizer, coordinated without a coordinator. With StarLogo, you can model (and gain insights into) many real-life phenomena, such as bird flocks, traffic jams, ant colonies, and market economies.

There's a book by Starlogo creator, Mitchel Resnick called Turtles, Termites, and Traffic Jams : Explorations in Massively Parallel Microworlds where he shows the use of Starlogo in education.

What I'd like to see, and I suspect I'm not alone here, is similar software that can sort email into any number of categories, not just spam and non-spam.

Any content-based classifier that works for spam/non-spam could also work for other categories, though the signals, and therefore the accuracy, might be different.

ifile is a general mail filtering system that works with a mail client to intelligently filter mail according to the way the user tends to organize mail. ifile uses the machine learning algorithm Naive Bayes to classify e-mail documents.

• http://dbn.media.mit.edu

• We need to start exploring the theory of QC, to find algorithms that don't get exponentially faster with QC.
• We also need to start remembering and improving the symmetric-key-based Key Distribution Center (KDC) models like Kerberos that don't depend on public-key crypto. We abandoned most of these, because public-key is much more convenient and doesn't have big obvious centralized security targets that can be attacked, but they still do an amazing number of jobs just fine.
• Today's problem is attacks on the Rijndael and Serpent AES winner/candidate symmetric-key algorithms, which has been proposed as a replacement for 3DES, the current highly-trusted-but-slow symmetric-key algorithm. We need to watch the crypto math folks apply their new techniques to the other AES candidates, so we can tell if any of them are still usable or if we have to get the NSA to run another contest. These aren't particularly affected by Quantum Cryptography.

...and here.

Hi! Would you like to attend MIT? It's just for people like yourself, you moron.

Mass Inane Turdlicking University

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.

Ocean Sequestration of CO2

Ronald Rivest, creator of MD5 and RC5, wrote an excellent paper on this topic. It is available here.

here is a link to a story about this and the man behind it.

and here is more detailed info.
and IBM's take on it can be found here

again, this is nothing new.

If we were trying to do our best to avoid global warming, what we'd do is harvest the undersea methane, crack it into hydrogen gas and carbon compounds (such as CO2, but graphite would be preferable), and bury the carbon in a form which prevents it from being released for a very long time. We could do whatever we wanted with the hydrogen without worrying about climate change.

It seems to me that open source would be the way to go, if only so any 'backdoors' or bugs can be found. 10 million stupid people or 5 million bored, smart people could really put our voting 'system' at risk.

This would also have the added benefit of removing the 'special interest' kickback that I'm sure the manufacturer/local politico is getting on some level.

Besides, what could be more patriotic (real patriotism, not bandwagon flags on your mailbox. ) than helping to create/debug a secure, fair, easy to use and accessible voting system? (Besides actually getting off your fat ass and voting. ;)

It seems to me that open source would be the way to go, if only so any 'backdoors' or bugs can be found. 10 million stupid people or 5 million bored, smart people could really put our voting 'system' at risk.

This would also have the added benefit of removing the 'special interest' kickback that I'm sure the manufacturer/local politico is getting on some level.

Besides, what could be more patriotic (real patriotism, not bandwagon flags on your mailbox. ) than helping to create/debug a secure, fair, easy to use and accessible voting system? (Besides actually getting off your fat ass and voting. ;)

After the last voting disaster a bunch of smart people looked at the situation and recommended simple optical scanning approach. That means Grandma uses a black marker or some such to fill in a bubble. Or circle the candidate, or write in etc. Computerizing things may help with registration, but for the actual vote simpler is better.

• new capabilities and applications
• principal limitations: A/d converters & processors
  
• SR disrupts the traditional value chain:
  - dedicated semiconductors vs general-purpose processors
  - Vendors vs OS designers and software programmers
• Cellular industry: Cost reduction > 30%, new business models, promotion of VMNOs & improved roaming
• Regulatory impact:
  - short term: certification
  - long term: standardication & spectrum management

Considering the person who originally hacked X-Box is a college (albeit graduate) at MIT, I don't see why you find this so surprising.

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.

I'm doing some work designing a solar car for a certain unnamed university.

I've eliminated MIT and U of A as this unnamed university.

Don't forget the old standby - the MIT LPF's rather huge paper from 1991 on the subject - it's still one of the better papers against patents around: Against Software Patents

The basic problem, I think, is that there is no shortage of ideas for computer software...there is mostly a shortage of good implementations of old ideas, and locking down the ideas so that only one entity has a monopoly on implementing them doesn't help matters.

Put another way, when most patent infringement cases seem to involve independent invention, the patent system is not doing its job.

This site at MIT gives a good overview. Even though it has a more american slant I think the arguments are pretty universal.