Readit NewsI guessed it was due to the cat-and-mouse adblocking prevention between YouTube and adblockers (I'm also using uBlock Origin).
Possibly you'd have more luck on a network where your client can allow incoming UDP connections on the Tailscale port, and so the exit node would be able to establish a direct connection.
But for a Tailscale peer I have running on AWS ECS, I can open the UDP port there, so a direct connection always happens regardless of what sort of network my Tailscale clients are on. I don't know if there's any Fly equivalent to get a direct connection to a UDP port.
The downside is that my traffic never went direct; it was always relayed via a Tailscale DERP node, as Fly.io machines were only accessible via anycast, and so a direct connection from Tailscale on my machine to the exit node on Fly.io couldn't be established.
So performance wasn't as great (and I felt bad about using up Tailscale's DERP bandwidth, as a free user).
My existing Fastmail account gives me WebDAV file storage, and Joplin can use that as a sync backend. End-to-end encrypted.
There are clients for macOS and Android. Neither of which are as relentlessly buggy as text editing with Evernote. Web Clipper browser extension. All open source.
I've had zero regrets about switching away from Evernote.
Alternatively we'd pay $36 for (3 free, 2 * $18) for Premium, which doesn't sound too bad. But the cost for each new user would be three times higher than it currently is (and Tailscale our most expensive SAAS product per person).
Or we stick to legacy pricing for now, and live with things like the Subnet Router limit which makes e.g. connecting home VoIP phones to the Tailnet price prohibitive.
It feels a little odd that the Free tier lets you use Premium features indefinitely, but as soon as you get more colleagues onboard, you lose those features.
Unless you're looking carefully at the pricing page, you'd miss that Starter has many fewer features compared to Free.
- write code
- run tests
- commit code
- update CI
- commit
- CI broken
- update CI
- commit
- CI broken
- update CI
- ...
The workarounds for this are generally awful.
For Jenkins, you stage your own instance locally and configure your webhooks to use that. It's exactly as terrible as it sounds, and I never recommend this approach.
For Travis and Concourse (I think), you can use their CLI to spin up a runner locally and run your CI/CD yaml against it. It works "fine," as long as you're okay with the runner it creates being different from the runners it actually uses in their environment (and especially your self-hosted runners).
In GitHub Actions, you can use Act to create a Dockerized runner with your own image which parses your YAML file and does what you want. This actually works quite well and is something that threatens Dagger IMO.
Other CI systems that I've used don't have an answer for this very grating problem.
Another lower-order problem Dagger appears to solve is using a markup language to express higher-level constructs like loops, conditionals, and relationships. They're using CUE to do this, though I'm not sure if hiring the creator of BCL (Borgmon Configuration Language) was the move. BCL was notoriously difficult to pickup, despite being very powerful and flexible. I say "lower-order" because many CI systems have decent-enough constructs for these, and this isn't something I'd consider a killer feature.
I also _also_ like that it assumes Dockerized runners by default, as every other CI product still relies on VMs for build work. VMs are useful for bigger projects that have a lot of tight-knit dependencies, but for most projects out there, Dockerized runners are fine, and are often a pain to get going with in CI (though this has changed over the years).
It's made by JFrog (makers of Artifactory), it's been around for while, it supports lots of formats including harder ones like apt, and it makes package distribution about as easy as it can be.
If you value your build times or your sanity in the slightest, I'd recommend either severely limiting use of Dagger, e.g. by only using it in certain, small Gradle modules, or using a different DI solution.
EDIT: Missed the part where "Accredited .eu Registrars will not be entitled to process any request for the registration of or for renewing registrations of .eu domain names by those [UK] undertakings, organisations and persons." Still, I bet the vast majority of domains will be transferred to some shell entity in the EU, even if it's just domain owners selling off domains they can't renew anymore.