But that's not flipping a spin. It's flipping two spins, which is different because the total angular momentum is the same before and after the flipping.
Flipping the spin is measuring in the quantum mechanical sense. Perhaps you should think 'interaction' instead of 'measurement'.
Spin is angular momentum. Angular momentum is conserved. Thus, to change the angular momentum of something means interacting with it.
I don't care about determining the spins of the particles
It doesn't matter if you care or not. It doesn't matter if you look at the results or not. It doesn't matter if it's you even have a result. What matters is that an interaction happened, where you could, in theory have received information about the spin state.
What if the unsuspecting electron is one of a correlated pair? When the flip occurs, does the sibling electron (perhaps a galaxy away) simultaneously flip
No. Flipping the spin is performing a measurement.
All I'm meaning is that in order to push performance to the limits, game developers often use or find undocumented features of the system.
In the 80's, yes. I don't believe they do so today. First off, at the speed hardware is changing it's not worth the effort to microoptimize like that.
Not to mention the fact that the thing does have an API and an OS. Those things were nonexistant before, which encouraged that kind of stuff.
Secondly, the platform isn't static. Revisions to the OS and hardware occur. Using undocumented stuff is putting yourself at great risk of having your code break.
But the more they tighten the secuirity model, the more strictly compliant the ported code will need to be.
IIRC, the only security holes found so far in the original X-box which didn't require a modchip were buffer overrun failures. Not due to using 'undocumented features' of any sort, but rather a simple programming error.
Microsoft could easily fix that by having a nonexecutable stack, for instance. That would not put any additional requirements whatsoever on the programmers.
I don't buy it. Could you give a real example of a program using an undocumented feature, and also explain how it constituted a security problem?
Interesting how, just today a columnist in Dagens Nyheter (largest newspaper in Sweden) wrote a column about blogging. He drew a parallel to other fads, the one he specifically mentioned was the early 90's Grunge trend.
These trends were first hailed as something new and different, which would change the world, only to subsequently be adopted by the mainstream/the existing powers, and eventually died off without actually changing anything. (The anti-fashion 'grunge look' became the fashion, then went out of fashion, then things were as they were before.)
The parallel he saw, was in the increasing amount of Celebrity blogging. People who are already in the mainstream media are increasingly starting to blog themselves, and that's corrupting the original visions of blogs being a kind of "even playing field".
Now I'm not sure whether the columnist was right or wrong about this. (I can't and won't predict the future.) But I thought it was an interesting thought anyway.
The harder they lock it down, the harder they make it for partners to port to their platform.
Care to elaborate on that? Because I can't see the connection.
What makes it easy or hard for partners to port to their platform is the OS itself, and the quality of the SDK and tools provided by MS. Microsoft has long been very good at giving devs what they want.
The original Xbox required developers to get their copy signed off by MS. I see absolutely no reason why they can't add security without adding to that inconvenience.
According to Webster's napalm is not sodium palmitate, but naphthene palmitate.
So, I stand corrected. But on the other hand, "naphthene palmitate" isn't a compound, "Naphtene" is just a group term for unsaturated polycarbons, those present in naphtha, which in turn is an older word for gasoline.
So "naphthene palmitate" probably means here "gasoline mixed with some palmitate salt", which makes sense chemically since there shouldn't be any significant difference whether you use sodium palmitate or potassium palmitate or any other palmitate salt, as long as it still retains its detergent effect.
This year, we lost out right at the bottom, with only 18 points. Compare that to a Moldovan granny banging a drum, which sailed on to 6th place with 128 points.
You can't quite blame that on friendship voting though. (I.e. they got points from a lot more places than just their neighbors)
The group in question (Zdob si Zdub), is an established group in East Europe (4 albums), with several hits and are pretty well known in Russia, the Ukraine, Belarus, Romania, Hungary, etc.
Like them or not, a lot of East Europe does and that's more of a cultural thing than a friendship thing.
Friendship only goes so far too.. Norway only gave Sweden (who's song totally sucked) a single point.
Is this what they mean when they say the company is going south?
Re:I was under the impression...
on
Open source Java?
·
· Score: 5, Informative
Blackdown, Kaffe, GCJ, and quite a few similar "branches", all getting somewhere 60% down the way and stopping there. Somehow I don't quite believe the new project will get anywhere near "usable" as well.
Ok, first Blackdown is 100%. It's not an open source VM. It's a port of Sun's.
Kaffe and GCJ haven't stopped anywhere. Both are using the same class library (GNU Classpath).
As an end user? No real reason why you should download one over the other. Ideally one will do as well as the other.
However, if you're using Linux (most distros don't accept Sun's licensing) you won't have to do that, since a FOSS distro wouldn't have the same terms.
If you're using an operating system which Sun's java doesn't support, you're plain out of luck. A FOSS JVM is more likely to be ported. And you can do it yourself if bad comes to worse.
Lastly, having a second implementation avoids vendor lock-in. Today there is no other implementation of Java than Sun's. (Apple, IBM, Blackdown and all that are based off Sun's code)
Re:gcj and the new license wars
on
Open source Java?
·
· Score: 4, Insightful
Why start from scratch? It this simply because the Apache folks don't like the GPL?
Actually it hasn't been decided if they will start from scratch yet. They might adopt an existing VM. They might adopt the GNU Classpath class library.
The discussions on checking up the inevitable licensing issues are already underway.
I think it's just incompetence or bad design on the part of Sun rather than a deliberate decision
Right, I don't attribute to malice what can be explained by incompetence either.
But.. I don't feel Sun has done enough to discourage this stuff. I've seen Sun example code using com.sun classes. Usually saying "You shouldn't really use this".
The sloppiness does actually extend to the public API in places, too.
Personally (and perhaps somewhat sadistically) I'd like to see Sun just rename all internal packages in com.sun.* for no other reason than to break those bad apps and have people fix them. If write-once-run-anywhere is as important as Sun makes it out to be, they should.
When Classpath is turning almost compliant, Apache tries to help it's accepance by requesting them to move the code to the Apache Licence.
Not true. Apache Harmony is an effort for an Apache VM. They haven't decided yet if that means writing their own from scratch or adopting one.
They haven't decided yet if they're going to use GNU Classpath either. Although it is very, very likely.
Apache has not requested that Classpath change its license. Firstly because they haven't decided to use it yet. Secondly because there is no percived reason to; So far noone has brought up any reason to belive the Classpath license is incompatible with the Apache one.
What has happened is that the Classpath hackers have said that if they chose to use Classpath, and if there is some minor problem with the license, then they will be prepared to tweak the license as to be compatible. But relicensing the code under the Apache license has not come up.
In any case. It's not about supporting Classpath or IBM. It's about their own self-interest. Apache has more Open Source java code than any other single entity out there. Why would they not want a Open Source JVM to run it on?
The aquarium may have less surface area than his computer, but the computer isn't the part that gets hot.. it's really just the CPU chip (and perhaps some graphics processing chips) that get hot.
That's because they have fans pushing air at them and out through the case. Air doesn't conduct heat well, and doesn't have time to warm the case significantly. If you turned the fans off, the case would start to heat up. But since the motherboard and things in between the chip and case conduct heat rather poorly, the chip would likely get too hot before the case got very warm.
In this setup, you have a much more heat-conductive medium, which is not moving around as much, and is not being exchanged with a huge reservoir around it held at ambient temperature. The chips will get too hot unless the oil can conduct heat fast enough to the aquarium walls (the only place it can go).
If the walls can't dissipitate that heat at an equal or greater rate, the oil will start to heat up, causing the walls to dissipitate more heat (warmer objects emit heat faster than colder ones (Stefan-Boltzmann law)), eventually you'll reach an equillibrium where the walls are emitting the same amount of heat which is produced and the temperature will be stable.
I don't see why I should automatically believe: 1) That the oil and walls can transport away heat from the chips fast enough to avoid them reaching an unhealthy temperature
2) That that transport will be more efficient than just cooling the hot parts by blowing air through them, and letting the rest of the machine remain at more-or-less ambient temperature.
The average temperature of the machine will almost certainly be higher. Since most of the case and things inside it are almost room-temperature during normal use. The temperature of the oil is not going to be colder than room temperature, and it is in direct contact with all the hottest parts, as well as the case.
That's correct and all. But I took that into account, I was referring to the equillibrium temperature, at which the thing isn't getting either hotter or colder.
While the aquarium may have less total area, the conduction of heat to the aquarium walls through oil is much, much more efficient than through air to the walls of an aluminum case, resulting in far better heat dissipation overall.
Yes, but the heat dissipitation in the case of air is promoted by having fans pushing outside air through the thing - the heat dissipitated by the case isn't significant. (typically the outer part of a computer case isn't noticably warmer than the ambient temp)
With this setup, the heat can only escape via the aquarium walls, which don't have any air being pushed around to cool them. In addition to a lower total area.
I don't see why it'd be a given that the setup has far better heat dissipitation.
Now seriously, rub two brain cells together and come up with whose fault this is: Is it Sun's for providing unsupported libraries for developers to play with, or the OO.o developer who disregarded the warning that every Java codemonkey with more than a week's experience knows by heart and went ahead and used sun.* packages in a production-bound system. He shoots his own code in the ass, and it comes out to be Sun's fault. Fucking brilliant!
Yes, because the OOo coder in question works for Sun. Heard of StarOffice? Sun's version of OOo? Well these java parts come from there.
It's not the Sun Java guy's fault. It's the Sun StarOffice guy's fault.
The thing is, he might be getting rid of less heat total, but he's evening out the average heat of the board, which is a good thing. The parts of the board in an air-cooled rig that would be really hot are down at the same level as the rest of the oil, no hot spots, which is the benefit.
Well, you can certainly have hot-spots in the oil too.
The fans (if they really are working..) aren't built for pushing a viscous fluid like oil. The distance between the fins of the cooling block aren't dimensioned for oil either. The flow around the CPU cooler fins may very well be limited to diffusion and convection. (natural draught)
That might be enough. But it might not.
(I've studied fluid- and thermodynamics once upon a time and done these kinds of calculations.. but not enough to be able to say anything offhand.)
So oil conducts heat much better than air. So the heat is going to be conducted away.. where? Hmm.. the aquarium walls. Then where does it go? Into the surrounding air. At a rate determined by the amount of surface area (and the airflow).
Thing is, I wager the aquarium walls have a lower total area against the surrounding air than his computer would've had otherwise. Which would mean that he's actually getting rid of less heat, and that in the long run (e.g. when the abient temperature, oil temp and computer temp have reached equillibrium) his computer is going to be a lot warmer than it was.
Or?
(And I can imagine that oil doing quite nasty things to the polymers in the machine. But that's a different story)
no app in it's right mind should be directly calling sun.*, for obvious reasons. If you find code in OO which does, then maybe there will be cause for complaint.
There is code in OOo which uses com.sun classes. Quite a lot of it.
Caolan McNamara is working on building OOo on GCJ. Right on his blog there you can see several examples listed, e.g:./hsqldb/makefile.mk is breaking due to sun.security.action.GetPropertyAction being missing.
Ok? Noone is saying it's all Sun's fault here. But part of it is.
Read RMS's The Java Trap. He isn't complaining about undocumented features, he was complaining about using features that haven't been implemented in a 'free' version of Java yet. In essence, he's complaining that GNU Classpath isn't developing fast enough (although he would never word it that way). Once GNU Classpath catches up to Sun (if it happens), then Open Office will work just fine with it.
TFA in question isn't Stallman's "The Java Trap". The article in question is about OOo using undocumented, Sun-VM-specific classes in Java.
Those features will never be implemented by GNU Classpath. Many of them are already not implemented by other proprietary JVMs, such as those from Apple and IBM. These classes (those under com.sun.*) simply are not part of Java. Sun themselves admit that and advise against using them.
Yes, this is exactly what Sun was criticizing MS for. MS was breaking compatibility by adding features to the standard library. If Sun programs are using parts of Java which are not officially part of the standard library, then they are doing so too.
(And BTW, GNU Classpath seems to be progressing quite well actually.)
Slashdot Mirror
But that's not flipping a spin. It's flipping two spins, which is different because the total angular momentum is the same before and after the flipping.
what about flipping the spin before measuring?
Flipping the spin is measuring in the quantum mechanical sense. Perhaps you should think 'interaction' instead of 'measurement'.
Spin is angular momentum. Angular momentum is conserved. Thus, to change the angular momentum of something means interacting with it.
I don't care about determining the spins of the particles
It doesn't matter if you care or not. It doesn't matter if you look at the results or not. It doesn't matter if it's you even have a result. What matters is that an interaction happened, where you could, in theory have received information about the spin state.
What if the unsuspecting electron is one of a correlated pair? When the flip occurs, does the sibling electron (perhaps a galaxy away) simultaneously flip
No. Flipping the spin is performing a measurement.
All I'm meaning is that in order to push performance to the limits, game developers often use or find undocumented features of the system.
In the 80's, yes. I don't believe they do so today. First off, at the speed hardware is changing it's not worth the effort to microoptimize like that.
Not to mention the fact that the thing does have an API and an OS. Those things were nonexistant before, which encouraged that kind of stuff.
Secondly, the platform isn't static. Revisions to the OS and hardware occur. Using undocumented stuff is putting yourself at great risk of having your code break.
But the more they tighten the secuirity model, the more strictly compliant the ported code will need to be.
IIRC, the only security holes found so far in the original X-box which didn't require a modchip were buffer overrun failures. Not due to using 'undocumented features' of any sort, but rather a simple programming error.
Microsoft could easily fix that by having a nonexecutable stack, for instance. That would not put any additional requirements whatsoever on the programmers.
I don't buy it. Could you give a real example of a program using an undocumented feature, and also explain how it constituted a security problem?
Interesting how, just today a columnist in Dagens Nyheter (largest newspaper in Sweden) wrote a column about blogging. He drew a parallel to other fads, the one he specifically mentioned was the early 90's Grunge trend.
These trends were first hailed as something new and different, which would change the world, only to subsequently be adopted by the mainstream/the existing powers, and eventually died off without actually changing anything.
(The anti-fashion 'grunge look' became the fashion, then went out of fashion, then things were as they were before.)
The parallel he saw, was in the increasing amount of Celebrity blogging. People who are already in the mainstream media are increasingly starting to blog themselves, and that's corrupting the original visions of blogs being a kind of "even playing field".
Now I'm not sure whether the columnist was right or wrong about this. (I can't and won't predict the future.) But I thought it was an interesting thought anyway.
The harder they lock it down, the harder they make it for partners to port to their platform.
Care to elaborate on that? Because I can't see the connection.
What makes it easy or hard for partners to port to their platform is the OS itself, and the quality of the SDK and tools provided by MS. Microsoft has long been very good at giving devs what they want.
The original Xbox required developers to get their copy signed off by MS. I see absolutely no reason why they can't add security without adding to that inconvenience.
According to Webster's napalm is not sodium palmitate, but naphthene palmitate.
So, I stand corrected.
But on the other hand, "naphthene palmitate" isn't a compound, "Naphtene" is just a group term for unsaturated polycarbons, those present in naphtha, which in turn is an older word for gasoline.
So "naphthene palmitate" probably means here "gasoline mixed with some palmitate salt", which makes sense chemically since there shouldn't be any significant difference whether you use sodium palmitate or potassium palmitate or any other palmitate salt, as long as it still retains its detergent effect.
Real napalm, by the way, is also a mixture of gasoline plus other stuff to stabilize it and slow the rate at which it burns.
Real napalm is originally a soap and gasoline.
Sodium (Na) palmitate --> Na-palm, which is a detergent still used today in some soaps.
Although I've heard about aluminum salts being used as well.
This year, we lost out right at the bottom, with only 18 points. Compare that to a Moldovan granny banging a drum, which sailed on to 6th place with 128 points.
You can't quite blame that on friendship voting though. (I.e. they got points from a lot more places than just their neighbors)
The group in question (Zdob si Zdub), is an established group in East Europe (4 albums), with several hits and are pretty well known in Russia, the Ukraine, Belarus, Romania, Hungary, etc.
Like them or not, a lot of East Europe does and that's more of a cultural thing than a friendship thing.
Friendship only goes so far too.. Norway only gave Sweden (who's song totally sucked) a single point.
>>Santa Clara Operations.
>I believe that's Santa Cruz Operations.
Is this what they mean when they say the company is going south?
Blackdown, Kaffe, GCJ, and quite a few similar "branches", all getting somewhere 60% down the way and stopping there. Somehow I don't quite believe the new project will get anywhere near "usable" as well.
Ok, first Blackdown is 100%. It's not an open source VM. It's a port of Sun's.
Kaffe and GCJ haven't stopped anywhere. Both are using the same class library (GNU Classpath).
Does this look like 'stopping'?
As an end user? No real reason why you should download one over the other. Ideally one will do as well as the other.
However, if you're using Linux (most distros don't accept Sun's licensing) you won't have to do that, since a FOSS distro wouldn't have the same terms.
If you're using an operating system which Sun's java doesn't support, you're plain out of luck. A FOSS JVM is more likely to be ported. And you can do it yourself if bad comes to worse.
Lastly, having a second implementation avoids vendor lock-in. Today there is no other implementation of Java than Sun's. (Apple, IBM, Blackdown and all that are based off Sun's code)
Why start from scratch? It this simply because the Apache folks don't like the GPL?
Actually it hasn't been decided if they will start from scratch yet. They might adopt an existing VM. They might adopt the GNU Classpath class library.
The discussions on checking up the inevitable licensing issues are already underway.
That wasn't by Cleese either, but you'll find this to be more relevant.
Snopes.
I think it's just incompetence or bad design on the part of Sun rather than a deliberate decision
Right, I don't attribute to malice what can be explained by incompetence either.
But.. I don't feel Sun has done enough to discourage this stuff. I've seen Sun example code using com.sun classes. Usually saying "You shouldn't really use this".
The sloppiness does actually extend to the public API in places, too.
Personally (and perhaps somewhat sadistically) I'd like to see Sun just rename all internal packages in com.sun.* for no other reason than to break those bad apps and have people fix them. If write-once-run-anywhere is as important as Sun makes it out to be, they should.
IBM has campaining for open source J2SE.
Right.
When Classpath is turning almost compliant, Apache tries to help it's accepance by requesting them to move the code to the Apache Licence.
Not true. Apache Harmony is an effort for an Apache VM. They haven't decided yet if that means writing their own from scratch or adopting one.
They haven't decided yet if they're going to use GNU Classpath either. Although it is very, very likely.
Apache has not requested that Classpath change its license. Firstly because they haven't decided to use it yet. Secondly because there is no percived reason to; So far noone has brought up any reason to belive the Classpath license is incompatible with the Apache one.
What has happened is that the Classpath hackers have said that if they chose to use Classpath, and if there is some minor problem with the license, then they will be prepared to tweak the license as to be compatible. But relicensing the code under the Apache license has not come up.
In any case. It's not about supporting Classpath or IBM. It's about their own self-interest. Apache has more Open Source java code than any other single entity out there. Why would they not want a Open Source JVM to run it on?
The aquarium may have less surface area than his computer, but the computer isn't the part that gets hot.. it's really just the CPU chip (and perhaps some graphics processing chips) that get hot.
That's because they have fans pushing air at them and out through the case. Air doesn't conduct heat well, and doesn't have time to warm the case significantly. If you turned the fans off, the case would start to heat up. But since the motherboard and things in between the chip and case conduct heat rather poorly, the chip would likely get too hot before the case got very warm.
In this setup, you have a much more heat-conductive medium, which is not moving around as much, and is not being exchanged with a huge reservoir around it held at ambient temperature. The chips will get too hot unless the oil can conduct heat fast enough to the aquarium walls (the only place it can go).
If the walls can't dissipitate that heat at an equal or greater rate, the oil will start to heat up, causing the walls to dissipitate more heat (warmer objects emit heat faster than colder ones (Stefan-Boltzmann law)), eventually you'll reach an equillibrium where the walls are emitting the same amount of heat which is produced and the temperature will be stable.
I don't see why I should automatically believe:
1) That the oil and walls can transport away heat from the chips fast enough to avoid them reaching an unhealthy temperature
2) That that transport will be more efficient than just cooling the hot parts by blowing air through them, and letting the rest of the machine remain at more-or-less ambient temperature.
The average temperature of the machine will almost certainly be higher. Since most of the case and things inside it are almost room-temperature during normal use. The temperature of the oil is not going to be colder than room temperature, and it is in direct contact with all the hottest parts, as well as the case.
That's correct and all. But I took that into account, I was referring to the equillibrium temperature, at which the thing isn't getting either hotter or colder.
Then differences in heat capacity don't matter.
While the aquarium may have less total area, the conduction of heat to the aquarium walls through oil is much, much more efficient than through air to the walls of an aluminum case, resulting in far better heat dissipation overall.
Yes, but the heat dissipitation in the case of air is promoted by having fans pushing outside air through the thing - the heat dissipitated by the case isn't significant.
(typically the outer part of a computer case isn't noticably warmer than the ambient temp)
With this setup, the heat can only escape via the aquarium walls, which don't have any air being pushed around to cool them. In addition to a lower total area.
I don't see why it'd be a given that the setup has far better heat dissipitation.
Now seriously, rub two brain cells together and come up with whose fault this is: Is it Sun's for providing unsupported libraries for developers to play with, or the OO.o developer who disregarded the warning that every Java codemonkey with more than a week's experience knows by heart and went ahead and used sun.* packages in a production-bound system. He shoots his own code in the ass, and it comes out to be Sun's fault. Fucking brilliant!
Yes, because the OOo coder in question works for Sun. Heard of StarOffice? Sun's version of OOo? Well these java parts come from there.
It's not the Sun Java guy's fault. It's the Sun StarOffice guy's fault.
The thing is, he might be getting rid of less heat total, but he's evening out the average heat of the board, which is a good thing. The parts of the board in an air-cooled rig that would be really hot are down at the same level as the rest of the oil, no hot spots, which is the benefit.
Well, you can certainly have hot-spots in the oil too.
The fans (if they really are working..) aren't built for pushing a viscous fluid like oil. The distance between the fins of the cooling block aren't dimensioned for oil either. The flow around the CPU cooler fins may very well be limited to diffusion and convection. (natural draught)
That might be enough. But it might not.
(I've studied fluid- and thermodynamics once upon a time and done these kinds of calculations.. but not enough to be able to say anything offhand.)
So oil conducts heat much better than air. So the heat is going to be conducted away.. where? Hmm.. the aquarium walls. Then where does it go? Into the surrounding air. At a rate determined by the amount of surface area (and the airflow).
Thing is, I wager the aquarium walls have a lower total area against the surrounding air than his computer would've had otherwise. Which would mean that he's actually getting rid of less heat, and that in the long run (e.g. when the abient temperature, oil temp and computer temp have reached equillibrium) his computer is going to be a lot warmer than it was.
Or?
(And I can imagine that oil doing quite nasty things to the polymers in the machine. But that's a different story)
no app in it's right mind should be directly calling sun.*, for obvious reasons. If you find code in OO which does, then maybe there will be cause for complaint.
./hsqldb/makefile.mk is breaking due to sun.security.action.GetPropertyAction being missing.
There is code in OOo which uses com.sun classes. Quite a lot of it.
Caolan McNamara is working on building OOo on GCJ. Right on his blog there you can see several examples listed, e.g:
Ok? Noone is saying it's all Sun's fault here. But part of it is.
Read RMS's The Java Trap. He isn't complaining about undocumented features, he was complaining about using features that haven't been implemented in a 'free' version of Java yet. In essence, he's complaining that GNU Classpath isn't developing fast enough (although he would never word it that way). Once GNU Classpath catches up to Sun (if it happens), then Open Office will work just fine with it.
TFA in question isn't Stallman's "The Java Trap". The article in question is about OOo using undocumented, Sun-VM-specific classes in Java.
Those features will never be implemented by GNU Classpath. Many of them are already not implemented by other proprietary JVMs, such as those from Apple and IBM. These classes (those under com.sun.*) simply are not part of Java. Sun themselves admit that and advise against using them.
Yes, this is exactly what Sun was criticizing MS for. MS was breaking compatibility by adding features to the standard library. If Sun programs are using parts of Java which are not officially part of the standard library, then they are doing so too.
(And BTW, GNU Classpath seems to be progressing quite well actually.)