Can't take a hard drive built with LVM and migrate it to another machine with the same name -- i.e. a common operation after a hardware upgrade.
I do this all the time with VMs with absolutely no config changes (i.e., it just works).
Now, if you have a system with a LVM group/volume name of foo/bar, then yes, you can't just add disks that already have a foo/bar group/volume to the machine and have it work. If there is no name collision, though, it just works. It's how I upgraded a really old Fedora install. I renamed the old LVM group, then disconnected the old hard drives, added an SSD, installed the latest Fedora on the SSD, and plugged the old drives back in to allow me to copy my customizations to the new drive.
I suppose it is possible to rename the logical volume, but this is fairly arcane
lvrename VolumeGroupName OldVolumeName NewVolumeName is arcane? I can tell you don't do much with LVM, since lvrename is one of the least twisted of all the LVM commands.
I think Windows actually over reports the size of that due to all the linking in there.
According to your link, it's the other way around, in that every bit of the OS is in the WinSxS directory, and the versions in other directories are links.
But, the real point is that it grows large because Microsoft has determined two things:
their patches aren't very good quality, and might need to be uninstalled regularly enough that 4-5 old versions of the same file are required to be kept around
people are too stupid to be able to find original media, so every single feature from the OS is placed into WinSxS, even it if is not "installed" and available, so just in case you might need to have the entire OS displayed in Japanese at some point in the future, those files are taking up space on your hard drive
What this also leads to is that every OS patch applies to every Windows system (Vista and beyond), because even if you don't have a feature "installed", they need to add the patch to the repository on your hard drive in case you want to install that feature. Basically, it is like a Linux install that has the entire repository from the distribution—including every version of every package that had ever been released—stored on the local hard drive.
It is insanely easy for government to get an under-performing contractor kicked off the job.
An individual, maybe, but not a contractor who works for one of the bigger companies.
Likewise, if you view the "contractor" as the "entity that holds a contract", it's almost impossible to get that entity dumped within the period of the contract, and lock-in sometimes makes it nearly impossible to award the contract to a new entity. For example, if company A provides computing services to the government, it's possible that moving those services to company B would be more expensive than dealing with the crappy performance from company A.
A dell R815 with 2 twelve-core AMD processors (although they were not bulldozer ones) 256GB of ram, and a pair of hard drives was $8k cheaper than a similarly configured Dell R810 with 2 10-core Intel Processors when we ordered a few weeks ago.
The Westmere-EX CPUs on the Dell R810 are recently released, and as such are very pricey. They are also much, much faster than any other Intel or AMD chip on a per-clock basis. Because the E7-88xx Xeons have nearly twice the cache (30MB "smart" vs. 24MB total L2 plus L3), are hyper-threaded, and run faster clock-for-clock, a heavily parallel task will likely finish faster on a single CPU Westmere-EX than on a dual CPU Magny-Cours.
Because of this, the R810 is a much, much more powerful system than the R815, so it only makes sense that it's more expensive, although part of it is paying for the bleeding edge of Intel. In the more normal realm, you can get a pair of 2.4GHz 6-core E5645s for less than the price of a single 2.2GHz Opteron 6174. That's 12 cores and 24 threads vs. 12 cores, and overall more performance.
Because running a device at 40-50 degrees Celsius below the Tmax will make it last longer than running it at 10 degrees below the Tmax. Heat eventually breaks down modern semiconductors.
Also, you want to avoid thermal processor throttling, which does not occur at an exact temperature. Giving yourself a lot of margin for error avoids that.
Last, you can get close to the same amount of cooling for about $40, which I consider a reasonable investment to help extend the life of a $300-600 processor.
This is a good thing, the B53 was a last ditch weapon intended to take out the hardened bunkers of the Soviet leadership, except it was air burst which is a highly, highly ineffective was to take out a bunker.
The B53 had a reinforced nose that (along with parachutes) allowed it to be detonated on the ground, which should have been fairly effective.
But, I'm getting the mental picture of such a bomb lying there while the bomb squad attempts to disarm it.
As to your numbers - the prices for drives didn't go up by 50-90%, they went up by 15-30%.
From the fucking story:
Speaking of price increases, we have seen a spike of 15% to 30% in the cost of some models over the last 72 hours.
As many others have pointed out, the story is wrong.
Drives that were $100 (free shipping) on Monday are now $148 (shipping up to $8). That's 48%. Drives that were $120 on Monday are now $190. That's nearly 60%, and from the comments, that's not the biggest jump.
God, the misconceptions in basic economics on this site are just overwhelming.
Yes, and you are spewing most of them, because you don't realize that selling 75 drives at $150 makes the manufacturer more money than selling 100 drives at $100, and that's exactly what is happening right now, because every hard drive manufactured is going to be sold. Even with this jump, hard drives are nowhere near the price point where people will cut down purchases so that inventory sits in the warehouse longer than it currently does. And, I guarantee you that when the flooded plant comes back online and drives it manufactures are actually sitting in retail stores, they will be 5-20% more expensive than the same drive was this past Monday, because people will have gotten used to paying $160 for a hard drive that fits their needs, and won't quite remember whether it was $100 or $110 before the big price jump.
It read pretty clearly to me, 3 blades - 3 blades should serve quite a few job seekers.
Maybe, maybe not.
If the system had 30 blades running it with the crappy performance, then 3 more won't do much. If it had 3 blades before, then maybe 3 more will help, unless, of course, the poor performance is not caused by lack of CPU resources. If it's because of disk or network issues, throwing more CPUs at it will probably make it worse. Or, perhaps the individual blades are underpowered.
there is real actual SCARCITY here, because the plants are not producing enough supply to satisfy the demand at the previous low prices.
Oh, really? You have access to the full inventory and shipping manifests from every hard drive manufacturer on the planet, and you can verify that the numbers as of right now are much lower than a month ago?
The problem is that you seem to assume that companies aren't going to take advantage of the loss of 25% of the hard drive manufacturing capacity to increase prices 50-90% right now despite any real scarcity (which may never exist), and then lower prices by 25% a few weeks after the plant comes back on line, then maybe drop prices another 25% a month or two later. The result will be that their profits for the next year or so will be a lot more, because they will be fast to raise and slow to lower prices, and hard drive demand is fairly constant.
The resellers and retailers are even more slimy, as it takes 3-4 months for a hard drive to make it from the manufacturer to the end-user, so right now there are 3-4 months of hard drive supply either in warehouses or on boats. If the plant is out of commission for a month, then prices should go up in January, and come back down before March.
What I'm wondering is how the hard drive manufacturers figured out how to cause the flood, 'cause it's a lot less suspicious than a fire.
based on supercar standards, this is pretty darn awesome.
Not really. Although the torque is lower at 638 lb-ft, a Corvette ZR1 will get about the same highway mileage and over 50% more horsepower (638 vs. 400).
Since torque is often based solely on the transmission (my car has a 350 lb-ft spec, while the same engine gives 420 lb-ft when married to a different transmission), I suspect that Chevrolet could get the same 960 lb-ft of torque if they chose to, but that it makes no difference to real-world performance.
So - I'm wondering why, exactly, do people want to do RAID with SSD? There are really only two reasons (that I'm aware of) for a RAID.
And both are as valid for SSD as they are for spinning disks.
RAID-0 can turn SSDs from fast to insane (if you have the controller bandwidth). Any of the data-protection RAID levels will help if your drive-with-really-new-and-somewhat-untested-technology dies an untimely death.
TRIM doesn't work with RAID, period. Most drives can work with RAID 0 or 1.
I just installed a pair of SSDs in RAID-1 using Fedora 15. I had searched far and wide to see if TRIM was supported, and didn't find anything conclusive, so I installed anyway, since I'm only using 16GB out of the 64GB drive (which means that even non-TRIM-aware wear-leveling would last 4 times as long). After I had installed, I did some more searching, and somewhere I found info that said the 3.0 kernels (which Fedora 15 uses, although renumbered to keep some apps from breaking) supported it. I didn't bookmark it, but I think it was part of the kernel mailing list.
Based on the fact that/sys/block/[device]/queue/discard_granularity contains 512 for every device in the stack (LVM/dm -> md -> sd[ab]) and there are no warnings at mount time with ext4 using the "discard" option, I believe it. Also, for any device not on top of an SSD, "discard_granularity" is 0 and you get warnings at mount time if you try to use the "discard" option.
And there's stuff you can't do easily with physical servers that you can with VMs. Take a system snapshot, change something or test something, then roll back to the snapshot.
One of the other cool things is that you can pull the plug on the VM (i.e., hard power off) without any chance of damage to physical hardware but still see how your application reacts.
I also found that prolonged disconnection from the disk drive doesn't make much difference to most operating systems (when I had a 2-hour SAN outage). This was a shock, as when the SAN came back up, the VMs resumed running with no issues.
Does it bug anyone else around here when they boast about how they built systems for as cheap as they claim?
Yes, especially when they also claim the system is about 10x as powerful as it really is.
With 16GB of RAM and 12GHz of total CPU, each of his "45-50 OS's" gets about 364MB of RAM and 266MHz of CPU, with no accounting for overhead. I have 8-core/16-thread ESX servers that run 10-15 VMs at pretty much bare-metal speed, but that's the limit if there is any real CPU use on those VMs. Then, too, there's I/O contention. 40 VMs all writing to one SATA disk would be painfully slow (and you don't get hardware RAID that ESXi can use in a box for less than $200).
I would really like to see motherboards with 8 or event 16 RAM slots become standard. Most of these motherboards support 16 GB maximum memory, which is nice, but once you start running VMs or databases on your machine, 16 GB can get eaten up pretty quickly. I would think that having a machine with a possible 64 GB of RAM would entice a lot of people.
Once you get above about 8GB of RAM, you really shouldn't trust it for anything serious without ECC.
Even the best listed bit-error rates (which are all pretty much a guess) show that 32GB of RAM will have an error every 3 years, while the worst listed rates would give you an error every 2 minutes. Based on ECC logs in my servers, I'd say the reality is about 8 errors per year for 32GB. So, if you want 64GB, and can live with a once-a-month error that could be anything from a BSOD to a subtle corruption of data, then go ahead and use a desktop chipset.
I think AMD is really missing a chance by not bragging about how their desktop processors support ECC and Intel's do not.
Its called Selective Availability. The time signals are deliberately dithered (random errors).
All this does is make GPS not accurate enough to steer a missile into a window. For normal use, the less than 100 meters error caused by SA wouldn't be much of a problem.
It's also very hard to limit this to a region. Although very large areas can be targeted, if (for example) Russia paid for full accuracy but the rest of the EU did not, then pretty much all of Europe would still get the full signal.
To shut off GPS in a region the DoD just has to press a couple of buttons in Colorado (IIRC).
I don't believe there is any way to shut down GPS at the source other than globally.
The satellites move too fast to have them turn on and off effectively and good GPS receivers can get a lock on satellites that are pretty low in the sky, so about the best they could do would be to shut down GPS for about half the globe.
Not if you wear bifocals, and you use the bottom part of your lenses to focus on the monitor.
I just got a pair of progressive lenses (i.e., no-line bifocals) and the bottom of the lens is best for viewing things about 6-12" away. My monitor is about 24" away, so the middle of the lens works just fine. Maybe it's just me, and maybe it's the progressive lenses.
The head of our IT department has single-vision lenses, and needs to put small print about 5" away from his face (with glasses off) to read it, and ISTR that same less than 12" distance is how my parents, etc, read things before they got bifocals.
Slashdot Mirror
or do navigation:
You'll note that the page you linked to says:
One day I said to Siri "tell my girlfriend I love her" The message that popped up was nicely addressed to my girlfriend and said "have her".
Do people really have contacts named "girlfriend", "wife", "grandmother", etc.?
If not, I think the database that Siri must be using is something the NSA would like to get their hands on.
Can't take a hard drive built with LVM and migrate it to another machine with the same name -- i.e. a common operation after a hardware upgrade.
I do this all the time with VMs with absolutely no config changes (i.e., it just works).
Now, if you have a system with a LVM group/volume name of foo/bar, then yes, you can't just add disks that already have a foo/bar group/volume to the machine and have it work. If there is no name collision, though, it just works. It's how I upgraded a really old Fedora install. I renamed the old LVM group, then disconnected the old hard drives, added an SSD, installed the latest Fedora on the SSD, and plugged the old drives back in to allow me to copy my customizations to the new drive.
I suppose it is possible to rename the logical volume, but this is fairly arcane
lvrename VolumeGroupName OldVolumeName NewVolumeName is arcane? I can tell you don't do much with LVM, since lvrename is one of the least twisted of all the LVM commands.
I think Windows actually over reports the size of that due to all the linking in there.
According to your link, it's the other way around, in that every bit of the OS is in the WinSxS directory, and the versions in other directories are links.
But, the real point is that it grows large because Microsoft has determined two things:
What this also leads to is that every OS patch applies to every Windows system (Vista and beyond), because even if you don't have a feature "installed", they need to add the patch to the repository on your hard drive in case you want to install that feature. Basically, it is like a Linux install that has the entire repository from the distribution—including every version of every package that had ever been released—stored on the local hard drive.
It is insanely easy for government to get an under-performing contractor kicked off the job.
An individual, maybe, but not a contractor who works for one of the bigger companies.
Likewise, if you view the "contractor" as the "entity that holds a contract", it's almost impossible to get that entity dumped within the period of the contract, and lock-in sometimes makes it nearly impossible to award the contract to a new entity. For example, if company A provides computing services to the government, it's possible that moving those services to company B would be more expensive than dealing with the crappy performance from company A.
A dell R815 with 2 twelve-core AMD processors (although they were not bulldozer ones) 256GB of ram, and a pair of hard drives was $8k cheaper than a similarly configured Dell R810 with 2 10-core Intel Processors when we ordered a few weeks ago.
The Westmere-EX CPUs on the Dell R810 are recently released, and as such are very pricey. They are also much, much faster than any other Intel or AMD chip on a per-clock basis. Because the E7-88xx Xeons have nearly twice the cache (30MB "smart" vs. 24MB total L2 plus L3), are hyper-threaded, and run faster clock-for-clock, a heavily parallel task will likely finish faster on a single CPU Westmere-EX than on a dual CPU Magny-Cours.
Because of this, the R810 is a much, much more powerful system than the R815, so it only makes sense that it's more expensive, although part of it is paying for the bleeding edge of Intel. In the more normal realm, you can get a pair of 2.4GHz 6-core E5645s for less than the price of a single 2.2GHz Opteron 6174. That's 12 cores and 24 threads vs. 12 cores, and overall more performance.
Oh, the pronunciation of "GNU" is also stupid.
It's also impossible to do as he says.
A hard "g" is a stop, so there must be a pause (however slight) after it, which means you have to end up with a two-syllable sound "guh-new".
But if he stays with you and you have a friendly parrot (if you know what I mean) he will be very, very glad.
FTFY
Because running a device at 40-50 degrees Celsius below the Tmax will make it last longer than running it at 10 degrees below the Tmax. Heat eventually breaks down modern semiconductors.
Also, you want to avoid thermal processor throttling, which does not occur at an exact temperature. Giving yourself a lot of margin for error avoids that.
Last, you can get close to the same amount of cooling for about $40, which I consider a reasonable investment to help extend the life of a $300-600 processor.
Think unexploded bomb in a sitcom, like "Hogan's Heroes", only with a really big bang for failure.
This is a good thing, the B53 was a last ditch weapon intended to take out the hardened bunkers of the Soviet leadership, except it was air burst which is a highly, highly ineffective was to take out a bunker.
The B53 had a reinforced nose that (along with parachutes) allowed it to be detonated on the ground, which should have been fairly effective.
But, I'm getting the mental picture of such a bomb lying there while the bomb squad attempts to disarm it.
RFC doesn't require it, I do.
No, the SMTP RFC does not permit rejection based on the argument to HELO unless it is syntactically incorrect.
As to your numbers - the prices for drives didn't go up by 50-90%, they went up by 15-30%.
From the fucking story:
Speaking of price increases, we have seen a spike of 15% to 30% in the cost of some models over the last 72 hours.
As many others have pointed out, the story is wrong.
Drives that were $100 (free shipping) on Monday are now $148 (shipping up to $8). That's 48%. Drives that were $120 on Monday are now $190. That's nearly 60%, and from the comments, that's not the biggest jump.
God, the misconceptions in basic economics on this site are just overwhelming.
Yes, and you are spewing most of them, because you don't realize that selling 75 drives at $150 makes the manufacturer more money than selling 100 drives at $100, and that's exactly what is happening right now, because every hard drive manufactured is going to be sold. Even with this jump, hard drives are nowhere near the price point where people will cut down purchases so that inventory sits in the warehouse longer than it currently does. And, I guarantee you that when the flooded plant comes back online and drives it manufactures are actually sitting in retail stores, they will be 5-20% more expensive than the same drive was this past Monday, because people will have gotten used to paying $160 for a hard drive that fits their needs, and won't quite remember whether it was $100 or $110 before the big price jump.
It read pretty clearly to me, 3 blades - 3 blades should serve quite a few job seekers.
Maybe, maybe not.
If the system had 30 blades running it with the crappy performance, then 3 more won't do much. If it had 3 blades before, then maybe 3 more will help, unless, of course, the poor performance is not caused by lack of CPU resources. If it's because of disk or network issues, throwing more CPUs at it will probably make it worse. Or, perhaps the individual blades are underpowered.
there is real actual SCARCITY here, because the plants are not producing enough supply to satisfy the demand at the previous low prices.
Oh, really? You have access to the full inventory and shipping manifests from every hard drive manufacturer on the planet, and you can verify that the numbers as of right now are much lower than a month ago?
The problem is that you seem to assume that companies aren't going to take advantage of the loss of 25% of the hard drive manufacturing capacity to increase prices 50-90% right now despite any real scarcity (which may never exist), and then lower prices by 25% a few weeks after the plant comes back on line, then maybe drop prices another 25% a month or two later. The result will be that their profits for the next year or so will be a lot more, because they will be fast to raise and slow to lower prices, and hard drive demand is fairly constant.
The resellers and retailers are even more slimy, as it takes 3-4 months for a hard drive to make it from the manufacturer to the end-user, so right now there are 3-4 months of hard drive supply either in warehouses or on boats. If the plant is out of commission for a month, then prices should go up in January, and come back down before March.
What I'm wondering is how the hard drive manufacturers figured out how to cause the flood, 'cause it's a lot less suspicious than a fire.
based on supercar standards, this is pretty darn awesome.
Not really. Although the torque is lower at 638 lb-ft, a Corvette ZR1 will get about the same highway mileage and over 50% more horsepower (638 vs. 400).
Since torque is often based solely on the transmission (my car has a 350 lb-ft spec, while the same engine gives 420 lb-ft when married to a different transmission), I suspect that Chevrolet could get the same 960 lb-ft of torque if they chose to, but that it makes no difference to real-world performance.
Mostly due to XP's memory manager being completely crap but that's another story.
Have you compared apples to apples? I run XP x64 as my desktop, and it runs everything just fine, with no memory management issues.
So - I'm wondering why, exactly, do people want to do RAID with SSD? There are really only two reasons (that I'm aware of) for a RAID.
And both are as valid for SSD as they are for spinning disks.
RAID-0 can turn SSDs from fast to insane (if you have the controller bandwidth). Any of the data-protection RAID levels will help if your drive-with-really-new-and-somewhat-untested-technology dies an untimely death.
TRIM doesn't work with RAID, period. Most drives can work with RAID 0 or 1.
I just installed a pair of SSDs in RAID-1 using Fedora 15. I had searched far and wide to see if TRIM was supported, and didn't find anything conclusive, so I installed anyway, since I'm only using 16GB out of the 64GB drive (which means that even non-TRIM-aware wear-leveling would last 4 times as long). After I had installed, I did some more searching, and somewhere I found info that said the 3.0 kernels (which Fedora 15 uses, although renumbered to keep some apps from breaking) supported it. I didn't bookmark it, but I think it was part of the kernel mailing list.
Based on the fact that /sys/block/[device]/queue/discard_granularity contains 512 for every device in the stack (LVM/dm -> md -> sd[ab]) and there are no warnings at mount time with ext4 using the "discard" option, I believe it. Also, for any device not on top of an SSD, "discard_granularity" is 0 and you get warnings at mount time if you try to use the "discard" option.
And there's stuff you can't do easily with physical servers that you can with VMs. Take a system snapshot, change something or test something, then roll back to the snapshot.
One of the other cool things is that you can pull the plug on the VM (i.e., hard power off) without any chance of damage to physical hardware but still see how your application reacts.
I also found that prolonged disconnection from the disk drive doesn't make much difference to most operating systems (when I had a 2-hour SAN outage). This was a shock, as when the SAN came back up, the VMs resumed running with no issues.
Does it bug anyone else around here when they boast about how they built systems for as cheap as they claim?
Yes, especially when they also claim the system is about 10x as powerful as it really is.
With 16GB of RAM and 12GHz of total CPU, each of his "45-50 OS's" gets about 364MB of RAM and 266MHz of CPU, with no accounting for overhead. I have 8-core/16-thread ESX servers that run 10-15 VMs at pretty much bare-metal speed, but that's the limit if there is any real CPU use on those VMs. Then, too, there's I/O contention. 40 VMs all writing to one SATA disk would be painfully slow (and you don't get hardware RAID that ESXi can use in a box for less than $200).
I would really like to see motherboards with 8 or event 16 RAM slots become standard. Most of these motherboards support 16 GB maximum memory, which is nice, but once you start running VMs or databases on your machine, 16 GB can get eaten up pretty quickly. I would think that having a machine with a possible 64 GB of RAM would entice a lot of people.
Once you get above about 8GB of RAM, you really shouldn't trust it for anything serious without ECC.
Even the best listed bit-error rates (which are all pretty much a guess) show that 32GB of RAM will have an error every 3 years, while the worst listed rates would give you an error every 2 minutes. Based on ECC logs in my servers, I'd say the reality is about 8 errors per year for 32GB. So, if you want 64GB, and can live with a once-a-month error that could be anything from a BSOD to a subtle corruption of data, then go ahead and use a desktop chipset.
I think AMD is really missing a chance by not bragging about how their desktop processors support ECC and Intel's do not.
Its called Selective Availability. The time signals are deliberately dithered (random errors).
All this does is make GPS not accurate enough to steer a missile into a window. For normal use, the less than 100 meters error caused by SA wouldn't be much of a problem.
It's also very hard to limit this to a region. Although very large areas can be targeted, if (for example) Russia paid for full accuracy but the rest of the EU did not, then pretty much all of Europe would still get the full signal.
To shut off GPS in a region the DoD just has to press a couple of buttons in Colorado (IIRC).
I don't believe there is any way to shut down GPS at the source other than globally.
The satellites move too fast to have them turn on and off effectively and good GPS receivers can get a lock on satellites that are pretty low in the sky, so about the best they could do would be to shut down GPS for about half the globe.
Not if you wear bifocals, and you use the bottom part of your lenses to focus on the monitor.
I just got a pair of progressive lenses (i.e., no-line bifocals) and the bottom of the lens is best for viewing things about 6-12" away. My monitor is about 24" away, so the middle of the lens works just fine. Maybe it's just me, and maybe it's the progressive lenses.
The head of our IT department has single-vision lenses, and needs to put small print about 5" away from his face (with glasses off) to read it, and ISTR that same less than 12" distance is how my parents, etc, read things before they got bifocals.