So apparently anything that can be heated by a microwave and detected with an EM field is now an RFID tag? Are my Hot Pockets(tm) safe?
The link you provided show no evidence whatever that there is any sort of remote tracking system -- just that you can unevenly heat cash in a microwave. Even if you assume there were some sort of RF identifier in currency there's no evidence that it's unique to the bill; a demonination-unique RF marking in currency could aid in automated handling, handling by the blind, etc., without any particular threat of privacy loss, as there is no way to track a particular bill.
If you want anyone to take you seriously you should find a better link. Or, you know, actually test bills for RF reactivity and to prove the presense of an RF device. Or even mechanically or chemically disassamble a bill and physically locate the supposed RF device. Until then I'm gonna file this one next to "Microwaved Water Kills Plants".
Yes, light that barely misses the event horizon is bent so that it appears to come from a source much closer (in an angular sense) to the black hole. But not light that would actually be occluded by the black hole -- that light is still blocked. Take another look at the diagram; it shows objects that are angularly distant from the black hole appearing to be much closer, not objects occluded by the black hole being somehow visible from the far side.
You can't see through the black hole, but it will lens light around it. Unfortunately it pulls in the wrong direction to see things directly behind it. http://en.wikipedia.org/wiki/Einstein_ring
But I think you might be able to sell the "record on to a black hole" idea to the RIAA.
Not unless you consider mirrors to be copying devices. More than one person at a time can observe the original due to the divergent paths of reflected photons. I don't see how optical splitting would be any different.
Except magazines ads are sold based on circulation numbers not actual ad impressions, so there's no lost revenue. Internet ads are generally only counted by actual image-loaded impressions, not the total number of site visitors. But you're right, the concept is similar.
Curtains are also untrustworthy and should not be relied on for access restriction. A sufficiently bright light, or one of the proper wavelength, can penetrate them without significant hindrance.
But more to the point, their complaint is not that people accessed the site, just that they didn't do so in a way that generated ad revenue. If someone is technically inclined enough to strip or otherwise modify their headers to gain access they are certainly technically inclined enough to install AdBlock if they wanted to avoid ads.
Except if you took a high resoluiton picture you'd actually have a copy, distinct from the original. A better analogy might be an artist puts their painting in a gallery window, and you open a shop across the street and put in a telescope so people can see the orignal painting, People still have to go *somewhere* to see the painting, and you *haven't* made an unauthorized copy, you just removed the original context (the gallery window) and replaced it with your own shop.
Certainly it's not a nice thing to do, and I'd be angry if someone did it to me, but wouldn't you prefer that the gallery just to put up curtains (or check the referer header)? Do you really want the courts saying it's illegal to use a telescope across the street from any art gallery?
No, I'm expecting that I can buy a used phone for $30 from some other customer who already paid their $300 and who has since canceled their service. Or that I can use any technically compatible phone that I purchased from any other vendor. Why is the service provider the only place that I'm allowed to by phones?
It's actually very difficult to bring your own phone in for new service with most carriers. It's even fairly difficult to bring your old phone from the same carrier back in to service if it's been deactivated for any period of time. With some carriers it can be done, but they don't make it easy.
I came up with 2/3 because you need to read the data and both parity stripes.
You only need to read one parity set unless you detect on error, and you need to read the original stripe regardless. You would only need the second set of parity data to determine which set of data is accurate in case of a conflict; in the general case the first parity set will match with data, and the second parity set can be ignored.
Actually it's worse than that, you need to read all the stripes to validate any given block, just as you do in a write operation. For example in the minimal 4 disk RAID-6 array, reading and verifying will be 4 times slower than reading without verifying.
When I read from RAID-6 without verifying I need to read the stripe itself. When I read with verification I need to read the stripe and one of the parity sets, which is 1/2 the size of the stripe. I come up with 100% + 50% = 150%. That's only 1/3 of the disk bandwidth going to parity data. Obviously you've got some other read/verify algorithm in mind, but I don't know why.
And that 50% overhead is still assuming that the parity data isn't cached and that the parity read (which is on a physically seperate disk) blocks other operations.
ZFS calculates checksums on a (variable size) block level. Compared with IO bandwidth, CPU and memory bandwidth are virtually free and getting cheaper all the time.
I don't know what systems you've been using, but it's been a long time since my memory bandwidth has jumped up any considerable amount. Overall bus speed is slowly gaining, but processor speed is still pulling away from bus speed, and unless there's some breakthough in bus technology that's like to continue to be true.
ZFS has an enormous advantage over md5sum: it is completely transparent to the user. I'd say that md5sum is the problem, and ZFS is the solution.
In many applications, md5 is completely transparent to the user. Run any modern package management system -- it fetches archives and their checksums and notes errors and in many cases refetches automatically in an attempt to correct the error. And it actually provides higher data integrity than ZFS's filesystem-level checking, because it actually knows what's supposed to be in the file, not just what the file system last thought was supposed to be in the file. As others have noted, it's not really end-to-end unless one of the ends is "program consuming data" -- with md5 that's possible, with ZFS it's not.
The underlying hardware will not necessarily notice errors. Hard drives are only designed to error protect the magnetic domains on the disk. There are all sorts of other places in the increasingly long datapath to disk where data can be lost, and, in fact, routinely does get lost.
Routinely does get lost is a bit of strech at best. If my data routinely got lost between the disk and the motherboard I'm pretty sure I'd notice. There are occasional transmission errors along physical data paths; if only someone had used your magical ZFS checksums when designing Ethernet or IP or SCSI to deal with these sorts of errors.
I know your link talks about how terrible firmware in SAN devices can be, but I have a hard time beliving that data integrity errors in a data storage device would go undiscovered for too long. If you're complaining about that you might as well whine about bad hard drive firmware or bad Ethernet firmware or bad RAM. In theory you could add protections for all those things, but it doesn't seem very useful to me; why not just test the system an to empirically discover such faults?
RAID-6 does not verify every read because it is a stupid way to achieve data integrity. It wastes two thirds of your aggregate IO read bandwidth when you can just use checksums virtually for free. CPU cycles for checksumming is dirt cheap whereas IO bandwidth is extremely expensive.
I don't know what kind of RAID-6 you use, but mine creates parity data that's significantly smaller than the original. I can't even guess at where you got the 2/3 number; the one I come up with is more like 1/3 worst-case-scenario, and that's only at the physical disk level, not at the host-interface level. And that worst-case scenario assumes that you haven't recently and weren't going to read the partiy data in the first place, and that reading parity data prevents you from completing other operations. I'll grant you that checksums are potentially more efficient from a data throughput standpoint, but let's try to stick to realistic numbers.
It's also worth noting that, while the checksum in ZFS is small, the entire data set much be read from memory and processed to calculate the checksum, in addition to whatever you plan to do with the data after you've done the integrity check. I/O starvation is not limited to disks; almost any busy system spends a huge amount of time waiting for data to come across the system bus from the RAM to the CPU. This is also not a task that can be entirely offloaded, even if you added a dedicated checksumming card or processor; given the end-to-end nature of ZFS, data would still have to come across the system bus to get to the card.
I'll admit there are things ZFS protects against that other systems do not, but those things don't seem any more likely to me than the possibility of a similar error in the ZFS system. For example, Mr. Bonwick sights bad firmware as a possible error. But how is an implementation error that causes a ghost write in my hard drive any more likely or difficult to detect than an implementation error that introduces a ghost write at the ZFS level?
If the data-integrity benefits of ZFS require that ZFS be implemented perfectly and only protects me from implementation errors in other, generally simpler systems, I'm not seeing a lot of practical benefit here. Belt-and-suspenders I guess, but nothing very pragmatic, since we're already talking about the very small percentage of the time that A) an error occurs and B) cannot be detected by all the existing data-integrity checking already in place. Not to mention the fact that, at least until ZFS is mature on non-Sun systems, I see the possibility of an error in the implementation of ZFS as much greater than the possibility of an error between my physical disk and my motherboard.
Yet strangely there aren't any other widely available storage solutions that provide transparent data integrity from the filesystem down.
No, but I can name several that provide it at both a higher and
First, let me introduce you to the file command, which can tell me all about your arch. Or failing that, less, or any other program than can read any binary on your system. Your binary executables necessarily include information about their format, including their architecture.
spaceheater ~ 0$ file/bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped
Second, why are you worried about compilers and version numbers if you're so sure people can't load modules anyway? What exactly are you trying to protect? There's something to be said for a minimalistic system, but you've yet to explain how having a compiler installed poses any sort of realistic security threat.
Finally, what's to keep someone from simply replacing your entire hand-complied, monolithic kernel? Even if you disable all the ways to do this without rebooting -- kexec() and/proc/kcore, probably among others -- they could always reboot the machine. Sure, you'd notice the reboot, but would you be able to detect their change after the reboot?
I'd also like to mention that OS-enforced append-only files are a poor substitute to logging to a hardware-enforced WORM drive, particularly if we're talking about rootkits. You're still fundamentally relaying on the OS to provide protection, which isn't reasonable when a rootkit has been installed.
With RAID-5, as with RAID-1, the critical number of disks is one. RAID-5 cannot transparently correct errors that occur on even a single stripe, unless you know a priori which stripe is affected.
Well, cannot correct errors that occur on a single stripe without being detected by the hardware. It's not like the underlying hardware won't notice bits being swapped about. But for the sake of argument I'll limit the scope to filesystem-bypassing block writes or the transformation of bits into so other configuration such that the disk still reads without error.
In that case you're right of course -- there's still less than 2 independent copies of the data in a standard RAID-5 array. I got excited with my RAID-6 an multi-layer RAID line of reasoning.
With RAID-6 you can automatically correct errors that occur on a single stripe, but it still does not automatically detect such errors on read the way ZFS and RAID-Z do.
What makes you say that? The choice to verify every read is purely an implementation decision -- RAID-6 provides all the necessary data. And in multi-layer RAID you likewise have enough copies of the data to transparently reconstruct after a single (or sometimes multiple) filesystem-bypassing write.
That's a great idea. Too bad those ZFS guys didn't think of it. Oh, wait.:)
I never suggested that ZFS didn't use a checksum. I was just arguing the novelity you seem to think ZFS has -- using checksums to verify data integrity is not exactly cutting-edge computer science.
I'm also not arguing the usefulness of having sufficiently redundant data storage so that you can transparently recover from a variety or errors. I'm just saying ZFS is neither the first nor the only way to accomplish this, and other solutions provide both maturity (at least on non-Sun platforms) and hardware acceleration.
And ZFS might have lots of other useful features that make it a great choice. I just don't think this particular feature is unique or superior to other available solutions for the same problem.
If two mirrored copies disagree on the contents of a block, the data is unrecoverable without manual intervention or external knowledge.
Or, you know, a checksum. Or more than one level of redundancy.
I agree that RAID-1 cannot, by itself, correctly recover from error-free reads of mis-matched data. But RAID 5 and 6 are both capable of verifying the primary data source against the parity data and transparently correcting errors that occur on less than the critical number of disks. In the common configuration this is only done when a hardware-level error is detected to keep things fast, but it's quite possible to verify every read if so your system is so configured. Mutli-layer RAID also provides this same sort of protection.
Hard drives silently losing data is a problem solved by RAID. I really don't see what additional protection this provides against hardware failures over any other filesystem on a RAID disk -- AFAICT it only protects against writes that bypass the file system without bypassing RAID.
There may be other benefits to ZFS, but I don't want to bog down my filesystem with data integrity calculations -- I have dedicated hardware for that.
Open competition can lead to a strong economy, or it could lead to a weak one. People seem to spend a lot of time complaining about how the open competition from overseas labor hurts our domestic economy, and how we should restrict it. I can't say I wholeheartedly agree with that viewpoint, but it's not completely unreasonable either.
Beside that, the second line in my post notes that I'm not claiming this particular activity is a valid use of the national security tactics to protect the economy, just that the general practice of protecting the economy in general is, in and of itself, a defense of national security.
If you read all the way to the second line in my message you'd see that I don't particularly believe that this data being released is a valid threat to national security. I was just objecting to the parent's asserition that protecting profits in general wasn't a reasonable national security activity.
He should be more fiscally responsible. Unfortunately "responsible" and "power hungry" don't go together well -- that's how we get the federal government.
Given that the security and stability of a nation is in large part a function of a sufficiently strong economy, "national security risks" and "risks to profit" are the same to some degree, regardless of your politics.
That's not to say this data should be kept secret, or that the "national security" banner isn't used to hide thing for political purposes, but it's silly to pretend that the economy plays no part in security.
That limits you to the area of a single circuit board in terms of through-mount connector space. Plus it's really complicated to assemble, and precludes the use of surface-mount chips, which are cheaper both to manufacture and assemble.
I'm thinking right-angle mounting would probably be your best bet -- think DIMMs on a motherboard -- but that still requires a bunch of connectors or complicated assembly.
I'm not saying there are no possible space gains to be had with solid-state, I just don't they're terribly significant as long as you're limited to the hard-drive form factor.
Now if you were willing to have a non-removable hard drive, you chould integrate the chips in clusters around the motherboard of a laptop, wherever there was enough space to put a few chips. It would be non-upgradable (or at least not easily upgradable) but it would allow for an effective use of space that isn't possible with a platter-based storage device.
While the poster wasn't clear, I believe he was trying to indicate that they don't show up as ITMS credit card transactions -- they are just generic retail transactions and could be from any number of products available at those stores.
I don't know about you, but I haven't seen a lot of circuit boards that are significantly thinner than a hard drive plater. You would get to reclaim of the of the space dedicated to the motor and the control arms, but you'd still need a case, connector, and interface board, and you'd still have to mount your storage chips on circuit boards within the case. I'm not seeing a whole lot of extra space in such an arrangement.
Since apparently missed the rounding lesson in third grade, here's your entire post transposed to reflect an equally likely scenario. Enjoy.
--
Will you be able to tell the difference at the end of a year?
Say you're buying a $5.22 lunch, five days a week. You're actually paying $5.20 a day.
Ten cents a week. $5.50 a year.
Add up all the pennies you gain by not being able to pay the penny amount, on all of your cash transactions - you might find that it's not insignificant over long periods of time. The ashtray of my truck is basically full of pennies - and every once in a while, I find that having a couple of dollars worth of pennies around is handy.
I would bet the store you're getting those one or two or three cents from does not see it as insignificant, considering that they may be paying that extra one to three cents on hundreds of transactions in a day. Extra expenses, paid to people who think that pennies don't matter!
Slashdot Mirror
So apparently anything that can be heated by a microwave and detected with an EM field is now an RFID tag? Are my Hot Pockets(tm) safe?
The link you provided show no evidence whatever that there is any sort of remote tracking system -- just that you can unevenly heat cash in a microwave. Even if you assume there were some sort of RF identifier in currency there's no evidence that it's unique to the bill; a demonination-unique RF marking in currency could aid in automated handling, handling by the blind, etc., without any particular threat of privacy loss, as there is no way to track a particular bill.
If you want anyone to take you seriously you should find a better link. Or, you know, actually test bills for RF reactivity and to prove the presense of an RF device. Or even mechanically or chemically disassamble a bill and physically locate the supposed RF device. Until then I'm gonna file this one next to "Microwaved Water Kills Plants".
Yes, light that barely misses the event horizon is bent so that it appears to come from a source much closer (in an angular sense) to the black hole. But not light that would actually be occluded by the black hole -- that light is still blocked. Take another look at the diagram; it shows objects that are angularly distant from the black hole appearing to be much closer, not objects occluded by the black hole being somehow visible from the far side.
You can't see through the black hole, but it will lens light around it. Unfortunately it pulls in the wrong direction to see things directly behind it. http://en.wikipedia.org/wiki/Einstein_ring
But I think you might be able to sell the "record on to a black hole" idea to the RIAA.
Not unless you consider mirrors to be copying devices. More than one person at a time can observe the original due to the divergent paths of reflected photons. I don't see how optical splitting would be any different.
Except magazines ads are sold based on circulation numbers not actual ad impressions, so there's no lost revenue. Internet ads are generally only counted by actual image-loaded impressions, not the total number of site visitors. But you're right, the concept is similar.
Curtains are also untrustworthy and should not be relied on for access restriction. A sufficiently bright light, or one of the proper wavelength, can penetrate them without significant hindrance.
But more to the point, their complaint is not that people accessed the site, just that they didn't do so in a way that generated ad revenue. If someone is technically inclined enough to strip or otherwise modify their headers to gain access they are certainly technically inclined enough to install AdBlock if they wanted to avoid ads.
Except if you took a high resoluiton picture you'd actually have a copy, distinct from the original. A better analogy might be an artist puts their painting in a gallery window, and you open a shop across the street and put in a telescope so people can see the orignal painting, People still have to go *somewhere* to see the painting, and you *haven't* made an unauthorized copy, you just removed the original context (the gallery window) and replaced it with your own shop.
Certainly it's not a nice thing to do, and I'd be angry if someone did it to me, but wouldn't you prefer that the gallery just to put up curtains (or check the referer header)? Do you really want the courts saying it's illegal to use a telescope across the street from any art gallery?
No, I'm expecting that I can buy a used phone for $30 from some other customer who already paid their $300 and who has since canceled their service. Or that I can use any technically compatible phone that I purchased from any other vendor. Why is the service provider the only place that I'm allowed to by phones?
So I can pay the cancelation fee at the start or the end of the contract? That's not much of a choice.
We already decided AT&T couldn't force us to buy their land-line phones; why are cellular companies allowed to do the same thing?
It's actually very difficult to bring your own phone in for new service with most carriers. It's even fairly difficult to bring your old phone from the same carrier back in to service if it's been deactivated for any period of time. With some carriers it can be done, but they don't make it easy.
I came up with 2/3 because you need to read the data and both parity stripes.
You only need to read one parity set unless you detect on error, and you need to read the original stripe regardless. You would only need the second set of parity data to determine which set of data is accurate in case of a conflict; in the general case the first parity set will match with data, and the second parity set can be ignored.
Actually it's worse than that, you need to read all the stripes to validate any given block, just as you do in a write operation. For example in the minimal 4 disk RAID-6 array, reading and verifying will be 4 times slower than reading without verifying.
When I read from RAID-6 without verifying I need to read the stripe itself. When I read with verification I need to read the stripe and one of the parity sets, which is 1/2 the size of the stripe. I come up with 100% + 50% = 150%. That's only 1/3 of the disk bandwidth going to parity data. Obviously you've got some other read/verify algorithm in mind, but I don't know why.
And that 50% overhead is still assuming that the parity data isn't cached and that the parity read (which is on a physically seperate disk) blocks other operations.
ZFS calculates checksums on a (variable size) block level. Compared with IO bandwidth, CPU and memory bandwidth are virtually free and getting cheaper all the time.
I don't know what systems you've been using, but it's been a long time since my memory bandwidth has jumped up any considerable amount. Overall bus speed is slowly gaining, but processor speed is still pulling away from bus speed, and unless there's some breakthough in bus technology that's like to continue to be true.
ZFS has an enormous advantage over md5sum: it is completely transparent to the user. I'd say that md5sum is the problem, and ZFS is the solution.
In many applications, md5 is completely transparent to the user. Run any modern package management system -- it fetches archives and their checksums and notes errors and in many cases refetches automatically in an attempt to correct the error. And it actually provides higher data integrity than ZFS's filesystem-level checking, because it actually knows what's supposed to be in the file, not just what the file system last thought was supposed to be in the file. As others have noted, it's not really end-to-end unless one of the ends is "program consuming data" -- with md5 that's possible, with ZFS it's not.
The underlying hardware will not necessarily notice errors. Hard drives are only designed to error protect the magnetic domains on the disk. There are all sorts of other places in the increasingly long datapath to disk where data can be lost, and, in fact, routinely does get lost.
Routinely does get lost is a bit of strech at best. If my data routinely got lost between the disk and the motherboard I'm pretty sure I'd notice. There are occasional transmission errors along physical data paths; if only someone had used your magical ZFS checksums when designing Ethernet or IP or SCSI to deal with these sorts of errors.
I know your link talks about how terrible firmware in SAN devices can be, but I have a hard time beliving that data integrity errors in a data storage device would go undiscovered for too long. If you're complaining about that you might as well whine about bad hard drive firmware or bad Ethernet firmware or bad RAM. In theory you could add protections for all those things, but it doesn't seem very useful to me; why not just test the system an to empirically discover such faults?
RAID-6 does not verify every read because it is a stupid way to achieve data integrity. It wastes two thirds of your aggregate IO read bandwidth when you can just use checksums virtually for free. CPU cycles for checksumming is dirt cheap whereas IO bandwidth is extremely expensive.
I don't know what kind of RAID-6 you use, but mine creates parity data that's significantly smaller than the original. I can't even guess at where you got the 2/3 number; the one I come up with is more like 1/3 worst-case-scenario, and that's only at the physical disk level, not at the host-interface level. And that worst-case scenario assumes that you haven't recently and weren't going to read the partiy data in the first place, and that reading parity data prevents you from completing other operations. I'll grant you that checksums are potentially more efficient from a data throughput standpoint, but let's try to stick to realistic numbers.
It's also worth noting that, while the checksum in ZFS is small, the entire data set much be read from memory and processed to calculate the checksum, in addition to whatever you plan to do with the data after you've done the integrity check. I/O starvation is not limited to disks; almost any busy system spends a huge amount of time waiting for data to come across the system bus from the RAM to the CPU. This is also not a task that can be entirely offloaded, even if you added a dedicated checksumming card or processor; given the end-to-end nature of ZFS, data would still have to come across the system bus to get to the card.
I'll admit there are things ZFS protects against that other systems do not, but those things don't seem any more likely to me than the possibility of a similar error in the ZFS system. For example, Mr. Bonwick sights bad firmware as a possible error. But how is an implementation error that causes a ghost write in my hard drive any more likely or difficult to detect than an implementation error that introduces a ghost write at the ZFS level?
If the data-integrity benefits of ZFS require that ZFS be implemented perfectly and only protects me from implementation errors in other, generally simpler systems, I'm not seeing a lot of practical benefit here. Belt-and-suspenders I guess, but nothing very pragmatic, since we're already talking about the very small percentage of the time that A) an error occurs and B) cannot be detected by all the existing data-integrity checking already in place. Not to mention the fact that, at least until ZFS is mature on non-Sun systems, I see the possibility of an error in the implementation of ZFS as much greater than the possibility of an error between my physical disk and my motherboard.
Yet strangely there aren't any other widely available storage solutions that provide transparent data integrity from the filesystem down.
No, but I can name several that provide it at both a higher and
First, let me introduce you to the file command, which can tell me all about your arch. Or failing that, less, or any other program than can read any binary on your system. Your binary executables necessarily include information about their format, including their architecture.
Second, why are you worried about compilers and version numbers if you're so sure people can't load modules anyway? What exactly are you trying to protect? There's something to be said for a minimalistic system, but you've yet to explain how having a compiler installed poses any sort of realistic security threat.
Finally, what's to keep someone from simply replacing your entire hand-complied, monolithic kernel? Even if you disable all the ways to do this without rebooting -- kexec() and /proc/kcore, probably among others -- they could always reboot the machine. Sure, you'd notice the reboot, but would you be able to detect their change after the reboot?
I'd also like to mention that OS-enforced append-only files are a poor substitute to logging to a hardware-enforced WORM drive, particularly if we're talking about rootkits. You're still fundamentally relaying on the OS to provide protection, which isn't reasonable when a rootkit has been installed.
With RAID-5, as with RAID-1, the critical number of disks is one. RAID-5 cannot transparently correct errors that occur on even a single stripe, unless you know a priori which stripe is affected.
:)
Well, cannot correct errors that occur on a single stripe without being detected by the hardware. It's not like the underlying hardware won't notice bits being swapped about. But for the sake of argument I'll limit the scope to filesystem-bypassing block writes or the transformation of bits into so other configuration such that the disk still reads without error.
In that case you're right of course -- there's still less than 2 independent copies of the data in a standard RAID-5 array. I got excited with my RAID-6 an multi-layer RAID line of reasoning.
With RAID-6 you can automatically correct errors that occur on a single stripe, but it still does not automatically detect such errors on read the way ZFS and RAID-Z do.
What makes you say that? The choice to verify every read is purely an implementation decision -- RAID-6 provides all the necessary data. And in multi-layer RAID you likewise have enough copies of the data to transparently reconstruct after a single (or sometimes multiple) filesystem-bypassing write.
That's a great idea. Too bad those ZFS guys didn't think of it. Oh, wait.
I never suggested that ZFS didn't use a checksum. I was just arguing the novelity you seem to think ZFS has -- using checksums to verify data integrity is not exactly cutting-edge computer science.
I'm also not arguing the usefulness of having sufficiently redundant data storage so that you can transparently recover from a variety or errors. I'm just saying ZFS is neither the first nor the only way to accomplish this, and other solutions provide both maturity (at least on non-Sun platforms) and hardware acceleration.
And ZFS might have lots of other useful features that make it a great choice. I just don't think this particular feature is unique or superior to other available solutions for the same problem.
If two mirrored copies disagree on the contents of a block, the data is unrecoverable without manual intervention or external knowledge.
Or, you know, a checksum. Or more than one level of redundancy.
I agree that RAID-1 cannot, by itself, correctly recover from error-free reads of mis-matched data. But RAID 5 and 6 are both capable of verifying the primary data source against the parity data and transparently correcting errors that occur on less than the critical number of disks. In the common configuration this is only done when a hardware-level error is detected to keep things fast, but it's quite possible to verify every read if so your system is so configured. Mutli-layer RAID also provides this same sort of protection.
Hard drives silently losing data is a problem solved by RAID. I really don't see what additional protection this provides against hardware failures over any other filesystem on a RAID disk -- AFAICT it only protects against writes that bypass the file system without bypassing RAID.
There may be other benefits to ZFS, but I don't want to bog down my filesystem with data integrity calculations -- I have dedicated hardware for that.
Open competition can lead to a strong economy, or it could lead to a weak one. People seem to spend a lot of time complaining about how the open competition from overseas labor hurts our domestic economy, and how we should restrict it. I can't say I wholeheartedly agree with that viewpoint, but it's not completely unreasonable either.
Beside that, the second line in my post notes that I'm not claiming this particular activity is a valid use of the national security tactics to protect the economy, just that the general practice of protecting the economy in general is, in and of itself, a defense of national security.
If you read all the way to the second line in my message you'd see that I don't particularly believe that this data being released is a valid threat to national security. I was just objecting to the parent's asserition that protecting profits in general wasn't a reasonable national security activity.
He should be more fiscally responsible. Unfortunately "responsible" and "power hungry" don't go together well -- that's how we get the federal government.
Given that the security and stability of a nation is in large part a function of a sufficiently strong economy, "national security risks" and "risks to profit" are the same to some degree, regardless of your politics.
That's not to say this data should be kept secret, or that the "national security" banner isn't used to hide thing for political purposes, but it's silly to pretend that the economy plays no part in security.
That limits you to the area of a single circuit board in terms of through-mount connector space. Plus it's really complicated to assemble, and precludes the use of surface-mount chips, which are cheaper both to manufacture and assemble.
I'm thinking right-angle mounting would probably be your best bet -- think DIMMs on a motherboard -- but that still requires a bunch of connectors or complicated assembly.
I'm not saying there are no possible space gains to be had with solid-state, I just don't they're terribly significant as long as you're limited to the hard-drive form factor.
Now if you were willing to have a non-removable hard drive, you chould integrate the chips in clusters around the motherboard of a laptop, wherever there was enough space to put a few chips. It would be non-upgradable (or at least not easily upgradable) but it would allow for an effective use of space that isn't possible with a platter-based storage device.
While the poster wasn't clear, I believe he was trying to indicate that they don't show up as ITMS credit card transactions -- they are just generic retail transactions and could be from any number of products available at those stores.
I don't know about you, but I haven't seen a lot of circuit boards that are significantly thinner than a hard drive plater. You would get to reclaim of the of the space dedicated to the motor and the control arms, but you'd still need a case, connector, and interface board, and you'd still have to mount your storage chips on circuit boards within the case. I'm not seeing a whole lot of extra space in such an arrangement.
Since apparently missed the rounding lesson in third grade, here's your entire post transposed to reflect an equally likely scenario. Enjoy.
--
Will you be able to tell the difference at the end of a year?
Say you're buying a $5.22 lunch, five days a week. You're actually paying $5.20 a day.
Ten cents a week.
$5.50 a year.
Add up all the pennies you gain by not being able to pay the penny amount, on all of your cash transactions - you might find that it's not insignificant over long periods of time. The ashtray of my truck is basically full of pennies - and every once in a while, I find that having a couple of dollars worth of pennies around is handy.
I would bet the store you're getting those one or two or three cents from does not see it as insignificant, considering that they may be paying that extra one to three cents on hundreds of transactions in a day. Extra expenses, paid to people who think that pennies don't matter!