Of course the RIAA only sent the message to people who were actually breaking the law. Why would they send it to those who weren't? If they had, you would have bitched about it anyway, probably more so.
I'm no fan of the RIAA, but I see no problem with them sending messages to people who are quite clearly breaking the law.
On RoadRunner (yes, from Time Warner; DUN-DUN-DUUUUUN) in Minneapolis, I get 2Mbps! Or, I would, if my freeking roommates would close their file sharing programs. *sigh*
I looked at DSL before getting cable, as I really wanted to have VISI as my ISP, but the price difference is absurd. DSL is much, much more expensive for equivalent bandwidth.
Looks like God forgot to check for integer overflow when he coded the universe!
Mr. Andrew Jackson here (that's $20 for those of you not familiar with US currency) says the width of the universe is a power of two (times the minimum quantized unit of length)!
See, back in 1993, I told you to get one of them top-loading NES's. They were selling for only $50. But NOOOOOOO, you said your old box version was doing just fine. Now, ten years later, who's system still works perfectly? Hmmm? Serves you right.
(Of course, I never use the thing. Emulators and all. Wonder how much I could sell it for on e-bay...)
That wasn't microsoft.com. That was some poor MS developer's code test server. It wasn't even meant to be open to the public. I don't think that counts.
Just to point out... According to the article, this guy was in charge of Microsoft's network's security, not Microsoft's software's security. The fact that he has been able to keep that web site, which runs on NT, from being cracked for so many years must qualify him as some sort of security god.
(If I am misinformed, and microsoft.com has actually been cracked and defaced at some point in the past, do tell...)
Yes, I know. It's because he looks for his own shortcomings and because he is unbaised (not looking to prove anything in particular) that I think his results are more accurate than any other I've seen. He obviously wasn't trying to prove Java was fast. He was trying to get accurate results as much as he could.
BTW, if you had looked harder, you would have seen that the only switches he used were "-classpath" and "-verbose".
http://www.bagley.org/~doug/shootout/craps.shtml Here you see Java scoring 703 vs. C's 752 in a wide range of unbiased speed tests. Do you have anything to back up your claim?
(I would have made that an HTML link, but the site checks the referring URL and gives you a page about how much Slashdot sucks if you are coming from Slashdot.)
As I understand it, you have to use modified versions of the languages if you want to get "verifiable" bytecode... that is, bytecode which users can verify is safe to run even if they don't trust the source. This mainly means restriction of raw pointers and some other things. I'm pretty sure you can compile standard C++ to unverifiable CLR code... or, at least, it is technically possible.
The Java virtual machine is very much designed around the Java programming language. I have heard about other languages being able to compile to it (isn't there an Ada -> JVM compiler?), but basically the language has to be lucky and use the same general feature set. Compiling C++ to the JVM would not be reasonably possible, since the JVM does not support raw pointers (for a good reason: if pointers were allowed, it would be impossible to verify that a Java applet was safe to run locally).
Microsoft's CLR (common language runtime; part of.NET) defines a virtual machine which can run many languages, while posessing the verifiably secure properties of Java bytecode specifically for those languages which make such verifiability possible (basically, languages without raw pointers). If you want a VM that supports multiple languages, the CLR is really the best option right now.
Personally, I am not convinced that such a common runtime is always an advantage. The CLR basically defines its own machine language, with all the basic instructions you'd see in any other assembly language. I don't like that approach because it is too low-level, and makes optimization harder. Allow me to explain...
It is a rather common misconception that bytecode-compiled languages must necessarily be slower than native compiled languages. The opposite is actually true in many cases. If you are running your bytecode on some sort of interpreter, then yes, it will be slower, but typically bytecode is re-compiled to native code at runtime. When this happens, the compiler can perform all sorts of optimizations specific to the host machine, OS, and the exact library set in use, which would be impossible if the software were distributed as native code. Thus, the code actually ends up faster... in Java's case, it can approach the speed of C, which is surprising considering all the abstraction in the Java language -- based on the languages alone, you would expect Java to be much slower.
Anyway, getting back to the point, higher level bytecode descriptions allow more optimization on the host machine. I am actually desiging a programming language right now, and my bytecode is only a little more than a parse tree. I like it that way.:)
Just think of the language runtime like a library. Different programs use different libraries. What's wrong with that?
Read the paper, will you? Of course good programmers don't write redundant code... at least, not intentionally. So, when you do see redundant code in a program, it is more likely a typo, and if it's a typo, it is likely a bug. So, if you have a program which detects redundant code, it will likely find bugs for you. They wrote such a program. It found hundreds of bugs in the Linux kernel.
Here's an example they cite from the Linux kernel:
/* 2.4.1/net/appletalk/aarp.c:aarp_rcv */ else {/* We need to make a copy of the entry. */
da.s_node = sa.s_node;
da.s_net = da.s_net;
That last line assigns a variable to itself. Do you think that's what the programmer intended? Of course not. It's a bug. But no one caught it. If not for their program, maybe it would never have been caught.
You think this research is useless? Do you always write bug-free code? Maybe you should run this program on your own code and see what happens.
Correction: Apparently (according to another poster), you need to add 10 bits to an RSA key to double the strength of the encryption. It would actually only take a little over 10^53 times the age of our universe to crack. So, never mind about having Duke Nukem Forever by then.
So, for a 64-bit key, it took five years? Correct me if I'm wrong, but at that rate, won't the 2048-bit key only take about 5 * 2^(2048 - 64), or a little over 2^1986 years to compute? I think that's somewhere around 10^587 times the age of our universe.
By that time, we'll all be playing Duke Nukem Forever on our Itanium-based systems running GNU/HURD and the Fesco windowing system. Open source software will have gone mainstream, giving us no reason to care about hacking the X-Box. Right?
Re:Seconding "Complete Waste of SlashDot Space" gr
on
Star Wars Origami
·
· Score: 2
No no no, you're going at it all wrong. If you try to treat Slashdot like a respectable news site or a place for intelligent discussion, you'll only get frustrated. Instead, set your reason modifiers so that anything modded "funny" gets +5 and everything else gets -5. Then, treat Slashdot like a humor site. It turns out to be one of the best!
Could real time medical rendering be whizzier than Id?
Probably, but not because of this. This technique would have very little use in a gaming environment. Indeed, algorithms indended for medical imaging rarely do. In this particular case, the dotted images don't really provide any sort of occlusion. That is, you can see right through the image to whatever is behind it. Great for medicine (where the whole point is to see inside the patient's body), bad for games.
As a matter of fact, when I read this, my only thought is "well, duh". I do 3D graphics myself, and I am having a hard time believing that this technique is new. Particle system rendering? There must be something more to this that the dumbed-down article isn't telling us. Maybe they have a new, advanced algorithm for deciding exactly where to place the dots... that really must be it. As long as we're reporting on low-level algorithms, I have a new algorithm I came up with for drawing borders on the silouette edges of cartoon renderings efficiently. Do you want to hear about it? No? Aww...
Slashdot Mirror
Of course the RIAA only sent the message to people who were actually breaking the law. Why would they send it to those who weren't? If they had, you would have bitched about it anyway, probably more so.
I'm no fan of the RIAA, but I see no problem with them sending messages to people who are quite clearly breaking the law.
for STORY; do
POST=no
#(CT) removed to increase efficiency
#rtfa $STORY
#ispell $STORY
if grep "Linux\|DMCA\|Microsoft\|Star Wars" $STORY; then
POST=yes
fi
if grep $STORY $PREVIOUS_STORIES; then
POST=noo
fi
if [ $POST != no ]; then
post $STORY
fi
done
On RoadRunner (yes, from Time Warner; DUN-DUN-DUUUUUN) in Minneapolis, I get 2Mbps! Or, I would, if my freeking roommates would close their file sharing programs. *sigh*
I looked at DSL before getting cable, as I really wanted to have VISI as my ISP, but the price difference is absurd. DSL is much, much more expensive for equivalent bandwidth.
Dude! I didn't know that Daler Mehndi (Indian pop star) was a senior VP for SCO. Damn, my respect for Mehndi just went downhill.
Are you saying you would have believed this article on any other day? This is Slashdot, after all. :P
if ((post.speling = "incorect") && (post.usesdoubleequalsforassignment)) {
post.auther = "CmdrTaco";
}
if((post.usesSingleEqualsForComparison)...
Aww, forget it!
I'll bet we could kill every single person on the face of the earth in, say, six months tops.
Been there, done that.
Looks like God forgot to check for integer overflow when he coded the universe!
Mr. Andrew Jackson here (that's $20 for those of you not familiar with US currency) says the width of the universe is a power of two (times the minimum quantized unit of length)!
See, back in 1993, I told you to get one of them top-loading NES's. They were selling for only $50. But NOOOOOOO, you said your old box version was doing just fine. Now, ten years later, who's system still works perfectly? Hmmm? Serves you right.
(Of course, I never use the thing. Emulators and all. Wonder how much I could sell it for on e-bay...)
That wasn't microsoft.com. That was some poor MS developer's code test server. It wasn't even meant to be open to the public. I don't think that counts.
Just to point out... According to the article, this guy was in charge of Microsoft's network's security, not Microsoft's software's security. The fact that he has been able to keep that web site, which runs on NT, from being cracked for so many years must qualify him as some sort of security god.
(If I am misinformed, and microsoft.com has actually been cracked and defaced at some point in the past, do tell...)
Furthemore, an erroneous lookup results in getting a VeriSign IP, not an error message.
So, does this mean I will be able to type in "http://shittyassregistrar.com" and get VeriSign?
Yes, I know. It's because he looks for his own shortcomings and because he is unbaised (not looking to prove anything in particular) that I think his results are more accurate than any other I've seen. He obviously wasn't trying to prove Java was fast. He was trying to get accurate results as much as he could.
BTW, if you had looked harder, you would have seen that the only switches he used were "-classpath" and "-verbose".
Yeah, well... so the GUI library is slow. That's the GUI library's fault, not the language. You can write a slow library in C, too.
http://www.bagley.org/~doug/shootout/craps.shtml
Here you see Java scoring 703 vs. C's 752 in a wide range of unbiased speed tests. Do you have anything to back up your claim?
(I would have made that an HTML link, but the site checks the referring URL and gives you a page about how much Slashdot sucks if you are coming from Slashdot.)
As I understand it, you have to use modified versions of the languages if you want to get "verifiable" bytecode... that is, bytecode which users can verify is safe to run even if they don't trust the source. This mainly means restriction of raw pointers and some other things. I'm pretty sure you can compile standard C++ to unverifiable CLR code... or, at least, it is technically possible.
The Java virtual machine is very much designed around the Java programming language. I have heard about other languages being able to compile to it (isn't there an Ada -> JVM compiler?), but basically the language has to be lucky and use the same general feature set. Compiling C++ to the JVM would not be reasonably possible, since the JVM does not support raw pointers (for a good reason: if pointers were allowed, it would be impossible to verify that a Java applet was safe to run locally).
.NET) defines a virtual machine which can run many languages, while posessing the verifiably secure properties of Java bytecode specifically for those languages which make such verifiability possible (basically, languages without raw pointers). If you want a VM that supports multiple languages, the CLR is really the best option right now.
:)
Microsoft's CLR (common language runtime; part of
Personally, I am not convinced that such a common runtime is always an advantage. The CLR basically defines its own machine language, with all the basic instructions you'd see in any other assembly language. I don't like that approach because it is too low-level, and makes optimization harder. Allow me to explain...
It is a rather common misconception that bytecode-compiled languages must necessarily be slower than native compiled languages. The opposite is actually true in many cases. If you are running your bytecode on some sort of interpreter, then yes, it will be slower, but typically bytecode is re-compiled to native code at runtime. When this happens, the compiler can perform all sorts of optimizations specific to the host machine, OS, and the exact library set in use, which would be impossible if the software were distributed as native code. Thus, the code actually ends up faster... in Java's case, it can approach the speed of C, which is surprising considering all the abstraction in the Java language -- based on the languages alone, you would expect Java to be much slower.
Anyway, getting back to the point, higher level bytecode descriptions allow more optimization on the host machine. I am actually desiging a programming language right now, and my bytecode is only a little more than a parse tree. I like it that way.
Just think of the language runtime like a library. Different programs use different libraries. What's wrong with that?
Here's an example they cite from the Linux kernel:That last line assigns a variable to itself. Do you think that's what the programmer intended? Of course not. It's a bug. But no one caught it. If not for their program, maybe it would never have been caught.
You think this research is useless? Do you always write bug-free code? Maybe you should run this program on your own code and see what happens.
If the page loads too slow, you might want to try Google's cached copy.
Correction: Apparently (according to another poster), you need to add 10 bits to an RSA key to double the strength of the encryption. It would actually only take a little over 10^53 times the age of our universe to crack. So, never mind about having Duke Nukem Forever by then.
So, for a 64-bit key, it took five years? Correct me if I'm wrong, but at that rate, won't the 2048-bit key only take about 5 * 2^(2048 - 64), or a little over 2^1986 years to compute? I think that's somewhere around 10^587 times the age of our universe.
By that time, we'll all be playing Duke Nukem Forever on our Itanium-based systems running GNU/HURD and the Fesco windowing system. Open source software will have gone mainstream, giving us no reason to care about hacking the X-Box. Right?
No no no, you're going at it all wrong. If you try to treat Slashdot like a respectable news site or a place for intelligent discussion, you'll only get frustrated. Instead, set your reason modifiers so that anything modded "funny" gets +5 and everything else gets -5. Then, treat Slashdot like a humor site. It turns out to be one of the best!
It's a direct quote from "Good Morning, Vietnam". Great movie.
"Sir, if the VP is such a VIP, shouldn't we keep his PC on the QT? If it leaks to the VC, he could become an MIA, and then we'd all be put on KP."
(Sorry. I've been up all night coding again.)
Could real time medical rendering be whizzier than Id?
Probably, but not because of this. This technique would have very little use in a gaming environment. Indeed, algorithms indended for medical imaging rarely do. In this particular case, the dotted images don't really provide any sort of occlusion. That is, you can see right through the image to whatever is behind it. Great for medicine (where the whole point is to see inside the patient's body), bad for games.
As a matter of fact, when I read this, my only thought is "well, duh". I do 3D graphics myself, and I am having a hard time believing that this technique is new. Particle system rendering? There must be something more to this that the dumbed-down article isn't telling us. Maybe they have a new, advanced algorithm for deciding exactly where to place the dots... that really must be it. As long as we're reporting on low-level algorithms, I have a new algorithm I came up with for drawing borders on the silouette edges of cartoon renderings efficiently. Do you want to hear about it? No? Aww...