Live data from Hacker News

Viewing profile — jacobwg

jacobwg

HN member
Joined
Fri, Jun 03, 2011, 3:59 PM UTC
HN karma
3,697
Public activity
449 items

About jacobwg

Co-founder and CTO of Depot (W23, https://depot.dev)

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

  1. comment
    Comment #49208177

    It's to prevent theft by the delivery person or by the wrong recipient

  2. 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) -…

  3. story
  4. 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…

  5. job
  6. job
  7. 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…

  8. 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.

  9. job
  10. story
  11. job
  12. 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…

  13. job
  14. story
  15. job
  16. 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…

  17. 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…

  18. 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…

  19. 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 …

  20. 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…

  21. 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.

  22. 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…

  23. 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…

  24. 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…

  25. comment
    Comment #43507095

    We're having some success with doing this at the block level (e.g. in-memory writeback cache).