i’ve been waiting a few years for iphone fold, im excited that they’re releasing it this year.
its both iphone mini (yay!! mini iphone again) and ipad mini (yay!! hueg screen for bedtime youtube) in one device presumably with a cpu powerful enough to run cyberpunk 2077. what a world :)
current view transition stack on ios was built for static transition between two well know layouts, like portrait to landscape rotation change. i would like live reflow too but i suspect 99% of existing apps aren’t ready to reflow at 120hz when they’ve been written around tween(start layout, end layout) style for decades
UIKit apps can already resize fluidly on Mac Catalyst and iPadOS. I suspect the issue here is more related to the video encoding / streaming used for iPhone Mirroring.
you can home tenants in a data center close to them, run a copy of your app in each region including the datastore. keep a central db for accounts, billing, etc but user content is easy enough to shard regionally.
taken to extreme, cloudflare durable objects & workers let you place data very close to a tenant automatically; but you lose total write throughput on top of sqlite.
oh for sure you start with client side cache & optimistic updates. but u need low latency / regional backend for multiplayer to feel good. I didn’t realize who i was replying to, aaron is probably one of the few people who think about sync engines more than me. anyways we do both at notion and of course we did local cache first client way before we did multi region at Notion.
But this is kind of meaningless unless the tenants themselves are in one geo. Take linear as an example, this strategy works as long as your company that uses linear is all colocated in one area. As soon as you have remote people it falls apart.
Not necessarily. You can do async replication either at the app level or DB level to other regions
Each individual user is fast due to close geo and everyone else has a small (potentially trivial) lag to see writes.
Not sure if such an architecture is worth the complexity, but it's definitely possible.
Actually such architectures are quite old. Back when I worked at Kmart, they had a store server in the office of every store. The store server would asynchronously sync back to corporate (afaik an overnight cron but I think it could be triggered on command). That was the geographically close "edge" server and the store was the tenant. Most ops were quick. For cross tenant queries, clients maintained a list of store numbers and locations. They did some bit twiddling with the store number to calculate a deterministic IP which went to the store server for that store (tenant discovery). With the server IP they could run remote queries directly at the cost of much higher latency since you had to go back through the corporate S2S VPN to headquarters then to the target store.
As for cross geo, you can have writes always be instantly acknowledged at the closest geo location and immediately available to nearby clients while they get asynchronously replicated in the background. Really you'd only see marginal higher write latency when two people are working at the same time in different geographies. That's partially mitigated with time zones
What you are describing is exactly what sync engines do. You can have replicas on the server or replicas on the clients. The tradeoffs are the same except the client-based replicas can be in memory, accessed synchronously directly on the ui thread. No server latency at all.
But it does mean you gracefully degrade so the majority of the company sees the target latency <100ms and the rest of the company sees "not geo-optimized" latency.
Only in the case where there is such a majority of the company that is tightly geolocated.
Again, AWS latency us-west-1 to us-east-1 is 70ms. That's absolute best case for one round-trip that does absolutely no work. And it's ignoring the case of anyone outside of continental US.
Add in actual server-side work, db interactions, and contention - and you're quickly looking at hundreds of ms.
If your users are truly broadly geodistributed, there's no avoiding hundreds of milliseconds of latency if you want strong consistency. You're fighting the speed of light. You can move the source of truth closer to the majority of users with effort without meaningfully regressing performance for the users who aren't tightly geolocated, so you can treat it as a fairly pure optimization.
is it really that far fetched that instead of bikes, football, and basketball, klingon society decided to give all their kids batleths, so everyone grows up really into it?
Deno originally was not Node compatible at all, and required you to do everything in a Deno way:
- Deno plugin in editor, otherwise types dont work
- All imports via absolute URL, like Golang
- No backwards compatibility, so no existing code worked.
Since Deno 2, they've taken Node compatibility much more seriously, hence the 50% to 70% compatibility jump claimed here.
Bun on the other hand, tried to make things Just Work without requiring any thinking for Nodejs / TypeScript developers. It's basically the `node` development experience with all incidental frictions removed (but some segfaults added).
tl;dr: you can use `bun` to write node projects, but `deno` can only be used for deno projects
Launch 1 True Recovery, open Terminal, then run “bputil -a” (without the quotes) to downgrade system security and allow for more boot arguments. You might need to restart after this step.
Then, run [nvram boot-args=”-s”] (without the square brackets). Restart to launch Single User Mode.
Once in Single User Mode, run these commands (in the following order) to mount the root volume group:
1. mount -P 1
2. /usr/libexec/init_data_protection
3. mount -P 2
Future restarts will always launch Single User Mode first. To stop launching Single User Mode, run [nvram boot-args=“”] (without the square brackets).
To restore your system to full security, run “bputil -f” (without the quotes). If you choose to run that command in macOS, prefix “sudo” to the beginning.
Wow, this is super cool. It almost feels like a DIY pocket-Cloudflare. I’m curious how a WASM binary gets mapped to HTTP endpoints that take JSON, how much of that is Pollen vs Extism? Are the routes encoded in the WASM binary somehow?
Ha, thanks! The routing is all Pollen. You reach the workloads through the gRPC control API (exposed on a socket on the host) via a `pln call seed_name function_name payload` or with a more traditional gRPC client. But once they're in, it routes them to a keyed WASM instance of that given seed on whatever node happens to be hosting it at that moment.
its both iphone mini (yay!! mini iphone again) and ipad mini (yay!! hueg screen for bedtime youtube) in one device presumably with a cpu powerful enough to run cyberpunk 2077. what a world :)
reply