That depends on the domain.
HN user
a_t48
Building the world's fastest container registry at clipper.dev
The common question I get asked about building my SaaS: "What's to stop customers from making their own?"
Sure, if you want to put an equal amount of time into what I've built, be on the hook for maintaining the infra, probably diverge from what will end up being a stable spec, go for it. It won't be as good, it won't be as fast, you will be fighting Claude at every corner just like I did to build the right thing. But consider this: people still pay for Dockerhub even though anyone can spin up any number of open source registries. SaaS is no where near doomed, people will always pay to not have distractions from their actual core business cases.
You should put a note in Find a Cofounder not to do that as well. Huge turnoff for me, though I guess a great filter.
I believe there's ways to configure clang to flag dangerous implicit casts as well.
Hey HN. Clipper is an alternative container registry/pull client/BuildKit driver that can do operations an order of magnitude faster by ditching OCI’s tarball format. I’ve spent the past few months heads down on getting the build side of things fast.
The text boxes on top aren't bad, but the background is a total turnoff, it's a big red flag to me. I'd ditch it, remove the fade-in effect that runs at like 10fps, and rewrite your text.
If any Podman engineers are here: does the new /libpod/local/artifacts/add endpoint let me ingest individual layers? I have an alternative pull client that's currently a little hamstrung on Podman compared to docker+containerd, due to having to convert the entire image to tarball to ingest rather than only new layers.
Hey HN. Clipper is an alternative container registry/pull client/BuildKit driver that can do operations an order of magnitude faster by ditching OCI’s tarball format. I’ve spent the past few months heads down on getting the build side of things fast.
Whoops! You're right, and it's too late to edit.
zstd has higher level modes. Default is -3. I saw a good tradeoff between compression speed and ratio up to -9 or so. From -20 to -22 it will use much more memory and IIRC can have downstream effects on decompression speed. I'm using -9 for my container registry and plan to recompress at a higher level for commonly accessed base layers, as well as give customers a button that lets them pay a bit more to do it themselves.
As someone currently with a nasty cold, having to work through it anyhow - please.
It could be opt in.
I get this a lot. Yeah, you can have an LLM copy what I've built, no it's not going to be as good unless you also spend the equivalent of the amount of hours I've spent on it.
Oh hey, second chance queue, nice. I'd originally searched this up because I was curious about how Arabic worked on early computers.
Definitely, it needs both sides.
At least in Oakland, it's the landlord's responsibility to manage pest control. It needs to be done at a building level, or else the roaches will just get shuffled around.
Wife also ran into this, advised her to click "no". Very odd.
Vulkan is a rendering technology, Unreal is an engine, that can render using Vulkan under the hood. You can absolutely do this in Unreal. I implemented this at Cruise using UE4 for integration testing, and it worked great for inference (we weren't doing training on sim at that point, but I was pushing for it! There was a paper out in 2018 or so that showed mixing in a bit of simulated data had an outside positive impact on the outputted model). There are companies out there right now doing this with even more modern renderers. I can't comment on how much the rendering realism gap matters here. I think there's some people out there using a variant of lower quality rendering + some kind of diffusion to get "better" images without having to do detailed modeling/lighting for their sims (fuzzy memory, I don't have a source on this).
typing something like "3.141" results in 5 characters rather than 4. Boo!
I made Docker not suck for large images. 2-10x faster depending on the operation. I’ve spent the past two weeks burning down the last bits needed to release a BuildKit integration.
Just run it under uv :)
I think it's just the images.
I remember this person's blog from before she went on haitus. The drawings attached used to be cute and the header (hero?) image semi-relevant. I hope she brings them back, they had charm!
Why is everything so....wide?
Thought this was mildly interesting. A few months back fuse-overlayfs was rewritten in Rust via Claude.
Hi Guanming/Bill. Would love to chat about what you're doing for actually running the models. I'm in a similar space, speeding up the `docker pull` component of inference deployment on edge devices (among other things!) If you're interested, shoot me an email at kyle@clipper.dev
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.
I haven't gone full custom (yet), just forks (except for the pull client), but totally understand.
Does COPY —-link allow this with BuildKit? In principle it should, in practice I’d guess it ends up pulling the base image.
You can, by using FUSE and lazy pulling files as they are opened. I'm working on doing this, myself.