Look at that, MongoDB write concerns have been improved since I last checked. Thanks for usefully pointing to that as a reference, instead of, say, quoting yourself just to be smug.
Writeable foreign data wrappers for PostgreSQL just appeared in 9.3, released a few weeks ago. I'm looking forward to seeing the hybrid storage approaches people build with that, with triggers pushing into a FDW being just one of the possibilities. All sorts of neat data queuing approaches are possible if you also combine that with the new background workers interface. You don't even need to make the FDW write synchronous. When eventual consistency is good enough for your data set, you can have the trigger push them into a queue, and then spool those in the background to other places (like a Mongo or Redis cache) via FDW.
No one really wants to stay in the SAP stable. It just costs so much to get in there, it's easier to keep cleaning up after the horses all day rather than to risk leaving.
There's a new SSD twist to this class of problem popping up more lately too. When SSDs wear out, they will sometimes quietly lose data. People doing SSD endurance testing with Anvil's tool stop the system periodically to see if it still works after being powered off for a bit. That's how some overused SSDs die at the end, and it's seriously ugly.
Once I saw a system running "SELECT * FROM customers,orders" to find the last customer and order number for a week end sales report, because the only SQL the developer knew was "SELECT * FROM". It was annoying to track down because the server would crash, running out of memory for that join, before it was logged it as a slow query. There was no evidence of what happened unless you caught it while it was running, and the damn thing fired at 4AM on a weekend morning.
Let's say you're actually deploying this system to full effectiveness, where you're using 96TB of RAM and depending on the speed increase that gives you. You are going to be so screwed if you ever reboot that thing. Cache refill after restart is a huge headache even on systems with 96 GB of RAM. If one of these monster servers goes down, I could see it taking a good chunk of a day to read everything back into cache again--during which the server is running at a tiny fraction of its regular rate.
PostgreSQL does have a synchronous commit mechanism mechanism too, which requires data be durably written to two nodes. It has a feature that as far as I know is unique to its implementation too: synchronous_commit is a per-transaction behavior. You have to specifically setup a synchronous standby server, but once it's there you can adjust the durability level you want at each commit. So you can pay for important data be fully synchronous, while streaming by less important things in standard mode, where you might lose a little on failover. You can even drop commit level from the default too, so that something you can afford to lose all copies of on a crash avoids any sort of disk commit before completing.
Since synchronous transactions block if there's not a second node around, in practice you have to deploy 3 nodes (to be able to tolerate losing one) and commits go to 2 of them. It doesn't have the ability to rollback locally committed transactions from a sever that's been disconnected yet though, that's a weak point compared to Mongo. A disconnected node that committed transactions nobody else saw is FUBAR, you have to rebuild the entire node to fix it.
I made no such quoting error--that was direct from the New BSD text on the Wikipedia page--and I can't make any sense of whatever it is you're claiming. The 3rd clause of the New BSD license is "Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission". That puts no restrictions on the code, only on the identity of the contributor. It just says that if I contribute code, the project can't use my name and write "Greg says our project is awesome" simply because I contributed--not without my written permission. That's what endorsement/promotion means here. The BSD licenses have always had "endorse or promote" restriction text of this form in them, because the University of California @ Berkeley didn't want people to think a BSD license says they approve of a program.
If you're reading any sort of profit or sale restriction out of that clause, you're very confused about what these licenses mean. I'd recommend Why you should use a BSD style license as a good piece comparing these licenses. Modified BSD License is more terse description of the same area, with a particularly easy to follow description of New BSD->GPL moves work.
MariaDB picked New BSD as the alternate license because it's "GPL compatible". That means they can just slurp up any contributions under those terms without worrying about the copyright trail on that code at all. All they have to do is include the New BSD license in their source and binary distributions for those parts, not mention their contributors by name so they're not seen as endorsing that commercial version, and they're done. New BSD code gets assimilated trivially, GPL code comes in with copyright assignment, and therefore at all times MariaDB is uniquely able to sell derived products or the company itself with full ownership of any new code added--again.
BSD style contributions are basically waiving all rights on your code, so of course they accept those too. It's functionally the same as putting your code in the public domain in this context, except for the copyright notice clause that only impacts the credits of the software. There's nothing in there restricting sale or profit: "This version allows unlimited redistribution for any purpose as long as its copyright notices and the license's disclaimers of warranty are maintained". "Any purpose" includes using your contribution in a derived work that's not open-source at all. That's the whole point of the BSD style licenses.
The reason people like GPL licenses is that everyone involved is compelled to share all related code. If MariaDB creates a cool extension to the database, in a regular GPL situation they would need to share it under the GPL terms to people they sell it to. This is not a theoretical point, as things like Commercial Extensions for MySQL Enterprise Edition popped up at multiple points in the database's history, making up part of why the company had commercial value to sell. They were only able to create those but not share the source because they had full copyright ownership on all of the code.
GPL with copyright assignment breaks the share with the community model, by letting the company who owns the copyright ignore those rules for the work they do. There's a long history of companies keeping a dual-licensed GPL codebase for commercial purposes like that, both from MySQL AB and companies like TrollTech. People used to give otherwise good open source contributors a free pass for making money this way. But Monty's past moves have been so bad for the MySQL community that there's this whole wasteful battle between Oracle MySQL and MariaDB going on, diluting the value of both projects. You can't really give him the benefit of the doubt here on what he intends to do with his license again.
There were some contributors to MySQL AB code that were hired as employees. Other than that, community contributors got nothing from the eventual sale. MariaDB is structured the same way. The only way they share profits is if they're impressed enough to hire you. Otherwise community contributors got zero before, and so far all the evidence says they'll get zero if Monty sells out again.
Introductions to SQL are a pretty small part of most PostgreSQL specific books, because that material is available from lots of sources. I think you're underestimate just how fast Postgres does change. I do support for a lot of PostgreSQL installs, and people who followed out of data information and have trouble as a result is a non trivial amount of traffic. I actively patrol online guides that have turned stale to get them updated or pointing to newer ones to try and improve the situation.
Postgres has an enormous manual. While it's tough for beginners to navigate sometime, if you're reading a book that's more than a few years old you'd really be better off with the official docs instead. What you gain in easy intros from smaller, older books you give back in wasted time following obsolete suggestions. Right now for example, any book that covers a version before 8.3 is going to be full of broken examples, because there was a major tightening on casting rules in that version, among other large changes.
When there is a complete free manual available online, it's really hard to get excited about an ancient book as useful to students. That's also something that makes this situation different from things like Photoshop.
That was meant to be a joke about the ugly differences "drop in replacement" might require, rather than a straw man.
If I were going to pick a still relevant way to criticize MySQL in this area, I'd point out that non-STRICT clients can insert data that's invalid when later STRICT clients try to do something with it. That's a small hole, but the fact that it's still there highlights how bolted on some of the MySQL integrity features are. You can still insert data and only later discover it's garbage even today, and for some people that's as bad as losing it altogether.
All they need is a compelling set of new code to sell a business based on that. Every time someone contributes to MariaDB, they're building exactly what whey need to end up with something they can sell again.
There's nothing to be done about old books. What authors can do is work clauses like this into their publishing contract, now, for new books that are written. From practical experience trying that, it's extremely hard to do that if you're an unpublished author. But if you've had a successful book already, it's possible to leverage that into future books eventually being available under a free license.
Since quite a bit of the computing book market is constantly being rewritten to stay current, if enough authors did this eventually we'd be at a more useful place. There are some classics in the field that aren't going anywhere that would allow such a change, but it doesn't cost that much to pick up all of the major ones.
K&R C and the Folley/van Dam book are classics of computing. Those represent a tiny chunk of the used book market though, not really representative of the average old book. Books that have later editions at all are generally a good sign of quality. It's reasonable to bin those separately from the one-shot books and prefer keeping them around. By that standard, an old "Programming Perl" *might* still be useful to someone who just doesn't want to spring for a newer version, while "PostgreSQL Essential Reference" heads for recycling. Having read each, those would both be reasonable calls.
I let the market decide by seeing what Amazon is selling used copies for. If it's 1 cent plus shipping, it gets tossed. "PostgreSQL Essential Reference"? Trash. "Programming Perl" 1st edition? Gone! This has worked quite well for helping cull my personal old book collection. It's easier to get rid of something if I know I can always replace it, should there come an improbable day I would need that ancient book again.
There's no direct replacement for SHOW CREATE TABLE. There are two similar things and a tool to do it though:
-Run CREATE TABLE y AS SELECT * FROM x LIMIT 0; That will make you another table just like the one you have, but with no data in it. That only gets you an exact duplicate, it doesn't show you the DDL or allow changing it in the middle. (You can then ALTER TABLE the result though, for 'like this but with X different' cases) -pg_dump with the options to only dump the schema. You'll have to dig the definition out of the dump. -pgadmin3 shows the SQL needed to re-create a table when you look at it in the GUI.
Enough people use pgadmin3 that there's not a lot of demand for cloning this MySQL-ism exactly. Just like \d instead of SHOW TABLE and learning that you connect to new databases in psql with \c, it's not a long-term pain point. Ditto for conversions, which hurt because Postgres is a lot more strict in what it will accept. That's a feature, not a bug.
As long as MariaDB is requiring copyright assignment, there's every reason to believe it will be sold off again the same way MySQL was. The FSF gets away with that for GNU projects because they've never abused contributor trust before. Monty is no FSF, and there's no reason believe MariaDB will remain outside of commercial control any better than MySQL did. I can't believe people are falling for the same trick again.
PostgreSQL aims for SQL standards conformance as much as possible. It's hard sometimes due to the difficulty of participating in the standard process. The idea that MySQL does a better job in that area is kind of odd though. You'll have to list some sample Postgres "oddities" to be credible with that claim.
PostgreSQL didn't release a solid Windows version until 2005. That's the biggest reason why MySQL adoption outpaced it for so long, but the plentiful PHP/MySQL examples certainly contributed too.
If someone has physical access to a system for long enough, of course any security can be bypassed and the system must be considered tampered. But a fully encrypted system cannot be compromised in only a minute or two of access; one with an unencrypted boot drive certainly can be. And time to exploit impacts how vulnerable you are in very common real world situations.
A regular full disk encryption candidate is a laptop you leave home with. I will sometimes leave my laptop sitting at a table with someone I trust enough to not to steal it while I walk away for a small number of minutes, like a bathroom break. But that might be a business meeting or a conference, where the other person sure would like to have the data on my laptop if they could install a siphon unobtrusively while I'm away. And that is plenty of time to install a software keylogger on a system without an encrypted operating system. You're not installing a hardware keylogger on my laptop that fast. There are a large number of exploits possible if you have the system for 30 minutes, but you're not pulling off much if someone leaves their laptop somewhere for two minutes before coming back for it.
Also, hardware keyloggers require a second round of access to the system to retrieve their recording. Software ones can expect they'll eventually get onto the Internet where they can deliver their payload. And there are very few real non-standard configurations out there. Most of the time you're going to find a laptop with Windows XP or 7, or a Mac, and a toolkit for dropping a software keylogger plus backdoor access on any of those is easy enough to bring along.
I find it pretty funny that you're speculating about all these unlikely advanced techniques here, while blowing off temp files, swap, and hibernation as non-issues. Run "strings" on a whole hard drive sometime if you want a terrifying look at how many sloppy programs leave text data in unexpected places. Your trust in simple strategies to eliminate them all is pretty optimistic.
Full disk encryption isn't a fad; it's the only way to this job well. Selective encryption makes people relax because it gives a false sense of security, but there are so many holes that you're still quite vulnerable. In some ways it's worst than no encryption at all, because people at least know they have to be careful about their system then.
The first giant issue is that operating systems and programs like editors will write work in progress data to disk outside of the encrypted area, such as temporary files, swap files, hibernation files, etc. In a selective encryption system, those are going to end up with unencrypted data exposed in there eventually.
And if the OS loads without supplying a decryption key, it's trivial for anyone who gets physical access to your system for even a short length of time to add a key logger that then captures the key. Even with full disk encryption you're vulnerable to evil maid attacks, but there are ways to make those harder to execute. An unencrypted OS makes the job trivial. Leave a system with selective encryption sitting near someone who knows this area well, go to the bathroom to take a leak, and they'll have your system owned--swiping your selective encryption key the next time you type it and publishing it over the Internet when possible--before you're back.
ECC RAM is an important part here, due to how scrubbing works in ZFS. The background disk scrubbing can check every block on the filesystem to see if it still matches its checksum, and it tries to repair issues found too. But if your memory is prone to flipping a bit, that can result in scrubbing actually destroying data that was perfectly fine until then. The worst case impact could even destroy the whole pool like that. It's a controversial issue; the odds of a massive pool failure and associated doom and gloom are seen as overblown by many people too. There's a quick summary of a community opinion survey at ZFS and ECC RAM, but sadly the mailing list links are broken and only lead to Oracle's crap now.
100 IOPS is an accurate number for 7200RPM drive. The 100K IOPS numbers some SSD vendors trot out are best case fantasy.
Last week I watched a 400GB Intel DC S3700 hit its limits for a long period. Intel is conservative on its numbers for this drive compared to a lot of the numbers other companies advertise. They only claim 36,000 IOPS. But here's what a real world worst case for the drive looks like, from a busy PostgreSQL database server:
I tell people they shouldn't expect more than 1500 IOPS on real mixed workloads with lots of concurrency from any single SSD. That's great, and it's completely reasonable to say a SSD is always going to be 10X faster than a mechanical drive. But the only devices consistently delivering even a real 100X speedup are the super expensive models from companies like FusionIO, Virident, etc, with matching price tags. And nobody is really doing 100K IOPS in anything but carefully controlled lab benchmarks.
Slashdot Mirror
And all devices become more awesome with Jim Beam Kong!
Look at that, MongoDB write concerns have been improved since I last checked. Thanks for usefully pointing to that as a reference, instead of, say, quoting yourself just to be smug.
Writeable foreign data wrappers for PostgreSQL just appeared in 9.3, released a few weeks ago. I'm looking forward to seeing the hybrid storage approaches people build with that, with triggers pushing into a FDW being just one of the possibilities. All sorts of neat data queuing approaches are possible if you also combine that with the new background workers interface. You don't even need to make the FDW write synchronous. When eventual consistency is good enough for your data set, you can have the trigger push them into a queue, and then spool those in the background to other places (like a Mongo or Redis cache) via FDW.
No one really wants to stay in the SAP stable. It just costs so much to get in there, it's easier to keep cleaning up after the horses all day rather than to risk leaving.
There's a new SSD twist to this class of problem popping up more lately too. When SSDs wear out, they will sometimes quietly lose data. People doing SSD endurance testing with Anvil's tool stop the system periodically to see if it still works after being powered off for a bit. That's how some overused SSDs die at the end, and it's seriously ugly.
Once I saw a system running "SELECT * FROM customers,orders" to find the last customer and order number for a week end sales report, because the only SQL the developer knew was "SELECT * FROM". It was annoying to track down because the server would crash, running out of memory for that join, before it was logged it as a slow query. There was no evidence of what happened unless you caught it while it was running, and the damn thing fired at 4AM on a weekend morning.
Let's say you're actually deploying this system to full effectiveness, where you're using 96TB of RAM and depending on the speed increase that gives you. You are going to be so screwed if you ever reboot that thing. Cache refill after restart is a huge headache even on systems with 96 GB of RAM. If one of these monster servers goes down, I could see it taking a good chunk of a day to read everything back into cache again--during which the server is running at a tiny fraction of its regular rate.
PostgreSQL does have a synchronous commit mechanism mechanism too, which requires data be durably written to two nodes. It has a feature that as far as I know is unique to its implementation too: synchronous_commit is a per-transaction behavior. You have to specifically setup a synchronous standby server, but once it's there you can adjust the durability level you want at each commit. So you can pay for important data be fully synchronous, while streaming by less important things in standard mode, where you might lose a little on failover. You can even drop commit level from the default too, so that something you can afford to lose all copies of on a crash avoids any sort of disk commit before completing.
Since synchronous transactions block if there's not a second node around, in practice you have to deploy 3 nodes (to be able to tolerate losing one) and commits go to 2 of them. It doesn't have the ability to rollback locally committed transactions from a sever that's been disconnected yet though, that's a weak point compared to Mongo. A disconnected node that committed transactions nobody else saw is FUBAR, you have to rebuild the entire node to fix it.
I made no such quoting error--that was direct from the New BSD text on the Wikipedia page--and I can't make any sense of whatever it is you're claiming. The 3rd clause of the New BSD license is "Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission". That puts no restrictions on the code, only on the identity of the contributor. It just says that if I contribute code, the project can't use my name and write "Greg says our project is awesome" simply because I contributed--not without my written permission. That's what endorsement/promotion means here. The BSD licenses have always had "endorse or promote" restriction text of this form in them, because the University of California @ Berkeley didn't want people to think a BSD license says they approve of a program.
If you're reading any sort of profit or sale restriction out of that clause, you're very confused about what these licenses mean. I'd recommend Why you should use a BSD style license as a good piece comparing these licenses. Modified BSD License is more terse description of the same area, with a particularly easy to follow description of New BSD->GPL moves work.
MariaDB picked New BSD as the alternate license because it's "GPL compatible". That means they can just slurp up any contributions under those terms without worrying about the copyright trail on that code at all. All they have to do is include the New BSD license in their source and binary distributions for those parts, not mention their contributors by name so they're not seen as endorsing that commercial version, and they're done. New BSD code gets assimilated trivially, GPL code comes in with copyright assignment, and therefore at all times MariaDB is uniquely able to sell derived products or the company itself with full ownership of any new code added--again.
BSD style contributions are basically waiving all rights on your code, so of course they accept those too. It's functionally the same as putting your code in the public domain in this context, except for the copyright notice clause that only impacts the credits of the software. There's nothing in there restricting sale or profit: "This version allows unlimited redistribution for any purpose as long as its copyright notices and the license's disclaimers of warranty are maintained". "Any purpose" includes using your contribution in a derived work that's not open-source at all. That's the whole point of the BSD style licenses.
The reason people like GPL licenses is that everyone involved is compelled to share all related code. If MariaDB creates a cool extension to the database, in a regular GPL situation they would need to share it under the GPL terms to people they sell it to. This is not a theoretical point, as things like Commercial Extensions for MySQL Enterprise Edition popped up at multiple points in the database's history, making up part of why the company had commercial value to sell. They were only able to create those but not share the source because they had full copyright ownership on all of the code.
GPL with copyright assignment breaks the share with the community model, by letting the company who owns the copyright ignore those rules for the work they do. There's a long history of companies keeping a dual-licensed GPL codebase for commercial purposes like that, both from MySQL AB and companies like TrollTech. People used to give otherwise good open source contributors a free pass for making money this way. But Monty's past moves have been so bad for the MySQL community that there's this whole wasteful battle between Oracle MySQL and MariaDB going on, diluting the value of both projects. You can't really give him the benefit of the doubt here on what he intends to do with his license again.
There were some contributors to MySQL AB code that were hired as employees. Other than that, community contributors got nothing from the eventual sale. MariaDB is structured the same way. The only way they share profits is if they're impressed enough to hire you. Otherwise community contributors got zero before, and so far all the evidence says they'll get zero if Monty sells out again.
Introductions to SQL are a pretty small part of most PostgreSQL specific books, because that material is available from lots of sources. I think you're underestimate just how fast Postgres does change. I do support for a lot of PostgreSQL installs, and people who followed out of data information and have trouble as a result is a non trivial amount of traffic. I actively patrol online guides that have turned stale to get them updated or pointing to newer ones to try and improve the situation.
Postgres has an enormous manual. While it's tough for beginners to navigate sometime, if you're reading a book that's more than a few years old you'd really be better off with the official docs instead. What you gain in easy intros from smaller, older books you give back in wasted time following obsolete suggestions. Right now for example, any book that covers a version before 8.3 is going to be full of broken examples, because there was a major tightening on casting rules in that version, among other large changes.
When there is a complete free manual available online, it's really hard to get excited about an ancient book as useful to students. That's also something that makes this situation different from things like Photoshop.
That was meant to be a joke about the ugly differences "drop in replacement" might require, rather than a straw man.
If I were going to pick a still relevant way to criticize MySQL in this area, I'd point out that non-STRICT clients can insert data that's invalid when later STRICT clients try to do something with it. That's a small hole, but the fact that it's still there highlights how bolted on some of the MySQL integrity features are. You can still insert data and only later discover it's garbage even today, and for some people that's as bad as losing it altogether.
All they need is a compelling set of new code to sell a business based on that. Every time someone contributes to MariaDB, they're building exactly what whey need to end up with something they can sell again.
There's nothing to be done about old books. What authors can do is work clauses like this into their publishing contract, now, for new books that are written. From practical experience trying that, it's extremely hard to do that if you're an unpublished author. But if you've had a successful book already, it's possible to leverage that into future books eventually being available under a free license.
Since quite a bit of the computing book market is constantly being rewritten to stay current, if enough authors did this eventually we'd be at a more useful place. There are some classics in the field that aren't going anywhere that would allow such a change, but it doesn't cost that much to pick up all of the major ones.
K&R C and the Folley/van Dam book are classics of computing. Those represent a tiny chunk of the used book market though, not really representative of the average old book. Books that have later editions at all are generally a good sign of quality. It's reasonable to bin those separately from the one-shot books and prefer keeping them around. By that standard, an old "Programming Perl" *might* still be useful to someone who just doesn't want to spring for a newer version, while "PostgreSQL Essential Reference" heads for recycling. Having read each, those would both be reasonable calls.
I let the market decide by seeing what Amazon is selling used copies for. If it's 1 cent plus shipping, it gets tossed. "PostgreSQL Essential Reference"? Trash. "Programming Perl" 1st edition? Gone! This has worked quite well for helping cull my personal old book collection. It's easier to get rid of something if I know I can always replace it, should there come an improbable day I would need that ancient book again.
There's no direct replacement for SHOW CREATE TABLE. There are two similar things and a tool to do it though:
-Run CREATE TABLE y AS SELECT * FROM x LIMIT 0; That will make you another table just like the one you have, but with no data in it. That only gets you an exact duplicate, it doesn't show you the DDL or allow changing it in the middle. (You can then ALTER TABLE the result though, for 'like this but with X different' cases)
-pg_dump with the options to only dump the schema. You'll have to dig the definition out of the dump.
-pgadmin3 shows the SQL needed to re-create a table when you look at it in the GUI.
Enough people use pgadmin3 that there's not a lot of demand for cloning this MySQL-ism exactly. Just like \d instead of SHOW TABLE and learning that you connect to new databases in psql with \c, it's not a long-term pain point. Ditto for conversions, which hurt because Postgres is a lot more strict in what it will accept. That's a feature, not a bug.
PostgreSQL's biggest disadvantage over MariaDB is that it's not a drop-in replacement for MySQL.
Postgres has a blackhole engine that loses data in unpredictable ways now. But that only emulates parts of MyISAM.
As long as MariaDB is requiring copyright assignment, there's every reason to believe it will be sold off again the same way MySQL was. The FSF gets away with that for GNU projects because they've never abused contributor trust before. Monty is no FSF, and there's no reason believe MariaDB will remain outside of commercial control any better than MySQL did. I can't believe people are falling for the same trick again.
PostgreSQL aims for SQL standards conformance as much as possible. It's hard sometimes due to the difficulty of participating in the standard process. The idea that MySQL does a better job in that area is kind of odd though. You'll have to list some sample Postgres "oddities" to be credible with that claim.
PostgreSQL didn't release a solid Windows version until 2005. That's the biggest reason why MySQL adoption outpaced it for so long, but the plentiful PHP/MySQL examples certainly contributed too.
If someone has physical access to a system for long enough, of course any security can be bypassed and the system must be considered tampered. But a fully encrypted system cannot be compromised in only a minute or two of access; one with an unencrypted boot drive certainly can be. And time to exploit impacts how vulnerable you are in very common real world situations.
A regular full disk encryption candidate is a laptop you leave home with. I will sometimes leave my laptop sitting at a table with someone I trust enough to not to steal it while I walk away for a small number of minutes, like a bathroom break. But that might be a business meeting or a conference, where the other person sure would like to have the data on my laptop if they could install a siphon unobtrusively while I'm away. And that is plenty of time to install a software keylogger on a system without an encrypted operating system. You're not installing a hardware keylogger on my laptop that fast. There are a large number of exploits possible if you have the system for 30 minutes, but you're not pulling off much if someone leaves their laptop somewhere for two minutes before coming back for it.
Also, hardware keyloggers require a second round of access to the system to retrieve their recording. Software ones can expect they'll eventually get onto the Internet where they can deliver their payload. And there are very few real non-standard configurations out there. Most of the time you're going to find a laptop with Windows XP or 7, or a Mac, and a toolkit for dropping a software keylogger plus backdoor access on any of those is easy enough to bring along.
I find it pretty funny that you're speculating about all these unlikely advanced techniques here, while blowing off temp files, swap, and hibernation as non-issues. Run "strings" on a whole hard drive sometime if you want a terrifying look at how many sloppy programs leave text data in unexpected places. Your trust in simple strategies to eliminate them all is pretty optimistic.
Full disk encryption isn't a fad; it's the only way to this job well. Selective encryption makes people relax because it gives a false sense of security, but there are so many holes that you're still quite vulnerable. In some ways it's worst than no encryption at all, because people at least know they have to be careful about their system then.
The first giant issue is that operating systems and programs like editors will write work in progress data to disk outside of the encrypted area, such as temporary files, swap files, hibernation files, etc. In a selective encryption system, those are going to end up with unencrypted data exposed in there eventually.
And if the OS loads without supplying a decryption key, it's trivial for anyone who gets physical access to your system for even a short length of time to add a key logger that then captures the key. Even with full disk encryption you're vulnerable to evil maid attacks, but there are ways to make those harder to execute. An unencrypted OS makes the job trivial. Leave a system with selective encryption sitting near someone who knows this area well, go to the bathroom to take a leak, and they'll have your system owned--swiping your selective encryption key the next time you type it and publishing it over the Internet when possible--before you're back.
ECC RAM is an important part here, due to how scrubbing works in ZFS. The background disk scrubbing can check every block on the filesystem to see if it still matches its checksum, and it tries to repair issues found too. But if your memory is prone to flipping a bit, that can result in scrubbing actually destroying data that was perfectly fine until then. The worst case impact could even destroy the whole pool like that. It's a controversial issue; the odds of a massive pool failure and associated doom and gloom are seen as overblown by many people too. There's a quick summary of a community opinion survey at ZFS and ECC RAM, but sadly the mailing list links are broken and only lead to Oracle's crap now.
100 IOPS is an accurate number for 7200RPM drive. The 100K IOPS numbers some SSD vendors trot out are best case fantasy.
Last week I watched a 400GB Intel DC S3700 hit its limits for a long period. Intel is conservative on its numbers for this drive compared to a lot of the numbers other companies advertise. They only claim 36,000 IOPS. But here's what a real world worst case for the drive looks like, from a busy PostgreSQL database server:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdc 0.00 22.80 888.00 483.00 6.82 3.96 16.10 162.34 118.79 0.73 100.00
sdc 0.00 2.60 908.00 422.00 6.27 3.32 14.77 170.80 125.76 0.75 100.00
sdc 7.00 54.20 1102.00 1900.40 11.64 15.26 18.35 166.82 56.68 0.33 100.00
I tell people they shouldn't expect more than 1500 IOPS on real mixed workloads with lots of concurrency from any single SSD. That's great, and it's completely reasonable to say a SSD is always going to be 10X faster than a mechanical drive. But the only devices consistently delivering even a real 100X speedup are the super expensive models from companies like FusionIO, Virident, etc, with matching price tags. And nobody is really doing 100K IOPS in anything but carefully controlled lab benchmarks.