Then you would have a sports car with 5 gears. It will still be capable of exceeding the speed limit and you will have already used it for a while. How many car rental places have you seen that provide 5 speed sports cars for free?
Now, if the gear they removed was reverse, that's a completely different story. Now that I think about it more, this Other OS debacle is more like removing reverse than it is removing top gear. Carry on.
A car manufacture advertised a feature where by you could connect a cappuccino machine to the cars cooling system and make coffee while you were driving
If they plan on selling this in New Zealand, they had better prepare to pay royalties. My friend owns a patent in this (I kid you not, New Zealand Patent 538408).
Sure they could. It would just be dual licensed under GPL and whatever MS wanted. The only limitation is that any 3rd party contributors would have to agree to having their code be distributable under all the licenses to be accepted upstream. Qt is an example of this sort of thing.
The basic fact is that IE9 is leaps and bounds ahead of previous IE versions.
Is that really the case, though? The article was a little light on details with this acceleration, for all I know it could be DirectCompute based which would not work on Intel graphics and might end up being slower than IE8 on such systems.
but the IE9 preview (as inefficient as it is, as you've pointed out) was already faster at Javascript than Firefox 3.7
I wasn't aware the Javascript had improved that much in IE9. Thanks for the info.
I realise that the workload demanded of browsers will increase, and that GPU acceleration is a good solution to that. It doesn't change the fact that when you compare older IE versions to the competition, they tend to require more processing power without actually doing more. You can require more processing power by being inefficient (as Microsoft typically does with a lot of their software - an example is their appalling built in.zip functionality) or by doing more useful work. The post I was defending wasn't entirely wrong in claiming that IE could be more efficient.
I could write a Wiki article about it if you want, but would that prove anything? It's a useful site, but shouldn't be treated as a one-stop shop for fact verification.
Did you even pay attention to what you replied to? Using the GPU is looking for more processing power, and not reducing the amount of computation done. I'm not saying they can't be more efficient and take advantage of GPU acceleration at the same time, but your attempt to correct the OP was misplaced.
Sure there would. My phone supports SMS and calling, and not a heck of a lot else. One excuse would be "it can't actually make use of gigabytes of storage".
You're perfectly entitled to not care where it is allocated. There is a good reason I brought it up though - this article is about speeding up dynamic allocation, which won't affect stack based objects at all.
Sorry, I seem to have made an error of omission. I was referring to small short lived C++ objects typically being on the stack. My point was that not all OOP languages automatically throw all their objects at some form of heap, which AuMatar seemed to be claiming.
I may be using a different defintion of heap to you, I see the heap as the dynamically allocated memory from the kernel and any smart allocator just maintains a local pool of memory to reduce system calls (and the JVM was shown as an example that does this). Azarael asked how this is better than system calls (note: system calls are by definition calls to the kernel) and you seem to know the answer to that already.
If the smart allocator is at the shared library level then it has 2 main options. It can be a globally smart allocator which means all processes use the same pool, but this again has contention issues and potential security issues. The other option is to have each process have it's own instance of the allocator but the downside is that if every application links against that, the system as a whole will use a lot more memory and systems that really do need a smart allocator tend to have a custom one anyway. It's very difficult to make a general purpose allocator that is fast and space efficient and supports a wide range of different sized allocations, but since the JVM knows a lot more about the code it is running/JITing it can make better optimisations based off assumptions a general purpose allocator can't safely make. Plus, the JVM can defragment the pool more safely than native allocators.
And how does this situation differ other than the fact that the alloc/free operations are done local to the JVM instead of making system calls? The fact that the JVM is doing the work doesn't magically make memory management easier.
Yes it does. The JVM already owns the memory and nothing else can touch it, so it doesn't have to get low level locks or switch between user space and kernel space contexts.
And a lot of those small, short life objects tend to sit on the stack, not heap, so malloc doesn't come into play there. That's one of the first annoyances I encountered in C#, I can't create intentionally short lived class objects on the stack.
They believe that you should buy a game and it is yours forever, you can't lend or sell it.
While I agree with most of what you said, I strongly disagree with this particular statement. They believe that you should buy a license to a game but it still remains their property. They can't really claim to prevent you from selling your own property, but they can try to claim that you aren't allowed to reassign an agreement between yourself and them to a 3rd party.
There is a minor bug in Slashdot moderating that caps it to 5.
It's easy to make economic arguments like that. But consider where the money comes from and who it goes to. Sure, the developers could spend an extra 5% of their resources to reduce the wasted costs of clients by 60% (I took the same liberty of numbers from nether regions), but that may result in the developer making a loss instead of a profit and they then stop producing the product. The clients may be happy that they save the $22,500 per year but probably won't be giving it to the developers.
Slashdot Mirror
must not be a satellite of another planet
This point emphasizes it better.
Then you would have a sports car with 5 gears. It will still be capable of exceeding the speed limit and you will have already used it for a while. How many car rental places have you seen that provide 5 speed sports cars for free?
Now, if the gear they removed was reverse, that's a completely different story. Now that I think about it more, this Other OS debacle is more like removing reverse than it is removing top gear. Carry on.
A car manufacture advertised a feature where by you could connect a cappuccino machine to the cars cooling system and make coffee while you were driving
If they plan on selling this in New Zealand, they had better prepare to pay royalties. My friend owns a patent in this (I kid you not, New Zealand Patent 538408).
I'm sure a lot of folks would rather see their paid-for features returned than a few dollars back from a retailer.
No. Most people don't care about the feature.
There's a difference between "a lot" and "most". If it wasn't for your initial "No", I would have agreed with both of you.
Fox example, if a phone company has an exclusive phone, it's highly likely you bought it from them
The PS3 is not exclusive to EB games, it could have come from any of a number of retailers.
Sure they could. It would just be dual licensed under GPL and whatever MS wanted. The only limitation is that any 3rd party contributors would have to agree to having their code be distributable under all the licenses to be accepted upstream. Qt is an example of this sort of thing.
The basic fact is that IE9 is leaps and bounds ahead of previous IE versions.
Is that really the case, though? The article was a little light on details with this acceleration, for all I know it could be DirectCompute based which would not work on Intel graphics and might end up being slower than IE8 on such systems.
but the IE9 preview (as inefficient as it is, as you've pointed out) was already faster at Javascript than Firefox 3.7
I wasn't aware the Javascript had improved that much in IE9. Thanks for the info.
I realise that the workload demanded of browsers will increase, and that GPU acceleration is a good solution to that. It doesn't change the fact that when you compare older IE versions to the competition, they tend to require more processing power without actually doing more. You can require more processing power by being inefficient (as Microsoft typically does with a lot of their software - an example is their appalling built in .zip functionality) or by doing more useful work. The post I was defending wasn't entirely wrong in claiming that IE could be more efficient.
I could write a Wiki article about it if you want, but would that prove anything? It's a useful site, but shouldn't be treated as a one-stop shop for fact verification.
Did you even pay attention to what you replied to? Using the GPU is looking for more processing power, and not reducing the amount of computation done. I'm not saying they can't be more efficient and take advantage of GPU acceleration at the same time, but your attempt to correct the OP was misplaced.
When I saw a link to xkcd regarding 2 vs 3 dimensions, I was expecting this comic.
Sure there would. My phone supports SMS and calling, and not a heck of a lot else. One excuse would be "it can't actually make use of gigabytes of storage".
....isn't more along the lines of "Solid State Physics"?
Which is taught in Electrical Engineering. Or at least it was a couple years ago when I got my degree.
Because they aren't selling it yet.
You're perfectly entitled to not care where it is allocated. There is a good reason I brought it up though - this article is about speeding up dynamic allocation, which won't affect stack based objects at all.
Sorry, I seem to have made an error of omission. I was referring to small short lived C++ objects typically being on the stack. My point was that not all OOP languages automatically throw all their objects at some form of heap, which AuMatar seemed to be claiming.
I may be using a different defintion of heap to you, I see the heap as the dynamically allocated memory from the kernel and any smart allocator just maintains a local pool of memory to reduce system calls (and the JVM was shown as an example that does this). Azarael asked how this is better than system calls (note: system calls are by definition calls to the kernel) and you seem to know the answer to that already.
If the smart allocator is at the shared library level then it has 2 main options. It can be a globally smart allocator which means all processes use the same pool, but this again has contention issues and potential security issues. The other option is to have each process have it's own instance of the allocator but the downside is that if every application links against that, the system as a whole will use a lot more memory and systems that really do need a smart allocator tend to have a custom one anyway. It's very difficult to make a general purpose allocator that is fast and space efficient and supports a wide range of different sized allocations, but since the JVM knows a lot more about the code it is running/JITing it can make better optimisations based off assumptions a general purpose allocator can't safely make. Plus, the JVM can defragment the pool more safely than native allocators.
And how does this situation differ other than the fact that the alloc/free operations are done local to the JVM instead of making system calls? The fact that the JVM is doing the work doesn't magically make memory management easier.
Yes it does. The JVM already owns the memory and nothing else can touch it, so it doesn't have to get low level locks or switch between user space and kernel space contexts.
And a lot of those small, short life objects tend to sit on the stack, not heap, so malloc doesn't come into play there. That's one of the first annoyances I encountered in C#, I can't create intentionally short lived class objects on the stack.
"I want this thread to be run on whatever CPU that other thread runs without caring which core it is."
I assume you meant something more along these lines?
after HTML5 obsoletes flash adobe is sunk
They still have Photoshop and a bunch of other products.
If they can't get something they "really" want, they will redirect their digital lust to a different product.
No, if they really want it, they will buy it. Otherwise, they will pirate a different game.
They believe that you should buy a game and it is yours forever, you can't lend or sell it.
While I agree with most of what you said, I strongly disagree with this particular statement. They believe that you should buy a license to a game but it still remains their property. They can't really claim to prevent you from selling your own property, but they can try to claim that you aren't allowed to reassign an agreement between yourself and them to a 3rd party.
Why can't somebody fix this?
Did you submit a bug report? Perhaps they don't know about it.
Why is the parent post not modded up to infinity?
There is a minor bug in Slashdot moderating that caps it to 5.
It's easy to make economic arguments like that. But consider where the money comes from and who it goes to. Sure, the developers could spend an extra 5% of their resources to reduce the wasted costs of clients by 60% (I took the same liberty of numbers from nether regions), but that may result in the developer making a loss instead of a profit and they then stop producing the product. The clients may be happy that they save the $22,500 per year but probably won't be giving it to the developers.