Live data from Hacker News

The rsync algorithm (1996) [pdf]

andrew.cmu.edu

11–20 of 51 posts

Re: The rsync algorithm (1996) [pdf]

#11

Fun facts, the author of rsync, Andrew Tridgell, is also the one who reverse-engineered Microsoft SMB that laid the foundation for Samba [1]. How he did manage to avoid lawsuits from Microsoft is beyond me. [1] Server Message Block: https://en.wikipedia.org/wiki/Server_Message_Block

A protocol is not a software, it is needed for interoperability.

Similar with header files. Issues arise if there is a "misuse" to derive actually not a compatible but competing solution.

Re: The rsync algorithm (1996) [pdf]

#12

Fun facts, the author of rsync, Andrew Tridgell, is also the one who reverse-engineered Microsoft SMB that laid the foundation for Samba [1]. How he did manage to avoid lawsuits from Microsoft is beyond me. [1] Server Message Block: https://en.wikipedia.org/wiki/Server_Message_Block

He also wrote a free BitKeeper client, antagonizing Larry McVoy, which is largely why we have git.

https://blog.brachiosoft.com/en/posts/git/

Re: The rsync algorithm (1996) [pdf]

#13

Fun facts, the author of rsync, Andrew Tridgell, is also the one who reverse-engineered Microsoft SMB that laid the foundation for Samba [1]. How he did manage to avoid lawsuits from Microsoft is beyond me. [1] Server Message Block: https://en.wikipedia.org/wiki/Server_Message_Block

Australians might like to know he worked on rsync and Samba while a PhD student at the ANU

Re: The rsync algorithm (1996) [pdf]

#14

Earlier quoted context omitted.

to be fair level of security of systems back then was pretty fucking bad

In 1996? OpenBSD and Apache had been around for a year. PGP had been around for several years. HTTPS was used where needed. SecurID tokens were common for organizations that cared about security. Admittedly SSH wasn't around, but kerberos+rlogin and SSL+telnet was available. Organizations who cared about security would have SecurID tokens issued to their employees and required for login. Dial-in over phone lines, and…

And every machine had 100 RCEs that you could discover with a few hours of effort.

Re: The rsync algorithm (1996) [pdf]

#16

Well-written, succinct. This small document shows what computer science looked like to me when I was just getting started: a way to make computers more efficient and smarter, to solve real problems. I wish more people who claim to be "computer scientists" or "engineers" would actually work on real problems like this (efficient file sync) instead of having to spend time learning how to use the new React API or patchin…

If only those who claim to be "managers" enabled those "engineers" to do such work, but it's not in their interest to their product, their bottom line, or their performance review. At least in their mind.

Re: The rsync algorithm (1996) [pdf]

#17
Rsync is one of my favorite programs. I use it daily. The CLI is a bit quirky (e.g. trailing slashes), but once you get used to it, it makes sense. And I really always use the same flags: `-avmLP`, with `-n` for dry runs.

One alternative I'd like to try is Google's abandoned CDC[1], which claims to be up to 30x faster than rsync in certain scenarios. Does anyone know if there is a maintained fork with full Linux support?

[1]: https://github.com/google/cdc-file-transfer

Re: The rsync algorithm (1996) [pdf]

#18

Earlier quoted context omitted.

to be fair level of security of systems back then was pretty fucking bad

6 characters or fewer passwords, if there were passwords at all. Phreaking still worked into the 90s, and all sorts of really stupid things were done without really thinking about the security at all. They'd print out receipts with the entire credit or debit card number and information on it, or carbon copy the card with an impression, and you'd see these receipts blowing around parking lots, or find entire bags or d…

Just read AWS or CloudFlare outage postmortems and you will see: are still there, in the happy land.

Re: The rsync algorithm (1996) [pdf]

#19

Well-written, succinct. This small document shows what computer science looked like to me when I was just getting started: a way to make computers more efficient and smarter, to solve real problems. I wish more people who claim to be "computer scientists" or "engineers" would actually work on real problems like this (efficient file sync) instead of having to spend time learning how to use the new React API or patchin…

If only those who claim to be "managers" enabled those "engineers" to do such work, but it's not in their interest to their product, their bottom line, or their performance review. At least in their mind.

…what? IC developers are a huge, huge contributor to the sort of over-complicated engineering and stack churn that’s at the heart of what’s being described here. Take an iota of responsibility for yourself.

Re: The rsync algorithm (1996) [pdf]

#20

I've been using this extensively recently. I was setting up remote virtual machines that boot a live ISO containing all the software for the machine. Sometimes I need to change a small config file, which would lead to generating a new 1.7GiB ISO, but 99.9% of that ISO is identical to the previous one. So I used rsync. Blew my mind when after a day of working on these images, uploading 1.7GiB ISO after 1.7GiB ISO, wir…

In the past I downloaded daily diffs from iso which were only few MB. I then applied this diff to my iso from yesterday. Forgot the name of this tool though. I did this on my machine, if parent wants to update in a remote machine I'm not sure it works the same way.
Post reply on HN