Though GPS as a system is passive, GPS receivers themselves are NOT completely passive. They use superheterodyne receivers (http://en.wikipedia.org/wiki/Superheterodyne) which produce a detectable radio frequency radiation (and at a fixed frequency).
You'll need a fairly sensitive radio to detect it from more than several centimeters, but it's certainly possible.
I cited these numbers from my memory. I now looked it up - the total losses are estimated from 23 millions to 32 millions of people by different studies. About 60%-75% of losses are estimated as civilian losses.
No. It's NOWHERE that close. The civilian losses of USSR was the mindboggling 26 million people, military losses were about 9 million people (including the partisan forces).
However, I completely agree with your second point.
And in the USSR, probably half of them were due to Stalin's catastrophic leadership, so they could have been avoided No, most of losses in USSR were civilian losses on occupied territories. Military losses don't even come close.
It's a "little known" fact, but nazis wanted to exterminate Slavic people along with the Jews. For example, in Belarus alone about 3 million people were killed by nazis.
Yes, you know nothing about Java. Java is almost as fast as C++ in practice, thanks to its JIT-compiler. Sun JVMs are also very stable, I manage a server farm of 35 servers with our application. I don't even remember the last time a node crashed because of a JVM bug.
Next, Java is _objectively_ better when it comes to security. It's NOT POSSIBLE to make a buffer overflow (and a bunch of other) bugs in Java, even if you tried.
Are you going to say, that if GNUPG, or GNU-Net is written in C, that it's inferior to Freenet JUST because it's written in C and can fall for a buffer overflow exploit? No. However, the chosen language is _important_ for security-oriented projects. C/C++ is just plain dangerous, it creates additional risks for an application designed to make you secure.
That's one of the stupidest post on the Slashdot for a while.
First of all, most of the security bugs ARE FOUND IN THE C/C++ CODE. Java is MUCH MUCH MUCH more secure than C/C++ in practice. To remotely exploit FreeNode, you'll need quite an exotic combination of bugs in JVM _and_ in the FreeNet.
And Java works just fine on PDAs, and FreeNet doesn't use anything fancy and non-portable like cool SWING GUIs.
I cringe at keeping my Linux machines up-to-date and protected What's so hard in it?
"apt-get update; apt-get upgrade;" on a Debian Stable works like a charm (because they push ONLY security and major bugfixes). I manage a farm of 30 servers for about 2 years and Debian update ALWAYS worked without any problem.
Actually, no. Your nose will be almost completely anaesthetized after several breaths.
That's actually a dangerous feature of hydrogen sulfide - it's quite poisonous and you can breath a fatal dose of it without even realizing that you're breathing a poison.
LLVM currently doesn't support _dynamic_ recompilation in runtime with speculative inlining. iPhone just has the static image of compiled binary, with dynamic calls.
That's why Sun JVM is sometimes 'faster' than C++ - it can inline function calls which can not be inlined by a static compiler. So there's no need to abandon OOP niceties to gain some speed.
I wrote several applications for Mac OS X and I don't really like Objective-C. It doesn't have a built-in garbage collector (it's possible to use conservative GC, but it's light years behind GC in Sun JVM), Objective-C is SLOW when you try to use it not only for UI, it doesn't have namespaces, and I also don't like its syntax (though it's a personal preference).
Speed Objective-C is quite OK when you need to write event handlers which are called maybe several times per second. But it's not enough for anything more serious.
Objective C _is_ as slow as Python when it does dynamic function calls. That's because they both use dynamic binding.
Of course, programs in Objective C use plain old C for most of functionality. But once you start using dynamic binding and other goodies - it's the world of SLOW.
>As for threading, Obj-C has an atomic attribute, @synchronized attribute, exception handling across threads, NSLock, NSRecursiveLock, NSConditionLock, and Semaphores. As for Java, you have the monitor attribute, synchronized, and event handling. I believe that both languages do adequately support threads. Both languages are subject to the limitation imposed by their host OS. Ok the JVM could perform multitasking in its own time slice, but boy would that suck...
We just use VPN even in internal networks.
:)
Problem solved
So... A little innocent wi-fi hack crashed network in several buildings?
That's a good reason to do an audit of your network structure. It should not be that easy to crash.
And if they are that flaky - just imagine someone hostile trying to bring down your network.
There is a mention of Moon and Mars flights in the original article (I read Russian).
Though GPS as a system is passive, GPS receivers themselves are NOT completely passive. They use superheterodyne receivers (http://en.wikipedia.org/wiki/Superheterodyne) which produce a detectable radio frequency radiation (and at a fixed frequency).
You'll need a fairly sensitive radio to detect it from more than several centimeters, but it's certainly possible.
Yes, almost right.
I cited these numbers from my memory. I now looked it up - the total losses are estimated from 23 millions to 32 millions of people by different studies. About 60%-75% of losses are estimated as civilian losses.
No. It's NOWHERE that close. The civilian losses of USSR was the mindboggling 26 million people, military losses were about 9 million people (including the partisan forces).
However, I completely agree with your second point.
It's a "little known" fact, but nazis wanted to exterminate Slavic people along with the Jews. For example, in Belarus alone about 3 million people were killed by nazis.
Next, Java is _objectively_ better when it comes to security. It's NOT POSSIBLE to make a buffer overflow (and a bunch of other) bugs in Java, even if you tried.
Are you going to say, that if GNUPG, or GNU-Net is written in C, that it's inferior to Freenet JUST because it's written in C and can fall for a buffer overflow exploit? No. However, the chosen language is _important_ for security-oriented projects. C/C++ is just plain dangerous, it creates additional risks for an application designed to make you secure.
That's one of the stupidest post on the Slashdot for a while.
First of all, most of the security bugs ARE FOUND IN THE C/C++ CODE. Java is MUCH MUCH MUCH more secure than C/C++ in practice. To remotely exploit FreeNode, you'll need quite an exotic combination of bugs in JVM _and_ in the FreeNet.
And Java works just fine on PDAs, and FreeNet doesn't use anything fancy and non-portable like cool SWING GUIs.
"apt-get update; apt-get upgrade;" on a Debian Stable works like a charm (because they push ONLY security and major bugfixes). I manage a farm of 30 servers for about 2 years and Debian update ALWAYS worked without any problem.
Actually, no. Your nose will be almost completely anaesthetized after several breaths.
That's actually a dangerous feature of hydrogen sulfide - it's quite poisonous and you can breath a fatal dose of it without even realizing that you're breathing a poison.
Common MP3 players usually do not have a built-in OS and a powerful CPU.
iPod touch, however, has a processing power comparable to a mid-level PDA, but it's almost completely locked down.
It's a matter of time until VLC supports BD playback. Besides, pure software decoders are mostly useless without hardware accelerators.
No, usually the transplantation clinic does this tests (also checking for contamination during transit, etc.).
It's possible they might not notice cancer, though.
The standard procedure is to check the implant before the transplantation. It surely will be checked for obvious infections like hepatitis and HIV.
Simple.
Open "Task Manager", open "View"->"Select columns". Then choose the columns "Bytes written"/"Bytes read".
You'll be able to spot the offending process without any difficulties.
It was in the official TSA blog, which was discussed here about a month ago.
LLVM currently doesn't support _dynamic_ recompilation in runtime with speculative inlining. iPhone just has the static image of compiled binary, with dynamic calls.
Do you realize that the MAIN feature of the HotSpot compiler is dynamic inlining of virtual methods?
http://en.wikipedia.org/wiki/Java_performance#Adaptive_optimization
That's why Sun JVM is sometimes 'faster' than C++ - it can inline function calls which can not be inlined by a static compiler. So there's no need to abandon OOP niceties to gain some speed.
I remember several Obejctive-C vs. Java comparisons from several years ago, but I can find only one:
http://web.archive.org/web/20040805153930/http://homepage.mac.com/spullara/rants/C1464297901/E775622191/index.html - In this benchmark Objective-C is 6.4 times slower than Java. And it's nothing unexpected - try to walk an Objective-C method call in a debugger in assembly language view someday...
I wrote several applications for Mac OS X and I don't really like Objective-C. It doesn't have a built-in garbage collector (it's possible to use conservative GC, but it's light years behind GC in Sun JVM), Objective-C is SLOW when you try to use it not only for UI, it doesn't have namespaces, and I also don't like its syntax (though it's a personal preference).
Speed Objective-C is quite OK when you need to write event handlers which are called maybe several times per second. But it's not enough for anything more serious.
Objective C _is_ as slow as Python when it does dynamic function calls. That's because they both use dynamic binding.
Of course, programs in Objective C use plain old C for most of functionality. But once you start using dynamic binding and other goodies - it's the world of SLOW.
>As for threading, Obj-C has an atomic attribute, @synchronized attribute, exception handling across threads, NSLock, NSRecursiveLock, NSConditionLock, and Semaphores. As for Java, you have the monitor attribute, synchronized, and event handling. I believe that both languages do adequately support threads. Both languages are subject to the limitation imposed by their host OS. Ok the JVM could perform multitasking in its own time slice, but boy would that suck...
Java also has a very nice concurrency library: http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/index.html and VERY good parallel collections library.
>You are the first person I have seen (outside of Sun) that has used "extremely fast" and "java" in the same sentence. Do you have references?
Ok, now you can see the second person who claims that Java is extremely fast.
References: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=gcc - Java is generally about 20% slower than optimized C, thanks to http://en.wikipedia.org/wiki/HotSpot compiler.
Objective C performance is about the same as Python: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=python - i.e. Java is in general more than 1000% faster.
Oh, and Java GUI can be fast - check Google Android, it has a very nice custom Java GUI, which works blazingly fast on 200MHz CPU.
This start might have exploded 399 million years, 11 months, 30 days and 23 hours ago. So you'll its gamma ray burst will reach the Earth in an hour.
Well, we now know the winner of the next president election in USA.
It's Vladimir Putin.
Makes sense, they are almost on the opposite sides of the reactivity series.