Someone in our company ran into this several weeks ago, and I had kind of a fun time tracking down the problem. The summary and most of the comments are missing a lot of details and nuance, which actually make this problem kind of interesting.

1) It wasn't even running out of memory

Sun/Oracle's VM implementation (HotSpot) has a concept of a permanent generation, which is separate from the rest of the heap and has its own maximum size. This generation holds stuff like the code cache and interned strings. Whether or not this is a good concept is debatable, and as far as I know, they are planning to do away with it in the future as JRockit and HotSpot merge. At any rate, this is the space that was filling up. This probably didn't happen very quickly on a normal Eclipse distribution, but with a lot of plugins installed (and thus a lot of classes being loaded) it crashed pretty quickly.

2) This is only because of somewhat subtle differences between the various VMs

HotSpot is the only major JVM I know of that has a PermGen space - J9 (IBM) and JRockit (Oracle, via BEA) don't have this concept. Thus the requirement to be able to behave differently based on which VM you are using. Being able to behave properly on multiple VMs is especially important for Eclipse because not only do they have a lot of people using it on HotSpot, but because it is the basis for IBM's RAD, they have a ton of people using it on J9 as well.

3) This problem is in the launcher, not Eclipse itself

So, the crux of the problem is that Eclipse needs to start a VM, and has to know the proper flags to pass to it *before* it starts up. A few people have suggested trying reflection or other runtime methods as a better way to solve this, but this ignores a) Once the VM has started up, you can't change the heap or PermGen sizes, and b) As far as I know, there is no way to query the VM at runtime to figure out what its underlying heap structure looks like - that is an implementation detail.

So, while it does kind of suck that Eclipse was relying on a vendor name, it is trickier to solve than it appears at first glance. The only really graceful ways I can think of to solve this problem rely on some changes to the VM spec.

Yeah, Prime is pretty sweet. A few months back, I ordered a new telescope on Friday morning and it was there the next morning. The charge for overnight, Saturday delivery? $7. I'm pretty sure that paid for Prime all by itself.

That sort of advertising might seem more accurate, but it really isn't.

Since, at some point, the bandwidth is shared, do they advertise the bandwidth at the theoretical worst - ie, everyone is using it at 100%? That number would be incredibly low, and you'd never see it go that low. It would be confusing and inaccurate.

What they do advertise is what they provide to most people under most circumstances, which seems fair and accurate enough for me. They do need to do a better job of disclosing how and why you might be throttled, but doing so in a concise and accurate way that people who don't post on /. would understand seems like a pretty tall order.

I still think the number of sites that can be supported by donations is exceptionally small.

Reducing distribution costs may help a little bit, but in reality distribution costs are often a very small percentage of the overall costs of a web content provider.

For those that block ads in a wholesale fashion, I have an honest question -

If everyone blocked all ads, what would you see that as gaining for the internet as a whole?

A lot of quality websites require a lot of resources to create and distribute the content. Most of them are supported by advertising. If they could no longer make sufficient money via advertising (and many are heading to this point), how would they support themselves?

- Converting to a paid service.

This would be bad because it would cost you money, and very few sites would be able to pull it off. Micropayments are one way this could maybe work, but they are still a pipe dream.

- Begging for donations.

Again, very few sites could pull this off.

- Selling personal and/or aggregate user data.

Not a lot of sites that are useful collect much data, and this is arguably worse than advertising.

I'm not trying to make a moral argument out of this, but more of a pragmatic one. You obviously visit ad-supported sites that are useful to you, and it is probably in your interests for them to make enough money to continue providing useful functionality or content, so how do you propose they do so if not through advertising?

I used to think that a programmer's tools are sacred and you should basically let people use whatever they feel they are most productive with, but I'm starting to see problems with that, at least in big organizations..

First, IDEs - I've worked on teams where 3 different IDEs were being used by different members of the team - IntelliJ, NetBeans, and Eclipse. It worked fairly well and no real problems came about as a result of the different IDEs. I've also been in training sessions where everyone is using the same IDE except for some crackhead insisting that their IDE is better and that they can't switch to Eclipse even just for the training, and everyone in training has to wait for half an hour why the instructors try to help them figure out why stuff isn't working in their IDE.

Second, platforms/libraries/frameworks - There are really a lot of valid reasons for standardizing the platforms, libraries, and frameworks your organization uses. You have better internal support, can leverage work done by other groups, and training is easier. Being able to switch people around easily is perfectly valid as well - people leave, get promoted, need a break from their project, want to explore different career goals, etc.. Plus, I think it is good to send people off to other projects to learn and share good practices. Having a standard set of tools makes this relatively easy - all you really need to learn on a new project is the business side of things.

That said, there isn't a one-size-fits-all solution, so it probably makes the most sense to pick a standard set of tools for common project types. If a project needs to deviate from one of those standards, that is fine, but they need to make their case for doing so.

So for full-blown enterprise apps, the standard may be Java EE. For smaller apps, it might be Rails or Grails. For desktop apps, you might mandate .NET. Then if someone says "Hey, it would be cool if we wrote this small app in Python", then they could do it, but they would have to show that the benefits gained by using Python in that scenario would outweigh the costs of using a non-standard platform.