Some of us live in a part of the world where we actually take assigned seats for granted. I actually like being able to see beforehand in which location I will be sitting so I can decide whether I want to buy that ticket or not. It must really suck to buy a ticket not knowing which seat you will get - I mean who wants to buy a ticket and then end up in the worst seat in the cinema?
When I buy tickets I usually pay with card, so yes it would in theory be possible to track down which seat I was sitting at. But you know often I go to the cinema together with friends, and usually one person pays all the tickets, so in that case you really won't know who was in what seat. Besides, unless they manage to fill the cinema, they can't be sure people are actually sitting on exactly the seat which they bought. It does sometimes happen that somebody reserves the best seats and don't show up. In that case usually somebody else will be sitting there rather than in the seats they reserved themselves. There really isn't much of a chance of knowing.
I like going to the cinema (I actually just came back from Men who hates women aka The Girl with the Dragon Tattoo), and I will probably keep going. If this kind of watermarking starts taking off I might start paying cash, just to avoid any false accusations (I don't trust their accuracy). But if they start annoying paying customers too much in their attempt to fight piracy, I might stop going.
What if I'm in the Canada, and buy (from a US company) a GPL program which comes with a written offer to provide the source. Then a month I move to Cuba, and send a letter to the US company asking them to please send me the source (including proof of purchase, and cash to cover costs of copying and sending the source code back to me)
What does the US company do now?
They are screwed. They either have to violate the USA law, or violate the license and thereby losing the rights to distribute the software. They could have prevented this exact scenario by giving the sources to begin with instead of the offer to give them at a later time. I'm still not certain if they are violating the law by giving the software to somebody who then later take it to Cuba.
But that is not the only risk a company runs by placing their headquarter in USA. If they end up having departments in different countries, USA law requires their departments abroad to discriminate against people from certain countries. That may very well be illegal in the country where that department is actually based. That way a company could end up in a situation where the company would be violating the law of one of the countries no matter what they do. In short, it is risky to do business in a country that try to make laws about what happens outside its own borders.
The best thing is that capabilities on the system calls would essentially be a per-process bitmap with as many entries as the system call table, and require only a couple extra instructions to check on each system call. I might do that later today, just for fun...
5. Drop all capabilities to system calls except for sys_read, sys_write, and sys_exit.
I like this idea (I even suggested it myself at some point in the past). I don't think it has been implemented, but it should be a fairly simple change to the kernel. There is one issue with memory management though. The kernel already has the ability to restrict the amount of memory a process can use, but the process still need to make some system call to allocate it. This leaves a few options.
Allocate a fixed amount of memory, which is of course going to waste memory in many cases.
Allow the brk/sbrk calls, which are very simplistic so you are still likely to waste memory in some cases because you cannot free memory in arbitrary orders.
Allow mmap/munmap, which are flexible enough, but more complicated calls that have been attack vectors to kernel exploits in the past.
Allow brk/sbrk to allocate memory an munmap to free it. That way you don't wast memory, but you constantly leak address space. On a 32 bit architecture that leaking of address space means your application is going to run out and then have to be restarted. On a 64 bit architecture you may have sufficient address space that you won't have to worry about this in many cases. Never reusing address space does have the additional advantage, that many use after free bugs are easier to debug.
Nobody enjoyed accidentally visiting a web page that used a Java applet because your entire system would grind to a halt for 10 seconds whilst the JVM would heave its bloated carcass into RAM. I am told the very latest versions of Java fix this
When the first Java version came out, 32MB of RAM was unusual for a desktop machine. A decade later I found myself employed as Java developer and frequently had the need to run 4 JVMs concurrently on a machine with 1GB of RAM. Turns out that would slow the machine to a crawl, even though the machine had 256MB of RAM per JVM and way more CPU power than you could dream of when Java was first introduced to the world. This makes me wonder if the fix was to add more RAM to the machines, or whether Java applications just became that much more heavy during that decade.
Tons of useful and well debugged code had already been written in C and C++ but Java only had weak support for it (jni is awful), and of course there was no internet deployment system for jni. NaCL lets you reuse your investment in existing native code.
I agree with your point about Java's initial drawback, but in the meantime a lot of Java code has been written. Today it is a little less clear which of the languages have the most useful code available. How much work would it be to make use of Java code under NaCl? I think it would be a nonzero amount of work, but possibly less than porting code from C to Java.
you probably lied to get set up an "anonymous" account, thus violating some TOS.
So what. That doesn't matter unless the site owner cares. A lot of sites allow you to write anonymous postings. And a lot of sites don't care if you violate the TOS a little bit as long as you don't harm the use of that site for other users. Really, many sites have a TOS just for the repetitive abuse cases and to be able to shut off abusers without being sued by the abusers. I'm not in a position to speak for specific sites of course.
BTW. Is a discussion site required to log any information about who wrote comments? It's easy to create a forum where no records are kept about who wrote a posting. I don't know how those warnings are supposed to work either. For example on slashdot, you are not notified about replies to any comment you wrote anonymously. How would you know that a warning was posted. Besides, what if the warning is modded down to -1 and the user who posted the original posting has configured it to not show comments at -1? Is the warning still valid in that case? What if the forum is actually moderated, and the moderator don't get around to accept the warning? What if the forum is hosted in a different country? It's plausible to have a forum hosted in one country, but the majority of the users living in a different country.
Using TOR, your neighbor's open WiFi, etc, all compound your crimes.
If somebody decides to give you some kind of access to their network connection through TOR or a WiFi access point, then using that access is not a crime. There are of course a few questions that could be asked. First of all the ISP may claim that providing such access is a violation of the terms on the connection. It's not clear whether an ISP is really allowed to impose restrictions on who a customer allow access to their own computer/access point, besides even if those restrictions are valid, it is the owner of the connection rather than the user who is violating it. And I don't think it is a criminal offense to violate the terms on your internet connection. Of course the owner may claim the access was not granted intentional, just to keep his own ass covered. Even if the access was not opened intentional, it is not something the user would always know. There are people who deliberately leave their access points open, and there is no way for a user to tell the difference. For tor you'd generally assume most people who run it does so deliberately, so even if a single owner of a machine running it claims it was unintentional, I doubt anybody would be violating any laws by using it.
Threads was havey in Linux due to bad implementation until kernel 2.6. Threads, until 2.6, was just a wrapper using process.
You are confusing the matters. The main problem with threads in earlier Linux versions were that they were not posix compliant. Threads in Linux actually offered a lot of features beyond those required by posix, and could be put to good use by programs written specifically for Linux. If you tried to make programs written for the posix thread API run on Linux things got messy. It wasn't actually performance that was the problem, but rather that the semantics of certain things were not exactly like they should be.
Saying that threads were a wrapper using processes is nonsense. If you created threads in Linux 2.4 they really were threads and performance was what you would expect from threads. In Linux 2.4 context switches between threads really were cheaper than between processes. However the naming of threads was not what you would expect from a posix system, each thread was assigned a pid, and you could get that with getpid(). In terms of process tree, signal handling, and various other aspects they behaved like processes, but in terms of shared address space and performance, they behaved like threads, because that is what they were. Having a nonstandard naming convention for threads doesn't mean that the performance goes down.
In Linux 2.6 the semantics of threads were changed to comply with posix. First of all each thread would now have both a thread id returned by gettid() and a thread group id returned by getpid(). In fact the id was assigned in exactly the same way as in 2.4, but just called a thread id instead of a process id, in addition to that the thread group id would be inherited from the parent. So when you create a process its process id and thread id are the same, but it can then create child threads, that inherit the process id and have a different thread id.
A few other things related to the thread ids were changed. For example the list of processes in/proc that used to list all threads on the system now only list the first in each group. (But you can still find a list of all threads elsewhere). And the semantics for signals changed, and there is a system call to terminate all threads in the group. But all of this is really just minor tweaks to the semantics of various system calls, it doesn't require any changes in how threads are actually implemented by the kernel.
There also were changes to improve performance, but those are completely unrelated to the semantic changes. Before those changes were made to Linux the performance was actually compared to Windows, and at the time processes in Linux were cheaper than threads in Windows. (Of course in each OS threads were cheaper than processes).
Seriously, it's almost trivial to completely avoid spam now.
It is trivial if you tolerate false positives. But if you cannot accept false positives, it is not trivial. The problem isn't solved until everybody who has a legitimate use for email can set up their own server on which they don't receive any significant amount of spam and at the same time gets all legitimate emails through. Try it, and you will see, that it is not easy. In fact it is already almost impossible to set up a server in a way that give you no false positives. Even if you don't do any filtering yourself, a lot of the emails you send will get filtered in the other end. I don't think anybody have a worldwide statistic on the amount of false positives, but I am sure it would be a scary number.
Breaking passwords is *technically* illegal, for any purpose..
System administrators systematically do this to find users with weak passwords. And I am not aware of any law that forbids taking a hashed password and try to find the original. Using the password afterwards to impersonate the user is a completely different matter.
He didn't provide us with a list of user names and passwords. We don't know about the exact circumstances under which he received them. You don't become a criminal just because somebody decides to send you something. Finding out which are the most popular passwords is a pretty harmless thing to do. If anything it should be a criminal offense to pick such a weak password to begin with. Of course breaking in to get the list of passwords and transferring it to somebody else isn't legal. Using those passwords to log in to those accounts wouldn't be legal either. But he didn't do any of those.
This is supposed to protect the key while the system is locked, and a password is used to unlock the screen. But if a password is required to unlock anyway, the key doesn't even have to be accessible while the system is locked, the password itself could be used to decrypt the key while unlocking. Of course there is a drawback in that any disk operations would have to be delayed until the system is unlocked, that might not be acceptable for all users.
The simplest way to implement my proposal would probably be to suspend the system instead of just locking the screen (like you do if you are not going to be using your laptop for a few hours). It just has to be implemented correctly such that the key really isn't available until decrypted using the password that you enter when waking it up.
If you want to lock your laptop and leave it doing things in the background requiring disk access, then the idea from this article might be valuable. There are other possibilities, one alternative is to store the key in special cryptographic hardware from where it can't just be read out (I haven't thought through the details of such a design, there are obviously some hurdles that would need to be sorted out). Or you could make some use of asymmetric cryptography, I don't think any storage encryption currently does that, since it could have a performance penalty, but it would provide some protection against attacks like this. You could also use ciphers that are less vulnerable to this kind of attack. Part of the attack is to use the key schedule as a kind of error correcting encoding that will help recovering the key. Key schedules are typically designed with performance in mind, and this kind of attack is not considered. But for most storage encryptions the performance of the key schedule isn't important, so a different key schedule could be designed to have no error correcting properties. (I think that just means the function mapping from key to key schedule would have to be a PRNG).
Either because it hadn't occurred otherwise to them or because they think they *are* average when they're far from it.
The average person does not exist. No matter which person you look at, that person will be far from the average in several aspects. (What those several aspects are will of course depend on which person you are looking at).
If you doubled the density of the drive by storing 2 bits on top and reading both the "current" and "previous" values, you wouldn't get anywhere near that high of a recovery, and you would need to use at least as much data as you saved in order to store the necessary error correction data.
But that is not true. The current value in itself would be used exactly the way it currently is and thus give the same amount of capacity as we have today, any capacity that you could get out of the previous values would thus mean an increase in capacity. If the previous values can be read correctly with a probability high enough to matter in case of recovery, then that can be used with an error correcting encoding to get some additional capacity. You need to know aproximately what the probability is in order to design the encoding. Let's for a moment assume you get a correct bit with 60% probability and a wrong bit with 40% probability. An error correcting code could then repeat each bit 125 times and use the majority when reading to get a correct result with 99% probability. That's a very simplistic approach, you can design a better encoding that utilizes capacity better, you just have to know how reliable you can read data from the physical media and how reliable you want the result to be.
Your redundant encoding would take at least as much extra space as you saved by increasing the data density.
No.
Assuming the numbers in the comment I replied to are correct, the redundant encoding would take just a few percent when doubling the density for a net gain of more than 90% in capacity.
Low level formatting overwrites every sector, but for hard drives, that's done at the factory, or using software made specifically for that drive (you might be able to download it from the drive manufacturer). Oh, and it takes a lot of time, much more than a (non-quick) high level format.
The format program I saw actually read all sectors on the disk, so it wasn't any faster than it would have been to write all sectors.
If you have a 99.990% success rate at reading previously erased data, that is still one error every 10 kilobytes. Acceptable for recovery, not so much for everyday use.
As long as you know what probability you have and what probability you want, you can design an appropriate redundant encoding to achieve that. So if you really could read overwritten data with that success rate, then drives would indeed be using it.
How can software get past the fact that the hard disk controller will be handing the OS all 0's?
Probably the data wasn't actually overwritten with all 0s. When playing around with emulators at some point in the past I came across a DOS version where the FORMAT command would actually never overwrite the harddisk with 0s. It would read all sectors to find out if there were any unreadable, and then it would write to the metadata areas on the disk.
Wouldn't setting security.ssl3.rsa_rc4_128_md5 to false prohibit these kind of attacks?
After reading about it on lwn.net, I learned that this setting does not protect you against this particular problem (but setting it to false doesn't hurt). I also learned that the certificate for lwn.net is signed using md5, so if the setting worked you would get a warning or error when trying to access lwn.net with https. If you want to try it out yourself here are two sites with md5 based certificates lwn.net and ssl247.com. It's just the leaves that are signed using md5, if the attack was used it would moste likely be an intermediate CA that was signed using md5. I tested this in both firefox and seamonkey, neither gave any warning.
Unless you shut down the db, then the filesystem and data on the drive you pull is not consistent.
If the system is working correctly the drive you pull out will be consistent. If you lose power at any point in time your database is supposed to guarantee that the data on disk will be in a consistent state once the system is back. That may involve some kind of roll back or a journal replay. But in the end you will have a consistent data base.
As others have already pointed out, if you do this, you have to have three mirrors for safety. And the additional load to resync when you put in another drive may be a problem. But if a single disk can handle normal workloads while the second disk is being replicated to the third disk, you might have a chance of doing that trick without hurting performance too much. Of course writes to the database have to be done to all three disks during the rebuild, so the normal workload will slow down the rebuild significantly. If you are using really large disks, don't be surprised if it takes a day to finish the rebuild.
Someone said that hot swap connectors are not designed for swapping on a daily basis. That might be true. But then you can do the trick logically rather than physically. Run RAID-1 across three disks. Tell the RAID to pull one disk out. On the same machine you can then access that single disk to make a backup to an off-site location. Once you are done with your backup put the disk back in the RAID. Of course before starting the procedure you have to verify that the RAID is actually running on all three disks. If the RAID is already short, that has to be resolved before starting the backup.
I'm not saying this is a good way to backup a database. But it certainly is doable without introducing unacceptable risks in the process. But you really have to know what you are doing.
Slashdot Mirror
Some of us live in a part of the world where we actually take assigned seats for granted. I actually like being able to see beforehand in which location I will be sitting so I can decide whether I want to buy that ticket or not. It must really suck to buy a ticket not knowing which seat you will get - I mean who wants to buy a ticket and then end up in the worst seat in the cinema?
When I buy tickets I usually pay with card, so yes it would in theory be possible to track down which seat I was sitting at. But you know often I go to the cinema together with friends, and usually one person pays all the tickets, so in that case you really won't know who was in what seat. Besides, unless they manage to fill the cinema, they can't be sure people are actually sitting on exactly the seat which they bought. It does sometimes happen that somebody reserves the best seats and don't show up. In that case usually somebody else will be sitting there rather than in the seats they reserved themselves. There really isn't much of a chance of knowing.
I like going to the cinema (I actually just came back from Men who hates women aka The Girl with the Dragon Tattoo), and I will probably keep going. If this kind of watermarking starts taking off I might start paying cash, just to avoid any false accusations (I don't trust their accuracy). But if they start annoying paying customers too much in their attempt to fight piracy, I might stop going.
Pretty much the same joke was on xkcd not so long ago.
They are screwed. They either have to violate the USA law, or violate the license and thereby losing the rights to distribute the software. They could have prevented this exact scenario by giving the sources to begin with instead of the offer to give them at a later time. I'm still not certain if they are violating the law by giving the software to somebody who then later take it to Cuba.
But that is not the only risk a company runs by placing their headquarter in USA. If they end up having departments in different countries, USA law requires their departments abroad to discriminate against people from certain countries. That may very well be illegal in the country where that department is actually based. That way a company could end up in a situation where the company would be violating the law of one of the countries no matter what they do. In short, it is risky to do business in a country that try to make laws about what happens outside its own borders.
If you do, let me know where to find the patch.
Gary shouldn't expect me to work a lot this week. After all I am on vacation.
I like this idea (I even suggested it myself at some point in the past). I don't think it has been implemented, but it should be a fairly simple change to the kernel. There is one issue with memory management though. The kernel already has the ability to restrict the amount of memory a process can use, but the process still need to make some system call to allocate it. This leaves a few options.
When the first Java version came out, 32MB of RAM was unusual for a desktop machine. A decade later I found myself employed as Java developer and frequently had the need to run 4 JVMs concurrently on a machine with 1GB of RAM. Turns out that would slow the machine to a crawl, even though the machine had 256MB of RAM per JVM and way more CPU power than you could dream of when Java was first introduced to the world. This makes me wonder if the fix was to add more RAM to the machines, or whether Java applications just became that much more heavy during that decade.
I agree with your point about Java's initial drawback, but in the meantime a lot of Java code has been written. Today it is a little less clear which of the languages have the most useful code available. How much work would it be to make use of Java code under NaCl? I think it would be a nonzero amount of work, but possibly less than porting code from C to Java.
So what. That doesn't matter unless the site owner cares. A lot of sites allow you to write anonymous postings. And a lot of sites don't care if you violate the TOS a little bit as long as you don't harm the use of that site for other users. Really, many sites have a TOS just for the repetitive abuse cases and to be able to shut off abusers without being sued by the abusers. I'm not in a position to speak for specific sites of course.
BTW. Is a discussion site required to log any information about who wrote comments? It's easy to create a forum where no records are kept about who wrote a posting. I don't know how those warnings are supposed to work either. For example on slashdot, you are not notified about replies to any comment you wrote anonymously. How would you know that a warning was posted. Besides, what if the warning is modded down to -1 and the user who posted the original posting has configured it to not show comments at -1? Is the warning still valid in that case? What if the forum is actually moderated, and the moderator don't get around to accept the warning? What if the forum is hosted in a different country? It's plausible to have a forum hosted in one country, but the majority of the users living in a different country.
If somebody decides to give you some kind of access to their network connection through TOR or a WiFi access point, then using that access is not a crime. There are of course a few questions that could be asked. First of all the ISP may claim that providing such access is a violation of the terms on the connection. It's not clear whether an ISP is really allowed to impose restrictions on who a customer allow access to their own computer/access point, besides even if those restrictions are valid, it is the owner of the connection rather than the user who is violating it. And I don't think it is a criminal offense to violate the terms on your internet connection. Of course the owner may claim the access was not granted intentional, just to keep his own ass covered. Even if the access was not opened intentional, it is not something the user would always know. There are people who deliberately leave their access points open, and there is no way for a user to tell the difference. For tor you'd generally assume most people who run it does so deliberately, so even if a single owner of a machine running it claims it was unintentional, I doubt anybody would be violating any laws by using it.
I'll just pretend I heard it from an anonymous coward on slashdot.
You are confusing the matters. The main problem with threads in earlier Linux versions were that they were not posix compliant. Threads in Linux actually offered a lot of features beyond those required by posix, and could be put to good use by programs written specifically for Linux. If you tried to make programs written for the posix thread API run on Linux things got messy. It wasn't actually performance that was the problem, but rather that the semantics of certain things were not exactly like they should be.
/proc that used to list all threads on the system now only list the first in each group. (But you can still find a list of all threads elsewhere). And the semantics for signals changed, and there is a system call to terminate all threads in the group. But all of this is really just minor tweaks to the semantics of various system calls, it doesn't require any changes in how threads are actually implemented by the kernel.
Saying that threads were a wrapper using processes is nonsense. If you created threads in Linux 2.4 they really were threads and performance was what you would expect from threads. In Linux 2.4 context switches between threads really were cheaper than between processes. However the naming of threads was not what you would expect from a posix system, each thread was assigned a pid, and you could get that with getpid(). In terms of process tree, signal handling, and various other aspects they behaved like processes, but in terms of shared address space and performance, they behaved like threads, because that is what they were. Having a nonstandard naming convention for threads doesn't mean that the performance goes down.
In Linux 2.6 the semantics of threads were changed to comply with posix. First of all each thread would now have both a thread id returned by gettid() and a thread group id returned by getpid(). In fact the id was assigned in exactly the same way as in 2.4, but just called a thread id instead of a process id, in addition to that the thread group id would be inherited from the parent. So when you create a process its process id and thread id are the same, but it can then create child threads, that inherit the process id and have a different thread id.
A few other things related to the thread ids were changed. For example the list of processes in
There also were changes to improve performance, but those are completely unrelated to the semantic changes. Before those changes were made to Linux the performance was actually compared to Windows, and at the time processes in Linux were cheaper than threads in Windows. (Of course in each OS threads were cheaper than processes).
It is trivial if you tolerate false positives. But if you cannot accept false positives, it is not trivial. The problem isn't solved until everybody who has a legitimate use for email can set up their own server on which they don't receive any significant amount of spam and at the same time gets all legitimate emails through. Try it, and you will see, that it is not easy. In fact it is already almost impossible to set up a server in a way that give you no false positives. Even if you don't do any filtering yourself, a lot of the emails you send will get filtered in the other end. I don't think anybody have a worldwide statistic on the amount of false positives, but I am sure it would be a scary number.
System administrators systematically do this to find users with weak passwords. And I am not aware of any law that forbids taking a hashed password and try to find the original. Using the password afterwards to impersonate the user is a completely different matter.
He didn't provide us with a list of user names and passwords. We don't know about the exact circumstances under which he received them. You don't become a criminal just because somebody decides to send you something. Finding out which are the most popular passwords is a pretty harmless thing to do. If anything it should be a criminal offense to pick such a weak password to begin with. Of course breaking in to get the list of passwords and transferring it to somebody else isn't legal. Using those passwords to log in to those accounts wouldn't be legal either. But he didn't do any of those.
This is supposed to protect the key while the system is locked, and a password is used to unlock the screen. But if a password is required to unlock anyway, the key doesn't even have to be accessible while the system is locked, the password itself could be used to decrypt the key while unlocking. Of course there is a drawback in that any disk operations would have to be delayed until the system is unlocked, that might not be acceptable for all users.
The simplest way to implement my proposal would probably be to suspend the system instead of just locking the screen (like you do if you are not going to be using your laptop for a few hours). It just has to be implemented correctly such that the key really isn't available until decrypted using the password that you enter when waking it up.
If you want to lock your laptop and leave it doing things in the background requiring disk access, then the idea from this article might be valuable. There are other possibilities, one alternative is to store the key in special cryptographic hardware from where it can't just be read out (I haven't thought through the details of such a design, there are obviously some hurdles that would need to be sorted out). Or you could make some use of asymmetric cryptography, I don't think any storage encryption currently does that, since it could have a performance penalty, but it would provide some protection against attacks like this. You could also use ciphers that are less vulnerable to this kind of attack. Part of the attack is to use the key schedule as a kind of error correcting encoding that will help recovering the key. Key schedules are typically designed with performance in mind, and this kind of attack is not considered. But for most storage encryptions the performance of the key schedule isn't important, so a different key schedule could be designed to have no error correcting properties. (I think that just means the function mapping from key to key schedule would have to be a PRNG).
The average person does not exist. No matter which person you look at, that person will be far from the average in several aspects. (What those several aspects are will of course depend on which person you are looking at).
You don't need to use the paradigm word. Leveraging synergies is a win-win.
If you consider one to be quite a few, then I suppose you are right.
But that is not true. The current value in itself would be used exactly the way it currently is and thus give the same amount of capacity as we have today, any capacity that you could get out of the previous values would thus mean an increase in capacity. If the previous values can be read correctly with a probability high enough to matter in case of recovery, then that can be used with an error correcting encoding to get some additional capacity. You need to know aproximately what the probability is in order to design the encoding. Let's for a moment assume you get a correct bit with 60% probability and a wrong bit with 40% probability. An error correcting code could then repeat each bit 125 times and use the majority when reading to get a correct result with 99% probability. That's a very simplistic approach, you can design a better encoding that utilizes capacity better, you just have to know how reliable you can read data from the physical media and how reliable you want the result to be.
No. Assuming the numbers in the comment I replied to are correct, the redundant encoding would take just a few percent when doubling the density for a net gain of more than 90% in capacity.
The format program I saw actually read all sectors on the disk, so it wasn't any faster than it would have been to write all sectors.
As long as you know what probability you have and what probability you want, you can design an appropriate redundant encoding to achieve that. So if you really could read overwritten data with that success rate, then drives would indeed be using it.
Probably the data wasn't actually overwritten with all 0s. When playing around with emulators at some point in the past I came across a DOS version where the FORMAT command would actually never overwrite the harddisk with 0s. It would read all sectors to find out if there were any unreadable, and then it would write to the metadata areas on the disk.
Is there eventually going to be a facebook group of terrorists? It would almost be too easy to find them then.
After reading about it on lwn.net, I learned that this setting does not protect you against this particular problem (but setting it to false doesn't hurt). I also learned that the certificate for lwn.net is signed using md5, so if the setting worked you would get a warning or error when trying to access lwn.net with https. If you want to try it out yourself here are two sites with md5 based certificates lwn.net and ssl247.com. It's just the leaves that are signed using md5, if the attack was used it would moste likely be an intermediate CA that was signed using md5. I tested this in both firefox and seamonkey, neither gave any warning.
If the system is working correctly the drive you pull out will be consistent. If you lose power at any point in time your database is supposed to guarantee that the data on disk will be in a consistent state once the system is back. That may involve some kind of roll back or a journal replay. But in the end you will have a consistent data base.
As others have already pointed out, if you do this, you have to have three mirrors for safety. And the additional load to resync when you put in another drive may be a problem. But if a single disk can handle normal workloads while the second disk is being replicated to the third disk, you might have a chance of doing that trick without hurting performance too much. Of course writes to the database have to be done to all three disks during the rebuild, so the normal workload will slow down the rebuild significantly. If you are using really large disks, don't be surprised if it takes a day to finish the rebuild.
Someone said that hot swap connectors are not designed for swapping on a daily basis. That might be true. But then you can do the trick logically rather than physically. Run RAID-1 across three disks. Tell the RAID to pull one disk out. On the same machine you can then access that single disk to make a backup to an off-site location. Once you are done with your backup put the disk back in the RAID. Of course before starting the procedure you have to verify that the RAID is actually running on all three disks. If the RAID is already short, that has to be resolved before starting the backup.
I'm not saying this is a good way to backup a database. But it certainly is doable without introducing unacceptable risks in the process. But you really have to know what you are doing.