 Hello! So glad you got my name correctly. So here is, let's start. So a few words about myself so that you can put this talk into some perspective. So I've been working as a Linux embodied engineer for the last seven years. Most of the time doing drones, just like this one, and other IoT devices. To do that I've been using tools such as Buildroot, Yocto, and Alchemy, which is an Android-based build system. Most of the time using Yocto, which is the most popular one, I think. Another thing about me is that I place high value on the tools I use every day. So for a few years I've been switching distributions, switching desktop environments, switching everything. I kept using one software, which is GNU MX for the last decade. But yeah, never found in Buildroot, in Yocto, in Android a reliable tool that I want to carry on using. So yeah, this is why I'm here. So in the meantime I discovered GNU Geeks. A few years ago I've been quite involved with GNU Geeks. I don't know how many of you have ever heard about GNU Geeks. Ah, great. Maybe you saw Clido talk yesterday. So GNU Geeks is many things. It started as a very innovative package manager based on Nix. But now it's much more than that. It's a tool to instantiate an operating system, which is called GNU Geeks system. It's a container provisioning tool. It's a CI tool. It's a lot of things. Yeah, back to Yocto. What do we expect from Yocto and such tools? We expect, obviously, a tool that you can use to generate some disk image so that you can put them on an embedded device and boot from this disk image. You also expect that this tool has a wide support of packages and recipes and board supports so that you don't have to write everything from scratch. And you also expect a tool that will allow you to deal with your 10 different hardware in 50 hardware revisions in 10 different products. Yeah, in a few words, help you cope with industrial mess, which is a real thing. And yeah, so Yocto does everything, the other tools also. But I've been wondering, could GNU Geeks do the same thing? And if you want to stop listening, the answer is yes. But I'll expose you why. So let's take a real-world example. Let's say I have this board, which is a PyNex 64, and I want to make it fly. So there is some work. One solution could be to install RduPilot, which is a real nice software. It's an autopilot. You can use it to build some drones, some helicopters, some planes, some submarines, some crazy stuff. Yeah, let's say I want to install RduPilot on this board. So we'll see how it's done with Yocto, and then we'll see how it could be done with Geeks. So how would we do that with Yocto? Let's say I'm using Ubuntu, so first I need to install some packages. Then I need to clone Yocto sources. So I use Pocky, which is a Yocto distribution. Then I need to find some support for this board, which is not included in this repository. So I have to find an extra layer, which I find there from some Mr. Alistair 23 I don't know about. I'll clone the layer. Then I will source the environment. Then I need to tell Yocto, hey, there is a new layer. You need to take it into account. So I write this command. And then I need to add RduPilot, the package RduPilot to my image. It doesn't exist in Yocto, so if you type this command, it won't work. It won't work at this step. But let's say it does. And so yeah, you add RduPilot, and then you can produce your disk image. So you type this command, you wait, and wait. No, no, no, before waiting you'll get this warning. It says, ah, your hash distribution, Ubuntu has not been validated. You may experience unexpected failures. Ah, you should use a tested distribution. So I did not know Ubuntu was such an exotic distribution. I mean, if I've been using crazy stuff like Gintu or GeekSystem, I would have understood. But yeah, Ubuntu, come on. So yeah, I see this. I don't want to go any further because it means that, yeah, it may fail. It may fail because of my distribution. I won't know why. I'll have to bisect it. So the solution here would be to use a virtual machine or a Docker file. But I really don't want to do that. So let's keep going. So now you wait. Then you go to sleep. Then you come back. Then you don't have any space on your hard drive anymore. But it works. You get a disk image. And yeah, that's the job. Like it's not that hard. And you can boot from it. And yeah, so a way of doing things. Another way would be to use GNU Geeks. So GNU Geeks is based on Guile language, GNU Guile, which is skin language. So obviously everything is written in Guile. So you have to write Guile. And so you write something like that, which is an operating system configuration, which tells to your geeks what will be the disk image you want. And so you'll have to describe a few things. So you'll have to tell the host name of your system. You have to tell the bootloader you use, which is a specific bootloader for this ball. Some fields are implicit. Like for instance, it doesn't say I want to use Linux, but it's an implicit field. I could use another thing in the future like herd or stuff. I have to specify some modules. The file system I want to use. The packages, which are the base geeks packages plus RDPilot, which is packaging geeks, which I did packaging geeks for this talk. And some services. So I'll take the base services and add a console service. And GNU Geeks is a functional distribution, which means that you apply functions to functions, which checks functions as arguments. So to go from this operating system declaration to your disk image, obviously you need to apply a function. And that function will be, hey geeks, please take my operating system and make a disk image from it. And that's pretty much it. I mean, you can start any REPL, type this function with this file as argument, and you'll get a disk image. You can also use a command to do that, which is quite obvious. You say geeks, I want a disk image system from the configuration file I show you. And I want it for this board architecture. Then you wait. You may wait a few minutes if everything goes, but yeah, I'll get there. And then when you have the disk image, you can flash it on an SD card. You plug the SD card on the board, and it works too. So some of this stuff is mainline. Some will come real soon if you try this on the current release, it won't work, but it may work in the future. And now the question is, I know. So yeah, you get something like that. So you have a geeks operating system. You can see that our decopter is running. And in short, you have to write one file, run write command, wait a few minutes, and then you get a system which does exactly what you want. And the question is, does it fly? So yeah, I can throw it out of the window, but it may not be an audio-pilot supported flight mode. So yeah, might find some motors and stuff first, but the hardest part is done for us. So now you know how it's done with geeks and Yocto. Let's talk about the two tools. So they have a different organization. Yocto has many layers maintained by different entities. So for instance, you can see that there are some open embedded layers, which are some kind of official layers with good support. And there are some layers which are quite unofficial, like the one I used for the board. And the quality can vary a lot. And geeks has a different approach. We have only one geeks repository with every packages, every board supported. While you can add some extra repositories with extra recipes, it's not the recommended way of doing things. I mean, adding some patches is just one patch to one geeks repository. Everyone can do that. It's very simple. So we have different organizations. Yeah, one thing I want to talk about is build reproducibility, also called deterministic compilation. So yeah, both GNUX and Yocto, I'm for reproducible builds if you read their documentation. But if you read the Yocto wiki, it says, depending on circumstances, it might help to build on the same distro with the same packages installed in the same pass and using the same build hardware. So it can be quite tricky. And what it means is that my colleague Alice can build my disk image on her computer with her distribution, and I can take the exact same sources, and it will fail on mine. And I can know why, but with GNUX, things are a bit different. Geeks is building in isolated environments, and you can expect that you'll get the same results, even if you are running completely different host distributions on different hardware and using different build pass. The only thing that matters is that you run the same version of GNUX. If you run the same version of GNUX, you have the guarantee that you have a stronger guarantee at least. You don't need to use a Docker image or a virtual machine. I think it's a good point. Another thing is that to build packages in Geeks, as I told you, it's functional, so you have to write a function that knows how to build the package. So it's a function that says, okay, run, make, and configure, and make, and make install, and you have to give this function some inputs, which are the package dependencies, and you get one output, most of the time a binary. Geeks has an official CI build form, which does all this stuff ahead of you, and when you start building your disk image, it will ask the server, hey, have you ever done this computation with this Geek version and those inputs? And if it says yes, then you just download the output file, and it will be much faster. If this package is Linux with all modules enabled, you'll be really glad that it did. You can also, with GNU Geeks, use offloading, so you can set up several machines on several architecture, and you can offload quite transparently the build to those machines, which is very nice too. Yocto has kind of the same mechanism about what we call substitutes in Geeks. It's called shared state. It's kind of what I described, but it means that if your build machine is running a slightly different distribution, or if it is ahead of you, there were some update updates which modified the versions. Chances of hitting substitutes and getting substitutes from the build machine are reduced, and are very reduced, and that's something that, yeah, we don't have in Geeks. And one other cool thing is that, remember the configuration file I wrote? I can do many things with it. I can build a disk image for my host architecture. I can build a disk image for a foreign board architecture, which is what I did earlier. I can also reconfigure my system by already running a Geeks system using the same configuration. I can also spawn a disk image. I can make a Docker container out of it. Or I can deploy it to remote machines by SSH. And all of this with almost the same configuration that I see, you can do all this stuff. Another cool thing is that Yocto is written in like Bash and BitBake language, and Python, makes lots of languages. And Geeks is written in only one language, and it means that you can use it to build upon your disk image. And for instance, let's say I build a copter earlier, and I want to change my mind and build a plane instead. So I can write a function that takes a vehicle in argument and returns an operating system, which inherits from the one I showed you earlier, and whose packages will be depending on this function, who again takes the vehicle. And if the vehicle is a copter, it will use the arducopter package, which is a variant of ardupilot. And if it's a plane, you can use the arduplane package. And then all you have to write is make vehicle copter or make vehicle plane, and you get either a plane or a copter. And having this flexibility is really nice, I think as a system integrator. You can build a lot of tools upon your Geeks system. And I'll give you other examples. Let's say I want to know all the licenses I have, all the licenses of my packages which are involved in my disk image. So I can start a Geeks API or run a script, which says, okay, for all the packages in my operating system, get the license and get the license name and print it. And then you get all the licenses involved in your disk image, just calling like three functions. And if I want to know all the packages which are licensed with GPLv3, it's quite easy too. I call the same function to get the packages, then I get the licenses, and then I can filter them depending on the license. And then again, I have the list of packages which are licensed with GPLv3. But Geeks can be seen as a scheme library. So I can do pretty much what I want. Yeah. And now let's say I don't have a strong knowledge in GNU line eggs and stuff. It happens sometimes. I mean, you have a team in industry. You have a team of people who are, their job is to do system integration. And then you have engineers which are signal engineer, which spends all the time in MATLAB. And sometimes they want to tweak a package, like add a configure flag, or change some things on the disk image. And if it's two of them, it's okay. But if it's 100 of them, you want them to be quite independent and do the stuff by themselves so that they don't have to go and bother you. And you don't have to explain to them what is Ubuntu and Git and BitBake and Pocky and repo. Yeah. It can be very fast for them. So with Git, the nice thing is that everything starts from the configuration file. So if, for instance, they want to take your image and add an SSH server, they can inherit, as I did earlier, from your system. They can add one services, which is OpenSSH, and they can tweak some parameters, which are, yeah, allow root login, add one authorize key, which is my key, and run on a different port. And it means that they don't have to add an extra layer, make it inherit from SSHD, then add an SSHD configuration file, modify it. They just have to read the documentation, find the suitable service, use the correct configuration, and they can refresh an image. This is true for OpenSSH, but this is true for most services. You can write your own services, obviously. I think it can be quite handy. Now some limits. I mean, yeah, it's the last slide. Well, Yocto and Beelroot and Android have been there for a few years, well, I mean, a lot of years. They work pretty well. They have a wide, wide board, a support of boards and packages, and yeah, those are nice tools. Geeks comes mostly from, I mean, at start, people use it as a desktop distribution, so it's recent that we started hacking on embedded devices, and this means that while you will have many packages that build natively, I mean, you can build Git on your computer, you can build every other packages, if you try to cross-compile them, well, it may fail because no one has tried before you. The main use case of Yocto and Beelroot is to cross-compile packages, so obviously, yeah, more packages are cross-compiling. And another limit is that the image is the image I produced earlier, the disk image, is not that minimal. With Yocto, it was 300 megabytes, and with NuGeeks, it's 1.5 gigabytes. There are no good reasons for it to be 1.5 gigabytes. It could really be like 300, but we have to spend some time, and as I said, it's not been a lot of time working on this stuff, so we have some progress to do. Also, we don't have support for the minimalistic Lipsy, like Solipsy, everything. We just use the plain G-Lipsy mostly. And we have support for like 10, 15 boards, which is nothing compared to Yocto and friends. But anyway, I think that NuGeeks is already, or almost already an alternative to Yocto. I mean, you can do what I want. You can, yeah, in the future, you can download Geeks, get your board, write your configuration file, and flash it. And it may be really, really fast. I mean, if the CI server has been doing this stuff ahead of you, building the disk image is like 5, 10 minutes, and it won't take 15 gigabytes, it can be very fast, and it can be really easy too. You don't have to inspect layers. You just have to write one configuration file. And the Scheme API can really be nice. I mean, both for system engineers and both for developers. And most important point, NuGeeks is like really fun, and you should come help us. So thank you for your attention. Yeah, I guess we have time for some questions. So you mentioned binary reproducibility. What guarantees do you give? Is it just, you know, it will be roughly the same, or is it really binary? So I can build the image, I can build it tomorrow, and it will have the same chart checks. Yeah, I tried to use the right vocabulary, which is quite complicated, but what I mean is that we offer the strong guarantees, like building an Azure IoT environment in containers with well-known inputs. So you have good chances that you'll get the same result from one disk image to another disk image on different distributions and stuff. But if one package is including a timestamp in your binary, then you get a different result. And it's true with the Octo, it's true with NuGeeks. It's just that you have stronger guarantees to get reproducibility with NuGeeks. But you're already handling things like the file system, and the file system itself, and I don't know, these partition labels, and stuff like that. Yeah, I guess. It generates packages and also SDKs. I mean, the point of the... So the question is with Octo, you can build some SDK. Do we have the same feature with Geeks? With Octo, it is often very useful to have this SDK because you can chip it to teams so that they don't have to download everything and they have a nice environment to hack. That's something I didn't show with Geeks. But you have also some really powerful tools to hack in a given environment to build your packages, your native packages. And I mean, it's not some really, really dedicated tools like the SDK. It's more how Geeks does stuff but I didn't have any commands like GeeksEnvironment, Geeks that can do pretty much the same thing without being a specific thing like the SDK. OK, so it's time's up. Thank you, everyone.