You make some good points. However, what is more interesting always depends on your background. For people interested in computational mechanics, billiards is very interesting because a well-done billiards simulation, augmented with nice graphics, can be used to impress people who would not give a damn about the most impressive algorithms for solving systems of nonholonomous differential equations or such.
Basically, I just wanted to point out that the physics involved are a lot more complicated than most people would think.
This not as simple as it seems. Realistic simulation of multibody dynamics with contact is still subject to research. There is no such thing as a single uniform friction coefficient, in reality, you have (probably nonlinear) elastic bodies with varying contact surface. Parts of this surface stick together, in other parts the bodies are slipping against each other. I doubt that it is possible to reproduce a complicated shot from a professional player in a numerical simulation.
The knapsack algorithm was devised by Ralph Merkle and Martin Hellman. Knapsacks would still be computationally prohibitive if they had not been broken.
Also, Whitfield Diffie is certainly best renowned for the Diffie-Hellman algorithm for key exchange.
This is not a problem with SSL as long as you have access to the private keys involved. Usually, there is no client authentication required in a web application, so no problem to trace the traffic.
google for ssldump, a great tool written by Eric Rescorla.
Slight correction: redhat 7.0 shipped with a snapshot towards gcc-3.0 they called gcc-2.96. It is true that this compiler version miscompiled the kernel, but it is also true that they provided a gcc version that was the recommended compiler for the kernel at that time. (they called it kgcc).
It is also true hat "gcc-2.96" did not have the quality of a proper gcc release. However, this step proved very valuable for gcc 3.0 development, because of the huge user base acting as testers. Of course, 99 percent of redhat users would never have bothered to install a development snapshot
of gcc. (and the rest would not have used in a production environment...)
The driver accelerates so the red light will look green to him because of the doppler effect.
(computing the required speed is left as an execise for the reader.)
Maybe so. But I still think that you are able to choose is not your archievement, but luck. Modern democracies did not grow on trees, but neither you nor me made a substantial contribution. Think about it.
autoconf is useful for c/c++ stuff, especially include paths (what the original post was about...),
linking options and so on.
For the kind of problem you are talking about, I suggest considering a scripting language like perl or python.
Open adressing hashing schemes have one inherent problem, especially if you use "double hashing", i.e. collision resolution makes use of a second hashing function.
You can not easily delete an item, you have to marked it as "deleted". No big deal, any decent book on algorithms states this very clearly. What is not so obvious, is that this kind of data structure does not easily recover from bad input.
Consider the case where the hash table is 80 percent full, and all the remaining entries are marked as deleted. This will severly degrade unsuccessful search, and there is no easy way of "garbage collection". Probably you need to rebuild the whole table. Not a good thing.
A chained hash does not have this kind of problem, because its state is determined only by its actual content.
You seem a bit confused about the concept "defense". Probably also about "national".
If you really want to draw an analogy to international politics, just think about these points:
which nation is dominating international politics?
which government is at this very moment severely resticting its "users" (think citizens) rights "in their best interest"?
which government is taking the chance to secure profit while talking about security?
which government arguest that "peer review" (think United Nations arms inspection) is a bad thing?
If your answer to all these questions is "France",
please think again.
try {... a bunch of attempts at trickery...
} catch (Exception e) {... they're at it again!...
}
You should not find this kind of thing in production code. Exceptions ought to be caught by reference.
(If you don't know why, just think of slicing...)
Sorry to correct you, but a STL set can not be implemented as a linked list, because it needs log(n) complexity for inserting or removing elements while makin sure there are no duplicates. One way to do this is a red-black tree like a map, but without additional data at the nodes.
If you want a container with double-linked list characteristics, there is std::list.
Yeah, I know, linux only aims at POSIX compliance... Despite some things in linux pthreads that are non-optimal, performance is reasonable, and everythings runs quite stable, once you have found out how to do it, so my critique may sound unfair. I notice you do not agree on my complaint about signal behaviour, and to be honest, this is a somewhat arcane thing also on other systems:-(
However, my main point is that there is no real smooth integration of threads in glibc.
IMHO this is much more important than largescale scalability. These guys are working to change that, which is a Very Good Thing(TM). As it is, using threads only makes sense if you really need them, and have time at hand to
explore the nifty details that must be correct for a real world application.
Scalability is a good thing, no doubt about that. However, there is another aspect that should be pointed out: the current thread API in linux is quite different from the POSIX specification and somewhat crufty. Just to mention the biggest problems: missing cancellation points: testing whether a thread has been cancelled should be done in lots of system calls, but linux pthreads do not support this. Instead, you have to call pthread_testcancel() before and after every such call. A real drag. signal handling: linux pthread signal handling is very different from the POSIX specification. However, proper signal handling is crucial for any real world application. fork() will not work as expected. This is a real nuissance if you want proper daemon behaviour for your application. documentation of linux-specific behaviour is poor. As a result, most of the existing literature on thread programming is pretty useless for linux.
All these points can be worked around, for sure. Nevertheless, it makes writing portable software a nightmare. Porting threaded software to linux, well... All in all, linux threads really need much better integration with the standard system API. A lot of applications could profit from multithreading. Just think of GUI responsiveness. Also, using threads makes some programming tasks much easier. No need for asynchronous hostname lookup, for example.
A solid, well documented, standard conforming threads implementation will make linux a much nicer environment for serious programming than it already is. I am really looking forward to this.
you've got to be willing to accept new ideas before you can process the facts.
These ideas are not new, by any means. This kind of nonsense has been said by nazi supporters ever since Germany lost the war it provoked and it has been thorouhly rebutted by science, and also in court. David Irving has tried to sue a lot of people for critizing him, and he has lost all of those cases hands down.
I do not say that the references that barnesreview gives are not correctly cited, but citing nonsense proves nothing. Of course I realize that all this may look somewhat less evident in the United States, but I live in Austria, and I personally know people who lived through these times, some of them are relatives of mine. I have read an original printing of "Mein Kampf". I have visited the death camp in Mauthausen. There is a very good exhibition about the war crimes committed by the Wehrmacht, which has been shown in a lot of places in Germany and Austria. I have seen it. It presents hundreds of photos, documents, etc. which proof without any doubt the awful truth.
Irving and other revisionists simply deny the vast historic research that has been done during the last 50 years. The holocaust has probably been documented and researched more thoroughly than any other historic event in history.
If some guys claim there has never been any slavery in the United States, would you believe them? Even if there were ten of them, all citing each other as evidence?
Slashdot Mirror
You make some good points. However, what is more interesting always depends on your background. For people interested in computational mechanics, billiards is very interesting because a well-done billiards simulation, augmented with nice graphics, can be used to impress people who would not give a damn about the most impressive algorithms for solving systems of nonholonomous differential equations or such.
Basically, I just wanted to point out that the physics involved are a lot more complicated than most people would think.
This not as simple as it seems. Realistic simulation of multibody dynamics with contact is still subject to research. There is no such thing as a single uniform friction coefficient, in reality, you have (probably nonlinear) elastic bodies with varying contact surface. Parts of this surface stick together, in other parts the bodies are slipping against each other. I doubt that it is possible to reproduce a complicated shot from a professional player in a numerical simulation.
The knapsack algorithm was devised by Ralph Merkle and Martin Hellman. Knapsacks would still be computationally prohibitive if they had not been broken.
Also, Whitfield Diffie is certainly best renowned for the Diffie-Hellman algorithm for key exchange.
This is not a problem with SSL as long as you have access to the private keys involved. Usually, there is no client authentication required in a web application, so no problem to trace the traffic.
google for ssldump, a great tool written by Eric Rescorla.
Funny, I get emails from self-appointed hot chicks all the time, thank you very much.
SuSE has had ftp install for ages. I remember installing 6.3 per ftp, worked like a charm.
Slight correction: redhat 7.0 shipped with a snapshot towards gcc-3.0 they called gcc-2.96. It is true that this compiler version miscompiled the kernel, but it is also true that they provided a gcc version that was the recommended compiler for the kernel at that time. (they called it kgcc).
It is also true hat "gcc-2.96" did not have the quality of a proper gcc release. However, this step proved very valuable for gcc 3.0 development, because of the huge user base acting as testers. Of course, 99 percent of redhat users would never have bothered to install a development snapshot of gcc. (and the rest would not have used in a production environment...)
The driver accelerates so the red light will look green to him because of the doppler effect.
(computing the required speed is left as an execise for the reader.)
Maybe so. But I still think that you are able to choose is not your archievement, but luck. Modern democracies did not grow on trees, but neither you nor me made a substantial contribution. Think about it.
autoconf is useful for c/c++ stuff, especially include paths (what the original post was about...), linking options and so on. For the kind of problem you are talking about, I suggest considering a scripting language like perl or python.
Just for the record, Julian Seward, the principal author of valgrind, is also the author of bzip2.
Open adressing hashing schemes have one inherent problem, especially if you use "double hashing", i.e. collision resolution makes use of a second hashing function.
You can not easily delete an item, you have to marked it as "deleted". No big deal, any decent book on algorithms states this very clearly. What is not so obvious, is that this kind of data structure does not easily recover from bad input. Consider the case where the hash table is 80 percent full, and all the remaining entries are marked as deleted. This will severly degrade unsuccessful search, and there is no easy way of "garbage collection". Probably you need to rebuild the whole table. Not a good thing.
A chained hash does not have this kind of problem, because its state is determined only by its actual content.
Why, 640 KB should be enough for everybody!
What's your problem with other nations having different opinions?
If you really want to draw an analogy to international politics, just think about these points:
which nation is dominating international politics?
which government is at this very moment severely resticting its "users" (think citizens) rights "in their best interest"?
which government is taking the chance to secure profit while talking about security?
which government arguest that "peer review" (think United Nations arms inspection) is a bad thing?
If your answer to all these questions is "France", please think again.
Sorry to correct you, but a STL set can not be implemented as a linked list, because it needs log(n) complexity for inserting or removing elements while makin sure there are no duplicates. One way to do this is a red-black tree like a map, but without additional data at the nodes. If you want a container with double-linked list characteristics, there is std::list.
Yeah, I know, linux only aims at POSIX compliance... Despite some things in linux pthreads that are non-optimal, performance is reasonable, and everythings runs quite stable, once you have found out how to do it, so my critique may sound unfair. I notice you do not agree on my complaint about signal behaviour, and to be honest, this is a somewhat arcane thing also on other systems :-(
However, my main point is that there is no real smooth integration of threads in glibc. IMHO this is much more important than largescale scalability. These guys are working to change that, which is a Very Good Thing(TM). As it is, using threads only makes sense if you really need them, and have time at hand to explore the nifty details that must be correct for a real world application.
Scalability is a good thing, no doubt about that. However, there is another aspect that should be pointed out: the current thread API in linux is quite different from the POSIX specification and somewhat crufty. Just to mention the biggest problems: ... All in all, linux threads really need much better integration with the standard system API. A lot of applications could profit from multithreading. Just think of GUI responsiveness. Also, using threads makes some programming tasks much easier. No need for asynchronous hostname lookup, for example.
missing cancellation points: testing whether a thread has been cancelled should be done in lots of system calls, but linux pthreads do not support this. Instead, you have to call pthread_testcancel() before and after every such call. A real drag.
signal handling: linux pthread signal handling is very different from the POSIX specification. However, proper signal handling is crucial for any real world application.
fork() will not work as expected. This is a real nuissance if you want proper daemon behaviour for your application.
documentation of linux-specific behaviour is poor. As a result, most of the existing literature on thread programming is pretty useless for linux.
All these points can be worked around, for sure. Nevertheless, it makes writing portable software a nightmare. Porting threaded software to linux, well
A solid, well documented, standard conforming threads implementation will make linux a much nicer environment for serious programming than it already is. I am really looking forward to this.
Once upon a time, when salesman were competent engineers, ...
I do not say that the references that barnesreview gives are not correctly cited, but citing nonsense proves nothing. Of course I realize that all this may look somewhat less evident in the United States, but I live in Austria, and I personally know people who lived through these times, some of them are relatives of mine. I have read an original printing of "Mein Kampf". I have visited the death camp in Mauthausen. There is a very good exhibition about the war crimes committed by the Wehrmacht, which has been shown in a lot of places in Germany and Austria. I have seen it. It presents hundreds of photos, documents, etc. which proof without any doubt the awful truth.
Irving and other revisionists simply deny the vast historic research that has been done during the last 50 years. The holocaust has probably been documented and researched more thoroughly than any other historic event in history.
If some guys claim there has never been any slavery in the United States, would you believe them? Even if there were ten of them, all citing each other as evidence?