podman's been great for me on macOS for testing stuff quick; which earlier used to need a whole limactl[3]/virt thing.
you can set it up with qemu-user-static for --platform linux/amd64; i don't remember which i exactly used, or if official docs have been updated for it but looked something like [1]
there is one sneaky bug in qemu that breaks uv [2] for cross-platform targets so i keep having to fall back to lima for that, but great otherwise.
Puppy via USB was one of my first. My real first was SUSE distributed via CD-ROM in a GNU/Linux magazine. I used to run Puppy from not a usb drive but a hard drive in an external closure plugged into the USB port. I was a poor college kid and that's all I had.
I just published Fintech Engineering Handbook distilled from 6 years of tears, sweat and swears.
It’s a free ~25-page resource with various hints and patterns around handling money.
Tell me what you think!
other than that, peruse the commits on the source [1], or wait for the author to respond.
A lot of the RFCs are flavored by the lack of https and prevalence of forward proxies run by the ISPs to improve perceived speed and reduce their network loads.. Back in the day.
By my estimation, that's why they explicitly call out only the client and origin can know what a GET body means; proxies should forward as-is and ignore.
Those days of ISP forward http proxies are gone, but those semantics are still fine; the body means what the origin and client agree it means.
> we brought down image creation time to mere seconds, even for images that were multiple GiB in size
this sounds interesting; for e.g., was wondering the other day if we could build images without actually pulling base images.. everytime we compile, we copy artifact(s) onto a multi-hundred MB base image which definitely doesn't need to be pulled everytime.
You absolutely can just build things and put them on base images without building or pulling the base image at any point. This is a central feature of ko, a simple container build tool for most Go applications: https://ko.build
There are many ways to achieve this. If you are just copying artifacts, and not using RUN, then there is in principle no need to download the base image at all. Feel free to message me if you'd like to chat (email is in my profile).
I can't comment on BuildKit, unfortunately, since I haven't used it. My experience comes from building bespoke systems (an image builder and a custom registry) fully from scratch, because we needed to have full control in order to achieve the performance we were aiming at.
Controlling both the builder and the registry is super nice btw, because they can work together. If the builder knows some of the layers already exist in the registry, it merely has to create and push the remaining ones (without downloading any of the other layers, not even those from the base image). That gives you near-instant builds once the biggest layers are cached in the registry!
Since builds usually happen in CI, and pulls happen elsewhere (e.g., a kubernetes node), in the end layers are only downloaded when the resulting container image is actually used.
Base image independent layers is something I’ve pondered about, but doesn’t feel compatible with things like apt. This conversation is giving me more reason to go implement lazy/fuse base layers though. My exports are already pretty fast due not not using tar+deduplication with similar layers, but pulling the base can still take several minutes.
https://docs.slack.dev/reference/block-kit/block-elements/ri...
admittedly i don't think there's a way for humans to do it through the ui currently yet, e.g.,
@@@ ```lang foo ``` @@@