- digital services act mandates interoperability in chat, but apparently companies can put require obnoxious terms for interoperating parties such as sharing their users IP addresses - which service is going to agree to that if a very large portion of the alternatives target people not wanting to share data with Facebook?
- pay "ridiculous price" or accept ads & tracking instead of allowing to disable tracking
i haven't heard about the first one yet. i totally believe it, but do we have an actual example of facebooks demands? are they documented somewhere?
the second one i experience daily and it's driving me nuts. i am sure it is actually illegal, but i have yet to find an explanation on why it should be allowed or a convincing legal argument in why it actually violates the rules. something that i could send to violators.
You generate a short-lived token, update, then rotate it. For most home setups, a cron job every 5 minutes with a 10-minute token window is fine. The RFC 2136 path is the real reason to use this instead of the HTTP update protocols most DDNS services use.
"Long-lived token" means API tokens for the management API (creating/
deleting zones, listing them, automating via Terraform-style flows),
not the TSIG keys for actual DNS updates. Every zone on every tier gets
its TSIG key — that's what powers the updates themselves. Free tier
manages zones via the dashboard; paid tiers add API tokens for
programmatic management.
Hi, just wanted to check in again to clarify this a bit. TSIG keys are used for both the api and the direct dns update, this is what authenticates the request and tied to a specific domain. the bearer (long and short) are for the account and is tied to you rather than a specific domain. https://dynip.dev/docs#api-register - you can also list current keys etc for the different domains.
I had main issue with smaller ecosystem. Very limited components and everything else is geared towards React. Take React Query for example. If you want first class data caching and retry logic etc, then Svelte support was second class at least couple of years ago.
I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic.
Migrating mostly was little effort and consisted of automatic migration and walking through the provided checklist (mostly to ensure I didn't miss anything important), but I don't have any comparison in the JS SPA ecosystem.
Vue 2 to Vue 3 has been equally painful for atleast one app I know about. Compare that to last three versions of Astro (with web components) and it has been a breeze.
> I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic.
The pain varies from project to project. Mine has been touched by a generation of developers of different levels of proficiency. A more disciplined project would’ve been easier to migrate in retrospective.
I think Angular ecosystem really missed the train with schematics (even ngrx!). Schematics could tackle a lot of toil if implemented exhaustively but apart from Angular and Material, nobody else seems to implement them effectively for brownfield projects.
I tried Angular 2+ back in the day. I found it frustrating to learn as the API had changed between versions, and when searching for help you would come across a blog post/stackoverflow answer, start implementing it and realise it didn't work in the version of Angular your project was in. Frustrating.
Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.
this doesn't really contradict with
> async task (or green thread, whatevs) per connection
The async tasks will probably run on a thread pool (e.g. in tokio).
reply