P.S.: my hot (and quite possibly wrong) take on the near future of software development is that we are going to see a shift toward local first tooling since agents can super easily deploy and use these libraries in isolated sandboxes (pods/containers/VMs). Obviously, this doesn't apply to everything and there are many use cases that will still require distributed, zero-downtime deployments. But, for most applications, the cost of deploying code/infra can be made so cheap with an ergonomic library that I think a lot of the appeal of centralized services/servers is decaying (especially if remote object storage can be plugged into the storage layer of a library/tool). Anyhow, those are just my two cents.
NOTE: litelink auto-generates a `litelink_offset` column (unique, doesn't compress). This column dominates bytes/row in rows where the the byte ratio is < 1 (litelink data is larger). The old, hand-rolled capture lacked any monotonically increasing offset. Also, for the rows that say byte ratio is"all" (reporting zero litelink files), this is because all of the data fits in litestream replicated WAL and there are not yet any compacted files
P.S.: my hot (and quite possibly wrong) take on the near future of software development is that we are going to see a shift toward local first tooling since agents can super easily deploy and use these libraries in isolated sandboxes (pods/containers/VMs). Obviously, this doesn't apply to everything and there are many use cases that will still require distributed, zero-downtime deployments. But, for most applications, the cost of deploying code/infra can be made so cheap with an ergonomic library that I think a lot of the appeal of centralized services/servers is decaying (especially if remote object storage can be plugged into the storage layer of a library/tool). Anyhow, those are just my two cents.