Recently, I’ve been spending a fair amount of time looking at the OCI runtime specification and at the reference implementation, runc. I tend to learn best by doing, and the low-level bits of how containers work have interested me for a long while now, so I’ve started writing a new non-production OCI runtime to learn more about it.
In the OCI spec, the docker run interface that folks familiar with Docker containers use has been broken up into multiple steps: create and start. But what’s interesting about runc’s implementation here is that the standard input/output streams (which I tend to refer to as STDIO) for the container’s main process are hooked up to the STDIO streams of runc create rather than that of runc start. This means that if you run runc create in one terminal, and then run runc start in a second terminal, the input and output of your container will be hooked up to the first terminal rather than the second!
I’m not entirely clear on the history of why runc behaves this way, but I think the how is interesting on its own. And that how is through multiple processes synchronizing via a FIFO.
LinuxFest Northwest (LFNW) is a local community conference about Linux put on every year by the Bellingham Linux Users Group and Bellingham Technical College. I spoke at LFNW last year, and had a proposal accepted again to speak this year. Unfortunately, COVID-19 threw a wrench in it, and the conference had to be canceled due to health concerns. The conference moved to an online conference made up of pre-recorded sessions (webinar-style), with an online discussion board. I recorded one of my sessions. This post is here to document what I did, as a first-time online presenter who primarily uses Linux.
Note: This post was originally published on the AWS Containers Blog.
On March 10, 2020, we introduced Bottlerocket, a new special-purpose operating system designed for hosting Linux containers. In this post, I want to take you through some of the goals we started with, engineering choices we made along the way, and our vision for how the OS will continue to evolve in the future.
In the welcome post of this blog, one of the things I said I wanted to write was a description of how this blog was built. I didn’t want to do that at the very beginning, as it would be weird for a brand-new blog to only have such meta-content.
But the blog has been around for a year now, and I was prompted by something I saw on the Internet: @hillelogram Have you considered writing your own static site generator?
With the outbreak of COVID-19, many large events like conferences are being canceled or rescheduled. SCALE is still on, and I’ve still traveled down to Pasadena for it since I don’t get to visit my family in LA frequently enough. However, different people have different risk assessments and/or tolerance, so the schedule has changed a fair bit.
As I published previously, I’m sharing my intended schedule. Here’s the revised version. If you feel like you want to join me, let me know!
Note: A revised schedule is available.
I’ll be speaking at the Southern California Linux Expo, otherwise known as SCALE (or SCaLE). I’d love if you came to see me! This is my first time attending the conference, but I grew up in Los Angeles and it’ll be nice to go to a conference there.
SCALE is a community-oriented conference about Linux and other free and open source software. It’s similar to LinuxFest Northwest up in Bellingham, WA, but I think SCALE is larger. For me, the subjects I tend to be most interested in are containers, security, Linux, and other operating systems. My schedule is going to be focused around those topics, but the nice thing about a community conference like this is the variety of talks.
I want to try something new for this conference: publishing my intended schedule. If you feel like you want to join me, let me know!
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.
