One of my colleagues recently asked me if there were any best practice guides for designing and testing software daemons (background processes). I hadn’t known of any before writing this blog post (and most of what I’ve found while researching were related to the mechanics of writing daemons), but we came up with a few ideas together and maybe this can serve as a starting point for others.
Note: This post was originally published on the AWS Compute Blog. On Monday, February 11, CVE-2019-5736 was disclosed. This vulnerability is a flaw in runc, which can be exploited to escape Linux containers launched with Docker, containerd, CRI-O, or any other user of runc. But how does it work? Dive in!
In 2018, I helped organize and run the first-ever “Go Northwest” community conference for Gophers (enthusiasts of the Go programming language) in the Pacific Northwest (Seattle, Vancouver, Portland, etc), along with Ryan Cox, Brittany Walentin, Jake Sanders, Yves Junqueria, and Tiffany Jernigan. I think the conference was pretty successful, with 280 attendees and 14 speakers and great feedback on the survey we sent to the attendees. It was a really fun experience for me, and I’d like to share my retrospective (which is, admittedly, written a little late).
Hello! My name is Samuel Karp and I just bought one of those spiffy new .dev domains. Now is as good of a time as any to start putting it to use; I have been wanting a place to publish some writing about technology and this seems an appropriate place. I work for one of those large technology companies and a significant portion of my responsibility at work is writing: I write design documents, I perform code review and design review, I write one-pagers and six-pagers about technology in the competitive landscape, I help plan our products, and so forth. This blog, however, is a place for personal writing about technology; unless otherwise indicated, I speak about my own opinions and those do not necessarily represent the opinions of my employer.