3. Voice input: My first exposure to this was a demo from IBM in the mid 1990's. PCs have increased in power a lot since then and the quality of voice recognition has hardly changed, so I think it's going to take a major new discovery to make significant advances in the next five years.
3. Voice input Speech to text is still pretty bad. Some examples of problems it still struggles with are handling different accents, background noise.
Ack. Imagine trying to tell a computer to go to Slashdot. I'd rather just double the killer delete select all...
If you have to say anything more than "go to slashdot", your system sucks. If you have to say an url, your system sucks. Thinking voice control means dictation is narrow minded at best.
You're incorrect on one point at least: I have a speech recognizer handy that finishes converting your speech to text 0 to 0.4 second after you finish talking. Not available publically though.
The interesting thing with speech is that, for at least part of the population, natural language for information retrieval is spontaneous orally but not with a keyboard. And well used natural language with its abstraction and requested answer description capabilities can be way more efficient than keywords when you're looking for something.
As for "however small", in our probability wave word there is pretty much no zero probability. "Small enough not to matter" is where it's at. Someone somewhere being hit by a meteorite, natural or artificial, is improbable enough to be close, yourself or someone you know being hit is straight in that territory.
In other words, it's billion of times more probable for you to die in a car accident than being hit by a meteorite.
Part of this stuff plummets out of orbit all the time. Most of it burns up, as for the rest, it's very hard to hit someone. The earth's surface is big (510 million square kilometers), mostly water, and we're only 6 billions or so with a rather small surface area each. A quick estimate of the hit-a-human probability puts it around 1e-6 or so.
Walmart tools are already crap in your own kitchen, how usable do you think they are in a vacuum, with the cold, the radiation and the gloves from hell astronauts have to wear?
In that context, it just means that windows are drawn offscreen and are copied together in the framebuffer later. Gives backing store for free and allows for easier transparent windows or other effects at the cost of more graphics memory (negligible nowadays) and on-gpu copies (probably less expensive than the lack of backing store since it happens on the same side of the graphics bus).
One word: stiction. I don't know how modern drives are susceptible to it (I don't power them off if I can avoid it), but with old drives a poweroff was a kind of russian roulette. You never knew if the drives would spinup again or not.
How many tries will the operator get? Because transcribing exactly what you hear over the phone is a fun task, *much* harder than just comparing with something written. In particular, should the operator use capitalization, punctuation, British or US spelling ? How do you ensure how the original operator who entered the password (or worse the client) followed the exact same rules to the letter?
Yep, you're right. I missed a step... The public key (certificate) is *signed* by a CA. That's the purpose of Verisign/Thawte/etc. Signing is another public key process, only its used to verify that the public key delivered by Party A and B are registered with Verisign.
And now compare with that part of the original post you cited as "not understanding crypto": Are we going to have a certificate registry for pirated material? Not very likely.
And when at least Al Viro and Alan Cox (at least, from what I remember) ask to have their code removed from the kernel, the entire scheme will go *poof*. Linus is not the only important one against the GPL3 as it is for the kernel.
You know what they say about assuming? The egcs guys decided from the start to only accept fsf-assigned contributions to allow re-merging with gcc in the future. Which eventually happened.
He got that from reality maybe? On a fedora core 5 64 bts with a small amount of extras packages, of 35814 dependencies in the packages 24112 are files and 11702 packages. That's 67% files.
It's broadcast news in arabic and mandarin. I don't have the latest numbers handy but 80%, well, 20-25% error rate, nobody in the ASR community uses accuracy, is pretty much correct for arabic. I think mandarin is better though. Arabic has some unique problems, the main one being that there is no such thing as arabic in the first place.
Translation *is* the hardest part in the Gale project. So much harder than in the current evaluations the translations are so bad that the impact of the ASR errors on the final result is not significantly detectable it seems. We hope that the MT teams are going to make some massive progress fast (they may, they get a *lot* of new data from the project) so that working on the ASR actually means something, but more importantly so that the project goes on.
Connection machine at a guess. The beautiful era of vector cpus and data parallelism. Which got scaled up and down at the same time to modern MMX/SSE/Altivec and friends.
Except the discussion wasn't about COW on fork, but COW in a zero-copy high performance userspace-kernel-device communication system. A faster write(), essentially (and write is already quite fast, TYVM).
Have you ever seen a painter or a writer work 9 to 17 weekdays period?
Quality programming has a non-negligible artistic component. I know it's fashionable to try and ignore it, especially at manager level, but then that kind of people do not really care about the quality part either.
I doubt one can do anything intersting about kernel fault isolation anyway. If you look at linux conceptually, there isn't that much in there: - device drivers - memory management - filesystems - networking
If a device driver crashes, unless it's usb you're essentially toast (think dma to lalaland, infinitely repeating interrupts...). And usb for funky devices tends to be done in userspace (see scanners with sane).
If a filesystem crashes and it's a primary one you're toast since you can't access programs anymore. Secondary ones can be in userspace (see FUSE).
If the memory management crashes, you're obviously dead.
And if networking crashes, you at least lose all current connections, which can be quite annoying. Tends to be a very, very well tested part of the kernel in today's internet though.
So, well, to the exception of networking which tends to be very stable anyway or dies fast, evrything that a microkernel could recover on crash tends to be doable and often done in userspace in linux. And probably in BSDs too, I just don't know them. So I'm not that sure there is a point to microkernels in practice, especially given their performance and engineering costs.
But linux _is_ purely monolithic. There is only one address space, and modules link their symbols directly inside the current image. Modules are equivalent to dlopen(), not fork+exec(). There is also no communication interfaces per se. Modules directly call functions or access structures fields. Of course these functions and structures are (mostly) organized in APIs and semi-objects, but that means the internal design is clean, not that it has anything to do with a microkernel.
Nope, CISC is technically superior for current processors because it allows to pack more instructions in less bytes. And it looks like nowadays a CISC-RISC translator takes less silicon than a bigger L1/L2. Don't underestimate the packing effect of CISC instruction sets, especially vs. RISC-VLIW. That's part of what killed IA-64.
The ability to change the underlying RISC/microcode without changing the CISC front-end is not to be neglected either.
Unless you don't care about anything post-1980. Dual doesn't help Mame at all, so you end up doing everything on one really puny 200Mhz processor. It *will* suck.
Slashdot Mirror
3. Voice input: My first exposure to this was a demo from IBM in the mid 1990's. PCs have increased in power a lot since then and the quality of voice recognition has hardly changed, so I think it's going to take a major new discovery to make significant advances in the next five years.
[Citation needed]
3. Voice input
Speech to text is still pretty bad. Some examples of problems it still struggles with are handling different accents, background noise.
Ack. Imagine trying to tell a computer to go to Slashdot.
I'd rather just double the killer delete select all...
If you have to say anything more than "go to slashdot", your system sucks. If you have to say an url, your system sucks. Thinking voice control means dictation is narrow minded at best.
OG.
You're incorrect on one point at least: I have a speech recognizer handy that finishes converting your speech to text 0 to 0.4 second after you finish talking. Not available publically though.
The interesting thing with speech is that, for at least part of the population, natural language for information retrieval is spontaneous orally but not with a keyboard. And well used natural language with its abstraction and requested answer description capabilities can be way more efficient than keywords when you're looking for something.
OG.
Burn and vaporize.
As for "however small", in our probability wave word there is pretty much no zero probability. "Small enough not to matter" is where it's at. Someone somewhere being hit by a meteorite, natural or artificial, is improbable enough to be close, yourself or someone you know being hit is straight in that territory.
In other words, it's billion of times more probable for you to die in a car accident than being hit by a meteorite.
OG.
Part of this stuff plummets out of orbit all the time. Most of it burns up, as for the rest, it's very hard to hit someone. The earth's surface is big (510 million square kilometers), mostly water, and we're only 6 billions or so with a rather small surface area each. A quick estimate of the hit-a-human probability puts it around 1e-6 or so.
OG.
Walmart tools are already crap in your own kitchen, how usable do you think they are in a vacuum, with the cold, the radiation and the gloves from hell astronauts have to wear?
OG.
In that context, it just means that windows are drawn offscreen and are copied together in the framebuffer later. Gives backing store for free and allows for easier transparent windows or other effects at the cost of more graphics memory (negligible nowadays) and on-gpu copies (probably less expensive than the lack of backing store since it happens on the same side of the graphics bus).
OG.
One word: stiction. I don't know how modern drives are susceptible to it (I don't power them off if I can avoid it), but with old drives a poweroff was a kind of russian roulette. You never knew if the drives would spinup again or not.
OG.
How many tries will the operator get? Because transcribing exactly what you hear over the phone is a fun task, *much* harder than just comparing with something written. In particular, should the operator use capitalization, punctuation, British or US spelling ? How do you ensure how the original operator who entered the password (or worse the client) followed the exact same rules to the letter?
OG.
Errr, by ISCA you mean the International Speech Communication Association?
OG.
Yep, you're right. I missed a step... The public key (certificate) is *signed* by a CA. That's the purpose of Verisign/Thawte/etc. Signing is another public key process, only its used to verify that the public key delivered by Party A and B are registered with Verisign.
And now compare with that part of the original post you cited as "not understanding crypto":
Are we going to have a certificate registry for pirated material? Not very likely.
*duh*.
OG.
And when at least Al Viro and Alan Cox (at least, from what I remember) ask to have their code removed from the kernel, the entire scheme will go *poof*. Linus is not the only important one against the GPL3 as it is for the kernel.
OG.
You know what they say about assuming? The egcs guys decided from the start to only accept fsf-assigned contributions to allow re-merging with gcc in the future. Which eventually happened.
OG.
He got that from reality maybe? On a fedora core 5 64 bts with a small amount of extras packages, of 35814 dependencies in the packages 24112 are files and 11702 packages. That's 67% files.
OG.
... ASR on people talking to each other naturally Just Doesn't Work[tm]. As in 70-80% error rate or worse.
Gale is about TV/Radio news, not random people conversations.
OG.
It's broadcast news in arabic and mandarin. I don't have the latest numbers handy but 80%, well, 20-25% error rate, nobody in the ASR community uses accuracy, is pretty much correct for arabic. I think mandarin is better though. Arabic has some unique problems, the main one being that there is no such thing as arabic in the first place.
OG.
Translation *is* the hardest part in the Gale project. So much harder than in the current evaluations the translations are so bad that the impact of the ASR errors on the final result is not significantly detectable it seems. We hope that the MT teams are going to make some massive progress fast (they may, they get a *lot* of new data from the project) so that working on the ASR actually means something, but more importantly so that the project goes on.
OG.
70-80% accuracy (well, 20-30% error rate) seems enough in practice. 100% never happens, even for humans.
OG.
Connection machine at a guess. The beautiful era of vector cpus and data parallelism. Which got scaled up and down at the same time to modern MMX/SSE/Altivec and friends.
OG.
Except the discussion wasn't about COW on fork, but COW in a zero-copy high performance userspace-kernel-device communication system. A faster write(), essentially (and write is already quite fast, TYVM).
OG.
Have you ever seen a painter or a writer work 9 to 17 weekdays period?
Quality programming has a non-negligible artistic component. I know it's fashionable to try and ignore it, especially at manager level, but then that kind of people do not really care about the quality part either.
OG.
I doubt one can do anything intersting about kernel fault isolation anyway. If you look at linux conceptually, there isn't that much in there:
- device drivers
- memory management
- filesystems
- networking
If a device driver crashes, unless it's usb you're essentially toast (think dma to lalaland, infinitely repeating interrupts...). And usb for funky devices tends to be done in userspace (see scanners with sane).
If a filesystem crashes and it's a primary one you're toast since you can't access programs anymore. Secondary ones can be in userspace (see FUSE).
If the memory management crashes, you're obviously dead.
And if networking crashes, you at least lose all current connections, which can be quite annoying. Tends to be a very, very well tested part of the kernel in today's internet though.
So, well, to the exception of networking which tends to be very stable anyway or dies fast, evrything that a microkernel could recover on crash tends to be doable and often done in userspace in linux. And probably in BSDs too, I just don't know them. So I'm not that sure there is a point to microkernels in practice, especially given their performance and engineering costs.
OG.
But linux _is_ purely monolithic. There is only one address space, and modules link their symbols directly inside the current image. Modules are equivalent to dlopen(), not fork+exec(). There is also no communication interfaces per se. Modules directly call functions or access structures fields. Of course these functions and structures are (mostly) organized in APIs and semi-objects, but that means the internal design is clean, not that it has anything to do with a microkernel.
OG.
Nope, CISC is technically superior for current processors because it allows to pack more instructions in less bytes. And it looks like nowadays a CISC-RISC translator takes less silicon than a bigger L1/L2. Don't underestimate the packing effect of CISC instruction sets, especially vs. RISC-VLIW. That's part of what killed IA-64.
The ability to change the underlying RISC/microcode without changing the CISC front-end is not to be neglected either.
OG.
Unless you don't care about anything post-1980. Dual doesn't help Mame at all, so you end up doing everything on one really puny 200Mhz processor. It *will* suck.
OG.