pgrust sounds very interesting, but with the deep changes there’s no viable path to upstream it - is the end goal to be robust enough that it’ll get wide adoption?

Is it really interesting though? It's essentially just vibe-coded by people who are unqualified for this kind of work. One of the authors claimed that what qualified them was having worked on a large-scale postgres cluster; they never actually worked on databases or compilers.

They are going to lose their coding driver's license.

Weirdly Apple seems to have something like this built-in for finding an apple TV remote - but the same flow doesn't appear to be launchable for any other device

It works for newer AirTags as well, this isn't BLE based but Ultra Wideband.

That's an entirely different technology, and if you look at it from an RF lens, a highly impressive one.

UWB is interesting.

If you use your phone as a key for your Tesla, you can turn on "nearby interactions" on the phone and the car can very accurately know your position.

Then with the accurate positioning, you can stand still in front of your trunk, and have it open. (it is a setting, hands free trunk/frunk)

Upthread the implication seems to be that smolmachines would be in some way a replacement for orbstack to run docker containers

But it seems more like a completely different way to run isolated workloads?

smol machines is a virtual machine, akin to firecracker but designed to run locally as well

It also has container-inages support built-in with crun so you can create a VM with a container running by default.

You can also just... run docker inside of it.

on the rare occasions where I need to loudly indicate my presence to a motor vehicle I wouldn't really want to be moving my hands - if I have time to move a hand to a horn I probably have time to brake/manouvre instead.

Generally in those situations I shout really loudly at the driver, and in general they seem to hear me

The way AWS keep their pricing section completely separate from their system and architecture docs, despite architecture being the primary driver of cost, is a major contributor to this

A bitmap index scan allows the database to narrow down which pages could include the data, but then still has to recheck the condition on the contents of those pages - so will still not be as performant as an proper index scan

With postgres indexes not containing liveness data for tuples you'll have to hit quite a lot of those pages anyway, unless they are frozen.

This pitch seems ok to people using simple log aggregation tools or metric tools that have to be wary of tag cardinality

But how does it compare to an actual modern observability stack built on a columnar datastore like Honeycomb?

Any advice on how to learn modern Swift?

When I tried to do learn some to put together a little app, every search result for my questions was for a quick blog seemingly aimed at iOS devs who didn’t want to learn and just wanted to copy-paste the answer - usually in the form of an extension method

A failure mode of ULIDs and similar is that they're too random to be easily compared or recognized by eye.

This is especially useful when you're using them for customer or user IDs - being able to easily spot your important or troublesome customers in logs is very helpful

Personally I'd go with a ULID-like scheme similar to the one in the OP - but I'd aim to use the smallest number of bits I could get away with, and pick a compact encoding scheme

I’m amazed that this comment is so low down

Stacked diffs seems like a solution to managing high WIP - but the best solution to high WIP is always to lower WIP

Absolutely everything gets easier when you lower your work in progress.

This seems idealistic. It's very normal to be working on a feature that depends on a not-yet-merged feature.

> It's very normal to be working on a feature that depends on a not-yet-merged feature.

Oh sure, many bad ideas and poor practises such as that one are quite "normal". It's not a recommendation.

I invite you to look into feature flagging.

It is entirely viable to never have more than 1 or 2 open pull requests on any particular code repository, and to use continuous delivery practices to keep deploying small changes to production 1 at a time.

That's exactly how I've worked for the past decade or so.