Use ZFS if you are in OpenSolaris/FreeBSD land, or use a Reed-Solomon tool - a GPL implementation of mine was Slashdotted 2 years ago, here: http://users.softlab.ntua.gr/~ttsiod/rsbep.html

Sorry mate, you're wrong. You can happily get unsecured content from any place you like, store it on your server and then serve it to anyone you please over HTTPS - from your *own* servers. This is what Google does when you click on "show me the cached content". Do you really think that the summaries written under the search results are obtained in real-time from the original servers and "woven" into your results the moment you search? No, the content IS scanned daily by Googlebots and stored in Google's machines - they are already serving the query RESULTS from their own servers, and this is what I am talking about - simply returning the RESULTS over HTTPS - whether you'll click on them and proceed over HTTP would then be your own choice. Regardless, some Slashdot moderator closed this thread - I can't for the life of me understand why, I think it's a valid question, and one many tech people would love to talk about...

I insist: we are talking about what they are *already* displaying in their result pages... why not serve it over HTTPS? I would understand performance issues, but I doubt they would pose a significant problem for Google... they do the same with GMail every day for millions of subscribers.

Must have touched a nerve ... :-) What's next, black suits at my door? (cowers in fear)

We are only talking about the queries and the search results here... these ARE Google's content. They could be served over HTTPS, and then it would be the user's choice - whether to proceed and view a result over unsecured HTTP or fire up Tor...

It just redirects me to a non-HTTPS version...

I also use rsync and OpenSolaris/ZFS to keep daily backups. BUT - important: If the content is made of big files that change slightly each day (e.g. VMWARE/VirtualBox disk images), make sure you also use "--inplace" when you do the rsync, so that you take advantage of the copy-on-write semantics of ZFS. For example, I am using rsync to back up a VMWARE server to an OpenSolaris/ZFS fileserver, where the virtual disks are huge "vmdk" files - in the order of 10GB each. These huge files change only a little each day (less than 1%) - rsync would indeed realize this and only copy over the network the parts that changed, but it would store completely new copies in the backup server for each day! (I am assuming here that you would ZFS-snapshot each day). If instead you use the --inplace option of rsync, rsync will not only send the blocks that changed, but it will also only write the blocks that changed - thus, your ZFS will be able to host many years' worth of daily snapshots of these "vmdk", a truly marvelous thing, if you think about it...

> I'd wager that this guy has never worked on huge projects

And you would be wrong. I've worked in very large projects (in the Telecom industry), and am currently coding specialized C/C++ code generators for the European Space Agency (the kind that actually generate the static, speedy, typesafe code that is appropriate for many projects). I know what you are talking about, and I never implied that Python is the way to go for all kinds of problems. My site has just as much C++ stuff as it does Python (e.g. my realtime 3D renderers) - even x86 SSE asm! What I am trying to show people is that there are many kinds of problems where scripting languages are not only adequate, but in fact the best way to go about... Google uses and advocates Python a lot, and Eric Raymond (esr) explains why a lot better than I ever could (Why Python?). In this day and age, developing speed and code clarity is just as important (if not more) as execution speed. Try Python and you'll know what I mean, when I refer to developing speed... And as for code clarity, the world is moving towards dynamic and type-infering languages (Ocaml, F#) for a reason...