Well, my N1 doesn't have an issue - either with stock Android or Cyogenmod7 - where I more heavily moved apps to the SD card than with Stock since stock wouldn't allow some apps to go to SD Card, while a lot more can with C7.

It's mostly likely due to something that the OEMs/Carriers did by allowing some critical piece of software to be moved to the SD card.

And the only "boot loop" issue I had was a memory allocation issue by the Activity Manager completely unrelated to whether or not the SD card was present.

Only b/c of legacy software.

As much as I disagree with how managers estimate time for projects, you can very well do that with software. However, you need software developers that are professionals, and not about being artistic. People that will stick to team guidelines, coding styles, design guidelines, etc, and people with experience. The more experience you have the better you'll get at estimating your own time.

And yes, I've seen that even with myself. In the early phase of a brand new project it can be harder to estimate time correctly, but as some of the technology in the project matured, other phases became a lot easier. Following design guidelines have reduced bugs to very low levels - near zero across over 400 KSLOC, most things users complain about are not bugs but product maturity (e.g. I don't have infrastructure in place to support what they want yet) - i.e. it's not bugs, but new features to add. (Bugs being defined as defects in existing code, not missing features.)

Software developers that insist that it cannot be done are simply (i) inexperienced, or (ii) do not know what they are doing and need to not be doing software.

No. It shows you know you have contracts work. You are bound to the contract you've signed. If you don't follow the contract and they have a problem, then you are on the hook for what is written in the contract. If they ask you for something that is not in the contract, then you can do it - but it won't be something they'd be able to hold you to.

In the end, your customer may complain at first; but when they get what they want they'll be happy. Make the contract renegotiation easy for them, and show them that the renegotiation is as much about them getting what they want and keeping them happy as it is ensuring that you are properly paid.

Yes, there is a line where you can say - well, the contract doesn't say that, but we'll do it any way. And that's a line you have to figure out how to walk. But you also cannot simply roll over and say "well, if the customer says it do it" - you won't be in business long if you do.

And, FYI, the Defense Industry operates on this very principle. The US Government puts out an RFP; contractors respond with their proposals; one of them wins, and then immediately renegotiates the proposal before any work is actually done. They seem to be doing very well.

And ultimately, if they don't want to do it - then they're not worth having as a customer either as it will impose undue risk on you and your own business.

And there's a difference between clarifying a point in the contract and product specification versus adding new features. As I said, there's a balance to be drawn. And businesses in every industry walk that line.

Software is no different except too many software developers enter into contracts without experience in contracting and then roll-over when their client wants a change.

They're not. But they want to be artists or academics that are. It's the Software Engineer vs. Academic Programmer issue.

Colleges focus on Academic Programmers when the business place wants Software Engineers.
One has Workmanship Standards while the other does not.

It's no different for the software industry.

When requirements change, you change the contract through a renegotiation. If they don't want to change the contract, you don't change what you provide. That's standard practice for contracting. All too often with software the developers do not renegotiate thinking it'll be easy to add, thus allowing feature creep that they are responsible for. A good contractor will be good at controlling the feature creep - this is extremely helpful by forcing contract renegotiations whenever a new feature is requested that was not in the original specification. Add in a contract renegotiation fee for each change, and they'll quickly get the picture that they can't keep changing things.

I had one colleage nearly a decade ago that worked on a project for another manager. She micromanaged things, and would tell him what to change. Our manager didn't really care, or pay much attention to it. She didn't really specify requirements, and in the end it would have been something like having an invisible elephant that you can see and has pink dots without any pink involved. He left the company. She later brought another contractor in and he told her that what she was asking was impossible and the code would have to be restarted from scratch (it was a mess due to her micromanagement). The project died.

That depends on the contract, of which there are several ways:

1. Hourly
2. By Project
3. On retainer (typically for a certain amount of time)

If he contracted them "by project", then the contractor is on the hook for fulfilling all the contract requirements regardless of time; the contractor better hope they estimated it correctly as they're on the hook until the customer signs-off on it. This is essentially a "salaried" contract; but it is not working as a salaried employee.

If he contracted them "hourly", then it is more his issue than the contractors.

However, from the description it sounds like he does "by project" contracting; but there's not really enough information to say.

FYI - it was a word adopted by the homosexual community (circa 1960's and 1970's) to try to replace the term "queer", and to convey a certain message in the process. Over time, though, it has come to be a synonym for "queer" instead.

Just goes to show that one can call something anything they like, but the name will eventually mean the same thing as what was originally given it.

True.

False.

97% of the papers may have used the same method, or various revisions thereof. There is nothing saying they all used different methodologies. All TFA says is that 97% of published papers and 97% of the surveyed researchers that work on them said AGW is man-made. It says nothing about the quality or validity of those papers, the credentials of the researchers, etc. For all we know, 97% of those researchers were ungrad-students doing research for a professor that required them to assume AGW was man-made.

No other conclusions can be drawn from it.

You do realize medicare/medicaide is more expensive than private insurance, don't you? Sure, you may not pay for it up front when visiting the doctor or paying for your drugs, but you do pay for it in taxes, along with everyone else.

TFA is not talking about majority opinion. It's talking about the majority of published papers. The two are not necessarily the same thing. Also note that TFA surveyed 1200 authors of the paper to see how their views related to what they published, so it is no surprise the authors thought the same as what they published.

From the very fact that it doesn't. It just means that 97% of papers are making the same assumption, and 3% are not.
It's either:
1. It's settled
2. There's an overwhelming majority wanting it to be settled a certain way and only publishing papers making that assumption.

#1 is only done through absolute proof that the assumption (that it is man-made) is accurate; otherwise it's #2. And there is by no means absolute proof that the assumption is accurate.

I wasn't aware that OIN was patenting anything, rather that they were just a group that you could join and donate existing patents to or draw from in order to protect yourself when sued over patents - e.g. a patent pool for self defense. Members were required to not sue each other over any patents in the pool. Or did I miss something?

The original iPhone was an iPod Touch enhanced with the 3G network and a camera. My wife was looking at getting one but we didn't want the data network. My cousin (an Apple employee at the time) suggested the iPod Touch instead, and then use WiFi+Skype for calls. Now she's looking at an iPad to get the camera (for video calls); but she's been otherwise very happy with her iPod Touch.

A ban that will never happen as long as the US or at least one other country on the Security Council think that autonomous drones with lethal capabilities are useful. (Hint: It only takes one Security Council member to veto nearly anything in the UN, especially where weapons are concerned.)

Even complete failured it trained of equipment is trained for. The military is taught not to rely on equipment to get the job done. Multiple failures are expected, and can easily happen in any combat situation.