Every keys has to be signed by Network Solutions, and you must update your signatures every 3 month.
Well, actually it seems that I relied on confusing information - the truth is that the domain owner has to sign it, it just happens that Network Solutions will be the one signing all.com's and probably a bunch of other ones.
DNSSEC has many years of actual deployment, not as wide spread as it needs to be, but it has been out there and tested.
Can you point me to a single implementation of DNSCurve? Can you even point me to a specification of what exactly it is? I've looked, and the best that I can tell, there aren't any. More over, it doesn't appear that DJB's website has been updated since he proposed DNSCurve last year.
From the namedroppers mailing list (IETF) there have been report of independently built client and server implementing DNSCurve. I alto trust Daniel J. Bernstein to update tinydns & dnscache as required if it gets adopted. Note that Microsft and Apple, who both have a good share of DNS servers out there, do not have a DNSSEC implementation yet.
The implementation is also much simpler than DNSSEC.
DNSSEC rely on having a central "trusted" authority to sign all the dns keys. [...] that means that everyone will depend on a single authority for name resolutions
Uhm... No?
The root key signs the ".org" key, the.org key signs the "slashdot.org" key, etc. Unless the owner of the root key and the.org key is one and the same, you don't have the root controlling whether slashdot can get signed, and you don't have.org controlling whether.com can get signed (and what can get signed under.com).
Go back to the specs. Every keys has to be signed by Network Solutions, and you must update your signatures every 3 month. If you have >100 domains to manage you sure can understand the pain:)
DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.
Uhmm... so in DNSCurve you don't need to trust the root? Also, DNSCurve offers integrity of the communication, not integrity of the data. That means if I'm the MITM between you and your DNS resolver, assuming you don't connect to the resolver in a secure manner, I can still spoof all the DNS data I want to. That's not possible when the data is signed (or at least it appears to be equivalent to the problem of breaking the cryptography).
At least, this is how I understand it. I welcome any corrections:)
DNSCurve is a trust chain. You have to trust the root and every server in-between to guarantee integrity. Once implemented from the root to the final authoritative server the trust is complete. It doesn't require any modification to registrar interfaces to managing it though, as all you need is to change your NS hostname (which embeds the DNSCurve key).
Trust is the same for DNSSEc, it's just that instead of using the root servers as a trust chain, you use a 3rd party that every domain owners had to pay for.
I hardly doubt many institutions will actually pay for signing their zones. o me it's more DNSSEC which is a hype and I'm under the impression many people pushing for it just don't know the implications (they just want to secure DNS).
DNSCurve is much easier to implement than DNSSEC and and also advantages in term of cryptography speed and increase of traffic.
DNSSEC rely on having a central "trusted" authority to sign all the dns keys. Not even speaking about the inherent security issues with this model, that means that everyone will depend on a single authority for name resolutions (sure Network Solutions loves this)
DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.
'nice' does not affect IO, only process scheduling.
The CFQ scheduler have IO classes with priorities that can be set with 'ionice'. Be sure to use a recent kernel though, I've seen nasty bugs in 2.5.25.
Depending on the typical load type even the IDLE class might be worse than the Deadline or Anticipatory schedulers (they do not support classes even if you can set them) so testing is the key, though for desktops CFQ+ionice should be best in most cases.
The problem is often not compatibility within the same company, but supporting clients and partners that never heard of OOo.
This means that when you send out a document in MS format from OOo, you need to be assured that the other party will see it properly with Office, and you shouldn't spend too much time fixing up documents you receive in MS format.
From my own experience vector art doesn't work within MS application neither!
Every time I used them I ended up with vector graphics offset from their original position, and I quite often seen the same behaviour on documents I received.
Yep, a wiser idea would have been using some distributed network like Akamai, and cutting the feed off before it get past the 95th percentile (36 hours IIRC) to avoid being charged for it:)
I've been using Thunderbird with IMAP along with Outlook on Windows, as Outlook doesn't work very nicely with mailing lists and GnuPG signatures... Along with Lightning (calendar extension) I'm sure this would be a good replacement. I know you can see calendars with Thunderbird (w/ Lightning) but haven't really tried using it (i.e. accepting, creating, etc.)
Overall Thunderbird if much faster than Outlook (my outlook datastore is ~2GB, 40000 emails and I imported them all in Thunderbird) and it doesn't need lengthy recoveries after power failures.
Have you looked at the comments to the popular mechanics article? It's really not meant to be a flame, but most of them look like they're from 12 yr. old kids! Between one who think the only thing you can make out of it is a flashlight, to one who want to put an end to the U.S. energy crisis using that... So far every single comment I read ranged from being pointless to totally stupid... wow!
Ok, I'm wondering why I'm still arguing with you, since you seem to just repear the same things over and over without even trying to understand what I say!
This is what YOU are not getting, as you are repeating it again.
Data is NOT lost if the OS knows the data was never TRULY written. This means that NO MATTER what type or state of the device cache is, the OS is 'smart' enough to realize when a write is 'completed', and not still in any cache mechanism.
There are OSes smart enough to do this, Microsoft makes a very popular one.
Then please enlighten me as to how this can be possible when the SCSI subsystem uses the standard method to report that the data IS written to disk when it's written TO RAM ONLY and WRITES LATER to disk. This is what WRITE-BACK is all about and is also why it's unsafe... Unless there's a battery (which is the case in most systems I've come across)
There may be techniques to minimize the damages by such configurations like replaying longer portions of the logs, but there's no way to tell whenever the data is really on disk. You can test by yourself though...
Also take note that this will unlikely bite you unless you're doing lots of I/O or use applications extremely sensitive to data loss.
NTFS is NOT something that true IT professionals, administrators, OS engineers, or OS theorists make fun of as lightly as you seem to do here.
There is a reason there has been a race for ZFS to mature, as it is the FIRST AND ONLY FS technology that comes close to providing the features and possible performance of NTFS. (Go Wiki it, kid.)
I agree NTFS was a rock star when in launched in the 90's, but it's not anymore. Besides the fact that is has lots of complex features for various Microsoft application, in term of journaling NTFS is just like many other journaling FS'es around today (Ext3, ReiserFS, Jfs, Xfs to name a few). You don't need ZFS to equal NTFS's journaling feature, it had been done already with many filesystems.
If you think NTFS is bad or notorious for data failure you are either drinking the kool-aid or have no experience in real world IT.
I didn't say that. What I'm saying is that any journaled fs - NTFS *included* - is susceptible to corruption when there's write-back caching.
Again, shall we talk about how it pretty much stands alone in the department of the OS understanding the device cache state and working with NTFS meta journaling?
Or should we talk about the added full journaling features of Windows 2008 server and Vista, where a dirty volume, let alone lost data is about as frequent as device failure itself?
Oh, really? In Windows 2008? Full data journaling has been available for quite some time in other file systems, unfortunately it's extremely slow unless you dedicate a device for the journal. Oh, does NTFS support external journals? Oops!
Anyway the point is not about x or y feature of NTFS, it's about the fact that write-back caching will lose your data. Data journaling will not help you in this regard.
When the OS/FS combination is pushing reliability percentages that are near parallel to device failure, you can't do much better.
If you want to make fun of NT or Win32, go for it, but NTFS is one area you better do your homework before you start talking smack, as there are a lot of OS theorists that are *nix zealots that would lay you out flat for calling NT's object model or NTFS a bad or ineffective design.
If you read carefully you'll note that I never discredited the NTFS file system. IMHO it's way too complex for my "keep it simple" philosophy, but that's another story and a personal preference. However, to use your words, YOU should probably do YOUR homework regarding SCSI, RAID and data integrity in non-Windows OS.
Yes, there are ways to flush cache on SCSI, but most RAID cards also give you ways to PRETEND the cache is properly flushed. This is called WRITE-BACK caching mode and if there's no battery backing-up the cache your data will be LOST.
Yes, *RECENT* IDE specifications specify mechanisms flush the write cache, but many cheap IDE drives doesn't implement it. Here's an example on one of my crap servers (dmesg):
That's because manufacturers often break standards to lower the prices or get better performances. That's why there *IS* a difference between "specifications" and "cheap consumer-class hardware".
I've seen more than once NTFS filesystems break on power failure, despite what you call "intrinsic 'object' level understanding of I/O" (Carefully chosen marketing words IMHO). That's not because Windows server does a bad job at handling the cache, that's simply because of the cheap hardware behind it. It can happen to Linux too, and that's not because they doesn't handle caching issues properly.
Oh and FYI, in older IDE specifications cache flushing is either ABSENT or OPTIONAL (and it's still optional for ATAPI devices).
Unfortunately you make absolutely no distinction between specifications, server-class hardware and cheap consumer-class hardware. I fully understand your comment if you're relying solely on server-class hardware, unfortunately that's not the case of millions of startups that try to keep IT costs low.
First of all, in server-class hardware data loss is not easy, but you can do it. Just get a SCSI card with memory cache, make sure there's no battery on it and force the cache to "write-back" mode. In this mode, even though the SCSI card signals to the OS that the data is safe, IT ISN'T. Obviously that's not the default, and that's also why you'll likely want a battery on your raid card (in which case it will likely default to write-back as it can sustain power failures);)
Secondly, IDE/SATA drive caches are not protected, and on by default on most drives. That's because consumer hardware strives to give the best performance possible at the lowest cost. I haven't looked at the exact specification, but it doesn't matter because I based my conclusions on real-life experience and PC hardware have an history of breaking specs. Even my current workstation's SATA drives, Western Digital RAID edition 250GB's (SATA1, ~1 year old), default to an unprotected mode.
FYI I did a lot of testing on this matter, including pulling power routinely (and automatically trough network power bars) of high-end clustered database servers, SANs, etc. in a testing environment. I do have cheap servers running on cheap IDE and SATA drives, but they're doing nearly no write ops and I can easily validate and sync the data on them (that's actually an automated process). The file server on which they rely for file integrity, OTOH, is much more reliable and I can sleep at night even knowing that the collocation facility have an history of unplanned power failures. The same goes for the database servers, which would take at least half a day to restore from backup should they fail due to data corruption.:)
The general problem with journaling filesystems recovery is not the data not being written (although in some very specific applications it can be required) as most serious apps like databases just fsync what they need on-disk. Problems arise when you have unprotected write cache.
This can happen on SCSI/SAS RAID cards when you force the write cache without a battery, but the most general cause is cheap hardware, especially IDE/SATA disks. For performance reasons they usually have the write cache enabled by default, and in many disks (possibly not many SATA's but this was common on IDE) you can't even disable the write cache (hdparm -W0).
With this kind of configuration, no matter what you do in term of journaling, you will *always* loose data when power fails during I/O operations.
On a side note, if you need data journaling you should probably use an external journal on a separate disk/array. This way the journal device will be doing synchronous writes which is much faster on standard disks.
There are amplifiers that send power over the wire, so you can plug the amp directly on the outdoor antenna and have the power send just before the spiting box or TV. With the one I bought you can even stack multiple amplifiers to get higher gain (10db per amp) - there's a piece that you remove from the inner amps to let the power flow up to the last one.
I'm not sure where you can find them in the U.S.; I bought mine in Montreal at www.addison-electronique.com for (IIRC) 10$.
I just read about the so called "write intent bitmap" feature, that according to the author is the only way to keep software raids safe...
The only purpose of this thing is to avoid a full resync after failures. The performance impact is high though, and won't help if you have disk write cache problems anyways. In the other case, the resync will just use data of the first disk which should be good if FS and applications properly fsync'ed their critical data.
I wouldn't recommend it unless you have a slow multi-terabyte array that would take days to sync.
While the author of this article do have some points, half of it is misconceptions or just plain nonsense.
I started laughing at the 2nd paragraph: did he says unrefreshed DRAM garbage being written to disk??? Regardless of the fact that DRAM keeps its content seconds, sometimes even minutes after power goes off - even when removed from the system, can he explain how, if there's no more power refresh the ram, his DMA controller will be copying data? How the disk controller will send the data trough the wire? How the data will be written when there's no power to spin the platters and move the heads?
Sure there used to be systems with power fail interrupt. That was the SGI's using an old version of XFS _without_ journaling. The PSU was loaded with big capacitors and upon triggering that interrupt the system would flush cache to disk before the power was out.
There's also misconception about databases - at least MySQL. I work with it in cluster environments. In my testing, I was routinely (and automatically trough network boot bars) shutting off current of the active node, causing a hard shutdown, and letting resources fail over the passive one. Did that hundred - maybe thousand - times on a well loaded replicated slave cluster without a single glitch. No forced InnoDB recoveries. No replication problems.
His "disk cache" issue is a nonsense too - at least the way he present it. The proper way to demonstrate it would rather be doing the sync, then upon sync returning shutting off the computer, because there lies the problem. My MySQL cluster above was able to recover because on every fsync (and there were hundreds _per second_!) it knew the data was hard on disk (in the battery-backed RAID controller cache actually). The problem lies with consumer-lever hardware. IDE/SATA has their write cache enabled by default. In some case it can't even be turned off.
So instead of suggesting to buy UPSes to "patch the problem", data reliability should start with decent hardware components: ECC Ram, SCSI/Sas drives, etc. Sometimes tha's also a tradeoff between speed and reliability as you ofter get the choice. And BTW in about 5 years I've seen whole datacenters loose power at 4 occasions, and not the cheapest/smallest ones (three times UPS failures, and once generator failed to kick in. That was in two different datacenters in US and Canada). I've also had an UPS failure from an expensive APC SMART-UPS. You can't only rely on UPSes.
Possibly because adding that much mercury (assuming they use that) to every computer on earth is the worse thing you could ever do against the environment. Even China refusing to lower their greenhouse gas emissions is nothing compared to it!
I'm pretty sure a couple of ESDs with your BBQ lighter on the chip pins will do it, although for safety a bunch of "shred" passes wouldn't be a bad idea first.
(FYI shred is a UNIX tool that erase normal hard disks in a way optimized to prevent data recovery)
Slashdot Mirror
Every keys has to be signed by Network Solutions, and you must update your signatures every 3 month.
Well, actually it seems that I relied on confusing information - the truth is that the domain owner has to sign it, it just happens that Network Solutions will be the one signing all .com's and probably a bunch of other ones.
DNSSEC has many years of actual deployment, not as wide spread as it needs to be, but it has been out there and tested.
Can you point me to a single implementation of DNSCurve? Can you even point me to a specification of what exactly it is? I've looked, and the best that I can tell, there aren't any. More over, it doesn't appear that DJB's website has been updated since he proposed DNSCurve last year.
From the namedroppers mailing list (IETF) there have been report of independently built client and server implementing DNSCurve. I alto trust Daniel J. Bernstein to update tinydns & dnscache as required if it gets adopted. Note that Microsft and Apple, who both have a good share of DNS servers out there, do not have a DNSSEC implementation yet.
The implementation is also much simpler than DNSSEC.
DNSSEC rely on having a central "trusted" authority to sign all the dns keys. [...] that means that everyone will depend on a single authority for name resolutions
Uhm... No?
The root key signs the ".org" key, the .org key signs the "slashdot.org" key, etc. Unless the owner of the root key and the .org key is one and the same, you don't have the root controlling whether slashdot can get signed, and you don't have .org controlling whether .com can get signed (and what can get signed under .com).
Go back to the specs. Every keys has to be signed by Network Solutions, and you must update your signatures every 3 month. If you have >100 domains to manage you sure can understand the pain :)
DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.
Uhmm... so in DNSCurve you don't need to trust the root? Also, DNSCurve offers integrity of the communication, not integrity of the data. That means if I'm the MITM between you and your DNS resolver, assuming you don't connect to the resolver in a secure manner, I can still spoof all the DNS data I want to. That's not possible when the data is signed (or at least it appears to be equivalent to the problem of breaking the cryptography).
At least, this is how I understand it. I welcome any corrections :)
DNSCurve is a trust chain. You have to trust the root and every server in-between to guarantee integrity. Once implemented from the root to the final authoritative server the trust is complete. It doesn't require any modification to registrar interfaces to managing it though, as all you need is to change your NS hostname (which embeds the DNSCurve key).
Trust is the same for DNSSEc, it's just that instead of using the root servers as a trust chain, you use a 3rd party that every domain owners had to pay for.
I hardly doubt many institutions will actually pay for signing their zones. o me it's more DNSSEC which is a hype and I'm under the impression many people pushing for it just don't know the implications (they just want to secure DNS).
DNSCurve is much easier to implement than DNSSEC and and also advantages in term of cryptography speed and increase of traffic.
DNSSEC rely on having a central "trusted" authority to sign all the dns keys. Not even speaking about the inherent security issues with this model, that means that everyone will depend on a single authority for name resolutions (sure Network Solutions loves this)
DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.
See http://dnscurve.org/index.html
Err I meant before 2.6.25, the < didn't catch.
'nice' does not affect IO, only process scheduling.
The CFQ scheduler have IO classes with priorities that can be set with 'ionice'. Be sure to use a recent kernel though, I've seen nasty bugs in 2.5.25.
Depending on the typical load type even the IDLE class might be worse than the Deadline or Anticipatory schedulers (they do not support classes even if you can set them) so testing is the key, though for desktops CFQ+ionice should be best in most cases.
The problem is often not compatibility within the same company, but supporting clients and partners that never heard of OOo.
This means that when you send out a document in MS format from OOo, you need to be assured that the other party will see it properly with Office, and you shouldn't spend too much time fixing up documents you receive in MS format.
From my own experience vector art doesn't work within MS application neither!
Every time I used them I ended up with vector graphics offset from their original position, and I quite often seen the same behaviour on documents I received.
If she is, she most likely received a letter too, she just didn't tell him!
Yep, a wiser idea would have been using some distributed network like Akamai, and cutting the feed off before it get past the 95th percentile (36 hours IIRC) to avoid being charged for it :)
I've been using Thunderbird with IMAP along with Outlook on Windows, as Outlook doesn't work very nicely with mailing lists and GnuPG signatures... Along with Lightning (calendar extension) I'm sure this would be a good replacement. I know you can see calendars with Thunderbird (w/ Lightning) but haven't really tried using it (i.e. accepting, creating, etc.)
Overall Thunderbird if much faster than Outlook (my outlook datastore is ~2GB, 40000 emails and I imported them all in Thunderbird) and it doesn't need lengthy recoveries after power failures.
If you want to download full IMAP folders automatically, you need some manual tweaking - see this bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=329229
Have you looked at the comments to the popular mechanics article? It's really not meant to be a flame, but most of them look like they're from 12 yr. old kids! Between one who think the only thing you can make out of it is a flashlight, to one who want to put an end to the U.S. energy crisis using that... So far every single comment I read ranged from being pointless to totally stupid... wow!
No...
Ok, I'm wondering why I'm still arguing with you, since you seem to just repear the same things over and over without even trying to understand what I say!
This is what YOU are not getting, as you are repeating it again.
Data is NOT lost if the OS knows the data was never TRULY written. This means that NO MATTER what type or state of the device cache is, the OS is 'smart' enough to realize when a write is 'completed', and not still in any cache mechanism.
There are OSes smart enough to do this, Microsoft makes a very popular one.
Then please enlighten me as to how this can be possible when the SCSI subsystem uses the standard method to report that the data IS written to disk when it's written TO RAM ONLY and WRITES LATER to disk. This is what WRITE-BACK is all about and is also why it's unsafe... Unless there's a battery (which is the case in most systems I've come across)
There may be techniques to minimize the damages by such configurations like replaying longer portions of the logs, but there's no way to tell whenever the data is really on disk. You can test by yourself though...
Also take note that this will unlikely bite you unless you're doing lots of I/O or use applications extremely sensitive to data loss.
NTFS is NOT something that true IT professionals, administrators, OS engineers, or OS theorists make fun of as lightly as you seem to do here.
There is a reason there has been a race for ZFS to mature, as it is the FIRST AND ONLY FS technology that comes close to providing the features and possible performance of NTFS. (Go Wiki it, kid.)
I agree NTFS was a rock star when in launched in the 90's, but it's not anymore. Besides the fact that is has lots of complex features for various Microsoft application, in term of journaling NTFS is just like many other journaling FS'es around today (Ext3, ReiserFS, Jfs, Xfs to name a few). You don't need ZFS to equal NTFS's journaling feature, it had been done already with many filesystems.
If you think NTFS is bad or notorious for data failure you are either drinking the kool-aid or have no experience in real world IT.
I didn't say that. What I'm saying is that any journaled fs - NTFS *included* - is susceptible to corruption when there's write-back caching.
Again, shall we talk about how it pretty much stands alone in the department of the OS understanding the device cache state and working with NTFS meta journaling?
Or should we talk about the added full journaling features of Windows 2008 server and Vista, where a dirty volume, let alone lost data is about as frequent as device failure itself?
Oh, really? In Windows 2008? Full data journaling has been available for quite some time in other file systems, unfortunately it's extremely slow unless you dedicate a device for the journal. Oh, does NTFS support external journals? Oops!
Anyway the point is not about x or y feature of NTFS, it's about the fact that write-back caching will lose your data. Data journaling will not help you in this regard.
When the OS/FS combination is pushing reliability percentages that are near parallel to device failure, you can't do much better.
If you want to make fun of NT or Win32, go for it, but NTFS is one area you better do your homework before you start talking smack, as there are a lot of OS theorists that are *nix zealots that would lay you out flat for calling NT's object model or NTFS a bad or ineffective design.
If you read carefully you'll note that I never discredited the NTFS file system. IMHO it's way too complex for my "keep it simple" philosophy, but that's another story and a personal preference. However, to use your words, YOU should probably do YOUR homework regarding SCSI, RAID and data integrity in non-Windows OS.
Did you even read my message?
Yes, there are ways to flush cache on SCSI, but most RAID cards also give you ways to PRETEND the cache is properly flushed. This is called WRITE-BACK caching mode and if there's no battery backing-up the cache your data will be LOST.
Yes, *RECENT* IDE specifications specify mechanisms flush the write cache, but many cheap IDE drives doesn't implement it. Here's an example on one of my crap servers (dmesg):
hda: UDMA/100 mode selected
hda: cache flushes not supported
hdc: UDMA/100 mode selected
hdc: cache flushes supported
That's because manufacturers often break standards to lower the prices or get better performances. That's why there *IS* a difference between "specifications" and "cheap consumer-class hardware".
I've seen more than once NTFS filesystems break on power failure, despite what you call "intrinsic 'object' level understanding of I/O" (Carefully chosen marketing words IMHO). That's not because Windows server does a bad job at handling the cache, that's simply because of the cheap hardware behind it. It can happen to Linux too, and that's not because they doesn't handle caching issues properly.
Oh and FYI, in older IDE specifications cache flushing is either ABSENT or OPTIONAL (and it's still optional for ATAPI devices).
Unfortunately you make absolutely no distinction between specifications, server-class hardware and cheap consumer-class hardware. I fully understand your comment if you're relying solely on server-class hardware, unfortunately that's not the case of millions of startups that try to keep IT costs low.
First of all, in server-class hardware data loss is not easy, but you can do it. Just get a SCSI card with memory cache, make sure there's no battery on it and force the cache to "write-back" mode. In this mode, even though the SCSI card signals to the OS that the data is safe, IT ISN'T. Obviously that's not the default, and that's also why you'll likely want a battery on your raid card (in which case it will likely default to write-back as it can sustain power failures) ;)
Secondly, IDE/SATA drive caches are not protected, and on by default on most drives. That's because consumer hardware strives to give the best performance possible at the lowest cost. I haven't looked at the exact specification, but it doesn't matter because I based my conclusions on real-life experience and PC hardware have an history of breaking specs. Even my current workstation's SATA drives, Western Digital RAID edition 250GB's (SATA1, ~1 year old), default to an unprotected mode.
FYI I did a lot of testing on this matter, including pulling power routinely (and automatically trough network power bars) of high-end clustered database servers, SANs, etc. in a testing environment. I do have cheap servers running on cheap IDE and SATA drives, but they're doing nearly no write ops and I can easily validate and sync the data on them (that's actually an automated process). The file server on which they rely for file integrity, OTOH, is much more reliable and I can sleep at night even knowing that the collocation facility have an history of unplanned power failures. The same goes for the database servers, which would take at least half a day to restore from backup should they fail due to data corruption. :)
The general problem with journaling filesystems recovery is not the data not being written (although in some very specific applications it can be required) as most serious apps like databases just fsync what they need on-disk. Problems arise when you have unprotected write cache.
This can happen on SCSI/SAS RAID cards when you force the write cache without a battery, but the most general cause is cheap hardware, especially IDE/SATA disks. For performance reasons they usually have the write cache enabled by default, and in many disks (possibly not many SATA's but this was common on IDE) you can't even disable the write cache (hdparm -W0).
With this kind of configuration, no matter what you do in term of journaling, you will *always* loose data when power fails during I/O operations.
On a side note, if you need data journaling you should probably use an external journal on a separate disk/array. This way the journal device will be doing synchronous writes which is much faster on standard disks.
There are amplifiers that send power over the wire, so you can plug the amp directly on the outdoor antenna and have the power send just before the spiting box or TV. With the one I bought you can even stack multiple amplifiers to get higher gain (10db per amp) - there's a piece that you remove from the inner amps to let the power flow up to the last one.
I'm not sure where you can find them in the U.S.; I bought mine in Montreal at www.addison-electronique.com for (IIRC) 10$.
I just read about the so called "write intent bitmap" feature, that according to the author is the only way to keep software raids safe...
The only purpose of this thing is to avoid a full resync after failures. The performance impact is high though, and won't help if you have disk write cache problems anyways. In the other case, the resync will just use data of the first disk which should be good if FS and applications properly fsync'ed their critical data.
I wouldn't recommend it unless you have a slow multi-terabyte array that would take days to sync.
While the author of this article do have some points, half of it is misconceptions or just plain nonsense.
I started laughing at the 2nd paragraph: did he says unrefreshed DRAM garbage being written to disk??? Regardless of the fact that DRAM keeps its content seconds, sometimes even minutes after power goes off - even when removed from the system, can he explain how, if there's no more power refresh the ram, his DMA controller will be copying data? How the disk controller will send the data trough the wire? How the data will be written when there's no power to spin the platters and move the heads?
Sure there used to be systems with power fail interrupt. That was the SGI's using an old version of XFS _without_ journaling. The PSU was loaded with big capacitors and upon triggering that interrupt the system would flush cache to disk before the power was out.
There's also misconception about databases - at least MySQL. I work with it in cluster environments. In my testing, I was routinely (and automatically trough network boot bars) shutting off current of the active node, causing a hard shutdown, and letting resources fail over the passive one. Did that hundred - maybe thousand - times on a well loaded replicated slave cluster without a single glitch. No forced InnoDB recoveries. No replication problems.
His "disk cache" issue is a nonsense too - at least the way he present it. The proper way to demonstrate it would rather be doing the sync, then upon sync returning shutting off the computer, because there lies the problem. My MySQL cluster above was able to recover because on every fsync (and there were hundreds _per second_!) it knew the data was hard on disk (in the battery-backed RAID controller cache actually). The problem lies with consumer-lever hardware. IDE/SATA has their write cache enabled by default. In some case it can't even be turned off.
So instead of suggesting to buy UPSes to "patch the problem", data reliability should start with decent hardware components: ECC Ram, SCSI/Sas drives, etc. Sometimes tha's also a tradeoff between speed and reliability as you ofter get the choice. And BTW in about 5 years I've seen whole datacenters loose power at 4 occasions, and not the cheapest/smallest ones (three times UPS failures, and once generator failed to kick in. That was in two different datacenters in US and Canada). I've also had an UPS failure from an expensive APC SMART-UPS. You can't only rely on UPSes.
Field's metal and Rose metal boiling points are too high.
Galinstan is probably very expensive... There are some more here:
http://en.wikipedia.org/wiki/Fusible_alloy
Possibly because adding that much mercury (assuming they use that) to every computer on earth is the worse thing you could ever do against the environment. Even China refusing to lower their greenhouse gas emissions is nothing compared to it!
That is a complex question, and it's best to start with where copyright came from.
I'd highly recommend that you read the Free Culture book by Lawrence Lessig:
http://www.free-culture.cc/
I'm pretty sure a couple of ESDs with your BBQ lighter on the chip pins will do it, although for safety a bunch of "shred" passes wouldn't be a bad idea first.
(FYI shred is a UNIX tool that erase normal hard disks in a way optimized to prevent data recovery)
Maybe for the first time we'll have gigabytes of rainbow tables for free...