Um.. well, I don't know about you, but if I were running a site entitled "LinuxHQ", I might at least consider it a good idea to do it on a Linux box, if only for the sake of credibility. If he's running it on a remote host, sure, no problem - but you don't see netbsd.org running on Linux, do you? Or openbsd.org? Or sun.com, for that matter? Perhaps you've heard the word "advocacy"? (As opposed to "moronic flaming", which seems to be what you're into.)
And as for "'tude", I think you've got more than enough for both of us...
Once again, you're missing my point. Unicode is NOT AN IMPROVEMENT over present schemes for CJK encoding, and in some areas introduces new problems.
You say that JIS has been sufficient for all but the rarest applications. That's totally incorrect. JIS has been insufficient for any serious work, resulting in a wide variety of incompatible workarounds. Unicode provides yet another woefully insufficient solution that will lead to yet more workarounds (and I include surrogate pairs in this). You say that you're agnostic about surrogates. You work with CJK, and yet you don't care that what the surrogate system does to Unicode is almost exactly what SJIS did to 8-bit characters? SJIS is the worst of the commonly-used Japanese encodings, yet the UTC chose the same path. Surrogate characters are an ugly solution to a problem that should never have happened, but they are the only solution proposed by the UTC. They're a patchup job to a coding scheme that was not properly thought out to begin with.
You ignore the proliferation of conversion tables from JIS to Unicode, and the fact that JIS to Unicode is not reversible. Any data that is converted to Unicode is stuck in Unicode; you can't even be sure which conversion table was used, meaning it's impossible to know whether a particular Unicode version of a document matches any other encoding.
You dismiss Japanese characters not included in Unicode as "spelling mistakes". The spelling used by Shakespeare differed greatly from modern spelling; does that mean his work was full of spelling mistakes? What if Unicode forced English scholars to use a particular spelling? They'd have been up in arms in a second. Yet, this is almost exactly what Unicode (and other encoding systems, to a certain extent) have done to CJK. It has been impossible to convert historical documents to digital form because of the limitations of present encoding systems - yet Unicode, rather than trying to solve these problems, has added greater complexity without providing a full solution. The UTC had a shot at getting it right, and they blew it. They refuse to acknowledge that, and as a result, the CJK-using countries will suffer. You talk about how the large database companies support Unicode "to address a global market". Rubbish. They support Unicode because it allows them to say that their software handles i18n. This is most likely the worst part of Unicode - it prevents better systems from having a fair chance, in that Western companies think that by supporting Unicode, they automatically gain entrance to non-Western markets. Because of the UTC's shortsightedness, nobody else can do anything about i18n without being told "Well, Unicode support is enough". It's not enough, and in its current form it never will be.
"I work in CJK computing, and I speak all three languages. I use a Unicode-based machine to read all three. I assure you that I have none of the difficulties you describe."
I speak and read two out of three, and I work at a publishing company that handles all three. You obviously don't do DTP. DTP is not presently practical under Unicode; give it a try sometime and you'll see what I mean.
"Someone working in just one of those languages would have it even easier. You're not going to get hit in the face by some horrible Chinese font if you are trying to read Japanese on a Japanese-only machine."
I didn't say that you would; what I said was that what the Unicode standard calls the same character can actually be a character that appears superficially similar (but not necessarily) but has a completely different meaning depending on the language.
To quote from the Unicode.org home page: "The design of Unicode is based on the simplicity and consistency of ASCII, but goes far beyond ASCII's limited ability to encode only the Latin alphabet. The Unicode Standard provides the capacity to encode all of the characters used for the written languages of the world. It uses a 16-bit encoding that provides code points for more than 65,000 characters. To keep character coding simple and efficient, the Unicode Standard assigns each character a unique 16-bit value, and does not use complex modes or escape codes."
This statement alone is enough to condemn Unicode for gross cultural arrogance. "All the languages of the world"? Yeah, right! And they say they do not use "complex modes or escape codes". Excuse me, last time I looked surrogate pairs weren't exactly simple. And an out-of-band markup or font tag is worse than an escape code; an escape code can at least be handled within a text stream, without having to look elsewhere for information about what language the text is supposed to be.
"No, there are not different code points for "A" in different languages in Unicode, and there never were. It's ridiculous to suggest that there should be. How often do we suffer because the French word "chat" (cat) and the English word "chat" are represented by the same code points in Latin-1? Approximately...never."
Did you actually read what I said? I was using the letter A as a theoretical example.
"Because English and French share a common encoding, in the case of Latin-1 (ISO 8859-1), you can tell at a glance what language it is and what it is saying. If you want to switch to a font that is more "French" in appearance, that's easy to do."
Great. You seem obsessed with on-screen appearance; try printing your text some time (and I'm not talking about using any TrueType crap here. Use a proper PS font.) Not to mention the fact that merely switching the fonts isn't going to work when you have two languages mixed in the same document.
"You say even the current system is better than Unicode. Really? Currently, if I send you a snippet of text in some East Asian language, how do you know what characters it represents? The major national encodings for Chinese, Japanese, and Korean completely remap the same double-byte codepoints. You have different characters depending on which encoding it is, so you have to be told the encoding, don't you? Having an encoding tag is just an out-of-band markup, but unlike the case of a language tag, the text is complete gibberish without the encoding tag with things as they currently are."
You're missing the point; Unicode still requires out-of-band information to determine the correct character to display for a particular code point in CJK, and converting text data from a current encoding scheme (take your pick; JIS, SJIS, EUC-J, Big5, whatever) to Unicode makes it IMPOSSIBLE to convert back to any of those coding schemes with a 100% guarantee of no loss of information. Try it; it really does work like that.
"Also, you say there aren't enough codepoints in double-byte Unicode to hold the needed number of Asian characters. Really? There are no currently implemented computer systems in all of Asia that contain any characters than are not already encoded in today's 2-byte Unicode, and more are being added from obscure old paper sources--characters so rare that nobody has yet used them on any computer."
That's because it wasn't POSSIBLE to use them on any computer, and it's still not possible with present implmentations of Unicode. And you seem to be rather misguided about the existence of characters not available under today's computer systems. What do you mean by "characters so rare that nobody has yet used them on any computer"? So what? Is this now the definition of a "useful" character - whether it's available on computer or not? In my opinion, we should be making the tools fit the job, rather than the other way around. Before you go spouting off about how Unicode is sufficient, and how "no currently implemented computer systems in all of Asia" use more characters, take a look at something like the GT Mincho Project, which has already defined 64,000 Japanese characters, and which will be extended to more than 100,000 characters in the near future. (And please don't tell me again about surrogate pairs; the UTC hasn't bothered to do much work on defining the code points yet, making them effectively useless.)
I could go on about problems with Unicode, but I'll just give you a quick list of some points: - Try searching using CJK Unicode. Depending on the characters you use, you'll pick up a whole pile of false hits because of the CJK unification. - Try typesetting with Unicode. It just doesn't work, and it's difficult to see how the UTC is going to make it work (if they even care). - Take a look at the conversion tables between Unicode and JIS. There's already at least three of them (not to mention Microsoft's implementation, which uses a fourth); how do you decide which is the correct one? - If you really believe surrogate pairs are a good thing, you're an idiot. - Look at Unicode's implementation of other Asian languages, like Thai. It sucks - but the UTC insists that they have "supported" these languages.
And lastly, about UCS-4: the Unicode.org home page has this to say - "The international standard ISO/IEC 10646 allows for two forms of use, a two-octet (=byte) form known as UCS-2 and a four-octet form known as UCS-4. The Unicode Standard, as a profile of ISO/IEC 10646, chooses the two-octet form, which is equivalent to saying that characters are represented in 16-bits per character. When extended characters are used, Unicode is equivalent to UTF-16." ISO-10646 was originally supposed to be a 31-bit standard, supporting CJK without unification of the code space - but because of the UTC, it was refused approval, and eventually turned into the 31-bit ISO-10646-1 standard, which just places the whole goddamn mess of 16-bit Unicode into the ISO-10646-1 31-bit codespace. And you're trying to tell me that the Unicode standard is good because it doesn't support 4-byte character codes?
This is a common problem with recent trackballs, particularly optical ones. They detect the rotation of the ball by sampling a particular area, and if it's changed, they know that the ball has rotated.
The problem is that if (for some reason) the rotation is either too fast or the driver can't get enough CPU time to sample regularly, you end up with random jumps that are most often in the OPPOSITE direction to the actual rotation.
Two suggestions: 1 - See if you can nice Civ (I know, it's gonna kill screen updates) 2 - Get a cheap mouse
Yeah, the fact that UTF-8 allows the use of ASCII in its present form was a big plus when it went up for approval.
Unfortunately, while it can handle UCS-2 (16bit) and USC-4 (31bit) characters, the Unicode codespace standard is brain-damaged; they decided to transfer the whole 16bit code space to UCS-4, which means we're still stuck with the mess of CJK unification, whereas if they'd had a clue, they would have thrown out UCS-2 and redefined the whole ball of wax for UCS-4.
The upshot is, even when we shift to 31bit UCS-4, people using CJK characters are still going to deal with the pile of crap that is UCS-2.
The "surrogate pair" concept, right? Well, it's not just CJK that's affected - languages with umlauts, Hebrew, and several other languages have to use them as well. Of course, the Unicode standard hasn't actually bothered to define what can be displayed with surrogate pairs and what can't, making them fairly pointless at the moment...
Yeah, that's pretty much it. The whole point of Unicode was that it's not supposed to depend on the font, but here we are with the same problems as Big5, JIS, SJIS, EUC, etc., had. In other words, there's not a lot of point in shifting to Unicode for people using these character codes.
The idea is, you have two or three characters that look very similar. One is Chinese, one is Japanese, one may be Korean. They look similar, but usage differs (ie, they have different meanings). Because of the ridiculous Unicode proposal, they are all unified into the same code point (ie have the same character code, which means there is no way to distinguish them through Unicode alone).
Now, the problem is, depending on the Unicode font used, you might get the Chinese character, you might get the Japanese character, or maybe the Korean character - but there is no way to be sure beforehand which one it is going to be without breaking the "universal" concept of Unicode.
The whole point of Unicode was that code points were supposed to be kept separate between languages - so an A in English and an A in French (as well as German, Dutch, etc. etc. etc.) are all supposed to have different code points, because usage differs between these languages. (This is just an example; I'm not positive that all these languages have a different code point for A). This concept unfortunately breaks down for CJK fonts.
It would seem that Microsoft is out to improve Perl performance on WIndows, but a closer look at the FAQ makes me suspicious. I know that Larry Wall said that ActiveState isn't so bad, and the fork() stuff doesn't bother me, but it rather goes against the grain of Perl to make alterations like MS is proposing (converting all applicable calls to use Unicode) without doing it in a cross-platform manner.
One other thing - the press release says that Unicode is greatly desired by Asian customers. This is nothing but marketing bullshit. Anyone in Asia who works with text processing knows that the current implementations of Unicode (including 2.0) are almost pitifully inadequate. And before anybody leaps forward to defend Unicode, please study up on the CJK problem before doing so. Unicode causes so many problems in its present state that it may simply be easier to continue using present "standards", at least in Asian countries. I'm quite simply disgusted with the way countries that don't use an ASCII superset have been treated with regard to Unicode.
(The CJK problem I'm referring to above, for those who can't be bothered looking it up for themselves, is that the present implementations of Unicode allow pretty much only for 16bit characters, which is nowhere enough to contain the number of characters required for Chinese-based fonts - ie, China, Japan and Korea (CJK). The idiots in charge of Unicode then decided that "similar" characters would have to use the same code point, thereby defeating the whole point of Unicode - that is, for CJK characters, the appearance of a character can vary depending on the font used, even though Unicode is supposed to define separate characters based on differences in usage between languages. To put it simply, a Unicode font is useless for DTP or other areas where the appearance of a particular character must be clearly defined. Iknow, there is a 31-bit version of Unicode, but nobody has made any serious attempt at defining code points outside of the 16bit code space.)
With this development, it would seem that Microsoft is going to ride roughshod over Asian markets by saying that Unicode is the complete solution to all our problems. Well, I say, stuff that where the sun don't shine, Billy boy.
BTW, my sig has been the same since I first registered at/. - I didn't change it just for this post...
My point exactly. There's no guarantee that a Celeron can be overclocked, so you're only likely to buy one for overclocking if you're short of money and can't afford a PII or PIII, or you've got enough money to not care that it may not work when overclocked but want to try it out cause you're '1337.
The reason I mentioned servers was because in a/. discussion about overclocking a few months ago, several people were talking about overclocking their servers and bitching that sometimes they weren't able to get the full potential out of their CPUs. What I was trying to say is that anyone who thinks like that is more than a little dim.
And regarding dual CPUs: it's become very common lately to buy a cheap dual CPU MB, a couple of PPGA Celerons and a pair of dual-jumper SEPP adapters, and then overclock the whole thing - which is pretty pointless when you're just using it for games, because virtually all the 3D games out there take no advantage of twin CPUs. (QIII might - and I emphasize "might" - be capable of using dual CPUs to the full in a later upgrade.) This is mainly because almost all 3D games run in a very tight loop that consists mostly of checking for user input, setting up the polygons, and blasting the data at a 3D card. Making games multithreaded just causes headaches for programmers in synchronizing things on screen, although Carmack apparently has a few new ideas that look promising.
IMNSHO, there's only two justifications for overclocking:
1: You're trying to get a bit more of a boost from an old chip.
2: You don't mind wasting your money on a slower chip if there's a chance that it can be overclocked.
Reason 2 implies that you're not going to be using the machine for any serious work, because, quite frankly, anybody who overclocks a server at work deserves to be fired. It's hard enough keeping a server going with as little downtime as possible as it is without throwing in random factors like overheating.
And as for overclocking dual CPU's, although it seems to be all the rage at the moment (with PPGA->SEPP adapters with dual jumpers and the cheaper dual MBs from Tekram, etc.), I have enough trouble handling overheating with my dual PII's as they are without overclocking them as well. (They start giving random compile errors and oopses at around 54-55 degrees Celcius.)
I love how the drooling idiots at news.com make the comment that 2.5 Gigabits/s "isn't quite" the same as an Exabit/s. Can you say "understatement"?
Ignoring the fact that an Exabit is one million times larger than a Gigabit, there's also the problem of routing - there isn't a router built that could possibly handle those kinds of speeds. I mean, c'mon, they can't even handle Gbps levels at reasonable cost yet.
Maybe news.com should be renamed "wedontknowwhatweretalkingaboutbutwelltakeyouradve rtisingdollars.com" or something.
Enlightenment is a window manager; it handles how your screen looks, i.e. the shape of windows, maybe your pager (the thing that allows you to choose your virtual screen), and so on.
Gnome is a graphical user environment; it is supposed to provide a unified interface for programs.
To put it simply (an oversimplification, I know), Enlightenment handles things outside your windows; Gnome handles things inside.
Of course, some window managers have elements of a graphical user environment, and KDE includes a window manager (kwm) itself. However, you should think of the WM and GUE as being two different things.
I'd bet on impossible. My IBM PC-110 (486SX@25Mhz) chokes on any MP3 that I try, using mpg123 with appropriate options on a virtual console under Linux. Even if it did work, you wouldn't be able to get anything that resembles music out of it:)
Tempest is a technique that allows you to "eavesdrop" on a computer by picking up the EM radiation from various parts, most commonly the monitor. Which means that the operator would have to sit inside the iron box in order to see the screen:)
Back to the subject at hand - thinner's illegal for anybody if they're gonna sniff it;) The police will pick you up for possession, but I'm not sure of the charge - I'm fairly certain that it's not classified as an illegal substance, although its sale is probably restricted.
The reason it's popular with young people is that it's cheap. A small bottle of the stuff is only a few thousand yen, a lot less than any other drug commonly found in Japan.
The point you're missing is that some knives have a valid purpose - as you mentioned, knives used in cooking, for example.
Guns have exactly one purpose - kill whatever it is that's in front of you. And don't try and tell me about how it's the person that kills, not the gun. I've met maybe three people that knew how to kill with their bare hands, and none of them would be able to stand up to a gun. Guns kill.
And by the way, it's "wakizashi", not "wakazashi".
You're talking about Aum; if you'd bothered to actually check the facts, besides making nerve gas (which, as it happens, was rather inefficient and terribly dangerous for the manufacturers), they were also trying to build their own automatic weapons, because guns aren't readily available in Japan.
It would help to know something about what you're talking about before you open your mouth...
Drug trafficking is not tolerated by japanese criminals - weird hey?
Bullshit. There are many places in Tokyo where you can pick up amphetamines, hashish and paint thinner (popular among younger people), and a lot of it comes through the Japanese gangs. People outside of Japan (and some inside it as well) seem to have this fantasy concept of Yakuza as honorable people who don't bother honest citizens.
Well let me tell you, that's crap. They're into every major area of making money here, including drugs, prostitution, gambling (both legal and illegal), the stockmarket, real estate... you name it, they've got a piece of the pie, and they're not nice people.
Thank you so much for your words of wisdom. And I'll return them right back to you - Don't go around thinking that the whole world revolves around your little chunk of it.
I don't know how many goddamn US-centric comments I've seen on/., but if I had a dollar for every one, I'd probably be up there with Bill Gates.
Well said. I'd just like to add that all of you morons posting summaries of your favorite scene/favorite line/whatever, just remember, TPM WAS ONLY RELEASED IN THE U.S. - NOBODY IN ANY OTHER COUNTRY HAS EVEN HAD A CHANCE TO SEE IT.
From another slashdotter who had his day totally trashed by assholes who just had to prove that they had seen the movie. Well done, guys. You suck.
Slashdot Mirror
Um.. well, I don't know about you, but if I were running a site entitled "LinuxHQ", I might at least consider it a good idea to do it on a Linux box, if only for the sake of credibility. If he's running it on a remote host, sure, no problem - but you don't see netbsd.org running on Linux, do you? Or openbsd.org? Or sun.com, for that matter? Perhaps you've heard the word "advocacy"? (As opposed to "moronic flaming", which seems to be what you're into.)
And as for "'tude", I think you've got more than enough for both of us...
Here's something interesting - queso gives the following output for www.linuxhq.com:
204.57.81.139:80 * NetBSD 1.3.x
Hmmm...
Once again, you're missing my point. Unicode is NOT AN IMPROVEMENT over present schemes for CJK encoding, and in some areas introduces new problems.
You say that JIS has been sufficient for all but the rarest applications. That's totally incorrect. JIS has been insufficient for any serious work, resulting in a wide variety of incompatible workarounds. Unicode provides yet another woefully insufficient solution that will lead to yet more workarounds (and I include surrogate pairs in this). You say that you're agnostic about surrogates. You work with CJK, and yet you don't care that what the surrogate system does to Unicode is almost exactly what SJIS did to 8-bit characters? SJIS is the worst of the commonly-used Japanese encodings, yet the UTC chose the same path. Surrogate characters are an ugly solution to a problem that should never have happened, but they are the only solution proposed by the UTC. They're a patchup job to a coding scheme that was not properly thought out to begin with.
You ignore the proliferation of conversion tables from JIS to Unicode, and the fact that JIS to Unicode is not reversible. Any data that is converted to Unicode is stuck in Unicode; you can't even be sure which conversion table was used, meaning it's impossible to know whether a particular Unicode version of a document matches any other encoding.
You dismiss Japanese characters not included in Unicode as "spelling mistakes". The spelling used by Shakespeare differed greatly from modern spelling; does that mean his work was full of spelling mistakes? What if Unicode forced English scholars to use a particular spelling? They'd have been up in arms in a second. Yet, this is almost exactly what Unicode (and other encoding systems, to a certain extent) have done to CJK. It has been impossible to convert historical documents to digital form because of the limitations of present encoding systems - yet Unicode, rather than trying to solve these problems, has added greater complexity without providing a full solution. The UTC had a shot at getting it right, and they blew it. They refuse to acknowledge that, and as a result, the CJK-using countries will suffer.
You talk about how the large database companies support Unicode "to address a global market". Rubbish. They support Unicode because it allows them to say that their software handles i18n. This is most likely the worst part of Unicode - it prevents better systems from having a fair chance, in that Western companies think that by supporting Unicode, they automatically gain entrance to non-Western markets. Because of the UTC's shortsightedness, nobody else can do anything about i18n without being told "Well, Unicode support is enough". It's not enough, and in its current form it never will be.
"I work in CJK computing, and I speak all three languages. I use a Unicode-based machine to read all three. I assure you that I have none of the difficulties you describe."
I speak and read two out of three, and I work at a publishing company that handles all three. You obviously don't do DTP. DTP is not presently practical under Unicode; give it a try sometime and you'll see what I mean.
"Someone working in just one of those languages would have it even easier. You're not going to get hit in the face by some horrible Chinese font if you are trying to read Japanese on a Japanese-only machine."
I didn't say that you would; what I said was that what the Unicode standard calls the same character can actually be a character that appears superficially similar (but not necessarily) but has a completely different meaning depending on the language.
To quote from the Unicode.org home page: "The design of Unicode is based on the simplicity and consistency of ASCII, but goes far beyond ASCII's limited ability to encode only the Latin alphabet. The Unicode Standard provides the capacity to encode all of the characters used for the written languages of the world. It uses a 16-bit encoding that provides code points for more than 65,000 characters. To keep character coding simple and efficient, the Unicode Standard assigns each character a unique 16-bit value, and does not use complex modes or escape codes."
This statement alone is enough to condemn Unicode for gross cultural arrogance. "All the languages of the world"? Yeah, right!
And they say they do not use "complex modes or escape codes". Excuse me, last time I looked surrogate pairs weren't exactly simple. And an out-of-band markup or font tag is worse than an escape code; an escape code can at least be handled within a text stream, without having to look elsewhere for information about what language the text is supposed to be.
"No, there are not different code points for "A" in different languages in Unicode, and there never were. It's ridiculous to suggest that there should be. How often do we suffer because the French word "chat" (cat) and the English word "chat" are represented by the same code points in Latin-1? Approximately...never."
Did you actually read what I said? I was using the letter A as a theoretical example.
"Because English and French share a common encoding, in the case of Latin-1 (ISO 8859-1), you can tell at a glance what language it is and what it is saying. If you want to switch to a font that is more "French" in appearance, that's easy to do."
Great. You seem obsessed with on-screen appearance; try printing your text some time (and I'm not talking about using any TrueType crap here. Use a proper PS font.) Not to mention the fact that merely switching the fonts isn't going to work when you have two languages mixed in the same document.
"You say even the current system is better than Unicode. Really? Currently, if I send you a snippet of text in some East Asian language, how do you know what characters it represents? The major national encodings for Chinese, Japanese, and Korean completely remap the same double-byte codepoints. You have different characters depending on which encoding it is, so you have to be told the encoding, don't you? Having an encoding tag is just an out-of-band markup, but unlike the case of a language tag, the text is complete gibberish without the encoding tag with things as they currently are."
You're missing the point; Unicode still requires out-of-band information to determine the correct character to display for a particular code point in CJK, and converting text data from a current encoding scheme (take your pick; JIS, SJIS, EUC-J, Big5, whatever) to Unicode makes it IMPOSSIBLE to convert back to any of those coding schemes with a 100% guarantee of no loss of information. Try it; it really does work like that.
"Also, you say there aren't enough codepoints in double-byte Unicode to hold the needed number of Asian characters. Really? There are no currently implemented computer systems in all of Asia that contain any characters than are not already encoded in today's 2-byte Unicode, and more are being added from obscure old paper sources--characters so rare that nobody has yet used them on any computer."
That's because it wasn't POSSIBLE to use them on any computer, and it's still not possible with present implmentations of Unicode. And you seem to be rather misguided about the existence of characters not available under today's computer systems. What do you mean by "characters so rare that nobody has yet used them on any computer"? So what? Is this now the definition of a "useful" character - whether it's available on computer or not? In my opinion, we should be making the tools fit the job, rather than the other way around.
Before you go spouting off about how Unicode is sufficient, and how "no currently implemented computer systems in all of Asia" use more characters, take a look at something like the GT Mincho Project, which has already defined 64,000 Japanese characters, and which will be extended to more than 100,000 characters in the near future. (And please don't tell me again about surrogate pairs; the UTC hasn't bothered to do much work on defining the code points yet, making them effectively useless.)
I could go on about problems with Unicode, but I'll just give you a quick list of some points:
- Try searching using CJK Unicode. Depending on the characters you use, you'll pick up a whole pile of false hits because of the CJK unification.
- Try typesetting with Unicode. It just doesn't work, and it's difficult to see how the UTC is going to make it work (if they even care).
- Take a look at the conversion tables between Unicode and JIS. There's already at least three of them (not to mention Microsoft's implementation, which uses a fourth); how do you decide which is the correct one?
- If you really believe surrogate pairs are a good thing, you're an idiot.
- Look at Unicode's implementation of other Asian languages, like Thai. It sucks - but the UTC insists that they have "supported" these languages.
And lastly, about UCS-4: the Unicode.org home page has this to say - "The international standard ISO/IEC 10646 allows for two forms of use, a two-octet (=byte) form known as UCS-2 and a four-octet form known as UCS-4. The Unicode Standard, as a profile of ISO/IEC 10646, chooses the two-octet form, which is equivalent to saying that characters are represented in 16-bits per character. When extended characters are used, Unicode is equivalent to UTF-16."
ISO-10646 was originally supposed to be a 31-bit standard, supporting CJK without unification of the code space - but because of the UTC, it was refused approval, and eventually turned into the 31-bit ISO-10646-1 standard, which just places the whole goddamn mess of 16-bit Unicode into the ISO-10646-1 31-bit codespace. And you're trying to tell me that the Unicode standard is good because it doesn't support 4-byte character codes?
This is a common problem with recent trackballs, particularly optical ones. They detect the rotation of the ball by sampling a particular area, and if it's changed, they know that the ball has rotated.
The problem is that if (for some reason) the rotation is either too fast or the driver can't get enough CPU time to sample regularly, you end up with random jumps that are most often in the OPPOSITE direction to the actual rotation.
Two suggestions:
1 - See if you can nice Civ (I know, it's gonna kill screen updates)
2 - Get a cheap mouse
Yeah, the fact that UTF-8 allows the use of ASCII in its present form was a big plus when it went up for approval.
Unfortunately, while it can handle UCS-2 (16bit) and USC-4 (31bit) characters, the Unicode codespace standard is brain-damaged; they decided to transfer the whole 16bit code space to UCS-4, which means we're still stuck with the mess of CJK unification, whereas if they'd had a clue, they would have thrown out UCS-2 and redefined the whole ball of wax for UCS-4.
The upshot is, even when we shift to 31bit UCS-4, people using CJK characters are still going to deal with the pile of crap that is UCS-2.
The "surrogate pair" concept, right? Well, it's not just CJK that's affected - languages with umlauts, Hebrew, and several other languages have to use them as well. Of course, the Unicode standard hasn't actually bothered to define what can be displayed with surrogate pairs and what can't, making them fairly pointless at the moment...
Yeah, that's pretty much it. The whole point of Unicode was that it's not supposed to depend on the font, but here we are with the same problems as Big5, JIS, SJIS, EUC, etc., had. In other words, there's not a lot of point in shifting to Unicode for people using these character codes.
Sorry I wasn't a bit clearer...
The idea is, you have two or three characters that look very similar. One is Chinese, one is Japanese, one may be Korean. They look similar, but usage differs (ie, they have different meanings). Because of the ridiculous Unicode proposal, they are all unified into the same code point (ie have the same character code, which means there is no way to distinguish them through Unicode alone).
Now, the problem is, depending on the Unicode font used, you might get the Chinese character, you might get the Japanese character, or maybe the Korean character - but there is no way to be sure beforehand which one it is going to be without breaking the "universal" concept of Unicode.
The whole point of Unicode was that code points were supposed to be kept separate between languages - so an A in English and an A in French (as well as German, Dutch, etc. etc. etc.) are all supposed to have different code points, because usage differs between these languages. (This is just an example; I'm not positive that all these languages have a different code point for A). This concept unfortunately breaks down for CJK fonts.
I hope that was a little easier to understand...
It would seem that Microsoft is out to improve Perl performance on WIndows, but a closer look at the FAQ makes me suspicious. I know that Larry Wall said that ActiveState isn't so bad, and the fork() stuff doesn't bother me, but it rather goes against the grain of Perl to make alterations like MS is proposing (converting all applicable calls to use Unicode) without doing it in a cross-platform manner.
/. - I didn't change it just for this post...
One other thing - the press release says that Unicode is greatly desired by Asian customers. This is nothing but marketing bullshit. Anyone in Asia who works with text processing knows that the current implementations of Unicode (including 2.0) are almost pitifully inadequate. And before anybody leaps forward to defend Unicode, please study up on the CJK problem before doing so. Unicode causes so many problems in its present state that it may simply be easier to continue using present "standards", at least in Asian countries. I'm quite simply disgusted with the way countries that don't use an ASCII superset have been treated with regard to Unicode.
(The CJK problem I'm referring to above, for those who can't be bothered looking it up for themselves, is that the present implementations of Unicode allow pretty much only for 16bit characters, which is nowhere enough to contain the number of characters required for Chinese-based fonts - ie, China, Japan and Korea (CJK). The idiots in charge of Unicode then decided that "similar" characters would have to use the same code point, thereby defeating the whole point of Unicode - that is, for CJK characters, the appearance of a character can vary depending on the font used, even though Unicode is supposed to define separate characters based on differences in usage between languages. To put it simply, a Unicode font is useless for DTP or other areas where the appearance of a particular character must be clearly defined. Iknow, there is a 31-bit version of Unicode, but nobody has made any serious attempt at defining code points outside of the 16bit code space.)
With this development, it would seem that Microsoft is going to ride roughshod over Asian markets by saying that Unicode is the complete solution to all our problems. Well, I say, stuff that where the sun don't shine, Billy boy.
BTW, my sig has been the same since I first registered at
Acch!! Pfft!! Obviously, I didn't mean a mailing list - it's from an old Usenet post in comp.dcom.lans.ethernet.
Found this on a mailing list - hope it helps (but it really would be easier to just buy a transceiver).
Ethernet AUI to AUI cheaply
My point exactly. There's no guarantee that a Celeron can be overclocked, so you're only likely to buy one for overclocking if you're short of money and can't afford a PII or PIII, or you've got enough money to not care that it may not work when overclocked but want to try it out cause you're '1337.
/. discussion about overclocking a few months ago, several people were talking about overclocking their servers and bitching that sometimes they weren't able to get the full potential out of their CPUs. What I was trying to say is that anyone who thinks like that is more than a little dim.
The reason I mentioned servers was because in a
And regarding dual CPUs: it's become very common lately to buy a cheap dual CPU MB, a couple of PPGA Celerons and a pair of dual-jumper SEPP adapters, and then overclock the whole thing - which is pretty pointless when you're just using it for games, because virtually all the 3D games out there take no advantage of twin CPUs. (QIII might - and I emphasize "might" - be capable of using dual CPUs to the full in a later upgrade.) This is mainly because almost all 3D games run in a very tight loop that consists mostly of checking for user input, setting up the polygons, and blasting the data at a 3D card. Making games multithreaded just causes headaches for programmers in synchronizing things on screen, although Carmack apparently has a few new ideas that look promising.
IMNSHO, there's only two justifications for overclocking:
1: You're trying to get a bit more of a boost from an old chip.
2: You don't mind wasting your money on a slower chip if there's a chance that it can be overclocked.
Reason 2 implies that you're not going to be using the machine for any serious work, because, quite frankly, anybody who overclocks a server at work deserves to be fired. It's hard enough keeping a server going with as little downtime as possible as it is without throwing in random factors like overheating.
And as for overclocking dual CPU's, although it seems to be all the rage at the moment (with PPGA->SEPP adapters with dual jumpers and the cheaper dual MBs from Tekram, etc.), I have enough trouble handling overheating with my dual PII's as they are without overclocking them as well. (They start giving random compile errors and oopses at around 54-55 degrees Celcius.)
I love how the drooling idiots at news.com make the comment that 2.5 Gigabits/s "isn't quite" the same as an Exabit/s. Can you say "understatement"?
Ignoring the fact that an Exabit is one million times larger than a Gigabit, there's also the problem of routing - there isn't a router built that could possibly handle those kinds of speeds. I mean, c'mon, they can't even handle Gbps levels at reasonable cost yet.
Maybe news.com should be renamed "wedontknowwhatweretalkingaboutbutwelltakeyouradv
Enlightenment is a window manager; it handles how your screen looks, i.e. the shape of windows, maybe your pager (the thing that allows you to choose your virtual screen), and so on.
Gnome is a graphical user environment; it is supposed to provide a unified interface for programs.
To put it simply (an oversimplification, I know), Enlightenment handles things outside your windows; Gnome handles things inside.
Of course, some window managers have elements of a graphical user environment, and KDE includes a window manager (kwm) itself. However, you should think of the WM and GUE as being two different things.
I'd bet on impossible. My IBM PC-110 (486SX@25Mhz) chokes on any MP3 that I try, using mpg123 with appropriate options on a virtual console under Linux. Even if it did work, you wouldn't be able to get anything that resembles music out of it
Tempest is a technique that allows you to "eavesdrop" on a computer by picking up the EM radiation from various parts, most commonly the monitor. Which means that the operator would have to sit inside the iron box in order to see the screen
Sorry about jumping all over you...
;)
Back to the subject at hand - thinner's illegal for anybody if they're gonna sniff it
The police will pick you up for possession, but I'm not sure of the charge - I'm fairly certain that it's not classified as an illegal substance, although its sale is probably restricted.
The reason it's popular with young people is that it's cheap. A small bottle of the stuff is only a few thousand yen, a lot less than any other drug commonly found in Japan.
The point you're missing is that some knives have a valid purpose - as you mentioned, knives used in cooking, for example.
Guns have exactly one purpose - kill whatever it is that's in front of you. And don't try and tell me about how it's the person that kills, not the gun. I've met maybe three people that knew how to kill with their bare hands, and none of them would be able to stand up to a gun. Guns kill.
And by the way, it's "wakizashi", not "wakazashi".
Many killed, not one gun.
You're talking about Aum; if you'd bothered to actually check the facts, besides making nerve gas (which, as it happens, was rather inefficient and terribly dangerous for the manufacturers), they were also trying to build their own automatic weapons, because guns aren't readily available in Japan.
It would help to know something about what you're talking about before you open your mouth...
Drug trafficking is not tolerated by japanese criminals - weird hey?
Bullshit. There are many places in Tokyo where you can pick up amphetamines, hashish and paint thinner (popular among younger people), and a lot of it comes through the Japanese gangs. People outside of Japan (and some inside it as well) seem to have this fantasy concept of Yakuza as honorable people who don't bother honest citizens.
Well let me tell you, that's crap. They're into every major area of making money here, including drugs, prostitution, gambling (both legal and illegal), the stockmarket, real estate... you name it, they've got a piece of the pie, and they're not nice people.
Thank you so much for your words of wisdom. And I'll return them right back to you - Don't go around thinking that the whole world revolves around your little chunk of it.
I don't know how many goddamn US-centric comments I've seen on
Well said. I'd just like to add that all of you morons posting summaries of your favorite scene/favorite line/whatever, just remember, TPM WAS ONLY RELEASED IN THE U.S. - NOBODY IN ANY OTHER COUNTRY HAS EVEN HAD A CHANCE TO SEE IT.
From another slashdotter who had his day totally trashed by assholes who just had to prove that they had seen the movie. Well done, guys. You suck.
What made you leave PHT?