Actually, they did have to ignore laws of nature for some of those. Homosexual behavior is quite common throughout the animal kingdom. So is infanticide, the close relative of abortion.

Given that you gave up Gmail's excellent reliability, scalability, and accessibility, why would you want to run your own private system?

Gaseous hydrogen leaks a great deal, no matter how it's stored. That's a cost that will strongly affect the economy of such aircraft. One could theoretically use the hydrogen for fuel for the propellers or electronic systems safely, so I wouldn't anticipate large problems with carrying enough fuel, but hydrogen molecules are very small and tend to leak right through pressure containers. And as the hydrogen leaks, it will tend to collect in any physical reservoirs around the gas bag. That could make preventing flammable buildups, especially near modern electrical systems, quite awkward.

Hydrogen is also quite reactive. (This is partly why it burns so well.) So I'd expect corrosive surprises with materials used in such an unusual environment, especially if low-cost bidders substitute cheap components that haven't been tested properly in the infrastructure exposed to the hydrogen. This isn't to say it can't be done economically, but the first few such ships are going to be prone to some unexpected failures due to interaction with an unusual environment.

It's helpful to people planning morge, hospital, and police resources. Making sure that your manpower is ready for clusters of murders and have the tools to handle the dead, injured, and evidence is useful. It's also useful to the communities to realize and have hard numbers to back up their needs for containment of such dangerous events, and to help them innoculate against the outbreak spreading by education and community outreach.

CDC vectoring tools would seem to be potentially useful. What is the timetable of such "outbreaks" ? Are control efforts better spent on dealing on each outbreak, as it occurs, or on broader "innoculation" via employment programs and drug rehabiliation?

Once the business of organ farming starts, China is facing an enormous market for healthy, young organs and an aging population that needs them around the world. It's much simpler to simply outlaw, outright, than to start trying to manage and regulate such a business.

I've worked with such commercial data centers. The access to personnel, equipment, transit, multiple data feeds, and urban electrical power can far outweigh the risks of such urban centers. High reliability offsite facilities can be enormously expensive in both hardware and manpower. A data center where personnel can walk over with installation media and update the BIOS on a full rack of equipment and come back to the office for lunch is a massive savings in engineering time and resources over expensive remote consoles, blade servers, or other solutions for remote hands-on access.

A quick review of the Wankel engine also shows that this technology might be better applied there. The engine destroying accidental misfires known to some Wankel designes would not occur, and the problems handling the spark plug or with lubrication also would not apply.

This is not a combustion engine, at all. It's an "insert water with hot oil, use generated steam to drive engine, separate back oil and water to reuse" engine.

The potential efficiency is interesting, and the reduction of generated hydrocarbons compared to a normal motor of the awkwardness of creating and handling lead-acid batteries or other awkward electrical energy storage is also interesting. The difficulty of doing reliable water and oil separation for long periods, at low cost and with low power cost, is an interesting one.

Or they can use the wi-fi functionality. Pre-planting a few wi-fi devices would not be difficult in a dense urban area. I'm afraid this is also aimed at blocking cellphone _cameras_, and recording of political speeches and security force behavior.

I'm afraid that you are mistaken: your ignorance of the technology is widespread, and leads to precisely the behavior I described of leaving the SSH keys unencrypted and widely available.

Look into the "ssh-agent" tool, the wrappers for it, and the various system keychaiins on different operating systems. It may take thought to handle it for your particular environment, but the simplest approach from a common shell environment is below:

          eval `ssh-agent1
          echo $SSH_AUTH_SOCK
          ssh-add -l
          ssh-add $HOME/.ssh/id_dsa
          ssh-add -l

You'll see that the key has been unlocked for any shells or system commands on that host that have the "SSH_AUTH_SOCK" set to access the running ssh-agent.

That value isn't always apparent to the manager, even if it's apparent to the customers. Experienced engineers tend to know better solutions to prevent a problem in the first place, or know not to use dangerous approaches. Younger engineers tend to be more willing to write from scratch and do what the manager asks for without question.

Older engineers do managerial orders, and large environments that hire managers based on head count need fewer managers. That's awkward for managers who want to manager more, less demanding engineers to improve their own careers It's part of Jerry Pournelle's "Iron Law of Bureaucracy", where some managers decide things for the organization and their "organizaiton" is the bureaucracy itself.

Also, do _not_ rely on the commonly enforced use of excessively "Mix3d!Cas3". The reasons not to use this take some thought, but are actually well described in XKCD:

              http://xkcd.com/936/

But the real reason is not there: it's that people frequently store such passwords in unencrypted, easily accessible locations such as a file called "passwords.doc" on their desktop, or send them via unencrypted email because they're too hard to remember or explain on a voice transmission.

From a recent security audit I participated in, you are mistaken. The number of SSH keys that were _not_ passphrase encrypted, in a typical multi-user environment, vastly exceeded the number that were encrypted. These keys were stored on an unsecured NFSv3 environment, and on poorly secured backup tapes. This configuration is common, and we even found several github and Sourceforge SSH keys for known participants in open source projects there.

While the number of security errors in those environments were quite large, they're quite commonplace. They are partly the result of the fact that SSH servers have no way of restricting users to the use of passphrase protected keys, and SSH key generators, especially those in the OpenSSH codebase, do not enforce the use of passphrase protected keys. (They issue a warning, but do not enforce the use of passphrase.) There are certainly tools available to help manage passphrase protected SSH keys. but even where available, they remain rarely used.

This is compounded by the lack of effective centralized management tools for SSH key access, and the nonexisting or recently implemented and rarely used expiration or revocation technologies for SSH. SSH should only be considered robust for protecting individual sessions from decryption. Its "key" technology should not be considered a robust authentication technology due to these commonplace flaws.

There are better general authentication approaches: SSH, both OpenSSH and SecureCRT's tool suites, now offer Kerberos authentication. This is a much safer technology, not vulnerable to the various "stolen passphrase free key" issues of normal SSH. Unfortunately, I've not seen any way for it to mesh well with SSH configurations that rely on the "ForceCommand" option being tuned for individual users and their SSH keys, especially source control technologies such as the "git" and "Subversion" and "CVS" access at Sourceforge.

> Oh come on. Do you really think Microsoft is going to blackmail world governments, or leave them without any recourse? Not to mention the fact that there are entire cottage industries that have grown up around the concept of third party interaction with these data formats.

Yes, of course they do. Forced updates and maintenance costs, with no guarantee of successful acces to the old documents, is the ongoing "danegeld" paid for MS Office format access. The cottage industries you mention are profoundly hampered by the deliberately hidden or deliberately mishandled API's used by Microsoft since the creation of their office suites. (Do look into the history of the so called "Open Office XML" standard, it's been fascinating.)

> Organizations are going to either pay MS for a (debatable) better product, or to technicians to bridge the gap of other solutions.

As somene who's dealt with broad scale deployments of Office, especially the email and calendar suites, that "or" is misplaced. The word should be "and". The expertise and support are necessary for either tool suite, the difficulties are in the amount of support. MS Office, for example, has a ludicrous number of constant and disruptive updates for documents that are fragile and difficult to source control, prone to lengthy arguments about which font to use for which paragraph. And the license management itself is very awkward.

LibreOffice (the successful fork of OpenOffice) is more portable, actually uses and follows document standards for permanent access to older documents. And the multi-platform compatibility with older hardware and other operating systems are huge reductions in "total cost of ownership", coupled with the time saved handling license registration and tracking for MS Office toolkits. The difficulty is in missing features: There is no direct freeware or open source competitor to Outlook, for example, with its tight integration with MS Exchange. (The freeware tools and most "Connector" tools that tie to MS Exchange are basically Outlook Web Access clients, with all the limitations that contains.)

If a company can use LibreOffice with hired or trained support, and a good mail and calendar integration tool such as corporate GMail, than at the IT level, there is no contest on "total cost of ownership". There remains a hidden cost: training. The staff need to relearn MS Office skills they learned during their education as paperwork handlers, and this is a very real cost.