...merely distributing css-descramble.cwithout the required header files and without the code that performs the DVD drive authentication and challenge. Hey, haven't you heard of tar | gzip | mimencode?
Look, either it's a symbolic measure of protest and civil disobedience: but then, it's much more fun to have tee-shirts and MP3's and images of the DeCSS source.
Or it's destined to be actually useful. But then, did you ever notice that the wonderful xmovie program comes with DeCSS included (though you'll have to recompile it yourself; which is a pretty difficult task, in fact). I haven't tried out version 1.5.1 for the moment, but I use version 1.4 to read my DVD's and it works marvelously. No messing around with css-cat's strange options. Brutal seeking works fine. This program is beautiful.
So instead of distributing just one isolated file which is worthless alone, distribute the entire xmovie source code. All right, it's a bit large - but it's worth it.
Re:What about RSA now?
on
GPG vs. PGP?
·
· Score: 2
Look, suppose we have a six-sided die and every man throws it once. I say "we have five chances out of six of not hitting the number one". You will agree with that, I hope. Well, of course you can point out a lot of people will hit the number one, and from their point of view the fact that "hitting one is pretty unlikely" is worthless, but the probability is still valid.
It is a trivial fact that half of humanity will be born in the "second half" of humanity, and they will be justified in their belief that there will be fewer people born after them than before.
Since we have no reason to believe that we are more likely to be in the former half than in the latter half, I say we have a one chance in two of being in the latter, and I draw the conclusions in that case. This is perfectly trivial reasoning.
Naturally, you can cite a lot of people who have lived in what we are now sure to be the former half, and they would be wrong in believing that they are in the latter half. I can't cite anyone sure to be in the latter half because we can never know for sure when it starts. But it evidently must exist, and it must contain as many people as the former half.
I don't know why people find this reasoning hard to accept: it's basically very simple.
Maybe you find that distressing and pessimistic. Well, here's another result which is more optimistic, then. As previously, let y=8*10^10 be the number of people who have lived so far, and x be the total number of people to live in the entire time span of humanity. The probability that x is at least equal to ky (for some real number k>1) is 1/k. If you calculate the mean expectancy of a so distributed random variable, you will find the integral to be divergent: the expectancy is infinite.
Thus, while there is a 1/2 probability that the number of people yet to live is at most 80 billion, the average number is infinite. Mind-boggling. But obvious.
Don't trsut me: do the math. And, of course, still ha, ha, only serious.
Beeep. Notice how I said that this was not a certainty but only a probability of one in two? And that's precisely the point: half of mankind (the "latter half") could make the computation and they would be right in the interval they find, whereas the other half would be wrong. Thus, there is no fallacy involved, only probabilities. There is no date involved, only an interval.
You should realize that more than half of all men that have been born so far have been born in the last two hundred years. You may get the impression that "Og the caveman, Euclid, Charlemagne or Newton" cover a vast part of the timeline of humanity, but in terms of numbers of birth, they do not.
The more dubious assertion is that the birth rate will remain over or about 150 million per year in the coming five centuries. But there, I don't know how to improve upon this.
Here's a cute little argument that predicts that mankind has a roughly one-in-two chance of ceasing to exist within five hundred years (and therefore probably won't be around when the sun dies). It uses the Anthropic principle, but backward. I am roughly translating from the not e in French I wrote on the subject.
Imagine the following game. Somebody chooses a positive (real) number x. He then picks a random number y uniformly distributed between 0 and x, and tells it to me. My goal is to guess what x was. If I state that "x is between y and 2y", then the probability of my being right is the probability of y being being beween x/2 and x (that's the same thing), so it is 1/2 because y was uniformly distributed between 0 and x. That's trivial. And in practice if you play this game, it is a sensible thing to guess that x is between y and 2y.
Now it evidently doesn't make sense to take for x the total lifespan of humanity, because men are not uniformly distributed along it. So we take for x the total number of human beings that will have lived in the entire duration of humanity. We would like to know what x is. We don't have a clue. However, one thing we do know is how many people have lived so far, or, which is roughly the same thing, your (or my) "rank number" in the list of all human beings (in order of birth). This number, y, is of the order of 8*10^10 (80 billion that is). Further, since you (or I) have no reason of being one given human being than another, y is uniformly distributed between 0 and x. Consequently, we can apply the result I just gave, and conclude that x has one chance out of two of being between y=8*10^10 and 2y=1.5*10^11.
Translated in other words, it means that there is one chance out of two that less than 80 billion human beings have yet to live (or be born). With a current rate of 1.5*10^7 (150 million) born each year, assuming it does not decrease considerably, this brings us 500 years hence. I think this is a sensible order of magnitude.
(Of course, the same reasoning also shows that there is a better than one-in-twenty chance of "doomsday" befalling within our lifetime. That's a rather chilling thought.)
In case it wasn't obvious, this post is to be taken as "Ha, ha, only serious". If you want more thoughts on the same line, see here.
GPG supports plugins and there has been one available for RSA for quite some time now. You can get it from here for example. Compilation instructions are included. Just ignore the legal shit at the beginning.
I've been using it already. I don't care about the patent: algorithms are not patentable in Europe, and RSA Security hasn't even tried to apply for it here.
In the UTF-8 encoding (defined by RFC2279), it takes between one and six octets (bytes) to encode one character, although no currently assigned character needs more than three. UTF-8 can address all the 2147483648 characters of ISO-10646-1.
In the UTF-16 encoding (RFC2781), it takes either two or four octets (bytes) to encoed one character, although no currently assigned character needs four. UTF-16 can access only the first 1114112 characters of ISO-10646-1 (the first 17 planes), which form the Unicode range proper.
Both these encodings use characters outside the ASCII range (i.e. 8-bit characters), which are not supported by current BIND versions, but which are still permitted by the DNS standards (RFC1034&1035).
However, the proposed IDNS standard does not use either of these encodings (IMHO not using UTF-8 is a terrible mistake) but yet another one, called UTF-5 (see "draft-jseng-utf5-00" in Internet Drafts).
In the UTF-5 encoding (defined by the aforementioned dreft), it takes between one and eight octets (bytes) to encode one character, although no currently assigned character needs more than four. UTF-5 can address all the 2147483648 characters of ISO-10646-1.
If UTF-5 is used on DNS labels, you can have up to 15 Chinese characters in such a label.
That's only part of the story. The only non-ASCII characters in Spanish are entirely contained in the ISO-8859-1 (aka Latin-1) character set. Since most programs are already configured to work correctly with Latin-1, supporting that (in browsers and such, that is) should be rather easy.
Chinese is moderately complicated. Yes, it does have a huge number of characters, but on the other hand they are fixed-width, and the difficulty of rendering Chinese is rather small once you have the appropriate font (I'm talking of rendering, e.g. in the URL bar); in fact, Chinese is simpler to render than the Latin script.
Devanagari (just like every other Indic script), on the other hand, is hugely complicated. The crazy ligature system means that we are going to have to wait a looong time before we see software that correctly handles the Nagari script in any non-trivial situation.
For example, consider the Unicode test page I keep referring to: you have a sample of Russian, a sample of classical (polytonic) Greek, a sample of Sanskrit (written in Devanagari script) and a sample of Chinese. Many browsers will handle the Russian and Chinese correctly, and the non-polytonic Greek characters; very few will handle the full Greek text correctly; none is known that correctly displays the Sanskrit text.
Conflicts with existing names are mostly dangerous when the user might type the name and make a typo. Evidently you would not type such a thing as "amazn.com" (here the "o" before the "n" is replaced by the cyrillic form of the same letter which is supposedly indistinguishable from it). When you are following links, well, you are following links, and you are therefore trusting the site with the links to some extent. After all, non-power users rarely read the URL written at the bottom of the page, in any case: if someone writes a site which looks very much like a well-known site and links to it, whatever the URL, many users will be fooled. I don't think "internationalized URLs" will be a major change in this respect.
Slashdot's handling of accented characters in nicknames was completely grotesque, in any case. It was done naïvely by taking the 8-bit data as submitted and using it in the URL. But this is not how it works: the data should have been encoded in UTF-8 beforehand.
--
Here you should see an upper-case e with an acute acent: é. Here you should see an upper-case Y with two dots on it: . Here you should see a capital greek Gamma: . Here you should see a Hebrew aleph and a Hebrew beth: ; of course, the aleph should be on the right because it is first (unless there was a line split between the two). Here you should see the Devanagari "OM" sign: . Here you should see a smiling face: . Here you should see the Chinese (or Japanese) character for "sun": . None of this should depend on your selected "document encoding". If you did not see all that, then your browser is broken and you should change it.
Recently I posted this comment mentioning the fact that there's really no reason why a domain such as www..com (you should see two Chinese ideograms meaning "China" between the "www." and the ".com" parts; further, if you click on this link, your browser should open a window telling you that the domain "www..com" does not exist, with the same two Chinese ideograms) doesn't exist.
Let us recall: first, as specified by the HTML specification, every HTML document, no matter what character set it is "encoded" as, is written in the all-englobing Unicode character set. So when you write something like "中国" in HTML, it refers to the Unicode characters (decimal) 20013 and 22269, no matter what the current character encoding and font are. So that's how you write the link text. Second, as for the URL itself, well, although it is not (as far as I know) formally recommended by an Internet standard, it is widely recognized that URLs are written in the UTF-8 encoding format (which is afterward %-encoded into ASCII).
The whole process is described in this Internet Draft ("Internationalized Uniform Resource Identifiers"; WORK IN PROGRESS!) by Larry Masinter and Martin Duerst where the relationship between URIs and IURIs (Internationalized URIs) is discussed in detail.
The DNS is the toughest part of all. The DNS specification (RFC1034) states (section 3.1) that DNS data is to be taken as binary for possible upward compatibility (this was wonderful foresight on Mockapetris' part!). Consequently, there is nothing as per standards wrong with using (UTF-8 encoded Unicode) 8-bit data in DNS labels. Except, of course, that many "buggy" implementations will have to be corrected for broken assumptions, *sigh*. The IDNS working group suggests using a UTF-5 encoding to avoid going beyond the current domain name limits: I think this is not a good thing and we should stick to UTF-8 and repair broken software.
Oh, and incidentally, see this page too know how broken your browser's Unicode support is.
Roughly [socialism is] the collective or governmental ownership and administration of a nations resources and means of production. No. That's communism. And that's not what we're discussing. Evidently nobody suggested that the European Union should nationalize AOL and/or Time Warner. That would be both stupid and impossible; and that would be communism. We're discussing forbidding the merger: this is about socialism. It's about protecting the consumer and the worker from excessive corporate power.
Evidently the governments of Western Europe are not communist. But there is not the shadow of a doubt that Tony Blair is more socialist than Margaret Thatcher (or even John Major); that Gerhard Schröder is more socialist than Helmut Kohl; that Lionel Jospin is more socialist than Alain Juppé; and that Romano Prodi (or even Massimo Dalema) is more socialist than Silvio Berlusconi. I'm not saying that there's a definite trend here: the goverments of Spain and Austria are definitely right-wing. But I definitely fail to see a trend of "replacing this dangerous socialism by sane libertarianism" in Europe.
Let us know when [France's] unemployment rate drops below 10%, willya? It is below 10%: you can find the official figures here (provided you can read French, of course). Remember, incidentally, that the European definition of "unemployed" is broader than the American one so that comparison is biased.
Along that line I could ask you to let "us" know when your poverty level (percentage of population whose income is less than half the national median) drops below 10%, but I frankly don't care. If you want to see an interesting comparison of the US with other rich world countries, see e.g. this page, it's very instructive and you'll learn that several countries can "keep up with the US" as you put it. But this is widely off topic.
A little more to the point, you say you think that they [European countries] became less socialistic. There is no doubt that Eastern European countries did (though in some countries, e.g. Russia, economic disaster has brought the communists back in popularity), but as far as Western European countries go, well, I have some news for you: the United Kingdom has a labor government; Germany is governed by a socialist / ecologist coalition; the socialist party heads the government in France, and there are several communist ministers; Portugal has a socialist government; Italy is governed by a coalition that is moderately left wing; and, you may believe it or not, but we have free elections even East of the Atlantic, and these various governments were freely chosen by the people. The European Parliament, on the other hand, has a comfortable right-wing majority. Also freely chosen.
The plain fact is not that socialism is good or bad; the plain fact is that you do not have a clue what socialism is.
...how often we will see the word "socialist" written in the comments of this discussion.
Slashdotters have a very peculiar vision of History: it seems they believe that after the fall of the Berlin[*] wall every European country became socialist.
They also for the most part believe that this is none of the European Union's affairs.
So we're going to see a looot of posts along the lines of:
Hopefully Time Warner and AOL will tell these socialist European governments to fuck off. They're in America, so they don't care what European socialists can say. Hey, that's what capitalism is all about. We don't need governments to interfere.
(Plus insert perhaps a bit about guns, just to make the point.)
Will those who are about to post something of similar content please reconsider? Do you truly believe the European Commission to be so stupid not to have noticed that AOL stands for "America" On Line?
-- [*]Actually, I suspect many would be unable to place Berlin on a map of Europe; they'd probably place it where Prag is. But that is irrelevant.
When Baron Pierre de Coubertin "reinvented" the Olympic Games in 1896, amateurism was one of his dearest principles, and he ruled that professional athletes would not be permitted. I don't remember when that rule was suppressed, but it seems like a looong time ago.
On the other hand, Coubertin's ideas were sometimes very dubious, if not outright fascist (pardon the anachronism) so one should not be too eager to rant about the (g?)Olden Days.
And they measure that distance continuously. It used to be true that the Earth-Moon distance was known with better precision than the distance between London and New York, in fact.
Now if such a customer file is shared by amazon between several countries, it must be kept in compliance with the law of every country in question.
So if you're not happy with amazon keeping personal info on your subject, go to amazon.fr, check that the info is indeed shared with amazon.com, and write them ("them" being amazon.fr) a letter (in formal French, of course) stating that you wish to exercise the rights vested upon you by article 36 of the aforementioned law 78-16 of january 6, 1978, and that in compliance with that law they must strike the information concerning you from the record (you can claim, e.g., that it is obsolete). Somehow I doubt they'll make a special effort to remove the info in amazon.fr and not in amazon.com, so they'll have to remove it completely.
(I only mention French law because I know that particular one. But maybe German or English law (for amazon.de or amazon.co.uk) could let you achieve the same results.)
Somehow I feel that we'll have to stand the "socialist Europe" cliché again...
A lot of people have pointed out that "ah, it doesn't matter, we can point to search engines that locate the code", or something of that kind.
Only this doesn't work, because if every direct link to the code is removed (I'm not saying it will be - I'm just pointing out that the argument is flawed), the search engines probably won't index it forever.
I suspect this is not a true Microsoft IIS server. I suspect it is really some Perl script running on FreeBSD that was hacked in a minute and that pretends to be Microsoft IIS (what the heck, all it has to do is send one redirect reply: do you really want to run a full web server for that?). And, of course, the guy who wrote that didn't bother to read the specs.
Yes, this is a conflict of standards, because the quoted section of the RFC (or its later revision, RFC2616, page 26) says
Data in character sets other than "ISO-8859-1" or
its subsets MUST be labeled with an appropriate charset value.
(Thus the HTML spec, strictly speaking, is in error: the HTTP protocol doesn't "mention" ISO-8859-1, and it's default use isn't a "recommendation" - it's a MUST. But it is certainly right in calling it "useless".)
IMHO the correct way to proceed is for HTML authors to use a meta http-equiv tag to specify the character set. Of course, an even better solution is to use XHTML, since the encoding is specified in the XML declaration; and the XML specification is clear on the subject:
In the absence of information provided by an external transport protocol
(e.g. HTTP or MIME), it is an
error [...] for an entity which begins
with neither a Byte Order Mark nor an encoding declaration to use an
encoding other than UTF-8.
Even better: write XHTML, use an XML character set declaration and add a meta http-equiv tag just to make sure...
I don't really see the point of encoding everything in ASCII (UTF-5) rather than using actual (UTF-8 encoded) 8-bit data in domain names: RFC1035 (Domain Names - Implementation and Specification) explicitely states (see section 2.3.3) that implementations should preserve all binary data verbatim. We don't need any new standards: the standards are already there.
In case this wasn't perfectly clear: my post contains several Asian characters. These should appear as such no matter what the "document encoding" is set to.
Ah, one of my favorite pet peeves. You've completely misunderstood the way Unicode works on web pages; but it's not really your fault, it's because Netscape Navigator is completely broken in this respect (it's far more - and far worse - than broken, in fact).
Neither the HTTP headers sent by Slashdot nor the preamble of the HTML file specify a character encoding. Therefore the encoding is the default encoding, i.e. ISO-8859-1 (aka latin-1). What you've written, then, is not "sayonara" but "comma cube comma ae comma E-grave comma c-cedilla". If you see anything else, your browser is broken! You've posted Shift_JIS-encoded data in an ISO-8859-1-encoded page and that doesn't make sense.
Now this does not mean that you can't have Japanese in HTML, even if the page is encoded as ISO-8859-1. Indeed, "at the bottom", every HTML document is written in Unicode, and every Unicode character is available, if not readily though the encoding (not necessarily UTF-8), then at least through SGML numeric entities of the form &#xxxxx; (where xxxxx is the decimal form of the Unicode character number). Consequently, the correct way of posting "sayonara" is "" (which I've written as "㇁よなら"). Again, if you see anything else than the hiragana for "sayonara" here (or perhaps a transcription of it, e.g. with lynx), especially if you see latin-1 characters, again, your browser is broken.
The brokenness about Netscape is that it assumes that numeric SGML character entities are to be interpreted in the current document encoding, and that is completely wrong. They should always be interpreted as Unicode character numbers. So this has somehow led to the conception that the basic HTML character data is in the character set of the encoding, which it is not! Fortunately, Mozilla repairs this brokenness, hopefully before any serious damage is done.
I posted another comment on this article to the effect that you can even have valid Chinese characters (in my example, , i.e. "China" in Chinese) in the host name part of a URL. It just happens that such domain names are not given out, but there is nothing wrong with it.
For more examples of Unicode and to see how badly your browser is broken, follow this link.
Slashdot Mirror
...merely distributing css-descramble.c without the required header files and without the code that performs the DVD drive authentication and challenge. Hey, haven't you heard of tar | gzip | mimencode?
Look, either it's a symbolic measure of protest and civil disobedience: but then, it's much more fun to have tee-shirts and MP3's and images of the DeCSS source.
Or it's destined to be actually useful. But then, did you ever notice that the wonderful xmovie program comes with DeCSS included (though you'll have to recompile it yourself; which is a pretty difficult task, in fact). I haven't tried out version 1.5.1 for the moment, but I use version 1.4 to read my DVD's and it works marvelously. No messing around with css-cat's strange options. Brutal seeking works fine. This program is beautiful.
So instead of distributing just one isolated file which is worthless alone, distribute the entire xmovie source code. All right, it's a bit large - but it's worth it.
See this comment.
Look, suppose we have a six-sided die and every man throws it once. I say "we have five chances out of six of not hitting the number one". You will agree with that, I hope. Well, of course you can point out a lot of people will hit the number one, and from their point of view the fact that "hitting one is pretty unlikely" is worthless, but the probability is still valid.
It is a trivial fact that half of humanity will be born in the "second half" of humanity, and they will be justified in their belief that there will be fewer people born after them than before.
Since we have no reason to believe that we are more likely to be in the former half than in the latter half, I say we have a one chance in two of being in the latter, and I draw the conclusions in that case. This is perfectly trivial reasoning.
Naturally, you can cite a lot of people who have lived in what we are now sure to be the former half, and they would be wrong in believing that they are in the latter half. I can't cite anyone sure to be in the latter half because we can never know for sure when it starts. But it evidently must exist, and it must contain as many people as the former half.
I don't know why people find this reasoning hard to accept: it's basically very simple.
Maybe you find that distressing and pessimistic. Well, here's another result which is more optimistic, then. As previously, let y=8*10^10 be the number of people who have lived so far, and x be the total number of people to live in the entire time span of humanity. The probability that x is at least equal to ky (for some real number k>1) is 1/k. If you calculate the mean expectancy of a so distributed random variable, you will find the integral to be divergent: the expectancy is infinite.
Thus, while there is a 1/2 probability that the number of people yet to live is at most 80 billion, the average number is infinite. Mind-boggling. But obvious.
Don't trsut me: do the math. And, of course, still ha, ha, only serious.
Beeep. Notice how I said that this was not a certainty but only a probability of one in two? And that's precisely the point: half of mankind (the "latter half") could make the computation and they would be right in the interval they find, whereas the other half would be wrong. Thus, there is no fallacy involved, only probabilities. There is no date involved, only an interval.
You should realize that more than half of all men that have been born so far have been born in the last two hundred years. You may get the impression that "Og the caveman, Euclid, Charlemagne or Newton" cover a vast part of the timeline of humanity, but in terms of numbers of birth, they do not.
The more dubious assertion is that the birth rate will remain over or about 150 million per year in the coming five centuries. But there, I don't know how to improve upon this.
Here's a cute little argument that predicts that mankind has a roughly one-in-two chance of ceasing to exist within five hundred years (and therefore probably won't be around when the sun dies). It uses the Anthropic principle, but backward. I am roughly translating from the not e in French I wrote on the subject.
Imagine the following game. Somebody chooses a positive (real) number x. He then picks a random number y uniformly distributed between 0 and x, and tells it to me. My goal is to guess what x was. If I state that "x is between y and 2y", then the probability of my being right is the probability of y being being beween x/2 and x (that's the same thing), so it is 1/2 because y was uniformly distributed between 0 and x. That's trivial. And in practice if you play this game, it is a sensible thing to guess that x is between y and 2y.
Now it evidently doesn't make sense to take for x the total lifespan of humanity, because men are not uniformly distributed along it. So we take for x the total number of human beings that will have lived in the entire duration of humanity. We would like to know what x is. We don't have a clue. However, one thing we do know is how many people have lived so far, or, which is roughly the same thing, your (or my) "rank number" in the list of all human beings (in order of birth). This number, y, is of the order of 8*10^10 (80 billion that is). Further, since you (or I) have no reason of being one given human being than another, y is uniformly distributed between 0 and x. Consequently, we can apply the result I just gave, and conclude that x has one chance out of two of being between y=8*10^10 and 2y=1.5*10^11.
Translated in other words, it means that there is one chance out of two that less than 80 billion human beings have yet to live (or be born). With a current rate of 1.5*10^7 (150 million) born each year, assuming it does not decrease considerably, this brings us 500 years hence. I think this is a sensible order of magnitude.
(Of course, the same reasoning also shows that there is a better than one-in-twenty chance of "doomsday" befalling within our lifetime. That's a rather chilling thought.)
In case it wasn't obvious, this post is to be taken as "Ha, ha, only serious". If you want more thoughts on the same line, see here.
See this comment.
GPG supports plugins and there has been one available for RSA for quite some time now. You can get it from here for example. Compilation instructions are included. Just ignore the legal shit at the beginning.
I've been using it already. I don't care about the patent: algorithms are not patentable in Europe, and RSA Security hasn't even tried to apply for it here.
In the UTF-8 encoding (defined by RFC2279), it takes between one and six octets (bytes) to encode one character, although no currently assigned character needs more than three. UTF-8 can address all the 2147483648 characters of ISO-10646-1.
In the UTF-16 encoding (RFC2781), it takes either two or four octets (bytes) to encoed one character, although no currently assigned character needs four. UTF-16 can access only the first 1114112 characters of ISO-10646-1 (the first 17 planes), which form the Unicode range proper.
Both these encodings use characters outside the ASCII range (i.e. 8-bit characters), which are not supported by current BIND versions, but which are still permitted by the DNS standards (RFC1034&1035).
However, the proposed IDNS standard does not use either of these encodings (IMHO not using UTF-8 is a terrible mistake) but yet another one, called UTF-5 (see "draft-jseng-utf5-00" in Internet Drafts).
In the UTF-5 encoding (defined by the aforementioned dreft), it takes between one and eight octets (bytes) to encode one character, although no currently assigned character needs more than four. UTF-5 can address all the 2147483648 characters of ISO-10646-1.
If UTF-5 is used on DNS labels, you can have up to 15 Chinese characters in such a label.
That's only part of the story. The only non-ASCII characters in Spanish are entirely contained in the ISO-8859-1 (aka Latin-1) character set. Since most programs are already configured to work correctly with Latin-1, supporting that (in browsers and such, that is) should be rather easy.
Chinese is moderately complicated. Yes, it does have a huge number of characters, but on the other hand they are fixed-width, and the difficulty of rendering Chinese is rather small once you have the appropriate font (I'm talking of rendering, e.g. in the URL bar); in fact, Chinese is simpler to render than the Latin script.
Devanagari (just like every other Indic script), on the other hand, is hugely complicated. The crazy ligature system means that we are going to have to wait a looong time before we see software that correctly handles the Nagari script in any non-trivial situation.
For example, consider the Unicode test page I keep referring to: you have a sample of Russian, a sample of classical (polytonic) Greek, a sample of Sanskrit (written in Devanagari script) and a sample of Chinese. Many browsers will handle the Russian and Chinese correctly, and the non-polytonic Greek characters; very few will handle the full Greek text correctly; none is known that correctly displays the Sanskrit text.
Conflicts with existing names are mostly dangerous when the user might type the name and make a typo. Evidently you would not type such a thing as "amazn.com" (here the "o" before the "n" is replaced by the cyrillic form of the same letter which is supposedly indistinguishable from it). When you are following links, well, you are following links, and you are therefore trusting the site with the links to some extent. After all, non-power users rarely read the URL written at the bottom of the page, in any case: if someone writes a site which looks very much like a well-known site and links to it, whatever the URL, many users will be fooled. I don't think "internationalized URLs" will be a major change in this respect.
Slashdot's handling of accented characters in nicknames was completely grotesque, in any case. It was done naïvely by taking the 8-bit data as submitted and using it in the URL. But this is not how it works: the data should have been encoded in UTF-8 beforehand.
--
Here you should see an upper-case e with an acute acent: é. Here you should see an upper-case Y with two dots on it: . Here you should see a capital greek Gamma: . Here you should see a Hebrew aleph and a Hebrew beth: ; of course, the aleph should be on the right because it is first (unless there was a line split between the two). Here you should see the Devanagari "OM" sign: . Here you should see a smiling face: . Here you should see the Chinese (or Japanese) character for "sun": . None of this should depend on your selected "document encoding". If you did not see all that, then your browser is broken and you should change it.
Recently I posted this comment mentioning the fact that there's really no reason why a domain such as www..com (you should see two Chinese ideograms meaning "China" between the "www." and the ".com" parts; further, if you click on this link, your browser should open a window telling you that the domain "www..com" does not exist, with the same two Chinese ideograms) doesn't exist.
Let us recall: first, as specified by the HTML specification, every HTML document, no matter what character set it is "encoded" as, is written in the all-englobing Unicode character set. So when you write something like "中国" in HTML, it refers to the Unicode characters (decimal) 20013 and 22269, no matter what the current character encoding and font are. So that's how you write the link text. Second, as for the URL itself, well, although it is not (as far as I know) formally recommended by an Internet standard, it is widely recognized that URLs are written in the UTF-8 encoding format (which is afterward %-encoded into ASCII).
The whole process is described in this Internet Draft ("Internationalized Uniform Resource Identifiers"; WORK IN PROGRESS!) by Larry Masinter and Martin Duerst where the relationship between URIs and IURIs (Internationalized URIs) is discussed in detail.
The DNS is the toughest part of all. The DNS specification (RFC1034) states (section 3.1) that DNS data is to be taken as binary for possible upward compatibility (this was wonderful foresight on Mockapetris' part!). Consequently, there is nothing as per standards wrong with using (UTF-8 encoded Unicode) 8-bit data in DNS labels. Except, of course, that many "buggy" implementations will have to be corrected for broken assumptions, *sigh*. The IDNS working group suggests using a UTF-5 encoding to avoid going beyond the current domain name limits: I think this is not a good thing and we should stick to UTF-8 and repair broken software.
Oh, and incidentally, see this page too know how broken your browser's Unicode support is.
Roughly [socialism is] the collective or governmental ownership and administration of a nations resources and means of production.
No. That's communism. And that's not what we're discussing. Evidently nobody suggested that the European Union should nationalize AOL and/or Time Warner. That would be both stupid and impossible; and that would be communism. We're discussing forbidding the merger: this is about socialism. It's about protecting the consumer and the worker from excessive corporate power.
Evidently the governments of Western Europe are not communist. But there is not the shadow of a doubt that Tony Blair is more socialist than Margaret Thatcher (or even John Major); that Gerhard Schröder is more socialist than Helmut Kohl; that Lionel Jospin is more socialist than Alain Juppé; and that Romano Prodi (or even Massimo Dalema) is more socialist than Silvio Berlusconi. I'm not saying that there's a definite trend here: the goverments of Spain and Austria are definitely right-wing. But I definitely fail to see a trend of "replacing this dangerous socialism by sane libertarianism" in Europe.
Let us know when [France's] unemployment rate drops below 10%, willya?
It is below 10%: you can find the official figures here (provided you can read French, of course). Remember, incidentally, that the European definition of "unemployed" is broader than the American one so that comparison is biased.
Along that line I could ask you to let "us" know when your poverty level (percentage of population whose income is less than half the national median) drops below 10%, but I frankly don't care. If you want to see an interesting comparison of the US with other rich world countries, see e.g. this page, it's very instructive and you'll learn that several countries can "keep up with the US" as you put it. But this is widely off topic.
A little more to the point, you say you think that they [European countries] became less socialistic. There is no doubt that Eastern European countries did (though in some countries, e.g. Russia, economic disaster has brought the communists back in popularity), but as far as Western European countries go, well, I have some news for you: the United Kingdom has a labor government; Germany is governed by a socialist / ecologist coalition; the socialist party heads the government in France, and there are several communist ministers; Portugal has a socialist government; Italy is governed by a coalition that is moderately left wing; and, you may believe it or not, but we have free elections even East of the Atlantic, and these various governments were freely chosen by the people. The European Parliament, on the other hand, has a comfortable right-wing majority. Also freely chosen.
The plain fact is not that socialism is good or bad; the plain fact is that you do not have a clue what socialism is.
You once got an AOL CD? I could tile the walls of my room with them. Yes, AOL is very much present in Europe.
...how often we will see the word "socialist" written in the comments of this discussion.
Slashdotters have a very peculiar vision of History: it seems they believe that after the fall of the Berlin[*] wall every European country became socialist.
They also for the most part believe that this is none of the European Union's affairs.
So we're going to see a looot of posts along the lines of:
(Plus insert perhaps a bit about guns, just to make the point.)
Will those who are about to post something of similar content please reconsider? Do you truly believe the European Commission to be so stupid not to have noticed that AOL stands for "America" On Line?
--
[*]Actually, I suspect many would be unable to place Berlin on a map of Europe; they'd probably place it where Prag is. But that is irrelevant.
When Baron Pierre de Coubertin "reinvented" the Olympic Games in 1896, amateurism was one of his dearest principles, and he ruled that professional athletes would not be permitted. I don't remember when that rule was suppressed, but it seems like a looong time ago.
On the other hand, Coubertin's ideas were sometimes very dubious, if not outright fascist (pardon the anachronism) so one should not be too eager to rant about the (g?)Olden Days.
And they measure that distance continuously. It used to be true that the Earth-Moon distance was known with better precision than the distance between London and New York, in fact.
Not to mention the newly opened French subsidiary, amazon.fr. In France, the law on personal data stored on computers is extremely strict (borderline paranoid, in fact).
Now if such a customer file is shared by amazon between several countries, it must be kept in compliance with the law of every country in question.
So if you're not happy with amazon keeping personal info on your subject, go to amazon.fr, check that the info is indeed shared with amazon.com, and write them ("them" being amazon.fr) a letter (in formal French, of course) stating that you wish to exercise the rights vested upon you by article 36 of the aforementioned law 78-16 of january 6, 1978, and that in compliance with that law they must strike the information concerning you from the record (you can claim, e.g., that it is obsolete). Somehow I doubt they'll make a special effort to remove the info in amazon.fr and not in amazon.com, so they'll have to remove it completely.
(I only mention French law because I know that particular one. But maybe German or English law (for amazon.de or amazon.co.uk) could let you achieve the same results.)
Somehow I feel that we'll have to stand the "socialist Europe" cliché again...
A lot of people have pointed out that "ah, it doesn't matter, we can point to search engines that locate the code", or something of that kind.
Only this doesn't work, because if every direct link to the code is removed (I'm not saying it will be - I'm just pointing out that the argument is flawed), the search engines probably won't index it forever.
I've just tried that (using nmap). But we don't get much info:
I suspect this is not a true Microsoft IIS server. I suspect it is really some Perl script running on FreeBSD that was hacked in a minute and that pretends to be Microsoft IIS (what the heck, all it has to do is send one redirect reply: do you really want to run a full web server for that?). And, of course, the guy who wrote that didn't bother to read the specs.
Yes, this is a conflict of standards, because the quoted section of the RFC (or its later revision, RFC2616, page 26) says
(Thus the HTML spec, strictly speaking, is in error: the HTTP protocol doesn't "mention" ISO-8859-1, and it's default use isn't a "recommendation" - it's a MUST. But it is certainly right in calling it "useless".)
IMHO the correct way to proceed is for HTML authors to use a meta http-equiv tag to specify the character set. Of course, an even better solution is to use XHTML, since the encoding is specified in the XML declaration; and the XML specification is clear on the subject:
Even better: write XHTML, use an XML character set declaration and add a meta http-equiv tag just to make sure...
...and just use ASCII :-)
I don't really see the point of encoding everything in ASCII (UTF-5) rather than using actual (UTF-8 encoded) 8-bit data in domain names: RFC1035 (Domain Names - Implementation and Specification) explicitely states (see section 2.3.3) that implementations should preserve all binary data verbatim. We don't need any new standards: the standards are already there.
In case this wasn't perfectly clear: my post contains several Asian characters. These should appear as such no matter what the "document encoding" is set to.
Ah, one of my favorite pet peeves. You've completely misunderstood the way Unicode works on web pages; but it's not really your fault, it's because Netscape Navigator is completely broken in this respect (it's far more - and far worse - than broken, in fact).
Neither the HTTP headers sent by Slashdot nor the preamble of the HTML file specify a character encoding. Therefore the encoding is the default encoding, i.e. ISO-8859-1 (aka latin-1). What you've written, then, is not "sayonara" but "comma cube comma ae comma E-grave comma c-cedilla". If you see anything else, your browser is broken! You've posted Shift_JIS-encoded data in an ISO-8859-1-encoded page and that doesn't make sense.
Now this does not mean that you can't have Japanese in HTML, even if the page is encoded as ISO-8859-1. Indeed, "at the bottom", every HTML document is written in Unicode, and every Unicode character is available, if not readily though the encoding (not necessarily UTF-8), then at least through SGML numeric entities of the form &#xxxxx; (where xxxxx is the decimal form of the Unicode character number). Consequently, the correct way of posting "sayonara" is "" (which I've written as "㇁よなら"). Again, if you see anything else than the hiragana for "sayonara" here (or perhaps a transcription of it, e.g. with lynx), especially if you see latin-1 characters, again, your browser is broken.
The brokenness about Netscape is that it assumes that numeric SGML character entities are to be interpreted in the current document encoding, and that is completely wrong. They should always be interpreted as Unicode character numbers. So this has somehow led to the conception that the basic HTML character data is in the character set of the encoding, which it is not! Fortunately, Mozilla repairs this brokenness, hopefully before any serious damage is done.
I posted another comment on this article to the effect that you can even have valid Chinese characters (in my example, , i.e. "China" in Chinese) in the host name part of a URL. It just happens that such domain names are not given out, but there is nothing wrong with it.
For more examples of Unicode and to see how badly your browser is broken, follow this link.
Sorry about the rant. .