I'm not saying your usage is erroneous. In some contexts it does make sense. This just isn't one of them. When you use language, you need to be sensitive to context, you can't just blinding plug in whatever definition suits you.

Unless you're in politics, of course...

I also tried to put myself into the shoes of an Iranian fundamentalist,but I got frustrated and decided to throw those shoes at someone.

Google vs. the goverment. What's the difference? Precious little. Trusting your privacy to Google is like mailing your private files to the FBI. American or Iranian, it's all goverment. Wake up and guard your privacy. What little you have left.

Never ask any question here that essentially asks: "Am I shit because I use Windows?". You will always get plenty of "yes"'s here.

Fortunately, being a geek has nothing to do with what Slashdotters think of you.

I'd moderate this retarded if I could, but it's not an option. Probably Palin had it removed. Anyway, allow me to explain.

Not sure if I'm being clear here, but a "standard change" is not an estimate - it's something we've done before and know exactly how long it takes. If you are doing any actual estimating, the more "estimating" you do vs. using historical data, the more range of error you'll have. I'll babble on this subject for a while, but that's the gist of this post.

There are different types of changes. If you're estimating something you've done a hundred times, you know exactly how long it will take. Something like custom configuration for a client, routine maintenance, things like that. You'll be correct on how long it takes.

If a customer wants a new web service, and you've never done a web service, you're going to be wrong no matter how much you quantify. You can determine how many objects you need to create/update, but you can't tell how long it will take.

In other words, estimating has to take into account many different things:

How many objects will be updated/added
How many of those will be trivial vs. complex changes
Level of familiarity of the person/people implementing it
Assumption that the number of objects is correct, and nothing was missed
Necessary documentation available *and correct*
Historical accuracy of estimating (are you getting better at estimating overall?)
Historical accuracy of estimating the kind of change requested (are you getting better at estimating *this*?)
Overhead of gates/reviews and change control or other process
Testing resource availability, familiarity with the new items, correct documentation supplied to whomever is testing

If MSDN or man page isn't correct, you're going to do a lot of debugging. If the client's web service you're connecting to doesn't match what you were given, you're doing rewrites once you hit testing. If your change is ready to go but a company-wide routing change is scheduled for the same date so you can't test your implementation, you're stuck. If the CSS works until someone enters a long comment, and you need to find a workaround to the layout, you're better off just saying won't fix.

Bottom line, the more foreign something is, the more incorrect you will be. If you are estimating something you've already done, there's not need to estimate - it's already done! So by definition, we are either dealing with something simple like search/replace and run, or something foreign where you're going to be wrong no matter what.

I'll close with - in a modern company, all code should be reusable. So you only do things once. So you can't learn to estimate more accurately, since you're always estimating something different. The only way to have accurate estimating is to have a solid team working together for a while, and doing similar work. Just limit yourself to things you know, and you'll be right.

A cost/benefit analysis of switching might come in handy. There are other support issues besides just security.

Since my last post, I realized that GSM and UMTS patents aren't the only patents affecting mobile phones. Multitouch gesture patents are another, and the licensing structures for these don't seem to be as reasonable and nondiscriminatory as the licensing structures for, say, GSM and UMTS patent pools.

Slashdot and Apple are based in the United States. In the United States, the three national carriers with decent coverage are Verizon, Sprint, and AT&T.[1] These carriers do not give a discount if you use a SIM-only (AT&T) or CSIM-only (VZW/Sprint) plan with your own handset instead of taking the carrier's subsidized handset. So in order to make your handset affordable to customers in the United States, you have to get your handset onto one of the United States carriers' subsidy plans. Nokia has had trouble doing this, leaving Apple and Google as the primary handset operating system publishers.

[1] T-Mobile is a national carrier that does offer a discount for bringing your own handset, but I'm leaving T-Mobile out of it because "there's a map for that" to an even greater extent than with AT&T.

You are running a software built by said commercial 3rd-party company. They don't need that server in the middle to see all of those things.

So there's no increase in capability if they are malicious. There is an increase in risk if they are incompetent - and do something like cache requests/responses containing that data.

Oh come on, he might be able to find a willing female. But not on that deadline, Comicon isn't until July.

They just might get marginalized a bit. Lots of people still prefer paper, paper books still look better on the bookshelf or coffee table, lots of people would rather read a paper book at the beach or poolside. There will always be a market for paper books - it just may shrink a bit as cost-conscious consumers sometimes choose the eBook option.

Frankly some of my friends who buy eBooks will ALSO buy the print edition of books they really like. And some will get the free sample chapter on their Kindle then go out and buy the paper version if they like it. Even better for publishers.

Except the reality is that only a very few actually make an "obscene profit". The vast majority of books, films and music wither and die with very little revenue. For every Dan Brown or J.K. Rowling there are a thousand other writers who will never make even a part-time wage for their works.

Book publishing is an expensive business and e-books level the playing field considerably. The three biggest costs in book production are (not necessarily in this order):

1. Printing
2. Marketing
3. Distribution

A publisher needs to have confidence that a book will sell X copies at Y price in order to know that they will at least break even on publishing it. And I guarantee you that every publisher has a warehouse full of books they guessed wrong on and nobody bought. But those costs are sunk. They pay get pennies on the dollar at the paper recycler but otherwise they've blown a lot of cash printing books they never sold.

As on-demand, and now e-book, publishing has become more and more viable the break-even point has come WAY down and books that would never have seen the light of day are getting their chance.

And publishers should LOVE eBooks - it takes printing and distribution largely out of the equation and means far greater profits off a much lower price. I wouldn't mind if my publisher did Kindle versions of my books, that's just one more medium and a much higher net profit from the books.

Competition is a good thing, no doubt about it. I'm a solid Firefox user but I'm happy to see Chrome or even Opera (or even IE for that matter) make significant advances in browser technology because I want to see that push Mozilla to further improve Firefox too.

I think having browser diversity helps to keep web designers honest as well - hopefully gone (or at least numbered) are the days when sites would only work with one particular browser. I'm pleased to see that I rarely have to use IE Tab anymore in Firefox as a lot of sites that used to be IE-only are now starting to work in Firefox as well.

It would probably be pretty easy to fake that though. Create some bogus plans to produce the thing you're patenting but never actually go through with it. It would be too costly to follow-up on every patent to make sure people actually did what they said they would.

Plus there are folks who get patents who don't intend to actually produce the thing themselves, rather they want to license it to others. Sort of an "R&D Department for Hire" concept. Unfortunately it's a fine line between those who intend to license their patents and those who intend to lay in the weeds and wait for somebody to infringe their patent and then sue.

It's those kinds of parasites we need to figure out way to deal with.

Seems to me a hosted email service essentially IS a backdoor. I can already get into the e-mail accounts of any server I'm the admin of - hence the power of Admin. Heck, not only do they own the admin accounts, they own the physical servers.

You haven't handed them the keys, they made (and own) the locks!