if the Internet had started in China (which would have been absolutely bizarre)
What's so bizzare about the idea? It's an alternate history idea, and there will of course be different events (I'd make the divergence China a republic sometime in the 50 years before 1930 . ..)
they probably would have used ascii characters, or some set of latin characters.
If your alternate history still calls for the predominance of US computing and ASCII/ISO-646, then they probably would have used some ASCII based system. Otherwise I see no reason for that; if an alphabet was needed, they could have used Bopomofo (Chinese phonetic characters), or Cyrillic or Katakana.
if they used Chinese symbols, then it wouldn't have gone outside the country until a different format came about.
Depends on the economic importance of the Chinese net. If Chinese was the language of computing, there wouldn't be a problem. Even if it wasn't, it's possible that people would have put it up with it and added ad-hoc changes to make it work with their languages.
Latin characters are easier to recognize and use than Chinese symbols (there are only 26 of them!). And just about every computer-aware culture is familiar with these 26 letters (since before the Internet).
But Chinese characters are more concise than Roman characters. In any case, everything you've said applies with equal power to Cyrillic; a Sino-Russian web would probably have used Cyrillic as a base.
I'm trying not to sound like a lingual elite-ist by any means, but can anyone really say that we shouldn't standardize on English/ASCII?
The 5 billion people in the world who don't have English as their native language might. Some would argue that language is a cornerstone of culture, and that when a society loses their language, they lose a significant part of their culture. I've read parts of Shakespeare in German, and was very unhappy about the destruction of the writing. I know several poets of my native tongue (Poe, in particular) would be lost completely in translation. I have no interest in condeming other people to reading the great literature of their cultures in translation.
In any case, ASCII isn't good enough for English writing. French accents are used in English writing, as well as the ae and oe ligatures. Even in modern writing, proper quotes and apostraphes are needed, and footnote daggers often show up in English writing. For specialized work, mathematics, linguistics (even of English), historical English writing and APL all have thier own body of characters outside ASCII that need supported.
W3C has a page on the subject. I don't know why it doesn't work in your case; I suspect you're dealing with character set issues, but you didn't mention what webbrowser you were using or anything, so it's hard to tell what went wrong.
but how can you (or a avarage user) send an email to say müller@müller.de using an english keyboard?
Yes, with the right ALT- combinations. Or you can cut and paste.
Sure, one might want to think twice about using müller@müller.de as an email address if you want to communicate with people who won't find that easy to type from their keyboard. But I don't think that's choice that should be imposed from the outside.
actually as it stands right now you can not have åöä in your address
You can't have it in the domain name. You can have it in the part of the URL following the domain name.
å is actually another letter entirely, something lots of english speakers can't get the grasp of.
I would be surprised to find many English speakers who couldn't learn that. I would expect that most of them just don't know that fact right now, and that many of them really don't care.
Solution: Make brovsers default to displaying links to sites with non-ascii address different from regular links
You're treating Unicode URL's as something wrong. They aren't, and a program should not usually annoy users using normal features of the standard.
A much better solution is to detect anomalous URL's (those with mixed scripts) and display them differently in the address box. Since a website can't do anything bad to your computer (and if it can, then that's a serious bug in the browser that needs to be fixed), you don't need to worry about links; just telling whether a site isn't authentic. If your users won't check the address bar, then ASCII links will have no problem spoofing them, either.
The only true way to security is to annoy your users into submission
It tends to make people not want to use your products. It induces random fear and doubt in others. What popping up random boxes for normal events tends not to do, is help users be any safer. It's amazing how fast I can click [yes] on Windows' dialog boxes, before I can even really check what they say.
Would be really slow to use some funky custom sorting routine.
What are you running? There are massive databases that use binary compare, and bitty boxes that use binary compare, but even my 386 should be able to do decent sorting in a negligable amount of time.
I don't know of many character sets that put the characters in sort order. ASCII doesn't work for English, because capital letters and lower case letters don't sort together. Latin-1 puts all its characters after ASCII, when some of them should sort with the ASCII characters.
As for why, the fact is it's not an option in a multilingual enviroment. Lithuanian sorts y after j; Swedish, German and Danish use some of the same accented characters, but sort them differently. The whole concept of binary sorting fails for some languages; Maltese and traditional Spanish both sort two letters ("ch" and "ll" for Spanish) as if they were one, and German sorts one letter ("ß") as if it were two ("ss").
But what if you see an email address on a business card, say ñà@miñrîsîft.com? How do you know what encodings are those 'c', 'a' and 'o' are in[...]?
Since the surrounding characters are Latin, I think it safe to assume they are 'c', 'a' and 'o'. (BTW: encodings are things like ISO-8859-*, KOI8-R, and so on, which the IDN will only use Unicode. The question should be what script they are in.)
Same goes for URLs, etc.
You've never been prohibitied from using non-ASCII stuff in URLs.
Another option -- say a Swedish company registers an URL that perfectly represent the name of the comapny in Swedish. With all those umlauts and whatever-they-are-called-those-circles-over-A. And you are sitting there with a US_en keyboard -- how are you expected to type that URL into a location field in your browser?
Depending on your system, you can use ALT- or SHIFT-CTRL- combinations and the character numbers. Character Map or the equivelent will also let you enter the characters in.
OTOH, why is this a problem? If they have a large non-Swedish audience, they ought to register an all-ASCII name. If they chose not to, then that's their problem. Odds are any such site will be in Swedish for Swedes.
Unicode certainly has its quirks, and this is one of the more obvious ones. I fail to see why it has been implemented so widely, without very, very rigorous testing.
It was tested; this is considered acceptable, as there are no workarounds.
There will be look alikes in Unicode, just like there are in ASCII. Prior character sets, including KOI8-R, ISO-8859-5, ISO-8859-7, and JIS X0213 - pretty much every character set with either Cyrillic or Greek in it - have the Cyrillic or the Greek A seperate from the Latin A. Besides backward compatibility, proper multilingualization calls for them to be kept seperate; what's the lowercase A look like, if the Greek and Latin A are merged?
And, despite that "delaying" factor, movies come out at the same time as they do in the US.
Because most Canadians live within a hundred miles of the US border and speak English, if you tried to release them later in Canada than the US, it would probably make Canadian distribution unprofitable. So you just factor in the time for dubbing anyway.
What if a film isn't in English or French? Does it have to be subbed anyway, even if the creators don't want to? What about French? Or is it only English which has to submit to this?
Not many. Virtually invincible and practical beats the heck out of invicible and clumsy for most.
You're grossly exaggerating the insecurity here.
Not really. If you loop over, breaking the code is trivial. If your noise algorithm really wasn't that great after the first few bytes (and/dev/random quite possibly isn't), breaking the code is trivial.
Yes, of course the NSA will announce when they've broken 3DES or Blowfish.
Civilian cyrtographers been working on block-algorithms like DES and Blowfish for many years now; even with the advance in knowledge and technology since DES was created, we still can't easily break DES. The only way we can think of to break it would take very expensive hardware that no civilian has. Given what we know about DES and DES-like algorithms, Blowfish or 3DES, given a secure password, can't be broke by any means known to man; all cracking algorithms would take longer than the expected lifetime of mankind. And if there were a shortcut, then the NSA would be moving the government away from DES and Blowfish-like cyphers; but they aren't.
Unless you're completely paranoid, the only reasonable guess is that they haven't cracked 3DES or Blowfish. And if you are, then I'd worry about the orbital mind-control lasers first.
What I'm talking about is allowing novice users to create any number of trivial algoritms,
95% of those algorithms aren't going to make cracking it any harder. Ceasar cyphers and the like don't change the enthropy of the message. Furthermore, they don't stack; they merge, meaning two of the algorthms make just another trivial algorthim of the same type. Worse yet, if you let novice users create encryption algorithms, some of them will mangle their data beyond recovery.
You can't just stack a bunch of trivial algorithms on top of each other and get a good algorithm. What you get is a trivial algorithm, and likely a trivial algorithm that is known and simple. And if you let novices at it, quite likely a trivial algorithm that doesn't work.
I don't see one-time pads listed there. The one algorithm that is provably undecipherable and it's not available to me.
You're a programmer; that's a program for a first-year student. There's so many possible formats for a one-time pad - I can't imagine a generic program that would support your CD-ROM idea. Given how insecure one-time pads are, if not used carefully, and how much a PIA they are to use, if used carefully, I really don't see the point in such an addition to GPG.
If the NSA wants to decrypt any one of these, they can.
There's no evidence they can break 3DES or Blowfish.
But if everyone were to adopt this kind of approach, the NSA would not be able to routinely decrypt our messages.
They would be able to decrypt any message they wanted to; half the time they would just feed them to a computer, the computer would run the top 50 trivial algorithms, and spit out the answer.
The complexity increase is not n times but rather n factorial
A complexity increase that can disappear in an instant, and comes at the cost of using a good algorithm.
Algorithms can be applied in daisy-chain fashion upon other algorithms.
Which, in some cases, will render them worthless as they counteract each other.
Yes, a decent cryptoanalyst will tear apart a trivial algorithm, but how many decent cryptoanalysts are there?
If you don't want to keep it from a decent cryptoanalyst, why bother using serious encryption in the first case?
For instance, two friends at graduation who are going their separate ways, agree to rip a CD using/dev/random, make a copy, and use those 680MB to encrypt the emails they send to one another... for life. Very cool, very doable... very unbreakable.
I don't know how many years it would take to get 680MB from/dev/random, but it isn't going to be quick. In any case, who cares? Add a patch to GPG to do this, but don't think there will be many users.
the NSA will be swimming in complexity... a kind of complexity they can't easily leverage their hardware to tame.
I would be surprised. One good algorithm used by the people they want to watch would give them trouble. A thousand lousy ones will merely make their jobs more interesting - "hey, look, here's another idiot using MD4. Haven't seen that in a while."
gnupg is great, but it presumes a single algorithm, doesn't it?
No. Everything's done by pluggable modules, and there are several choices of algorithm.
But if he first has to figure out what algorithm is being used, suddenly his job becomes many orders of magnitude harder.
It becomes n times harder, where n is the number of algorithms. Assuming, of course, that each of those algorithms is equally secure. In practice, there are a handful of algorithms that have been pounded hard enough to believe secure. Many other algorithms, especially those done by an untrained amature, will fall apart under the hands of a decent cryptoanalyist. It's much better to double your key length then to try and make choice of algorithm part of the encryption. (GPG includes the algorithm choice in plain text due to this principle.)
It's interesting that the literate programming tool I'm most familiar with, noweb (because it's not bound to any one programming language, and I don't usually program in C or Pascal), isn't itself a literate program, because a literate program was too much work according to the author. The only major literate programs I'm familiar with are those written by Donald Knuth.
Teraterm [vector.co.jp] is an excellent open-source terminal emulator for Windows machines [...] 1) the weird license prohibits distributing any fixes to the core code
(and the most famous time they did-- Plessy v. Ferguson being overturned by Brown v. Board of Ed of Topeka, took 58 years).
But Minersville School Dist. V. Gobitis (1940) was overturned by West Virginia State Bd. of Educ. v. Barnette (1943) in just three years, and unlike Plessy v. Ferguson, this doesn't radically effect whole social systems.
Because "case blah:" statements are basically labels.
Why? Only because the creators of C chose it to be. There are many other languages - pretty much every non-C based descendent of Algol - where case labels are clearly control statements and clearly end the block.
What would the founding fathers think if you couldn't EVEN publish a list of your enemies?
This goes way beyond publishing a list of thier ememies; it approaches the conspiracy to commit murder range, which I think the founding fathers wouldn't have approved of.
I'm not sure that all of the founding fathers were that big on the freedom of speech either, considering the Sedition Acts were passed during Madison's term.
Why should people not have the right to advocate murder of individuals, when the state has the right to advocate and execute murders.
Under the social contract theory, we give any right we have to threaten and kill to the state, so that the state can produce a civilized society.
OSS is generally NOT put up to the same design methodology or testing standards as the software running on a Boeing 777
No non-embedded software is, open-source or not. They slam GNU for "pretty much ignoring the need for competence and expertise on the part of software developers", but tests on GNU utilities in 1990, 1995 and 2001 showed them to be more reliable than the equivelent utilities that come with Solaris. I won't praise the quality of all free software, but often ego and sufficent time to get it right beats the heck out of money and short deadlines.
If speed is an issue, then you'd nearly always choose the native compiler.
This isn't automatically true. When GCC was first ported to the Sun, it beat the native compiler by, IIRC, 30%. While I have no recent numbers, it wouldn't surprise me if this were still true in some cases; GCC has a lot of optimization work done on it, and the hardware vendor may not have the ability to produce a highly optimizing stable compiler. The ix86, a CISC chip that brings in loads of cash for its maker, is of course an exception.
Supporting multiple compilers does introduce extra issues because lazy programmers will rely on a portable compiler instead of writing portable code.
The set of strictly conforming C or C++ programs isn't very large, and the set of C or C++ compilers guarenteed to work correctly is empty. How much work one should take to work around the bugs and hideous malfeatures of many compilers instead of dealing with the bugs and hideous malfeatures of just one compiler is up to the programmer; many programs aren't worth the trouble to get them running for the people who insist on compiling them with WeirdC (we've been working towards ANSI C for almost twenty years now!).
If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.
OpenMP isn't available, but threading is; you can use various forms of native threads for C or C++, or you can go straight to Java or Ada and let the compiler deal with the native threads.
If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.
It says "stay out" without trying too hard and inciting curiosity.
The problem is, it's just exactly the thing that would incite my curiosity. On one hand, we have something that's clearly human in origin; on the other, it's completely abnormal, inhospitable and irregular. Of course, it's only inviting to archeologists and other terminally curious people, who will be curious no matter how you mark it, so you might just have to write them off.
If the code isn't written with IEEE math in mind (and I suspect the vast majority of floating point code is written by people who not completely sure of the difference of real numbers and floating point numbers), then why not use -ffast-math?
A person who understands completely how floating point numbers work can handle whatever imprecisions tossed at them. People who don't know how floating point numbers work, in order to get usable results, are going to need every bit of precision the computer can give them - they don't need fast-math burning all their precision for speed. If all you need is a meaningless number, there are quicker algorithms. If you need maximum speed and meaningful results, then you had better learn how to use your tools correctly.
Show me one single large-scale implementation of communism that's actually worked. That's right, there aren't any.
Well, gee. On one hand, any one who wanted to set up a truly communist government had the US against him, willing to fund whatever tinpot dictator that's willing to take the US's money. On the other hand, he has the USSR and China against him, willing to fund whatever tinput dictator that's willing to take their money. (One example of this is the Spanish communists who were fighting against Franco, who were also fighting Soviet communists.) The odds of any surviving against every major superpower don't seem high.
Slashdot Mirror
if the Internet had started in China (which would have been absolutely bizarre)
.)
What's so bizzare about the idea? It's an alternate history idea, and there will of course be different events (I'd make the divergence China a republic sometime in the 50 years before 1930 . .
they probably would have used ascii characters, or some set of latin characters.
If your alternate history still calls for the predominance of US computing and ASCII/ISO-646, then they probably would have used some ASCII based system. Otherwise I see no reason for that; if an alphabet was needed, they could have used Bopomofo (Chinese phonetic characters), or Cyrillic or Katakana.
if they used Chinese symbols, then it wouldn't have gone outside the country until a different format came about.
Depends on the economic importance of the Chinese net. If Chinese was the language of computing, there wouldn't be a problem. Even if it wasn't, it's possible that people would have put it up with it and added ad-hoc changes to make it work with their languages.
Latin characters are easier to recognize and use than Chinese symbols (there are only 26 of them!). And just about every computer-aware culture is familiar with these 26 letters (since before the Internet).
But Chinese characters are more concise than Roman characters. In any case, everything you've said applies with equal power to Cyrillic; a Sino-Russian web would probably have used Cyrillic as a base.
I'm trying not to sound like a lingual elite-ist by any means, but can anyone really say that we shouldn't standardize on English/ASCII?
The 5 billion people in the world who don't have English as their native language might. Some would argue that language is a cornerstone of culture, and that when a society loses their language, they lose a significant part of their culture. I've read parts of Shakespeare in German, and was very unhappy about the destruction of the writing. I know several poets of my native tongue (Poe, in particular) would be lost completely in translation. I have no interest in condeming other people to reading the great literature of their cultures in translation.
In any case, ASCII isn't good enough for English writing. French accents are used in English writing, as well as the ae and oe ligatures. Even in modern writing, proper quotes and apostraphes are needed, and footnote daggers often show up in English writing. For specialized work, mathematics, linguistics (even of English), historical English writing and APL all have thier own body of characters outside ASCII that need supported.
W3C has a page on the subject. I don't know why it doesn't work in your case; I suspect you're dealing with character set issues, but you didn't mention what webbrowser you were using or anything, so it's hard to tell what went wrong.
but how can you (or a avarage user) send an email to say müller@müller.de using an english keyboard?
Yes, with the right ALT- combinations. Or you can cut and paste.
Sure, one might want to think twice about using müller@müller.de as an email address if you want to communicate with people who won't find that easy to type from their keyboard. But I don't think that's choice that should be imposed from the outside.
actually as it stands right now you can not have åöä in your address
You can't have it in the domain name. You can have it in the part of the URL following the domain name.
å is actually another letter entirely, something lots of english speakers can't get the grasp of.
I would be surprised to find many English speakers who couldn't learn that. I would expect that most of them just don't know that fact right now, and that many of them really don't care.
[...]pretty-much done all of the things that would allow me to be as arrogant as you try to be, that you haven't.
And at the grand old age of 25 (according to your webpage), too.
Solution: Make brovsers default to displaying links to sites with non-ascii address different from regular links
You're treating Unicode URL's as something wrong. They aren't, and a program should not usually annoy users using normal features of the standard.
A much better solution is to detect anomalous URL's (those with mixed scripts) and display them differently in the address box. Since a website can't do anything bad to your computer (and if it can, then that's a serious bug in the browser that needs to be fixed), you don't need to worry about links; just telling whether a site isn't authentic. If your users won't check the address bar, then ASCII links will have no problem spoofing them, either.
The only true way to security is to annoy your users into submission
It tends to make people not want to use your products. It induces random fear and doubt in others. What popping up random boxes for normal events tends not to do, is help users be any safer. It's amazing how fast I can click [yes] on Windows' dialog boxes, before I can even really check what they say.
How do you sort stuff alphabetically if you can't just do an integer comparison?
Unicode Sorting Algorithm.
Would be really slow to use some funky custom sorting routine.
What are you running? There are massive databases that use binary compare, and bitty boxes that use binary compare, but even my 386 should be able to do decent sorting in a negligable amount of time.
I don't know of many character sets that put the characters in sort order. ASCII doesn't work for English, because capital letters and lower case letters don't sort together. Latin-1 puts all its characters after ASCII, when some of them should sort with the ASCII characters.
As for why, the fact is it's not an option in a multilingual enviroment. Lithuanian sorts y after j; Swedish, German and Danish use some of the same accented characters, but sort them differently. The whole concept of binary sorting fails for some languages; Maltese and traditional Spanish both sort two letters ("ch" and "ll" for Spanish) as if they were one, and German sorts one letter ("ß") as if it were two ("ss").
But what if you see an email address on a business card, say ñà@miñrîsîft.com? How do you know what encodings are those 'c', 'a' and 'o' are in[...]?
Since the surrounding characters are Latin, I think it safe to assume they are 'c', 'a' and 'o'. (BTW: encodings are things like ISO-8859-*, KOI8-R, and so on, which the IDN will only use Unicode. The question should be what script they are in.)
Same goes for URLs, etc.
You've never been prohibitied from using non-ASCII stuff in URLs.
Another option -- say a Swedish company registers an URL that perfectly represent the name of the comapny in Swedish. With all those umlauts and whatever-they-are-called-those-circles-over-A. And you are sitting there with a US_en keyboard -- how are you expected to type that URL into a location field in your browser?
Depending on your system, you can use ALT- or SHIFT-CTRL- combinations and the character numbers. Character Map or the equivelent will also let you enter the characters in.
OTOH, why is this a problem? If they have a large non-Swedish audience, they ought to register an all-ASCII name. If they chose not to, then that's their problem. Odds are any such site will be in Swedish for Swedes.
Unicode certainly has its quirks, and this is one of the more obvious ones. I fail to see why it has been implemented so widely, without very, very rigorous testing.
It was tested; this is considered acceptable, as there are no workarounds.
There will be look alikes in Unicode, just like there are in ASCII. Prior character sets, including KOI8-R, ISO-8859-5, ISO-8859-7, and JIS X0213 - pretty much every character set with either Cyrillic or Greek in it - have the Cyrillic or the Greek A seperate from the Latin A. Besides backward compatibility, proper multilingualization calls for them to be kept seperate; what's the lowercase A look like, if
the Greek and Latin A are merged?
And, despite that "delaying" factor, movies come out at the same time as they do in the US.
Because most Canadians live within a hundred miles of the US border and speak English, if you tried to release them later in Canada than the US, it would probably make Canadian distribution unprofitable. So you just factor in the time for dubbing anyway.
What if a film isn't in English or French? Does it have to be subbed anyway, even if the creators don't want to? What about French? Or is it only English which has to submit to this?
That makes it ideal for certain applications.
/dev/random quite possibly isn't), breaking the code is trivial.
Not many. Virtually invincible and practical beats the heck out of invicible and clumsy for most.
You're grossly exaggerating the insecurity here.
Not really. If you loop over, breaking the code is trivial. If your noise algorithm really wasn't that great after the first few bytes (and
Yes, of course the NSA will announce when they've broken 3DES or Blowfish.
Civilian cyrtographers been working on block-algorithms like DES and Blowfish for many years now; even with the advance in knowledge and technology since DES was created, we still can't easily break DES. The only way we can think of to break it would take very expensive hardware that no civilian has. Given what we know about DES and DES-like algorithms, Blowfish or 3DES, given a secure password, can't be broke by any means known to man; all cracking algorithms would take longer than the expected lifetime of mankind. And if there were a shortcut, then the NSA would be moving the government away from DES and Blowfish-like cyphers; but they aren't.
Unless you're completely paranoid, the only reasonable guess is that they haven't cracked 3DES or Blowfish. And if you are, then I'd worry about the orbital mind-control lasers first.
What I'm talking about is allowing novice users to create any number of trivial algoritms,
95% of those algorithms aren't going to make cracking it any harder. Ceasar cyphers and the like don't change the enthropy of the message. Furthermore, they don't stack; they merge, meaning two of the algorthms make just another trivial algorthim of the same type. Worse yet, if you let novice users create encryption algorithms, some of them will mangle their data beyond recovery.
You can't just stack a bunch of trivial algorithms on top of each other and get a good algorithm. What you get is a trivial algorithm, and likely a trivial algorithm that is known and simple. And if you let novices at it, quite likely a trivial algorithm that doesn't work.
I don't see one-time pads listed there. The one algorithm that is provably undecipherable and it's not available to me.
You're a programmer; that's a program for a first-year student. There's so many possible formats for a one-time pad - I can't imagine a generic program that would support your CD-ROM idea. Given how insecure one-time pads are, if not used carefully, and how much a PIA they are to use, if used carefully, I really don't see the point in such an addition to GPG.
If the NSA wants to decrypt any one of these, they can.
There's no evidence they can break 3DES or Blowfish.
But if everyone were to adopt this kind of approach, the NSA would not be able to routinely decrypt our messages.
They would be able to decrypt any message they wanted to; half the time they would just feed them to a computer, the computer would run the top 50 trivial algorithms, and spit out the answer.
The complexity increase is not n times but rather n factorial
/dev/random, make a copy, and use those 680MB to encrypt the emails they send to one another... for life. Very cool, very doable... very unbreakable.
/dev/random, but it isn't going to be quick. In any case, who cares? Add a patch to GPG to do this, but don't think there will be many users.
A complexity increase that can disappear in an instant, and comes at the cost of using a good algorithm.
Algorithms can be applied in daisy-chain fashion upon other algorithms.
Which, in some cases, will render them worthless as they counteract each other.
Yes, a decent cryptoanalyst will tear apart a trivial algorithm, but how many decent cryptoanalysts are there?
If you don't want to keep it from a decent cryptoanalyst, why bother using serious encryption in the first case?
For instance, two friends at graduation who are going their separate ways, agree to rip a CD using
I don't know how many years it would take to get 680MB from
the NSA will be swimming in complexity... a kind of complexity they can't easily leverage their hardware to tame.
I would be surprised. One good algorithm used by the people they want to watch would give them trouble. A thousand lousy ones will merely make their jobs more interesting - "hey, look, here's another idiot using MD4. Haven't seen that in a while."
gnupg is great, but it presumes a single algorithm, doesn't it?
No. Everything's done by pluggable modules, and there are several choices of algorithm.
But if he first has to figure out what algorithm is being used, suddenly his job becomes many orders of magnitude harder.
It becomes n times harder, where n is the number of algorithms. Assuming, of course, that each of those algorithms is equally secure. In practice, there are a handful of algorithms that have been pounded hard enough to believe secure. Many other algorithms, especially those done by an untrained amature, will fall apart under the hands of a decent cryptoanalyist. It's much better to double your key length then to try and make choice of algorithm part of the encryption. (GPG includes the algorithm choice in plain text due to this principle.)
It's interesting that the literate programming tool I'm most familiar with, noweb (because it's not bound to any one programming language, and I don't usually program in C or Pascal), isn't itself a literate program, because a literate program was too much work according to the author. The only major literate programs I'm familiar with are those written by Donald Knuth.
Teraterm [vector.co.jp] is an excellent open-source terminal emulator for Windows machines [...] 1) the weird license prohibits distributing any fixes to the core code
Then it's not open-source, is it?
(and the most famous time they did-- Plessy v. Ferguson being overturned by Brown v. Board of Ed of Topeka, took 58 years).
But Minersville School Dist. V. Gobitis (1940) was overturned by West Virginia State Bd. of Educ. v. Barnette (1943) in just three years, and unlike Plessy v. Ferguson, this doesn't radically effect whole social systems.
Because "case blah:" statements are basically labels.
Why? Only because the creators of C chose it to be. There are many other languages - pretty much every non-C based descendent of Algol - where case labels are clearly control statements and clearly end the block.
What would the founding fathers think if you couldn't EVEN publish a list of your enemies?
This goes way beyond publishing a list of thier ememies; it approaches the conspiracy to commit murder range, which I think the founding fathers wouldn't have approved of.
I'm not sure that all of the founding fathers were that big on the freedom of speech either, considering the Sedition Acts were passed during Madison's term.
Why should people not have the right to advocate murder of individuals, when the state has the right to advocate and execute murders.
Under the social contract theory, we give any right we have to threaten and kill to the state, so that the state can produce a civilized society.
OSS is generally NOT put up to the same design methodology or testing standards as the software running on a Boeing 777
No non-embedded software is, open-source or not. They slam GNU for "pretty much ignoring the
need for competence and expertise on the part of software developers", but tests on GNU utilities in 1990, 1995 and 2001 showed them to be more reliable than the equivelent utilities that come with Solaris. I won't praise the quality of all free software, but often ego and sufficent time to get it right beats the heck out of money and short deadlines.
If speed is an issue, then you'd nearly always choose the native compiler.
This isn't automatically true. When GCC was first ported to the Sun, it beat the native compiler by, IIRC, 30%. While I have no recent numbers, it wouldn't surprise me if this were still true in some cases; GCC has a lot of optimization work done on it, and the hardware vendor may not have the ability to produce a highly optimizing stable compiler. The ix86, a CISC chip that brings in loads of cash for its maker, is of course an exception.
Supporting multiple compilers does introduce extra issues because lazy programmers will rely on a portable compiler instead of writing portable code.
The set of strictly conforming C or C++ programs isn't very large, and the set of C or C++ compilers guarenteed to work correctly is empty. How much work one should take to work around the bugs and hideous malfeatures of many compilers instead of dealing with the bugs and hideous malfeatures of just one compiler is up to the programmer; many programs aren't worth the trouble to get them running for the people who insist on compiling them with WeirdC (we've been working towards ANSI C for almost twenty years now!).
If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.
OpenMP isn't available, but threading is; you can use various forms of native threads for C or C++, or you can go straight to Java or Ada and let the compiler deal with the native threads.
If you need OpenMP / threaded code, then gcc/gdb aren't even in the race.
It says "stay out" without trying too hard and inciting curiosity.
The problem is, it's just exactly the thing that would incite my curiosity. On one hand, we have something that's clearly human in origin; on the other, it's completely abnormal, inhospitable and irregular. Of course, it's only inviting to archeologists and other terminally curious people, who will be curious no matter how you mark it, so you might just have to write them off.
If the code isn't written with IEEE math in mind (and I suspect the vast majority of floating point code is written by people who not completely sure of the difference of real numbers and floating point numbers), then why not use -ffast-math?
A person who understands completely how floating point numbers work can handle whatever imprecisions tossed at them. People who don't know how floating point numbers work, in order to get usable results, are going to need every bit of precision the computer can give them - they don't need fast-math burning all their precision for speed. If all you need is a meaningless number, there are quicker algorithms. If you need maximum speed and meaningful results, then you had better learn how to use your tools correctly.
Show me one single large-scale implementation of communism that's actually worked. That's right, there aren't any.
Well, gee. On one hand, any one who wanted to set up a truly communist government had the US against him, willing to fund whatever tinpot dictator that's willing to take the US's money. On the other hand, he has the USSR and China against him, willing to fund whatever tinput dictator that's willing to take their money. (One example of this is the Spanish communists who were fighting against Franco, who were also fighting Soviet communists.) The odds of any surviving against every major superpower don't seem high.