Well I can parse my nginx logs and don't see that happening, so I'm not convinced. I suppose my websites aren't the most discoverable, but the number of bogus connections sshd rejects is an order of magnitude or three higher than the number of unknown connections I get to my web server. Today I received requests from two whole clients from US data centers, so scrapers must be far more selective than you claim, or they are nowhere near the indie web killer OP purports them to be.
I've worked with a company that has had to invest in scraper traffic mitigation, so I'm not disputing that it happens in high enough volume to be problematic for content aggregators, but as for small independent non-commercial websites I'll stick with my original hypothesis unless I come across contradictory evidence.
> TL;DR: Tailscale’s free plan is free because we keep our scaling costs low relative to typical SaaS companies. We care about privacy, so unlike some other freemium models, you and your data are not the product. Rather, increased word-of-mouth from free plans sells the more valuable corporate plans. I know, it sounds too good to be true. Let’s see some details.
So it's a weighed choice between "if something seems like it's too good to be true, it often is", and "the explanations they give make good sense, and it's a way of doing business that some ethical company could choose to take".
We probably won't know in the short-to-medium term, so we'll have to take their word for it..
But I must admit, their products look pretty impressive. I'll have to have a closer look at them.
For what it's worth the scaling costs for their service are quite low. Tailscale connections are almost entirely peer to peer after an initial NAT busting operation. They can afford to do a loss leader like this and the product is actually so good that I've recommended it to a number of places. It's literally the first VPN that I think is worth paying for. I wouldn't have known that if the free tier didn't exist. Using is believing in their case. It's not uncommon to be literally angry at how easy it is to set up/manage/deploy given how much of a trash fire most vpn software is.
> Tailscale connections are almost entirely peer to peer after an initial NAT busting operation.
Ah, interesting, thanks. That would indeed make it a lot less costly. I would need to dive into it to get a better understanding how their service works.
Would you happen to have some good resources you found useful?
Well, this addresses the sniffing concern. From the link:
Note that the private key never, ever leaves its node. This is important because the private key is the only thing that could potentially be used to impersonate that node when negotiating a WireGuard session. As a result, only that node can encrypt packets addressed from itself, or decrypt packets addressed to itself. It’s important to keep that in mind: Tailscale node connections are end-to-end encrypted (a concept called “zero trust networking”).
Until you want to introduce a change that affects both machines. You need to start rewriting history or cherry-pick the changes on both branches. The further the history diverges, the harder this becomes.
How does that work if there's a conflict? Whether or not there's a hash involved, you still have to manually apply the patch to each branch, would you not? If there's no conflict, merging each branch up in git is not hard at all, but it's still a tedious extra 'n - 1' operations that you don't need in chezmoi.
For example, say I have a line "export FOO=bar" in my .bashrc on one machine and "export FOO=baz" on another. If I then indent the line on the bar branch and try to merge to the other one, something has to tell the baz branch that the right line is both differences: " export FOO=baz". Except the conflict may not be so obvious to resolve as that! And whatever you do, you'll either have a "trellis" of 'n' branches if you merge, or 'n' parallel linear branches if you cherry pick everything. Both of those history layouts quickly become very hard (to me at least) to make sure they all contain everything they should and nothing they shouldn't.
Whereas with chezmoi, the bashrc file is a template that is the same on all machines that simply says "export FOO={{ fooval }}" and chezmoi does the templating. So you can just indent the line and fast-forward/apply on other machines and that's it.
Also, the conflict resolution is just another patch (Pijul patches aren't just regular diffs, they have a lot more information), so should you decide to merge it back upstream after all, you can also cherry-pick the conflict resolution along with the conflicting patch, and also without changing the hash.
One of the motivations behind Pijul was to manage custom versions of Nixpkgs while still benefiting from upstream commits. One issue that's hard with Git is that when you also want to contribute multiple changes back, you have:
1. A branch pointing to the latest nixpkgs head.
2. A branch with commit A (let's say commit A introduces a new package to nixpkgs).
3. A branch with commit B (changing some config file).
4. A branch currently at in use for your own machines, with branches 2 and 3 rebased on top of branch 1.
Every time you do anything, you'll have to remember the flow for getting the commits fetched/rebased. Which is fine if you have a DevOps team doing exactly that, but isn't too cool if you are anything other than a large company.
In Pijul, you would have a single channel (branch sort-of equivalent) and two patches (A and B) instead, which you can push independently from each other at any time if you want to contribute them back.
Darcs does the same but wouldn't scale to Nixpkgs-sized repos.
It's surprising how often projects retag releases. Diffoscope makes it easy to see the difference between the original tarball and the retagged versions.
Changes vary from from forgetting to update an in-source version to tagging the wrong commit to fixing file metadata (file owner in the tarball).
For someone who understands git, it certainly is not. But if you are not aware of how git works, committing things when HEAD is detached could to confusion in the best case, and lost commits in the worst.
First from known networks, then from residential IPs. First with dumb http clients, now with full blown headless chrome browsers.