It will suffer specifically when you put multiple number-crunching VMs on the same physical host,
not specifically because there is a "virtualization overhead", but because
when you try to consolidate workloads with heavy demand for a limited resource,
there will be contention; on the dedicated host it doesn't have to share, so there
will be more CPU time available that is not scheduled for other number-crunchers.
You can avoid the problem with proper capacity planning
'cause if you knock it offline by accident, your easiest tool with which to bring it back online is gone?
However, your vCenter is much more likely to fail hard if you place it on a separate physical server.
Physical servers fail all the time. By virtualizing vCenter, what you accomplish is that you protect it using HA; if one of your VM hosts fails, you can have two hosts standing by to start the VM.
You can also use HA to protect the SQL server that vCenter requires to work, and you can establish DRS rules to indicate which host(s) you prefer those two to live on.
If some operator erroneously powers this off, or mucks it up, there is still an easily available tool, the VPX Client; vSphere Client, can be used to connect directly to a host and start the VM.
You can also have a separate physical host with the vSphere CLI installed, to allow you to power on a VM that way.
It does make sense to have perhaps 2 cheap physical servers to run such things, and maybe double as a DNS or AD server, to avoid circular dependency problems with DNS or authentication; these would also be the servers your backup tools should be installed on, to facilitate recovery of VM(s) (including the vCenter VM) from backup.
That's fine and valid, but vCenter itself should be clustered.
Unless you are paying through the nose for vCenter Heartbeat,
running it as a VM is the best common supported practice for accomplishing that.
It's just fine to do that. However, a few things are important:
(1) You need at least 1 point of access to the environment at all times -- e.g. You need a "backup way" in that works and gives you full control, even if for some reason no VMs are running (worst case).
(2) You need to ensure there are no circular dependencies -- if all VMs are down, your environment is still sufficiently operational for you to correct any issue. An example of a circular dependency would be that you have virtualized a VPN server/firewall required to gain access to your ESXi hosts; yeah, it's secure from an integrity standpoint, but what about secure from an availability standpoint, and secure from a disaster recovery standpoint?
(3) If you have virtualized your active directory servers, you should ensure you have a backup plan that will allow you to authenticate to all your hypervisors, virtualization management, and network infrastructure/out of band management, EVEN if AD is crippled and offline.
(4) If you have virtualized DNS servers, you should have at least 2 DNS servers that will probably not fail at the same time,
because you have eliminated as many common failure modes as possible.
(a) Redundant DNS servers should not be on the same server. Ideally you would have two sites, with separate virtualization clusters, separate storage, and 2 redundant DNS servers at each site.
(b) Redundant DNS servers should not be stored on the same SAN, or the same local storage medium.
(c) If your Hypervisor requires a DNS lookup to gain access to the SAN, you should have a backup plan to get
your environment back up when all DNS servers are down. Each virtualized DNS server should be stored either on separate DAS storage, or on shared storage that can be accessed even when DNS is unavailable.
It is just FINE to virtualize them; and shared disk is not an issue in any whatsoever. However, your consolidation effort will likely not be successful if done haphazardly, correct sizing, design, and capacity planning is important; choosing good hardware is important, not just "buying whatever server is cheapest and seems to have enough memory and large enough amount of disk space", because there are a LOT of details that matter, especially regarding CPU, CPU chipset, and NIC capabilities, DIMM/RAM configurations and speed, hard drive configurations, RPMs, array cache, etc. You have to spend more money on storage to virtualize a busy database, than if you were just virtualizing a server with very low or highly sequential IOPS workloads, and thinking the plan through is important.
Busy databases are often placed on shared disk, it's not a poor practice; databases go on SANs, it's standard practice for large enterprises; properly designed SAS-attached, fibre-channel attached, iSCSI, or FCoE attached SAN infrastructures are just as performant as direct-attached storage.
What often gets SMBs in trouble with busy databases is using RAID5 on SATA drives, and not allocating specific spindles to specific workloads when necessary.
Don't use RAID5 for busy databases. Don't dare use RAID6 for any database. Don't use SATA drives for busy databases. In fact, if you are serious about consolidation,
don't use RAID5 or RAID6 period.
Enterprise level SAS SSDs are OK. RAID10 with plenty of cache is OK, RAID-DP with plenty of cache is OK.
Busy databases are part of the "20%".
Consolidating them is good, to keep your infrastructure simpler, and provide the many advantages
of virtualization, but straight up hardware cost is not a benefit in this case --
you would not be consolidating if all your other workloads incurred just as much expense to consolidate.
You can save money on operational expenses of your databases, but you should expect to spend about as much
extra into your hardware to add that workload as you would to deploy the workload physically.
Yeah, and BT uploaders and seeders are vTerrorists or "Virtual" Terrorists, who should be jailed
immediately upon identification, for life, without trial, as enemy vCombatants.
if you have that level of engineering expertise, just skip the whole "steal nuke" part and build your own with stolen enriched Plutonium.
I assume defeating the security component would be easier and less costly for a bad actor to accomplish than to design and construct the whole thing from raw materials.
Yes that was considered all the way back in 1945, which is why nukes back then had multiple interlocks to prevent such a thing.
You mean before the mass production of many nukes became a priority, and some brilliant manager probably decided that eliminating redundancy would let them produce more nukes on their budget, and software automation of ICBM launch would reduce the amount of manpower required to maintain readiness?
Now, point out to me where the possibility exists that a faulty electrical component in the unit's electronics could detonate the bomb?
Undetected non-simultaneous failures of multiple different electronic components.
Not really. The starter switch in the ignition key switch, on my car at least, has separate wires going to power the ignition, fuel pump, and the starter solenoid.
There are a lot of cars nowadays, you can start with a push of a button in the car, or on a keyfob remote.
"Starting when in gear" is not mechanically prevented, it is electrically prevented.
There are Electric-Unleaded Hybrids now that have a continuously varying transmission, so there's no such thing as "In gear"; Drive-by-wire systems, where Brakes, Throttle, and all the settings are controlled by computer.
Just like not all cars have the same design, not all nukes have the same design.
Since your DRM'd computer is still going to ask you to prove that your copy of Windows is genuine every couple of weeks
OEM systems are often pre-activated with some BIOS code and a special OEM customization.
Legitimate installs of windows won't ask you to prove it's genuine every couple of weeks if you don't make changes to the hardware every couple of weeks.
There are plenty of Microsoft Certified Professionals out there that work in a computer store
Those certifications are skills accreditations based on passing a test. Just because the professionals doing the work carry a personal Microsoft certification, does not mean that Microsoft certifies or stands behind their work product or controls the results in any way whatsoever.
Just because the work is done by a MCP does not mean the actual work is certified by MS; the MCP is not employed by Microsoft, so Microsoft does not certify all their work, they only accredit their ability to pass certain tests.
Now presumably, they are certifying the work done by their stores in some way, like most businesses do.
There are plenty of professionals who have paper Microsoft creds that are not really qualified, and could not get (or keep) a job at a M$ store doing the work.
You can't just rip out the pass-coded detonator and wire all the blasting caps on the explosives together, to get the explosive "lens" in an implosion type weapon requires some blasting caps go off before others to take the core super-critical.If that timing is off all you get is a dirty bomb
No, I certainly could not, but I am sure there are people that exist who would be able to defeat the pass-code protection or reset the code to a known quantity, or reverse-engineer the detonator and engineer their own, given a sufficient amount of time. There is also someone out there responsible for doing the manual work required to SET that passcode, and I wouldn't be too surprised if all units used the same passcode, and it was something simple like 000000.
Accidentally entering the passcode might not be too likely... but did you consider the possibility that a faulty electrical component in the unit's electronics or software results in it arming the device when it's not supposed to be armed, or acts as if a passcode has been entered and starts a countdown when no human has instructed it to arm or detonate?
This is done not only for safety, it prevents a saboteur from detonating a warhead. Worrying about a nuke accidentally going off is like me worrying about my car accidentally starting and driving over a little kid while I sit here in my house.
It's conceivable a short circuit and software bug in your computer-controlled ignition system
could result in your engine starting.
If your parking break wasn't working for some reason, not in use, or controlled by a drive-by-wire system which also failed, it's possible your car would then lurch forward running over someone.
As small as the probability is, it's still far from zero, it's still a potential concern.
Even if a car DOES do that, it's not that big a risk. And only a person standing directly ahead of the car is really at risk.
An accidental nuke detonation is a MUCH larger catastrophe.
If you protest you get your way, even when it doesn't make fiscal sense.
You assume it doesn't make fiscal sense, BUT:
Who says it doesn't make fiscal sense what they are doing?
Surely there are some tax incentives and other benefits for Apple to make this choice.
Electricity has been getting more expensive, and generating your own helps make costs more predictable,
and less influenced by outside elements, especially if you anticipate the market price will be increasing in the future,
AND there is a concern of possible "carbon taxes" being implemented in the future.
Apple has a surplus of cash, it's not as if they can't fiscally afford the 100% renewable thing,
especially if it helps them maintain the corporate image they want to maintain,
and reduces some risks; AND creates another argument Why users should utilize iCloud:
It's GREENER than using your own spinning rust, because your files will be stored on a
system that utilizes 100% Green energy. Win win win for Apple.
2.5 times as much generated as put into production is still infinitely better than "burn a load of coal" or "produce a load of nuclear waste".
"Load of Nuclear waste" is an artificial thing created by the ban against recycling nuclear wastes,
out of concern that the plutonium produced by said recycling might fall into the wrong hands.
Nuclear power generation properly implemented is much more efficient than either Coal fired plants,
OR manufacture of solar cells, and produces only Tiny amounts of waste, which can (and must) be 100% contained; whereas the manufacturing process and the burning of Coal EACH produce massive amounts of highly toxic waste, in the form of heavy metals, MOST of which are released directly into the air.
That's good to hear, but unless it generates more energy than the plant needs, to the point where it exceeds the plant's requirements by enough to recover the energy used to make it
It probably will. If they intend to be 100% renewable; there must be some spare capacity to cope with upgrades and peak usage.
They presumably also need backup power sources, such as a grid backup, or emergency generators.
So to be "100% renewable" they'll need to estimate their annual usage of that, to make sure they will generate
the amount of extra power to recover that.
Why do we care about limits on this stuff, in terms of numbers? I can totally understand saying "Let's get rid of these things, period, they are too dangerous."
Statistically.... every weapon is a risk. The number of weapons stolen and placed in the wrong hands required to cause massive loss of life: ONE.
The number of insane technicians required to detonate a unit they're supposed to be maintaining or dismantling: ONE.
The number of weapons required to malfunction to cause serious problems: ONE.
Even if it's a 0.0000000000000000000000000000000001% probability; the more weapons you have in more places, the more likely something goes wrong.
Each weapon requires maintenance which costs money -- they don't last forever,
A is a word, so I just use "a a a a" and it is as secure as any other 4 random words
Statistically, we can say that the probability you selected "a a a a" through a random process
from all common words is microscopic.
Yeah, if you repeat the same word 3 times, or take all 4 words from the same page of a dictionary,
that's easy to crack, if the attacker anticipates that you might do that.
3) Even if we assume that humans can create entropic passwords, it's difficult for a human to estimate that entropy. What happens when the password entropy checker rejects "This shit tastes like chicken"? How does the human know how to make that password more acceptable?
"Your passphrase-style secret is unacceptably weak. Please make one of the following changes to improve its strength:"
Revise your passphrase so that it contains additional tokens which are not valid words or valid simple transformations of words, at least one capitalization error, and at least one spelling error, example: "this %@^* taStes like chiken."
Revise your passphrase so that it contains at least one noun, at least two pronouns, at least two adjectives, at least one adverb or gerund, at least one verb, and a comma splice or at least two direct objects: "This bloody shit almost tastes like your homemade chicken noodle soup."
Revise your passphrase so that it contains multiple capitalization, punctuation, grammatical errors, and spelling anomolies, example: "thiSs heR shi-t tAste like ChicK en"
Revise your passphrase so that it does not match a sentence found in any work of literature or public writing.
Revise your passphrase so that it contains additional words which are not duplicated
Revise your sentence-based passphrase so that it contains an additional statement or idea.
Revise your passphrase so that it contains additional adjectives and adverbs.
but I do know many dictionary cracking programs implement mixing of words on the list - meaning "correct horse staple battery" will be cracked in SECONDS, not centuries.
There are approximately 6000 common words in the English language,
so if you just pick 4 random words, there are
6000 ^ 4 = 1296000000000000 possibilities
If you pick a truly random 8-character password, there are:
140 ^ 7 = 1054135040000000 possible choices.
Even at 1,000,000 crack attempts per second, it still takes on average 16 years to crack
a password formulated using either method.
way.
It does make sense... sort of... the name "Persian Gulf" is the internationally recognized name.
"Arabian Gulf" is a local preference that does not have much acceptance.
When two banks offer credit at different rates, is that a "conflict of interest?"
No. But it is if one bank offers credit at a certain rate, and another bank offers interest earnings to
depositors at a higher APR rate than the other bank charges for credit.
Slashdot Mirror
It will suffer specifically when you put multiple number-crunching VMs on the same physical host, not specifically because there is a "virtualization overhead", but because when you try to consolidate workloads with heavy demand for a limited resource, there will be contention; on the dedicated host it doesn't have to share, so there will be more CPU time available that is not scheduled for other number-crunchers.
You can avoid the problem with proper capacity planning
The only limitations for x86 virtualization are proprietary cards...
VMDirectPath. (Obviously with the caveat of lost vMotion capability)
'cause if you knock it offline by accident, your easiest tool with which to bring it back online is gone?
However, your vCenter is much more likely to fail hard if you place it on a separate physical server.
Physical servers fail all the time. By virtualizing vCenter, what you accomplish is that you protect it using HA; if one of your VM hosts fails, you can have two hosts standing by to start the VM.
You can also use HA to protect the SQL server that vCenter requires to work, and you can establish DRS rules to indicate which host(s) you prefer those two to live on.
If some operator erroneously powers this off, or mucks it up, there is still an easily available tool, the VPX Client; vSphere Client, can be used to connect directly to a host and start the VM.
You can also have a separate physical host with the vSphere CLI installed, to allow you to power on a VM that way. It does make sense to have perhaps 2 cheap physical servers to run such things, and maybe double as a DNS or AD server, to avoid circular dependency problems with DNS or authentication; these would also be the servers your backup tools should be installed on, to facilitate recovery of VM(s) (including the vCenter VM) from backup.
That's fine and valid, but vCenter itself should be clustered. Unless you are paying through the nose for vCenter Heartbeat, running it as a VM is the best common supported practice for accomplishing that.
It's just fine to do that. However, a few things are important:
(1) You need at least 1 point of access to the environment at all times -- e.g. You need a "backup way" in that works and gives you full control, even if for some reason no VMs are running (worst case).
(2) You need to ensure there are no circular dependencies -- if all VMs are down, your environment is still sufficiently operational for you to correct any issue. An example of a circular dependency would be that you have virtualized a VPN server/firewall required to gain access to your ESXi hosts; yeah, it's secure from an integrity standpoint, but what about secure from an availability standpoint, and secure from a disaster recovery standpoint?
(3) If you have virtualized your active directory servers, you should ensure you have a backup plan that will allow you to authenticate to all your hypervisors, virtualization management, and network infrastructure/out of band management, EVEN if AD is crippled and offline.
(4) If you have virtualized DNS servers, you should have at least 2 DNS servers that will probably not fail at the same time, because you have eliminated as many common failure modes as possible.
(a) Redundant DNS servers should not be on the same server. Ideally you would have two sites, with separate virtualization clusters, separate storage, and 2 redundant DNS servers at each site.
(b) Redundant DNS servers should not be stored on the same SAN, or the same local storage medium.
(c) If your Hypervisor requires a DNS lookup to gain access to the SAN, you should have a backup plan to get your environment back up when all DNS servers are down. Each virtualized DNS server should be stored either on separate DAS storage, or on shared storage that can be accessed even when DNS is unavailable.
Shared disk does not make I/O happy.
It is just FINE to virtualize them; and shared disk is not an issue in any whatsoever. However, your consolidation effort will likely not be successful if done haphazardly, correct sizing, design, and capacity planning is important; choosing good hardware is important, not just "buying whatever server is cheapest and seems to have enough memory and large enough amount of disk space", because there are a LOT of details that matter, especially regarding CPU, CPU chipset, and NIC capabilities, DIMM/RAM configurations and speed, hard drive configurations, RPMs, array cache, etc. You have to spend more money on storage to virtualize a busy database, than if you were just virtualizing a server with very low or highly sequential IOPS workloads, and thinking the plan through is important.
Busy databases are often placed on shared disk, it's not a poor practice; databases go on SANs, it's standard practice for large enterprises; properly designed SAS-attached, fibre-channel attached, iSCSI, or FCoE attached SAN infrastructures are just as performant as direct-attached storage.
What often gets SMBs in trouble with busy databases is using RAID5 on SATA drives, and not allocating specific spindles to specific workloads when necessary.
Don't use RAID5 for busy databases. Don't dare use RAID6 for any database.
Don't use SATA drives for busy databases.
In fact, if you are serious about consolidation, don't use RAID5 or RAID6 period.
Enterprise level SAS SSDs are OK. RAID10 with plenty of cache is OK, RAID-DP with plenty of cache is OK.
Busy databases are part of the "20%". Consolidating them is good, to keep your infrastructure simpler, and provide the many advantages of virtualization, but straight up hardware cost is not a benefit in this case -- you would not be consolidating if all your other workloads incurred just as much expense to consolidate.
You can save money on operational expenses of your databases, but you should expect to spend about as much extra into your hardware to add that workload as you would to deploy the workload physically.
Bittorrent = Terrorism.
Yeah, and BT uploaders and seeders are vTerrorists or "Virtual" Terrorists, who should be jailed immediately upon identification, for life, without trial, as enemy vCombatants.
I didn't realize Cisco had gotten into the drug manufacturing business.
But then maybe the folks paying full price for Cisco's latest gear need meds; in that case, they should be manufacturing Aripiprazole.
if you have that level of engineering expertise, just skip the whole "steal nuke" part and build your own with stolen enriched Plutonium.
I assume defeating the security component would be easier and less costly for a bad actor to accomplish than to design and construct the whole thing from raw materials.
Yes that was considered all the way back in 1945, which is why nukes back then had multiple interlocks to prevent such a thing.
You mean before the mass production of many nukes became a priority, and some brilliant manager probably decided that eliminating redundancy would let them produce more nukes on their budget, and software automation of ICBM launch would reduce the amount of manpower required to maintain readiness?
Now, point out to me where the possibility exists that a faulty electrical component in the unit's electronics could detonate the bomb?
Undetected non-simultaneous failures of multiple different electronic components.
Not really. The starter switch in the ignition key switch, on my car at least, has separate wires going to power the ignition, fuel pump, and the starter solenoid.
There are a lot of cars nowadays, you can start with a push of a button in the car, or on a keyfob remote. "Starting when in gear" is not mechanically prevented, it is electrically prevented.
There are Electric-Unleaded Hybrids now that have a continuously varying transmission, so there's no such thing as "In gear"; Drive-by-wire systems, where Brakes, Throttle, and all the settings are controlled by computer.
Just like not all cars have the same design, not all nukes have the same design.
Since your DRM'd computer is still going to ask you to prove that your copy of Windows is genuine every couple of weeks
OEM systems are often pre-activated with some BIOS code and a special OEM customization.
Legitimate installs of windows won't ask you to prove it's genuine every couple of weeks if you don't make changes to the hardware every couple of weeks.
There are plenty of Microsoft Certified Professionals out there that work in a computer store
Those certifications are skills accreditations based on passing a test. Just because the professionals doing the work carry a personal Microsoft certification, does not mean that Microsoft certifies or stands behind their work product or controls the results in any way whatsoever.
Just because the work is done by a MCP does not mean the actual work is certified by MS; the MCP is not employed by Microsoft, so Microsoft does not certify all their work, they only accredit their ability to pass certain tests.
Now presumably, they are certifying the work done by their stores in some way, like most businesses do.
There are plenty of professionals who have paper Microsoft creds that are not really qualified, and could not get (or keep) a job at a M$ store doing the work.
You can't just rip out the pass-coded detonator and wire all the blasting caps on the explosives together, to get the explosive "lens" in an implosion type weapon requires some blasting caps go off before others to take the core super-critical.If that timing is off all you get is a dirty bomb
No, I certainly could not, but I am sure there are people that exist who would be able to defeat the pass-code protection or reset the code to a known quantity, or reverse-engineer the detonator and engineer their own, given a sufficient amount of time. There is also someone out there responsible for doing the manual work required to SET that passcode, and I wouldn't be too surprised if all units used the same passcode, and it was something simple like 000000.
Accidentally entering the passcode might not be too likely... but did you consider the possibility that a faulty electrical component in the unit's electronics or software results in it arming the device when it's not supposed to be armed, or acts as if a passcode has been entered and starts a countdown when no human has instructed it to arm or detonate?
This is done not only for safety, it prevents a saboteur from detonating a warhead. Worrying about a nuke accidentally going off is like me worrying about my car accidentally starting and driving over a little kid while I sit here in my house.
It's conceivable a short circuit and software bug in your computer-controlled ignition system could result in your engine starting.
If your parking break wasn't working for some reason, not in use, or controlled by a drive-by-wire system which also failed, it's possible your car would then lurch forward running over someone.
As small as the probability is, it's still far from zero, it's still a potential concern. Even if a car DOES do that, it's not that big a risk. And only a person standing directly ahead of the car is really at risk.
An accidental nuke detonation is a MUCH larger catastrophe.
If you protest you get your way, even when it doesn't make fiscal sense.
You assume it doesn't make fiscal sense, BUT: Who says it doesn't make fiscal sense what they are doing?
Surely there are some tax incentives and other benefits for Apple to make this choice.
Electricity has been getting more expensive, and generating your own helps make costs more predictable, and less influenced by outside elements, especially if you anticipate the market price will be increasing in the future, AND there is a concern of possible "carbon taxes" being implemented in the future.
Apple has a surplus of cash, it's not as if they can't fiscally afford the 100% renewable thing, especially if it helps them maintain the corporate image they want to maintain, and reduces some risks; AND creates another argument Why users should utilize iCloud: It's GREENER than using your own spinning rust, because your files will be stored on a system that utilizes 100% Green energy. Win win win for Apple.
2.5 times as much generated as put into production is still infinitely better than "burn a load of coal" or "produce a load of nuclear waste".
"Load of Nuclear waste" is an artificial thing created by the ban against recycling nuclear wastes, out of concern that the plutonium produced by said recycling might fall into the wrong hands.
Nuclear power generation properly implemented is much more efficient than either Coal fired plants, OR manufacture of solar cells, and produces only Tiny amounts of waste, which can (and must) be 100% contained; whereas the manufacturing process and the burning of Coal EACH produce massive amounts of highly toxic waste, in the form of heavy metals, MOST of which are released directly into the air.
That's good to hear, but unless it generates more energy than the plant needs, to the point where it exceeds the plant's requirements by enough to recover the energy used to make it
It probably will. If they intend to be 100% renewable; there must be some spare capacity to cope with upgrades and peak usage.
They presumably also need backup power sources, such as a grid backup, or emergency generators.
So to be "100% renewable" they'll need to estimate their annual usage of that, to make sure they will generate the amount of extra power to recover that.
Why do we care about limits on this stuff, in terms of numbers? I can totally understand saying "Let's get rid of these things, period, they are too dangerous."
Statistically.... every weapon is a risk. The number of weapons stolen and placed in the wrong hands required to cause massive loss of life: ONE. The number of insane technicians required to detonate a unit they're supposed to be maintaining or dismantling: ONE.
The number of weapons required to malfunction to cause serious problems: ONE. Even if it's a 0.0000000000000000000000000000000001% probability; the more weapons you have in more places, the more likely something goes wrong.
Each weapon requires maintenance which costs money -- they don't last forever,
A is a word, so I just use "a a a a" and it is as secure as any other 4 random words
Statistically, we can say that the probability you selected "a a a a" through a random process from all common words is microscopic.
Yeah, if you repeat the same word 3 times, or take all 4 words from the same page of a dictionary, that's easy to crack, if the attacker anticipates that you might do that.
Try a billion attempts per second with a single GPU. A maximum of 15 days.
A single GPU cannot get as high as 1000 PBKDF-2 or SCRYPT hashes per second, let alone a billion.
That would be an indication that Apple is now leading the industry, and Microsoft is just a follower.....
3) Even if we assume that humans can create entropic passwords, it's difficult for a human to estimate that entropy. What happens when the password entropy checker rejects "This shit tastes like chicken"? How does the human know how to make that password more acceptable?
"Your passphrase-style secret is unacceptably weak. Please make one of the following changes to improve its strength:"
but I do know many dictionary cracking programs implement mixing of words on the list - meaning "correct horse staple battery" will be cracked in SECONDS, not centuries.
There are approximately 6000 common words in the English language, so if you just pick 4 random words, there are
6000 ^ 4 = 1296000000000000 possibilities
If you pick a truly random 8-character password, there are:
140 ^ 7 = 1054135040000000 possible choices.
Even at 1,000,000 crack attempts per second, it still takes on average 16 years to crack a password formulated using either method. way.
Apparently some Arabs want it renamed the "Arabian Gulf."
Who cares... I want the Gulf of Mexico to be renamed to The Gulf of Texas. Some Arabs wanting something named does not make it authoritative.
The International Hydrographic Organization calls it Persian gulf. Persian gulf is the authoritative name.
And the name doesn't change just because a few folks are dismayed by it.
It does make sense... sort of... the name "Persian Gulf" is the internationally recognized name. "Arabian Gulf" is a local preference that does not have much acceptance.
[AP][er][as][ib][ia][na]n? Gulf
APerasibianan Gulf
Or just "* Gulf" for short; or hell just make "Gulf" the label.
Did they also adjust Siri's answer to other questions such as "What tablet is the best?" and "How do I jailbreak the iphone?"
When two banks offer credit at different rates, is that a "conflict of interest?"
No. But it is if one bank offers credit at a certain rate, and another bank offers interest earnings to depositors at a higher APR rate than the other bank charges for credit.