If you don't know if you have a quantum computer, then obviously a quantum computer isn't that important. I mean if your problem isn't solved remarkably easier with a given tool, YOU DON'T NEED THAT TOOL! If it IS solved remarkably easier with that tool, then YOU DEFINITELY KNOW IF WHAT YOU'RE HOLDING IS THE CORRECT TOOL!
There are different kinds of "easy" though. Factoring integers is 'easier' on a quantum computer since we can use Shor's algorithm, but it's 'harder' because we need large, expensive, supercooled apparatus, and it's 'harder' because we can't entangle more than a handful of qubits. If I calculate that the integer I want to factor will take, let's say, 100 years on classical computers, it might be worth my time to invest 20 years developing a quantum computer to perform the same work in a much shorter time.
Also, there is one really interesting use for quantum computers which your logic doesn't cover: quantum computers would allow us to perform quantum experiments to very high precision, just by running the computer on an algorithm with a known result (eg. pi).
Obviously, you don't have a use for a quantum computer if you can't find a way to determine if it's a quantum computer. If it's just speed, what you want is a super-computer. If it's the ability to perform certain calculations, they simply don't work on a classical computer (or take eternity, even for a super-computer).
Not quite, since one of the best 'definitely quantum' results we have so far is that 15 = 3 * 5, which is trivially found on a classical machine.
I would say instead, that if getting a correct result doesn't determine whether it's quantum or not, then it's not quantum in any 'meaningful' way (in the sense that the transistors in my laptop's CPU aren't quantum in a 'meaningful' way).
Why buy something that isn't demonstratively faster than the old stuff...
I mean if the difference is so small that there is some sort of debate about if it is effectively working or not, then it seems to me at that point cost should be the deciding factor. I doubt these D Wave machines are any cheaper than the old stuff.
Part of the problem has been D-Wave's confusing abuse of terminology:
1) They claim their device is a computer, but it's not according to the usual definition (a Turing machine with bounded tape (RAM)). It's more similar to an ASIC (application-specific integrated circuit). 2) They claim their device is a quantum computer, but it's not according to the usual definition (a device which requires quantum phenomena to operate). There is some evidence it uses quantum effects, but they don't appear fundamental to its operation (otherwise we wouldn't be having this quantum-or-not merry-go-round). 3) They claim their device solves its (application-specific) problem 35,000x faster than a classical machine, but in fact they had programmed the classical machine with a much harder problem (finding an exact solution, rather than an approximate one). When a classical computer was programmed to solve the same problem as D-Wave's machine, the classical machine was faster. 4) They consistently conflate quantum algorithms (algorithms inspired by quantum mechanics) with quantum computing (which requires quantum mechanics to operate). Their machine implements a 'quantum simulated annealing' algorithm, but this doesn't require a quantum computer to run. Likewise, a regular 'simulated annealing' algorithm doesn't require a heat engine to run. Likewise a 'genetic algorithm' doesn't require a DNA-based computer to run. 5) They keep moving the goalposts to remain as impressive-but-vague as possible. Rather than showing definitive results to back up their claims, they keep making claims then weakening them afterwards when researchers show them to be false. This is like an inverse No-True-Scotsman; academics have a clear definition of what a quantum computer is, and D-Wave keep trying to expand that definition it to include their machines.
In short, Google and NASA bought their machines when there were claims bouncing around about 35,000x speedups, but these were subsequently found to be flawed.
I'm all for investing in basic research, but it often looks like D-Wave's research output is coming from their marketing department rather than their scientists and engineers:(
This judge just assured himself and his lawyer friends of income for the rest of their lives...
Since the summary specifically says 'Federal Judge Stephanie Rose', are you assuming the first payments will be going towards gender-reassignment surgery?
Where are the general-purpose natural language command languages and parsers?
They're sat in the middle of whatever voice-command pipeline you're imagining, between the speech-recognition layer and the voice synthesiser. The advantage of the CLI is that you don't need to recognise speech or synthesise a voice.
The kind of voice control Google is after (as in "the second-most intuitive interface") is hardly the same as the kind of voice control that is available today. The first would be able to interpret your intent as well as a human could, possibly better (filtering out noise, asking to clarify ambiguities rather than making assumptions). And it's nothing like the command line, which does no interpreting, refining or clarification at all; it just executes a limited set of commands exactly as entered, with no room for so much as a misplaced comma.
It's exactly like a commandline, which have been attempting to interpret their input for decades (most famously with http://en.wikipedia.org/wiki/D... ).
The two reasons modern commandlines don't do this are 1) lack of effort and 2) that it's often a very bad thing. According to http://www.nhplace.com/kent/Pa... one of the motivating factors for defining Common LISP was to stop DARPA from rolling out INTERLISP, and therefore DWIM, across all their projects.
As for clarification, I run into this all the time when typing non-existant commands (thanks to the "command not found" program) or using undefined variables (thanks to GHC).
Shane Legg's research is pretty cool, since it deals with very sci-fi-like problems in a pretty rigorous way. For example, his PhD dissertation "Machine Superintelligence" approaches intelligence in a non-anthropocentric way, from the perspective of computability http://www.vetta.org/documents...
More recently he's tried to define an IQ-like metric for comparing different AI projects and measure progress in the field http://www.vetta.org/2011/11/a...
Since Google still seems to believe Glass has potential to be the "next big thing" and it's entirely voice controlled, it makes sense that they'd want a voice assistant that can respond more intelligently than "I don't have a clue what you're talking about, should I search the web?" Maybe this company's AI would be adaptable to something along those lines?
Personally, I'm not a big fan of talking to machines. Yeah, it looks awesome in sci-fi, but in real life it just makes you look like a hipster douchebag when you're out in public talking to the little robotic voice inside your mobile device.
I still find it amusing that command lines are seen as the least intuitive interface and voice control is seen as the second-most intuitive (after mind-controlled), even though voice control is just a command line over a noisy, ambiguous channel, where you can't even see the commands you're inputting.
Some developers prefer to favor the freedom of the people who get code from them, over the freedoms of people who might (or might not) get the code from someone else, second hand. That’s BSD licensing. I give you my code, you do what you want with it, including telling other people they can’t do the same.
Other developers prefer to make commercial exploitation of their work difficult. They say you can use their code, but you have to give both the original code and your changes to everyone else. That’s GPL.
I think of it more as a division between developers and end users: liberal licenses say that developers are free to screw over their end users, copyleft licenses say that end users are free from being screwed over by the developers. Since there are far more end users than developers, and each developer is also an end user, I prefer copyleft. I tend to go with the Affero GPL for my personal stuff (like GPL but access over a network counts as distribution), but I've also had a full-time job writing CPAL code (like MPL but access over a network counts as distribution).
why the hell should the open source community praise Valve for bringing proprietrary software to its most famous platform?
Because if anything is going to bring users to Linux it'll be games. Games are what tie me to Windows, and I'd be more interested in testing Wine on my existing library if I can get my newest games out of the (proverbial) box on Linux.
So this offer might get some Debian developers to switch to Linux?
SteamOS is a good thing, since it will reduce the amount of proprietary software used by many gamers. Eventually, Debian may reach the stage where SteamOS and Steam become obsolete, in which case those gamers can switch to regular Debian. However, DDs are *already* on regular Debian, so this would be a step backwards, for short-term gratification.
I don't want to deny DDs this gift, but they should be aware those bearing it may be Greeks.
The first thing that came to mind when I saw 'gratis licenses for Free Software devs' was BitKeeper, and we saw how well that turned out. Thankfully Valve make games, so if this ends up exploding then nothing important will be lost.
You are aware that the "carrots help you see in the dark" thing was a lie the Brits told to try to cover the fact that they had radar? As far as I'm aware there's zero evidence whatsoever that carrots or any nutrient in them does a damned thing for your eyes.
Carrots don't help you see in the dark, but they can prevent you going blind
Why does every network management tool include their own ugly, broken little programming language for configuring it?
Why not just use an existing language?
The better solution is to fix the DSL, rather than introducing a general-purpose language.
Domain Specific Languages are really good at making code simpler, more concise and less redundant, but their most important feature is reducing bugs. A DSL can use primitives which have the possible error-modes built in; a general-purpose language would have to build that in a separate library layer, but the problems with that are 1) the general-purpose stuff is still available, which won't catch your errors 2) a decent abstraction layer *is* a DSL. In OO land, an object's interface is a DSL for controlling that object and a class library is a simulation of the components of some problem domain. In functional land it's usually even more explicit, with datatypes to represent programs, combinators for building them up and functions for interpreting them.
I do not consider " teaching "all sides" of "competing theories" to be rhetoric. If "science" cannot withstand alternative theories to be taught alongside their theories then it is not science. Those advocating creationism have just as many valid points as the rabid theorists believing as they do.
Science *has* withstood alternative theories being taught alongside. In fact, those "alternative theories" were the *only* thing being taught for a few thousand years. Our current understanding is thanks to brilliant people who 'taught the controversy' of modern science over the past few hundred years and have almost won.
Religious creation myths are not the underdog; they dominated the world when there was no alternative; as soon as one appeared, they crumbled. Nonsense like creationism is just a last-ditch attempt by particular church leaders to cling on to their power. They know they're on the way out, so don't mind alienating the majority in order to radicalise a few.
So instead of dropping the privilege to write files at all, which would not be feasible in many applications, you would have a file descriptor to a directory that allows writing files under that directory.
That's an interesting choice of example, since I've often seen the *opposite* used to demonstrate capability systems; specifically that we can keep a filesystem capability in our shell and do everything else with stdio and pipes. For example, rather than giving a filesystem capability to "cp", we can get rid of "cp" altogether and use "cat file2". Since "cat" is only operating on stdio, we don't need to give it any filesystem capability.
don't most people these days favor streaming options? Why would I fret with starting a download at 8am (programming it into a DVR-like device, making sure it gets saved somewhere proper, etc.) when I can just hit play at 8pm anyway?
People don't prefer streaming, they prefer downloading. Ask anyone if they get annoyed by "buffering" messages, especially when they're skipping *backwards*. Streaming is only a thing since broadband speeds have made it feasible and there are big bucks to be had in the preventing-people-from-having-what-they-want business, also known as media distribution. "Streaming" is just a buzzword which means 'you will download it on to your disk in your machine using your bandwidth, but we will delete it lolololol'.
Your straw man doesn't even make any sense:
* Why would you need to start a download 12 hours before watching it if you have enough bandwidth to stream it? When you "just hit play at 8pm" do you then immediately hit pause and leave it to buffer for 12 hours (assuming that the service lets you buffer more than 10 minutes)? I assume your Internet connection doesn't gain magical turbo powers when you delete stuff, so stop fretting and open the URL in VLC at 8pm.
* What are netflix.com, youtube.com, etc. if not "DVR-like devices"? At least if you download it, you can use whatever the hell "DVR-like device" you want; plus you won't have to wait until those services give enough of a crap about the particular device you want to use that they implement a fresh port of their DVR-like service to it (protip: they won't; instead, you'll have to buy the brand new whizz-bang device they do give a crap about thanks to an exclusivity contract, which will be a different device from every other service you like).
* Why do you care that downloads 'get saved somewhere proper'? You obviously don't care about that for your streams, since they don't get saved! Just dump everything into/tmp already.
It's like like they're only targeting free operating systems, as Mac somehow made the list.
More likely: the author happens to develop on Linux, Mac and/or Android and once it compiled there, the others came for free. Since adding Windows support usually requires a bunch of workarounds and rewrites, we'll have to wait until the effort's been put in.
What makes this interesting is the inversion of control. For years, net neutrality has basically hinged on the fact that users are paying their ISP for bandwidth, so it's up to the user what they do with it. This idea completely inverts that, so the user has absolutely no control anymore.
We were worried that walled gardens like Facebook were turning the Web into a consumer service, well this will do the same for the Internet itself.
I've been using Emacs for a couple of years now and think it's pretty good. The most important bug IMHO is its lack of concurrency. Connecting to remote machines with TRAMP is great, but having the whole app become unresponsive for a period is jarring. Also, I have to run GNUs from a separate process so I can actually do some work while it refreshes.
Giving ELisp lexical scope is a good start in this direction, since it allows for fully encapsulated closures which won't trample over each others' namespaces. Once that becomes pervasive, it wouldn't be too (conceptually) difficult to add a concurrent event handler to fire off asynchronous functions like node.js.
"Are these outdated specs worth your privacy and freedom?"
Hell yes! I paid £200 (the price in TFS) for my current laptop, an OLPC XO-1. It has a 433MHz processor, 256MB RAM and 1GB storage, so the system described in the summary would be a great upgrade (although I assume its screen isn't from Pixel Qi:( ). The reason I've stuck with my XO-1 for the past 4 years is that I've been ratchetting myself away from proprietary systems:
Slashdot Mirror
If you don't know if you have a quantum computer, then obviously a quantum computer isn't that important. I mean if your problem isn't solved remarkably easier with a given tool, YOU DON'T NEED THAT TOOL! If it IS solved remarkably easier with that tool, then YOU DEFINITELY KNOW IF WHAT YOU'RE HOLDING IS THE CORRECT TOOL!
There are different kinds of "easy" though. Factoring integers is 'easier' on a quantum computer since we can use Shor's algorithm, but it's 'harder' because we need large, expensive, supercooled apparatus, and it's 'harder' because we can't entangle more than a handful of qubits. If I calculate that the integer I want to factor will take, let's say, 100 years on classical computers, it might be worth my time to invest 20 years developing a quantum computer to perform the same work in a much shorter time.
Also, there is one really interesting use for quantum computers which your logic doesn't cover: quantum computers would allow us to perform quantum experiments to very high precision, just by running the computer on an algorithm with a known result (eg. pi).
Obviously, you don't have a use for a quantum computer if you can't find a way to determine if it's a quantum computer. If it's just speed, what you want is a super-computer. If it's the ability to perform certain calculations, they simply don't work on a classical computer (or take eternity, even for a super-computer).
Not quite, since one of the best 'definitely quantum' results we have so far is that 15 = 3 * 5, which is trivially found on a classical machine.
I would say instead, that if getting a correct result doesn't determine whether it's quantum or not, then it's not quantum in any 'meaningful' way (in the sense that the transistors in my laptop's CPU aren't quantum in a 'meaningful' way).
Why buy something that isn't demonstratively faster than the old stuff...
I mean if the difference is so small that there is some sort of debate about if it is effectively working or not, then it seems to me at that point cost should be the deciding factor. I doubt these D Wave machines are any cheaper than the old stuff.
Part of the problem has been D-Wave's confusing abuse of terminology:
1) They claim their device is a computer, but it's not according to the usual definition (a Turing machine with bounded tape (RAM)). It's more similar to an ASIC (application-specific integrated circuit).
2) They claim their device is a quantum computer, but it's not according to the usual definition (a device which requires quantum phenomena to operate). There is some evidence it uses quantum effects, but they don't appear fundamental to its operation (otherwise we wouldn't be having this quantum-or-not merry-go-round).
3) They claim their device solves its (application-specific) problem 35,000x faster than a classical machine, but in fact they had programmed the classical machine with a much harder problem (finding an exact solution, rather than an approximate one). When a classical computer was programmed to solve the same problem as D-Wave's machine, the classical machine was faster.
4) They consistently conflate quantum algorithms (algorithms inspired by quantum mechanics) with quantum computing (which requires quantum mechanics to operate). Their machine implements a 'quantum simulated annealing' algorithm, but this doesn't require a quantum computer to run. Likewise, a regular 'simulated annealing' algorithm doesn't require a heat engine to run. Likewise a 'genetic algorithm' doesn't require a DNA-based computer to run.
5) They keep moving the goalposts to remain as impressive-but-vague as possible. Rather than showing definitive results to back up their claims, they keep making claims then weakening them afterwards when researchers show them to be false. This is like an inverse No-True-Scotsman; academics have a clear definition of what a quantum computer is, and D-Wave keep trying to expand that definition it to include their machines.
In short, Google and NASA bought their machines when there were claims bouncing around about 35,000x speedups, but these were subsequently found to be flawed.
I'm all for investing in basic research, but it often looks like D-Wave's research output is coming from their marketing department rather than their scientists and engineers :(
1) Why distinguish client from server?
2) Server technology is advancing.
3) Client technology isn't that fragmented.
This judge just assured himself and his lawyer friends of income for the rest of their lives...
Since the summary specifically says 'Federal Judge Stephanie Rose', are you assuming the first payments will be going towards gender-reassignment surgery?
Wait...I thought that the ban on stem-cell-farming from unborn babies was going to stunt US stem-cell research forever?
TFA confirms that hypothesis: both of the techniques mentioned were discovered in Japan ;)
Where are the general-purpose natural language command languages and parsers?
They're sat in the middle of whatever voice-command pipeline you're imagining, between the speech-recognition layer and the voice synthesiser. The advantage of the CLI is that you don't need to recognise speech or synthesise a voice.
The kind of voice control Google is after (as in "the second-most intuitive interface") is hardly the same as the kind of voice control that is available today. The first would be able to interpret your intent as well as a human could, possibly better (filtering out noise, asking to clarify ambiguities rather than making assumptions). And it's nothing like the command line, which does no interpreting, refining or clarification at all; it just executes a limited set of commands exactly as entered, with no room for so much as a misplaced comma.
It's exactly like a commandline, which have been attempting to interpret their input for decades (most famously with http://en.wikipedia.org/wiki/D... ).
The two reasons modern commandlines don't do this are 1) lack of effort and 2) that it's often a very bad thing. According to http://www.nhplace.com/kent/Pa... one of the motivating factors for defining Common LISP was to stop DARPA from rolling out INTERLISP, and therefore DWIM, across all their projects.
As for clarification, I run into this all the time when typing non-existant commands (thanks to the "command not found" program) or using undefined variables (thanks to GHC).
Shane Legg's research is pretty cool, since it deals with very sci-fi-like problems in a pretty rigorous way. For example, his PhD dissertation "Machine Superintelligence" approaches intelligence in a non-anthropocentric way, from the perspective of computability http://www.vetta.org/documents...
More recently he's tried to define an IQ-like metric for comparing different AI projects and measure progress in the field http://www.vetta.org/2011/11/a...
Since Google still seems to believe Glass has potential to be the "next big thing" and it's entirely voice controlled, it makes sense that they'd want a voice assistant that can respond more intelligently than "I don't have a clue what you're talking about, should I search the web?" Maybe this company's AI would be adaptable to something along those lines?
Personally, I'm not a big fan of talking to machines. Yeah, it looks awesome in sci-fi, but in real life it just makes you look like a hipster douchebag when you're out in public talking to the little robotic voice inside your mobile device.
I still find it amusing that command lines are seen as the least intuitive interface and voice control is seen as the second-most intuitive (after mind-controlled), even though voice control is just a command line over a noisy, ambiguous channel, where you can't even see the commands you're inputting.
Some developers prefer to favor the freedom of the people who get code from them, over the freedoms of people who might (or might not) get the code from someone else, second hand. That’s BSD licensing. I give you my code, you do what you want with it, including telling other people they can’t do the same.
Other developers prefer to make commercial exploitation of their work difficult. They say you can use their code, but you have to give both the original code and your changes to everyone else. That’s GPL.
I think of it more as a division between developers and end users: liberal licenses say that developers are free to screw over their end users, copyleft licenses say that end users are free from being screwed over by the developers. Since there are far more end users than developers, and each developer is also an end user, I prefer copyleft. I tend to go with the Affero GPL for my personal stuff (like GPL but access over a network counts as distribution), but I've also had a full-time job writing CPAL code (like MPL but access over a network counts as distribution).
Because if anything is going to bring users to Linux it'll be games. Games are what tie me to Windows, and I'd be more interested in testing Wine on my existing library if I can get my newest games out of the (proverbial) box on Linux.
So this offer might get some Debian developers to switch to Linux?
SteamOS is a good thing, since it will reduce the amount of proprietary software used by many gamers. Eventually, Debian may reach the stage where SteamOS and Steam become obsolete, in which case those gamers can switch to regular Debian. However, DDs are *already* on regular Debian, so this would be a step backwards, for short-term gratification.
I don't want to deny DDs this gift, but they should be aware those bearing it may be Greeks.
The first thing that came to mind when I saw 'gratis licenses for Free Software devs' was BitKeeper, and we saw how well that turned out. Thankfully Valve make games, so if this ends up exploding then nothing important will be lost.
You are aware that the "carrots help you see in the dark" thing was a lie the Brits told to try to cover the fact that they had radar? As far as I'm aware there's zero evidence whatsoever that carrots or any nutrient in them does a damned thing for your eyes.
Carrots don't help you see in the dark, but they can prevent you going blind
http://www.blindness.org/index...
http://www.goldenrice.org/Cont...
Why does every network management tool include their own ugly, broken little programming language for configuring it?
Why not just use an existing language?
The better solution is to fix the DSL, rather than introducing a general-purpose language.
Domain Specific Languages are really good at making code simpler, more concise and less redundant, but their most important feature is reducing bugs. A DSL can use primitives which have the possible error-modes built in; a general-purpose language would have to build that in a separate library layer, but the problems with that are 1) the general-purpose stuff is still available, which won't catch your errors 2) a decent abstraction layer *is* a DSL. In OO land, an object's interface is a DSL for controlling that object and a class library is a simulation of the components of some problem domain. In functional land it's usually even more explicit, with datatypes to represent programs, combinators for building them up and functions for interpreting them.
I do not consider " teaching "all sides" of "competing theories" to be rhetoric. If "science" cannot withstand alternative theories to be taught alongside their theories then it is not science. Those advocating creationism have just as many valid points as the rabid theorists believing as they do.
Science *has* withstood alternative theories being taught alongside. In fact, those "alternative theories" were the *only* thing being taught for a few thousand years. Our current understanding is thanks to brilliant people who 'taught the controversy' of modern science over the past few hundred years and have almost won.
Religious creation myths are not the underdog; they dominated the world when there was no alternative; as soon as one appeared, they crumbled. Nonsense like creationism is just a last-ditch attempt by particular church leaders to cling on to their power. They know they're on the way out, so don't mind alienating the majority in order to radicalise a few.
How Good Are Charter Schools For the Public School System?
No!
So instead of dropping the privilege to write files at all, which would not be feasible in many applications, you would have a file descriptor to a directory that allows writing files under that directory.
That's an interesting choice of example, since I've often seen the *opposite* used to demonstrate capability systems; specifically that we can keep a filesystem capability in our shell and do everything else with stdio and pipes. For example, rather than giving a filesystem capability to "cp", we can get rid of "cp" altogether and use "cat file2". Since "cat" is only operating on stdio, we don't need to give it any filesystem capability.
"Many eyes" is bogus, "the right eyes" is more appropriate.
In this case "the right eyes" are robotic.
don't most people these days favor streaming options? Why would I fret with starting a download at 8am (programming it into a DVR-like device, making sure it gets saved somewhere proper, etc.) when I can just hit play at 8pm anyway?
People don't prefer streaming, they prefer downloading. Ask anyone if they get annoyed by "buffering" messages, especially when they're skipping *backwards*. Streaming is only a thing since broadband speeds have made it feasible and there are big bucks to be had in the preventing-people-from-having-what-they-want business, also known as media distribution. "Streaming" is just a buzzword which means 'you will download it on to your disk in your machine using your bandwidth, but we will delete it lolololol'.
Your straw man doesn't even make any sense: /tmp already.
* Why would you need to start a download 12 hours before watching it if you have enough bandwidth to stream it? When you "just hit play at 8pm" do you then immediately hit pause and leave it to buffer for 12 hours (assuming that the service lets you buffer more than 10 minutes)? I assume your Internet connection doesn't gain magical turbo powers when you delete stuff, so stop fretting and open the URL in VLC at 8pm.
* What are netflix.com, youtube.com, etc. if not "DVR-like devices"? At least if you download it, you can use whatever the hell "DVR-like device" you want; plus you won't have to wait until those services give enough of a crap about the particular device you want to use that they implement a fresh port of their DVR-like service to it (protip: they won't; instead, you'll have to buy the brand new whizz-bang device they do give a crap about thanks to an exclusivity contract, which will be a different device from every other service you like).
* Why do you care that downloads 'get saved somewhere proper'? You obviously don't care about that for your streams, since they don't get saved! Just dump everything into
It's like like they're only targeting free operating systems, as Mac somehow made the list.
More likely: the author happens to develop on Linux, Mac and/or Android and once it compiled there, the others came for free. Since adding Windows support usually requires a bunch of workarounds and rewrites, we'll have to wait until the effort's been put in.
What makes this interesting is the inversion of control. For years, net neutrality has basically hinged on the fact that users are paying their ISP for bandwidth, so it's up to the user what they do with it. This idea completely inverts that, so the user has absolutely no control anymore.
We were worried that walled gardens like Facebook were turning the Web into a consumer service, well this will do the same for the Internet itself.
I've been using Emacs for a couple of years now and think it's pretty good. The most important bug IMHO is its lack of concurrency. Connecting to remote machines with TRAMP is great, but having the whole app become unresponsive for a period is jarring. Also, I have to run GNUs from a separate process so I can actually do some work while it refreshes.
Giving ELisp lexical scope is a good start in this direction, since it allows for fully encapsulated closures which won't trample over each others' namespaces. Once that becomes pervasive, it wouldn't be too (conceptually) difficult to add a concurrent event handler to fire off asynchronous functions like node.js.
See http://www.arcadelearningenvironment.org/ for a few other approaches to this de-facto AI test.
"Are these outdated specs worth your privacy and freedom?"
Hell yes! I paid £200 (the price in TFS) for my current laptop, an OLPC XO-1. It has a 433MHz processor, 256MB RAM and 1GB storage, so the system described in the summary would be a great upgrade (although I assume its screen isn't from Pixel Qi :( ). The reason I've stuck with my XO-1 for the past 4 years is that I've been ratchetting myself away from proprietary systems:
Windows+nVidia+Flash+BIOS -> Dual-boot Windows/Linux+nVidia+Flash+BIOS -> Linux+nVidia+Flash+BIOS -> Linux+Flash+BIOS -> Linux+BIOS -> Linux+OpenFirmware
Since there are so few systems as free as my XO-1, it's been difficult to find anything to switch to. I'll probably get one of these laptops :)
Now if only someone would make a phone without binary blobs, so I can upgrade from my aging OpenMoko :/