Don't get too discouraged by the large number of commenters who haven't used speech recognition or who don't understand why someone might need to lay off the keyboard for a while. I wrote 100k lines of C++ code hands-free for my astronomy thesis over the course of two years, using with speech recognition software that is now about 10 years out-of-date. There have been significant improvements in both the speech recognition technology and tools for coding by voice since then.
For coding, take a look at the VoiceCode project at
http://voicecode.iit.nrc.ca/VoiceCode/public/ywiki .cgi
For other tools/approaches to coding by voice, see also the VoiceCoder group at yahoo groups:
http://groups.yahoo.com/group/VoiceCoder/
I don't know of any open-source or non-commercial dictation software which matches the accuracy and ease-of-use of the Dragon NaturallySpeaking (fair warning - I work for Nuance, which makes Natspeak, though I was a user long before I became an employee). Natspeak is only available for MS Windows, but you can always put a Windows box on your desk and connect to a unix host via an X server (exceed, xwin32). That generally works well for command-line stuff, not so great for GUIs (but you say you prefer command-lines anyway).
I've done a bit of asynchronous debugging, principally troubleshooting interaction between a speech recognition system and Emacs. Most of the bugs I found tended to be due to errors in assumptions in the code. For example,
(a) when a "change text" event handler in the editor is invoked, the editor will always be done reporting the result of the previous change.
(b) event z will always be preceded by event w
If you know the assumptions for each event handler, cases where they break down may become obvious. If not, you can add assertions to check those assumptions.
Beyond that, strategies really depend on what sort of feedback loops you have. When you are debugging interaction between two objects or programs, try to simplify one so that you don't waste a lot of time trying to figure out which side is buggy. For example, I wrote a simple brain-dead editor which I was confident I understood and connected it to the speech recognition system. That way, when I found a problem, I was confident that I could quickly find any bugs on the editor side, so if I didn't find the bug there quickly, it had to be in the speech reco system.
I don't know whether Mr. Young was misquoted or just mistaken, but it's easy to see that there's something fishy about the 1 in 455 chance of human extinction due to asteroids, comets, or "super volcanos" in 100 years.
Suppose that figure is true. Suppose also that this figure hasn't increased over the time in which human beings have existed on Earth.
Homo sapiens sapiens (modern man) has been around for about 100,000 years. Homo sapiens as a whole is about 500,000 years, and homo erectus dates back to 1.8 million years.
Given the 1 in 455 per 100 years figure, the probability of homo sapiens sapiens surviving 100000 years is (454/455)^1000 = 11%. The probability of homo sapiens having survived from 500000 years until today would be (454/455)^5000 = 1.67 x 10^-5 (1 in 60000). The probability that homo erectus would have survived to evolve into homo sapiens, and that homo sapiens would have survived to today would be (454/455)^(18000) = 6.3 x 10^-18 (1 in a billion-billion).
This makes the starting assumptions of the calculation extremely unlikely.
Of course, maybe my second assumption, that the risk of extinction from asteroids, comets, and supervolcanos hasn't increased lately, was wrong.
I don't know what a supervolcano is, but geology usually changes on, well, geological timescales. As for comets and asteroids, I don't recall anyone mentioning the increase in impacts while I was studying astronomy in grad school in the nineties.
Still, maybe it's not that the frequency of such events that has increased, but that our chance of surviving them has decreased. I suppose one could argue that there are more of us and less nature to survive on, or that most of us don't know how to hunt, gather, or grow our own food, so perhaps a larger fraction of the population would die in such a catastrophe. However, it is not clear that such an event would cause the extinction of the species.
So, all in all, I'd say that 1 in 455 is a bit high.
The article says that SCO will reveal the copied code to analysts who sign a non-disclosure agreement. Is this consistent with SEC regulations which prohibit a company from selectively disclosing material non-public information to investment advisors?
The regulations states that:
Information is material if "there is a substantial likelihood that a reasonable shareholder would consider it important" in making an investment decision
Since SCO's future financial success may hinge on whether it can establish its claims, proof of those claims would certainly seem to be material.
Looking up Regulation FD at www.sec.gov, it seems that it is legal to disclose such information selectively provided that:
the disclosees sign a non-disclosure agreement, AND
the disclosees do not make stock trades on the basis of the information.
So, it looks like SCO has #1 covered, but they'd better be careful about #2, or they could end up in really hot water.
Slashdot Mirror
Fortunately, Jobs didn't create Millions of McNealies
Don't get too discouraged by the large number of commenters who haven't used speech recognition or who don't understand why someone might need to lay off the keyboard for a while. I wrote 100k lines of C++ code hands-free for my astronomy thesis over the course of two years, using with speech recognition software that is now about 10 years out-of-date. There have been significant improvements in both the speech recognition technology and tools for coding by voice since then. For coding, take a look at the VoiceCode project at http://voicecode.iit.nrc.ca/VoiceCode/public/ywiki .cgi
For other tools/approaches to coding by voice, see also the VoiceCoder group at yahoo groups:
http://groups.yahoo.com/group/VoiceCoder/
I don't know of any open-source or non-commercial dictation software which matches the accuracy and ease-of-use of the Dragon NaturallySpeaking (fair warning - I work for Nuance, which makes Natspeak, though I was a user long before I became an employee). Natspeak is only available for MS Windows, but you can always put a Windows box on your desk and connect to a unix host via an X server (exceed, xwin32). That generally works well for command-line stuff, not so great for GUIs (but you say you prefer command-lines anyway).
I've done a bit of asynchronous debugging, principally troubleshooting interaction between a speech recognition system and Emacs. Most of the bugs I found tended to be due to errors in assumptions in the code. For example,
(a) when a "change text" event handler in the editor is invoked, the editor will always be done reporting the result of the previous change.
(b) event z will always be preceded by event w
If you know the assumptions for each event handler, cases where they break down may become obvious. If not, you can add assertions to check those assumptions.
Beyond that, strategies really depend on what sort of feedback loops you have. When you are debugging interaction between two objects or programs, try to simplify one so that you don't waste a lot of time trying to figure out which side is buggy. For example, I wrote a simple brain-dead editor which I was confident I understood and connected it to the speech recognition system. That way, when I found a problem, I was confident that I could quickly find any bugs on the editor side, so if I didn't find the bug there quickly, it had to be in the speech reco system.
I don't know whether Mr. Young was misquoted or just mistaken, but it's easy to see that there's something fishy about the 1 in 455 chance of human extinction due to asteroids, comets, or "super volcanos" in 100 years.
Suppose that figure is true. Suppose also that this figure hasn't increased over the time in which human beings have existed on Earth.
Homo sapiens sapiens (modern man) has been around for about 100,000 years. Homo sapiens as a whole is about 500,000 years, and homo erectus dates back to 1.8 million years.
Given the 1 in 455 per 100 years figure, the probability of homo sapiens sapiens surviving 100000 years is (454/455)^1000 = 11%. The probability of homo sapiens having survived from 500000 years until today would be (454/455)^5000 = 1.67 x 10^-5 (1 in 60000). The probability that homo erectus would have survived to evolve into homo sapiens, and that homo sapiens would have survived to today would be (454/455)^(18000) = 6.3 x 10^-18 (1 in a billion-billion).
This makes the starting assumptions of the calculation extremely unlikely.
Of course, maybe my second assumption, that the risk of extinction from asteroids, comets, and supervolcanos hasn't increased lately, was wrong.
I don't know what a supervolcano is, but geology usually changes on, well, geological timescales. As for comets and asteroids, I don't recall anyone mentioning the increase in impacts while I was studying astronomy in grad school in the nineties.
Still, maybe it's not that the frequency of such events that has increased, but that our chance of surviving them has decreased. I suppose one could argue that there are more of us and less nature to survive on, or that most of us don't know how to hunt, gather, or grow our own food, so perhaps a larger fraction of the population would die in such a catastrophe. However, it is not clear that such an event would cause the extinction of the species.
So, all in all, I'd say that 1 in 455 is a bit high.
The article says that SCO will reveal the copied code to analysts who sign a non-disclosure agreement. Is this consistent with SEC regulations which prohibit a company from selectively disclosing material non-public information to investment advisors?
The regulations states that:
Since SCO's future financial success may hinge on whether it can establish its claims, proof of those claims would certainly seem to be material.
Looking up Regulation FD at www.sec.gov, it seems that it is legal to disclose such information selectively provided that:
So, it looks like SCO has #1 covered, but they'd better be careful about #2, or they could end up in really hot water.
Any lawyers out there want to comment?