Really? Before I was annoyed now I'm bitter.

In Novell's case I think its inertia. There was a time that Novell offered a suit of solutions that worked together well and made things easier. Eventually, industry surpassed Novell.

Good IT managers are conservative. In the short term, "If it ain't broke don't fix it" is a good motto. But sometimes sticking with the old becomes a burden and its good to be proactive. Knowing when to migrate or upgrade (and when not to) is what separates the good managers from the great ones.

I'm guessing you are an engineer. The willies you get from sales is your BS detector going off. The sales people are selling product they don't completely understand. The management making the buy decision is buying a product they don't completely understand. But the sales people and the management speak the same language. The engineers usually do not. So the management trusts the sales people and the "monster" is purchased.

Maybe my employer will finally move away from Novell's terrible Web Services, GroupWise, and iPrint.

I have a dream that one day I'll be able to have my name, longer than 8 characters, supported as a username w/o being cut off.

They have had something like this at BWI for years. Even better - you don't have to look at your phone while driving. There are red and green lights marking open spots and the number of free spaces listed at the head of each row.

Similarly, the parking structure at the Grove in LA lists the number of free spaces per floor.

Great response - if I could mod you up I would.

I wasn't as clear as I could have been. The 50% could have been people waiting to report their broken phone until after a new one was released. (Was there a dip in claims in the preceding months? No way of knowing from the article).

What found problematic was the 'Four in ten of the iPhone claims received by Supercover is deemed "suspicious."'...Korina said that iPhones are very difficult to damage, making the false claims are actually easy to spot.' My iPhone was pretty dented up from normal use and the screen cracked when I dropped it from waist height (somehow missed my pocket). It sounds like they would say my phone was "suspicious" but I was pretty careful with it (drop not-withstanding).

 

I don't know how they define "suspicious." I had an original iPhone with a cracked screen. It wasn't pretty but still worked so I held on to it until the 3Gs came out. Then I got a new iPhone. I'm sure that would have looked suspicious to the insurance company but it actually would have saved them money.

If they had 18 billion ear marked to spend on their networks what else would they be spending it on besides upgrades and expansions?

I mentioned the card in a thread higher up but I forgot about the electronic version. Thanks for the reminder. I have a vague recollection (not sure about this) that there might be 2 different "zones" with two different rates.

Fear of getting caught/penalties I guess. The same thing that keeps many people from not feeding a meter when they are running into a store for 15 min.

I should have mentioned that typically you buy the cards in advance and keep them in your glove compartment. You don't normally have to find a store, buy a ticket, and then return to your car.

In a number of cities in Israel you purchase scratch-off cards in connivence-stores. When you want to park you scratch the date/time off the card (to "activate" it) and hang it in your window. I think its pretty brilliant. No physical infrastructure to maintain. To money/coins to collect. If the city wants to change the price of parking - they just change it. No machines to update.

I know this doesn't answer your question but...

Make your students get together IRL to collaborate. I transforms programming from a isolating activity to a social one. This way students are more likely to form personal bonds and continue studying computer science.

No but transactions are easier for the lay public to understand and they introduce many of the same issues. Plus, simultaneous transactions do create processes that are running simultaneously (i.e. in parallel) do they not? I agree there are many issues that come up with parallel programming that transactions won't introduce (how to best parallelize an algorithm, how to prevent deadlock etc) but transactions do describe the problem of maintaining consistent data across processes well.

This is just a simple example to show how hard it is to keep data consistent across different processes. A better example would have been to think about a shared bank account account where one person might be withdrawing money and the other might be checking the balance at the same time.