mnutt

In cases where startup time matters and you have a slow disk, bundling can drastically reduce the number of filesystem calls you have to make for large dependency graphs.

I have been playing around with building an Iroh Tunnel Sandstorm app that can connect two Sandstorm instances, and share some capabilities exposed from one Sandstorm instance to the other, as if the capabilities were local. Iroh has been very reliable throughout the process.

WebKit does allow outside contributions, though that example is perhaps not the most illustrative as it is from an Igalia employee. Igalia maintains substantial parts of WebKit and at this point has to be the #2 contributor other than Apple themselves.

I think you could in theory have a similar webkit-based stripped down headless crate that might have a good tradeoff of features, performance, and size.

I have a large rails app that was plagued with slow specs using factory_bot. Associations in factories are especially dangerous given how easy it is to build up big dependency chains. The single largest speedup was noting that nearly every test was in the context of a user and org, and creating a default_user and default_org fixture.

Would be interesting to see a benchmark with the rust binary with successively more “bloat” in the binary to separate out how much of the cold start is app start time vs app transfer time. It would also be useful to have the c++ lambda runtime there too; I expect it probably performs similarly to rust.

Tangent: when you have a lambda returning binary data, it’s pretty painful to have to encode it as base64 just so it can be serialized to json for the runtime. To add insult to injury, the base64 encoding is much more likely put you over the response size limits (6MB normally, 1MB via ALB). The c++ lambda runtime (and maybe rust?) lets you return non-JSON and do whatever you want, as it’s just POSTing to an endpoint within the lambda. So you can return a binary payload and just have your client handle the blob.

Sure, you can only use EC2, not use autoscaling or spot and instead just provision to your highest capacity needs, and not use any other AWS service that relies on dynamo as a dependency.

We still take some steps to mitigate control plane issues in what I consider a reasonable AWS setup (attempt to lock ASGs to prevent scale-down) but I place the control plane disappearing on the same level as the entire region going dark, and just run multi-region.

we never had any issues, because we didn't depend on calling AWS APIs to continue operating. Things already running continue to run.

I think it was just luck of the draw that the failure happened in this way and not some other way. Even if APIs falling over but EC2 instances remaining up is a slightly more likely failure mode, it means you can't run autoscaling, can't depend on spot instances which in an outage you can lose and can't replace.

Even their transfer rates between AZs _in the same region_ are expensive, given they presumably own the fiber?

This aligns with their “you should be in multiple AZs” sales strategy, because self-hosted and third-party services can’t replicate data between AZs without expensive bandwidth costs, while their own managed services (ElastiCache, RDS, etc) can offer replication between zones for free.

This is a great project writeup, I did something _very_ similar for my son. (HT802, asterisk, twilio, calling relatives) With all of the NAT involved I could never get sjsip to work properly so I ended up having to use the old sip module, but looking at yours makes me want to revisit it.

Once you have asterisk set up and running, it becomes easy to also set up all sorts of other extensions like "check the weather" / "tell a joke" / "check the train statuses". I put up some code for it here: https://github.com/mnutt/rotary

That's amazing, what a great idea.

As a four year old, my child loved playing "the subway game", which is similar to this but just in our heads: I name two subway stations and he tries to think of the fastest route between them. When that is exhausted, we move onto the fewest transfers, the most convoluted routes, the 1968 lines only, etc. There's just something about the NYC subway which really draws kids (and many adults) in.

I did a writeup of my own experiences using Asterisk for this exact use case: https://github.com/mnutt/rotary

We tried this out a middle schoolers at an installfest in Alabama in the 90s, but something was broken with the resulting install and had to wipe it and start over. Funny that 25+ years later I learn that the problem could have been that the locale was set to en_RN…

You can even do neat things like having the revalidate fetch tell your backend “I served this object out of cache 1100 times since last fetch, maybe consider putting a few extra cpu cycles into the compression on this one”

Looks interesting, I'm curious how you settled on WebDAV? A decade ago I built a NextCloud alternative backend that also used WebDAV, and I'm not sure it's something I would ever touch again. Lots of clients say they support WebDAV but they all do slightly different things, and if you own the clients then there are probably simpler protocols.

Yes, there are a bunch of redis+disk projects out there, one big consideration is the size of your values: some must hold all keys in memory and only offload values to disk, while others (kvrocks, other rocksdb dbs) can offload both keys and values to disk, with some other tradeoffs.

I’ve been testing kvrocks as a replacement for a Scylla use case where we have TBs of data and uniform TTLs. In many of these LSM dbs, compaction is the thing that really kills throughput, making TTLs (or really any updates/deletes) difficult.

KVRocks doesn’t expose it directly right now so it requires code changes, but so far I have had good success with FIFO compaction. When an sstable gets old enough, it just gets dropped.

I had a similar experience: I built dragging and handle resize, then later added rotation via a bit of trigonometry. Each operation worked fine separately, but if you tried to rotate and then resize, unexpected things happened. I left the bug for years, thinking I needed to come back and just add a bit more trigonometry to get rotated resizing working. When I finally came back to it I spent quite a while hacking at it before realizing that matrices were a much better way to describe the solution.

Using jQuery CDN might have helped with cross-site caching in the past, but now all major browsers have cache partitioning by origin for privacy reasons.

On Mobile Safari at least, you can press and hold the image to share. I imagine there's probably an equivalent gesture on Mobile Chrome. I spent considerable time many years ago trying to figure out how to indicate to users that they could do this. ("press and hold to share", with a progress indicator) Results were mixed.

Fortunately, these days if you wanted to make it more obvious you could hook up a regular Share button to navigator.share() API and pass it your image blob.

As of 2024, WebKit's Linux ports (GTK and WPE) are switching to Skia too. [0] Prior to that, they used cairo.

[0] https://blogs.igalia.com/carlosgc/2024/02/19/webkit-switchin...

Grace mode itself doesn’t prevent thundering herd; varnish coalesces all requests automatically and grace mode is used to increase the likelihood of clients receiving cached (albeit stale) responses.

Looks very nice. I'm curious about "no mjml" -- I've worked with authoring tools in related domains and found that separating the serialization format from the output format has some benefits. It manifested in needing to store editing concerns like "this element is locked" in the HTML when it had no business being in the HTML output.

It sounds nice, but also consider: 1) depending on how your app crashes, are you sure the buffer will be flushed, and 2) if logging is expensive from a performance perspective, your base performance profile may be operating under the assumption that you’re humming along not logging anything. Some errors may beget more errors and have a snowball effect.

As the author of a different VoIP write-up that made the front page, you're not wrong. There's a lot of variance across home networks, and SIP behind a NAT can be incredibly painful to get working correctly.

They talk about the limitations of the EC2 autoscaler and mention calling LaunchInstances themselves, but are there any autoscaler service projects for EC2 ASGs out there? The AWS-provided one is slow (as they mention), annoyingly opaque, and has all kinds of limitations like not being able to use Warm Pools with multiple instance types etc.

They’re also significantly narrower than they need to be to stop a car: https://gothamist.com/news/security-measures-on-hudson-river...

Still, I guess they’re better than the concrete jersey barriers they installed initially, and still have in some places along that route.

That looks daunting, but it's not just a big string of key sequences you have to memorize. Half of them are moving the cursor around, and the sequences follow from what you're doing. It'd be a bit like critiquing the equivalent vscode '" " <left arrow> C-v C-a <shift> C-e ...'

That’s awesome. I love that it’s the intersection of tech and something so wholesome and unequivocally good. It feels hard to find in tech these days.