Viewing profile — jacobwg
jacobwg
HN member- Joined
- Fri, Jun 03, 2011, 3:59 PM UTC
- HN karma
- 3,697
- Public activity
- 449 items
- HN profile
- View on Hacker News ↗
About jacobwg
Previously at Era Software, Thorn, Webflow, Playlist.
jacobwgillespie@gmail.com
https://jacobwgillespie.com
https://github.com/jacobwgillespie
https://twitter.com/jacobwgillespie
[ my public key: https://keybase.io/jacobwgillespie; my proof: https://keybase.io/jacobwgillespie/sigs/F-KFv_EcnLeEUyxHBMSuyDH8bw4t5-4sfhrxE-zbdMs ]
Recent public activity
-
comment
Comment #49208177
It's to prevent theft by the delivery person or by the wrong recipient
-
comment
Comment #49202856
We've been working on this at Depot[0]. We built the internals of Depot CI as a general-purpose workflow engine that understands GitHub Actions as an input (with plans to extend) -…
- story
-
comment
Comment #47502386
Hey, I'm one of Depot's founders - we built our own custom parser for the YAML syntax that translates to Depot CI's orchestration APIs. This API will actually be a public API short…
- job
- job
-
comment
Comment #45724677
You all should add EC2 - extra bonus if you have some way of tracking performance in addition to errors (right now we're seeing EC2 instances in us-east-1c not transition out of Pe…
-
comment
Comment #45724635
We've been observing EC2 instances launched in us-east-1c (use1-az2) remain in Pending status for a very long time / indefinitely, starting at around 16:00 UTC.
- job
- story
- job
-
comment
Comment #44660617
Since we launched this last year, GitHub released a v2 of their internal cache API [0], based on Twirp [1] of all things, so we adapted to that. Interestingly that Twirp service al…
- job
- story
- job
-
comment
Comment #44162328
Depot (W23) | Enterprise Support Engineer | Remote (UK, Europe) | Full-time | €100K - €160K | https://depot.dev Depot is the fastest place to build software. We accelerate builds f…
-
comment
Comment #44070930
Not quite for every container, but we operate a multi-tenant remote build execution service (container builds, GitHub Actions jobs, etc) so we launch a lot of ephemeral VMs in resp…
-
comment
Comment #44070901
We also do GitHub Actions runners as a service, so a very high volume of differently-sized ephemeral VMs. We’ve experimented with .metal hosts, however they represent a bin-packing…
-
comment
Comment #43509330
Yeah we do some similar tricks with our registry[0]: pushes and pulls from inside AWS are served directly from AWS for maximum performance and no data transfer cost. Then when the …
-
comment
Comment #43509027
No worries, entirely valid question. There may be ways to tune page cache to be more like this, but my mental model for what we've done is effectively make reads and writes transpa…
-
comment
Comment #43508534
Exactly, a ramdisk-backed writeback cache for the root volume for Linux. For macOS we wrote a custom nbd filter to achieve the same thing.
-
comment
Comment #43508270
Today we (Depot) are not, though some of our customers configure this. For the moment at least, the ephemeral public IP architecture makes it generally unnecessary from a rate-limi…
-
comment
Comment #43508048
The block level has two advantages: (1) you can accelerate access to everything on the whole disk (like even OS packages) and (2) everything appears as one device to the OS, meanin…
-
comment
Comment #43507512
A list of fun things we've done for CI runners to improve CI: - Configured a block-level in-memory disk accelerator / cache (fs operations at the speed of RAM!) - Benchmarked EC2 i…
-
comment
Comment #43507095
We're having some success with doing this at the block level (e.g. in-memory writeback cache).