aobdev

This is hardly surprising after the recent string of venture-backed developer tooling acquisitions: Bun -> Anthropic, VoidZero (vite) -> Cloudflare, Astral (uv, ruff) -> OpenAI

The only thing that remains to be seen is how these affect those tools going forward (and who's next)

I had to double check the site because I believed for a second that Apple was doing some pricing sleight of hand by saying "Look, it's cheaper!" and removing half the product...

But this isn't true at all, it's $129 for a normal case, $149 for a wireless charging case.

Python and Java do not have any similar constructs

That only works with "G" brand gaming devices. Their entire MX line does not allow you to store customizations in onboard memory.

Logitech mice and keyboards have extra features that the OS would consider non-standard; you can customize a lot of behaviors as well as map extra buttons to specific actions. For some reason, Logitech decided not to store customization settings on-device so there is a background daemon that must run on the host. Also inexplicably, it is an electron app with a 600MB install footprint requiring online connectivity (apparently there's also an offline version, weighing in at 1.2GB). Also not available on Linux.

I’m not claiming it’s not fine, but it is a surprising consideration for a relatively small deployment. You have to start planning around Postgres’ architecture for anything larger, hence the solution in PgBouncer.

Yes but they can’t be shared. If you size your pool to hold 10 connections (because asyncio can handle that and more), then deploy with uvicorn —-workers 4 (which should match the number of cores on your app server), and then deploy to 3 app servers (for redundancy) then you’ve now got 120 open connections to Postgres. Run anything more than a trivial query and you’re easily at gigabytes of ram.

That's fine but doesn't address the issue that PgBouncer does. Your application connection pool can multiplex all the connections needed in one application. PgBouncer can multiplex the connections across all applications (whether different apps or many instances of the same app).

This solves the latency but not the overhead--you'll end up with a full pool of connections for each running instance of your application.

> If you have a connection pooler in your application, and the DB is only used for this application, you don't need an external pool like PgBouncer.

But this is only true if you have no more than a few running instances of your application. So it feels like the cases where you must have Postgres (over an alternative like SQLite) but can't justify PgBouncer are very narrow.

Every single connection to Postgres is a new process, which requires a fork and new memory allocation (at least 10MB plus whatever you need for your query).

PgBouncer opens a pool of connections and then reuses them each time a client asks for a connection. This reduces latency (no more fork) and overhead (reuse memory).

The author is pretty unsympathetic towards those who give their lives to “Workism” in exchange for money, no?

Huh, TIL. Thanks for pointing it out.

I think you’ve made an extreme leap in your interpretation of the comment you’re replying to…

Airlines have kept tabs on Bluetooth and WiFi hotspots as early as the Samsung Galaxy Note 7 incidents (2016)