I agree with other posters who think the suggest feature is not so useful (a live spell checker would had been more handy, could save lots of clicks on the "did you mean" link).
The big deal with Google Suggest has nothing to do with suggestion. The point is that it does live queries on the server without changing currently loaded HTML page. This trick is not very common on web right now. It raises the bar because from now on, as a developper, if I argue with my boss that this sort of gadget is not possible to do on the web, he could answer "Why? Google does it".
Every new HTML user interface goodie is implemented by combining various hacks of ECMAScript/JavaScript, DOM manipulation and specific browser capabilities. There is no clean and standard model underneath this trick. We are patching HTML over HTTP instead of re-designing the web to allow a more suited bi-directional communication of user interface events.
It's not acceptable that in 2004 this appears as a great programming achievement.
Yes, people will expect more responsive Web interfaces but the 1000+ lines of codes necessary to make this work clearly shows that the underneath HTTP+HTML model is inappropriate to handle this kind of functionality. We need something more suited for fine-grain event handling.
It's a product based on the Eclipse patform (not a plugin, more a standalone application).
It's a VoiceXML-oriented IDE. In a nutshell, VoiceXML is a specification that defines how to make a speech recognition (or DTMF) application for the *phone* (not the desktop) using a Web model (that is, exchanging documents over HTTP). The toolkit developped by IBM allows programmers to build call flows graphically, to edit VoiceXML and grammar documents, to manipulate pronounciation dictionnaries and to do other related tasks. I believe this is the part that they are going to give to Eclipse.
The other piece they're going to open is "Reusable Dialog Components", a set of VoiceXML documents (or templates), grammars and code. Theses modules allow programmer to combine different components together in order to build a complete application. I think this part is going to Apache.
Also note that:
Currently, Voice Toolkit for WebSphere Studio is only available on Windows
Although VoiceXML is a growing standard, many area are still uncovered by the spec. AFAIK, this toolkit is not likely to integrate nicely with run-time platforms other than IBM WebSphere Voice Server.
This is just an IDE. You need to buy the runtime (the VoiceXML gateway). I really don't think they will open their speech recognition software (a lot more than a 10M$ investment).
I agree, this is computer dilemma #21: must choose between secure and usable.
Also, nobody mentioned that Windows users are quite different from Linux users. That have different habits, concerns and goals toward their systems. I think that this plays a big role in this phenomenon. Linux users are more technical, no wonder why they don't execute attachments.
I don't share the author's vision on the linux community effect (i.e. everybody helping each other suddently because we're all linuxians). This is utopy.
You are accusing me of wishing violence on Americans. It's not the case. I'd like to see the big-boat going underwater. That's it. I don't want anybody to die.
Your entire nation is scared to death. Just stop feeling threatened. I'm soooooo far from being a menace for USA. You act like a paranoid and that's why US citizens approve any military moves.
While this carrier is a incredible technical achivement, it is one of the most horrible human realization. I want people to live peacefully and that ship is going the other way.
We are millions of people not understanding the object of your pride. You are devoting your professional lives to design and build war-supporting machines. What are you proud of?
I'm amazed to see that people are working day after day on such project. I'm unable to imagine how you can justify yourself.
what? You don't work on the bullets? ah... well in this case: you're clean!
It's sure is a headline but surely not in the happy-happy-joy-joy category. I'd like to see this 5-billion monster sinking.
The consequences for speech recognition are much worse (sure, your hidden Markov model-based systems working with sequences of two or three phonemes are pretty effective, but they'll never be 100% successful in my opinion).
I doubt that anything can be 100% successful given that human perception is not totally error-free. Speech recognition HMM models are based on contextual realizations of phonemes (allophonic model). This takes into account coarticulation. Same technique applies for generation: in-context phonemes are used.
Poor quality of current TTS engine comes from bad concatenation of segments (e.g distortion at jonction). Other problems come from high-level analysis (semantic) and from inappropriate prosody (emphasis, rhythm, intonation).
That is the correct answer. Which seems to be sufficient evidence that whoever thought of this riddle has never actually had sex.;)
yeah... it was too unreal for me. Althought I thought about turning them inside out, I found this to be too risky to be considered safe. Instead, the riddle should have been written with a surgeon, 3 patients and 2 pairs of rubber gloves. But then again...
"In ideal conditions the reviewer was able to twice run through a list of 14 song titles without fail. This included titles with "non-real word" band names like Sum41 and U2."
Don't buy the "it-worked-for-me" argument. Especially with speech-recognition technology. A selective test is not a benchmark.
This speaker-independent technology is based on recognition of phonems. To be able to perform recognition, you first need to translate written entries into sequences of phonems. For example, "Genesis" will become "JH EH1 N AH0 S AH0 S". Usually, this conversion is done by looking up in a phonetic dictionary. When there's a missing entry, a fallback strategy is to perform automatic graphem-to-phonem automatic, i.e. create phonem strings based on lexical structure of a word. This yields poor results for many languages such as english which has unpredictable graphem-to-phonem correspondence. So, either this technology uses a dictionary (within the PC application) or it uses a graphem-to-phonem engine. The problem with dictionary is that it may be HUGE with all the music authors and titles available and it evolves rapidly.
Also, the training is usually done for only one language (sometimes, two). This is called acoustic model training. Each phonem of a given language will be trained in HMMs (Hidden Markov Model). You can only achieve limited results when using words made out of foreign phonemes. "Björk", for instance, will be phonetized "B Y AO1 R K" for english-speaking persons. If you happend to pronounce correctly (i.e. in Icelandic), the engine won't be able to figure it out because the acoustic data is not modeled properly.
I have strong doubts about this gadget because it requires dynamic dictionaries and multi-lingual support. I listen a lot to foreign music. I don't think this toy will work ok for me.
Of course, anybody who really is into security knows every problem mentioned by the document. However, some people do not stay informed on a daily basis. This kind of analysis is useful for neophytes and for people outside of the security domain. Also, as the document mentioned, the idea was to help sysadmin choose which problem to fix first.
Something interesting comes out of this analysis:
-General problems remain present with years. Negligence from the users, programmer and administrators are the cause of all the security problems.
-Unix and Windows problems have basically the same roots: programming errors (buffer overflow, bad input validation) and inadequate trust.
Not mentioned in this article:
-Windows users are less computer-literate than Unix users. This is the major why so much problems occur on Windows (virus, worms, executable mail attachments, etc...).
System security is a very pragmatic issue. Some relatively well-known pratices will increase a lot the security of a network/system. There is always a hole somewhere but removing the well-known ones will make a huge difference.
My provider, Videotron (cable access), is blocking any incoming request to port 80 from the outside. Consequently, my web site is no longer available but it was against the service agreement anyway, so I cannot complain. I still have access to any other services (I have a sshd running).
I've got only 18 nimda attempts yesterday so I must admit that my ISP has taken an appropriate measure. They've started doing that with Code Red and never removed this filter (and they must be very happy with that...).
Makes me remember that a few days ago, in an article about the Pope, in the sentence "May (the Madonna) give comfort and hope to those who are suffering as a result of the tragic terrorist attack..." the word "Madonna" was followed with some yahoo search hyperlinks about the pop singer.
Unfortunateley, they aren't there anymore. Does Yahoo have an automatic link engine that add hyperlinks to some keywords? Or was it the work of our friend?
Another funny story was held on canoe.ca. The title was something like "President Bush called up 50,000 reservists" and beside the article was a photo of Bush on the phone...
I like your comment because you are raising the importance of size and complexity of algorithms.
A higher-level abstraction language, such as Java, allows easy replacements of the strategies. The operative word here is "easy". Although it's possible to implement cache, instance pool and threaded operations in plain old C, it's more complex than in C++ or Java.
Since the most notable optimizations are done by changing algorithms, the "speed" of a language (what it means for you) should not be the primary criteria when choosing a programming language for a project. To speed, I'll prefer functionality, readibility, simplicity, safety and coherence.
Personally, I'm sick of spending too much time on trying to figure out what that C++ compiler message means, what the semantic of that expression and how the linker will find that symbol. I prefer to spend my time on solving the real problem. For this reason, I choose Java for most of my projects. If I were programming games or math-intensive applications, that might be different.
I think we need the ability to run Java apps directly on the desktop. That's not the same thing as running KDE apps written in Java. I'm talking about truly portable apps, not apps written especially for QT or KDE.
This became obvious for me when I used the Java version of ICQ which was not truly integrated with my desktop. I would have liked to switch to "away" state whenever the screensaver would kick in, just like in Windows. The java program cannot be aware of all the desktop properties and event. Maybe there should exist an API for this precise purpose.
IMHO it would be a pity if GNOME decided to "aim low" just because of fear of falling behind the competition. This is open source, where we compete on technical merits, not release schedules or the expectations of share holders.
I think that "aiming low" is a strategy that makes a lot of sense. If I were a GNOME developper, I would prefer having a new version of GNOME containing less changes coming out earlier than something blue six months late. Miguel is proposing a plan that will prevent GNOME to be obsolete at some point. He's also making sure that application will be able to keep up with the changes. He's not pushing the blue sky scenario that much. Think of Blue Sky as the ultimate goal and "Aim Low" as the path.
Many projects depend on GNOME. Miguel is well aware of that and understand that the key to success is to be there at the right time. It is a matter of risk. Not to release something for a long period of time increase the risk. Some projects have choose that path and are doing fine (like Mozilla and KDE) but they had a hard-time. GNOME doesn't need that risk.
A schedule for open-source project... I agree that this is something unusual but for something important like GNOME, we cannot afford to miss that. Or at least, we need to define milestones. You're confusing "necessary delays" and "necessary changes". A good plan would make thoses changes appear gradually and safely. Unplanned delays come from bad planning.
ooh boy, now I'm talking like a project manager...
..threaded and GUI programming, which XP programmers readily admit doesn't work well with the XP methodology.
Frankly, I don't see the problem with threads and XP.
Regarding GUI's, you may have some troubles regarding unit testing. But, that is one aspect of XP. You can gain from using it partially. It is not all-or-nothing.
"[But] this breathtaking vista must be contrasted with the Great Shame of computer science, which is that we don't seem to be able to write software much better as computers get much faster."
I don't get it. How am I supposed to write "much better" software with a faster computer. Did anyone ever believe that "quality of products" and "horsepower" are related?
Slashdot Mirror
"Accio 15 copies!"
The big deal with Google Suggest has nothing to do with suggestion. The point is that it does live queries on the server without changing currently loaded HTML page. This trick is not very common on web right now. It raises the bar because from now on, as a developper, if I argue with my boss that this sort of gadget is not possible to do on the web, he could answer "Why? Google does it".
Every new HTML user interface goodie is implemented by combining various hacks of ECMAScript/JavaScript, DOM manipulation and specific browser capabilities. There is no clean and standard model underneath this trick. We are patching HTML over HTTP instead of re-designing the web to allow a more suited bi-directional communication of user interface events.
It's not acceptable that in 2004 this appears as a great programming achievement.
Yes, people will expect more responsive Web interfaces but the 1000+ lines of codes necessary to make this work clearly shows that the underneath HTTP+HTML model is inappropriate to handle this kind of functionality. We need something more suited for fine-grain event handling.
It's a product based on the Eclipse patform (not a plugin, more a standalone application).
It's a VoiceXML-oriented IDE. In a nutshell, VoiceXML is a specification that defines how to make a speech recognition (or DTMF) application for the *phone* (not the desktop) using a Web model (that is, exchanging documents over HTTP). The toolkit developped by IBM allows programmers to build call flows graphically, to edit VoiceXML and grammar documents, to manipulate pronounciation dictionnaries and to do other related tasks. I believe this is the part that they are going to give to Eclipse.
The other piece they're going to open is "Reusable Dialog Components", a set of VoiceXML documents (or templates), grammars and code. Theses modules allow programmer to combine different components together in order to build a complete application. I think this part is going to Apache.
Also note that:
Currently, Voice Toolkit for WebSphere Studio is only available on Windows
Although VoiceXML is a growing standard, many area are still uncovered by the spec. AFAIK, this toolkit is not likely to integrate nicely with run-time platforms other than IBM WebSphere Voice Server.
This is just an IDE. You need to buy the runtime (the VoiceXML gateway). I really don't think they will open their speech recognition software (a lot more than a 10M$ investment).
I agree, this is computer dilemma #21: must choose between secure and usable.
Also, nobody mentioned that Windows users are quite different from Linux users. That have different habits, concerns and goals toward their systems. I think that this plays a big role in this phenomenon. Linux users are more technical, no wonder why they don't execute attachments.
I don't share the author's vision on the linux community effect (i.e. everybody helping each other suddently because we're all linuxians). This is utopy.
I wish I could.
Excuse me for having moral values.
You are accusing me of wishing violence on Americans. It's not the case. I'd like to see the big-boat going underwater. That's it. I don't want anybody to die.
Your entire nation is scared to death. Just stop feeling threatened. I'm soooooo far from being a menace for USA. You act like a paranoid and that's why US citizens approve any military moves.
While this carrier is a incredible technical achivement, it is one of the most horrible human realization. I want people to live peacefully and that ship is going the other way.
Of all the things you could have said about the man, you have choosen something he's not responsible of.
I don't care if you're 15 years old.
We are millions of people not understanding the object of your pride. You are devoting your professional lives to design and build war-supporting machines. What are you proud of?
I'm amazed to see that people are working day after day on such project. I'm unable to imagine how you can justify yourself.
what? You don't work on the bullets? ah... well in this case: you're clean!
It's sure is a headline but surely not in the happy-happy-joy-joy category. I'd like to see this 5-billion monster sinking.
The consequences for speech recognition are much worse (sure, your hidden Markov model-based systems working with sequences of two or three phonemes are pretty effective, but they'll never be 100% successful in my opinion).
I doubt that anything can be 100% successful given that human perception is not totally error-free. Speech recognition HMM models are based on contextual realizations of phonemes (allophonic model). This takes into account coarticulation. Same technique applies for generation: in-context phonemes are used.
Poor quality of current TTS engine comes from bad concatenation of segments (e.g distortion at jonction). Other problems come from high-level analysis (semantic) and from inappropriate prosody (emphasis, rhythm, intonation).
Great... now that they know, they'll spam me with gifs and jpeg.
That is the correct answer. Which seems to be sufficient evidence that whoever thought of this riddle has never actually had sex. ;)
yeah... it was too unreal for me. Althought I thought about turning them inside out, I found this to be too risky to be considered safe. Instead, the riddle should have been written with a surgeon, 3 patients and 2 pairs of rubber gloves. But then again...
Don't buy the "it-worked-for-me" argument. Especially with speech-recognition technology. A selective test is not a benchmark.
This speaker-independent technology is based on recognition of phonems. To be able to perform recognition, you first need to translate written entries into sequences of phonems. For example, "Genesis" will become "JH EH1 N AH0 S AH0 S". Usually, this conversion is done by looking up in a phonetic dictionary. When there's a missing entry, a fallback strategy is to perform automatic graphem-to-phonem automatic, i.e. create phonem strings based on lexical structure of a word. This yields poor results for many languages such as english which has unpredictable graphem-to-phonem correspondence. So, either this technology uses a dictionary (within the PC application) or it uses a graphem-to-phonem engine. The problem with dictionary is that it may be HUGE with all the music authors and titles available and it evolves rapidly.
Also, the training is usually done for only one language (sometimes, two). This is called acoustic model training. Each phonem of a given language will be trained in HMMs (Hidden Markov Model). You can only achieve limited results when using words made out of foreign phonemes. "Björk", for instance, will be phonetized "B Y AO1 R K" for english-speaking persons. If you happend to pronounce correctly (i.e. in Icelandic), the engine won't be able to figure it out because the acoustic data is not modeled properly.
I have strong doubts about this gadget because it requires dynamic dictionaries and multi-lingual support. I listen a lot to foreign music. I don't think this toy will work ok for me.
but it uses the Perl syntax: it looks like Snoopy swearing.
Of course, anybody who really is into security knows every problem mentioned by the document. However, some people do not stay informed on a daily basis. This kind of analysis is useful for neophytes and for people outside of the security domain. Also, as the document mentioned, the idea was to help sysadmin choose which problem to fix first.
Something interesting comes out of this analysis:
-General problems remain present with years. Negligence from the users, programmer and administrators are the cause of all the security problems.
-Unix and Windows problems have basically the same roots: programming errors (buffer overflow, bad input validation) and inadequate trust.
Not mentioned in this article:
-Windows users are less computer-literate than Unix users. This is the major why so much problems occur on Windows (virus, worms, executable mail attachments, etc...).
System security is a very pragmatic issue. Some relatively well-known pratices will increase a lot the security of a network/system. There is always a hole somewhere but removing the well-known ones will make a huge difference.
My provider, Videotron (cable access), is blocking any incoming request to port 80 from the outside. Consequently, my web site is no longer available but it was against the service agreement anyway, so I cannot complain. I still have access to any other services (I have a sshd running).
I've got only 18 nimda attempts yesterday so I must admit that my ISP has taken an appropriate measure. They've started doing that with Code Red and never removed this filter (and they must be very happy with that...).
Unfortunateley, they aren't there anymore. Does Yahoo have an automatic link engine that add hyperlinks to some keywords? Or was it the work of our friend?
Another funny story was held on canoe.ca. The title was something like "President Bush called up 50,000 reservists" and beside the article was a photo of Bush on the phone...
I like your comment because you are raising the importance of size and complexity of algorithms.
A higher-level abstraction language, such as Java, allows easy replacements of the strategies. The operative word here is "easy". Although it's possible to implement cache, instance pool and threaded operations in plain old C, it's more complex than in C++ or Java.
Since the most notable optimizations are done by changing algorithms, the "speed" of a language (what it means for you) should not be the primary criteria when choosing a programming language for a project. To speed, I'll prefer functionality, readibility, simplicity, safety and coherence.
Personally, I'm sick of spending too much time on trying to figure out what that C++ compiler message means, what the semantic of that expression and how the linker will find that symbol. I prefer to spend my time on solving the real problem. For this reason, I choose Java for most of my projects. If I were programming games or math-intensive applications, that might be different.
well... it was a figure of speech.
one does not need to perform a complex comparative analysis to see the huge functional differences between those standard libraries.
From what I've seen of SLIB, it is not comparable with the Java 2 platform (standard edition) version 1.4. :
Threads
I/O (blocking or non)
Reflection API
Weak references (and the likes)
Networking (including http client, ipv6 support, URLs, datagrams, network interface)
RPC (RMI, CORBA)
Security (permission, keys)
Relational database API (implemented by MANY vendors, you can often *choose* your implementation...)
Text formatting
Data structures (OK, needs functional improvements, I agree)
Useful classes: date, calendar, locale, time zones, currency, timer...
Logging
Regexp
Zip
Preferences
Accessibility
Imaging API
Naming API (directories, ldap)
Printing API
GUI API (awt, Swing)
XML parser + DOM + SAX
XSLT
Components (java beans)
Sound
Should I continue with enterprise edition?
I think no langage can compete with Java in terms of API richness and uniformity.
tr N-ZA-Mn-za-m A-MN-Za-mn-z < myfile
This became obvious for me when I used the Java version of ICQ which was not truly integrated with my desktop. I would have liked to switch to "away" state whenever the screensaver would kick in, just like in Windows. The java program cannot be aware of all the desktop properties and event. Maybe there should exist an API for this precise purpose.
IMHO it would be a pity if GNOME decided to "aim low" just because of fear of falling behind the competition. This is open source, where we compete on technical merits, not release schedules or the expectations of share holders.
I think that "aiming low" is a strategy that makes a lot of sense. If I were a GNOME developper, I would prefer having a new version of GNOME containing less changes coming out earlier than something blue six months late. Miguel is proposing a plan that will prevent GNOME to be obsolete at some point. He's also making sure that application will be able to keep up with the changes. He's not pushing the blue sky scenario that much. Think of Blue Sky as the ultimate goal and "Aim Low" as the path.
Many projects depend on GNOME. Miguel is well aware of that and understand that the key to success is to be there at the right time. It is a matter of risk. Not to release something for a long period of time increase the risk. Some projects have choose that path and are doing fine (like Mozilla and KDE) but they had a hard-time. GNOME doesn't need that risk.
A schedule for open-source project... I agree that this is something unusual but for something important like GNOME, we cannot afford to miss that. Or at least, we need to define milestones. You're confusing "necessary delays" and "necessary changes". A good plan would make thoses changes appear gradually and safely. Unplanned delays come from bad planning.
ooh boy, now I'm talking like a project manager...
..threaded and GUI programming, which XP programmers readily admit doesn't work well with the XP methodology.
Frankly, I don't see the problem with threads and XP.
Regarding GUI's, you may have some troubles regarding unit testing. But, that is one aspect of XP. You can gain from using it partially. It is not all-or-nothing.
I don't get it. How am I supposed to write "much better" software with a faster computer. Did anyone ever believe that "quality of products" and "horsepower" are related?