glenjamin

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?

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

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 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.

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.

Does pglite in memory outperform “normal” postgres?

If so then supporting the network protocol so it could be run in CI for non-JS languages could be really cool

There's a couple of passing mentions of Download Monitor, but also the timeline strongly implies that a specific source was simply guessing the URL of the PDF long before it was uploaded

I'm not clear from the doc which of these scenarios is what they're calling the "leak"

that looks neat - how but do you handle failover/restarts?

Other than motherduck, is anyone aware of any good models for running multi-user cloud-based duckdb?

ie. Running it like a normal database, and getting to take advantage of all of its goodies

This reminded me of a slide from a Dan North talk - perhaps this one https://dannorth.net/talks/#software-faster? One of those anyway.

The key quote was something like "You want your software to be like surgery - as little of it as possible to fix your problem".

Anyway, it doesn't seem like this blog post is following that vibe.

This doesn't seem accurate to me - Gambling sites legally operating in the UK already have strict KYC requirements applied to them via the Gamling regulator.

Visiting a gambling site isn't restricted, but signing up and gambling is.

The only mention I can see in this document of compression is

Significantly smaller than JSON without complex compression

Although compression of JSON could be considered complex, it's also extremely simple in that it's widely used and usually performed in a distinct step - often transparently to a user. Gzip, and increasingly zstd are widely used.

I'd be interested to see a comparison between compressed JSON and CBOR, I'm quite surprised that this hasn't been included.

It’s worth noting that if you DisallowUnknownFields it makes it much harder to handle forward/backward compatible API changes - which is a very common and usually desirable pattern

oh, I can't edit now but that was supposed to say "nudge"

I think in some cases (like WhatsApp) the better model exists and is available, but isn’t used by the app - possibly as a judge to get you to give it more permissions

On iOS Strava’s app is able to access a photo picker, and the app only gets the photos I actually pick

Meanwhile WhatsApp insists on using the model where it tries to access all photos, and I limit it to specific ones via the OS

It would be cool if someone could come up with a way for the runtime system to automatically wrap errors with the calling context.

That way you’d be able to trace the stack of functions that were involved in passing an error back up to the place where it’s actually handled.

I chatted to a staff member on the checkout of my local coop supermarket

She said that every shelf item is ordered on a JIT basis as the store stock levels require them - there are no standing orders to a store

Based on that, I presume they didn’t really know what any store would need

Even when they were struggling my local store still had a decent stock of lots of stuff - just some shelves were empty

No, it's "hard", because it requires an extension to monitor all requests to a different search enging and hijack those to perform a redirect.

This is a clever workaround by Kagi, but a glaring hole in the Safari extension API surface area.

I find it a little surprising that the famous apple blogger neglects to mention that Apple makes it hard to use a search engine like Kagi on iOS!

Complaining about the for loop behaviour seems odd. Variables declared in the expression section of the loop are scoped to the loop body - this is generally reasonable and the least likely to produce errors.

Notably, Go initially decided to stick with the C-style approach and have the scope be outside the loop, and has since decided that the tiny performance improvement this provides isn't worth the many many times it's tripped people up, and has changed the semantics in recent versions: https://go.dev/blog/loopvar-preview

If you’re running inside AWS us-east-1 then docker hub will give you direct S3 URLs for layer downloads (or it used to anyway)

Any pulls doing this become zero cost for docker hub

Any sort of cache you put between docker hub and your own infra would probably be S3 backed anyway, so adding another cache in between could be mostly a waste

That’s how you’d expect it to work, but that’s not how pod deletion works.

The pod delete event is sent out, and the load balancer and the pod itself both receive and react to it at the same time.

So unless the LB switchover is very quick, or the pod shutdown is slow - you get dropped requests - usually 502s.

Try googling for graceful k8s deploys and every article will say you have to put a preStop sleep in

The fundamental gap in my opinion, is that k8s has no mechanism (that I am aware of) to notify the load balancing mechanism (whether that's a service, ingress or gateway) that it intends to remove a node - and for the load balancer to confirm this is complete.

This is how all pre-k8s rolling deployment systems I've used have worked.

So instead we move the logic to the application, and put a sleep in the shutdown phase to account for the time it takes for the load balancer to process/acknowledge the shutdown and stop routing new traffic to that node.

The fact that the state of the art container orchestration system requires you to run a sleep command in order to not drop traffic on the floor is a travesty of system design.

We had perfectly good rolling deploys before k8s came on the scene, but k8s insistence on a single-phase deployment process means we end up with this silly workaround.

I yelled into the void about this once and I was told that this was inevitable because it's an eventually consistent distributed system. I'm pretty sure it could still have had a 2 phase pod shutdown by encoding a timeout on the first stage. Sure, it would have made some internals require more complex state - but isn't that the point of k8s? Instead everyone has to rediscover the sleep hack over and over again.

This strikes me as something that could be done for the highest traffic packages at the backend, rather than be driven by the client at pubish-time.

This matches my experience - I was intentional about not saying that a project manager was important - just that project management (the practice) is important.