Weekly Microsoft Critical Security Issue 518
An anonymous reader sent in linkage to a zd story discussing the latest Windows Security Patches including an especially nice hole letting Java apps gain total control of your machine and assist you in reclaiming disk space by, say, reformating your drive.
But quickly fixed... (Score:5, Informative)
Re:jvm (Score:4, Informative)
It's MICROSOFT'S JAVA IMPLEMENTATION.
The problem is NOT Java.
The problem is (and always has been) Micro$oft's purposely broken version of Java.
RTFA (Score:5, Informative)
The three warnings, all issued on Wednesday, involve the Microsoft Virtual Machine for running Java applets on Windows
So it's Microsoft's VM implementation...
Re:Hmm... (Score:5, Informative)
Actually the court order is to put Sun's version of the JVM into Windows - exactly to fix this type of stupid problem.
Applets, not apps. (Score:4, Informative)
Re:And in other news... (Score:2, Informative)
Look troll, blah blah blah.
I'm sick of this crap. There is no 100% secure OS for the x86 platform. None.
Download the patch without Windows Update (Score:2, Informative)
If you don't want to run Windows Update, or don't want to use Internet Explorer 5+ in order to use Windows Update, here is a list [microsoft.com] of recent security related patches that you can download individually.
Of course, you should realize that you have already signed your soul over to Microsoft by having Windows on your machine. You might as well close your eyes and agree to the EULA for Windows Update.
Why is anyone using MS' Java VM? (Score:3, Informative)
Re:Tech support != "geeks" (Score:3, Informative)
No, they don't occur purely because of failed memory allocations. If a memory allocation fails, the pointer will be uninitialized and the application will segfault due to that. You just don't understand what you are talking about.
Several people there have said they've actually solved segfaults by re-clocking their over-clocked CPUs to normal speeds, or slowing down the memory-speed-settings. These are things people have done that have actually eliminated segfaults. In other words, segfaults ARE the fault of the hardware (namely, overclocked CPU, RAM running speed-settings that are too high, and/or bad RAM).
Ok, Mr. Doesn't know shit, the reason why this happens is because if you overclock a CPU sometimes your memory allocations will fail. Memory allocations do not cause segfaults. Poor application development does.
Segmentation faults are entirely an applications fault. They are caused by people doing this: Without verifying that "variable" was properly allocated. Under no circumstances, with a properly designed application, will hardware cause a segmentation fault.
From the SIG11 page, and I'm going to bold this for you:
Signal 11, or officially know as "segmentation fault", means that the program accessed a memory location that was not assigned. That's usually a bug in the program. So if you're writing your own program, that's the most likely cause. However, this FAQ will concentrate on the possibilities besides that.
Do you see hardware in there at all? No.
So go play with your little toys, and let the real men write code and understand. So, while it's funny to read you spouting off about this, you are still wrong. Even better how you proudly proclaim you don't believe in stupid things, but you believe in yourself.
Keep it up, Chim Chim, maybe someday Sparky will let you fix Mach 5!