Nobody else should be charging either of us extra to talk to each other as fast as any other website on the internet.
If anything the opposite should be true.
I have something like 2G of mobile data a month, but some services (e.g. Faceboo, Spotify, SD Netflix) are not metered. When there is competition, making popular services cheaper means their service is more valuable.
This is a myth. When you factor out the high infant mortality rate, average life expectancy in the Roman world was somewhere around the late 50s. So a little under half of everyone who made it to (say) age 10 could be expected to live into their 60s.
Please read what I said again, bearing in mind that this story is about interpreters. There have been PLENTY of standard library exploits, but I can't think of any JVM bugs that have been exploited. There might be a couple of obscure ones.
That is fair, that the JVM hasn't been exploited. That is partly because you have to get through the verifier first.
If you're using JNI, you are already on the other side of the airlock. Unless you can get malicious JNI loaded from the outside, a JNI attack is not a JVM flaw.
I don't see what's different about them, beyond perhaps the fact that camera lenses aren't perfect so there is going to be some leak around the shadow perimeter.
I don't really understand what you're referring to. The 2 second exposure example looks red to me; I pulled the image into GIMP, eyedroppered a point inside the shadow, and the RGB values were (82,54,51).
Having said that, colour reproduction is more art than science. Every professional photograph or movie that you have ever seen has been colour timed or colour graded before it made it to your eyes. The raw numbers that come out of a modern astronomical observatory are not meaningful by themselves, and need to be visualised to be meaningful.
Most consumer-grade cameras, as well as your eyes, have automatic exposure control. So it's unsurprising that you will perceive both the Moon and the Earth's shadow as brighter as the amount of light decreases.
I don't live in North America, but I would encourage you next time to set out a camera with the exposure set manually to slow (an astronomical photographer should be able to suggest a good setting) and see if the shadow is red for the entire eclipse. The best experiment would be to use three cameras side by side: one fast, one slow, and one auto.
Now the catch is that the moon is also round, so reflection off the silhouette edge is darker than that of the part that faces us. But the Moon surface is enough of a retro reflector (the Oren-Nayar model captures it reasonably well to a first approximation) that it should be visible.
This is hust a guess, but the shadow colour "changing" and the unshadowed part "brightening" are probably the same thing: the camera exposure was adjusted in post. The dynamic range of the camera is much greater than that of the video format.
Your eyes do the same thing if you walk from a dark room to a light room and vice versa. The room is too bright (and a different colour saturation) until your automatic gain control compensates.
Surely that's the point? The places where you tend to see C and C++ used the most are precisely those situations where an abstracted software environment is not the platform, the hardware and the OS are the platform.
b) C and C++ are not so fast anymore. There was a time where you couldn't write better code in assembler than a well optimized C or C++ code set could produce. Working in tools like Intel vTune Amplifier and optimizing your C or C++ code allowed amazing code performance to be achieved. Then money was spent on JIT technologies and hand optimized JIT code ended up being substantially faster in most cases.
I respectfully disagree about "most cases".
The cases where managed JIT-compiled languages tend to do win big compared to C++ are those cases where abstractions can be compiled away at run-time because they are not used. The classic case is engineering for testability; Java programmers often make an interface for every "important" class so that it can be replaced with a mock or stub during test time. Hotspot can compile these interfaces away at run-time because the mocks and stubs are never used at run-time.
It's worth pointing out that this only applies to languages like Java or C#. These optimisations are typically not available to Node.JS.
You get a small win from tuning the compiled code to the platform on which the system is actually running, but in my experience you lose it back in virtual machine overhead (e.g. memory footprint).
Managed JIT-compiled languages tend to do worse on the most common and most important data structure in existence: the array of structs. This is why any program which is algorithmically nontrivial is almost always slower in a managed JIT-compiled language than in C++.
Having said that, there's a lot of algorithmically trivial code out there. The modern world basically runs on scripting/glue layers.
But for me, the biggest issue is this: A critical mass of software these days run on machines that are powered by batteries, and it's only going to get worse. CPU cycles are no longer the most important factor to optimise for. Battery life is far more important. In this environment, compiling at run-time is the worst of all possible worlds.
Just try it, then look at the assembly code... "register" most likely got ignored.
Deprecating "register" is one design decision that I am a little ambivalent about. What it should mean is "it is an error to take the address of this variable", no more and no less.
It's a niche feature, but one that's occasionally useful.
It's usually considered a weakness of language design to disallow certain combinations of orthogonal features just because you can't see a use for those combinations.
Imposing exceptions to rules makes a language spec more complicated, not less.
Slashdot Mirror
Nobody else should be charging either of us extra to talk to each other as fast as any other website on the internet.
If anything the opposite should be true.
I have something like 2G of mobile data a month, but some services (e.g. Faceboo, Spotify, SD Netflix) are not metered. When there is competition, making popular services cheaper means their service is more valuable.
This is a myth. When you factor out the high infant mortality rate, average life expectancy in the Roman world was somewhere around the late 50s. So a little under half of everyone who made it to (say) age 10 could be expected to live into their 60s.
Not really -- all it needs to do is measure temperature.
Or humidity. Or both.
How many of those were JVM exploits?
Please read what I said again, bearing in mind that this story is about interpreters. There have been PLENTY of standard library exploits, but I can't think of any JVM bugs that have been exploited. There might be a couple of obscure ones.
That is fair, that the JVM hasn't been exploited. That is partly because you have to get through the verifier first.
If you're using JNI, you are already on the other side of the airlock. Unless you can get malicious JNI loaded from the outside, a JNI attack is not a JVM flaw.
To pick an obvious example, there has never to my knowledge been an exploitable bug in the JVM. Plenty in the standard library though.
I don't see what's different about them, beyond perhaps the fact that camera lenses aren't perfect so there is going to be some leak around the shadow perimeter.
I don't really understand what you're referring to. The 2 second exposure example looks red to me; I pulled the image into GIMP, eyedroppered a point inside the shadow, and the RGB values were (82,54,51).
Having said that, colour reproduction is more art than science. Every professional photograph or movie that you have ever seen has been colour timed or colour graded before it made it to your eyes. The raw numbers that come out of a modern astronomical observatory are not meaningful by themselves, and need to be visualised to be meaningful.
If it were so obvious, how come I had to explain it? Take that, round Earthers!
Most consumer-grade cameras, as well as your eyes, have automatic exposure control. So it's unsurprising that you will perceive both the Moon and the Earth's shadow as brighter as the amount of light decreases.
I don't live in North America, but I would encourage you next time to set out a camera with the exposure set manually to slow (an astronomical photographer should be able to suggest a good setting) and see if the shadow is red for the entire eclipse. The best experiment would be to use three cameras side by side: one fast, one slow, and one auto.
Now the catch is that the moon is also round, so reflection off the silhouette edge is darker than that of the part that faces us. But the Moon surface is enough of a retro reflector (the Oren-Nayar model captures it reasonably well to a first approximation) that it should be visible.
Do the experiment.
This is hust a guess, but the shadow colour "changing" and the unshadowed part "brightening" are probably the same thing: the camera exposure was adjusted in post. The dynamic range of the camera is much greater than that of the video format.
Your eyes do the same thing if you walk from a dark room to a light room and vice versa. The room is too bright (and a different colour saturation) until your automatic gain control compensates.
There is a biologist named Elisabetta Coli. She caused some headaches for bio text researchers.
^ Neither Kim Dotcom nor Julian Assange detected.
Not in Australia, they can't.
...and here's the proof.
Only division (and plain right shift) actually works differently on signed vs unsigned types.
Also comparisons and word extensions (zero extension vs signed extension). I've probably missed one or two more operations.
Congratulations, you are the only person on the Internet today who used the term "SJW" correctly.
I like it. In Javanese (i.e. the actual Java language), it means "unsteady".
Neither C or C++ are useful as a platform.
Surely that's the point? The places where you tend to see C and C++ used the most are precisely those situations where an abstracted software environment is not the platform, the hardware and the OS are the platform.
b) C and C++ are not so fast anymore. There was a time where you couldn't write better code in assembler than a well optimized C or C++ code set could produce. Working in tools like Intel vTune Amplifier and optimizing your C or C++ code allowed amazing code performance to be achieved. Then money was spent on JIT technologies and hand optimized JIT code ended up being substantially faster in most cases.
I respectfully disagree about "most cases".
The cases where managed JIT-compiled languages tend to do win big compared to C++ are those cases where abstractions can be compiled away at run-time because they are not used. The classic case is engineering for testability; Java programmers often make an interface for every "important" class so that it can be replaced with a mock or stub during test time. Hotspot can compile these interfaces away at run-time because the mocks and stubs are never used at run-time.
It's worth pointing out that this only applies to languages like Java or C#. These optimisations are typically not available to Node.JS.
You get a small win from tuning the compiled code to the platform on which the system is actually running, but in my experience you lose it back in virtual machine overhead (e.g. memory footprint).
Managed JIT-compiled languages tend to do worse on the most common and most important data structure in existence: the array of structs. This is why any program which is algorithmically nontrivial is almost always slower in a managed JIT-compiled language than in C++.
Having said that, there's a lot of algorithmically trivial code out there. The modern world basically runs on scripting/glue layers.
But for me, the biggest issue is this: A critical mass of software these days run on machines that are powered by batteries, and it's only going to get worse. CPU cycles are no longer the most important factor to optimise for. Battery life is far more important. In this environment, compiling at run-time is the worst of all possible worlds.
Just try it, then look at the assembly code ... "register" most likely got ignored.
Deprecating "register" is one design decision that I am a little ambivalent about. What it should mean is "it is an error to take the address of this variable", no more and no less.
It's a niche feature, but one that's occasionally useful.
Is there anything of value to read here?
It's a post-9/11 ESR blog post that's not about Colossal Cave Adventure. So no.
In the case of ESR rants, it was twice this month.
On x86-64 there are two calling conventions: Windows and SysV (used by everything except Windows).
Non-C languages may do other stuff, but as far as C and C++ are concerned, there are two.
It's usually considered a weakness of language design to disallow certain combinations of orthogonal features just because you can't see a use for those combinations.
Imposing exceptions to rules makes a language spec more complicated, not less.
To be fair, that was back in the day when OO was considered to be an advantage. My how times have changed.