WEBVTT 00:00.000 --> 00:15.760 Yes, already. Hello. Thanks for being here. My name is Ludwig. I'm the founder of Geeks. 00:15.760 --> 00:25.640 I'm the co-maintener of Guy together with Andy. I'm here to talk about the shepherd. 00:25.640 --> 00:30.640 Who in this room has already heard about the shepherd? 00:30.640 --> 00:36.640 Everybody, wow. Who could have thought? Okay. 00:36.640 --> 00:41.640 So I'm going to steal, you know, talk a little bit about what the shepherd is. 00:41.640 --> 00:52.640 Many of you already know, that's great. And I'm going to talk about what it's like inside, which probably is less well known, we'll see. 00:52.640 --> 01:00.640 First of all, did you know that the shepherd started actually a long time ago, 22 years ago, I think? 01:00.640 --> 01:10.640 So that was the actual announcement of the very first pre-pre-release pre-alpha release of the shepherd, which was the name DMD. 01:10.640 --> 01:18.640 And this is the real text of the announcements. So you can see this is coming from someone who really enjoyed the scheme, right? 01:18.640 --> 01:24.640 You can only see the parents straight in the announcement. So this is great. 01:24.640 --> 01:36.640 A lot of things have changed since 2003. So in particular, you know, there was that initial piece of code for DMD. 01:36.640 --> 01:44.640 And then in 2013, we revived the shepherd DMD shepherd. Why do that? You may ask, right? 01:44.640 --> 01:50.640 It was already a little bit silly to, you know, start a new distribution. 01:50.640 --> 01:56.640 Geeks, you know, that geeks things you may have heard about. Why start a new in its system? I get to that in a second. 01:56.640 --> 02:04.640 So that's one of the main events I would say. And the second event is we had a one point or release just in December. 02:04.640 --> 02:10.640 That's quite something, right? 02:10.640 --> 02:18.640 Yeah. So why start that project? I mean, why keep working on an in-it system when we have cool options available? 02:18.640 --> 02:26.640 Well, so that geeks system thing I was talking about, you know, it has a kernel. All right, that's a Linux kernel. 02:26.640 --> 02:38.640 But you know, we like parents. So as soon as possible, we like to have, you know, that initial RAM disk. And of course, we would use scheme inside that initial RAM disk, right? 02:38.640 --> 02:48.640 So what happens next, you know, you need to have so many systems at that point. And this is where the shepherd comes in, right? 02:48.640 --> 02:54.640 PID1. And we obviously also want to have our favorite language in that piece of code. 02:54.640 --> 03:06.640 And then, well, the rest applications, you know, sometimes you have to use applications, not written in guide. That's okay. That happens. But that's the idea, right? 03:06.640 --> 03:12.640 Okay, then more time. This is a scary problem to talk. Please bear with me. 03:12.640 --> 03:22.640 Um, all right. So this is, this is my laptop, okay? I'm running geeks system. And so I'm running to shepherd. 03:22.640 --> 03:26.640 So what does it look like? 03:26.640 --> 03:32.640 Well, if you've ever used system D, for example, it kind of looks similar. 03:32.640 --> 03:40.640 I mean, at the command line level, at least. So you can earn the heard status command. And you see the available services. 03:40.640 --> 03:48.640 There are lots of them. We could have a three-style representation of those services. I agree. I mean, system CTL does a better job here. 03:48.640 --> 03:50.640 We're going to improve on that. 03:50.640 --> 03:54.640 Anyway, you have the list of services, as you would expect. 03:54.640 --> 04:01.640 And from there, you can say, well, what's the status of, let's say, the average demand service? 04:01.640 --> 04:07.640 Okay, and you get pretty much what you would expect. So the, if this status, you see the main PID, 04:07.640 --> 04:15.640 you see the command line, what it depends on, you know, the requires line says it depends on a bunch of services. 04:15.640 --> 04:24.640 Um, you see it's log file, and you see things like things that have a demand world with standard output recently. 04:24.640 --> 04:29.640 So you get an idea. It's not totally happy with the network situation or something. 04:29.640 --> 04:35.640 Anyway, and there's one thing here, the custom action thing, which is more unusual, I would say. 04:35.640 --> 04:41.640 So this service of a demand has a custom action. So you can not only start it, stop it. 04:41.640 --> 04:48.640 You can also use the configuration action. So let me show what it looks like. 04:49.640 --> 04:54.640 So do heard configuration, have a hidden demand. 04:54.640 --> 05:01.640 And it just prints one line, which is the fine name of the configuration file. 05:01.640 --> 05:06.640 So I can, I can actually view the configuration file like this. 05:06.640 --> 05:09.640 Okay, that's the thing. 05:09.640 --> 05:15.640 All right, going back to heard status, we can see that there are different types of services. 05:15.640 --> 05:19.640 And in particular, we have timers, which is a relatively new feature. 05:19.640 --> 05:25.640 So for example, we have a GC timer, which has nothing to do with snippets. 05:25.640 --> 05:29.640 But it does have to do with garbage collection in the context of gigs. 05:29.640 --> 05:37.640 And the log notation timers. So I can query the status of log rotation like this. 05:38.640 --> 05:41.640 Again, I see it's up, et cetera. 05:41.640 --> 05:45.640 And I get information about upcoming timer alarm. 05:45.640 --> 05:48.640 So when it's going to run next, things like that. 05:48.640 --> 05:54.640 Okay, so this was for PID1, my main shepherd instance. 05:54.640 --> 05:56.640 But I also have shepherd running as a user. 05:56.640 --> 06:03.640 So if I type heard status without sudo, I can see my services running as my user. 06:04.640 --> 06:07.640 Because I'm using gigs on them. So these are services running as my users. 06:07.640 --> 06:11.640 Some are stopped, some are timers, some are started. 06:11.640 --> 06:16.640 And one of them is the repal service, that's Winger Bell. 06:16.640 --> 06:19.640 That's to read a wrong print loop service. 06:19.640 --> 06:32.640 And so of course, I can actually connect to my shepherd instance, if I manage shepherd. 06:32.640 --> 06:36.640 Okay, this is this is guy running inside my shepherd instance. 06:36.640 --> 06:41.640 And I can say, please choose the shepherd service module. 06:41.640 --> 06:46.640 And show me the GPG agent service. 06:46.640 --> 06:49.640 This is my GPG agent service. 06:49.640 --> 06:53.640 And I can do things like show me the status of that service. 06:53.640 --> 06:56.640 Here it is, things like that. 06:56.640 --> 07:00.640 It's even more fun to do it with PID1. 07:00.640 --> 07:05.640 I want to do it here. Okay, but you get the idea. 07:05.640 --> 07:11.640 All right, so this is what the shepherd is from a user's perspective. 07:11.640 --> 07:14.640 And of course, you first need to configure it. 07:14.640 --> 07:16.640 So what does the configuration look like? 07:16.640 --> 07:20.640 You have a configuration file, which is actually a scheme code. 07:20.640 --> 07:25.640 Obviously, this is an example where you define the SSHD service. 07:25.640 --> 07:30.640 We're just saying, in this particular case, where we're forking SSHD in demon mode. 07:30.640 --> 07:32.640 It has a PID file. 07:32.640 --> 07:36.640 If it terminates to our leap, please respond it on my behalf. 07:36.640 --> 07:40.640 And then register the service and start it in the background. 07:40.640 --> 07:43.640 And this is my entire configuration file. 07:43.640 --> 07:47.640 Of course, in practice, you have more services that we get the idea. 07:47.640 --> 07:53.640 But I can also say, well, I would like SSHD to be started as a 90D style service. 07:53.640 --> 07:58.640 So if you're old enough, you probably know about I need D otherwise. 07:58.640 --> 08:06.640 Well, it's a thing that allows you to say, please listen for accept connections on these two end points here. 08:06.640 --> 08:09.640 And whenever somebody connects to these end points, 08:09.640 --> 08:12.640 then starts that SSHD program. 08:12.640 --> 08:14.640 And it will take care of the rest. 08:14.640 --> 08:17.640 So that's how it's implemented currently on GIF system. 08:17.640 --> 08:19.640 We have a 90D service. 08:19.640 --> 08:23.640 The good thing is it starts instantaneously when you boot your system. 08:23.640 --> 08:25.640 It doesn't actually spawn SSHD. 08:25.640 --> 08:30.640 And SSHD is only spawn when you actually connect to the machine. 08:30.640 --> 08:35.640 It supports, well, other types of services like timers as we saw before. 08:35.640 --> 08:39.640 So this is an example of a timer, which specify a calendar event thing. 08:39.640 --> 08:47.640 In this case, you're saying, I want this update DB command to learn every day at noon and midnight. 08:47.640 --> 08:48.640 That's an example. 08:48.640 --> 08:53.640 So the calendar event thing specifies constraints on when you want to learn to command. 08:53.640 --> 09:00.640 And I can say I want additional actions like a trigger action to trigger the update DB thingy. 09:00.640 --> 09:05.640 Whenever I want the sudo, heard trigger update DB. 09:05.640 --> 09:11.640 It starts getting interesting when you do other things. 09:11.640 --> 09:16.640 You know, you can do other things and just start processes or listen for incoming connections and stuff like that. 09:16.640 --> 09:19.640 Because this is all scheme, right? 09:19.640 --> 09:25.640 So you can say, well, my start method here is going to do something I want to do. 09:25.640 --> 09:27.640 Which is, for example, to mount a file system. 09:27.640 --> 09:29.640 And this is how I would do it. 09:29.640 --> 09:36.640 So I specify a custom start and a custom stops method that mount and mount a file system. 09:36.640 --> 09:39.640 And you know, sky is the limit. 09:39.640 --> 09:41.640 You can do pretty much anything. 09:41.640 --> 09:44.640 And actually on GIF system, we use it a lot to do. 09:44.640 --> 09:51.640 Lots of different things, you know, beyond just starting demons. 09:51.640 --> 09:53.640 So that's the idea. 09:53.640 --> 10:03.640 The whole thing, you know, that whole idea of how you design the system is about blurring the line between users and developers. 10:03.640 --> 10:09.640 Because in the end, you know, when you start customizing your system, the higher your shepherd configuration file, 10:09.640 --> 10:12.640 then effectively, you are sort of becoming a developer. 10:12.640 --> 10:15.640 You know, there's no clear line here. 10:15.640 --> 10:20.640 And that's the whole point of this design. 10:20.640 --> 10:22.640 All right. 10:22.640 --> 10:26.640 How does this all work internally? 10:26.640 --> 10:33.640 Well, when I started hacking on the shepherd and DMD, I thought, this is very simple, right? 10:33.640 --> 10:36.640 I mean, the thing is just going to start programs. 10:36.640 --> 10:39.640 And then it needs to wait for a sick child. 10:39.640 --> 10:42.640 And when sick child happens, it responds with program. 10:42.640 --> 10:43.640 And that's it, right? 10:43.640 --> 10:47.640 I mean, it's not very complex. 10:47.640 --> 10:48.640 Yeah, bear with me. 10:48.640 --> 10:52.640 I thought I would do the diagrams with TXE, but it's just too complicated. 10:52.640 --> 10:54.640 So yeah. 10:54.640 --> 10:58.640 So it turns out, you need to do that in shepherd, but you need to do more things. 10:58.640 --> 11:05.640 So for example, you want to be able to use that third command to inspect the status of your services, 11:05.640 --> 11:08.640 or to modify them, to start them, stop them. 11:08.640 --> 11:13.640 And so you need, at some point, in the shepherd, to have something like this, where you listen 11:13.640 --> 11:16.640 for incoming connections, you accept incoming connections. 11:16.640 --> 11:21.640 And when you get an incoming connection, then you need to process that connection 11:21.640 --> 11:25.640 in a reader commands that the user sends, like a status command, for example, 11:25.640 --> 11:27.640 and maybe multiple commands. 11:27.640 --> 11:30.640 And at the same time, you need to keep accepting new connections for new, 11:30.640 --> 11:34.640 heard programs, for example. 11:34.640 --> 11:37.640 And there's more than that, actually. 11:37.640 --> 11:41.640 So when you start looking about the details of how you can start a demon, 11:41.640 --> 11:46.640 well, for example, one thing we saw before that, you might have a PID file 11:46.640 --> 11:49.640 that you want to wait for when you start a demon. 11:49.640 --> 11:54.640 So yes, you start by 4x plus xx, you know, to start the program. 11:54.640 --> 11:59.640 And then you have to wait a little bit and see if the PID file comes up, right? 11:59.640 --> 12:02.640 And so you have two solutions in that case. 12:02.640 --> 12:05.640 You have to wait, you specify, you know, some period. 12:05.640 --> 12:08.640 Let's say I will wait for at most 5 seconds. 12:08.640 --> 12:11.640 And I'm checking if the PID file comes up. 12:11.640 --> 12:16.640 And if it comes up, I'm going to the right hand side here, the PID file is here. 12:16.640 --> 12:19.640 So the service is starting, I'm done. 12:19.640 --> 12:20.640 Okay? 12:20.640 --> 12:24.640 But if the PID file does not show up within 5 seconds, 12:24.640 --> 12:26.640 then I'm going to the left hand side. 12:26.640 --> 12:30.640 I don't have PID files, so I must probably do some clean up, like, 12:30.640 --> 12:35.640 terminating the process that I initially started and that was supposed to create that PID file. 12:35.640 --> 12:41.640 And at that point, I should change the status of the service to stop. 12:41.640 --> 12:47.640 So it's getting kind of more complicated than I initially thought. 12:47.640 --> 12:52.640 And I mean, more generally, you know, services might take a bit of time to start. 12:52.640 --> 12:56.640 So it's not just stopped or started running. 12:56.640 --> 13:01.640 You have probably at least two additional states, so starting, you know, 13:01.640 --> 13:04.640 the service might take 5 seconds to start. 13:04.640 --> 13:05.640 That's okay. 13:05.640 --> 13:10.640 And stopping because it might also take a little bit of time to stop itself. 13:10.640 --> 13:15.640 And so you need to keep track of all these for each and every service. 13:15.640 --> 13:20.640 So in the end, you have all these things, and that's only part of the story, 13:20.640 --> 13:24.640 because I'm not even talking about any these type of services here, 13:24.640 --> 13:28.640 like I mentioned for SSHD, I'm not even talking about socket-based activations, 13:28.640 --> 13:30.640 timers, things like that. 13:30.640 --> 13:36.640 So you have all these sort of activities that you need to bring in parallel, right? 13:36.640 --> 13:41.640 And so, you know, usually when facing that kind of situation, you're like, 13:41.640 --> 13:44.640 yeah, I'm going to use threads. 13:44.640 --> 13:47.640 But that's not possible. 13:47.640 --> 13:50.640 We want to be able to use fork. 13:51.640 --> 13:54.640 And, you know, it's actually quite little known, 13:54.640 --> 13:59.640 but you cannot use fork in a reliable way in a multi-threaded program. 13:59.640 --> 14:00.640 That's the thing. 14:00.640 --> 14:03.640 So you need shepherd itself to be single. 14:03.640 --> 14:07.640 And so you need, you still need to have all that concurrency. 14:07.640 --> 14:09.640 It'd be single-threaded. 14:09.640 --> 14:12.640 So how do people do that generally? 14:12.640 --> 14:16.640 I looked at the system deco to get an idea. 14:16.640 --> 14:21.640 It's really in C, but I think that's the same in many programming languages and frameworks. 14:21.640 --> 14:24.640 Essentially, in this case, you have to, 14:24.640 --> 14:30.640 I mean, if you look at the code, this is a code for restarting the service that stops 14:30.640 --> 14:33.640 too early, you know, responding the service. 14:33.640 --> 14:36.640 So you have to, you know, the service stopped. 14:36.640 --> 14:39.640 So you wait a little bit and you restart it. 14:39.640 --> 14:41.640 The code looks like this. 14:41.640 --> 14:43.640 You cannot recognize those loops. 14:43.640 --> 14:46.640 You know, it's totally different. 14:46.640 --> 14:47.640 There's a state machine here. 14:47.640 --> 14:48.640 You're in a function. 14:48.640 --> 14:49.640 You're living the function. 14:49.640 --> 14:51.640 You're going to come back later. 14:51.640 --> 15:01.640 It's very hard to see how the code actually relates to the diagrams I showed before. 15:01.640 --> 15:04.640 In the shepherd, it's very different. 15:04.640 --> 15:06.640 Overall, thanks to fibers. 15:06.640 --> 15:08.640 I get back to that in a minute. 15:08.640 --> 15:12.640 We are able to have code that directly resembles the loops. 15:12.640 --> 15:16.640 I showed before, the sequential pieces of programs. 15:16.640 --> 15:21.640 So for example, this is the code that handles sick child in the shepherd. 15:21.640 --> 15:24.640 It's slightly, but very slightly simplified view. 15:24.640 --> 15:26.640 You can check the actual code. 15:26.640 --> 15:29.640 It's an actual loop, right? 15:29.640 --> 15:33.640 And here, we're just consuming a signal, you know, data coming from a signal, 15:33.640 --> 15:36.640 left-defile descriptor. 15:36.640 --> 15:39.640 And the thing here, so a port in scheme, if you're not familiar, 15:39.640 --> 15:43.640 is a wrapper around the file descriptor, essentially. 15:43.640 --> 15:46.640 And here, we're just reading from that file descriptor. 15:46.640 --> 15:51.640 And you know, it might block because I don't have a sick child available right here and now. 15:51.640 --> 15:58.640 But that's okay because fibers is going to do that corporatively is going to suspend this piece of code 15:58.640 --> 16:02.640 and to save the continuation of that code for later. 16:02.640 --> 16:07.640 And when sick child actually comes in on that file descriptor, 16:07.640 --> 16:11.640 then it's going to resume that computation and that piece of code, right? 16:11.640 --> 16:16.640 This is sort of like, you can think of it like corporative scheduling. 16:16.640 --> 16:18.640 Yeah. 16:18.640 --> 16:26.640 Same story for the, you know, the listen loop, the loop that writes for incoming connections from clients, 16:26.640 --> 16:27.640 like the heard command. 16:27.640 --> 16:31.640 It's just like this, you know, we accept incoming connections 16:31.640 --> 16:36.640 and from there, this accept call unified block forever. 16:36.640 --> 16:42.640 But that's okay because Shepherd is actually going to suspend it and resume the continuation. 16:42.640 --> 16:45.640 When incoming connection actually happens, okay? 16:45.640 --> 16:50.640 And from there, you know, I have that connection and I can spawn a fiber. 16:50.640 --> 16:56.640 That's going to process the client request, the client commands. 16:57.640 --> 17:00.640 Same for the, you know, how you terminate processes. 17:00.640 --> 17:05.640 So typically when you terminate a process in the Shepherd or in any in the system, 17:05.640 --> 17:11.640 you basically want to, you know, send it sick term and hope that the process is going to be kind 17:11.640 --> 17:14.640 and terminate itself properly, you know, within a few seconds. 17:14.640 --> 17:21.640 And if it does not, then at that point you send sick kill to terminate it brutally. 17:21.640 --> 17:25.640 And the thing is this function here is actually quite simple. 17:25.640 --> 17:32.640 I mean, there is no state machine, you know, you just see the entire floor in one function. 17:32.640 --> 17:39.640 And that's a key thing, you know, you write for a message that tells you this process terminated. 17:39.640 --> 17:43.640 And if the message doesn't come in within grace period seconds, 17:43.640 --> 17:46.640 then you know you have to send sick kill. 17:46.640 --> 17:49.640 And this is it and it's very, very everything. 17:49.640 --> 17:51.640 This is wonderful. 17:52.640 --> 17:55.640 I mentioned the states of services. 17:55.640 --> 18:00.640 So individual services have to have those four states possibly. 18:00.640 --> 18:06.640 And so each service actually needs to have something, you know, that carries that state. 18:06.640 --> 18:12.640 And so in fact, each service internally in the Shepherd is associated with a loop like this, 18:12.640 --> 18:18.640 that closes a very little state of the service like its grand status, its value, 18:18.640 --> 18:25.640 and information such as when the service was previously restarted when it changed states, 18:25.640 --> 18:28.640 you know, so you can have debugging information. 18:28.640 --> 18:31.640 And this is pretty much an actor. 18:31.640 --> 18:35.640 I've host in the room, it's familiar with the actor model. 18:35.640 --> 18:38.640 I mean, this is everybody's familiar with the actor model, 18:38.640 --> 18:42.640 because this is pretty people keep talking about it, right? 18:42.640 --> 18:45.640 This is pretty much like an actor, right? 18:45.640 --> 18:50.640 Every service in the Shepherd is essentially that loop that we just saw before. 18:50.640 --> 18:54.640 And we can send a message to it to inspect its state. 18:54.640 --> 18:59.640 For example, when did you switch to the running state or what is your value? 18:59.640 --> 19:02.640 What is the PID of your process, you know, things like that? 19:02.640 --> 19:10.640 We can send message and we can also, well, send message to inspect the state or send message to change the state of the service. 19:10.640 --> 19:14.640 And this is what we have, you know, a whole bunch of actors essentially. 19:15.640 --> 19:21.640 That we can talk to to inspect and modify their state. 19:21.640 --> 19:28.640 This is, I mentioned the actor model, but maybe Christine would be upset if I were too much conflating, 19:28.640 --> 19:30.640 you know, the actor model and what this actually is. 19:30.640 --> 19:36.640 Again, this is using fibers, so it's actually the concurrency credential process is model, 19:36.640 --> 19:42.640 which is not quite the actor model, we'll see there are a few consequences here. 19:42.640 --> 19:50.640 Sweat and tears. I'm presenting, you know, a very beautiful panorama of the landscape of the thing. 19:50.640 --> 19:54.640 It's not always been easy, I won't lie. 19:54.640 --> 20:07.640 So, one thing is fibers is great, you know, because it hides the whole idea behind that you have scheduling and corporation, et cetera. 20:07.640 --> 20:11.640 But there are a few gutches, a few pitfalls. 20:11.640 --> 20:18.640 And so, one of them is, you need to be aware that when you use channels to communicate between fibers, 20:18.640 --> 20:25.640 channels to channels have a get message and put message operation on them, but it's blocking. 20:25.640 --> 20:28.640 So, well, it's not blocking it that you have to run the view. 20:28.640 --> 20:36.640 So, in this example, we have Alice and Bob trying to talk to one another, so it's a fairly common pattern when you use fibers. 20:36.640 --> 20:46.640 Bob has given the channel that Alice is listening to, and Bob is doing, you know, put message to hide to me with the reply channel. 20:46.640 --> 20:53.640 So, that's a fairly common pattern and the idea is that eventually Bob would listen on that reply channel to get the reply. 20:53.640 --> 21:01.640 But in this case, Bob is not a great friend, you know, he's just saying, bye bye, instead of actually, you know, trying to listen on the reply. 21:01.640 --> 21:10.640 So, what happens here is that Alice, when Alice does a put message on that reply channel, there's nobody listening on the other end. 21:10.640 --> 21:15.640 So, Alice will just block there forever, you know, that's kind of a problem. 21:15.640 --> 21:25.640 So, you can easily fall into that kind of trap, and even for example, in cases where, you know, Bob throws an exception because something went wrong. 21:25.640 --> 21:38.640 And so, the consequence Bob will never listen on the reply channel, but Alice doesn't know, and that is still there, you know, trying to send that message to Bob, but Bob is gone, you know, so that's a problem. 21:38.640 --> 21:43.640 So, the lesson here is you must not miss a run the view. 21:44.640 --> 21:58.640 And more generally, you know, shepherd is extensible, so you have situations where people might say, hey, look, I wrote my own service with my own start and stop method, and it's great, but now for some reason, hurt status hangs. 21:58.640 --> 22:01.640 Well, we have a problem. 22:01.640 --> 22:09.640 More generally, you know, for this kind of problem, we'd like to have something like this, so I don't know if you use GDP before and 23 programs. 22:09.640 --> 22:14.640 Yeah, usually when you're in that situation, it's a bad day. 22:14.640 --> 22:22.640 But in GDP, you can do threat apply all BT, and that shows you the backtrace of all the threats, right? 22:22.640 --> 22:30.640 So, you get another view of what's happening in your program, and we don't have that with fibers, so you never really know what your fibers are doing right now. 22:30.640 --> 22:37.640 So, when debugging, you have to be, you know, thoughtful and creative. 22:37.640 --> 22:50.640 And we've had a couple of other issues, so this is this civil-dool guy reporting a bug against fibers, a memory leak, you know, a memory leak, that's kind of a problem. 22:50.640 --> 22:56.640 Actually, that same guy actually implemented the leak before or so. 22:56.640 --> 22:59.640 But we got a second one, a few years later. 22:59.640 --> 23:10.640 This one was a bit less serious, because it only happens with very specific circumstances, but still, you know, a memory leak in PID1, that's like, not great. 23:10.640 --> 23:18.640 So, well, I mean, like any runtime support libraries, I guess you need to take care of it, right? 23:19.640 --> 23:30.640 All right, thanks for your help. So, what's the status of this thing? Well, there's been this Linux magazine headline, which I found summarized the situation pretty well. 23:30.640 --> 23:38.640 System D fix is a bug, while facing a new challenger. 23:39.640 --> 23:48.640 Yeah, so we have one point of open running. It's being used on all of your gigs machines, Gix people. 23:48.640 --> 23:54.640 It's great. I think it's, it's pretty stable. We haven't had any serious issues so far. 23:54.640 --> 24:07.640 It's being better integrated in Gix system and Gix home. So, for example, replacing that old and clunky log rotation service that we had with the Shepherd's log rotation service, 24:07.640 --> 24:13.640 replacing mcrone by Shepherd timers, which are, I think, more convenient and replacing the old styles. 24:13.640 --> 24:23.640 This log D by the Shepherd's, this log D. Fiber's, despite what I said, before it's a solid foundation, any time you want to have, you know, that kind of concurrency. 24:23.640 --> 24:31.640 There are a few pitfalls, but really, really, it's pretty nice because it hides all the complexity. There is no callback hell. It's great. 24:31.640 --> 24:35.640 And it needs love. I'm trying to give it some of my love as you can help. 24:35.640 --> 24:44.640 The Shepherd itself is very small, so it's not a system to replace them because system did so many things these days, right? 24:44.640 --> 24:51.640 But it does, you know, the core functionality of managing services, you know, spawning demons and doing other things. 24:51.640 --> 24:56.640 And in only 7K lines, of course, so I think that's really cool. 24:56.640 --> 25:04.640 And if you're missing anything from the Shepherd, well, let's just go ahead and hack. You can hack in your config file as a start or you can hack into Shepherd itself. 25:04.640 --> 25:10.640 And you're welcome to do so. What about the future? The future is next talk. 25:10.640 --> 25:16.640 Juliana is going to talk about the integration of the Shepherd and Goblin, so I don't have to talk about the future. 25:16.640 --> 25:19.640 And this is it. Thank you. 25:19.640 --> 25:34.640 Any questions? 25:34.640 --> 25:39.640 David. 25:39.640 --> 25:56.640 So the question is, how did we address the run-divou problem in Shepherd itself? Do we have some sort of inbox and outbox? 25:56.640 --> 26:05.640 No, we don't. So we still have synchronous messaging, so the basic channel thing. We just pay attention. 26:05.640 --> 26:14.640 And that's the whole thing. I agree. It's kind of, yeah, you have to be careful to be available any time you're sending or receiving a message. 26:14.640 --> 26:21.640 So essentially, that means you spawn a fiber if you're going to do something that might take a bit of time. That's the thing. 26:21.640 --> 26:23.640 There was a question here. Yes. 26:23.640 --> 26:33.640 Would you say that the fibers are just, do you need it? Just to work around the limitations of the positive stress? 26:33.640 --> 26:41.640 No. So the question is, are fibers used here just as a workaround for the limitation of positive stress and fork? 26:41.640 --> 26:50.640 No, no. I think it's really useful for any time you have concurrent sequential processes, lowercase, as is the case here. 26:50.640 --> 26:57.640 I mean, you have different activities to run concurrently. I was going to say in parallel concurrently. 26:57.640 --> 27:04.640 And so if you want to do that, Shepherd is a great foundation for it. Whether or not you're talking. That's a different story. 27:04.640 --> 27:14.640 And actually fibers let you choose whether you want to have multiple threads, post-extreads in your process or just one. So you can mix and match. 27:14.640 --> 27:18.640 Any other questions? Yes? 27:18.640 --> 27:24.640 How do I hack on the Shepherd from PAD1? 27:24.640 --> 27:33.640 So the Shepherd has an extensive test suite that is not running as root and the Spirit1. 27:33.640 --> 27:41.640 So for the vast majority of situations, it's enough. You don't need to hack it as Spirit1. 27:41.640 --> 27:55.640 But then we also have system tests in geeksystem running in a VM where when making changes that only have an effect on PAD1, you would first test it in a VM. 27:55.640 --> 28:02.640 So we have system tests, for example, that make sure that the root file system is properly and mounted when you shut down. 28:02.640 --> 28:08.640 And that's something that's very specific to PAD1 and that you need to test in a VM, basically. 28:12.640 --> 28:17.640 Another question. Yes, please. 28:26.640 --> 28:34.640 Would it be possible to replace Android's in its system with Shepherd? 28:35.640 --> 28:44.640 I don't know, maybe I'm not familiar with Android, but maybe maybe I don't know. 28:44.640 --> 28:51.640 Okay, let me know if you do find out. 28:52.640 --> 28:54.640 Okay. 29:03.640 --> 29:05.640 It could be an option, okay. 29:08.640 --> 29:11.640 Are we done? Peter, what's the status here? 29:11.640 --> 29:13.640 Are you have a question? 29:13.640 --> 29:17.640 Does Shepherd support any kernels besides the Linux kernel? 29:17.640 --> 29:21.640 Yes, the Shepherd can run on the hurt. 29:21.640 --> 29:29.640 And it has a small portability layer because the hurt doesn't have signal FD, for example, which is the signal file descriptor thing. 29:29.640 --> 29:33.640 Yes, and it should work on any public system actually. 29:33.640 --> 29:35.640 Just not tested. 29:35.640 --> 29:36.640 Awesome. 29:47.640 --> 29:49.640 Thank you.