I'm not sure what you mean by failover. For me failover is active-passive. So one node just sits there and starts the applicaiton when the other node fails.
If it's some sort of always-live where the data needs to be replicated realtime to all nodes, I confirm that the complexitiy is not worth the gain in uptime. Such constructions often experience more downtime because of the complexity, not because of the failures they should protect against.

I never upgraded the powerbook as the next versions of the OS felt like being a regression.
I kept it only because some software is not available on linux. But wine may be a way out of that.
Currently another laptop made it's appearance. That one has windows and linux. But I only use linux and never had the need to boot into windows.
The smartphone I bought was not iOS but android.
So yes, the Apple adventure was nice but I did not get hooked.

have you run findup (from fslint package) against same. Who wins?

Note: fslint is a shell script, so porting to windows could be a problem. Or simple by installing cygwin.

Well yes, this is a linux tool, but still I was quite pleased with it's results for 800k files. It took some time but it had an end.
It's basically a shellscript doing what others have suggested: sort by size, same size files are checksummed. /usr/share/fslint/fslint/findup
find dUPlicate files.
Usage: findup [[[-t [-m|-d]] | [--summary]] [-r] [-f] paths(s) ...]
If no path(s) specified then the currrent directory is assumed.
When -m is specified any found duplicates will be merged (using hardlinks).
When -d is specified any found duplicates will be deleted (leaving just 1).
When -t is specfied, only report what -m or -d would do.

When --summary is specified change output format to include file sizes.
You can also pipe this summary format to /usr/share/fslint/fslint/fstool/dupwaste
to get a total of the wastage due to duplicates.

As it's a single command line with dozens of pipes, it should use all cores if needed.
some text from the source:

Description

      will show duplicate files in the specified directories
      (and their subdirectories), in the format:

              file1
              file2

              file3
              file4
              file5

      or if the --summary option is specified:

              2 * 2048 file1 file2
              3 * 1024 file3 file4 file5

      Where the number is the disk usage in bytes of each of the
      duplicate files on that line, and all duplicate files are
      shown on the same line.
              Output it ordered by largest disk usage first and
      then by the number of duplicate files.
Caveats/Notes:
      I compared this to any equivalent utils I could find (as of Nov 2000)
      and it's (by far) the fastest, has the most functionality (thanks to
      find) and has no (known) bugs. In my opinion fdupes is the next best but
      is slower (even though written in C), and has a bug where hard links
      in different directories are reported as duplicates sometimes.

      This script requires uniq > V2.0.21 (part of GNU textutils|coreutils)
      dir/file names containing \n are ignored
      undefined operation for dir/file names containing \1
      sparse files are not treated differently.
      Don't specify params to find that affect output etc. (e.g -printf etc.)
      zero length files are ignored.
      symbolic links are ignored.
      path1 & path2 can be files &/or directories

and the code has optimizations like this one
sort -k2,2n -k3,3n | #NB sort inodes so md5sum does less seeking all over disk

For the same price (or less) you get this beast
http://www.youtube.com/watch?v=A2cgGTLMeCQ

it is not MD5 we are talking but MD5crypt: http://en.wikipedia.org/wiki/Crypt_(Unix)#MD5-based_scheme
Which is 1000 times MD5, so you get not 50 billion attempts on your rig but 0.05 billion

unison has already been suggested multiple times.

I used unison. It's perfect to sync from A to B (it only syncs the diffs) then modify B and later sync B to A
You also can modify A and B at the same time as long as it's not the same file, then sync and then A and B are identical.
You can even sync in cycles: A->B->C->A with modifications on all three directory trees and it still works
Unison also handles deletions on both sides fine.
Hint: use the -group -owner -times flags

Yeah, go for it.
paying for security patches is the way to go.

Sometimes gonna hate arial
ARlAL
ariaI

IoI

yeah, like it's done for "TERRAIN - PULL UP" or something like that.

where are you living. What's a quaterback?

oh, american? LOL

Thanks for marking as troll :-)

1=lowest
2=medium
3=high

If there is over 20% at level 3, just add one level, so you get this:
1=lowest
2=medium
3=hich
4=top

And in some years the top priority will be at level 10 etc...
That way you will never have 50% of high, and never have to purge the list to start from scratch.

I bet their revenue will stay the same, or just fall tremendously as there are more people who will boycott the movies and music.

that would be really nice

on recent gnome the FULL gnome session is running with a lot of deamons because it has to account for power saving stuff, accessibility and more. It was one of the complaints on one of the 27c3 talks given.