 I'm here to present the OpenRC, an alternative in-it system and service manager. So, one question, who cares about the in-it system? Great, great, that's why you're coming here. And who has gone through the in-it system debate around 2014? Great, great. Thank you. And who likes show scripts? Nice, I think I'm meeting with the correct audience. So, something about me, I'm a long-term Debian user since the age of Woody, and then I also involved in Gen2, and right now I'm applying to be a Debian developer. So, from my point of view of the patience of skills required, the Debian and Gen2 has a kind of this relationship. So, I'm climbing up, so finally to be a Debian developer, which made me very excited. Hopefully, this meeting can give me a boost of that. Okay, so let's come to the topic of today. What is OpenRC? Basically, OpenRC has been grown from the Gen2 community as an answer for the call to design a modern in-it system. It should be compatible with the traditional scripts as much as possible. And basically, OpenRC is written in C and shell scripts. And that makes the system quite simple. And very much portable. So, if you want to install OpenRC on Debian, you can copy this command. It basically installs system v init and OpenRC and removes the system v sysv replacement and with this single command. And after the reboot, you will be powered by OpenRC. So, that's all for the talk. Well, not really. So, I think the audience is not quite convinced why OpenRC is useful, at least for some cases. Well, I think it's a good, to answer this question, it is needed to consider, reconsider the good practice of free software. I, from my point of view, it should be respect the UNIX philosophy. And it should be easy to tinker and easy to understand and straightforward to hack. And it should provide some modern or standard feature set that everybody take for granted. And as a benchmark, I think a software that is successful is usually used when not anticipated by the developers. So, let me show you that OpenRC meets these standards. So, first, OpenRC has a very flexible design because the services are defined by shell scripts and the shell script is the most natural language to invoke commands because we use shells to invoke commands every day. And so, therefore, this gives the OpenRC a very flexible design. First, an example is like this. It can be very decorative. For example, you give a description, you give a file and command, and some extra arguments, and it will become a service. You can start and stop and make it run automatically on reboot. Or it can be very much like a script where you define some functions and you execute commands inside those functions. By the way, this is for the dependency and the more conventional example is in the start function. For example, it is to mount some kernel file systems. You can just write shell script directly. Or we can support the Davian Linux standard-based Inescripts, which is why we ported this system to Davian. Secondly, OpenRC is a very small tool, to be honest. And it is very simple to understand. So I think the model is when you are in doubt of the behavior, just read the code. For example, in the past case, I've shown this decorative example and this decorative example is defined in some shell script. And this shell script can be read directly. For example, on the Davian system, it is in this file and we can see, okay, so if we define the PID file, it will use the PID file here. If we define some other arguments, it will be used, the pass to start, stop, demon. So it is very simple to understand. And it is actually a good, educative piece of software where we can learn for system programming and shell script hacking. And also OpenRC, thanks to its simpleness, it's very easy to hack. And I think this is the central spirit of free software. And because the codebase is very light and you can easily, very easily, to find the solution to satisfy your need. And because the OpenRC respects the backward compatibility, so your hacks will be long lived. For example, initially the Davian LSP scripts has some weak dependencies. And these dependencies make some dependency loop which is not originally supported by Gen2 version OpenRC. So in order to port the OpenRC to Davian, so we implemented a dependency handler to accept the loops in the dependency. And it has been working well for four years for this hack and the patch hasn't been changed at all. And it works for every new versions of OpenRC. And because it's a very simple tool, so it does one thing and does it correctly. And for example, it manages the service dependency and as well as the start and stop of the services. It can be in foreground or in background. So recently we have a trend to supervise the services. So if we put the daemon in foreground, it is easier to be supervised. And so that when the daemon crashes, it can be restarted and to minimize the downtime. And also the OpenRC is flexible. It can be interplayed with C-group or some alternative unit programs like S6 and Runnit. They are also very nice and simple service supervisors. You can also do many things with OpenRC. For example, you're not necessarily using the Udev. You can use some Mdev from the busy box or you're not tied to the CSV unit. You can use some alternative unit programs or write some unit by yourself as long as it starts OpenRC or it calls OpenRC. Or even OpenRC can be used as a normal user and started by some Chrome tab or some manual execution. It doesn't care. So as long as it gets executed, it's executed perfectly. And the other point I want to cover is that the OpenRC's philosophy is that it's evolution. The users has the ultimate words on the development. For example, there are many power users giving opinions to the developers and sometimes they do a very good hack and they become developers by themselves. And the group is very friendly to speak with and to work with. For example, when we were adopting OpenRC to Debian, there has been some name conflicts. For example, the Run script and the RC are in conflict with existing Debian packages. And the upstream acted very quickly to change their executables to OpenRC specific names. And we were very appreciative with that. And finally, what I think is very important for software freedom and for Debian as the universal operating system. The OpenRC is not Linux only. It supports, as I mentioned, as long as it started, it started. So it supports alternative kernels. For example, this GNU K3 BSD, kernel-free BSD. This is a screenshot. If I have my laptop, I can show you a live version of that. And also GNU HURT. This one, the HURT is not that very colorful. So you can, but you can see this line is starting the GNU kernel. And if you want to get more information about OpenRC, you can get this tracker. It's already in Debian and it's easy to be installed. And the popcorn graph is like this. We are constantly gaining users. And hopefully after this talk, I can see a upward trend of this popcorn. So I want to convey some messages to the audience. First, OpenRC offers some modern features. It is a feature for unit system and service manager. And it supports the features we're taking for defaults. For example, the service dependencies, the process supervision, and fast boot of the systems. But these features are not came with a downside of not understandable system. It's still keeping to be very simple. And to understand and to hack. Also, it is driven by a friendly community. And also the users have the final word of where it goes. And it is easy to be installed on Debian. I can give you a like a seven second demonstration of how to install it. If you want that demo, talk to me after my talk. So finally, I like to thank the supporters of OpenRC. This has been a long history before starting, before the long debate of unit system. Roger, who's already been retired, I think has laid down the ground breaking work. And Thomas and Adam has been supervising our work. And Dimitri and Bill has gave various contributions. And the herd patch has not been possible if not were Svent and Giburi. So I like to thank my colleagues. And that's all. Hopefully this has get you some interest in OpenRC and I'm open for questions or debates. So this sounds great. So I should say I'm Ian Jackson. I have somehow ended up being in charge of Sysvi in Debian. I didn't really want to be in charge of it, but nobody else is taking care of it. This is cool. Do you have like a transition plan? I mean, obviously like realistically, it's not likely to become the default anytime soon, but because you have these service files, we need packages to have these service files in. Is there a way to do that like, compatibly to like transition from, let's say, let's start easy. Can we transition to a situation where Sysvi and its support and OpenRC support is somehow done in the same way? These little shell scripts seem quite nice. Maybe we could, is it possible to interpret these shell scripts with Sysvi in it? Sure. I think it's doable in a similar way as the LSB scripts. And the LSB scripts took, I think, one afternoon to hack up. So I expect at most the system, the units, the container layer, would take one week's work. Right. So I do think that's a very nice way to go forward. So I mean, I don't really like Sysvi in it very much. I would like to switch to something with better service supervision. There are reasons why I'm not using the competition, which you have deployed in your slides very well, yes. Here, yes. Yeah, all of these. No, no, at the bottom of the slides, we have all the anti-patterns. Yes, this is why I'm not using the competition that we shall not name. So, but I have all these, like I currently have a lot of Sysvi in it, scripts, obviously, they come in all the packages. Are we gonna be sending, are you going to be sending patches to package maintainers, have you tried that? Is that working well? I haven't because I'm using Davion Stable. So the trend has not came to me yet, but I believe in Buster, I will be meet some packages that I like that doesn't ship the init scripts anymore. Right, so far, you're basically using the init scripts, that's right, you're using Sysvi init scripts. Yes, so far, all the services I use ships, the LSB scripts, which works perfectly. Okay. So, but the upcoming trend is that maintainers are removing those scripts. Have you seen that anywhere? If you have examples, talk to me afterwards. Okay, okay, I've saw some bug reports, but I can't remember it. Okay. Immediately. But I do think somebody else, sorry. But I do think the Compatible Layer for SystemDunit is a superior way to move forward. Right, quite possibly. Does anybody else have any more questions? Short question? Well, thank you. Thank you.