Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kylegalbraith
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
61.
▲
by
kylegalbraith
2y ago
This is an interesting read and take. I don't think it's applicable to everything because not everything fits neatly into "if I explain it, you will buy". This also cripples any kind of outbound motion, which for some bu
62.
▲
by
kylegalbraith
2y ago
Yeah, this is definitely lacking on our pricing page; thank you for flagging it. We charge $0.08/minute for macOS runners [0] which has 8 CPUs, 24 GB of memory, and 150 GB of disk. They run with M2 chips, so the closest GitHub-hosted m
63.
▲
by
kylegalbraith
2y ago
This is exciting to see as arm64 is really a growing space, as we've seen since first launching our Docker image build acceleration [0]. Free for public repos is definitely a strong pull if you can live with some of the quirks. Even wi
64.
▲
by
kylegalbraith
2y ago
One of the founders of Depot here. Always feel free to ping me directly (email in my bio) if you ever want to chat more about container builds in general.
65.
▲
by
kylegalbraith
2y ago
This is the type of project I still absolutely love reading about on HN. It feels like we use to see these types of things much more frequently than we do now. But I’m sure that is just my own browsing habits changing.
66.
▲
by
kylegalbraith
2y ago
I got excited until I saw the one zone part. That is a critical difference in terms of cost.
67.
▲
Pulling Containers Faster with EStargz
(depot.dev)
1 points
by
kylegalbraith
2y ago
|
0 comments
68.
▲
Docker Buildx Explained
(depot.dev)
4 points
by
kylegalbraith
2y ago
|
1 comments
69.
▲
by
kylegalbraith
2y ago
This was a great read. As an American who is currently living in France, I'm always blown away by how easy it is for me to get just about anywhere via train.
70.
▲
Building a custom Envoy discovery service
(depot.dev)
1 points
by
kylegalbraith
2y ago
|
0 comments
71.
▲
by
kylegalbraith
2y ago
Other founder of Depot here. AWS is pretty close to this idea with their Warm Pools [0]. But for our use case, they're just too slow to react to changes. We observed 60s+ to notice a change and actually start the machine. That doesn&#x
72.
▲
Building Containers from Scratch: Layers
(depot.dev)
28 points
by
kylegalbraith
2y ago
|
0 comments
73.
▲
by
kylegalbraith
2y ago
It's very strange how these types of nice UX things seem to be lacking in big modern apps nowadays. I think we all know why, they aren't revenue drivers. But, surely this wouldn't be that hard for Spotify to do themselves. Sh
74.
▲
by
kylegalbraith
3y ago
This is what HN is all about. This probably isn't your next big LLM project but its a wonderfully simple example that shows what is happening underneath the hood. Do you plan on writing up something like a blog post to go with it?
75.
▲
by
kylegalbraith
3y ago
Just curious if you thought of other build systems outside of Bazel and if so which ones & why?
76.
▲
Depot Build API: build Docker images as a service
(depot.dev)
3 points
by
kylegalbraith
3y ago
|
0 comments
77.
▲
by
kylegalbraith
3y ago
Yup! We observed the same thing back before we built Depot. The act of saving/loading cache over a GHA network pretty much negated any performance gain from layer caching. So, we created a solution to persist cache to NVMe disks and or
78.
▲
by
kylegalbraith
3y ago
Couldn't agree more. Somewhere, we lost the concept of disks in CI unless you run it yourself, and a lot of build tools could benefit from having them. We came to the same conclusion and built Depot around this exact workflow for the D
79.
▲
by
kylegalbraith
3y ago
This is definitely a direction to try. But if its faster Docker image builds and a layer caching system that actually works, you should definitely try out Depot. We automatically persist layer cache to persistent NVMe devices and orchestrat
80.
▲
by
kylegalbraith
3y ago
Thanks for the shout-out regarding Depot, really appreciate it. We came to the same conclusion regarding Docker layer cache and thus why we created Depot in the first place. The limitations and performance surrounding GitHub Actions cache l
81.
▲
by
kylegalbraith
3y ago
Other Depot founder here. This is a really great point. You've hit on all the main points regarding Docker image cache in GHA. Persisting the massive layer cache over networks is incredibly slow and has weird limits (like 10GB per repo
82.
▲
Aqua – Declarative CLI Version Manager Written in Go
(github.com)
1 points
by
kylegalbraith
3y ago
|
0 comments
83.
▲
by
kylegalbraith
3y ago
Do you not offer Arm images for the various services? For folks wanting to run this stack, I'd imagine some of them are interested in running on Arm for better cost optimization. Maybe it doesn't matter for how lightweight the ser
84.
▲
by
kylegalbraith
3y ago
Does this work with uv as well?
85.
▲
by
kylegalbraith
3y ago
This is super cool and was very easy to get going. Missing keyboard shortcuts is pretty annoying and would make this even simpler. I hopped in hoping it was like a Google Drawing, which it's pretty close, but the lack of keyboard short
86.
▲
Building Containers from Scratch: Layers
(depot.dev)
1 points
by
kylegalbraith
3y ago
|
0 comments
87.
▲
Buildx bake deep dive: Bake all your Docker images with one command
(depot.dev)
1 points
by
kylegalbraith
3y ago
|
0 comments
88.
▲
by
kylegalbraith
3y ago
It's always a lot of fun to see stuff like this on HN. It's a reminder that there are still a lot of fun and amusing things on the internet. I also love seeing stupid simple HTML sites like this. It's hideous to look at but i
89.
▲
by
kylegalbraith
3y ago
Dagger is quite cool, and we've been doing some collaboration with their new Zenith stuff. We actually have a module where you can route an image build in your Dagger pipeline to Depot and do interesting things with the result as we st
90.
▲
by
kylegalbraith
3y ago
This is one of the things that led us to write this post! It's almost all undocumented, as you're mentioning, and there are quite a lot of complexities underneath the surface that often feel very inefficient as well. We're wo
More ›