We need to consider a few things:

  - What sort of drones are we talking about? For example those huge military drones that probably use as much fuel as a helicopter?
  - What is the relative cost compared to the previous method?
  - What are the cost break downs?

It is a huge amount of money and seems like they need to change there costing model.

While I dislike writing unit tests, I have to admit they are useful in protecting your butt when something breaks, since the test should catch it first. Of course you need to decide whether in a particular scenario they add value or just make you manager happy.

In a case like yours, you can make code modifications and hope nothing breaks or build unit tests and ensure that you don't break any of them when refactoring. Initially rather than just ripping out the seemingly duplicate methods, rip out/tweak their implementation and have them point to what they seems like a the right method to provide the common functionality. If your unit tests show breakage, then you know that you missed something.

If you do things wholesale, then you are likely to break something in an unmanageable way. Oh and make sure things are version controlled ;)

Thanks for the info. I went with the premise that they were the only Android phones guaranteed to get software updates. Now I am just confused as how to know a good Android phone that will be in the front running for getting system updates, without having to jailbreak.

Just don't mention the master piece of conservativeness that was Windows CE (aka Windows Mobile). Microsoft had ample opportunity to make an operating system designed for hand helds. Instead they decided that they would cram a desktop experience into a PDA and do little to improve the experience. After all businesses just want functionality? - At least that was the attitude back then, in certain ways still the case.

Another company that had ample opportunity was Palm, but also failed. Between business people and techies, then we no notion of design and making things attractive or easy.

This is where the Playstore needs to be clearer on minimum specs for an app and indicate which applications can't be installed on the device. Google doesn't help Android in pretending all phones are made equal.

There is a reason when I go Android, I go Nexus.

He didn't invent the smartphone and many of Apple's product aren't first of the kind. On the other hand Apple has innovated and transformed languishing ideas, only appealing to techies, into something that evetyone want and desires.

Success is based not just on a feature set, but also on making that technology feel easy, attractive and not feeling like something some that requires the mindset of some mad genius.

Read back through Slashdot and see how many times Apple was accused by the /. crowd that Apple didn't understand the market they were diving into, before being proved that us geeks don't always understand the larger market.

Are there Google Chrome or Firefox add-ons that can deal with this issue, or is it injected into the request header on Verizon's side?

Javascript and SVG. How good the authoring applications are for them, on the other hand, I am not sure. Flash, may still have the better authoring tools?

I'll bite. While xhtml can be ignored rather safely, IPv6 not so much. IPv6 adoption is like the Y2K problem, but with no clear cut off date. We know we will run out of IPv4 addresses, but when depends on who you speak to or what your analysis is based on. As someone who takes care of infrastructure, I would rather start addressing IPv4 exhaustion problem with something other than double or tripple NATting, and provide a solution that is already working when others are screaming for lack of foresight.

To the people suggesting we could have taken an alternative approach to IPv6: any changes to IPv4 would break everything anyhow, so you might as well come up with a solution designed for the long term. NATs are tolerable up to a point, but once you double or n-Nat, then you are in a territory where doing things properly would have been better.

Certainly IPv6 probably creates new problems, but not ones that can't be solved with the proper tools. For example, you lose the apparent security of a NAT, but at that point Firewalls are already providing an alternative and capable solution.

With all these issues, I am wondering whether beyond the firewall to the external network, internal portions of a corporate network should be firewalled too. For example HR related data should be on a sub-section of the network protected by its own firewall. I would imagine the chances of breaching multiple firewalls being low, unless the penetration into the network is either done by an insider or someone who has been able to lay low on the network for a while?

This may already be the case in many organisations, but I don't know enough about security specifics?

Found it. For anyone else interested: https://github.com/erlerobot

It runs Linux, but is the controller code open source? I couldn't find any links to the source code and without it, whether it runs Linux or something else becomes irrelevant. If anyone finds the link, please share it.

The problem is when Google decides something is good for everyone they don't give us ways to switch back to the old behaviour, even if that change feels like a middle finger. You can have a thousand people open bug reports and Google devs will politely tell you that they know better than everyone else. Sometimes it makes me want to grab a bunch of eager developers and fork Chrome. In the meantime there is still Firefox and Opera to move to.

For the session tokens, their values can be encrypted and they can be tied to an IP address. If the client does not need to do anything special with the cookie values, then the server can do whatever it wants. The session ID cookie may not even need to be encrypted and instead the server side holds which IP address the session is locked to, so it can't be reused.

I am just fed up with Google dumbing down the web browser and turning Chrome into our way or the highway. Cases in point:
    - refusal to support APNG
    - hiding protocol in address field URL

I am hesitating whether to go back to Firefox.