Funny you mentioned systemd, as hibernate on pre-systemd setup didn't work for me reliably on two Linux machines I use. Now I use it routinely without any problem.

I guess every situation is different, but how much of that can he get away by just sending a PDF copy to his customers?
I actually try to do that as much as I can, even for internal use. Worst nightmare is that every person who receive it gives me back an amended copy, ending up babysitting 5 versions of same document. (I'd rather get comments out of band and make an adjustment myself.)

I think the spirit of that "Except local traffic" is pretty much for discouraging commercial vehicles (trucks, etc.) from using a corridor of a road for thru-traffic.

This wouldn't work in a typical passenger vehicle case as you have described, but if enough people in the neighborhood are seeing/reporting a number of trucks routinely without making delivery to the area, that would be a different story...

As far as I know, Costco does accept credit cards (actually they don't accept anything else, including cash) at least for my local one.

You will have to validate yourself for the member, which you can use their membership card or Costco AMEX.
If you choose to validate yourself with AMEX, it should give you option whether you want use Costco AMEX or something else.

Exactly the same thought when I heard the spec...

In addition to it, users have to worry about things like malware protection and that further drives usability down; not even sure if it will be usable...

That''s somewhat the conclusion I've reached after I've been hopping between different OS. (Windows, Mac OS, Linux)

So I myself find that Linux is least painful for me, at least for the fact that it doesn't try to hide the details from me. While mileage may vary with the nature of the issue, but it at least it's relativy simple for me to <b>try</b> to address and fix the problem before resorting to complete fresh of the machine.

They have an exit enclave for DDG search engine traffic and also hidden service at 3g2upl4pq6kufc4m.onion...
So there at least they provide some additional layer of protection for those who are needed.

Actually, if you have Sprint, I believe.

I have been trying this periodically to see if it works, it simply refuses MMS destined to Google Voice numbers, at least on T-mobile.

That's the one thing that I love about it.

It reduces onboarding process for the user as simple as typing in the secret. One of the pet peeves I had with most of P2P file synchronization services were that they required registration with the central server. It's much easier directing my peer installing software, then typing in secret instead of "install the software, now go to their website and register, wait for E-mail confirmation, and then confirm your E-mail...what? You can't remember the password you have set?"

Their Windows installer even provides an opportunity to type in the secret right after installation, which makes the cases like above very easy to handle.

Actually, the case that was illustrated in the earlier comment can throw things off pretty bad. By inserting a bit at the beginning of the file, it'll pretty much shift the offset of the block for the whole file thereafter invalidating all the blocks, unless the actual data of files are considered. (Which I believe BitTorrent Sync is NOT doing.)

You only share among people with same shared key. So, no, you are not spreading your encrypted file to other people. At 1:1 it's pretty much direct peer-to-peer transfer. If more nodes are participating, then it can leverage distributed transfers from other nodes that may have part of the whole part of a file.

As they are using BitTorrent technology, perhaps the metadata would contain size of data (number of blocks) to be transferred. Considering you can choose to NOT use a tracker, and go DHT (or pre-defined host) only, so probably there are some data transfer that are not accounted in this figure.