"Unlimited" means "as much as any device we support can use" rather than "any device anywhere that could exist could potentially use."

When you sell "Unlimited" to 500 uses who can potentially use 50GB daily, then you are stating that you have the hardware to support 500 users using 50GB daily. There is no abuse here; there is no misrepresentation here. When you sell it to 5000 users and advertise "Unlimited" then you are lying.

I really don't mind that I am sold tiered bandwidth allocations. I like knowing what I'm paying for and so long as they meter it fairly, I make the decision to buy and use or not buy the service. I do mind that they call it 4G ( 4G is a lie.)

Really annoying is thinking (but not having done sufficient research to know with certainty) that when I purchase 5GB/monthly service, what I'm really getting is sometimes maybe throttled without telling me and often insufficient for demand service. If I buy "5 free donuts daily" and I get "5 free donuts daily when maybe not everybody we sold them to is actually picking up their donuts and sorry, today you get 1 donut because it looks like a good dounut day" then yeah, they've sold me something they are incapable of guaranteeing delivery of. Fine. I can deal with that. You sell something thinking you can deliver it and you can't, then you failed; your bad, you broke the contract. GIVE ME MY MONEY BACK.

You sell me 5 donuts, I expect 5 donuts. You can only deliver 3? I don't care about your other customers, that is between them and you, but I have every right to depend on 5 donuts and you failed. You failed. GIVE ME MY MONEY BACK. Okay, so you acknowledge that you can't give 5 donuts a day to eveybody you sold 5 donuts daily to? Fine, you broke your contract, offer only what you really can deliver. Sell me 1 donut a day guaranteed and if you give me 5, then I'm your biggest fan.

You sell me A, you owe me A. It is that simple and I have every right to truly expect A.

The FTC needs to say "the new rule starting June 1, 2008 is: you sell only what you can really supply. You can say 'up to 5GB' but you must also say 'actual guaranteed rate of 'X' where X is what you can actually deliver if every customer you have is using everything you sold them."

The actual implication intended is that the countries in the Middle East are, as a group, not sane. I don't think that having nuclear weapons has made Israel's borders safe.

Spitballing here, so I freely acknowledge there are probably many issues I haven't thought through...

How about we sell lots of safe nuclear generators to Iran? I am interested in nuclear power because it has a tremendous potential for meeting energy demands, but I also acknowledge that creating safe nuclear plants that aren't a precursor to nuclear weapons requires a high level of technical expertise. The US and China and other highly developed countries have the expertise but face a lot of public opinion inertia. Maybe we should try to produce the generators in a box (google Hyperion) and sell them to Iran with built in safety precautions. Alternatively, set up a treaty to develop thorium reactors there, which I believe are hard or impossible to weaponize.

Either way, we could help them meet their energy goals while protecting the global interest of preventing them from developing weapons. As a side effect, we would get to use the pro-nuclear government there as a safety proving ground for new technologies. They want to take the risks and we need to show that the new technologies are safe and feasible, so we have coinciding interest, which can make a strong bond for peaceful trade.

Common misconception. When selling a product that you are going to expect to replace to stay in business, you charge the price to replace the product, else you end up losing sales to your competitors and holding the more expensive stock, and selling out when the price has gone up while your competitors continue making profits selling at market price. That's why it's called market price maybe? The trick is keeping your customers happy at the price you charge.

Gas prices that change every few minutes or food prices that change every few minutes are also perhaps both possible and optimal by the same theory. It may be that we'll see those, but people like being able to predict without effort what the cost of a ticket will be. Likely my local favourite theatre could make more money on a few tickets, but mostly I suspect people who are considering the value of the individual ticket would often pass on the same price they purchase now.

If you go to the grocery store and see milk priced at $8.95/gal when you saw it the day before at $1.98/gal, then you'll remember that higher price vividly. If it happens often enough for something you planned on purchasing, then you're likely to start shopping for milk somewhere else, even if the average is a little higher, because the security of being able to make the planned purchase is worth the higher stable price.

I have a couple choices of theatres to choose from, and if they were pricing some tickets at $18.50 and others at $9.48, then I'd be more likely to look at alternatives, considering the potential value of the movie rather than basing my purchase on my preference of theatre.

Movie tickets aren't really where the profit is anyway, profit comes from people like me who purchase the experience including overpriced (but surprisingly tasty) food and drink. I really enjoy the dining+bar+movie experience much more than the movie alone, else I'd be waiting until the movie was in the local $1 theatre.

Please, please, please tell me that there is a programming language named Judaism!

I second the AC, you can use pretty much anything as long as you're good at it, but not ASP.NET. Every implementation I've seen has fared poorly when compared to similar projects done on other platforms. I can't really say why, after all it *seems* like it should do well and developers seem happy at first, but after a couple years, every one seems to falter and either start suffering performance wise (bloat? rot?) or climbing maintenance costs. It shouldn't be that way of course, but that seems to be the common trend.

PHP is fine if you enjoy working with it and can keep it up to date, particularly if you have a framework you like to use it with... to a point. If you expect the code to be maintained by a team of people in the future, and need the best possible performance you can squeeze out of it, then you might want to look at something else. It is nearly always easier and cheaper to buy more hardware than it is to rebuild code, but sometimes foresight before the project can give you better bang for the buck down the road.

From a developer standpoint, I've had really good luck with my own PHP. Years after it was written, I've been able to go back in and do maintenance with little effort. Mostly that's because my programming tendencies tend to be pretty static (stagnant?) and I do comment. Facebook is running on PHP and Wikipedia is running on PHP, so there is no question that it *can* handle the big jobs, just a lot of questions as to whether it is best suited or not.

The same can be said for Perl. If you can handle maintaining it well, and you're good at it, you can work with Perl for years and years and get good performance from it. It runs /. after all, so it can handle a pretty serious load and scale if it really needs to. It has much the same issues as PHP, it *can* but is it *best* is the question.

By far the best web experiences I've had from the consumer side were compiled code. C, C++, C#, Go, Visual Basic, or whatever floats your boat as long as you're good at it and can manage the support for it. Yet, the difference in performance isn't all that great, so I still do recommend Java or Python. I don't particularly love using either one, but both perform well and seem to be enterprise capable, in fact, I really recommend looking at AppEngine if you can stomach it because it will give you a good testing platform and huge scalability later if you need it.