And even then, there would still be pedestrians, bicycles, motorcycles, etc, to worry about. So I think traffic lights won't be going away anytime soon.
Motorcycles will be robotic too. Bicycle riders will be required to be equipped with an electronic interface to the vehicle network. Their bike will identify them to the other vehicles as a rider and tell them when they can stop/go; or they just won't be allowed on the road.
Lack of traffic lights does not preclude the concept of walk/no walk signs for pedestrians.
Pedestrians crossing roads may be required to pay a tax/fee to a machine at the crosswalk in order to compensate for the locality's expenses involved in providing human readable signals.
You won't be able to get rid of traffic lights (etc) until all manually-driven cars have been banned from public streets. Which will happen sometime between "when your great grandchildren are old", and "never".
As soon as it's shown that all the accidents occuring involve human drivers; government will identify it as a safety feature, and require all new cars be fully robotic within some number of years.
Soon after all new cars are robotic, human drivers will get banned altogether. The DMVs will simply stop issuing drivers licenses, except under special cases, and only issue "robotic vehicle user's permits" to the rest of the population.
Eventually the special exceptions will be phased out, and all legal drivers will be robotic. 'Manual' cars will no longer be road legal.
Now if robot cars become the norm it gets easier still. The computers can just talk to each other to say 'can I merge?'
If robot cars become the norm, we can get rid of 'traffic lights', stop signs, etc, and use a network protocol to determine which cars get to enter the intersection in which order, in order to optimize the aggregate cars-per-second rate of the road system.
Speed limits can also be determined by a safety algorithm, and we won't need traffic cops anymore, which will save government a lot of money on road equipment, and free up police officers to investigate real crimes, like expired break tags.
With "parking rule data" stored in cars' memory banks, we can even eliminate parking enforcement officers;
since cars will simply refuse to park in any properly designated no-parking area; and they'll automatically submit paid parking meter fees, so municipalities can have their meter maids doing something more useful like going around washing the cars whose owner pushed the "yes" button to please wash my car, when they were parking....
, the first time someone gets hurt by one there will be a huge outcry and a lawsuit.
There will be an outcry, until the video footage recorded in the robot car's black box shows that a human involved caused the accident, not the machine.
Power steering isn't steer-by-wire; it's just power assist.
First of all... there ARE steer-by-wire systems. And they are in much more wide use than robotic cars, of course, but they are allowed on the road.
Also... I understand you've driven cars with inoperative power steering, in other words, you were using probably something close to manual steering with total or near total failure of the power assist systems, but that doesn't necessarily mean that all failures of the power steering system have the same outcome or failure mode... what happens when the power steering breaks in a way other than just causing the assist to go away....
what about failure modes of the power steering system that cause the power steering to be apply the hydraulic force TOWARDS one direction, when you are actually trying to steer in the opposite direction, because the servo mechanism has failed, but the power steering pump is still fully operational?
By my estimation, in my experience (freenode and efnet), most people on IRC are running some form of older-school Linux distribution, such as Debian or Slackware. There are some Ubuntu peeps but I think a lot of them use something more 'modern', i.e. skype or pidgin. I see BSD folks in my BSD channels, but they only barely edge out the Windows guys overall.
I'll go with that. I'm one of the few folks left who still uses IRC, and I used Slackware until very recently...
I am afraid I have moved to the dark side; using MacOS on the desktop.
I think if there are hackers on IRC who still use windows, most of them are at least smart enough to use an *ix-based proxy, such as BNC.
As a long time DALnet user; I can't say too much about Freenode/Efnet. But I have not observed many Windows "hackers" anymore. Sure, there are still windows users. Not the types who would engage in PoD competitions.
I use the hyperbole as one of the "5 users left" on IRC, because since I started using IRC on DALnet in early 1995; I have watched the average peak online number of users counts grow well into 130,000+ users, and then in later years drop way back to 15,000.
I can't help but mourn that IRC in many respects may be past its prime; i'm afraid networks will slowly erode , as soon as the current generation of IRC server admins retire, and ISPs can no longer be found that want to run IRC servers for free.:-/
Keep in mind that if it goes to SCOTUS, it might be overturned. The Supreme Court might decide that extortion which is asking for an agreement not to pursue a known legal right--i.e. suing you--
Blackmailing someone is asking for an agreement not to pursue a known legal right---i.e. to exercise freedom of speech and publish newsworthy information.
That doesn't mean it's no longer extortion.
I would like to see this hold up at SCOTUS, so it can be applied to RIAA lawyers' tactics.
All they have to do in order to make it no longer extortion is to increase their settlement demands
to an amount at parity with the costs of going to court and defending yourself
As I see it, notaries acting as short-term CAs to proxy DNSSEC would have to prove themselves to the browser makers just as any other CA would.
Notaries are mini-CAs, so they would need to meet some standard, but my argument is that would be a lesser standard than CAs need to meet. I would envision Notaries being operated by the same kinds of companies that currently operate CAs, and they would still need to charge for their services, probably a monthly fee, and companies that operate full CAs would still need to meet current standards.
Depending on how frequently the notary certs need to be reissued, it could still be less than $100/year.
CPU and bandwidth issue for certificate issuance are negligible per certificate.
There is a cost, but that is small per user.
Risks of a malevolent notary could be limited by limiting the validity period of the Notary signing certificates by the intermediary CA, to a period of no more than say 24 hours (or twice whatever the 'notarization' expire interval is).
The difference is CAs define their own practices, such as their customer verification practices, and a third party audits their practices to determine if they are within certain externally defined requirements. Some CAs just check DNS records.... others demand state issued ID. Every CA has to go through a lot of trouble to define all these different things, but...
For Notaries, it could be greatly simplified.... since all notary issued certificates would be required to have the same parameters
defined by the standard, meet the same exact parameters, and be verified the exact same way, no more, no less, "auditing" a notary becomes a simple matter, of verifying that their practices are identical to the standard, and proper IT security practices are in place.
Basically... i'm saying instead of the Notary defining their own "Certification Standard Practicese" / CSPs, every Notary would be required to conform with a simple, identical standard document, uniformly specifying the same verification for every certificate and every notarizer.
The notarizers could even be required to deploy very specific hardware and software configurations, and hardware devices designed to perform the Notary function with security at the hardware level and no risk of a signing key being divulged, like a CA could have.
The notary could be required to embed the entire signed DNSSEC path using extension attributes inside the certificate.
Browsers that fully support DNSSEC could be programmed to "snitch" on any notary, if they connect to a server, and are presented with a Notary certificate that does not appear consistent with DNSSEC information in the certificate (or in DNS), by posting a form to a URL indicated in the upstream certificate's extension section for 'notary certificate'.
Upon examining the proof, if the full signed DNSSEC path from root to domain DS+RRSIGs embedded in the certificate does not signature validate, that Notary's signing certificate will not be renewed by the CA certifying that notary.
Yeah, once at your servers the attacker would better just do the DB updates needed to get what he wants, or change your web content. (Oh, and don't forget about setting a backdor.)
That's true.... that is why it makes sense to use a read-only NFS mount or a read-only mode GPFS mount, so the individual web servers that are exposed to the world don't actually have access to change any of the content, and an IDS continuously monitors the file servers for any unapproved changes.
If this is a high-security site, such as an e-commerce site that has credit card numbers, it also makes sense to avoid storing any SQL usernames or passwords with full DB access on any web server, as well.
This can be accomplished by directing the SQL server to authenticate SQL logins against a database that corresponds to the user accounts; for example if someone's username on the website is "foo" password "bar"; and they login, a SQL login is performed with credentials derived from that combination, and the resulting SQL login will only have access to execute stored procedures that operate at a DB permission level equivalent to that user's permissions.
As a result, the only way a web server ever operates with full 'admin' level access, is if an admin logs in.
A sensible security design is... no 'admin login' mechanism exists on the publicly accessible website.
Admin login only exists on an internal site with dedicated web servers.
As a result... at no time do public facing web servers have an ability to 'change the database'.
What if somebody subverts the securelevel, and then fires up gdb?
I would encourage you to try finding just one example of something that successfully subverts securelevel on a kernel released in the past 3 years.
What if the intruder subverts veriexec, and remounts the filesystems read-write?
I said veriexec level 1, but I actually meant veriexec level 3.
Binaries that were not allowed in the predefined list are not able to run, period.
And any files that are in the predefined list cannot be modified, even if filesystems are read-write.
No filesystem can be mounted, unmounted, or remounted when securelevel is 2 or higher.
Raw block devices also cannot be accessed, and root cannot bypass protected mode and directly access any kernel or user space memory, load/unload any modules, etc.
Furthermore, since the filesystems are mounted from ISO images, the Kernel is actually physically incapable of making the filesystem read-write.
The only way to change the filesystem contents is to alter the underlying disk image; which is even harder when this disk image is stored on read-only media, or a SAN that will not grant the server itself write access.
If somebody rooted your server, they could attach a gdb to the already running Apache process, in order to grab the already-decrypted private RSA key from memory.
No.... the system runs at securelevel 2. It's not possible to run gdb, trace any process, or access raw memory from user programs, or a root shell.
In addition, veriexec is enabled at level 1, and most filesystems are read-only: upgrades are handled by imaging entire filesystems.
These are bare minimum precautions.
Many organizations employ load balancers for their SSL sites, that employ hardware crypto, oft' with no method of extracting private keys available.
A more likely attack would be inserting a script/page in the company's web content area
designed to steal credentials by forwarding them outside the secure domain.
However, this is easily detected by IDS, or page integrity checks
No. Your base assumptions are wrong. The thing is you can't verify identity. I break into your server. I take your cert. I throw it in my apache directory. I pwn your nameserver. Now, I am you. None of these steps take a rocket scientist.
Why do you think we have to type in a 64-character passphrase every time we start Apache on the
secure servers, before they can unlock the secret RSA key, get added to the load balancer, and start answering requests?
No... breaking into my server does not let you pretend to be me.
And if you do break into the SSL server, you can be sure i'll have a new SSL cert soon, and the previous one
will be listed in the CRLs long before you can get a hand at trying to crack the AES encryption protecting RSA key.
The part where there have to be edges between people in different cities. Otherwise there are multiple disjoint webs, one for each city, not one global web.
There are plenty of people who travel between cities, so there are already plenty of opportunities for edges.
A handful of people between nearby cities can extend the range of the web of trust.
Almost all cities are close to some other city.
Eventually, the web could spread between all cities, just by spreading between people at nearby cities.
The problem is not travel; the problem is getting everyone involved, not just crypto geeks.
Provided all clients support DNSSEC, which probably won't happen for several years.
Then we could introduce the concept of a public notary, which would be a DNSSEC enabled server
that will vouch for the server.
For example... we could eliminate all trusted CA certificates, and replace them with trusted notary certificates.
The rules regarding notaries issuing certificates for domain names or any subdomain could be something like:
(1) any notary issued certificate must be valid for no longer than 1 hour.
(2) a notary certificate can only be issued after comparing the details of the CSR presented, with a valid DNSSEC distributed public key, and finding the Subject name and public key details identical.
(3) a certificate for an e-mail address (e.g. for S/MIME), for code signing, or AD/LDAP Directory authentication, may be issued for a longer period, but must not be valid after the current expiration date of the domain name, and for issuance, SSL keys must be distributed under a DNSSEC validated subdomain that [1] identifies the desired subject of the certificate, [2] identifies the desired duration of the certificate, and [3] identifies the public key, etc.... all CSR details must be mirrored in the DNS record, and all signed using DNSSEC
No, no, no... You completely misread that. You're only allowed to move your mouse pointer 2000 pixels per window, per day. Licensure of pixels is then 100 "points" per 1000 above that.
Hm... maybe we should try a car analogy
You buy a truck with a twin engine turbodiesel and two fuel tanks.
Next you buy a 50' trailer with a compartment system that is sold based on how many engine sockets you have, so you pay your
two $4500 "Engine licenses" plus a $5,000 door handle license for $14,000 total for the compartment system, plus a total annual maintenance contract of
23%, or $3,220 a year, which guarantees you the a free entitlement to company's latest models as they come out,
every 3 years.
The compartment system you licensed is essentially a series of boxes that lets you divide your trailer
however you see fit.
Then a couple years later, they come out with a compartment system V2.
You are entitled to a free upgrade as promised, BUT, before they give it to you, they
hand you a new EULA, and say you won't get your promised upgrade unless you "sign this",
which contains a clause stipulating For each engine license, you are only entitled
to 20000 pounds of trailer storage (cores) AND 1000 cubic feet of trailer storage.
Since your truck is normally used to tow a payload of 3000 cubic feet, you will have to buy an additional engine license.
costing you another $4500 and another $1035 a year, to utilize your "free" upgrade.
For every CPU, you can have 2000x2000 pixels worth of open windows.
To determine if you are in compliance, add up the widthXheight pixel sizes of the open windows for all running
applications (whether minimized or not), if the number of vPixels used exceeds your entitlement, then you are not in compliance
and must buy additional OS licenses.
This applies whether you paid in advance for yearly free upgrades or not.
If this is a problem for you, we recommend calling your application vendors to change the size of your windows.
Once they are right-sized, there should be no performance impact, and you won't notice at all.
(P.S. enjoy your 50 pixel by 50 pixel notepad++ window)
Oddly, it doesn't have Live snapshotting (which is free in VMware)
It seems like the virtualization vendors are all making the mistake of charging money for new features they had to develop,
out of proportion to their place within the software.
More enterprises need snapshotting mechanisms to take backups (IMO) than need live migration.
The features everyone needs should have the lowest cost, to encourage users with basic needs
to adopt free edition, and pay up, when they start to need more.
"no, we won't honor the contract, you'll have to buy more product," and B) stupid, as the licensing model directly undermines one of VMware's principal advantages.
They did this once before, at the last major release when they introduced Enterprise+.
They had been publicizing new advanced features that would be in vSphere for many months.
Then, when the release actually came out, they introduced a new license tier "Enterprise+" which would get all the new features.
So, even though the upgrade to vSphere was provided under SnS, Enterprise customers only got minor, incremental
improvements. None of the advanced features introduced in the upgrade that they had paid for maintenance in order to obtain!
I would not be surprised if one day vCenter ends up managing Xen and/or KVM the same way it will manage ESXi./em>
I would be surprised. If VMware were to add this ability to vCenter, it would increase the value of their competitors' hypervisors...
now suddenly you wouldn't even need to change management tools or admin skillsets to migrate to the competitors' platform....
The Virtual reality check product has published whitepapers with detailed performance comparisons between VMware, Hyper-V, and XenServer. To summarize them all, they show XenServer has much better performance than VMware for VDI [XenDesktop].
Basically, faster, and you can therefore consolidate more VMs per host than with VMware.
Slashdot Mirror
allowing it to be coupled with mini turbines to produce steam that can then be used to generate electricity.
Forget cars... every house could use one of these Thorium generators to produce its own power.
We'd no longer need a massive, failure-prone, expensive, inefficient electrical grid to get electricity.
if 1 gram = 7500gal, then a kilogram will power my house for a hundred years or more.
I didn't see the tea party types react much to the NHTSA folks planning to mandate backup cameras for 2014. :-)
I don't know that the tea party will necessarily be that influential by the time robotic cars start coming around anyways. A lot can happen in 5 years
And even then, there would still be pedestrians, bicycles, motorcycles, etc, to worry about. So I think traffic lights won't be going away anytime soon.
Motorcycles will be robotic too. Bicycle riders will be required to be equipped with an electronic interface to the vehicle network. Their bike will identify them to the other vehicles as a rider and tell them when they can stop/go; or they just won't be allowed on the road.
Lack of traffic lights does not preclude the concept of walk/no walk signs for pedestrians. Pedestrians crossing roads may be required to pay a tax/fee to a machine at the crosswalk in order to compensate for the locality's expenses involved in providing human readable signals.
You won't be able to get rid of traffic lights (etc) until all manually-driven cars have been banned from public streets. Which will happen sometime between "when your great grandchildren are old", and "never".
As soon as it's shown that all the accidents occuring involve human drivers; government will identify it as a safety feature, and require all new cars be fully robotic within some number of years.
Soon after all new cars are robotic, human drivers will get banned altogether. The DMVs will simply stop issuing drivers licenses, except under special cases, and only issue "robotic vehicle user's permits" to the rest of the population.
Eventually the special exceptions will be phased out, and all legal drivers will be robotic. 'Manual' cars will no longer be road legal.
Now if robot cars become the norm it gets easier still. The computers can just talk to each other to say 'can I merge?'
If robot cars become the norm, we can get rid of 'traffic lights', stop signs, etc, and use a network protocol to determine which cars get to enter the intersection in which order, in order to optimize the aggregate cars-per-second rate of the road system.
Speed limits can also be determined by a safety algorithm, and we won't need traffic cops anymore, which will save government a lot of money on road equipment, and free up police officers to investigate real crimes, like expired break tags.
With "parking rule data" stored in cars' memory banks, we can even eliminate parking enforcement officers; since cars will simply refuse to park in any properly designated no-parking area; and they'll automatically submit paid parking meter fees, so municipalities can have their meter maids doing something more useful like going around washing the cars whose owner pushed the "yes" button to please wash my car, when they were parking....
, the first time someone gets hurt by one there will be a huge outcry and a lawsuit.
There will be an outcry, until the video footage recorded in the robot car's black box shows that a human involved caused the accident, not the machine.
Power steering isn't steer-by-wire; it's just power assist.
First of all... there ARE steer-by-wire systems. And they are in much more wide use than robotic cars, of course, but they are allowed on the road.
Also... I understand you've driven cars with inoperative power steering, in other words, you were using probably something close to manual steering with total or near total failure of the power assist systems, but that doesn't necessarily mean that all failures of the power steering system have the same outcome or failure mode... what happens when the power steering breaks in a way other than just causing the assist to go away.... what about failure modes of the power steering system that cause the power steering to be apply the hydraulic force TOWARDS one direction, when you are actually trying to steer in the opposite direction, because the servo mechanism has failed, but the power steering pump is still fully operational?
more fun if you can have the backup driver in the right-hand seat and a large dog or a Terminator mannequin in the left-hand seat
It would be even more fun with something more like the Airplane! The Movie: autopilot in the left-hand seat
By my estimation, in my experience (freenode and efnet), most people on IRC are running some form of older-school Linux distribution, such as Debian or Slackware. There are some Ubuntu peeps but I think a lot of them use something more 'modern', i.e. skype or pidgin. I see BSD folks in my BSD channels, but they only barely edge out the Windows guys overall.
I'll go with that. I'm one of the few folks left who still uses IRC, and I used Slackware until very recently... I am afraid I have moved to the dark side; using MacOS on the desktop. I think if there are hackers on IRC who still use windows, most of them are at least smart enough to use an *ix-based proxy, such as BNC.
As a long time DALnet user; I can't say too much about Freenode/Efnet. But I have not observed many Windows "hackers" anymore. Sure, there are still windows users. Not the types who would engage in PoD competitions.
I use the hyperbole as one of the "5 users left" on IRC, because since I started using IRC on DALnet in early 1995; I have watched the average peak online number of users counts grow well into 130,000+ users, and then in later years drop way back to 15,000. I can't help but mourn that IRC in many respects may be past its prime; i'm afraid networks will slowly erode , as soon as the current generation of IRC server admins retire, and ISPs can no longer be found that want to run IRC servers for free. :-/
better late then never!
It must be their trump card... a feature saved for a rainy day.
Now every IRC'er in the world will need to upgrade to Windows 7, so they can be invincible to PoD.
Oops... someone should have reminded MS that the 5 IRC'ers left in the world already switched to*ix.
Keep in mind that if it goes to SCOTUS, it might be overturned. The Supreme Court might decide that extortion which is asking for an agreement not to pursue a known legal right--i.e. suing you--
Blackmailing someone is asking for an agreement not to pursue a known legal right---i.e. to exercise freedom of speech and publish newsworthy information.
That doesn't mean it's no longer extortion.
I would like to see this hold up at SCOTUS, so it can be applied to RIAA lawyers' tactics.
All they have to do in order to make it no longer extortion is to increase their settlement demands to an amount at parity with the costs of going to court and defending yourself
As I see it, notaries acting as short-term CAs to proxy DNSSEC would have to prove themselves to the browser makers just as any other CA would.
Notaries are mini-CAs, so they would need to meet some standard, but my argument is that would be a lesser standard than CAs need to meet. I would envision Notaries being operated by the same kinds of companies that currently operate CAs, and they would still need to charge for their services, probably a monthly fee, and companies that operate full CAs would still need to meet current standards.
Depending on how frequently the notary certs need to be reissued, it could still be less than $100/year. CPU and bandwidth issue for certificate issuance are negligible per certificate. There is a cost, but that is small per user.
Risks of a malevolent notary could be limited by limiting the validity period of the Notary signing certificates by the intermediary CA, to a period of no more than say 24 hours (or twice whatever the 'notarization' expire interval is).
The difference is CAs define their own practices, such as their customer verification practices, and a third party audits their practices to determine if they are within certain externally defined requirements. Some CAs just check DNS records.... others demand state issued ID. Every CA has to go through a lot of trouble to define all these different things, but...
For Notaries, it could be greatly simplified.... since all notary issued certificates would be required to have the same parameters defined by the standard, meet the same exact parameters, and be verified the exact same way, no more, no less, "auditing" a notary becomes a simple matter, of verifying that their practices are identical to the standard, and proper IT security practices are in place.
Basically... i'm saying instead of the Notary defining their own "Certification Standard Practicese" / CSPs, every Notary would be required to conform with a simple, identical standard document, uniformly specifying the same verification for every certificate and every notarizer.
The notarizers could even be required to deploy very specific hardware and software configurations, and hardware devices designed to perform the Notary function with security at the hardware level and no risk of a signing key being divulged, like a CA could have.
The notary could be required to embed the entire signed DNSSEC path using extension attributes inside the certificate.
Browsers that fully support DNSSEC could be programmed to "snitch" on any notary, if they connect to a server, and are presented with a Notary certificate that does not appear consistent with DNSSEC information in the certificate (or in DNS), by posting a form to a URL indicated in the upstream certificate's extension section for 'notary certificate'.
Upon examining the proof, if the full signed DNSSEC path from root to domain DS+RRSIGs embedded in the certificate does not signature validate, that Notary's signing certificate will not be renewed by the CA certifying that notary.
Yeah, once at your servers the attacker would better just do the DB updates needed to get what he wants, or change your web content. (Oh, and don't forget about setting a backdor.)
That's true.... that is why it makes sense to use a read-only NFS mount or a read-only mode GPFS mount, so the individual web servers that are exposed to the world don't actually have access to change any of the content, and an IDS continuously monitors the file servers for any unapproved changes.
If this is a high-security site, such as an e-commerce site that has credit card numbers, it also makes sense to avoid storing any SQL usernames or passwords with full DB access on any web server, as well.
This can be accomplished by directing the SQL server to authenticate SQL logins against a database that corresponds to the user accounts; for example if someone's username on the website is "foo" password "bar"; and they login, a SQL login is performed with credentials derived from that combination, and the resulting SQL login will only have access to execute stored procedures that operate at a DB permission level equivalent to that user's permissions.
As a result, the only way a web server ever operates with full 'admin' level access, is if an admin logs in.
A sensible security design is... no 'admin login' mechanism exists on the publicly accessible website. Admin login only exists on an internal site with dedicated web servers.
As a result... at no time do public facing web servers have an ability to 'change the database'.
What if somebody subverts the securelevel, and then fires up gdb?
I would encourage you to try finding just one example of something that successfully subverts securelevel on a kernel released in the past 3 years.
What if the intruder subverts veriexec, and remounts the filesystems read-write?
I said veriexec level 1, but I actually meant veriexec level 3.
Binaries that were not allowed in the predefined list are not able to run, period. And any files that are in the predefined list cannot be modified, even if filesystems are read-write.
No filesystem can be mounted, unmounted, or remounted when securelevel is 2 or higher. Raw block devices also cannot be accessed, and root cannot bypass protected mode and directly access any kernel or user space memory, load/unload any modules, etc.
Furthermore, since the filesystems are mounted from ISO images, the Kernel is actually physically incapable of making the filesystem read-write.
The only way to change the filesystem contents is to alter the underlying disk image; which is even harder when this disk image is stored on read-only media, or a SAN that will not grant the server itself write access.
If somebody rooted your server, they could attach a gdb to the already running Apache process, in order to grab the already-decrypted private RSA key from memory.
No.... the system runs at securelevel 2. It's not possible to run gdb, trace any process, or access raw memory from user programs, or a root shell.
In addition, veriexec is enabled at level 1, and most filesystems are read-only: upgrades are handled by imaging entire filesystems.
These are bare minimum precautions. Many organizations employ load balancers for their SSL sites, that employ hardware crypto, oft' with no method of extracting private keys available.
A more likely attack would be inserting a script/page in the company's web content area designed to steal credentials by forwarding them outside the secure domain. However, this is easily detected by IDS, or page integrity checks
No. Your base assumptions are wrong. The thing is you can't verify identity. I break into your server. I take your cert. I throw it in my apache directory. I pwn your nameserver. Now, I am you. None of these steps take a rocket scientist.
Why do you think we have to type in a 64-character passphrase every time we start Apache on the secure servers, before they can unlock the secret RSA key, get added to the load balancer, and start answering requests?
No... breaking into my server does not let you pretend to be me.
And if you do break into the SSL server, you can be sure i'll have a new SSL cert soon, and the previous one will be listed in the CRLs long before you can get a hand at trying to crack the AES encryption protecting RSA key.
The part where there have to be edges between people in different cities. Otherwise there are multiple disjoint webs, one for each city, not one global web.
There are plenty of people who travel between cities, so there are already plenty of opportunities for edges.
A handful of people between nearby cities can extend the range of the web of trust.
Almost all cities are close to some other city. Eventually, the web could spread between all cities, just by spreading between people at nearby cities.
The problem is not travel; the problem is getting everyone involved, not just crypto geeks.
Provided all clients support DNSSEC, which probably won't happen for several years.
Then we could introduce the concept of a public notary, which would be a DNSSEC enabled server that will vouch for the server.
For example... we could eliminate all trusted CA certificates, and replace them with trusted notary certificates.
The rules regarding notaries issuing certificates for domain names or any subdomain could be something like: (1) any notary issued certificate must be valid for no longer than 1 hour.
(2) a notary certificate can only be issued after comparing the details of the CSR presented, with a valid DNSSEC distributed public key, and finding the Subject name and public key details identical.
(3) a certificate for an e-mail address (e.g. for S/MIME), for code signing, or AD/LDAP Directory authentication, may be issued for a longer period, but must not be valid after the current expiration date of the domain name, and for issuance, SSL keys must be distributed under a DNSSEC validated subdomain that [1] identifies the desired subject of the certificate, [2] identifies the desired duration of the certificate, and [3] identifies the public key, etc.... all CSR details must be mirrored in the DNS record, and all signed using DNSSEC
No, no, no... You completely misread that. You're only allowed to move your mouse pointer 2000 pixels per window, per day. Licensure of pixels is then 100 "points" per 1000 above that.
Hm... maybe we should try a car analogy
You buy a truck with a twin engine turbodiesel and two fuel tanks.
Next you buy a 50' trailer with a compartment system that is sold based on how many engine sockets you have, so you pay your two $4500 "Engine licenses" plus a $5,000 door handle license for $14,000 total for the compartment system, plus a total annual maintenance contract of 23%, or $3,220 a year, which guarantees you the a free entitlement to company's latest models as they come out, every 3 years.
The compartment system you licensed is essentially a series of boxes that lets you divide your trailer however you see fit.
Then a couple years later, they come out with a compartment system V2.
You are entitled to a free upgrade as promised, BUT, before they give it to you, they hand you a new EULA, and say you won't get your promised upgrade unless you "sign this", which contains a clause stipulating For each engine license, you are only entitled to 20000 pounds of trailer storage (cores) AND 1000 cubic feet of trailer storage.
Since your truck is normally used to tow a payload of 3000 cubic feet, you will have to buy an additional engine license. costing you another $4500 and another $1035 a year, to utilize your "free" upgrade.
Will have a per-CPU "Window size" entitlement.
For every CPU, you can have 2000x2000 pixels worth of open windows.
To determine if you are in compliance, add up the widthXheight pixel sizes of the open windows for all running applications (whether minimized or not), if the number of vPixels used exceeds your entitlement, then you are not in compliance and must buy additional OS licenses.
This applies whether you paid in advance for yearly free upgrades or not.
If this is a problem for you, we recommend calling your application vendors to change the size of your windows. Once they are right-sized, there should be no performance impact, and you won't notice at all. (P.S. enjoy your 50 pixel by 50 pixel notepad++ window)
[Just kidding.]
To minimize the amount of time spent mowing, get someone else to do it, e.g. hire some neighbor's kid.
To minimize the amount of resources spent mowing, forego mowing entirely.
Does not have LM or auto provisioning.
XenServer free edition has XenMotion.
Oddly, it doesn't have Live snapshotting (which is free in VMware)
It seems like the virtualization vendors are all making the mistake of charging money for new features they had to develop, out of proportion to their place within the software.
More enterprises need snapshotting mechanisms to take backups (IMO) than need live migration. The features everyone needs should have the lowest cost, to encourage users with basic needs to adopt free edition, and pay up, when they start to need more.
I've seen marketing material for RHEV-M which suggests a vCenter-like set of capabilities, but no hands on to *really* vouch for or against it.
RHEV lost a lot of respect from me, when I learned about certain "limitations" that they weren't very forward with.
Last I checked, You have to shutdown a VM to take a snapshot.
VLAN support in a later release, maybe
If your RHEV-M server goes down, auto-restart-VMS capability also goes down
No graphical management if RHEV-M server goes down; no ability to connect with a management client directly to individual Nodes.
No equivalent to storage vMotion
The list of serious limitations goes on and on. XenServer sounds better to me.
"no, we won't honor the contract, you'll have to buy more product," and B) stupid, as the licensing model directly undermines one of VMware's principal advantages.
They did this once before, at the last major release when they introduced Enterprise+.
They had been publicizing new advanced features that would be in vSphere for many months.
Then, when the release actually came out, they introduced a new license tier "Enterprise+" which would get all the new features.
So, even though the upgrade to vSphere was provided under SnS, Enterprise customers only got minor, incremental improvements. None of the advanced features introduced in the upgrade that they had paid for maintenance in order to obtain!
I would not be surprised if one day vCenter ends up managing Xen and/or KVM the same way it will manage ESXi./em>
I would be surprised. If VMware were to add this ability to vCenter, it would increase the value of their competitors' hypervisors... now suddenly you wouldn't even need to change management tools or admin skillsets to migrate to the competitors' platform....
The Virtual reality check product has published whitepapers with detailed performance comparisons between VMware, Hyper-V, and XenServer. To summarize them all, they show XenServer has much better performance than VMware for VDI [XenDesktop]. Basically, faster, and you can therefore consolidate more VMs per host than with VMware.