I find it hard to believe that using SSDs as a cache is wise, but I also question if the money couldn't be better spent adding more DDR3 RAM to the processor and letting it cache the drive (with the obvious options and benefits that brings).
The benefit of using FLASH as a cache is that it is much denser than RAM, and therefore you can get much more for your money. While your CPU spends most of it's time working out of it's cache and RAM, the data not being referenced can be stored on FLASH in the knowledge it is a millisecond away from being usable. While not low latency in computer terms, it is blindingly fast in human terms, and more than makes up for the swapping that isn't required to disks.
Of course, this assumes your working set of data is bigger than available RAM, which even on modest desktops today, is unlikely for personal use. Where it really comes into it's own is on server machines, where the working set can be significantly bigger than RAM. Buying 60GB of RAM is still relatively expensive, whereas buying 60GB of FLASH is not, and against network stack latency, the latency of FLASH is not so significant.
I am surprised they weren't doing this on day 2 after the event.
Me too. After 9/11, there were robots on scene in under 2 days. The iRobot unit being used here is a standard PackBot, of which about 20,000 have been manufactured for the US military.
The priority just wasn't having a look. They had to cool the thing, and some robot poking round the reactor would not have helped the cooling one bit.
After 9/11, the priority would have been to find improbable survivors. Hence the deployment of robots.
The worst aspect of this disaster for the future of nuclear power is that it all came merely from a loss of cooling. The plant survived the earthquake. The reactor's cooling system survived the tsunami and continued to function until the battery backups were drained. Loss of cooling caused heat buildup, hydrogen release, and the hydrogen explosions. All the damage you're seeing is from the hydrogen explosiions, not the natural disaster.
One could argue that had the hydrogen been allowed to be vented to the atmosphere, even the hydrogen explosions wouldn't have happened.
It has been noted that these were old designs, and more modern designs have passive cooling designs that do not require power to operate, I guess using convection to circulate coolant.
Regardless, the cooling system did NOT survive the tsunami. The backup diesel generators were written off in the tsunami, which is why the backup batteries were being used for the cooling system.
A total loss of cooling power could happen for other reasons - a fire, tornado, hurricane, or act of terrorism. There's been a design assumption that no disaster would result in the loss of all power sources. That turns out to be a bad assumption.
Let's be clear. This was an unprecedented earthquake and subsequent tsunami. A once in a millennium occurrence? The design assumption was based on how big previous natural disasters had been.
Acts of terrorism? To replicate the devastation of the tsunami would require how much force do you think? It would probably require a sustained direct assault from an army unit with heavy artillery. I doubt an airliner crash could have enough impact, and a lone operative could surely never penetrate with enough explosives to cause enough damage once inside and not be noticed as "a bit suspicious".
With Japan being regularly hit by typhoons, I guess the plant was designed to handle hurricane force winds. Tornadoes? Don't make me laugh.
As we've seen, the worst impact of the "nuclear disaster" is economic, rather than human or ecological.
I bought one once. I set up the network for a small organization and every time there was any kind of problem they blamed the WiFi router and called me. I bought a Airport and threw that in there instead. Now they have just as many problems but they assume that the Apple product cannot possibly be the issue, and I have not received a complaint from them since. It has been a almost two years. It was well worth the $180 to me.
Why not just sell them a per-call support contract?
Internally the modern x86 is really a RISC at heart anyway. But it's got a really massive support system on top of that that converts the older style CISC instruction set into a VLIW/ RISC style that's more efficiently executed in a superscalar way.
If you look at a picture of any modern CPU die, the real estate is totally dominated by the caches. That "massive support system" (which in reality is only a tiny fraction of the whole die area) serves largely as a decoder that unpacks the compact CISC-style opcodes (many of which are only one or two bytes long) into whatever obscure internal superscalar architecture is in vogue this year. This saves huge amounts of instruction cache space compared to unpacking bloated one-size-fits-all RISC-style opcodes into the some similar internal architecture du jour.
While the instructions can be more densely packed in x86 than a typical RISC CPU, x86 often loses out by having more instructions to work round the fact that they have a poor architecture. With only 8 GPR, there is much shuffling of data between registers and memory that RISC CPUs just don't need. Thus, RISC cpus tend not to hit their data cache as hard.
x64 has improved that somewhat, with 16 GPR (the same as ARM).
Thus, the X86 can end up needing less die area overall. This is one reason that despite what elitists geeks say, over the years X86 has usually provided more bang for the buck than any competing processor family.
I think you'll find that, for example, Alpha processors used less die area than their contemporary x86 CPUs. For example, compare the Alpha 21064A with the Pentium, the Alpha has less transistors (1.75M vs 3.1M) and smaller die (186mm^2 vs 294mm^2). That's with the same cache size, and hence roughly the same cache transister count. Which CPU do you think would have been cheaper to make at Pentium volumes?
Same with the original ARM versus earlier x86. ARM was scarily simple (~30,000 transistors?), yet higher IPC than i386.
x86 bang per buck is a volume thing, not architectural.
The difference gets smaller in later generation CPUs, as cache starts to dominate area. Control logic is much less dense than cache, so the extra compatibility transistors of earlier x86 really hurt transistor counts versus contemporary RISC CPUs.
This scheme is so advantageous, that even ARM has tacked on a similarly convoluted opcode decompresser. If ARM ever evolves into a mainstream general-purpose high-end CPU, there will be undoubtedly dozens more layers of cruft added to the ARM architecture to make it competitive with X86, at which point it will be similarly complex. (For another example, take a look at how the POWER architecture ended up over time. You can hardly call it RISC any more.)
Why would ARM need more layers? Adding a 64-bit data/pointer mode would be advantageous, but that wouldn't have nearly the same problems as was encountered with x64, as there would be no fundamental change in the instruction set, just an extension of the register sizes and added instructions to load the extra width data. Other RISC CPUs came through the 64-bit barrier without adding loads of cruft to the architecture. That includes POWER, SPARC, PA-RISC and MIPS.
RISC isn't an implementation thing. It's an instruction set thing. POWER is most definitely RISC.
I doubt these units could be hot swapped. They don't have staggered power pins for a start. They'd need to be loaded into some sort of caddie with the proper connectors, at which point you may as well just use the 1.8" form factor.
I guess it's better than an Otto cycle engine due to less work lost to camshafts and valve springs. Being compression ignition based, it would have the efficiency benefits of a two stroke diesel engine, but also without the loss to the valve train.
I'm not sure what it has particularly over a two crank system such as used in similar engines in the past. I guess it comes down to the friction of the main crank bearings being half that of a two crank system.
Probably the biggest barrier to entry for new engines like this is pure momentum of existing engines. Mass produced engines are not cheap to tool up for. New engines are almost always refinements of existing designs, and a new design would require significant proving.
In fact, 1 is exactly the same as 0.999...; 0.999... is just a geometric series. 1 is also the same as 1/2+1/4+1/8+... and 2/3+2/9+2/27... and a variety of other infinite expansions in other bases.
That's just plain wrong.
0.999... < 1. Simple fact. It is infinitesimally less, but less all the same.
IANADBA, but something like the redo log volumes don't exactly tax a mechanical disk, being mostly sequential reads and writes, and so would be a reasonable candidate to leave as HDD. Even a cheap as chips 5400rpm laptop drive could sustain 23MB/s (2TB/day) sequentially without breaking a sweat.
However, using the SAME (Stripe And Mirror Everything) principle, spreading all load across multiple mirrored SSDs should provide both the speed and endurance capacity you would need, with the great random performance provided by SSD and less wasted space of short stroked HDD.
I think it'll be interesting to compare the price/performance of all SSD based TPC benchmarks when they start coming in. High throughput TPC configurations end up being expensive partly due to the huge number of HDDs required to provide the IOPS. SSD should make the storage simpler and reduce the number of drives required, reducing capital and management costs.
The OS is awful at write-back as if the power fails you've lost state. The benefit of a hybrid drive is that the flash is non-volatile. Writing to the flash ram is cheap. Writing to the disk is expensive. You get the best of both worlds with a flash based write-back cache.
Unfortunately, FLASH is quite slow at writing, especially with only a single channel to write to. While a drive like this would probably still beat a pure HD for write latency (and hence perceived performance), synthetic sequential write benchmarks would take a pounding the drive simply wouldn't sell.
As an example, consider the cheap Intel 40GB SSD. It has only 5 channels (half the channels and flash of the 80GB drive) and can only write 35MB/s sequentially. That works out at about 7MB/s per channel! Try selling a drive that can only write 7MB/s sequentially.
Of course, the drive could recognize sequential writes and bypass the FLASH cache for these, but that of course complicates the firmware further.
The OS cache shields you from most write latency anyway, and it is read latency that hinders most peoples perception of performance. Hence why read caching only is done.
Now it will be the same thing with hard drives. In a way, it already is. I don't need the drive to be super fast, no. 30-40MB/s of linear read speed would be enough for most of my drives, but I have to buy 7200RPM drives with a lot of cache that do 100MB/s. How about a huge 5.25" Full Height drive with >10 platters that does 40MB/s and has 50ms full seek. The drive would probably be cheaper or more reliable because of the lower data density or it would have much more capacity than the regular 3.5" drives.
Sucked ass performance wise, but good price per MB.
Where SSD score big is random IO, in real world use sequential IO performance is largely moot. Random IO dominates performance. SSD are orders of magnitude better performing on random IO, especially reads.
I don't trust flash based storage devices. If the power supply fails and sends +30V where 5V should have been the flash memory will be destroyed with all its contents. If this happens to a hard drive, I could at least bring it to a data recovery company (if the data is very valuable) or try to recover the data myself (if the data is not that valuable). It would probably only need a circuit board replacement. Oh, and flash memory has a limited number of write cycles.
That's what backups are for. You do make backups, right?
Correct:
pSeries is the new name for the previous RS/6000 AIX boxes,
iSeries is the new name for the previous AS/400 boxes that ran OS/400,
and zSeries is the new name for the previous mainframe line.
the p and i boxes now run pretty much the same hardware, and both have supported Linux for some time. The iSeries has excellent virtual machine support (called "partitioning" in iSeries parlance) and can run Linux instances natively or on an installed Intel-class processor board that shares system memory and disk (DASD).
As to why you might want to run Linux on mainframe-class hardware, reliability and scalability come to mind.
The military basically says, I need a plane that can go at least mach 2, can carry X number of pounds of air to ground or air to air weapons, has X% stealth capability, has a range of X miles, can land on a aircraft carrier, etc., etc... and costs about X dollars.
Wow, I'd like to see the value of X that can fit all of those parameters!
My server just mails me its daily security run, and most days there is a couple of brute force attempts.
It reminds me of a time I was in an airport going through the TSA security line to go into the terminal. The agent checked my ID and boarding pass and then got distracted by a bunch of flight attendants she had to let through. She then turned back around and asked me if she had checked my ID. I gave her a hard time because in this system I am assumed to be untrustworthy until she says otherwise so she shouldn't trust anything I tell her.
I had a similar issue when I left my camera on a plane. Having departed the plane, I told security on the gate what had happened, and the muppet just sent me straight back on to the plain with no security checks whatsoever!
$5 per license? You reckon? 20 years ago, when they were touting DOS for $5 per machine sold (whether it ran DOS or not) perhaps, but not now.
Vista Home Basic is $99 for the OEM version. You think the system builder has a 2000% markup? Probably not. Lenovo probably get a big discount on that $99, but not a >90% discount.
I wouldn't worry about it. I have this and I work for IBM:)
For example, a recent server we bought internally went up the chain for approval, fell at the last hurdle, back down a different chain to someone else, back across to our team, then back up the approval chain again.
When we got the hardware, no-one had factored in software licenses, so we went through the whole process again while the hardware gathered dust.
We now have an 8 core, 32GB RAM machine simply doling out compile jobs, rather than the original task it was intended for.
Most medical records today aren't things that patients get
From what I've seen myself, and heard from family members etc. that appears to be the default - to keep patient, and medical data on that patient, in separate places. But why ??? Can anyone from the medical profession enlighten us what's wrong with patients studying their own X-rays, reviewing lists of drugs to be used in the course of a (planned) operation, or re-reading a diagnosis? And I'm talking totally separate from the issue of how much influence a patient should have on these things. Is medical data only interesting to doctors etc., but not for patients themselves? Are well-informed patients a nuisance, or what? What do medical professionals think of this?
I'm not in the medical profession, but in the UK at least, everyone has the right to see their own medical records under the Data Protection Act.
There is much controversy about the upcoming UK digital medical system. Currently projected to cost >£12B, it will electronically record all patient records. Some fear it will be open to abuse, without giving much regard to details like bank records already being digital and "open to abuse".
Of course, it will be bodged, and indeed open to abuse if current projects are anything to go by.
Slashdot Mirror
I thought TCR station was closed anyway?
The way he shakes when he moves, he reminds me more of Old Bob from The Black Hole movie.
It didn't.
Wrong. They gave the last person to find the cache (!) a police caution, which means that they now have a criminal record.
Why did the dumbass accept a caution! He should have seen it through to court.
I find it hard to believe that using SSDs as a cache is wise, but I also question if the money couldn't be better spent adding more DDR3 RAM to the processor and letting it cache the drive (with the obvious options and benefits that brings).
The benefit of using FLASH as a cache is that it is much denser than RAM, and therefore you can get much more for your money. While your CPU spends most of it's time working out of it's cache and RAM, the data not being referenced can be stored on FLASH in the knowledge it is a millisecond away from being usable. While not low latency in computer terms, it is blindingly fast in human terms, and more than makes up for the swapping that isn't required to disks.
Of course, this assumes your working set of data is bigger than available RAM, which even on modest desktops today, is unlikely for personal use. Where it really comes into it's own is on server machines, where the working set can be significantly bigger than RAM. Buying 60GB of RAM is still relatively expensive, whereas buying 60GB of FLASH is not, and against network stack latency, the latency of FLASH is not so significant.
The update is quite good; but seriously ... 1.99? What happens if you find a critical bug - you'll have to go 1.991... when does the insanity end?!
99 + 1 = 100
While also being securely attached to the airframe? Airframe sinks, that's a big flotation device required.
I am surprised they weren't doing this on day 2 after the event.
Me too. After 9/11, there were robots on scene in under 2 days. The iRobot unit being used here is a standard PackBot, of which about 20,000 have been manufactured for the US military.
The priority just wasn't having a look. They had to cool the thing, and some robot poking round the reactor would not have helped the cooling one bit.
After 9/11, the priority would have been to find improbable survivors. Hence the deployment of robots.
The worst aspect of this disaster for the future of nuclear power is that it all came merely from a loss of cooling. The plant survived the earthquake. The reactor's cooling system survived the tsunami and continued to function until the battery backups were drained. Loss of cooling caused heat buildup, hydrogen release, and the hydrogen explosions. All the damage you're seeing is from the hydrogen explosiions, not the natural disaster.
One could argue that had the hydrogen been allowed to be vented to the atmosphere, even the hydrogen explosions wouldn't have happened.
It has been noted that these were old designs, and more modern designs have passive cooling designs that do not require power to operate, I guess using convection to circulate coolant.
Regardless, the cooling system did NOT survive the tsunami. The backup diesel generators were written off in the tsunami, which is why the backup batteries were being used for the cooling system.
A total loss of cooling power could happen for other reasons - a fire, tornado, hurricane, or act of terrorism. There's been a design assumption that no disaster would result in the loss of all power sources. That turns out to be a bad assumption.
Let's be clear. This was an unprecedented earthquake and subsequent tsunami. A once in a millennium occurrence? The design assumption was based on how big previous natural disasters had been.
Acts of terrorism? To replicate the devastation of the tsunami would require how much force do you think? It would probably require a sustained direct assault from an army unit with heavy artillery. I doubt an airliner crash could have enough impact, and a lone operative could surely never penetrate with enough explosives to cause enough damage once inside and not be noticed as "a bit suspicious".
With Japan being regularly hit by typhoons, I guess the plant was designed to handle hurricane force winds. Tornadoes? Don't make me laugh.
As we've seen, the worst impact of the "nuclear disaster" is economic, rather than human or ecological.
I bought one once. I set up the network for a small organization and every time there was any kind of problem they blamed the WiFi router and called me. I bought a Airport and threw that in there instead. Now they have just as many problems but they assume that the Apple product cannot possibly be the issue, and I have not received a complaint from them since. It has been a almost two years. It was well worth the $180 to me.
Why not just sell them a per-call support contract?
Internally the modern x86 is really a RISC at heart anyway. But it's got a really massive support system on top of that that converts the older style CISC instruction set into a VLIW/ RISC style that's more efficiently executed in a superscalar way.
If you look at a picture of any modern CPU die, the real estate is totally dominated by the caches. That "massive support system" (which in reality is only a tiny fraction of the whole die area) serves largely as a decoder that unpacks the compact CISC-style opcodes (many of which are only one or two bytes long) into whatever obscure internal superscalar architecture is in vogue this year. This saves huge amounts of instruction cache space compared to unpacking bloated one-size-fits-all RISC-style opcodes into the some similar internal architecture du jour.
While the instructions can be more densely packed in x86 than a typical RISC CPU, x86 often loses out by having more instructions to work round the fact that they have a poor architecture. With only 8 GPR, there is much shuffling of data between registers and memory that RISC CPUs just don't need. Thus, RISC cpus tend not to hit their data cache as hard.
x64 has improved that somewhat, with 16 GPR (the same as ARM).
Thus, the X86 can end up needing less die area overall. This is one reason that despite what elitists geeks say, over the years X86 has usually provided more bang for the buck than any competing processor family.
I think you'll find that, for example, Alpha processors used less die area than their contemporary x86 CPUs. For example, compare the Alpha 21064A with the Pentium, the Alpha has less transistors (1.75M vs 3.1M) and smaller die (186mm^2 vs 294mm^2). That's with the same cache size, and hence roughly the same cache transister count. Which CPU do you think would have been cheaper to make at Pentium volumes?
Same with the original ARM versus earlier x86. ARM was scarily simple (~30,000 transistors?), yet higher IPC than i386.
x86 bang per buck is a volume thing, not architectural.
The difference gets smaller in later generation CPUs, as cache starts to dominate area. Control logic is much less dense than cache, so the extra compatibility transistors of earlier x86 really hurt transistor counts versus contemporary RISC CPUs.
This scheme is so advantageous, that even ARM has tacked on a similarly convoluted opcode decompresser. If ARM ever evolves into a mainstream general-purpose high-end CPU, there will be undoubtedly dozens more layers of cruft added to the ARM architecture to make it competitive with X86, at which point it will be similarly complex. (For another example, take a look at how the POWER architecture ended up over time. You can hardly call it RISC any more.)
Why would ARM need more layers? Adding a 64-bit data/pointer mode would be advantageous, but that wouldn't have nearly the same problems as was encountered with x64, as there would be no fundamental change in the instruction set, just an extension of the register sizes and added instructions to load the extra width data. Other RISC CPUs came through the 64-bit barrier without adding loads of cruft to the architecture. That includes POWER, SPARC, PA-RISC and MIPS.
RISC isn't an implementation thing. It's an instruction set thing. POWER is most definitely RISC.
I doubt these units could be hot swapped. They don't have staggered power pins for a start. They'd need to be loaded into some sort of caddie with the proper connectors, at which point you may as well just use the 1.8" form factor.
I guess it's better than an Otto cycle engine due to less work lost to camshafts and valve springs. Being compression ignition based, it would have the efficiency benefits of a two stroke diesel engine, but also without the loss to the valve train.
I'm not sure what it has particularly over a two crank system such as used in similar engines in the past. I guess it comes down to the friction of the main crank bearings being half that of a two crank system.
Probably the biggest barrier to entry for new engines like this is pure momentum of existing engines. Mass produced engines are not cheap to tool up for. New engines are almost always refinements of existing designs, and a new design would require significant proving.
You might be right.
The more I read, the more I'm persuaded. If it's good enough for Leonhard Euler...
In fact, 1 is exactly the same as 0.999...; 0.999... is just a geometric series. 1 is also the same as 1/2+1/4+1/8+... and 2/3+2/9+2/27... and a variety of other infinite expansions in other bases.
That's just plain wrong.
0.999... < 1. Simple fact. It is infinitesimally less, but less all the same.
Are there any open-source filesystems that offer deduplication?
I've been meaning to look at http://www.lessfs.com/wordpress/, a Linux FUSE based dedup system.
But ZFS is open source, you know. If you don't like the way OpenSolaris has gone, try it with FreeBSD.
IANADBA, but something like the redo log volumes don't exactly tax a mechanical disk, being mostly sequential reads and writes, and so would be a reasonable candidate to leave as HDD. Even a cheap as chips 5400rpm laptop drive could sustain 23MB/s (2TB/day) sequentially without breaking a sweat.
However, using the SAME (Stripe And Mirror Everything) principle, spreading all load across multiple mirrored SSDs should provide both the speed and endurance capacity you would need, with the great random performance provided by SSD and less wasted space of short stroked HDD.
I think it'll be interesting to compare the price/performance of all SSD based TPC benchmarks when they start coming in. High throughput TPC configurations end up being expensive partly due to the huge number of HDDs required to provide the IOPS. SSD should make the storage simpler and reduce the number of drives required, reducing capital and management costs.
I'm sure Algebra and 0 were invented sometime before 1948.
The OS is awful at write-back as if the power fails you've lost state. The benefit of a hybrid drive is that the flash is non-volatile. Writing to the flash ram is cheap. Writing to the disk is expensive. You get the best of both worlds with a flash based write-back cache.
Unfortunately, FLASH is quite slow at writing, especially with only a single channel to write to. While a drive like this would probably still beat a pure HD for write latency (and hence perceived performance), synthetic sequential write benchmarks would take a pounding the drive simply wouldn't sell.
As an example, consider the cheap Intel 40GB SSD. It has only 5 channels (half the channels and flash of the 80GB drive) and can only write 35MB/s sequentially. That works out at about 7MB/s per channel! Try selling a drive that can only write 7MB/s sequentially.
Of course, the drive could recognize sequential writes and bypass the FLASH cache for these, but that of course complicates the firmware further.
The OS cache shields you from most write latency anyway, and it is read latency that hinders most peoples perception of performance. Hence why read caching only is done.
Now it will be the same thing with hard drives. In a way, it already is. I don't need the drive to be super fast, no. 30-40MB/s of linear read speed would be enough for most of my drives, but I have to buy 7200RPM drives with a lot of cache that do 100MB/s. How about a huge 5.25" Full Height drive with >10 platters that does 40MB/s and has 50ms full seek. The drive would probably be cheaper or more reliable because of the lower data density or it would have much more capacity than the regular 3.5" drives.
There was a drive like that in the 90's. http://en.wikipedia.org/wiki/Quantum_Bigfoot_(hard_drive)
Sucked ass performance wise, but good price per MB.
Where SSD score big is random IO, in real world use sequential IO performance is largely moot. Random IO dominates performance. SSD are orders of magnitude better performing on random IO, especially reads.
I don't trust flash based storage devices. If the power supply fails and sends +30V where 5V should have been the flash memory will be destroyed with all its contents. If this happens to a hard drive, I could at least bring it to a data recovery company (if the data is very valuable) or try to recover the data myself (if the data is not that valuable). It would probably only need a circuit board replacement. Oh, and flash memory has a limited number of write cycles.
That's what backups are for. You do make backups, right?
sed 's/\(.\)Series/System \1/g' <<EOF
Correct:
pSeries is the new name for the previous RS/6000 AIX boxes,
iSeries is the new name for the previous AS/400 boxes that ran OS/400,
and zSeries is the new name for the previous mainframe line.
the p and i boxes now run pretty much the same hardware, and both have supported Linux for some time. The iSeries has excellent virtual machine support (called "partitioning" in iSeries parlance) and can run Linux instances natively or on an installed Intel-class processor board that shares system memory and disk (DASD).
As to why you might want to run Linux on mainframe-class hardware, reliability and scalability come to mind.
EOF
The military basically says, I need a plane that can go at least mach 2, can carry X number of pounds of air to ground or air to air weapons, has X% stealth capability, has a range of X miles, can land on a aircraft carrier, etc., etc... and costs about X dollars.
Wow, I'd like to see the value of X that can fit all of those parameters!
My server just mails me its daily security run, and most days there is a couple of brute force attempts.
It reminds me of a time I was in an airport going through the TSA security line to go into the terminal. The agent checked my ID and boarding pass and then got distracted by a bunch of flight attendants she had to let through. She then turned back around and asked me if she had checked my ID. I gave her a hard time because in this system I am assumed to be untrustworthy until she says otherwise so she shouldn't trust anything I tell her.
I had a similar issue when I left my camera on a plane. Having departed the plane, I told security on the gate what had happened, and the muppet just sent me straight back on to the plain with no security checks whatsoever!
$5 per license? You reckon? 20 years ago, when they were touting DOS for $5 per machine sold (whether it ran DOS or not) perhaps, but not now.
Vista Home Basic is $99 for the OEM version. You think the system builder has a 2000% markup? Probably not. Lenovo probably get a big discount on that $99, but not a >90% discount.
I wouldn't worry about it. I have this and I work for IBM :)
For example, a recent server we bought internally went up the chain for approval, fell at the last hurdle, back down a different chain to someone else, back across to our team, then back up the approval chain again.
When we got the hardware, no-one had factored in software licenses, so we went through the whole process again while the hardware gathered dust.
We now have an 8 core, 32GB RAM machine simply doling out compile jobs, rather than the original task it was intended for.
Gotta love IBM.
Most medical records today aren't things that patients get
From what I've seen myself, and heard from family members etc. that appears to be the default - to keep patient, and medical data on that patient, in separate places. But why ??? Can anyone from the medical profession enlighten us what's wrong with patients studying their own X-rays, reviewing lists of drugs to be used in the course of a (planned) operation, or re-reading a diagnosis? And I'm talking totally separate from the issue of how much influence a patient should have on these things. Is medical data only interesting to doctors etc., but not for patients themselves? Are well-informed patients a nuisance, or what? What do medical professionals think of this?
I'm not in the medical profession, but in the UK at least, everyone has the right to see their own medical records under the Data Protection Act.
There is much controversy about the upcoming UK digital medical system. Currently projected to cost >£12B, it will electronically record all patient records. Some fear it will be open to abuse, without giving much regard to details like bank records already being digital and "open to abuse".
Of course, it will be bodged, and indeed open to abuse if current projects are anything to go by.
Oops,selected wrong moderation option. This replay is to wipe that moderation.