Replace "speed of light" with "speed of sound" to see why your argument is bogus. Why can't you send a signal faster than light that still arrives at its destination after it was sent? -- Patrick Doyle
C is the speed of light in a vacuum. What they have done is find a medium where light travels faster than it does in a vacuum (supposedly). -- Patrick Doyle
The speed of electricity is not governed by the speed of individual electrons. IIRC, they only drift a few millimeters a second. The important effect is more like those executive toys with the five steel balls on strings that swing back and forth. The force is transmitted through the balls, at a speed which is unrelated to the speed at which the balls themselves move. -- Patrick Doyle
Main Entry: product Pronunciation: 'prä-(")d&kt Function: noun Etymology: in sense 1, from Middle English, from Medieval Latin productum, from Latin, something produced, from neuter of productus, past participle of producere; in other senses, from Latin productum Date: 15th century 1 : the number or expression resulting from the multiplication together of two or more numbers or expressions 2 a : something produced b : something resulting from or necessarily following from a set of conditions 3 : the amount, quantity, or total produced 4 : CONJUNCTION 5
I guess it's the typical Canadian reaction, but I don't care. The Privacy Commissioner said last night on CBC radio that the main problem is that people don't know it's there. Lots of people (apparently) think that if they give some info to, say, the Ministry of Transportation, then Revenue Canada won't know about it.
Well, duh. I think it's pretty logical to assume that anything you tell the Government, It then knows forever. Hey, just like any other person/company/whatever. If I told the IT department at a company something, should I be surprised if HR finds out about it? Of course not.
All in all, I don't find this database too surprising or worrisome.
The US Constitution mandates that copyright be used to "promote the Progress of Science and useful Arts". Which do you feel poses more of a thread to this goal: trading music for free on the Internet, or using lawsuits and intimidation to prevent such trading?
(I'm afraid I've posted this too late for the moderators to see it, but I'd relly like to see Metallica answer this.) -- Patrick Doyle
You make a good point that DTDs are useful for maintaining the proper format of a document. We still disagree, however, about the semantics.
DTD's do indeed have their semantics documented, indeed most of the more common ones have their semantics documented MUCH more extensively than ANY proprietary format out there.
Perhaps, but this is not a feature of XML. Nothing in XML mandates (or even assists in) providing semantics for each construct.
So, again, I feel that this doesn't change the fact that XML can't replace proprietary formats. As I said originally, it's XML + DTDs + semantics.
Personally, I think the government could do much to open up the playing field by making it so all documents sent to the government had to be in some openly documented file format (XML based if you like to pretend that XML solves all problems, or just some random binary format or what not.)
Trust me, don't let the government decide on that format! I have seen government-designed data formats, and in the process of trying to think of every possible piece of data you might want to store, they forget to take a step back and look for a simple underlying abstraction.
Of course, my opinion is biased by my experience. My appologies to the government data format designers reading this.
DTDs are not that important in the grand scheme of things. They specify the valid structure of a type of XML document. Period. They do no more than any other kind of data format specification. In fact, they do less than most format specs, because they do not specify any semantics. They don't fundamentally change the world.
I'll be the first to say that XML is very convenient. I chose it for a project last summer because it fit the bill quite well. But the question was whether it will replace file formats, and the answer is no, because XML, even with DTDs, does not do what a bona fide data format does; namely, specify the semantics of the data.
If Word21 needs to add additional elements or attributes to support new features, they simply create new tags.
Sure, and they could presumably do that in their own format. But they don't, so why should we expect them to do it with XML?
"XML can't replace proprietary document formats. That's like asking if ASCII could replace proprietary document formats."
I must not be understanding what you mean when you're refering to ASCII since simple texts replace proprietary document formats all the time. TeX, CSV, RTF, HTML, PS, all are human readable text files.
You just said it yourself. It's not ASCII that replaces these things, it's TeX, CSV, etc. Those are the file formats. ASCII is just a character encoding scheme.
XML can't replace proprietary document formats. That's like asking if ASCII could replace proprietary document formats. XML and ASCII are not really file formats. They simply don't do the same job as file formats.
If you have ever used lex or yacc, then you'll know what I mean when I say that XML parsers essentially do the job of lex, but not of yacc. An XML parser is little more than a scanner which breaks a file into chunks to simplify the next level of processing. The XML parser gives the illusion of hierarchical processing that lex can't do, but it's an illusion nonetheless.
Your example of Word formats changing is a perfect one. If Word95 used XML, Word97 could still be incompatible if it used different elements and attributes.
So no, XML will not replace proprietary file formats. XML + proprietary DTD specifications + proprietary semantics could replace proprietary file formats. Is this an improvement? Probably. Will it make backward (or forward, or sideways) compatibility problems go away? Nope. -- Patrick Doyle
Ok, so you only have to search 1 percent of the game tree. Now, lets do our freshman computer science math here, kids:.01 * (35 ^ 100) = (an intractable runtime)
(Ok, please try to see the point I'm making instead of getting lost in the example.)
Who said it's 1 percent? What if it's 1/(35^98) of the game tree?
The point is that the total number of games doesn't matter because you may only need to search a tiny fraction of them. How tiny? I don't know. The point (again) is that you can't argue that solving chess is impossible because of the huge number of possible games.
I could use the same argument to claim that adding 1+2 is impossible because you'd have to search every possible integer answer. It's just a ridiculous argument.
Branch and Bound is an interesting technique, but it won't help you in chess.
Right. I did say that in my article, but it bears repeating. It was meant as an example of how the raw number of games is not necessarily relevant. -- Patrick Doyle
You can get an exhaustive search of a tree without searching every node in the tree. Pruning techniques can remove many, many orders of magnitude from the amount of nodes that need to be search.
I have implemented a circuit partitioning engine using branch and bound that only searched 1% of the possible partitionings, and was still guaranteed to come up with the same solution you get with a real exhaustive search. This was with very small circuits; the larger the circuit, the smaller proportion of the nodes need be searched.
So, the raw number of possible games is not really an issue, even if you want to do the equivalent of an exhaustive search. If there happens to be a good pruning technique, the number of nodes in the tree becomes almost irrelevant. Branch and Bound may not work for Chess, but perhaps another technique would make the problem solvable by current technology.
Secondly, strcpy() and sprintf() are very useful, and I don't find them dangerous at all.
Then you haven't given the issue much thought. Strcpy() has no idea how big the destination buffer is, so you can easily corrupt memory. sprintf(x, "%s", y) is the same as strcpy(x,y), so same problem.
Of course, you probably know this already. It must seem quite easy to fix an example this small, and wonder what's so unsafe about strcpy. All I can say to this is that you must be smarter than the average coder, because code like the first example is all over the place.
Here, however, libsafe could not help anyway, because I really doubt they've found a way to make a library that can determine how much you really want to store in dest before overwriting something important nearby on your data segment, such as a function pointer, etc.
Hey, moderate this up! Even though libsafe can prevent you from overwriting the return address, it can't prevent you from overwriting a function pointer in the current stack frame. The latter could be just as good as the former for buffer overflow attacks.
Making the stack non-executable can intefere with valid code (e.g. signal handlers, nested function calls and trampoline functions)
What are you talking about? None of these things need an executable stack. And the example exploit does need an executable stack. The code is loaded into a local variable (ie. on the stack) and then executed.
Normal C code does not provide any way to execute the stack. You have to do abnormal things like cast the address of a local variable as a function pointer and execute it; not something that normal C programs do. Or (of course) overrun the return address. --
Patrick Doyle
This is a smart-ass answer to a perfectly legitimate question. The example is contrived and bears no resemblance to the real issues faced when choosing CPUs.
This post brings up an interesting (though fictional) point, but +5?? Gimme a break. -- Patrick Doyle
Slashdot Mirror
Replace "speed of light" with "speed of sound" to see why your argument is bogus. Why can't you send a signal faster than light that still arrives at its destination after it was sent?
--
Patrick Doyle
C is the speed of light in a vacuum. What they have done is find a medium where light travels faster than it does in a vacuum (supposedly).
--
Patrick Doyle
Combine this with Quantum Teleportation, and couldn't you teleport matter faster than light?
--
Patrick Doyle
The speed of electricity is not governed by the speed of individual electrons. IIRC, they only drift a few millimeters a second. The important effect is more like those executive toys with the five steel balls on strings that swing back and forth. The force is transmitted through the balls, at a speed which is unrelated to the speed at which the balls themselves move.
--
Patrick Doyle
Main Entry: product
Pronunciation: 'prä-(")d&kt
Function: noun
Etymology: in sense 1, from Middle English, from Medieval Latin
productum, from Latin, something produced, from neuter of
productus, past participle of producere; in other senses, from Latin
productum
Date: 15th century
1 : the number or expression resulting from the multiplication together
of two or more numbers or expressions
2 a : something produced b : something resulting from or necessarily
following from a set of conditions
3 : the amount, quantity, or total produced
4 : CONJUNCTION 5
No mention of being sold.
--
Patrick Doyle
I guess it's the typical Canadian reaction, but I don't care. The Privacy Commissioner said last night on CBC radio that the main problem is that people don't know it's there. Lots of people (apparently) think that if they give some info to, say, the Ministry of Transportation, then Revenue Canada won't know about it.
Well, duh. I think it's pretty logical to assume that anything you tell the Government, It then knows forever. Hey, just like any other person/company/whatever. If I told the IT department at a company something, should I be surprised if HR finds out about it? Of course not.
All in all, I don't find this database too surprising or worrisome.
--
Patrick Doyle
The US Constitution mandates that copyright be used to "promote the Progress of Science and useful Arts". Which do you feel poses more of a thread to this goal: trading music for free on the Internet, or using lawsuits and intimidation to prevent such trading?
(I'm afraid I've posted this too late for the moderators to see it, but I'd relly like to see Metallica answer this.)
--
Patrick Doyle
You make a good point that DTDs are useful for maintaining the proper format of a document. We still disagree, however, about the semantics.
DTD's do indeed have their semantics documented, indeed most of the more common ones have their semantics documented MUCH more extensively than ANY proprietary format out there.
Perhaps, but this is not a feature of XML. Nothing in XML mandates (or even assists in) providing semantics for each construct.
So, again, I feel that this doesn't change the fact that XML can't replace proprietary formats. As I said originally, it's XML + DTDs + semantics.
--
Patrick Doyle
Personally, I think the government could do much to open up the playing field by making it so all documents sent to the government had to be in some openly documented file format (XML based if you like to pretend that XML solves all problems, or just some random binary format or what not.)
Trust me, don't let the government decide on that format! I have seen government-designed data formats, and in the process of trying to think of every possible piece of data you might want to store, they forget to take a step back and look for a simple underlying abstraction.
Of course, my opinion is biased by my experience. My appologies to the government data format designers reading this.
--
Patrick Doyle
You forget about the benefit of a DTD.
:-)
No I don't.
DTDs are not that important in the grand scheme of things. They specify the valid structure of a type of XML document. Period. They do no more than any other kind of data format specification. In fact, they do less than most format specs, because they do not specify any semantics. They don't fundamentally change the world.
I'll be the first to say that XML is very convenient. I chose it for a project last summer because it fit the bill quite well. But the question was whether it will replace file formats, and the answer is no, because XML, even with DTDs, does not do what a bona fide data format does; namely, specify the semantics of the data.
--
Patrick Doyle
If Word21 needs to add additional elements or attributes to support new features, they simply create new tags.
Sure, and they could presumably do that in their own format. But they don't, so why should we expect them to do it with XML?
"XML can't replace proprietary document formats. That's like asking if ASCII could replace proprietary document formats."
I must not be understanding what you mean when you're refering to ASCII since simple texts replace proprietary document formats all the time. TeX, CSV, RTF, HTML, PS, all are human readable text files.
You just said it yourself. It's not ASCII that replaces these things, it's TeX, CSV, etc. Those are the file formats. ASCII is just a character encoding scheme.
--
Patrick Doyle
XML can't replace proprietary document formats. That's like asking if ASCII could replace proprietary document formats. XML and ASCII are not really file formats. They simply don't do the same job as file formats.
If you have ever used lex or yacc, then you'll know what I mean when I say that XML parsers essentially do the job of lex, but not of yacc. An XML parser is little more than a scanner which breaks a file into chunks to simplify the next level of processing. The XML parser gives the illusion of hierarchical processing that lex can't do, but it's an illusion nonetheless.
Your example of Word formats changing is a perfect one. If Word95 used XML, Word97 could still be incompatible if it used different elements and attributes.
So no, XML will not replace proprietary file formats. XML + proprietary DTD specifications + proprietary semantics could replace proprietary file formats. Is this an improvement? Probably. Will it make backward (or forward, or sideways) compatibility problems go away? Nope.
--
Patrick Doyle
That's the sound of the joke flying over your head.
--
Patrick Doyle
Ok, so you only have to search 1 percent of the game tree. Now, lets do our freshman computer science math here, kids: .01 * (35 ^ 100) = (an intractable runtime)
(Ok, please try to see the point I'm making instead of getting lost in the example.)
Who said it's 1 percent? What if it's 1/(35^98) of the game tree?
The point is that the total number of games doesn't matter because you may only need to search a tiny fraction of them. How tiny? I don't know. The point (again) is that you can't argue that solving chess is impossible because of the huge number of possible games.
I could use the same argument to claim that adding 1+2 is impossible because you'd have to search every possible integer answer. It's just a ridiculous argument.
Got it?
--
Patrick Doyle
Branch and Bound is an interesting technique, but it won't help you in chess.
Right. I did say that in my article, but it bears repeating. It was meant as an example of how the raw number of games is not necessarily relevant.
--
Patrick Doyle
"If you put an infinite number of monkeys, working on an infinite number of typewriters eventually one will bang out the script to hamlet"
Actually, if you have an infinite number of monkeys, you could even say that an infinite subset of them will immediately produce Hamlet.
I think the original monkey theorem was that 1000 monkeys on 1000 typewriters will eventually produce Hamlet.
--
Patrick Doyle
You can get an exhaustive search of a tree without searching every node in the tree. Pruning techniques can remove many, many orders of magnitude from the amount of nodes that need to be search.
Have a look at Branch and Bound for example.
I have implemented a circuit partitioning engine using branch and bound that only searched 1% of the possible partitionings, and was still guaranteed to come up with the same solution you get with a real exhaustive search. This was with very small circuits; the larger the circuit, the smaller proportion of the nodes need be searched.
So, the raw number of possible games is not really an issue, even if you want to do the equivalent of an exhaustive search. If there happens to be a good pruning technique, the number of nodes in the tree becomes almost irrelevant. Branch and Bound may not work for Chess, but perhaps another technique would make the problem solvable by current technology.
--
Patrick Doyle
So maybe it's possible they could make the perfect chess player.. one who never lost.. but who's to say you still couldn't stalemate it?
Um, that's precisely the point of the question: can we "solve" chess and say that there is a way to play that always wins?
We have our answer for tic-tac-toe, for instance. The answer is no. A perfect player cannot force a win.
The idea is to answer the same question for Chess.
--
Patrick Doyle
non-exec stacks on x86 are worthless
Why is that?
--
Patrick Doyle
Secondly, strcpy() and sprintf() are very useful, and I don't find them dangerous at all.
Then you haven't given the issue much thought. Strcpy() has no idea how big the destination buffer is, so you can easily corrupt memory. sprintf(x, "%s", y) is the same as strcpy(x,y), so same problem.
Here's some code for ya:
void func(char *arg){
char buf[1024];
strcpy(buf, arg);
}
If arg happens to point to more than 1024 characters of data, you're screwed. Here's the fixed version:
void func(char *arg){
char buf[1024];
strncpy(buf, arg, sizeof(buf)-1);
buf[sizeof(buf)-1] = 0;
}
This will safely copy the data into the buffer, and make sure it's null-terminated (which strncpy does not guarantee).
The sprintf version looks like this:
void func(char *arg){
char buf[1024];
sprintf(buf, "%.*s", sizeof(buf)-1, arg);
}
Of course, you probably know this already. It must seem quite easy to fix an example this small, and wonder what's so unsafe about strcpy. All I can say to this is that you must be smarter than the average coder, because code like the first example is all over the place.
--
Patrick Doyle
Here, however, libsafe could not help anyway, because I really doubt they've found a way to make a library that can determine how much you really want to store in dest before overwriting something important nearby on your data segment, such as a function pointer, etc.
Hey, moderate this up! Even though libsafe can prevent you from overwriting the return address, it can't prevent you from overwriting a function pointer in the current stack frame. The latter could be just as good as the former for buffer overflow attacks.
--
Patrick Doyle
Making the stack non-executable can intefere with valid code (e.g. signal handlers, nested function calls and trampoline functions)
What are you talking about? None of these things need an executable stack. And the example exploit does need an executable stack. The code is loaded into a local variable (ie. on the stack) and then executed.
Normal C code does not provide any way to execute the stack. You have to do abnormal things like cast the address of a local variable as a function pointer and execute it; not something that normal C programs do. Or (of course) overrun the return address.
--
Patrick Doyle
Synchronization
Pocket-PC:
Fast, continuous
and automatic with
ActiveSync.
Palm Products:
HotSync - must push
button.
That does it, I want one.
--
Patrick Doyle
Sorry, but I can't stand it...
The word you want is "lieu". The phrase "in lieu of" means "instead of". People use the former to make them sound smarter.
I think the phrase you really wanted might be "in light of". As it stands, your post says the opposite of what I think you meant.
Ok, I have no life.
--
Patrick Doyle
This is a smart-ass answer to a perfectly legitimate question. The example is contrived and bears no resemblance to the real issues faced when choosing CPUs.
This post brings up an interesting (though fictional) point, but +5?? Gimme a break.
--
Patrick Doyle