Barco: Linux containers from scratch in C

Bart: In this episode of KubeFM, we'll be learning how to build containers from scratch in C with something called Barco. Barco in Spanish means boat, but it turns out that this word actually comes from another language, which you'll be hearing from our presenter, Luca. Luca created Barco in order to make it easier to build containers from scratch in C. We're going to be talking about namespaces, talking about control groups. He's got tons of experience and can explain how he built this, the things that went into it behind the scenes. On top of that, we would like to thank our sponsor for this episode, Learnk8s. Learnk8s is a training organization that allows you to learn all the latest and greatest things happening in the Kubernetes ecosystem right from the comfort of your home. There are online courses as well as courses that are in-person. They are instructor-led, a balance between theoretical and practical, as we know it's important to get your hands dirty, to get real experience with these technologies in order to level up. Like I said, courses are online or in person. You'll have access to all the videos for the rest of your life, so you can squeeze all that knowledge or revisit topics if you choose to do so in the future. Check out learnk8s.io for more information. And now, let's get to the episode. So here we are in season two. Very nice to have our first guest with us. His name is Luca. Luca, welcome to the QFM podcast.

Luca: Thanks, Bart, for having me.

Bart: Good, pleasure. Now, that being said, if you had a brand new Kubernetes cluster, what would be the first three tools that you would install?

Luca: Oh, that's a good question. I think it really depends on what that Kubernetes cluster is for. I used to work as a consultant in the past, and I work on different projects for different customers. And some of them needed MTLS. Well, in that case, we would deploy Istio, for example. Others may need some... special CI/CD set up so we will deploy Argo CD. I think I would say it really depends on the use case. I am myself not particularly into tools. I try to keep them at the minimum. So even tools like K9S, right? It's something I don't really use because of those kubectl. And I try to go as much as possible with stock options. Um, so yeah, my definitive answers would be, it depends.

Bart: That's a fair answer. And like you said, I've been in consulting background, not rushing it necessarily to one tool or the other. That being said, you know, you said you did work as a consultant, but tell us more about what you do now, who you work for, the kind of stuff you're working on.

Luca: Well, currently I work as a senior software engineer at GitHub, and actions in particular. I work a lot with Go, Kubernetes, also more on the platform engineering side of things. So I like to keep myself somewhere in between software development and DevOps, platform engineering, cloud computing. Yeah, so that is in short what I am and what I do.

Bart: This is off script, so you can answer however you want. Given that you talked about platform engineering, is DevOps dead? Is it alongside platform engineering? Are we talking about two different things? What's your take on that?

Luca: I think there are many names for what is. In a way, all the same thing. You could call it DevOps, you could call it platform engineering. The core idea behind it is to provide tools to developers to be able to do their work nicely and to the business to be able to run their application. There are some nuances. Maybe platform engineering is more about building a platform. for teams to use, for the business to use, but in the end. I see all these terms a bit as, you know, maybe marketing terms, as if we're trying to sell something as new. But in the end, I would say it's pretty much all the same stuff.

Bart: You know, in terms of how things have progressed over time, how did you get into cloud native? And what were you doing before you were doing cloud native?

Luca: Right. So I've been in software development for... About 10 years. Yeah, I think it's 2023. Sorry, it's really 10 years, exactly. I started as a full-stack developer. So I'm located in the Netherlands, but I was born and grew up in Italy. And I worked there for three years before moving here. And what I did there, as I said, was a full-stack development. So creating... websites and platforms, CMS systems, for example, for external customers. I used to work at an agency. Back then, PHP and Laravel, jQuery were all the rage. So that's pretty much how I started. And then I moved here and well, I sort of continued that full stack trend, but I would say I was more focused on back end development and more with no go like providers. And that's pretty much what I did up until maybe 2018 or so. I became more and more interested in infrastructure and cloud native. And that's when I decided to make. the switch and focus more on Cloud Native, Google Cloud, back then, Kubernetes. What I found more interesting than, let's say, full-stack development or front-end with React is that I feel when you're doing infrastructure kind of work or more heavy backend kind of work, then you're really working on what powers the internet, what powers the business and any kind of system really. So that's, it's as if you're working closely with, you know, with machines and with actually providing the backbone of modern technology and the internet. Whereas, say, if you're working as a front-end engineer, nothing against front-end engineers, that's my experience, but I couldn't easily see myself, let's say, building some UI for a... music player, an online music player, for example. I used Spotify in the past. I'm using Apple Music, but it's something that... It isn't something that I find very important in my life. It's a bit ephemeral in a way. So I like to work on something that is the foundation of modern computing rather than specific use cases, like a non-like music player could be or a website to order food online. I use those. They're very useful. I see less value in that than say building infrastructure, right? Working with networking and that kind of stuff.

Bart: You know, the cognitive ecosystem, Kubernetes, this space moves very, very quickly. How do you stay up to date? Blogs, videos, podcasts, what are your resources of choice?

Luca: A few years ago, I found out about this app or a website called Feedly. And... No, they're not sponsoring me, but I find Feedly very useful in that. Well, it's an app that lets you aggregate different RSS providers. So you can get like a personalized list of news every day from whatever blogs and websites you decide to follow. So I have a pretty big setup that I use there with many websites about, I don't know, Cloud Native or Golang, open source and whatnot. And I try to go through those news every day just to see what's new. Though, I must say, maybe in general, I wouldn't really call myself an early adopter. So in my life, I have limited time, and I can't really chase all the new things that are happening. So I like to keep an eye out on the tech world and how it develops, but then I try, I think most of the times, I let others try for me, and if it's something that sticks, it will become famous and big enough that it will be impossible to ignore. For example, I remember I mentioned Istio earlier. Well, a few years ago, Istio was this new thing. It wasn't really clear what it was for and where the benefits would be. So I really avoided it at the beginning. Many of us are familiar with what Istio is for. So I'm going to show you a few examples. I let others try it and experiment with it. And now I know what it is for, what the experiences of people are. And I think now it's a good time for me to dive deeper into that. That's just an example. But yeah, in general, I like to filter out stuff that is really important, technologies that are important, that can be useful. from every new thing that appears every day. Even though we're talking of cloud native and not JavaScript frameworks, so that's even a bigger problem there. Yeah, but I would say that that's been my philosophy. Okay.

Bart: And since you mentioned time being a later adopter and your experience, if you had to go back and give yourself advice at an early point in your career about learning Kubernetes, things that would have been helpful to know when you got started, what would that advice look like?

Luca: So I have to say I'm fairly happy about my progression so far. And there aren't any major things that... that would change about it. But pretty much on the same note as what we just said, I think at the beginning of my career, I sometimes would spend time, maybe too much time focusing on certain tools or certain new, hyped technologies. And well, later on, I learned to filter that out. But maybe in the first years, I spent a bit more time that. than now I would have wanted to. So that would be my main advice for myself. Start earlier with filtering out the hype and only focus on what really matters.

Bart: Very good point. It's a process that everyone has to go through in one way or another. And keeping that in mind that there will be filtering that will happen because of the hype, because of, like you said, the value that can be seen in marketing in certain terms or another, pumping up a certain technology, that it takes time. And it's something that everyone goes through in one way or another. Now, for today's episode, you wrote an article called Barco Linux Containers from Scratch in C. For those of the folks in our audience that don't know what the word barco means in Spanish, it means boat. So this is quite fitting with the nautical theme that we're frequently speaking about. But to get started, can you tell our audience what Linux containers are and how they work?

Luca: Well, what I learned working on that project and writing the blog post is that... Anyway, there's no such thing as Linux containers. The Linux containers are really the product of a number of Linux features, that you can put together and configure properly to get what we know as containers. Right. So. Some of the most important of those Linux kernel features that are needed to build containers are, for example, cgroups and namespaces. So cgroups are a way to tell Linux how much of a resource to allocate to a process. So how much CPU, how much memory, for example. And that's the same kind of configuration that you see, for example, when creating some Kubernetes deployment, for example, where you specify requests and limits, as in CPU limits. And namespaces instead are another feature to tell Linux to isolate certain aspects of your process from the rest. So there are a number of types of namespaces. There's, for example, mount namespaces for the file system. There's user namespaces to isolate different users. And these two are really the main things behind containers. Then other. Other features are like, for example, seccomp, that is configuration that you can give Linux to set security rules for your container capabilities, which is similar to seccomp. capabilities let you specify what a user and what the container can and cannot do inside the container that also affects the the host operating system Yeah, so building that project, Barco, that's where I learned that there's no, let's say, create container system call in Linux. Containers are really what you get by putting together all these different features.

Bart: With some of those features that you described, isn't a lot of that what Docker is used for?

Luca: Yeah, definitely. So Docker relies on those Linux features to provide Docker containers. So a few years ago, I would look at Docker and ask myself, How is Docker doing all of this? They must be geniuses. And well, I mean, they're definitely good engineers, but all they're doing is really building something on top of what is already provided by the Linux kernel. And well, those features, the way we talked about earlier, they're really the product of maybe 20 years of development in the kernel and contributions from other companies. So before Docker became big, I don't know, maybe 10 years ago or so now, there were different opinions in the industry. From IBM, for example, or Google, they all had different opinions on how to... to have containers, what we now call containers, right? So a way to run applications in your Linux system, but then separate from everything else that's on the machine. It also makes it possible to distribute these applications. So definitely, yes, it's what Docker does, but Docker builds on top of existing Linux features.

Bart: So like you said, in that case, having something like Docker, but then there's also the option of writing your own. And that's essentially what you did with Barco, right?

Luca: Yeah, that's correct. Well, the project I worked on, it's similar to Docker, I would say. in its core idea, so leveraging those Linux features to create the container. But it's infinitely more simple and really the only thing that it does is set up a hard-coded container. the main idea behind it was really to learn what Docker does, what containers are. So I've been working in the cloud native space for a few years now, and I read books about Docker and about Kubernetes. I read blog posts about containers. I always feel that just by reading, especially for certain topics, it's really hard to understand what you are dealing with. So if you read a book about Kubernetes, you will learn what containers are and maybe C groups will be mentioned. But then I didn't really find any resource, I didn't find any book that would tell me what to do. how do you create the container? Everyone tells you what the container is, but if you want to dig deeper, then it's something you really need to do yourself and build a project like Barco to really understand what's going on. Yeah, that's... A recurring theme for me, I would say, for example, another project that worked on is a very small and simple DNS server built in Rust. That was also, for me, more of an educational project rather than a real attempt at creating a DNS server. But even if you pick up a networking book and you read what DNS is. it's still hard, at least for me, to wrap my head around what is DNS besides, or what is DNS at a deeper level? How does it work? What does it mean to read bytes from a buffer and to parse that byte into a DNS message that you can make sense of? So... To summarize, Barco and other late projects of mine, they came from my need to understand in code what it means to build containers or... have the DNS server, for example.

Bart: It's great to see, though, that just like with a lot of startups, is that you yourself encountered a problem of how does someone actually create a container? Where do these things come from? And then providing that answer yourself through this project. Can you walk us through just exactly how Barco works, particularly if we're thinking about things like capabilities and seccomp?

Luca: Barco is a CLI application and when you start a process you need to specify some parameters. For example, the command you want to run, where to mount the file system, namespace and other such options. The first thing it does is really... There's a setup part, I would say, where the very basic settings for the container are created. So, for example... setting up cgroups, that's one, or creating the namespace that will be used eventually. And while you mentioned seccomp and capabilities, those are steps after that initial setup. And they're actually called from inside the container for the most part. So I just mentioned cgroups and namespaces. Those are options that are mostly set by the parent process, so barco. But then that parent process starts the new process, and that's the actual container. And when starting, that container needs to make certain calls for setting up seccomp, setting up capabilities, and also later to start the actual... application that the container should run. So specifically about capabilities and seccomp, so we said it's a configuration that's set before the container starts doing actual stuff and they are set with Linux system calls. So there are syscalls that you can make from C to set those options. There's, for example, the seccomp rule add system call from Linux. It lets you add a second rule. For example, you can limit the user, or you can prevent the user from running certain combinations of the chmod command, for example. Or with capabilities, you can ask Linux to prevent the user from checking the syslog or running other types of directory-based commands, for example. And that's all configuration needed for security. And that configuration really, well, I got it mostly from blog posts. and also looking at the Docker config, you might be interested in what are the basic security settings that I've used. I spent some time reading blog posts and all those blog posts tend to point to a Docker documentation. That's because, well, Docker is a bit of the golden standard in containers. I mean, there are other options like, for example, Podman, but I think for the most part, Docker is still the tool that is most widely used. There is a page in their docs where they tell you exactly the basic security configuration that docker uses. So I rely on those docs to set up the basic security options for Barco. But there are settings, for example, in Docker that can be changed. So you can set capabilities for a container. That's possible, for example, when creating a deployment for Kubernetes. I think one of those is PTrace. That's a feature that is disabled by default for security reasons, but it can be enabled later. In the case of Barcode, everything is hardcoded, so there's no way to customize that. And that's another way in which Barcode is much different than, say, a production-ready tool like Podman or Docker. Those let you configure your environment as you like, Barcode as everything hardcoded, and once again, just for educational purposes. Maybe something good to add would be that I just said how seccomp and capabilities are set via system calls. That's not the case for all Linux kernel features related to containers. For example, cgroups, those rely on a virtual file system. So setting up cgroups for a container really involves writing a file to a special location on disk. I thought it's different to see how different features in Linux work differently. Initially, I would expect everything to be done. Yeah, syscalls maybe, or everything is file-based in Unix-like systems. So maybe everything could have been files. But I think... Barco not only helped me understand more about containers, but also about Linux internals, which is something else that I find very interesting and maybe an extra reason for me to work on this project. So not just to learn more about containers, but also a bit to learn how Linux does things, especially at the lower kernel level.

Bart: Now at this point, the container is running and it's secure. What happens after that? What's next?

Luca: Once everything is set up, the container is running on its own. So if you tell Barco to run bash, for example, inside the container, well then in your terminal, you get this shell to bash inside your container. Through Barcode, but inside the container. A bit like you would with Docker. And there you're free to do, I wouldn't say pretty much everything because that wouldn't be correct, really. You have access to everything that bash has access to. So you can run ls, you can run cd, you can run an echo. But there's no networking, for example. I never added that part to Barco. It was enough educational material for me already as it is. The project contains some docs, some ideas on how that could be implemented. But really, well, there aren't many things you can do inside a Barco container, let's say. So once it's running, what happens is that the parent container, sorry, the parent process, so Barco, which spawned the container, is waiting for the container to exit. That's something else that's done via system calls. Really, we have Barco waiting for the container to exit through the syscall. The parent process is alerted when the container exits. And then, after the exit, Barco takes care of cleaning up the resources that were used. So for example, clearing the cgroups or making sure that there is no user configuration left behind that was initially set up for the container. And well, besides that, it's not container specific, but Barco also brings up some memory that it's used for other stuff. Like for example, some library that I'm using to handle CLI commands. So it does that, and once all the resources have been freed, then also the Barco process exits. Ideally, without leaving any allocated memory behind. I think that the project itself is quite simple, and allocations are easy to track. But that's definitely a concern when using a language like C, where you have to manage memory yourself.

Bart: You used the word easy, and... It doesn't sound like this would be the easiest kind of project to do in my spare time. What, you know, how much time did this take you to get it up and running?

Luca: Oh, you definitely could. I think it took me about, I don't know, maybe a month. And I would work on it in the evenings or the weekends. So, yeah, I would say about a month. And it's definitely challenging to get to do something new, like interacting with Linux at the low level. But... I relied heavily on documentation and blog posts. I would say the biggest part, the most difficult part was really finding the right resources and the right guides and examples that I could reuse rather than really figuring out the nitty-gritty details. There's always a box that you need to investigate and find out why, for example, cgroups are written on this machine, but not my other machine that has a slightly different version of the Linux kernel. So I would say it's a doable project. Well, I might be biased now because I've done it, but I think it's accessible with the right resources overall.

Bart: Speaking of those resources. What were the most challenging resources to access? I know you mentioned blogs. I know you mentioned books. What were the biggest challenges in terms of finding the right resources? And if there are any that stand out as being the most helpful, a book that you might recommend to our listeners, which one would it be?

Luca: One big challenge is finding a blog post that goes deep enough, right? So as I've said earlier, if you read a book about Kubernetes, for example, they will tell you what the containers are, but it's very hard to find information about Docker internals, for example. And even if you do, if you look into the Docker source code, it's very hard to tell what is the... minimum amount of code that I need to create a container. A resource that I found quite useful is the Linux manual. I find it's very hard to navigate and you need also maybe more context about the kernel works than I had to really understand what they're saying. So certain system calls like seccomp syscalls to add a rule, you can find them there documented. They will also tell you which C headers you need to include to be able to use those functions. But overall, I feel... it would be useful to know a bit more about Linux and the kernel to really make good use of the Linux documentation in this case. There aren't really any books that I can recommend on the topic because, yeah, as I said, I find it... very hard. Like I couldn't really find any book that goes deep into these things. Right. So you can, for example, there's a, a big book. It's like 1500 pages about the Linux programming interface. Let's see. And they tell you a bit, you know, all the system calls that you can make in Linux. But when you have 1500 pages and this huge collection of functions that you could call. It's really hard to understand what is the correct combination to use to create containers. So it's not a book like that. It's not container specific. It's Linux specific. And then if you know a bit more about containers, then maybe you can make choices based on that information. But I haven't found... any, let's say, containers from scratch book. Maybe it's something we could write. I guess some people might be interested in that.

Bart: Sounds like there's an opportunity there. That's good. Now, you did talk a little bit about C previously, and you also mentioned Rust. But with all the different programming languages, whether it's Rust, Go, or Zig, why did you end up deciding on C? What were the advantages that you saw in that that made you make that choice?

Luca: Yeah. So the main reason why I went with C is highly technical. And it is that I... I learned a bit of C in school, and that was over 10 years ago. I never really used it for anything anymore. So I just wanted to play more with it. So that's the key reason. Besides that, C is very low level. It has simple access to all Linux kernel stuff, be it buildable file systems or system calls. So I guess... You could do it with Rust as well. You can definitely use Go. Docker is written in Go. Other runtime containers, containers, runtimes are written in Go. But I feel, you know, C is so low level that it's very hard to not learn anything from what you're doing, right? So every instruction does exactly that. So if you're making a syscall to set capabilities, for example, it's quite clear what is happening. And I think that's an advantage of C, especially if your goal is to learn more about containers in this case. I think it's good to be able to work at such low level because there's no magic happening. Go library that does all container security stuff behind some function call. So if you use that, it's quick, but there's less to learn from, I would say, than doing things the hardcore way.

Bart: If you could go back and change anything, add anything, modify anything with Barco, what would it be?

Luca: I think... The main thing that's missing there is the ability to configure options like how much CPU to use, for example, how much memory. Everything is hardcoded. And the key reason there is it's just some tool to learn how containers work. But I guess. Being able to configure certain options would make it extremely more useful, even just for learning purposes, than having everything encoded. So that's something that doesn't necessarily... We will need to go back in time to change that and some of it can be added now. But if I had to add a feature, I think that would probably be it next to the networking, right? So we said earlier there's no networking in Barco containers. That could be added. And I guess it'd be fun also to be able to, I don't know. ping some host from inside a barco container, or in general having networking capabilities. I guess there's a lot more that would be possible to explore at that point.

Bart: You published this article on Hacker News. In terms of the feedback that you got, were you surprised by any of it? Was it what you expected more or less? What was the reaction?

Luca: Oh yeah, absolutely surprised. So it's not the first time I share something on HackerNews or Reddit. And I wasn't really expecting much, even because if I knew a bold interaction the project would get, then maybe I would have polished the docs a bit more. That's definitely something I was not expecting. I've really seen lots of positive feedback. And I think that really shows the need for other engineers, their desire to learn more about technology in that, right? So how does a container work? Well, it turns out that question is very interesting for many people, especially, you know, not... to have an explanation that's not just a blog post, but something that you can actually run on your machine. And to have code that you can look at, you can change, you can compile. So there's definitely a need in the tech community, I think, to have more in-depth resources, right? So not just... how do I run a container, but what is a container? I think, especially in the last few years, maybe technology has become more and more complicated, right? So in the 70s, all you needed to be a software engineer was to know C, maybe assembly, if you were unlucky enough. But now... we rely upon layers and layers, complex layers of technology building on top of each other. So in this case, we mentioned Docker. So Docker relies on kernel features and Linux kernel relies on CPU features to create containers. Well, I received lots of positive feedback, unexpected, I must say. And I would say it also became quite clear that there is a need in the community to not just have more tools, but really understand more about how these tools work. So, by school, for example, you learn about networking or computer architecture. The problem there is that it's all really, well, first of all, outdated to a large extent, but also everything is paper-based. So you read what a DNS server is, but nobody really tells you how you listen for DNS requests, how you parse and do something with those requests. So it's everything quite high level, I would say, what you learn from books in school. In a way, unfortunately so, because it would be great, like a book that you could read to learn more about how does DNS work in detail. I'm not saying those do not exist. They certainly do. So at least that was my experience. And those kind of resources, it's something that I've always been longing for. I still haven't found many good ones, maybe only for specific topics. So that was definitely interesting to see in the community.

Bart: And also just your experience too. I think there's a lot to be said. You know, what we try to feature a lot in the podcast are folks such as yourself that have written something, that have created something, that have shared it. A lot of people I think might be kicking around ideas, but they don't take that next step. You know, sometimes it can be imposter syndrome or feel like, oh, well, it's already done. Or what do I have to contribute? What would you say to people out there that might have an idea, but like I said, they stop from taking the next step. whether it's giving a talk or writing a post, creating a tool, things of that nature. What would your advice be to people that are out there? What's your experience been in that regard?

Luca: My basic answer, which is very cliche, is go for it. It never hurts to write a blog post or to work with some project, even if you think someone else has done it. Though... Something I must say as well, and I do it myself, I also try to ensure what I'm giving the world has some value. So I don't want to sort of discourage people from doing things, from writing blog posts or speaking at conferences. As I said, go for it. But my recommendation... which I think is good both for the person doing it and also for the community out there, is do it, but make sure there's a certain level of value that you are providing. So as an example, while working on this Barco project, I came across... so many blog posts and links and opinions that it's very hard to find the information you need and of course the internet is very accessible and that's great it's good that we have that at the same time that can create sort of an information overload that makes it hard to find what you really need there I think, or I hope, is also the spirit, for example, behind the blog posts I write. I try to only publish what I think has been really useful for me that I couldn't find anywhere else. If I see a blog post of someone who has more or less my same problem, but not exactly, then in that case, I try to avoid publishing more material to the internet and muddy the waters even more. So... Long story short, go for it. That's my advice. But make sure what you are giving the world has value, right? So don't just... publish something for marketing, for SEO purpose. That's something we've seen a lot lately in the internet. It's becoming very hard to find what you need. And even if you find it, maybe you need information that could be a few lines, but there's a huge wall of text that just rephrases or rephrases the actual information. And that's done often for SEO purpose, for example. So what I hope the internet will be in the future is less, let's say, sales techniques and more useful information.

Bart: I think you'd find a lot of people agreeing with that. You had to name this. How did you decide on the name Barco? And what was more some of the alternatives maybe? Or were there any alternatives?

Luca: No, there weren't any alternatives. So at the beginning of the chat, you said Barco has to do with the naval world, and it's a Spanish world. Unfortunately, I must tell you, that's not correct.

Bart: That's great. That's good, actually.

Luca: So, Barco is a Venetian word. A word of the language that is spoken or used to be spoken in the Venice area, in the Veneto region of Italy. And what it means is like, it's a hut where you store hay, right? Hay for cows and horses. And that definitely hasn't anything to do with Docker and containers and ships. I really chose it just, I guess, out of tribute for the place I was born. And yeah, Venetian is pretty much a dying language. for a number of reasons, but I find it a very, you know, expressive language and to try and to preserve some words, maybe I use that for that sparkle for my project. So it has more to do, I guess, with regional lore than any recent strategy in naming. Yeah. So I would say all choices, like name choices and choosing C, there's no big reasoning behind it, no really data-driven decisions or technical considerations. It's just something that I chose to have fun. I think that that's also important. Every time, for example, you go to LinkedIn, you see all these blog posts about... business and data and percentages and career development. And now it can be interesting and important to an extent, but I think everything is becoming so data-driven and optimized for something that we all forget. There's more to life than the numbers.

Bart: Couldn't agree more. And very nice to hear about the etymology of the word barco. I will be telling all my friends here in Spain that they are very much mistaken if they think it's exclusively a Spanish word. That's very cool. You mentioned a really important thing too, that there are things in life that are more important than blog posts and these just sort of hype machines. Apart from knowing things from the Venetian language, what do you like to do in your free time?

Luca: Oh, yes, great question. I love talking about my free time. I don't have much lately for one reason or another. But in general, I really like cycling, road cycling. It's awesome to do it in the Netherlands. There's bike lanes everywhere. Then usually after a good ride, I like to fire up my Camado grill. So like cook some spirits or some smoked salmon, for example, that that's, uh, great to do, especially in summer. Now, not so much. Um, Yeah. And I have cats. They're looking busy. When I'm not busy with cats, I try to play video games. That's something I like to do a lot. More than I should, maybe. But, yeah.

Bart: That's what they're for? Yeah. Any particular video games you've been playing lately or one that you know all-time favorites?

Luca: Well, I recently got myself a Steam Deck, right? So the latest version came out. And currently, well, I played a few in space of maybe a month. There's Stray. That's like a story-based game where you're a cat. There's also robots. I recommend it. And I played The Last of Us. So my wife and I, we watched the series on HBO, I guess. Yeah, HBO. And currently I'm playing Horizon Zero Dawn.

Bart: And so what's next for you? Can we expect, you know, new things you'll be writing and see any new projects that you have in mind?

Luca: As we're recording this, well, it's still December and Christmas is approaching. So what's next for me really is playing video games and build Legos. So that's what's next for me. After that, there's a book about AI that I'm reading. It's Applied AI for Engineers, I think. So it contains more information about how you as an engineer can use AI to build stuff rather than complex maths and equations that tell you. the nitty gritty details of statistical models. So that's something I'm reading, but I bought that book. to play games and build LEGOs, mostly. And also, I'm looking for a nice Rust project to contribute to, open source project. I haven't found one yet, but I'm looking for something systems level. possibly in the networking space. So that's what I like to do after Christmas. If I find anything, then you will see it on my GitHub profile.

Bart: Solid plan. And for folks out there that have Rust-based networking projects that need contributors, you definitely have someone you can speak to here. For folks that want to get in touch with you, what's the best way to do so?

Luca: So I have a GitHub profile. Obviously, because I work at GitHub, though, there's no way to reach me there, I think. Besides that, there's LinkedIn. So if you connect with me on LinkedIn, there's a, well, you can send me a message and I'll be open to have a nice conversation. Yeah, so that's pretty much all the social networks I use.

Bart: That's fine. It's more than enough. I think we all, 2024 can be the year that we downsize our social media and spend more time building things with Legos, learning about AI, playing video games, cycling, doing other kinds of hobbies and habits. I definitely think that's a healthy thing for us to keep in mind. Well, Luca, thank you very much, first of all, for your time. And secondly, for all the hard work that you put into this project. As others have already benefited from what you put out on Hacker News, I'm sure our listeners will appreciate what you shared with us today in terms of the process behind it. how you're answering questions that you couldn't find answers for, creating resources you feel were missing in the ecosystem as a lesson for others to do the same. Like you said, always focusing on providing value for others. So thank you.

Luca: Yes, I definitely hope my projects can be useful for others to learn more, well, in this case, about containers. Yeah, I wish everyone a good time ahead.

Bart: See you in 2024. Take care.

Luca: Thanks. Bye.