I would like to see the questionnaire and how it was worded. One interesting problem is that the term "copyrighted" probably has a hazy meaning to most respondents. I'm sure many of them will automatically associate "copyrighted" with "commercial", so I really doubt that much of the gap is due to open source, etc. Still, without more specific details on the survey, it's impossible to interpret the results. There's also no indication of how they sampled and from what population.
They're probably right in concluding that people are stealing, but the statistics as presented are meaningless.
The article picks the weakest tasks for voice to deal with, trivial things like scrolling. Obviously no one wants to do that. But I'd love to be able to speak my Google query instead of typing it, activate some applications without clicking, and many other tasks.
The dubious argument about interfering with memory is pretty weak, and I would love to hear a good memory expert in psychology comment on that. Even if that's strictly true, it only applies when one is interrupting some particlarly "vocal" activity, like writing or reading. There are plenty of times I'm using the computer when I'd rather speak to it than move my eyes or my hands.
This researcher seems to have latched onto a single modality instead of considering what we use day to day to communicate with each other, a combination of many communication forms.
I know I don't roll my eyes or gesture to ask someone to pass the salt... unless my mouth is full.:)
I've always wondered why we work so hard for full natural language interface. It's far more likely that I will learn a new language than that my computer will. Indeed, I've learned several languages to "talk" to my computer.
Of course, these are programming languages, but I don't see why some highly structured, relatively unambiguous language couldn't be constructed to talk to computers.
The success of the Palm Pilot can be traced, in my view, to the fact that it didn't strive for full hand-writing recognition (like, say, a Newton). Instead, it required the human to meet it half-way. You get decent accuracy/speed for a small investment in learning.
We accept these compromises in many of our dealings with computers. I don't understand why people aren't promoting a similar compromise in voice communications?
I'm so relieved that there are UI experts out there making decisions like this. If it hadn't been for them, I would never have realized that right-clicking and selecting "Back" is nowhere near as efficient as trying to do it, seeing the context menu for that part of the screen doesn't have it, and then having to move all the way to the top left of the screen and click the Back button.
They won't even add a pref for it because adding another pref would be "bad UI" according to their designers. If what they have now is "good UI", then I really don't understand how they think.
This might explain why I've never talked to anyone who works in UI who didn't come across like a cross between a flaky social psychologist and a failed fine arts student.
Note, I'm sure the UI field has its share of brilliant people... it just seems to have more than its share of opinionated pedants.
My experience with Promise is considerably worse. I have the FastTrak100 TX2 and as far as I can tell, the drivers they provide will only work with the original Redhat 7.1 kernel (not the upgraded kernels). In any event, I submitted two "problem reports" to Promise, one in October 2001, another in January 2002. No reponse. I directly emailed their support group in February. Still no response.
I wrote civil messages, carefully explaining that I wasn't compiling up my own kernels but using the official RedHat kernels, so I don't think they can be excused on the grounds that I'm outside a reasonable support area. They didn't even have the decency to answer!
Now I'm stuck with a useless card (the open source driver doesn't support mirroring) that I bought because they claimed to support Linux.
That's funny... I actually live in Guelph, the city with the "stupid" garbage separation. It's no problem in my household and I don't go picking through garbage. In fact, on the rare occasions when one has accidentally thrown something away it's much nicer because you probably threw it in the dry and don't have to navigate around coffee grounds, etc.
"I don't take being forced to do anything very well when it doesn't harm anyone else, and neither should you!"
What, like paying taxes for roads and fuel? You're forced to do that because it's part of your public responsibility. Why should the environment be any different? The fact is that very few people will voluntarily pay for environmental benefits using the same short-sighted "doesn't harm anyone" reasoning you've applied.
This is a good idea. The recycling is good idea and the only way to get it done is for it to be paid up front. If we legislated recycling but allowed aftermarket payment, we'd find the roadsides littered with abandoned PC's. The EU is trying (rather unsuccessfully) to do the same thing with cars.
The following are results on 100 variable, 460 clause, "hard" random 3-SAT problems running on a PIII 750. The results are averaged over 100 repetitions of 1000 variables (some solvers are stochastic which is why multiple runs are used).
The result shown is the average number of seconds required to solve a single problem once.
Note, these problems are 5 times larger than the one solved by the DNA computer and likely much harder (the DNA one sounds very underconstrained).
Both complete and incomplete solvers are shown:
My mistake. They have promised a modem add-on and a NIC add-on. History has shown that peripherals don't succeed in general, although if FFXI is potentially the "killer app" that could move them. The problem exists for the PS2, of course.
The GameCube doesn't have online capability (at present). That sort of kills FFXI. I don't believe Nintendo has committed to providing a modem/NIC as of yet.
..read the book! I read the book when I was about 9. It was pretty good (when you're 9). It had a lot more detail, a more romantic relationship between Tron and whassername. It also had them chased by Grid Bugs and a lot more complexity in the solar sailer (?) sequence. I always thought the Grid Bugs were cool.
The movie, game (first game), and book had such an impact on me as a kid that I programmed crappy little text-based Tron games of a complexity a little higher than "Hunt the Wumpus". Of course, that was on an Amdahl mainframe running Sharp APL, so I might be forgiven if they were less than visually stunning (the terminals were Volker-Craig 415 PFs). I personally think that writing in APL set my programming ability back by about three years in the long haul, but I digress.
Hmmm... lots of random assertions, plenty of highly opinionated jabs at people and companies, but not much actually said about the nature of the problem and no interesting solutions at all. He has, perhaps, one point. The rest is vague claims of a lack of "science" in other people's UI design. If that's the best he can do, I'm certainly not buying one, let alone two books he wrote.
I'm not going to try to champion Java, JITs, or native compilation, I'm just going to point out what's wrong with this "study".
This has to be the third or fourth weak study of Java performance I've seen over several years. Issues such as whether or not all Java features are in place in the native compilations (e.g. array bound checking, but note that GCJ turns this on by default) or what sort of optimizations are performed by the native compiler and JVMs are completely ignored. The author also suggests that compiling from bytecode to native code is the natural route when it's quite possible that gains could be made by compiling directly from source to native. While GCJ accepts either Java source or bytecode, it's not clear from the documentation I've read whether or not it first translates source to bytecode or goes straight from source to native.
When comparing disk space, the author comments that an installed JVM can be up to 50 MB vs. 3 MB or so for libgcj. This is a ridiculous comparison since those directories probably include all of the tools, examples and libraries, and as far as I know, libgcj doesn't include the whole J2SE API set, so it's nowhere near a fair comparison. It's a pretty limited set of benchmarks for making these judgements too.
I played around with native compilation of Java a few years ago. At one point (probably around 1996/7?) native compilers could offer noticable gains over Sun's JVM on a numerically intensive application (neural network stuff). However, after the initial versions of HotSpot and IBM's JIT, I couldn't find a native compiler that gave competitive performance on similar apps. I think this is largely due to underdeveloped native compilers with poor optimization (HotSpot is quite insane in its runtime optimizations).
Anyway, I sure hope IBM doesn't pay too generously for studies this poor. Its final message is essentially "who knows?" - not terribly useful.
Ada was not designed by a committee. It was one of several proprosed languages. And it's really not a bad language (I just wrote a compiler for a subset of the language), especially considering when it was made. I'd certainly rather write Ada than Perl.
Slashdot Mirror
Are there any similar projects for the RioVolt SP250? It has upgradeable firmware as well. A quick Google search turned up nothing.
I would like to see the questionnaire and how it was worded. One interesting problem is that the term "copyrighted" probably has a hazy meaning to most respondents. I'm sure many of them will automatically associate "copyrighted" with "commercial", so I really doubt that much of the gap is due to open source, etc. Still, without more specific details on the survey, it's impossible to interpret the results. There's also no indication of how they sampled and from what population.
They're probably right in concluding that people are stealing, but the statistics as presented are meaningless.
Hmm.... talking into a machine will be bad for the office... gee, I guess we better throw away all those telephones...
The article picks the weakest tasks for voice to deal with, trivial things like scrolling. Obviously no one wants to do that. But I'd love to be able to speak my Google query instead of typing it, activate some applications without clicking, and many other tasks.
:)
The dubious argument about interfering with memory is pretty weak, and I would love to hear a good memory expert in psychology comment on that. Even if that's strictly true, it only applies when one is interrupting some particlarly "vocal" activity, like writing or reading. There are plenty of times I'm using the computer when I'd rather speak to it than move my eyes or my hands.
This researcher seems to have latched onto a single modality instead of considering what we use day to day to communicate with each other, a combination of many communication forms.
I know I don't roll my eyes or gesture to ask someone to pass the salt... unless my mouth is full.
I've always wondered why we work so hard for full natural language interface. It's far more likely that I will learn a new language than that my computer will. Indeed, I've learned several languages to "talk" to my computer.
Of course, these are programming languages, but I don't see why some highly structured, relatively unambiguous language couldn't be constructed to talk to computers.
The success of the Palm Pilot can be traced, in my view, to the fact that it didn't strive for full hand-writing recognition (like, say, a Newton). Instead, it required the human to meet it half-way. You get decent accuracy/speed for a small investment in learning.
We accept these compromises in many of our dealings with computers. I don't understand why people aren't promoting a similar compromise in voice communications?
I'm so relieved that there are UI experts out there making decisions like this. If it hadn't been for them, I would never have realized that right-clicking and selecting "Back" is nowhere near as efficient as trying to do it, seeing the context menu for that part of the screen doesn't have it, and then having to move all the way to the top left of the screen and click the Back button.
They won't even add a pref for it because adding another pref would be "bad UI" according to their designers. If what they have now is "good UI", then I really don't understand how they think.
This might explain why I've never talked to anyone who works in UI who didn't come across like a cross between a flaky social psychologist and a failed fine arts student.
Note, I'm sure the UI field has its share of brilliant people... it just seems to have more than its share of opinionated pedants.
My experience with Promise is considerably worse. I have the FastTrak100 TX2 and as far as I can tell, the drivers they provide will only work with the original Redhat 7.1 kernel (not the upgraded kernels). In any event, I submitted two "problem reports" to Promise, one in October 2001, another in January 2002. No reponse. I directly emailed their support group in February. Still no response.
I wrote civil messages, carefully explaining that I wasn't compiling up my own kernels but using the official RedHat kernels, so I don't think they can be excused on the grounds that I'm outside a reasonable support area. They didn't even have the decency to answer!
Now I'm stuck with a useless card (the open source driver doesn't support mirroring) that I bought because they claimed to support Linux.
That's funny... I actually live in Guelph, the city with the "stupid" garbage separation. It's no problem in my household and I don't go picking through garbage. In fact, on the rare occasions when one has accidentally thrown something away it's much nicer because you probably threw it in the dry and don't have to navigate around coffee grounds, etc.
"I don't take being forced to do anything very well when it doesn't harm anyone else, and neither should you!"
What, like paying taxes for roads and fuel? You're forced to do that because it's part of your public responsibility. Why should the environment be any different? The fact is that very few people will voluntarily pay for environmental benefits using the same short-sighted "doesn't harm anyone" reasoning you've applied.
This is a good idea. The recycling is good idea and the only way to get it done is for it to be paid up front. If we legislated recycling but allowed aftermarket payment, we'd find the roadsides littered with abandoned PC's. The EU is trying (rather unsuccessfully) to do the same thing with cars.
Sorry, that's "100 repetitions of 1000 problems" (not variables).
Note, these problems are 5 times larger than the one solved by the DNA computer and likely much harder (the DNA one sounds very underconstrained).
Both complete and incomplete solvers are shown:
Note: Things don't really get interesting until you get up over 500 variables for hard, random 3-SAT.
My mistake. They have promised a modem add-on and a NIC add-on. History has shown that peripherals don't succeed in general, although if FFXI is potentially the "killer app" that could move them. The problem exists for the PS2, of course.
The GameCube doesn't have online capability (at present). That sort of kills FFXI. I don't believe Nintendo has committed to providing a modem/NIC as of yet.
..read the book! I read the book when I was about 9. It was pretty good (when you're 9). It had a lot more detail, a more romantic relationship between Tron and whassername. It also had them chased by Grid Bugs and a lot more complexity in the solar sailer (?) sequence. I always thought the Grid Bugs were cool.
The movie, game (first game), and book had such an impact on me as a kid that I programmed crappy little text-based Tron games of a complexity a little higher than "Hunt the Wumpus". Of course, that was on an Amdahl mainframe running Sharp APL, so I might be forgiven if they were less than visually stunning (the terminals were Volker-Craig 415 PFs). I personally think that writing in APL set my programming ability back by about three years in the long haul, but I digress.
Hmmm... lots of random assertions, plenty of highly opinionated jabs at people and companies, but not much actually said about the nature of the problem and no interesting solutions at all. He has, perhaps, one point. The rest is vague claims of a lack of "science" in other people's UI design. If that's the best he can do, I'm certainly not buying one, let alone two books he wrote.
I'm not going to try to champion Java, JITs, or native compilation, I'm just going to point out what's wrong with this "study".
This has to be the third or fourth weak study of Java performance I've seen over several years. Issues such as whether or not all Java features are in place in the native compilations (e.g. array bound checking, but note that GCJ turns this on by default) or what sort of optimizations are performed by the native compiler and JVMs are completely ignored. The author also suggests that compiling from bytecode to native code is the natural route when it's quite possible that gains could be made by compiling directly from source to native. While GCJ accepts either Java source or bytecode, it's not clear from the documentation I've read whether or not it first translates source to bytecode or goes straight from source to native.
When comparing disk space, the author comments that an installed JVM can be up to 50 MB vs. 3 MB or so for libgcj. This is a ridiculous comparison since those directories probably include all of the tools, examples and libraries, and as far as I know, libgcj doesn't include the whole J2SE API set, so it's nowhere near a fair comparison. It's a pretty limited set of benchmarks for making these judgements too.
I played around with native compilation of Java a few years ago. At one point (probably around 1996/7?) native compilers could offer noticable gains over Sun's JVM on a numerically intensive application (neural network stuff). However, after the initial versions of HotSpot and IBM's JIT, I couldn't find a native compiler that gave competitive performance on similar apps. I think this is largely due to underdeveloped native compilers with poor optimization (HotSpot is quite insane in its runtime optimizations).
Anyway, I sure hope IBM doesn't pay too generously for studies this poor. Its final message is essentially "who knows?" - not terribly useful.
Alea
Ada was not designed by a committee. It was one of several proprosed languages. And it's really not a bad language (I just wrote a compiler for a subset of the language), especially considering when it was made. I'd certainly rather write Ada than Perl.