There's no direct evidence that the document is forged. There's also no direct evidence that it's genuine, or even what "genuine" would mean. There are stories vaguely associating it with various interesting people, such as John Dee and Roger Bacon, but they're all pretty vague.
People have been studying this document for the better part of a century, because it's fascinating, enigmatic, and beautiful. (You can find some pictures of it at www.voynichinfo.com) We know a bit more than we did about what kinds of hypotheses are plausible and what kinds are not. For example: we can be pretty sure that it is not written in any natural language. We can also be pretty sure that it isn't just a simple substitution cipher. Finally, we can be pretty sure that it isn't a 20th century forgery: it has been given a rough date, it really does look like a manuscript from the 15th or 16th century, and it probably was once owned by Rudolf II. The Roger Bacon rumors are almost certainly false, because the manuscript doesn't appear to be that old. The John Dee rumors may be true.
At present the two most plausible guesses are that it is a real 15th or 16th century treatise on an occult subject, written in a code that has yet to be broken, or that it's a good imitation of an encoded occult text. If the latter, it was probably written specifically for the purpose of fooling Rudolf. It is known that he was fascinated by the occult (there's even an opera where that's a crucial plot point), and it is known that many of the astrologers and alchemists he patronized were quacks and that many of the texts he bought were forgeries.
What's interesting about this research isn't that it's a new argument against the possibility that the manuscript is genuine, but that it's a good counterargument. Until now, many people argued that the manuscript wasn't likely to be a forgery because the text followed a certain statistical property of natural languages (Zipf's law) that weren't known until the 20th century. Thus, the argument goes, it's unlikely to be a 16th century fake because a 16th century forger, inventing a fake code or a fake language, wouldn't have known to match this statistical distribution.
The reason this work is interesting is that it shows that this argument is invalid: there is a plausible method that a 16th century forger might have used that might have produced such a document. This doesn't show that it really is a 16th century forgery, it only shows that there's one fewer argument against that possibility than we once believed.
In the end, of course, we're unlikely to ever have decisive evidence that the manuscript is fake. Either someone will come up with a believable decryption (several people claim to have done it already; none of their claims have stood up), or people will keep trying and failing. The longer scholars bang their heads against the wall trying to get a translation, the less likely people will think it is that there really is one. Messy, but that's the way the world works. Sometimes you don't get to learn for sure whose guess is right.
HR2239 and evoting machines shouldn't be a partisan issue. Yes, Kucinich seems to be a decent man if you happen to share his political views. But everyone, no matter what their political views are, should care about honest and accurate elections.
You need to distinguish a paper receipt (which, as you point out, is wastepaper or worse) and a paper ballot that gets counted. Using the same word, 'receipt", for such different concepts, is a bad mistake.
This is what Rebecca Mercuri describes as the Voter Verified Balloting concept. She discusses it in her dissertation, and in a RISKS digest article.
The article makes it clear that we're dealing with fundamental issues of democracy, not with details of computer implementations. The rest of the world is not impressed by the US's infatuation with evoting.
A better approach, I believe, would have been to take the traditional paper-punch machines and simply add some hardware to electrically detect what holes were punched.
What's so traditional about the paper-punch ballot? The only reason some American counties use punch cards is that they're cheap. They're not particularly accurate, they're not particularly easy to use, and they're not particularly easy to count without complicated and fragile machinery.
A better voting technology to start from are the optically scanned ballots. The voter draws a line between two arrows or fills in a bubble. It's easy to use, it has been shown to be more accurate than punch cards, and it's fairly easy to count by hand. It's used a fair amount in the US; it's the system they use in San Mateo County, for example. It's easy to extend the optical scan systems to give voters instant feedback on their choices. It's slightly more expensive than punch cards, which is the only reason I can think of that the US hasn't gotten rid of punch cards long ago.
And, of course, in lots of other countries ballots are just ink on paper, counted by hand in public. This is a perfectly fine system too, and lots of countries find that it works well.
The first Common Lisp standard was published in 1984. The Ada 95 standard was published in 1995. (Depending on your definition of "object oriented" you might argue that Ada 83 was an object-oriented language, but most people don't seem to say that.)
Re:What's wrong with national IDs?
on
Beyond Fear
·
· Score: 2, Insightful
I don't understand why Americans are so afraid of national ID cards.
Read the book. This is one of the cases that he analyzes. The questions to ask about national ID cards is the same as for any security measure: what assets are you trying to protect, what threats are you trying to protect against, how well does this measure work to reduce the risks from those threats, what new threats does it introduce, and so on.
I can see ways in which a national ID card could be useful. I do not see that it could be useful as a security measure. I can see ways in which it could hurt security. (It could increase the risk of identity theft, for example, by creating a new database with security issues of its own.)
But again: read the book. If I were to present a complete security analysis of national ID cards I'd just be ripping off Bruce Schneier anyway, so you'd be better off getting it from the original than from my summary.
Re:Best example of how to speak about Security
on
Beyond Fear
·
· Score: 1
The discussions of door locks and car theft and bank vaults aren't metaphors. They're examples. He's showing concrete cases where one makes judgments about security.
Remember: this is not a book about computer security. It's not trying to teach you about password management techniques (although he does use password lists as yet another example, since they're yet another everyday security issue for most of us) or firewall configuration. It's trying to teach you how to think about security in general.
To the extent that this book is trying to teach you about any particular area of security, it's not computers but terrorism. The author is very specific about that in the introduction: he was motivated to write this book because security has recently become a hot topic. There's lots more discussion of security than there was two and a half years ago, a lot more proposals for things that will supposedly make us secure, and lots of that discussion and those proposals are wrong. This book is an attempt to make an important national discussion more intelligent.
The name isn't C++0x. The name will be C++. People are informally saying "C++0x" in the same way they were saying C9x: because it's expected that the next revision of the C++ standard will be released some time within the next seven years. Similarly, people informally refer to "C++98", meaning C++ as described in the 1999 ISO standard.
It's the same deal as with C: people sometimes refer to "C90" (i.e. the version of C specified in the 1994 ISO standard), "C94" (C90 plus the 1994 normative addendum), and "C99" (the version of C specified in the 1999 ISO standard).
For those who don't recognize the quote, the exact wording is: "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." It comes from Richard Feynman's appendex to the Rogers Commission report on the Challenger.
Mark's recursive-descent parser isn't faster than the 3.3 yacc-based parser right now, but there also has been zero performance tuning at this point. There's reason to think that it will be faster once there has been tuning.
That is: there are a number of places where it's known that the recursive descent parser can be made faster if someone just does the work. There doesn't seem to be similar scope for improvement in the old yacc-based parser.
I don't understand this. Inlining is an optimization -- it has no semantic effect. How could failure to inline cause something to break?
If you're writing nonportable low-level code (which wouldn't be too extraordinary in a kernel), there are all sorts of ways you could detect the difference: you could use alloca, you could write code that makes assumptions about the way that stack variables are arranged in memory, you could play tricks with setjmp/longjmp, and so on.
I've never seen a good QM book that's completely nonmathematical; my impression is that there aren't any. I think you'll have to read something with equations, which means some calculus and linear algebra.
The two books that seem to be used most often as undergrad texts are Liboff and Gasiorowicz. Both are pretty good; I've used both. I like Gasiorowicz a bit better, but tastes probably differ.
If you've got a strong mathematical background, the most elegant summary of quantum mechanics I've seen is the first few chapters of Dirac's Principle of Quantum Mechanics.
Come on wasn't it Shakespeare who said "The first thing we do, let's kill all the lawyers"
No. It was one of Shakespeare's characters. This particular character was a bad guy.
Re:Sorry, stupid Q: What is an ABI?
on
GCC 3.2 Released
·
· Score: 2, Informative
And the third issue is how to represent exception-handling information, and the fourth issue is how to deal with typeinfo, and the fifth issue is initialization and destruction of namespace-scope objects, and the sixth issue is handling of covariant return types, and the seventh issue is merging static data in inline functions, and the eighth issue is representation of pointers to members, and...
A C++ ABI has to cover an awful lot of things. It's much, much more than just name mangling; that's one of the easy pieces.
who else actually supports this "multi-vendor standard" C++ ABI?
HP and Intel already have compilers that support it. (Remember that the ABI was originally designed for Intel's Itanium.) Other companies were heavily involved with the design, and may eventually have compiler that support this ABI if they don't already.
Re:Breaking interoperability... again???
on
GCC 3.2 Released
·
· Score: 1
Apple does use C++ internally, yes. However, Apple is careful not to expose C++ interfaces. That's precisely because of the danger of the C++ ABI changing.
The one exception is IOKit. It uses a specific subset of C++; it's believed that ABI stability will be easier with that subset than with the full language.
NASA uses it, Disney uses it, more shops than you probably imagine.
NASA and Disney use all sorts of languages. Which, of course, is typical of large organizations. (My department, a smallish branch of a moderate-sized company, uses C++, C, Objective C, Java, Perl, Python, TCL, Ruby, various assembly languages, and probably a few other languages that I don't happen to remember off the top of my head.)
I'm sure neither NASA nor Disney would consider using Python for everything. Competent programmers know that different tools are useful for different purposes.
Guiding declarations are an obsolete and rather arcane feature that was present in some early versions of pre-standard C++ but that aren't part of the C++ standard. For the most part they're only of historical interest. (Assuming you're interested in the history of such things, that is.)
If you've got legacy code that used guiding declarations and you need to know how to convert it to standard C++, there's a nice discussion in the kcc documentation.
There aren't very many C++ parsers. GCC has one, Microsoft has one, and most of the other compilers use the EDG front end.
That's an exaggeration. EDG's front end is widely used (as it ought to be, because it's very good), but there are lots of companies with non-EDG compilers out there. To name a few: Metrowerks, IBM, Sun, HP, Borland.
In particular, I know that KAI C++ and Compaq's C++ compiler are both based on EGD.
Yes, KAI and Compaq use the Edison front end. So do Comeau, SGI, Intel, and a number of other compilers. See EDG's site for a more complete list.
Some of EDG's customers will release a compiler based on the new front end sooner than others, partly for business reasons (every company has different tradeoffs) and partly for technical reasons (for some companies, a new front end means an awful lot of integration work).
I expect Comeau to be the first company to sell a compiler based on the new EDG front end: Greg Comeau has been very excited at being able to support export. I'll be surprised if it takes longer than a few weeks for the new Comeau compiler to come out.
There has also been an IA-64 C++ ABI since the start
To be a bit more specific, it's an ABI for IA-64 Unix systems that use the ELF object format.
That's an awful lot of qualifications, but they're necessary. (And not just for C++.) Even such simple things as function calling conventions differ from platform to platform, and linkers are a lot less trivial, and involve a lot more design choices, than most people realize.
Slashdot Mirror
There's no direct evidence that the document is forged. There's also no direct evidence that it's genuine, or even what "genuine" would mean. There are stories vaguely associating it with various interesting people, such as John Dee and Roger Bacon, but they're all pretty vague.
People have been studying this document for the better part of a century, because it's fascinating, enigmatic, and beautiful. (You can find some pictures of it at www.voynichinfo.com) We know a bit more than we did about what kinds of hypotheses are plausible and what kinds are not. For example: we can be pretty sure that it is not written in any natural language. We can also be pretty sure that it isn't just a simple substitution cipher. Finally, we can be pretty sure that it isn't a 20th century forgery: it has been given a rough date, it really does look like a manuscript from the 15th or 16th century, and it probably was once owned by Rudolf II. The Roger Bacon rumors are almost certainly false, because the manuscript doesn't appear to be that old. The John Dee rumors may be true.
At present the two most plausible guesses are that it is a real 15th or 16th century treatise on an occult subject, written in a code that has yet to be broken, or that it's a good imitation of an encoded occult text. If the latter, it was probably written specifically for the purpose of fooling Rudolf. It is known that he was fascinated by the occult (there's even an opera where that's a crucial plot point), and it is known that many of the astrologers and alchemists he patronized were quacks and that many of the texts he bought were forgeries.
What's interesting about this research isn't that it's a new argument against the possibility that the manuscript is genuine, but that it's a good counterargument. Until now, many people argued that the manuscript wasn't likely to be a forgery because the text followed a certain statistical property of natural languages (Zipf's law) that weren't known until the 20th century. Thus, the argument goes, it's unlikely to be a 16th century fake because a 16th century forger, inventing a fake code or a fake language, wouldn't have known to match this statistical distribution.
The reason this work is interesting is that it shows that this argument is invalid: there is a plausible method that a 16th century forger might have used that might have produced such a document. This doesn't show that it really is a 16th century forgery, it only shows that there's one fewer argument against that possibility than we once believed.
In the end, of course, we're unlikely to ever have decisive evidence that the manuscript is fake. Either someone will come up with a believable decryption (several people claim to have done it already; none of their claims have stood up), or people will keep trying and failing. The longer scholars bang their heads against the wall trying to get a translation, the less likely people will think it is that there really is one. Messy, but that's the way the world works. Sometimes you don't get to learn for sure whose guess is right.
HR2239 and evoting machines shouldn't be a partisan issue. Yes, Kucinich seems to be a decent man if you happen to share his political views. But everyone, no matter what their political views are, should care about honest and accurate elections.
See Apple's Expose page for a demo. They've got a Quicktime movie showing how it works.
And yes, I'm biased (I'm an Apple employee), but I find it a really useful feature.
You need to distinguish a paper receipt (which, as you point out, is wastepaper or worse) and a paper ballot that gets counted. Using the same word, 'receipt", for such different concepts, is a bad mistake.
This is what Rebecca Mercuri describes as the Voter Verified Balloting concept. She discusses it in her dissertation, and in a RISKS digest article.
There's a good article about this in the Independent of London: http://news.independent.co.uk/world/americas/story .jsp?story=452972.
The article makes it clear that we're dealing with fundamental issues of democracy, not with details of computer implementations. The rest of the world is not impressed by the US's infatuation with evoting.
What's so traditional about the paper-punch ballot? The only reason some American counties use punch cards is that they're cheap. They're not particularly accurate, they're not particularly easy to use, and they're not particularly easy to count without complicated and fragile machinery.
A better voting technology to start from are the optically scanned ballots. The voter draws a line between two arrows or fills in a bubble. It's easy to use, it has been shown to be more accurate than punch cards, and it's fairly easy to count by hand. It's used a fair amount in the US; it's the system they use in San Mateo County, for example. It's easy to extend the optical scan systems to give voters instant feedback on their choices. It's slightly more expensive than punch cards, which is the only reason I can think of that the US hasn't gotten rid of punch cards long ago.
And, of course, in lots of other countries ballots are just ink on paper, counted by hand in public. This is a perfectly fine system too, and lots of countries find that it works well.
The first Common Lisp standard was published in 1984. The Ada 95 standard was published in 1995. (Depending on your definition of "object oriented" you might argue that Ada 83 was an object-oriented language, but most people don't seem to say that.)
Read the book. This is one of the cases that he analyzes. The questions to ask about national ID cards is the same as for any security measure: what assets are you trying to protect, what threats are you trying to protect against, how well does this measure work to reduce the risks from those threats, what new threats does it introduce, and so on.
I can see ways in which a national ID card could be useful. I do not see that it could be useful as a security measure. I can see ways in which it could hurt security. (It could increase the risk of identity theft, for example, by creating a new database with security issues of its own.)
But again: read the book. If I were to present a complete security analysis of national ID cards I'd just be ripping off Bruce Schneier anyway, so you'd be better off getting it from the original than from my summary.
The discussions of door locks and car theft and bank vaults aren't metaphors. They're examples. He's showing concrete cases where one makes judgments about security.
Remember: this is not a book about computer security. It's not trying to teach you about password management techniques (although he does use password lists as yet another example, since they're yet another everyday security issue for most of us) or firewall configuration. It's trying to teach you how to think about security in general.
To the extent that this book is trying to teach you about any particular area of security, it's not computers but terrorism. The author is very specific about that in the introduction: he was motivated to write this book because security has recently become a hot topic. There's lots more discussion of security than there was two and a half years ago, a lot more proposals for things that will supposedly make us secure, and lots of that discussion and those proposals are wrong. This book is an attempt to make an important national discussion more intelligent.
"Naught", not "knot". It means the same thing as "zero".
In what way do you not regard std::string as a standard string class?
The name isn't C++0x. The name will be C++. People are informally saying "C++0x" in the same way they were saying C9x: because it's expected that the next revision of the C++ standard will be released some time within the next seven years. Similarly, people informally refer to "C++98", meaning C++ as described in the 1999 ISO standard.
It's the same deal as with C: people sometimes refer to "C90" (i.e. the version of C specified in the 1994 ISO standard), "C94" (C90 plus the 1994 normative addendum), and "C99" (the version of C specified in the 1999 ISO standard).
For those who don't recognize the quote, the exact wording is: "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." It comes from Richard Feynman's appendex to the Rogers Commission report on the Challenger.
Mark's recursive-descent parser isn't faster than the 3.3 yacc-based parser right now, but there also has been zero performance tuning at this point. There's reason to think that it will be faster once there has been tuning.
That is: there are a number of places where it's known that the recursive descent parser can be made faster if someone just does the work. There doesn't seem to be similar scope for improvement in the old yacc-based parser.
If you're writing nonportable low-level code (which wouldn't be too extraordinary in a kernel), there are all sorts of ways you could detect the difference: you could use alloca, you could write code that makes assumptions about the way that stack variables are arranged in memory, you could play tricks with setjmp/longjmp, and so on.
I've never seen a good QM book that's completely nonmathematical; my impression is that there aren't any. I think you'll have to read something with equations, which means some calculus and linear algebra.
The two books that seem to be used most often as undergrad texts are Liboff and Gasiorowicz. Both are pretty good; I've used both. I like Gasiorowicz a bit better, but tastes probably differ.
If you've got a strong mathematical background, the most elegant summary of quantum mechanics I've seen is the first few chapters of Dirac's Principle of Quantum Mechanics.
No. It was one of Shakespeare's characters. This particular character was a bad guy.
And the third issue is how to represent exception-handling information, and the fourth issue is how to deal with typeinfo, and the fifth issue is initialization and destruction of namespace-scope objects, and the sixth issue is handling of covariant return types, and the seventh issue is merging static data in inline functions, and the eighth issue is representation of pointers to members, and...
A C++ ABI has to cover an awful lot of things. It's much, much more than just name mangling; that's one of the easy pieces.
gcc's C++ ABI is docuemented at http://www.codesourcery.com/cxx-abi/abi.html.
HP and Intel already have compilers that support it. (Remember that the ABI was originally designed for Intel's Itanium.) Other companies were heavily involved with the design, and may eventually have compiler that support this ABI if they don't already.
Apple does use C++ internally, yes. However, Apple is careful not to expose C++ interfaces. That's precisely because of the danger of the C++ ABI changing.
The one exception is IOKit. It uses a specific subset of C++; it's believed that ABI stability will be easier with that subset than with the full language.
NASA and Disney use all sorts of languages. Which, of course, is typical of large organizations. (My department, a smallish branch of a moderate-sized company, uses C++, C, Objective C, Java, Perl, Python, TCL, Ruby, various assembly languages, and probably a few other languages that I don't happen to remember off the top of my head.)
I'm sure neither NASA nor Disney would consider using Python for everything. Competent programmers know that different tools are useful for different purposes.
Guiding declarations are an obsolete and rather arcane feature that was present in some early versions of pre-standard C++ but that aren't part of the C++ standard. For the most part they're only of historical interest. (Assuming you're interested in the history of such things, that is.)
If you've got legacy code that used guiding declarations and you need to know how to convert it to standard C++, there's a nice discussion in the kcc documentation.
That's an exaggeration. EDG's front end is widely used (as it ought to be, because it's very good), but there are lots of companies with non-EDG compilers out there. To name a few: Metrowerks, IBM, Sun, HP, Borland.
Yes, KAI and Compaq use the Edison front end. So do Comeau, SGI, Intel, and a number of other compilers. See EDG's site for a more complete list.
Some of EDG's customers will release a compiler based on the new front end sooner than others, partly for business reasons (every company has different tradeoffs) and partly for technical reasons (for some companies, a new front end means an awful lot of integration work).
I expect Comeau to be the first company to sell a compiler based on the new EDG front end: Greg Comeau has been very excited at being able to support export. I'll be surprised if it takes longer than a few weeks for the new Comeau compiler to come out.
To be a bit more specific, it's an ABI for IA-64 Unix systems that use the ELF object format.
That's an awful lot of qualifications, but they're necessary. (And not just for C++.) Even such simple things as function calling conventions differ from platform to platform, and linkers are a lot less trivial, and involve a lot more design choices, than most people realize.