Slashdot Mirror

I think it's safe to say that nobody would confuse the Onion as having presidential support or endorsement.

Don't be so sure.

Unfortunately, the AP article disseminated around the world is short and loose on the facts of what happened in SF, thereby leading to a lot of undeserved blame for the outcome of the experiment on the MIT participants. Read about what really happened, in an account that the MythBusters agree is factual, in the test diary.

Things to note:

• The boat, selected and procured by the MythBusters, was one that had sunk and had been salvaged and could barely float. Consider: Would the Romans have built their war ships by refurbishing salvaged ships that had sunk in the sea and be satisfied with a ship that could barely float?
• Focusing the beam on the hemp sails was attempted, and failed. Consider: The light beam was able to char the side of the boat very quickly, but had no effect on the sail.
• While the beam of light significantly damaged the target, flaming arrows (tried on their earlier attempt and in this one, though it is not discussed in the diary) had no impact on the target. Consider: If you believe this test "proves" the technical infeasibility of a solar death ray for burning ships, then you must necessarily also believe that the MythBusters have proved the technical infeasibility of using flaming arrows, and therefore that is a myth.

The MIT team's goal, as stated in the original essay, was to test the technical feasibility of a solar ray for igniting wood at approximately 100ft with a simple, inexpensive setup. The conclusion from this test is that it was inconclusive because of the unknown effects of different experimental parameters (what if the target was a real Roman ship, or at least more seaworthy? what if the bronze mirrors had all been of uniform quality? etc). Sure, given much more resources and time, a much larger scale test could be done, but calculations had indicated that the array would be sufficient for achieving the same result as the initial MIT test, and the costs of doing the experiment were already beyond what was anticipated. However, assumptions about the target that would be used were not correct, and probably significantly affected the result of the experiment.

All-in-all, my understanding is that the MythBusters-MIT collaboration was a fun one although the results were not decisive enough to change anyone's opinion about the technical feasibility of the myth. Everyone is entitled to their own opinion. The experiment should be viewed as a fun educational exercise, NOT hard-core scientific research. The press that was achieved from the initial class exercise was unanticipated. That is, there was NO effort made to promote the class exercise. Instead, news of it spread by word-of-mouth, on blogs, and eventually into the mainstream media. People shouldn't take everything they read about in the news seriously, and should read what was posted about the attempts to get the facts about what the real purpose was behind the experiment (that is, to conduct a fun exercise for a class, NOT to claim that it had never been done before since links to past accounts had been provided to the students, and NOT to claim that the exercise was cutting-edge research).

Disclaimer: I am not speaking for the MIT team that conducted this experiment and was not a member of that team.

This explains why Microsoft would need to pay royalties. Even LAME is not exempt (at least in Germany & the USA) - the whole reason for its original name ("LAME Ain't an Mp3 Encoder") is to help avoid the patent issues around mp3 encoding.

Seriously, this really sounds like a load of bs to me. Perhaps auto-generated?

Seriously, this really sounds like a load of bs to me. Perhaps auto-generated?

(answering my own question)

Credits:

I found the link to http://opensource.mit.edu/ on this page:

Matthias Stürmer wrote a thesis available from his site,

"Open Source Community Building" (PDF format)

I'm sure his server can handle the attention, judging from the few replies I got to my post. : )

(answering my own question)

Credits:

I found the link to http://opensource.mit.edu/ on this page:

Matthias Stürmer wrote a thesis available from his site,

"Open Source Community Building" (PDF format)

I'm sure his server can handle the attention, judging from the few replies I got to my post. : )

...just start programing.

The answer to that depends on what you hope to learn. Programming is a big topic and there are a lot of ways to approach it.

Probably most Slashdotters will answer this question with something practical and job-oriented. "Get a copy of Kernighan and Ritchie, C is a language everybody should know." "Download Perl." "Download the Java SDK." "Use the VBA engine in Word to write macros." Etc. All worth doing if you're looking for a career as a programmer. But I sense that this guy is motivated more by intellectual curiousity than by career development. (As he should be — the developer job market is a tad oversupplied.) He's used computers most of his life, but has an unsatisified curiousity about how the suckers work.

One good way to satisfy that curiousity would be with the very basics: machine language and assembly language. These are not useful skills for most programmers, who only need to know the high-level abstractions of the systems they work with. (Some people would disagree with me on that.) But for satisfying your curiousity about just what computers do, it's a nice exercise.

Or instead of going very low level, you can go very high level, and learn some basic computer science while you're at it. That the route if you read the classic Structure and Interpretation of Computer Programs and work its Scheme programming exercises.

Then again, learning programming on your own is not for everybody. If somebody has managed to be around computers for a long time, but has never go around to learning programming, he probably is the sort of person who needs some initial handholding. Community colleges often have good classes.

Since the WSJ didn't link to it, here is MIT's web page for their filtration system: http://web.mit.edu/newsoffice/2001/nepalwater.html

http://web.mit.edu/2.009/www/lectures/10_Archimede sFAQ.html#FAQi

Nobody's freedom of speech is being abridged, it's just their anonymity in doing it.

And anonymity is part of free speech. As early as the early 1800s the USSC, US Supreme Court, has ruled that part of free speech is anonymity. A more recent case is from 2002 when Supremes OK Anonymous Free Speech. Here's EPIC's webpage on Anonymity. I found this page from MIT also on USSC upholding anonymity in political speech. And this is EFF's page. Fact is is that the "Federalist Papers" written under the pseudonym "Publius" was written by James Madison, Alexander Hamilton, and John James, all Founding Fathers of the USA. They knew how important anonymous political speech was. You enjoy your freedom because they fought for those rights. If you live in the USA that is, but I don't know this. Thomas Jefferson, who did write the DOI, Declaration of Independence, also write pseudonymously

Here's a search of Findlaw on court ruling on privacy anonymous "free speech" "supreme court". Fact is is there's a long history of anonymous political speech in the USA with some of the Founding Fathers exercising it.

Seriously, the whole nuke thing is a dead-end. A giant Yucca Mountain size dead end. If you are for nuclear power, also - look me straight in the pixel - and tell me you wouldn't mind a nuclear dump in your back yard. Yeah, that's what I thought.

Point number 2 - security - assuming, as has been blazed on our foreheads that we are so-so-so afraid of the terrorist, well what about nuclear security? Do you trust the same keystone cops who blundered through Katrina to secure our nuclear facilities? For an example, see how inherently insecure this site at the University of Wisconsin is. Also read this fascinating book about the controversy surrounding the construction of a nuclear test reactor at Vallecitos. This was in the '60s, before Americans worried about Osama. Now think about that book from the 9/11 perspective.

like buring ships?

Not only is this not new, it's not even new for MIT (1999). MIT is really stagnating, guys. Snap out of it!

Also for those of you that RTFA, did anyone stop to think that maybe Gerald Ilukwe, the general manager of Microsoft Nigeria would know more about needs in Africa than your run of the mill Slashdot user?

Just try to analyze the whole situation before you cast of Microsoft as the evil one here. Also for those of you really interested in computing in 3rd world countries, I do enjoy reading about this invention from MIT

I think cell phones are becoming too much like pet squirrels. Soon, they'll learn to breed like crazy during summer - they already know how to hibernate.

Still my question remains: what's the next big thing for web browsers?

Support for the Semantic web (a.k.a. Web 2.0, a.k.a. web APIs + RSS feeds + other kinds of high-level semantic markup). You can already have a taste for it in projects like Haystack and the Firefox Piggy Bank extension.

The main difference is that future web hypertext content will be less based on the "site" metaphor and more on services like del.icio.us and Flickr, so interface support for interacting with these new information structures is a must.

Still my question remains: what's the next big thing for web browsers?

Support for the Semantic web (a.k.a. Web 2.0, a.k.a. web APIs + RSS feeds + other kinds of high-level semantic markup). You can already have a taste for it in projects like Haystack and the Firefox Piggy Bank extension.

The main difference is that future web hypertext content will be less based on the "site" metaphor and more on services like del.icio.us and Flickr, so interface support for interacting with these new information structures is a must.

Clocky!

Ah yes, because the government is soooo good at defending against counterfeiters and unauthorized money.

Enjoy your freedom (when the U.S. Army starts quoting Trotsky, be afraid. Very afraid.)

This basically the same as a problem I was assigned in a recitation once:
http://ocw.mit.edu/NR/rdonlyres/Electrical-Enginee ring-and-Computer-Science/6-042JSpring-2005/E02DAA C7-A909-43C2-86E5-C9FBE52FCC02/0/rec3.pdf
(scroll to the end for the MIT-approved solution ;)

You are shifting the burden of proof and rather distorting the facts: You may only ever have seen exceptionally weak arguments, but that is not because only exceptionally weak arguments have ever been deployed - quite the converse is true*. The problem so far has instead been that no argument with even a semblance of strength for introducing software patents has ever been produced. And however weak you think any argument against the expansion of patentable subject matter is, it automatically wins unless you have a strong argument in favour of that expansion. But the expansion has occurred anyway of course, and in the face of strong arguments and strong opposition from industry and academia. That many companies, academics and individuals had to make such arguments at all illustrates the appalling state of recent policy making in this area (if you can call it policy making). Any credible economist will tell you that patent scope expansion without prior empirical and sound theoretical justification is verboten. Too bad - the damage is done and in the US it seems the fight's effectively over now, but the rest of what I want to say is appropriately Eurocentric anyway.

*
http://researchoninnovation.org/online.htm
http://www.si.umich.edu/~kahin/mip.html
http://swpat.ffii.org/archive/mirror/impact/index. en.html
http://philsalin.com/patents.html
http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt
http://www.spectrum.ieee.org/jul05/1557
http://www.dailytimes.com.pk/default.asp?page=stor y_16-8-2005_pg5_12
http://swpat.ffii.org/archive/quotes/index.en.html

"You have to be prepared to deal with issues like why expressing a particular piece of logic in C or Ada doesn't deserve patent protection, while expressing the same logic in Verilog or VHDL, which look identical to a non-programmer should deserve that protection."

That is definitely not an issue. One does not ask whether or not some invention deserves a patent, but whether or not it is patentable subject matter at all and your example is a poor one because if the claims of a patent are directed to the expressions of logic, then they are software patent claims.

"Likewise, why a device that fits the description in a patent claim should not be protected if the implementation happens to be (even in part) carried out with an embedded processor with embedded code, even though it's not at all apparent to the outside world that there's any software involved at all."

The distinction between hardware and software is not useful and is not at all relevant to the question of whether a patent claim is a software patent claim or not. One way to discover how the distinction between software patent and non-software patent is determined (and it is not always easy) is to read the way it is expressed by Judge Peter Prescott QC in his recent CFPH decision, in which he carefully and fully interprets the EPC Article 52 exclusions. Unfortunately, Prescott's interpretation seems to me to leave a lot of room for claiming things such as image enhancement techniques derived from purely mathematical considerations, but at least compression algorithms and data manipulation and data st

This sort of demonstration has been done before. I remember [...] charring in a simulated boat target.

Yes, people have had "proof-of-concept" success before by charring a target, but this time they got flames!

It's in Spanish, but it does have a photograph of about 40 of the 70 man-sized mirrors they used. He managed to ignite a tarred wooden boat in about 3 minutes.

I am now seeing "Forbidden" when trying to access the original MIT web page, however Google claims there is mention of the Sakkis experiment on this one (also forbidden).

Very cool. However, there's one little problem --- how the hell do you turn it? If the sensor's got to be 50'000km away from the lens, then to turn it 90 degrees (why does Slashdot block Unicode?) you're going to have to move the sensor some 70'000km, which means a lot of hydrazine.

Imagine a sunshade that's in Earth's orbit (not in orbit around Earth, but in the same orbit) with the sensor craft coorbital but trailing. In the course of a year, your field of view will traverse 360 degrees without ever once manuvering either craft.

In practice, they plan to have the two craft in seperate orbits around L2 - as described in this PDF, but the basic principle is as described above.

http://web.mit.edu/invent/iow/cocke.html

I think he's referring to Rodney Brooks. Along with much of the robotics community, Tilden was heavily influenced by Brooks in the late 80s (see this article). Brooks preached an approach of building and evolving robot designs, starting with simple "insects" first. Tilden has taken the simple-only approach a bit further than anyone else though, and remains pretty controversial in his ideas.

1) What if we modified Automatic CS Paper Generator to create patent forms with the latest buzzwords.
2) Use as many modern buzzwords as possible
3) SUE, SUE, SUE
4) Profit.

You're trying to do the impossible. For at least 30 years, people have adovcated the "paperless office." It has reached a mythic status. It's just that: a myth. People always want to print. Hard copies allow annotations. Forms do not. Paper can be changed on the fly. Forms can not. Paper is portable. Forms are not. Even with laptops, you're still tied to the laptop. Paper can be folded up, and carried in pockets. Paper is collaborative. Computers aren't. Only one person can use a terminal. There's no rapid interaction among the group. That's why meetings and phone calls are still used even though email is practically ubiquitous.

Anyone that advocates rigid computer forms over flexible paper, doesn't understand how paper is used in society. I could go on and on, but there's no need. An entire book has already been written about this.

And before you anyone cries "luddite," the book was written by a cognitive psycologist at Hewlett-Packard, and a senior Microsoft researcher in interactive systems. Hardly luddites, and arguably an ironic position for them to take given their employment.

MIT perhaps?

More info on the lecture

MIT (77 Massachusetts Ave.)
Room 10-250
1:00 PM


http://web.mit.edu/bookstore/www/events/#ig

Learn Scheme or learn computing using Scheme. Or learn to appreciate art and still get something done.

Nirvana.

Bad form to reply to myself, but a little more reaserach also give this

How to Design Programs is an entry level programming book, meant to teach high schoolers and people with NO programming experience. Any CS graduate should be intimately familiar with its teachings, and that of the more grown-up SICP.

One would like to think so. However, given the "quality" of a number of posts here on slashdot, it seems not to be the case. It seems that too many folk out there never grasped concepts as basic as recursion, much less HOF, and could do with a refresher from something like HTDP.

As for SICP, it's a wonderful book, but a terrible read. I'm guessing a lot of people out there would fare better with the Abelson & Sussman lecture videos.

I'm sure that you could create a display server optimised for applications running locally on a desktop machine with a single monitor {most people's configuration} and it probably would be less resource-intensive. But would it really be worth it? Who is the intended market?

we will get the fat out of the systems. Today's laptops have become obese. Two-thirds of their software is used to manage the other third, which mostly does the same functions nine different ways.

CLiki [cliki.net], a programming language blog. Contains lots of stuff on programming languages and paradigms, including debates on merits and disadvantages.

That's not true. CLiki is just the Common Lisp wiki; meaning everything Common Lisp, specially those that satisfy the Debian license. From the site:

"Links to and resources for free software implemented in Common Lisp and available on Unix-like systems. Listed software should satisfy the Debian Free Software Guidelines (DFSG)."

ll-discuss, a mailing list related to programming language concepts. Perhaps most interesting if you're into language implementation, but it's the closest thing to a magazine that I can recommend.

Not really. ll-discuss is for small light-weight languages (think scripting languages, or tiny dynamic languages) The "ll" stands for Light-weight Languages actually, and it grew from the conference by the same name.

People who are into language design frequent LtU. Or more likely they're busy reading their huge required reading list :-)

Bugtraq is for security specialists, or people who code in C/C++ ;-)

Practical Common Lisp is a book, not a magazine.

How to Design Programs is an entry level programming book, meant to teach high schoolers and people with NO programming experience. Any CS graduate should be intimately familiar with its teachings, and that of the more grown-up SICP.

Hindsight.

At the time, the obviousness of being able to target an industry-standard, pervasive platform, just wasn't obvious. There simply wasn't such a platform with many megabytes of memory, many gigabytes of disk, processors which could handle hundreds of millions of operations a second, and so forth.

There were interpreted Lisps on a variety of platforms that were in common use. There were a handful of compiled Lisps. Most notably, MacLisp in ITS (and later on other OSes on PDP-10s), which was so popular at MIT's AI lab that enough was developed in it that performance became a key issue.

At the time it made sense to investigate hand-building a machine that would be an optimal target for a compiled Lisp, especially in that it would make known optimization techniques easier, and would welcome rather than tolerate large garbage-collected heaps.

Nowadays, Scheme textbooks like the excellent SICP: Structure and Interpretation of Computer Programs (or, say, The Schematics of Computation) introduce compiler-writing and target an implementation of a virtual machine. These VMs are directly analogous to the actual CADR hardware. On modern fast computers, they run faster than the actual processor hardware in the physical CADR. Running a VM with performances down in the 1/double-digit or 1/triple-digit of physical processors would have been intolerable back then.

There were always people working on targetting mass-produced general-purpose hardware, it's just that there was a lot of learning to be done about how to optimize things.

Lots of that work was done in the context of the amazing T project. The T compiler was a massive watershed development for Lisp compilation, as it implemented or introduced such things as efficient lexical scoping; simplifying the code through transformation until you were left with operations on only as many variables as you have registers; lambda-lifting; CPS-transformation; dramatically improved copying garbage collection; "pseudo-hardware typing". A number of other innovations directly stem from these.

One look at this is Olin Shivers writing about his memories of the T project.

Nowadays, with these techniques, and others learned since, compiling Lisp to practically any modern processor is straightforward. Modern Lisp and Scheme compilers generate either efficient and fast native code, or portable C (to the extent that it should work on any 32 or 64 bit platform gcc supports).

There remain some implementations that target a tight purpose-written VM, like CLISP or Scheme48 does. There are some implementation that target other VMs, particularly the Java one, compiling into JVM bytecodes or Java as an intermediate language.

The cheapness and reasonable speed of VMs, the efficiencies of compilers targeting C, assembly, or native machine code, and the tightness of runtime environments supporting type-handling and garbage collection, are such that practically nobody would seriously think about building hardware dedicated to supporting Lisp like languages.

With the benefit of hindsight, you are completely right.

The two points you raise, prior to T, would have been thought of as somewhere between funny and insane.

T was ca. 1982.

The CADR Lisp Machine was started ca. 1975 and documented in AI memo 528 in 1979.

Lisplike-compiled-language-favourable hardware chugged along until the early 1990s, when they collectively could no longer compete with the performance (never mind the price) of implementations compiling for x86, SPARC, Alpha, and a few other popular workstation instruction sets.

While not magazines, I've found these resources to be useful in becoming a better programmer:

CLiki, a programming language blog. Contains lots of stuff on programming languages and paradigms, including debates on merits and disadvantages.

ll-discuss, a mailing list related to programming language concepts. Perhaps most interesting if you're into language implementation, but it's the closest thing to a magazine that I can recommend.

Bugtraq, a (the?) security list. This will teach you what things to avoid; at least, the 3 most common errors.

Practical Common Lisp, a book that basically provides a crash course on Common Lisp. It shows you how things are done in Common Lisp, why they are done that way, and occasionally draws comparisons with other languages, everything including practical examples. It is said that, even if you don't program in Lisp, knowing it makes you a better programmer.

How to Design Programs, a fairly extensive book on program design. I haven't read the whole book, but it seems to both solidly and concisely cover many fundamentals. It uses Scheme for explaining things, but the material applies to other languages just as well.

There have been many research machines, but no successful commercial products. Data flow techniques seem have had their greatest impact in two areas: compiler optimization and instruction scheduling inside the CPU. Many optimizations use SSA, or static single assignment. SSA means that any variable is only assigned a value once. Converting to SSA means that the code can be represented as a Directed Acyclic Graph (DAG), and this is useful for code generation. Dataflow is also implemented in hardware to enable parallelism and features like speculative execution in the pipeline.

Experience has shown that there is only so much parallelism that can usefully be exploited using either compiler or hardware based dataflow based techniques. This is not a good sign for this project, unless they are targeting primarily very parallel applications, for example DSP algorithms or image processing. Even so, other research groups have tried this and failed (or at least not succeeded). One is the RAW architecture at MIT: http://cag-www.lcs.mit.edu/raw/ Another example is iWarp, a CMU/Intel systolic processor. RAW is currently active, iWarp is over.

You need to use SCIgen to generate a research paper with graphs, equations and everything, then try submitting it to a conference. Who knows you may get to give a lecture on your new theory.

I can see AMD's reasoning though - they have to push this to market and make whatever they can off it as quickly as possible - MIT is fast on the road to their $100 laptops that include a screen and a hand-crank for cryin' out loud.

Heck, for an even smaller size, one could spend another $100 or so and get an Apple Mac Mini, and a.) have better componants, and b.) not have to suffer the Windows. If you're not going to game, at least buy a nice Unix-based OS for stability.

I appluad AMD for the effort, but it's about 2 years too late. The niche in the market has major contenders in with better products, and some that will arrive soon that are even better than what's available, while AMD is just dragging in a low-end box.

Maybe that's true but largely irrelevant. Once a product (OS/library/API) is released and people are using it, whatever it does is a feature. Read The UNIX-HATERS Handbook; the number of users required to fix a featurebug in stone is 5.

As a user, and absent the ability to change the OS/library, you can either piss and whine about it, or you can figure it out and work around it. Having a spec to hand actively hinders doing the latter, as you waste time trying to figure out why it's behaving incorrectly.

I can generally agree with Linus that English-language specifications are hardly ever good enough to build software around. I can think of at least one notable example that is both large, useful, and accurate: The Definition of Standard ML defines the programming language SML in a way that is very accurate and thorough, to the point that the specification is almost machine-executable. (Indeed, a project is currently underway at CMU to formalize an alternate version of the definition in Twelf, and mechanically prove it correct, which would really make it machine executable.) Because of this spec, SML has several compilers that are impressively compatible, and where they differ, it's almost always clear who's right and who's wrong. (To be fair, there are some known mistakes and ambiguities in the published version, which is one of the reasons for the machine-verifiable version in development.)

The real problem is that specs are hard, I mean, way harder than writing software that more-or-less works, like linux does. If you believe "worse is better", then maybe specs aren't necessary. If you believe that it's worth the time to make sure you're really doing something right, it is possible to write specs that are accurate and useful, and that can be helpful to collect your thoughts outside the warzone of source code, and reason abstractly about the program that you intend to write.

This is a very cool idea. There is a gig going on in little Logan, UT this week about Advancing the Effectiveness and Sustainability of Open Education Conference. (The pod-casts will be available soon.) And one of the keynote speakers (Joris Komen from Namibia) mentioned this.

Just imagine how we may learn in the future with the current OpenCourseWare movement at MIT and other colleges and universities around the world. This conference has outlined several possible ways, but more are needed. I won't entertain with the details of the conference, but if you are interested check it out and think about what you might do to make this soon-to-be-available technology actually work.

http://www.mit.edu/~kbarr/ipod.html

They claim at http://laptop.media.mit.edu/ "First, by dramatically lowering the cost of the display. The first-generation machine may use a novel, dual-mode LCD display commonly found in inexpensive DVD players, but that can also be used in black and white, in bright sunlight, and at four times the normal resolution--all at a cost of approximately $35."

Generally these inexpensive displays are often 480 x 234 pixels...there is a reason why they are so cheap. Text will look pretty sad on these!

I think the same as you, but I stopped posting on slashdot about how a piece of software should be the default one. It would be ideal.
When a software is developed since a long time, and the involved guys continue to make it evolve because its base design is not bad, they are not going to let the code down to go on something else. I would not say thats a holy war, just that if you get very involved in a project, it is tough to scrap it, and even more when you did it mostly in your spare time just because you loved to work on it.

At the moment I rather try to encourage people to use and promote free and open standards. Who care if you use one or another application, if you can very easily make them understand the same format? The standard is a big part of the software itself and efforts must be made to improve the free desktop one.

When I switched my desktop to linux, I dreamed that KDE and Gnome efforts would merge. For the very reason I wrote above, I see it will not happen. Now I think it is really important to make every software designed for these both desktop environment being fully compatible with a common platform of standards.

In a perfect free desktop world, one codebase would exists for all your needs. Everything the user could see and touch would be scripted/scriptable. Free softwares allows ideas to be shared and modified, I agree then that no one needs to develop more than a unique app for a precise goal. If the app UI is not what you needed, edit it. People say that choice is good? Don't waste your time coding a new app from scratch! All the possible choices should be built-in the app, letting the user modify the default script. Just make it as modular as possible, and GPL it.

What have the most successful and well known softwares that emerged from the F/OSS community in common? They are all deeply modularized. To give some examples: Linux(the kernel), GCC, apache, mozilla firefox.
(Here is a informative paper I found when googling to verify I did not just wrote absurd things)
http://opensource.mit.edu/papers/narduzzorossi.pdf

At the moment I see KDE being the nearest from those ideas. But I don't see much of inter-desktop compatibility efforts.

Sorry for the bad english and some half-explained ideas

Pierre

That's really a shame, because that was just about everything I was looking for in a "travel laptop". Plus, it's so cheap that if it gets damage/destroyed, I don't feel so bad.

On the other hand, it has what appears to be a membrane keyboard. That's a dealbreaker right there.

I wonder if the "mesh networking" advertised in there is roofnet over 802.11b?

According to this story at Macworld and the official MIT site, they will have 1 gig of RAM. Which should be more than enough for a stripped-down version of Linux.

Please note: these laptops are not in production. They are not--and will not--be available for purchase by individuals.