A 12x DVD drive spins the disc at 7000rpm. You can't defeat physics; the disc will fight any attempt to rotate while spinning at that speed (recall the high school physics experiement where you try to rotate a spinning bicycle tire). Hardware isn't psychic; by the time it will have detected movement the damage is done.
You're correct, the 360 is built to STAND in either orientation. The unit isn't designed to MOVE while playing a game. It isn't build to withstand some dumbass showing his friends how cool it is that the green light changes its location when he rotates the unit around.
The manual tells you not to it. Common sense tells you not to it. Physics tells you not to it. Don't do it, and you won't fuck up your game disc. Crying about how much of a dumbass you are isn't going to help.
The PS2 doesn't spin the disc very fast. If you change orientation fast enough while the disc is spinning you will scratch the disc in the drive. People have done it, and they have complained about it just like these dumbasses.
The dumbasses changed the orientation of the machine while it was running. The same thing will happen with any 12x dvd drive if you rotate it 90 degrees while the disc is spinnning.
Fine, so quit complaining and I've told you why I think GC of other resources hasn't been done yet, namely that nobody has found a need for implementing it
Oh brilliant arguement. Don't complain that something sucks, so noboody else will realize that it sucks and sees that maybe there is a need for doing it.
Other people do have a need for it; C# wouldn't have things like the "HandleCollector" class wouldn't exist if nobody had a need for it.
I sketched an algorithm is my previous post, and that algorithm works. It's also very simple.
You then listed a set of reasons about why that alorithm is problematic and probably shouldn't be used.
I don't agree. Keeping track of any resource (with the exception of remote resources) isn't harder than keeping track of memory, and that's a solved problem.
Then why do we have garbage collection of memory in the first place? If it's "easy" to do, and by virtue of being easy 'improvements' are not worthwhile, then why is garbage collection of memory worthwhile?
You keep suggesting other ways of doing what I want. I've been there, done that, and don't like it. You keep suggesting workarounds that involve just endless amounts of pointless redundant code.
Your latest suggestion (force a garbage collection) requires the following for every operation which could potentially consume a handle (which includes any creation of an object I don't "own"/control the code to):
TheirObject foo = null; try {
foo = new TheirObject(); } finally {
if (foo == null)
{// todo: code to force garbage collection// todo: code to wait for garbage collection to finish
foo = new TheirObject();
} }
That has to be done every time I allocate an object, because I don't know what resources that object consumes in the ctor. I have to do it every time I make a function call, because I don't know what resources that function consumes. And so on.
That sucks.
I have never once said that doing what I want can't be accomplished with traditional means. I have consistently been saying that traditional means are a giant pain in the ass, and that when you're using those traditional means many of the benefits of using garbage collection are negated.
What I have been trying to convince you of is that you should not rely on the collector that deals with one resource to also do collection for another resource
You're saying that garbage collection should only deal with memory. I'm saying that garbage collection currently only deals with memory, and that it would be better if it dealt with whatever else can be 'collected' as well.
You've failed to convince me that garbage collection should be restricted to memory resources only; memory and non-memory resources are intrinsicly linked. I see no reason for garbage collection to be limited to memory management.
you stated that there are some situations in which it's problematic when resources held by some object are only released when the object is collected, but you want the resources to be reusable earlier. You suggested that this is a deficiency of garbage collectors.
The fact that garbage collectors today only deal with one type of resource IS a limitation of existing garbage collectors. Does this mean that garbage collection sucks? No. Does this mean that existing garbage collectors could be improved? Yes. Does this result in resource starvation that can be hard to track down? Yes.
What I have been trying to convince you of is that you should not rely on the collector that deals with one resource to also do collection for another resource. The reason is that these resources will probably have to be collected at different rates, and combining collection for multiple resources will either degrade performance by collecting a resource too often, or lead to avoidable failures by collecting a resource insufficiently often.
You're telling me why it is hard, and why it hasn't been done yet. I fully acknolwedge that it isn't an easy problem to solve, and that is why it hasn't been done yet.
I don't accept "because doing what you want is hard" as a valid justification for why I should be happy with something that doesn't do what I want.
However, and this is a separate issue, I have difficulty imagining situations where releasing resources other than memory is a difficult problem, or requires any work at all.
I feel like I'm talking to a wall here. It isn't hard to manually release them. I never claimed that it was.
What is hard is keeping track of them. Why do we like garbage collection in the first place? Because it means we don't have to track allocation/deallocation of objects. Yet, if that object holds onto something that is more limited than memory, we have to make sure that "something" gets released before we run out of them. This greatly reduces the usefulness of existing garbage collectors, because you still have to manually manage that non-memory resource linked to the memory resource.
In short, like manually managing memory, it is a pain in the ass.
If I've got a limit to the number of window/file/foo handles (or any other resource that the operating system provides a finite number of) I can use in a program, why should I have to go throught he laborious process of manually releasing each handle when I'm done with it? Why can't the underlying runtime know that there is a limit to the number of handles and start collecting orphaned objects holding those handles when we get close to running out?
I can't give you a simple example that demonstrates "the problem" because this sort of problem generally surfaces only in larger applications that run for long periods of time. You aren't going to see it in a contrived for-loop.
I have yet to see an arguement made against this other than "so what, you can do it without garbage collection" and "its hard." I know that. I don't care. Those reasons suck. It would be like me telling you "why bother with garbage collection, you can do that with a call to delete".
You sort of seem to get this towards the end of the post, but your reaction is more like "meh, I don't see the point". I don't know how to illustrate the point any better than I have.
The problem arrises when that close() needs to happen before the garbage collector does its thing. Ie: the server runs out of available connections and connection attempts begin to fail.
You aren't saving yourself any effort in this case. You've just changed the syntax.
Garbage collection of memory is a cool idea. I like it. It saves me time and effort for cases where objects don't reference anything but other objects.
But it could be better if it understood the relationship between memory and what is being held in that memory.
If you write an object which consumes one of these finite resources (which is 100% of the time in nearly every garbage collected language), that resource isn't "released" until the object is destroyed, which happens at a non-deterministic point in time.
As I said, the disposal pattern covers this case. I just think it is crappy workaround for the core issue: garbage collection needs to be concerned about more than just managing memory.
This is an issue for any acquired resource where "lazy" release/freeing is problematic.
Ex: perhaps only 16 handles to a certain resource are available at any given point in time, or perhaps it is acquiring an exclusive handle to a hardware device, or cases where a limited number of connections can be established with a database server, open files, etc.
The 'expected' behavior is for those resources to be freed after the object leaves scope, but you and I both know that with most garbage collection algorithms this is not the case.
These sorts of things are always worked around by implementing some sort of "disposal" pattern on the object, which is a fine way to work around the problem. But at that point you've back to square 1 -- you've got to make sure you call dispose before the object is orphaned.
As you say, these cases can be dealt with. But as I say, it essentially negates the benefits of garbage collection in the first place.
It isn't an easy problem to solve mind you, so I can't say I'm surprised it hasn't been.:) I think there was actually some interesting stuff added to.Net 2.0 which allows you to give the runtime "hints" about other types of resources, their limits, and when to start attempting to reclaim some of those resources. A step in the right direction at least.:)
Unless the language specifies that you can't have circular references between objects, I would consider that broken: the application can get into a state where orphaned objects are not garbage collected.
Reference counted garbage collection models are inherantly flawed. Leaks are harder to find and easier to provoke. You might as well not have them if you've got to "delete" the references to the other objects.
Modern garbage collection algorithms do not have this sort of problem.
What bothers me about garbage collection is that it only solves part of the problem: memory is not the only resource your application holds onto, and the kludges you have to make to deal with them in garbage collected languages are just annoying (hey, you don't have to worry about cleaning up after an allocation... unless your object has a handle in it; have fun memorizing which objects you have to twiddle with to "release" the resource). If memory didn't have a different release pattern than other resources it wouldn't be a big deal, but...
Over their lifetimes, this is true. However, it took Sony over three years to transition to profitability for the PS1, and roughly 1 year for the PS2. (this doesn't mean that they were or were not selling hardware for a loss, but it does mean that the balance sheet for the division shows a positive or negative number).
Another thing that I find amusing... nobody knows how much money that the xbox has lost for Microsoft. Everyone keeps quoting figures from the division that the xbox is in, assuming that the only thing that division does is the xbox (which is not true). They definately haven't made any money off of it though.
They're profitable NOW. The PS1 lost money for 3 years before Sony started putting it on their financial statements. And even then they were still losing about $20m a quarter. But you go right ahead and keep crying in your corner about how life isn't fair.
What, you don't think that Sony used revenue from their electronics, music, and movie empires to fund the introduction of the PS2?
Is Microsoft only allowed to sell Operating Systems and Office Suites? For every $1 they spend they have to immediately make it back two times over? They're "investing" in a new market. It doesn't matter where the money comes from -- it is their money to spend. If they lose it all or make it back, it doesn't matter. It is their money, not yours.
Other companies are free to spend their money on whatever they want. Or they can get VC to give them money to spend.
You forgot: a) they're using laptop harddrives, which are more expensive b) to account for the cost of electronics in the external unit c) to account for the cost of the casing of the external unit d) manufacturing costs
You also have to prove that the act is predatory (very hard to do) and that the act is abnormal.
Given that selling the console at a loss is common in the industry, and that Microsoft sells the units for roughly the same price in each market, a dumping case can't be made.
Are you daft? Their customers "sponsored" the "study". You're reading market research. Merrill Lynch is an investment firm trying to figure out which company will produce a better return. If they give bad advice, their customers go elsewhere.
This is all very true, and I don't disagree with anything you've said and I don't think that it contradicts anything I've tried to say (though your verbage is definately more precise than mine).
Your last two paragraphs identify exactly what I'm trying to express, which is essentially "how can an existing project incorporate this?"
This effect isn't Microsoft's fault. They can't do anything to prevent that effect, and I don't see how a resonable person could say "ah ha! they're being evil and intentionally trying to exclude GPL'd code from using this". It is just a result of how the GPL works.
We Brits and Europeans feel that some things are more important than making money
The contrast is that money tends to be a much better motivator than feeling like you've done the right thing. Greed has a much more powerful influence on a person's psyche than most are willing to admit. Patents prey on greed, with the theory being that in the long run society as a whole benefits.
I personally don't have a problem with what patents try to achieve. I do have issues with how they are currently granted and I don't think they achieve that goal in the software realm. But our like or dislike of patents isn't really relivent -- they exist, and they must be dealt with in some form.
And so we now arrive back full circle where we started, where the GPL effectively prevents existing projects from sucking in patented technology.
Almost, but not quite. If you have a licence to implement the patented method in the USA, you can write software, based on GPL software, which implements the method -- BUT you can't distribute it under the GPL in the USA {you may be allowed to distribute it by special permission or under fair use exemption}.
This is an important detail; I hadn't considered the "countries where nobody cares about patents" case.
It isn't clear from the GPL whether or not you could distribute software under the GPL in some countries, but not in others; my gut feeling is yes, because the "additional restriction" is added by the law of the land and not on the whim of an individual. Some countries forbid strong encryption, but that didn't keep GnuPG from being released under the GPL.
Hmmm... if that were true, I would have to wonder why anyone cares about this situation at all then.
Funny, I was just thinking the same thing about you...... whatever you want to label yourself. People like yourself plug your fingers in your ears and yell "lalalala" whenever something challenges your preconceived notion of what is and what isn't.
I may not always be correct in my assertions, but at least I attempt to discuss the concepts at hand and change my opinion when presented with new information or convincing arguements.
Slashdot Mirror
A 12x DVD drive spins the disc at 7000rpm. You can't defeat physics; the disc will fight any attempt to rotate while spinning at that speed (recall the high school physics experiement where you try to rotate a spinning bicycle tire). Hardware isn't psychic; by the time it will have detected movement the damage is done.
You're correct, the 360 is built to STAND in either orientation. The unit isn't designed to MOVE while playing a game. It isn't build to withstand some dumbass showing his friends how cool it is that the green light changes its location when he rotates the unit around.
The manual tells you not to it. Common sense tells you not to it. Physics tells you not to it. Don't do it, and you won't fuck up your game disc. Crying about how much of a dumbass you are isn't going to help.
The PS2 doesn't spin the disc very fast. If you change orientation fast enough while the disc is spinning you will scratch the disc in the drive. People have done it, and they have complained about it just like these dumbasses.
The dumbasses changed the orientation of the machine while it was running. The same thing will happen with any 12x dvd drive if you rotate it 90 degrees while the disc is spinnning.
All I know is that the gamestop in my local mall didn't have any in stock each time I checked over the course of 6 months. Your mileage may vary.
Those posters were lying idiots.
I couldn't find a friggin ps2 for at least 6 months after the machine was made available in the US.
Fine, so quit complaining and I've told you why I think GC of other resources hasn't been done yet, namely that nobody has found a need for implementing it
// todo: code to force garbage collection // todo: code to wait for garbage collection to finish
Oh brilliant arguement. Don't complain that something sucks, so noboody else will realize that it sucks and sees that maybe there is a need for doing it.
Other people do have a need for it; C# wouldn't have things like the "HandleCollector" class wouldn't exist if nobody had a need for it.
I sketched an algorithm is my previous post, and that algorithm works. It's also very simple.
You then listed a set of reasons about why that alorithm is problematic and probably shouldn't be used.
I don't agree. Keeping track of any resource (with the exception of remote resources) isn't harder than keeping track of memory, and that's a solved problem.
Then why do we have garbage collection of memory in the first place? If it's "easy" to do, and by virtue of being easy 'improvements' are not worthwhile, then why is garbage collection of memory worthwhile?
You keep suggesting other ways of doing what I want. I've been there, done that, and don't like it. You keep suggesting workarounds that involve just endless amounts of pointless redundant code.
Your latest suggestion (force a garbage collection) requires the following for every operation which could potentially consume a handle (which includes any creation of an object I don't "own"/control the code to):
TheirObject foo = null;
try {
foo = new TheirObject();
}
finally
{
if (foo == null)
{
foo = new TheirObject();
}
}
That has to be done every time I allocate an object, because I don't know what resources that object consumes in the ctor. I have to do it every time I make a function call, because I don't know what resources that function consumes. And so on.
That sucks.
I have never once said that doing what I want can't be accomplished with traditional means. I have consistently been saying that traditional means are a giant pain in the ass, and that when you're using those traditional means many of the benefits of using garbage collection are negated.
What I have been trying to convince you of is that you should not rely on the collector that deals with one resource to also do collection for another resource
You're saying that garbage collection should only deal with memory. I'm saying that garbage collection currently only deals with memory, and that it would be better if it dealt with whatever else can be 'collected' as well.
You've failed to convince me that garbage collection should be restricted to memory resources only; memory and non-memory resources are intrinsicly linked. I see no reason for garbage collection to be limited to memory management.
you stated that there are some situations in which it's problematic when resources held by some object are only released when the object is collected, but you want the resources to be reusable earlier. You suggested that this is a deficiency of garbage collectors.
The fact that garbage collectors today only deal with one type of resource IS a limitation of existing garbage collectors. Does this mean that garbage collection sucks? No. Does this mean that existing garbage collectors could be improved? Yes. Does this result in resource starvation that can be hard to track down? Yes.
What I have been trying to convince you of is that you should not rely on the collector that deals with one resource to also do collection for another resource. The reason is that these resources will probably have to be collected at different rates, and combining collection for multiple resources will either degrade performance by collecting a resource too often, or lead to avoidable failures by collecting a resource insufficiently often.
You're telling me why it is hard, and why it hasn't been done yet. I fully acknolwedge that it isn't an easy problem to solve, and that is why it hasn't been done yet.
I don't accept "because doing what you want is hard" as a valid justification for why I should be happy with something that doesn't do what I want.
However, and this is a separate issue, I have difficulty imagining situations where releasing resources other than memory is a difficult problem, or requires any work at all.
I feel like I'm talking to a wall here. It isn't hard to manually release them. I never claimed that it was.
What is hard is keeping track of them. Why do we like garbage collection in the first place? Because it means we don't have to track allocation/deallocation of objects. Yet, if that object holds onto something that is more limited than memory, we have to make sure that "something" gets released before we run out of them. This greatly reduces the usefulness of existing garbage collectors, because you still have to manually manage that non-memory resource linked to the memory resource.
In short, like manually managing memory, it is a pain in the ass.
If I've got a limit to the number of window/file/foo handles (or any other resource that the operating system provides a finite number of) I can use in a program, why should I have to go throught he laborious process of manually releasing each handle when I'm done with it? Why can't the underlying runtime know that there is a limit to the number of handles and start collecting orphaned objects holding those handles when we get close to running out?
I can't give you a simple example that demonstrates "the problem" because this sort of problem generally surfaces only in larger applications that run for long periods of time. You aren't going to see it in a contrived for-loop.
I have yet to see an arguement made against this other than "so what, you can do it without garbage collection" and "its hard." I know that. I don't care. Those reasons suck. It would be like me telling you "why bother with garbage collection, you can do that with a call to delete".
You sort of seem to get this towards the end of the post, but your reaction is more like "meh, I don't see the point". I don't know how to illustrate the point any better than I have.
Correct.
The problem arrises when that close() needs to happen before the garbage collector does its thing. Ie: the server runs out of available connections and connection attempts begin to fail.
You're still missing my point:
Why is:
MyObject foo = new MyObject();
foo.Dispose();
Better than
MyObject foo = new MyOjbect();
delete foo;
You aren't saving yourself any effort in this case. You've just changed the syntax.
Garbage collection of memory is a cool idea. I like it. It saves me time and effort for cases where objects don't reference anything but other objects.
But it could be better if it understood the relationship between memory and what is being held in that memory.
If you write an object which consumes one of these finite resources (which is 100% of the time in nearly every garbage collected language), that resource isn't "released" until the object is destroyed, which happens at a non-deterministic point in time.
As I said, the disposal pattern covers this case. I just think it is crappy workaround for the core issue: garbage collection needs to be concerned about more than just managing memory.
This is an issue for any acquired resource where "lazy" release/freeing is problematic.
:) I think there was actually some interesting stuff added to .Net 2.0 which allows you to give the runtime "hints" about other types of resources, their limits, and when to start attempting to reclaim some of those resources. A step in the right direction at least. :)
Ex: perhaps only 16 handles to a certain resource are available at any given point in time, or perhaps it is acquiring an exclusive handle to a hardware device, or cases where a limited number of connections can be established with a database server, open files, etc.
The 'expected' behavior is for those resources to be freed after the object leaves scope, but you and I both know that with most garbage collection algorithms this is not the case.
These sorts of things are always worked around by implementing some sort of "disposal" pattern on the object, which is a fine way to work around the problem. But at that point you've back to square 1 -- you've got to make sure you call dispose before the object is orphaned.
As you say, these cases can be dealt with. But as I say, it essentially negates the benefits of garbage collection in the first place.
It isn't an easy problem to solve mind you, so I can't say I'm surprised it hasn't been.
Unless the language specifies that you can't have circular references between objects, I would consider that broken: the application can get into a state where orphaned objects are not garbage collected.
... unless your object has a handle in it; have fun memorizing which objects you have to twiddle with to "release" the resource). If memory didn't have a different release pattern than other resources it wouldn't be a big deal, but ...
Reference counted garbage collection models are inherantly flawed. Leaks are harder to find and easier to provoke. You might as well not have them if you've got to "delete" the references to the other objects.
Modern garbage collection algorithms do not have this sort of problem.
What bothers me about garbage collection is that it only solves part of the problem: memory is not the only resource your application holds onto, and the kludges you have to make to deal with them in garbage collected languages are just annoying (hey, you don't have to worry about cleaning up after an allocation
Over their lifetimes, this is true. However, it took Sony over three years to transition to profitability for the PS1, and roughly 1 year for the PS2. (this doesn't mean that they were or were not selling hardware for a loss, but it does mean that the balance sheet for the division shows a positive or negative number).
... nobody knows how much money that the xbox has lost for Microsoft. Everyone keeps quoting figures from the division that the xbox is in, assuming that the only thing that division does is the xbox (which is not true). They definately haven't made any money off of it though.
Another thing that I find amusing
Ah yes, I have many fond memories of attempting to blow dust out of connectors ... I miss the simpler times of the NES.
This thread just jumped the shark. You're comparing rape to a company selling a product. You need help.
Sure they did. Probably the same way Slashdot gets paid for posting a link to it.
They're profitable NOW. The PS1 lost money for 3 years before Sony started putting it on their financial statements. And even then they were still losing about $20m a quarter. But you go right ahead and keep crying in your corner about how life isn't fair.
What, you don't think that Sony used revenue from their electronics, music, and movie empires to fund the introduction of the PS2?
Is Microsoft only allowed to sell Operating Systems and Office Suites? For every $1 they spend they have to immediately make it back two times over? They're "investing" in a new market. It doesn't matter where the money comes from -- it is their money to spend. If they lose it all or make it back, it doesn't matter. It is their money, not yours.
Other companies are free to spend their money on whatever they want. Or they can get VC to give them money to spend.
You forgot:
a) they're using laptop harddrives, which are more expensive
b) to account for the cost of electronics in the external unit
c) to account for the cost of the casing of the external unit
d) manufacturing costs
You also have to prove that the act is predatory (very hard to do) and that the act is abnormal.
Given that selling the console at a loss is common in the industry, and that Microsoft sells the units for roughly the same price in each market, a dumping case can't be made.
Are you daft? Their customers "sponsored" the "study". You're reading market research. Merrill Lynch is an investment firm trying to figure out which company will produce a better return. If they give bad advice, their customers go elsewhere.
This is all very true, and I don't disagree with anything you've said and I don't think that it contradicts anything I've tried to say (though your verbage is definately more precise than mine).
Your last two paragraphs identify exactly what I'm trying to express, which is essentially "how can an existing project incorporate this?"
This effect isn't Microsoft's fault. They can't do anything to prevent that effect, and I don't see how a resonable person could say "ah ha! they're being evil and intentionally trying to exclude GPL'd code from using this". It is just a result of how the GPL works.
We Brits and Europeans feel that some things are more important than making money
The contrast is that money tends to be a much better motivator than feeling like you've done the right thing. Greed has a much more powerful influence on a person's psyche than most are willing to admit. Patents prey on greed, with the theory being that in the long run society as a whole benefits.
I personally don't have a problem with what patents try to achieve. I do have issues with how they are currently granted and I don't think they achieve that goal in the software realm. But our like or dislike of patents isn't really relivent -- they exist, and they must be dealt with in some form.
And so we now arrive back full circle where we started, where the GPL effectively prevents existing projects from sucking in patented technology.
Almost, but not quite. If you have a licence to implement the patented method in the USA, you can write software, based on GPL software, which implements the method -- BUT you can't distribute it under the GPL in the USA {you may be allowed to distribute it by special permission or under fair use exemption}.
... if that were true, I would have to wonder why anyone cares about this situation at all then.
This is an important detail; I hadn't considered the "countries where nobody cares about patents" case.
It isn't clear from the GPL whether or not you could distribute software under the GPL in some countries, but not in others; my gut feeling is yes, because the "additional restriction" is added by the law of the land and not on the whim of an individual. Some countries forbid strong encryption, but that didn't keep GnuPG from being released under the GPL.
Hmmm
If they sold out on launch day at every store they released in, they've sold about 500k-750k units. I wouldn't exactly call that tiny.
Funny, I was just thinking the same thing about you ... ... whatever you want to label yourself. People like yourself plug your fingers in your ears and yell "lalalala" whenever something challenges your preconceived notion of what is and what isn't.
I may not always be correct in my assertions, but at least I attempt to discuss the concepts at hand and change my opinion when presented with new information or convincing arguements.