Version 4 and still no Unicode? Pathetic...
on
MySQL 4.0 Released
·
· Score: 1
They do claim to have added a new "character set" in order to handle German sort order: "latin_de". What?? You need a special, non-standard *character set* in order to handle German collation?
What an architecture that must be. Talk about amateurish....
"killing hundreds of thousands both thru actions and inaction"
For every bloody conflict on earth, there are those who demand that the US help side A (action), those who demand that the US help side B (different action), and those who demand that the US stay out of it (inaction). No matter which option we choose, people will die, and we will be held responsible for those deaths and hated for it. When we act, we're simultaneously responsible on one side for acting, and on the other for not acting enough.
I suppose the right answer is that the US should do exactly what the rest of mankind agree unanimously that we should do. Oh, yeah, if the rest of the world were unanimous, there wouldn't be any conflict to be unanimous about.
BTW, I don't agree with US actions in many cases, and I don't attempt to justify actions that *I* consider wrong. Still, I have few illusions that if the US always did the "right thing" by my judgment, everyone would like us. Not a chance. I've seen too many cases of people furious that the US "allows" them to be abused by their government, and then furious at the US for "attacking" their country if we try to stop their abusive government.
Most countries can avoid all blame by not doing anything, but the US doesn't usually have that option. We get blamed by millions around the world for the brutality of our "inaction". The US is the only country whose inaction is counted as an action by most of the world.
"letting much of the world suffer without electricity, food, water...."
Yes, yes, this is just one of our weapons of mass destruction. Despite having the highest rate of charitable contribution (per capita) of any country on earth, there are still children who starve to death while we buy videogames -- so *we* killed them. Did the Norwegians also kill them? Of course not, silly. They can buy videogames. *American* inaction is the only inaction that will be condemned worldwide, often as "genocide".
"The root of all violence is violence". Yes, yes, and the KKK, the Mafia, and the Taliban are just misunderstood, and you "don't wish them to feel shame".
Clearly you feel none.
As for "do you have any concept of the conditions in Kuwait now?...I don't." No kidding. Best to just assume that they have problems of some sort and *we* are responsible for them.
Are you implying that if a person has "strength of character", he becomes invincible? Or perhaps just loved by all, so he won't be hurt by anyone? Are all crime victims suffering from some lack of character or perhaps an unwillingness to help that would have saved them? Are there no criminals, only reasonable folks murdering people who deserve it due to a lack of character?
I find your comments both insulting and profoundly ignorant.
I just came from their site. I just read the FAQ. They reiterated the point in several of the answers: "no, you have to buy the pro or enterprise version if you want to sell on Win32", "no the free version is not even available on Win32, only the pro or enterprise version," "no, you *can't* even develop for free on Win32 and then pay for a license when you decide to start selling, the Win32 license requires you to pay us, even for development...."
They couldn't be much clearer. Or, are you saying that their Website is wrong?
Two cartoonish caricatures for the price of one
on
Bert Is Evil
·
· Score: 2, Funny
The one is a caricature of medieval backwardness, like a character from Monty Python's Search for the Holy Grail. The other is more modern and doesn't always hold his finger up when he talks.
Well, I'm an American, but I like you Brits, so might I suggest an alternative? Buy the book, read it, then donate it to your local UK public library, and let them use their limited budgets for other things?
The best "revenge" for this attack is to shake it off and go forward as if nothing happened. If a mosquito stings you, you don't drive your car into a tree. You accept a little itchy bite, you swat the mosquito *if it's convenient for you*, but your car doesn't swerve an inch.
We do need to close any newly revealed vulnerabilities. We should also try to identify the perpetrators and perhaps kill them, if it's convenient for us.
I'm not advocating forgiveness here. I'm advocating ignoring, which is the worst punishment you can give a terrorist. I'm saying that the purpose of terrorism is to leverage small resources into big effects on your target. The whole point is try to cause huge trouble for America overall, not to kill a tiny fraction of 1% of Americans. Perhaps they can get America to overreact in all sorts of ways, bringing more nations over to the "enemies of America" camp to join the perpetrators, messing up the economy, etc.
I say we don't let them have their desired outcome. We reduce the effect of their actions to the deaths and injuries they actually caused, we clean up, close up some vulnerabilities, we swat them if it isn't too much effort to be worth, but we move on basically as if it never happened.
It's very important that we not let terrorists pull our strings. Certainly, closing up newly discovered vulnerabilities is reasonable -- depending on how it's done -- but the best "revenge" really will be to not be swerved an inch by this attack.
Part of the problem is the nature of programming languages.
A tool like C++ would never be tolerated in the world of bridge building. Too prone to invisible screwups.
Eiffel is an example of the sort of tool bridge builders might use. Eiffel will never succeed, though, because of the perverse nature of the programming tools market.
1) Programmers love the mental challenge of mastering systems of arcane, complex rules. It's a macho thing. They don't automatically reject monstrosities like C++, as bridge builders would, because to do so makes them sound wimpy. ("I don't know what you're talking about, it's not hard for *me*....")
2) Also, if programmers were to lose their careers over a single "crasher" bug, as bridge builders would, even they would reject C++ and go for something like an ubersafe Eiffel.
3) There's tremendous language inertia in programming languages (though not as much as in bridge building technologies.) There may be thousands of programming languages out there, but most are virtually off-limits for practical projects. That's why things like C++ grow so much tangled hair. It's easier to learn one more round of gotchas than to learn a whole new language, buy and master all new tools, and change jobs to a company using the new language.
If I created a really great new language, would it become popular? I'll take the 1 in a thousand risk of being wrong and state flatly "No."
As long as we're programming with the languages we use, we'll have the level of bugs we have.
I was a passionate fan of real science fiction. I could learn about science and experience some aspects of what our real future might end up being like because of real science. I wanted to learn things that could be really useful, not waste mental CPU cycles learning the goofy rules of some enchanted tree or some such thing.
I guess the market for fictional speculations on the fascinating, even astounding, implications of real science and technology is just too small compared to the market for superstitious nonsense, which is never-ending.
Polluting science fiction with dwarves with magic rings, dragons and enchanted swords and all that nonsense is like making the astronomy category into astronomy/astrology.
If Americans say "don't do terrible things to people in your country", they're blasted for "interfering in internal affairs". Aren't those Americans terrible?
If they say, "what other people do in their own country isn't our business", they're blasted for being so provincial. "You must be American right?", accuses the poster.
Yes, Americans are just terrible. Regardless of what they do (including nothing), there are several million people in the world who will immediately hate them for it.
Every year, I hear half a dozen earth shaking announcements -- half of them from IBM -- of major flat screen breakthroughs that should be hitting the shelves in "a couple of years". Yet year after year we go on with LCDs that just get a little better and a little cheaper each year.
A major (say 2 order of magnitude) change in flat screen benefit/cost ratio would have a huge impact. With the evolutionary changes we have now, we'll get there in a decade or so, but where did all those "revolutionary" improvements go?
If you *must know how a computer works at a fundamental level*, then assembler isn't it. I had a microcode class that really helped me to understand about assembler optimization. You can make the argument that you can't really understand level N unless you understand level N-1, recursively all the way to quantum physics.
Or why not start at the other end of the abstraction stack? Start with cognitive pyschology, perception, human-computer interaction, and the identification of human needs -- then you figure out an approach that best meets people's needs, which would lead to how to choose the right software tools and approach for any particular case.
For a CS class, I wouldn't start at either extreme. Choosing the right level of abstraction is important, and the answer isn't just automatically one below what the other guy suggests.
I think CS classes should start by making it clear that the point of it all is to create useful stuff for real people. Teach them what they need to know to get started ASAP doing so, and fill in the details with later classes.
1) The conversion tables you use depend on your needs. The problem is not in the nature of Unicode, but in the nature of the script system itself and the slight differences in opinion of the experts who have designed all the common CJK character sets. It's quite similar to debates among professors in Asia regarding proper stroke order or even number of strokes in characters. No two experts answer exactly the same for all characters. Without Unicode, there are various alternative mappings among popular CJK character sets. Conversions to and from Unicode seem to have fewer problems than the others. What would you suggest? Create a new character set and declare a set of maps as standard? As soon as you do, a dozen other parties will make slight adjustments to reflect their views and publish "corrected" maps. It's not Unicode that is the problem. And, by the way, I have converted megabytes of electronic text of various sorts, and working with Unicode has been bliss compared to legacy CJK character sets.
2) No, I admitted that CJK unification has one disadvantage but several nice advantages. Not unifying would reverse that. I can't think of a system that would have only advantages. Can you? "The Japanese" at JIS couldn't, which is why they essentially invented CJK unification several years before the Unicode Consortium was created. Not only have I been to a lot of Japanese discussions of Unicode, but my job has been to deliver the Unicode support demanded by our Japanese customers in products that I *guarantee* you would recognize. "Paid by the Unicode Consortium"? The average 7-Eleven has a bigger annual budget than the Unicode Consortium. What are you smoking?
3) Why are there so many different tools if a hammer is so great?
And, if Unicode lacks the characters to fully cover some writing system, please identify the missing characters and submit your data as scores of individuals and government bodies have done and continue to do. Surely you'll be able to find quite a few examples of characters missing from Unicode 3.1 that you need, right?
ISO 10646 itself is now restricted to the range described by UTF-32. ISO has agreed to close down the state space and to never define any code points that can't be reached by UTF-16 surrogates, which is where the UTF-32 boundary came from. UCS-4 is now obsolete, even at ISO.
Far more "technical people in Japan" are in favor of Unicode than are opposed to it, and the percentage opposed appears to shrink every month as the feared "dangers" somehow don't materialize but the benefits do.
Re: your little list...
-- The conversion tables differ only very slightly, and *almost* everyone uses the tables at the Unicode.org site, either directly or by calling converters in the OS. Still, there are potential tiny differences, as you see in all cases of matching massive character sets across borders, though in the case of Unicode the problem is much smaller.
-- CJK Unification has the disadvantage that you can't be certain of picking a font that is guaranteed to be acceptable based on the code point alone. In practice, this rarely turns out to be much of a problem, but it can happen. On the other hand, there are some nice benefits of the unification that more than make up for that one problem. The problem you cite isn't a problem. The character distinctions that the Japanese want to make have been made by the Japanese in the JIS X character sets. Those distinctions were then directly ported over to Unicode.
-- Certainly you're referring to UTF-16 surrogates, but calling it "Unicode" to make the problem sound larger. In fact, UTF-8 is "Unicode", too. It's the greatest method for text data exchange ever created, and it has no 64K issue, no endianness issue, is self-synchronizing (if you miss a byte in a stream, only one character [code point] is lost), and many other nice features. The greatest of all is, of course, that it can encode virtually every language in the world in the same encoding.
He had to connect to the phone to set the clock, because Tivo wouldn't let him manually set it. While connected to the phone, the unit called "home" in the middle of the night, and downloaded a new OS -- one that removed features that had existed previously, features that he had paid for.
When he bought the product he made a choice to trade a certain amount of money for certain features. Tivo, after the fact, disabled some of those features. He didn't get to unilaterally retract some of the money he paid them after they delivered his Tivo, did he? Why should they be able to unilaterally retract features?
"They're a business" is not an answer. Busineses don't get special treatment under contract law. They're just parties, like individuals are.
You should be able to scroll the display without going somewhere far away and fumbling around to hit the small scroll button.
Mouse wheels are the best idea since the mouse itself. They let you scroll without taking your eyes, or your virtual hand (mouse pointer), off of your work. I can't imagine doing without it. I'm really annoyed by applications that can't be scrolled by simply passing the mouse pointer over the region I'm looking at and rolling the wheel. Having to go hunt down the proper scroll control on the screen and hit it with the mouse seems like a huge nuisance now that we have something better.
Well, you pretty much exemplify his point. Learning about symlinks really doesn't take much time -- assuming you've already learned countless other little things first. None of these things take much time by themselves, but there are thousands of equally useful things in the *nix world that your symlink argument could apply to. The time adds up. Most Slashdotters have learned mountains of details by spending massive amounts of time at their computers engaging in activities that were partly productive and partly just figuring out how to do things with their computer.
A doctor or lawyer should not have to stop their doctorin' and lawyerin' to learn about details like symlinks in order to qualify as non-idiots to runnynosed geeks who can't tell a platelet from a patella. They have better things to do with their time. Many of them "refuse to learn" for the same reason that they refuse to learn how to repair their own automobile engines: it's a low value-added activity best subcontracted to others.
Somebody needs to know the details, but then a high-value added activity for *them* would be to encapsulate those details behind a UI that is so clever that it amplifies the power of doctors and lawyers instead of dissipating it on trivia.
No karma points for a "me, too", but *me too*. Everything is going Unicode, and UTF-8 is the right form to use for most data that is meant to be passed between systems. IETF has already said that it will be the standard encoding for all *future* protocols. Okay, let's do it well. I would rather see a lot of systems start ramming through UTF-8 upgrades, even when they break some things for a while, than to see lots of cruft layered on obsolete standards to bridge the gap between the obsolete standards and UTF-8. A quick, rocky transition would be better at getting people motivated to do things in UTF-8. Viva UTF-8!
Unless I'm misreading the spec, XML-RPC is limited to ASCII text (a tiny subset of UTF-8). Talk about primitive! Now, let's see. That means I could use the "worldwide" Internet to create distributed apps that support English, Hawaiian, Indonesian, and Swahili. All other languages would require SOAP, which uses the full UTF-8 strings that are standard with XML. No wonder large corporations required a version for grownups: SOAP. ASCII just doesn't cut it anymore, especially on the Internet. Unicode is the only real option for serious developers.
I really hope that all parties working on various aspects of Linux & *BSD will make a full conversion to Unicode ASAP. Then they need to insist that all GUI text widgets and command lines be capable of rendering any combination of languages/scripts. I don't mean that everything has to work in version 1, just that complete globalization of all functionality is assumed to be the target from the start, so the proper foundation is laid. None of the usual, "we'll think about internationalization *after* we've carved the architecture in stone."
I want to be able to cut mixed Hebrew, Japanese, and French text (or anything else representable by Unicode) from a GUI widget running on one distribution and paste it to the command line of a CLI app running via telnet on another machine running another distribution, with no doubts that it will work. From the perspective of all the apps on all those disties, it should be as smooth as ASCII is today.
Then, if they want to specialize ("Ours comes with ten alternative Japanese input methods instead of the usual two or three!") that's great.
One thing unix people seem not to realize is that the look of Windows (and Mac before it) is constrained by the need to be usable on very low quality monitors and by people with limited vision. (On unix, users of low-quality monitors tend to just stick to the CLI.) Both companies did a great deal of research on usability of this sort, and it's a professional touch that is seldom recognized by GUI amateurs. Black checkmarks against white backgrounds, for example, are designed to be visible on 2-color monitors, or by people with very poor eyesight. "Graceful degradation".
It's not surprising that the platform that expresses the greatest scorn for the value of GUIs shows the least understanding of them. Nevertheless, Linux GUIs are growing up. Clearly, people with real GUI expertise are joining the kernel experts who started this new platform, and I have every reason to hope that eventually Linux may boast the best GUIs of any platform. (I say this because I think Win & Mac really need to stick with a single, consistent GUI, while Linux can fork into the OS for all sorts of devices with different constraints and different high-quality GUIs for different users with different needs.)
Slashdot Mirror
They do claim to have added a new "character set" in order to handle German sort order: "latin_de". What?? You need a special, non-standard *character set* in order to handle German collation?
What an architecture that must be. Talk about amateurish....
"killing hundreds of thousands both thru actions and inaction"
For every bloody conflict on earth, there are those who demand that the US help side A (action), those who demand that the US help side B (different action), and those who demand that the US stay out of it (inaction). No matter which option we choose, people will die, and we will be held responsible for those deaths and hated for it. When we act, we're simultaneously responsible on one side for acting, and on the other for not acting enough.
I suppose the right answer is that the US should do exactly what the rest of mankind agree unanimously that we should do. Oh, yeah, if the rest of the world were unanimous, there wouldn't be any conflict to be unanimous about.
BTW, I don't agree with US actions in many cases, and I don't attempt to justify actions that *I* consider wrong. Still, I have few illusions that if the US always did the "right thing" by my judgment, everyone would like us. Not a chance. I've seen too many cases of people furious that the US "allows" them to be abused by their government, and then furious at the US for "attacking" their country if we try to stop their abusive government.
Most countries can avoid all blame by not doing anything, but the US doesn't usually have that option. We get blamed by millions around the world for the brutality of our "inaction". The US is the only country whose inaction is counted as an action by most of the world.
"letting much of the world suffer without electricity, food, water...."
Yes, yes, this is just one of our weapons of mass destruction. Despite having the highest rate of charitable contribution (per capita) of any country on earth, there are still children who starve to death while we buy videogames -- so *we* killed them. Did the Norwegians also kill them? Of course not, silly. They can buy videogames. *American* inaction is the only inaction that will be condemned worldwide, often as "genocide".
"The root of all violence is violence". Yes, yes, and the KKK, the Mafia, and the Taliban are just misunderstood, and you "don't wish them to feel shame".
Clearly you feel none.
As for "do you have any concept of the conditions in Kuwait now?...I don't." No kidding. Best to just assume that they have problems of some sort and *we* are responsible for them.
Are you implying that if a person has "strength of character", he becomes invincible? Or perhaps just loved by all, so he won't be hurt by anyone? Are all crime victims suffering from some lack of character or perhaps an unwillingness to help that would have saved them? Are there no criminals, only reasonable folks murdering people who deserve it due to a lack of character?
I find your comments both insulting and profoundly ignorant.
I just came from their site. I just read the FAQ. They reiterated the point in several of the answers: "no, you have to buy the pro or enterprise version if you want to sell on Win32", "no the free version is not even available on Win32, only the pro or enterprise version," "no, you *can't* even develop for free on Win32 and then pay for a license when you decide to start selling, the Win32 license requires you to pay us, even for development...."
They couldn't be much clearer. Or, are you saying that their Website is wrong?
The one is a caricature of medieval backwardness, like a character from Monty Python's Search for the Holy Grail. The other is more modern and doesn't always hold his finger up when he talks.
Beyond that....
Well, I'm an American, but I like you Brits, so might I suggest an alternative? Buy the book, read it, then donate it to your local UK public library, and let them use their limited budgets for other things?
Just my two cent^H^H^H^H^H^tuppence.
The best "revenge" for this attack is to shake it off and go forward as if nothing happened. If a mosquito stings you, you don't drive your car into a tree. You accept a little itchy bite, you swat the mosquito *if it's convenient for you*, but your car doesn't swerve an inch.
We do need to close any newly revealed vulnerabilities. We should also try to identify the perpetrators and perhaps kill them, if it's convenient for us.
I'm not advocating forgiveness here. I'm advocating ignoring, which is the worst punishment you can give a terrorist. I'm saying that the purpose of terrorism is to leverage small resources into big effects on your target. The whole point is try to cause huge trouble for America overall, not to kill a tiny fraction of 1% of Americans. Perhaps they can get America to overreact in all sorts of ways, bringing more nations over to the "enemies of America" camp to join the perpetrators, messing up the economy, etc.
I say we don't let them have their desired outcome. We reduce the effect of their actions to the deaths and injuries they actually caused, we clean up, close up some vulnerabilities, we swat them if it isn't too much effort to be worth, but we move on basically as if it never happened.
We're in control, not them.
It's very important that we not let terrorists pull our strings. Certainly, closing up newly discovered vulnerabilities is reasonable -- depending on how it's done -- but the best "revenge" really will be to not be swerved an inch by this attack.
Part of the problem is the nature of programming languages.
A tool like C++ would never be tolerated in the world of bridge building. Too prone to invisible screwups.
Eiffel is an example of the sort of tool bridge builders might use. Eiffel will never succeed, though, because of the perverse nature of the programming tools market.
1) Programmers love the mental challenge of mastering systems of arcane, complex rules. It's a macho thing. They don't automatically reject monstrosities like C++, as bridge builders would, because to do so makes them sound wimpy. ("I don't know what you're talking about, it's not hard for *me*....")
2) Also, if programmers were to lose their careers over a single "crasher" bug, as bridge builders would, even they would reject C++ and go for something like an ubersafe Eiffel.
3) There's tremendous language inertia in programming languages (though not as much as in bridge building technologies.) There may be thousands of programming languages out there, but most are virtually off-limits for practical projects. That's why things like C++ grow so much tangled hair. It's easier to learn one more round of gotchas than to learn a whole new language, buy and master all new tools, and change jobs to a company using the new language.
If I created a really great new language, would it become popular? I'll take the 1 in a thousand risk of being wrong and state flatly "No."
As long as we're programming with the languages we use, we'll have the level of bugs we have.
I was a passionate fan of real science fiction. I could learn about science and experience some aspects of what our real future might end up being like because of real science. I wanted to learn things that could be really useful, not waste mental CPU cycles learning the goofy rules of some enchanted tree or some such thing.
I guess the market for fictional speculations on the fascinating, even astounding, implications of real science and technology is just too small compared to the market for superstitious nonsense, which is never-ending.
Polluting science fiction with dwarves with magic rings, dragons and enchanted swords and all that nonsense is like making the astronomy category into astronomy/astrology.
It's just another example of "dumbing down".
If Americans say "don't do terrible things to people in your country", they're blasted for "interfering in internal affairs". Aren't those Americans terrible?
If they say, "what other people do in their own country isn't our business", they're blasted for being so provincial. "You must be American right?", accuses the poster.
Yes, Americans are just terrible. Regardless of what they do (including nothing), there are several million people in the world who will immediately hate them for it.
Every year, I hear half a dozen earth shaking announcements -- half of them from IBM -- of major flat screen breakthroughs that should be hitting the shelves in "a couple of years". Yet year after year we go on with LCDs that just get a little better and a little cheaper each year.
A major (say 2 order of magnitude) change in flat screen benefit/cost ratio would have a huge impact. With the evolutionary changes we have now, we'll get there in a decade or so, but where did all those "revolutionary" improvements go?
Now here's a new screen saver market for you....
If you *must know how a computer works at a fundamental level*, then assembler isn't it. I had a microcode class that really helped me to understand about assembler optimization. You can make the argument that you can't really understand level N unless you understand level N-1, recursively all the way to quantum physics.
Or why not start at the other end of the abstraction stack? Start with cognitive pyschology, perception, human-computer interaction, and the identification of human needs -- then you figure out an approach that best meets people's needs, which would lead to how to choose the right software tools and approach for any particular case.
For a CS class, I wouldn't start at either extreme. Choosing the right level of abstraction is important, and the answer isn't just automatically one below what the other guy suggests.
I think CS classes should start by making it clear that the point of it all is to create useful stuff for real people. Teach them what they need to know to get started ASAP doing so, and fill in the details with later classes.
1) The conversion tables you use depend on your needs. The problem is not in the nature of Unicode, but in the nature of the script system itself and the slight differences in opinion of the experts who have designed all the common CJK character sets. It's quite similar to debates among professors in Asia regarding proper stroke order or even number of strokes in characters. No two experts answer exactly the same for all characters. Without Unicode, there are various alternative mappings among popular CJK character sets. Conversions to and from Unicode seem to have fewer problems than the others. What would you suggest? Create a new character set and declare a set of maps as standard? As soon as you do, a dozen other parties will make slight adjustments to reflect their views and publish "corrected" maps. It's not Unicode that is the problem. And, by the way, I have converted megabytes of electronic text of various sorts, and working with Unicode has been bliss compared to legacy CJK character sets.
2) No, I admitted that CJK unification has one disadvantage but several nice advantages. Not unifying would reverse that. I can't think of a system that would have only advantages. Can you? "The Japanese" at JIS couldn't, which is why they essentially invented CJK unification several years before the Unicode Consortium was created. Not only have I been to a lot of Japanese discussions of Unicode, but my job has been to deliver the Unicode support demanded by our Japanese customers in products that I *guarantee* you would recognize. "Paid by the Unicode Consortium"? The average 7-Eleven has a bigger annual budget than the Unicode Consortium. What are you smoking?
3) Why are there so many different tools if a hammer is so great?
And, if Unicode lacks the characters to fully cover some writing system, please identify the missing characters and submit your data as scores of individuals and government bodies have done and continue to do. Surely you'll be able to find quite a few examples of characters missing from Unicode 3.1 that you need, right?
ISO 10646 itself is now restricted to the range described by UTF-32. ISO has agreed to close down the state space and to never define any code points that can't be reached by UTF-16 surrogates, which is where the UTF-32 boundary came from. UCS-4 is now obsolete, even at ISO.
Far more "technical people in Japan" are in favor of Unicode than are opposed to it, and the percentage opposed appears to shrink every month as the feared "dangers" somehow don't materialize but the benefits do.
Re: your little list...
-- The conversion tables differ only very slightly, and *almost* everyone uses the tables at the Unicode.org site, either directly or by calling converters in the OS. Still, there are potential tiny differences, as you see in all cases of matching massive character sets across borders, though in the case of Unicode the problem is much smaller.
-- CJK Unification has the disadvantage that you can't be certain of picking a font that is guaranteed to be acceptable based on the code point alone. In practice, this rarely turns out to be much of a problem, but it can happen. On the other hand, there are some nice benefits of the unification that more than make up for that one problem. The problem you cite isn't a problem. The character distinctions that the Japanese want to make have been made by the Japanese in the JIS X character sets. Those distinctions were then directly ported over to Unicode.
-- Certainly you're referring to UTF-16 surrogates, but calling it "Unicode" to make the problem sound larger. In fact, UTF-8 is "Unicode", too. It's the greatest method for text data exchange ever created, and it has no 64K issue, no endianness issue, is self-synchronizing (if you miss a byte in a stream, only one character [code point] is lost), and many other nice features. The greatest of all is, of course, that it can encode virtually every language in the world in the same encoding.
He had to connect to the phone to set the clock, because Tivo wouldn't let him manually set it. While connected to the phone, the unit called "home" in the middle of the night, and downloaded a new OS -- one that removed features that had existed previously, features that he had paid for.
When he bought the product he made a choice to trade a certain amount of money for certain features. Tivo, after the fact, disabled some of those features. He didn't get to unilaterally retract some of the money he paid them after they delivered his Tivo, did he? Why should they be able to unilaterally retract features?
"They're a business" is not an answer. Busineses don't get special treatment under contract law. They're just parties, like individuals are.
You should be able to scroll the display without going somewhere far away and fumbling around to hit the small scroll button.
Mouse wheels are the best idea since the mouse itself. They let you scroll without taking your eyes, or your virtual hand (mouse pointer), off of your work. I can't imagine doing without it. I'm really annoyed by applications that can't be scrolled by simply passing the mouse pointer over the region I'm looking at and rolling the wheel. Having to go hunt down the proper scroll control on the screen and hit it with the mouse seems like a huge nuisance now that we have something better.
Well, you pretty much exemplify his point. Learning about symlinks really doesn't take much time -- assuming you've already learned countless other little things first. None of these things take much time by themselves, but there are thousands of equally useful things in the *nix world that your symlink argument could apply to. The time adds up. Most Slashdotters have learned mountains of details by spending massive amounts of time at their computers engaging in activities that were partly productive and partly just figuring out how to do things with their computer.
A doctor or lawyer should not have to stop their doctorin' and lawyerin' to learn about details like symlinks in order to qualify as non-idiots to runnynosed geeks who can't tell a platelet from a patella. They have better things to do with their time. Many of them "refuse to learn" for the same reason that they refuse to learn how to repair their own automobile engines: it's a low value-added activity best subcontracted to others.
Somebody needs to know the details, but then a high-value added activity for *them* would be to encapsulate those details behind a UI that is so clever that it amplifies the power of doctors and lawyers instead of dissipating it on trivia.
No karma points for a "me, too", but *me too*. Everything is going Unicode, and UTF-8 is the right form to use for most data that is meant to be passed between systems. IETF has already said that it will be the standard encoding for all *future* protocols. Okay, let's do it well. I would rather see a lot of systems start ramming through UTF-8 upgrades, even when they break some things for a while, than to see lots of cruft layered on obsolete standards to bridge the gap between the obsolete standards and UTF-8. A quick, rocky transition would be better at getting people motivated to do things in UTF-8. Viva UTF-8!
xml-rpc requires that all strings be 7-bit ASCII. Pretty dumb. Few languages can get by with such a pitiful character repertoire.
Unless I'm misreading the spec, XML-RPC is limited to ASCII text (a tiny subset of UTF-8). Talk about primitive! Now, let's see. That means I could use the "worldwide" Internet to create distributed apps that support English, Hawaiian, Indonesian, and Swahili. All other languages would require SOAP, which uses the full UTF-8 strings that are standard with XML. No wonder large corporations required a version for grownups: SOAP. ASCII just doesn't cut it anymore, especially on the Internet. Unicode is the only real option for serious developers.
I really hope that all parties working on various aspects of Linux & *BSD will make a full conversion to Unicode ASAP. Then they need to insist that all GUI text widgets and command lines be capable of rendering any combination of languages/scripts. I don't mean that everything has to work in version 1, just that complete globalization of all functionality is assumed to be the target from the start, so the proper foundation is laid. None of the usual, "we'll think about internationalization *after* we've carved the architecture in stone."
I want to be able to cut mixed Hebrew, Japanese, and French text (or anything else representable by Unicode) from a GUI widget running on one distribution and paste it to the command line of a CLI app running via telnet on another machine running another distribution, with no doubts that it will work. From the perspective of all the apps on all those disties, it should be as smooth as ASCII is today.
Then, if they want to specialize ("Ours comes with ten alternative Japanese input methods instead of the usual two or three!") that's great.
(And, yes, I've heard of Pango. Thank you, Owen!)
One thing unix people seem not to realize is that the look of Windows (and Mac before it) is constrained by the need to be usable on very low quality monitors and by people with limited vision. (On unix, users of low-quality monitors tend to just stick to the CLI.) Both companies did a great deal of research on usability of this sort, and it's a professional touch that is seldom recognized by GUI amateurs. Black checkmarks against white backgrounds, for example, are designed to be visible on 2-color monitors, or by people with very poor eyesight. "Graceful degradation".
It's not surprising that the platform that expresses the greatest scorn for the value of GUIs shows the least understanding of them. Nevertheless, Linux GUIs are growing up. Clearly, people with real GUI expertise are joining the kernel experts who started this new platform, and I have every reason to hope that eventually Linux may boast the best GUIs of any platform. (I say this because I think Win & Mac really need to stick with a single, consistent GUI, while Linux can fork into the OS for all sorts of devices with different constraints and different high-quality GUIs for different users with different needs.)