Please excuse my language: I just spent a long time with a partner who insisted on doing things _very much_ the hard way.
> I'd bet that most users who don't have SNI supporting browsers don't have access to IPv6 servers either. IIRC IPv6 on windows XP is turned off by default which for most users means it may as well not be there.
Please separate the requirements of their browsers from the requirements of their servers. The need for SNI is primarily due to the difficulties of SSL key handling: when you connect to an IP address for an encrypted SSL connection, which is tied to the IP address and the host's SSL keys associated with that IP address.
SNI provides some useful workarounds for that requirement, but it's often been awkward to scale and to support. Profound difficulties occur when supporting the name-based virtual servers for people and software _who refuse to follow the best practices_. The results can be nightmarish. If I, as a user, use "www.example.com" instead of "example.com" and they're both at the same IP address, I can often wind up with completely different web pages and little hint of what I did wrong, and then call tech support about the problem. Similarly,
It's a problem I, or my colleagues, run into several times a year.
> umm at least with apache there doesn't seem to be much difference. With IP based vitual hosting you tell it what IP you want to go with each site. With name based virtual hosting you tell it a list of names to go with each site.
The difference is that there are often many ways to reach exactly the same IP address with alternative hostnames in the URL, such as DNS aliases, putting a "." on the end of the hostname (which is completely valid in DNS and prevents the addition of an automatic local domain extension), shortened hostnames if your local DNS supports adding the local domain, modified/etc/hosts files on the client, (which is still far too common a practice from very, very old setup documentation), internal DNS versus DNS entries in sites that use load balancers or static NAT, and others. Couple this with old and poorly managed configuration files complex ourtward facing environments, and a long QA and release process, as is common in large environments, and the slightest name-based misconfiguration can corrupt the entire site and be very awkward to trace back.
There is also the very confusing behavior when common software configurations start putting IP address "127.0.0.1" and "::1" in the webserver's/etc/hosts with the fully qualified hostname. This is actually quite common, but it means that the web server itself can't reliably detect whether the web server is running properly running. Going to the IP address by typing it directly is not necessarily the same virtual host, and redirects will go to the/etc/hosts specified "127.0.0.1". This makes testing the primary web service from the same host itself quite chaotic.
The IP based virtual hosting not only allows far easier management of these configurations, it allows vastly simplified packet analysis to trace and analyze the virtual host specific network traffic. For that reasoon alone, I urge partners and colleagues to switch to IPv6 IP based virtual hosts for crowded externally facing virtual hosts, and to feel free to use IPv4 virtual hosts for internal NAT'ed addresses.
Or they can use IPv6 and IP based web servers, instead of the amazing crap that is server name based virtual hosting and which has *never* worked well.. Avoiding the guesswork, rewriting, and redirecting rules of name based virtual hosting is one of the best justifications I know for using IPv6.
The whole field of transmitting the high-frequency trading information seems to be going away in favor of FPGA's sitting right on the fiber leaving Wall Str.
By putting these sorts of devices directly on leased connections from the stock market, adjacent to the stock market, they eliminate the need for the extremely expensive and often quite unreliable remote high speed connections. I was recently privileged to hear a presentation on the risks of data loss on those lines: they're apparently using multicast for high speed synchronoous transmission, But by the time you've checksummed and re-assembled your data and re-collected the lost packets, it can actually be _slower_ than normal TCP, and the the data verification technologies are often poorly tested.
The key to using the FPGA's is to tune and simplify the models that are stored and processed locally, in place of the expensive remote data centers. And updating those devices doesn't require the low latency and high speed: the analysis of stored data and updates of models can be done remotely and much more slowly.
You've raised several good points, which I'll try to explain.
* The Trusted Computing focus on DRM instead of privacy puts the most critical software keys in the hands of the software vendors, not the computer users. Computer users' keys are designed, in Trusted Computing, to be held in Microsoft's central escrow. The result is that to access your data, and possibly your hardware, you must use Trusted Computing authorized software, and your private keys are accessible to anyone with access to Microsoft's central repository. The result is a direct loss of personal security because both the software keys and yoru personal keys live in Microsoft's hands, not merely your hands. The results for personal privacy are profound: the system ensures authentication and tracking of document creation thorugh review of public and private keys, it does _not_ protect individuals from government or corporate abuse of this central key repository..
* The centralization of the keys and escrow management also means that the keys can be _revoked_, at the software level, denying you access to your previously encrypted private data. Revocation of keys is a critical feature of Trusted Computing, and is rarely addressed for its potential to deny people access to their own Trusted Computing secured data.
* DRM is not for the "owners" of a piece of property. It is for the _vendors_ of that property. They may not actually own a single line of the code, but the particular assemblage of the code which they sell is locked down. This can be useful to prevent cheating in computer games, but it's precisely what TIVO tried to do with patent encumbrance on top of GPL licensed software. It is an ongoing dream of many software vendors who work with "open source" software or proprietary software to lock down their particular implementation and charge whatever the market will bear for that particular version.
* DRM is often a violation of ordinary sales rights to use property. If you can successfully put a codicil in the contract or bill of sale, well and good, but many DRM tools far exceed any reasonable or documented codicil. They grant far too much control to the vendor of the software. (Examine Trusted Computing and the history of Sony's "root kits" for examples of such abuse.)
* RMS has been very careful, and clear, that the people working under GPL are using exactly the right you want: the right to insist that software be used the way the authors want it to be used, or not to be used at all. Many of hsi views are impractical, but that doesn't mean they wouldn't be effective if consistently applied
I actually had the opportunity to speak to RMS a few years ago at a conference. He's a strange man in person, but his approaches to technology and freedom are consistent and well thought out.
It's actually an interesting point. Freedom of software use, and the ownership and ability to access and modify data and software which we purchase, is vital to protecting private data. The "Trusted Computing" technology, for example, is designed to provide secured key access for software and data, and it's being heavily promoted among CPU and motherboard manufacturers and software vendors. It's designed to provide a secure toolchain to authenticate, to encrypt, and to provide software registered access to data.
But careful review of its actual use show thits primary use is DRM, _preventing_ individuals or software from accessing their data in any way other than that specifically authorized by the company issuing the key. The master signature keys for Trusted Computing are held by Microsoft, and they hold most of the private keys in escrow. And the legal guidelines protecting those keys don't seem to exist. I've not been able to find any clear guideline on when, and under what legal requirements, Microsoft will give out or even _subvert_ those keys to install software on computers without the authorization of the owner. This is one of Richard's current concerns: the use of technology to fetter communications and access to your own data and your own resources.
That's a very reasonable point. It's certainly a common one for people who run their own systems. Google has apparently been good about resisting illicit searches, but they do seem to cooperate with legal searches. And a search that is legal can still be inappropriate. (The US Patriot Act is a good example of bad law.)
The difficulty that has strongly reduced my desire for private email systems has been reliability. There are numerous difficulties. Backup and failover, with all traffic preserved, have been awkward.This also includes the bandwidth issues at remote sites, and the resistance to DDOS (distributed denial of service attacks) I've found it very effective to put up with their advertising, or pay a very modest fee for business service, for a service that has an uptime I've never seen in a private service. And I've _run_ or helped integrate and clean up literally dozens of such systems throughout my career.
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.
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:
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:
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.
How is it possibly surprising that the accretion disk is spinning the same way as the black hole itself? The same stellar evolutionary forces that created the galaxy and imparted spin to it would impart mostly consistent spins to every star and to the core structure of the black hole, built out of the same intragalactic nebulae. Is there any process that could impart a different spin to the accretion disk than to the core black hole itself?
Excuse my language above, please, I just spent a very very long week with a partner who invested a lot of money in a few leading edge components they did not and budgeted for it by getting very, very cheap and difficult to support hardware for the rest of their operations. The side by side presentation of "Linux versus Windows" costs had to be completely re-written, and any savings from selection of OS were swamped by the support costs and complete instability caused by the hardware selections.
Hardly. Between NVidia drivers and their misshapen proprietary libraries, and the giant dripping cluster*** that is the new oversold, underperforming 10GBit cards from HP, along with every MegaRAID SCSI card ever made (which are, admittedly, complete donkey apples), and the endless churn of mislabeled and broken "features" of wifi chipsets that don't work even *with* the drivers, it's still often difficult to get things working right on leading edge laptops or underpriced pizza boxes.
It's that 1% that tends to show up in those very, very cheap or very, very expensive systems that will make people tear their harir out in both Linux and in the rest of the support world.
Welcome to Object Oriented Programming (especially Java, which is very popular among these companies). You are not supposed to pay any attention to what is on the other end of the data pipeline, you're just supposed to stream and process the data as absolutely fast as possible. Safety checks, input sanitization, and monitoring of transactions all take precious cycles which are actively discouraged in these high speed envirornments.
Slashdot Mirror
Please excuse my language: I just spent a long time with a partner who insisted on doing things _very much_ the hard way.
> I'd bet that most users who don't have SNI supporting browsers don't have access to IPv6 servers either. IIRC IPv6 on windows XP is turned off by default which for most users means it may as well not be there.
Please separate the requirements of their browsers from the requirements of their servers. The need for SNI is primarily due to the difficulties of SSL key handling: when you connect to an IP address for an encrypted SSL connection, which is tied to the IP address and the host's SSL keys associated with that IP address.
SNI provides some useful workarounds for that requirement, but it's often been awkward to scale and to support. Profound difficulties occur when supporting the name-based virtual servers for people and software _who refuse to follow the best practices_. The results can be nightmarish. If I, as a user, use "www.example.com" instead of "example.com" and they're both at the same IP address, I can often wind up with completely different web pages and little hint of what I did wrong, and then call tech support about the problem. Similarly,
It's a problem I, or my colleagues, run into several times a year.
> umm at least with apache there doesn't seem to be much difference. With IP based vitual hosting you tell it what IP you want to go with each site. With name based virtual hosting you tell it a list of names to go with each site.
The difference is that there are often many ways to reach exactly the same IP address with alternative hostnames in the URL, such as DNS aliases, putting a "." on the end of the hostname (which is completely valid in DNS and prevents the addition of an automatic local domain extension), shortened hostnames if your local DNS supports adding the local domain, modified /etc/hosts files on the client, (which is still far too common a practice from very, very old setup documentation), internal DNS versus DNS entries in sites that use load balancers or static NAT, and others. Couple this with old and poorly managed configuration files complex ourtward facing environments, and a long QA and release process, as is common in large environments, and the slightest name-based misconfiguration can corrupt the entire site and be very awkward to trace back.
There is also the very confusing behavior when common software configurations start putting IP address "127.0.0.1" and "::1" in the webserver's /etc/hosts with the fully qualified hostname. This is actually quite common, but it means that the web server itself can't reliably detect whether the web server is running properly running. Going to the IP address by typing it directly is not necessarily the same virtual host, and redirects will go to the /etc/hosts specified "127.0.0.1". This makes testing the primary web service from the same host itself quite chaotic.
The IP based virtual hosting not only allows far easier management of these configurations, it allows vastly simplified packet analysis to trace and analyze the virtual host specific network traffic. For that reasoon alone, I urge partners and colleagues to switch to IPv6 IP based virtual hosts for crowded externally facing virtual hosts, and to feel free to use IPv4 virtual hosts for internal NAT'ed addresses.
Or they can use IPv6 and IP based web servers, instead of the amazing crap that is server name based virtual hosting and which has *never* worked well.. Avoiding the guesswork, rewriting, and redirecting rules of name based virtual hosting is one of the best justifications I know for using IPv6.
The whole field of transmitting the high-frequency trading information seems to be going away in favor of FPGA's sitting right on the fiber leaving Wall Str.
ftp://ftp.bittware.com/documents/data_sheets/ds-hft.pdf
By putting these sorts of devices directly on leased connections from the stock market, adjacent to the stock market, they eliminate the need for the extremely expensive and often quite unreliable remote high speed connections. I was recently privileged to hear a presentation on the risks of data loss on those lines: they're apparently using multicast for high speed synchronoous transmission, But by the time you've checksummed and re-assembled your data and re-collected the lost packets, it can actually be _slower_ than normal TCP, and the the data verification technologies are often poorly tested.
The key to using the FPGA's is to tune and simplify the models that are stored and processed locally, in place of the expensive remote data centers. And updating those devices doesn't require the low latency and high speed: the analysis of stored data and updates of models can be done remotely and much more slowly.
You've raised several good points, which I'll try to explain.
* The Trusted Computing focus on DRM instead of privacy puts the most critical software keys in the hands of the software vendors, not the computer users. Computer users' keys are designed, in Trusted Computing, to be held in Microsoft's central escrow. The result is that to access your data, and possibly your hardware, you must use Trusted Computing authorized software, and your private keys are accessible to anyone with access to Microsoft's central repository. The result is a direct loss of personal security because both the software keys and yoru personal keys live in Microsoft's hands, not merely your hands. The results for personal privacy are profound: the system ensures authentication and tracking of document creation thorugh review of public and private keys, it does _not_ protect individuals from government or corporate abuse of this central key repository..
* The centralization of the keys and escrow management also means that the keys can be _revoked_, at the software level, denying you access to your previously encrypted private data. Revocation of keys is a critical feature of Trusted Computing, and is rarely addressed for its potential to deny people access to their own Trusted Computing secured data.
* DRM is not for the "owners" of a piece of property. It is for the _vendors_ of that property. They may not actually own a single line of the code, but the particular assemblage of the code which they sell is locked down. This can be useful to prevent cheating in computer games, but it's precisely what TIVO tried to do with patent encumbrance on top of GPL licensed software. It is an ongoing dream of many software vendors who work with "open source" software or proprietary software to lock down their particular implementation and charge whatever the market will bear for that particular version.
* DRM is often a violation of ordinary sales rights to use property. If you can successfully put a codicil in the contract or bill of sale, well and good, but many DRM tools far exceed any reasonable or documented codicil. They grant far too much control to the vendor of the software. (Examine Trusted Computing and the history of Sony's "root kits" for examples of such abuse.)
* RMS has been very careful, and clear, that the people working under GPL are using exactly the right you want: the right to insist that software be used the way the authors want it to be used, or not to be used at all. Many of hsi views are impractical, but that doesn't mean they wouldn't be effective if consistently applied
I actually had the opportunity to speak to RMS a few years ago at a conference. He's a strange man in person, but his approaches to technology and freedom are consistent and well thought out.
It's actually an interesting point. Freedom of software use, and the ownership and ability to access and modify data and software which we purchase, is vital to protecting private data. The "Trusted Computing" technology, for example, is designed to provide secured key access for software and data, and it's being heavily promoted among CPU and motherboard manufacturers and software vendors. It's designed to provide a secure toolchain to authenticate, to encrypt, and to provide software registered access to data.
But careful review of its actual use show thits primary use is DRM, _preventing_ individuals or software from accessing their data in any way other than that specifically authorized by the company issuing the key. The master signature keys for Trusted Computing are held by Microsoft, and they hold most of the private keys in escrow. And the legal guidelines protecting those keys don't seem to exist. I've not been able to find any clear guideline on when, and under what legal requirements, Microsoft will give out or even _subvert_ those keys to install software on computers without the authorization of the owner. This is one of Richard's current concerns: the use of technology to fetter communications and access to your own data and your own resources.
That's a very reasonable point. It's certainly a common one for people who run their own systems. Google has apparently been good about resisting illicit searches, but they do seem to cooperate with legal searches. And a search that is legal can still be inappropriate. (The US Patriot Act is a good example of bad law.)
The difficulty that has strongly reduced my desire for private email systems has been reliability. There are numerous difficulties. Backup and failover, with all traffic preserved, have been awkward.This also includes the bandwidth issues at remote sites, and the resistance to DDOS (distributed denial of service attacks) I've found it very effective to put up with their advertising, or pay a very modest fee for business service, for a service that has an uptime I've never seen in a private service. And I've _run_ or helped integrate and clean up literally dozens of such systems throughout my career.
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.
How is it possibly surprising that the accretion disk is spinning the same way as the black hole itself? The same stellar evolutionary forces that created the galaxy and imparted spin to it would impart mostly consistent spins to every star and to the core structure of the black hole, built out of the same intragalactic nebulae. Is there any process that could impart a different spin to the accretion disk than to the core black hole itself?
Excuse my language above, please, I just spent a very very long week with a partner who invested a lot of money in a few leading edge components they did not and budgeted for it by getting very, very cheap and difficult to support hardware for the rest of their operations. The side by side presentation of "Linux versus Windows" costs had to be completely re-written, and any savings from selection of OS were swamped by the support costs and complete instability caused by the hardware selections.
Hardly. Between NVidia drivers and their misshapen proprietary libraries, and the giant dripping cluster*** that is the new oversold, underperforming 10GBit cards from HP, along with every MegaRAID SCSI card ever made (which are, admittedly, complete donkey apples), and the endless churn of mislabeled and broken "features" of wifi chipsets that don't work even *with* the drivers, it's still often difficult to get things working right on leading edge laptops or underpriced pizza boxes.
It's that 1% that tends to show up in those very, very cheap or very, very expensive systems that will make people tear their harir out in both Linux and in the rest of the support world.
Welcome to Object Oriented Programming (especially Java, which is very popular among these companies). You are not supposed to pay any attention to what is on the other end of the data pipeline, you're just supposed to stream and process the data as absolutely fast as possible. Safety checks, input sanitization, and monitoring of transactions all take precious cycles which are actively discouraged in these high speed envirornments.