 So, welcome for this third and last session about system boot of this morning. So, Mikael Sappelberg started contributing to Debian in 2008. Last year, he ran a survey on system D and the general sentiment in the Debian community about system D. And so today he's going to build, like, for the survey more than 2,000 people actually answered and he's going to build upon that to present some, or to debunk some of the myths that we have about system D. Please welcome Mikael. Okay, thank you for the introduction. Just in case I'm speaking too fast or anybody can't hear me, please just give a sign and I'll hope to correct that. So, my name is Mikael Sappelberg and while yesterday we had a talk by Leonard from the upstream point of view, this talk is going to be more the downstream point of view. In case you have any questions, please hold them until the end. We will have some time for questions and answers unless it's really, really important, in which case you can just ask it right away. Now, first of all, to cover a little bit of my backstory, I read Leonard's initial blog post a few days after it came out and I was skeptical. I thought that's a huge undertaking and I wasn't sure if that's actually going to work. So, I decided I will just hold off for a year or so and quite a while after system D was released, I actually first installed it and figured out, wow, this actually totally makes sense. Like all the commands are so cool. We finally have a way to introspect our system. I can check the status of any system. I can reliably start and stop services, etc., etc. And at that point, I figured this is the way forward. This is what we need. And I started contributing service files to packages to make them even better because system D supports system five services, but in order to get better support like more features and use the full spectrum of what system D can offer, it's better to have native service files. So, I started doing that and some maintainers in Debian actually merged these service files, but the overall progress was pretty slow, mostly due to a few issues that nobody in the package system D team really had time to tackle. So, when I finally figured out how to approach the problem, I decided to join the package system D team and just, you know, work on fixing that. That happened, I think, half a year to a year ago, and what I work by now in package system D is bug reports also merging contributions. So, if you send a patch for system D, chances are that I will actually merge it into our packaging. If it's patched to the actual system D source code, I will forward it upstream. That has been working well in the past. I also care about DH system D, which is a depth helper plugin to improve packaging and in its system helpers, which is a thing I talked about yesterday. I also sometimes do simple service files because they're just fun to do and just a quick task and they improve the package, but I also tackle the more complex service files because I feel that they should really be done right. So, I take my time and discuss with the maintainers and go back and forth, and we try to do the complex service files so you don't necessarily have to. Also, what's important for me is I say community outreach. I did the survey, I did several blog posts, I do talks at DEBCON, obviously, and I hope to do some real-life discussions. So, in case you have any questions, feel free to grab me at any point during the conference. Now, about the blog post, quick show of hands. Who noticed that I did a few blog posts? Okay, a couple. Who of those read those end-to-end, like, very carefully? Okay, perfect. Great. So, the motivation of this talk is, as you might have noticed, we, as in the package system D team, do not discuss on Debin Devil merely because we think it's not a good use of any of our time, but we actually want to communicate with you. So, I don't want to discuss the fact why Debin Devil is not well suited for that kind of communication, but I figured we should give a talk, and we want to address the top concerns, not only for the people who read the blog posts, but also for the people who prefer to just listen to me. Also, we want to encourage face-to-face discussions, so in case you don't have anything you want to discuss about before the talk, maybe you have something after the talk. Who of you did notice the survey? Who of you participated in the survey? Okay, great. For the others, we had about 573 participants of which 45.7% claimed to be DD or DM or some kind of maintainer of a Debin package. We also asked whether we should make it the default, but that was just, you know, to have, like, the opinion, not to actually make a decision. 43% said yes, 32% said no, and 23% couldn't decide yet. But what was most important about that survey was that we had free text fields for people to voice their top concerns, so they could just enter anything, and then I tried to, you know, create buckets out of that and have the top concerns listed with a respective weight and then address them in this talk. So the agenda of this talk will be, first of all, these are actually the three top survey concerns we identified. The first of them is complexity. This was voiced in many different ways, and it has many different, you know, things to consider. Some people said that system D has too many dependencies or it's too complex or it does too many things. It has too many features. It's hard to understand. All that kind of stuff is what I'm trying to address here. Then there's the issue of portability. Many of you might know that system E only runs on Linux. That's what's going to be in the second part, and the third part deals with debugging. In case any of you have any questions that are not or any concerns that are not within these three major topics, we have some time to answer them at the end. Now, before we start, a few quick clarifications because they also came up in the survey. The system D config files are not binary. They're human readable ASCII text files. It's just fact. Also, you can install system D alongside CSV in it. So on each and every one of your machines, you can just install it, try it out if you don't like it, switch back or switch back and forth if you have any particular problem. Also, system D has plenty of documentation. It might be hard to understand all of it because it's just so much documentation, but it's much better to have so much documentation than none at all. So those, I just wanted to get out of the way. Now, let's start with the complexity. First of all, people mentioned that system D has so many dependencies. Now, I wasn't actually sure how to address that. I decided that, hey, I don't actually know each and every dependency of system D, but probably I shouldn't answer to answer that. So I made a list of all the dependencies and you can read that document online. The slides will be uploaded later on. It's also in my blog. And in that document, I carefully document all the dependencies of PID 1, which are like 10. And then we have like about 40 other binaries that are somewhat related to system D. Some of them are just very simple command line wrappers that you can use in your shell script. Some of them are actually demos that are started on demand, like the whole time date CTL stuff and host name CTL stuff, stuff like that. So in case you're interested in that and you want to arrive at your own opinion on whether a system D has too many dependencies or just the right amount of justified dependencies, please read the document and then, you know, have your own opinion. Many people talk to me about debuts and how they don't like debuts and they don't want debuts to be running within their inner system. And I feel that it's worth clarifying that what system D actually uses is the debuts wire format. So it uses debuts for serialization in the first place in order to not invent its own IPC mechanism because by now we actually have enough of them, right? There's no point in just inventing another one of them and going through all the problems again. So the system CTL command, which you use to, you know, introspect your system, etc., and you know, start it and debug it. It actually, when you run it as root, will communicate with system D through a private Unix socket. It's not required to have a debuts demo running. Of course, if you want to use it on a typical desktop system and use the GNOME tools to see your service hierarchy and all that stuff, that goes over the regular system debuts bus. All right. Most of the other libraries that system D actually uses are widely used libraries. Like I already mentioned debuts, there's SELinux, there's lipcap, all that kind of stuff. And those libraries are mostly memory mapped anyway. You could say, well, not on an embedded system. Yeah, I give you that. But on most of your machines, it's going to be memory mapped anyway. Most of them are actually installed already. So if you actually will type apt-get install system D even though you're not actually going to install it, you will see that it only pulls in like five packages or so. All right. The next argument was that system D is so bloated. Now bloat is hard to define, but Wikipedia gives a definition and I tried to follow that. Wikipedia says that bloated programs are often using more resources, like more memory, more CPU. They are bigger in terms of lines of code. They're perceived as slower. They have higher maintenance costs, all that stuff. To that, we say that, yes, obviously system D uses more memory. You can actually measure that, but it's worth it because it does a lot more stuff. It doesn't just run your service in the background and then hope that it will all magically just work out. It actually keeps track of it and if it dies, it can restart it. If it dies, it will show you what's the exit code, when did it actually die, what are the log lines that are produced, all that stuff and that obviously requires more resources. I think that's very clear. Also, the second point of bloat as per the Wikipedia definition is that bloated software is slower, but it turns out that system D is actually measurably faster than system V in it. That clearly doesn't apply. Also, there is the factor about maintenance costs and we think that there will be actually less maintenance costs eventually. What do we mean by that? Currently, we have the model where we have a relatively simple system five in it and then we have a lot of complexity over all the in its scripts. A lot of maintainers need to learn about what should go into an in its script and how to implement all these features. I have recently looked at a couple of in its scripts and many, many of them have this idiom where they will try to shut down the service cleanly and if that doesn't work, they fall back on killing it and if that doesn't work, they fall back on killing it really, really hard and each and every one of them has a slightly different implementation of that with slightly different timeouts and all that stuff and that's a pattern you see in all the in its scripts. Just look at them. With system D, obviously, that complexity will not go away. It will just go into a different place but it will go into one repository where there's one upstream and we can all fix that stuff there and then over all the distributions, we can actually benefit from Arch Linux people contributing their fixes, from Gentoo people contributing their fixes, from the Fedora people, etc. We will have one solution that has some complexity but in turn, all of you, all the package maintainers, don't actually need to deal with all that complexity anymore so I think that's a great benefit. Some people were saying that system D is too complex. I just try to explain why I think that the complexity is actually centralized and not added because it's just pulled into a different place. Let me just add that many features of system D are optional. As an example, I'm not actually using all the features of system D. I'm not actually running GNOME so I use what I like. I like the journal. I like system D itself. All the other stuff is not that important to me and also new things always seem complex at first so whichever init system it's going to be that we switch to, it will seem complex just because it's new. Many of you have grown up with system 5 and me included and we think that we know how it works because we're used to it and it seems to work but I actually looked at the source code recently and at all the init scripts and stuff and it's much, much more complex than I thought and I think many of you might be in the same situation that you just think, yeah, it's this simple thing but it turns out it's actually not and if you compared it, if you honestly really compared it, I think system D doesn't look too bad. Now, the second part is that system D is not portable and obviously that's a fact. We can't have any opinion about that. It's just a fact. System D is a Linux specific init system and it does not run on Debian slash K free BST or Debian slash herd, which we have. Now, that is not an arbitrary decision as Leonard tried to explain in his talk yesterday. We actually need C groups for system D to achieve all the things that it does and also one important factor is that if we try to make it portable and for example had a K free BST implementation of system D that would not use C groups, we would need a lot of code and it would be, you know, the test matrix of just changing one little thing in system D, you would have to experiment and try it out on all the different platforms and write compatibility code for non-C group stuff. It would just blow up, right? It would be so much more complicated to contribute anything to system D to just change it, that it's just a decision that upstream made that they are not going to do that. Now, I say not portable is actually not a problem because we can use system D on Linux and system five-minute elsewhere or something else elsewhere. You know, if there's a better in the system coming up of 40 K free BST people, they can adopt that. In the midterm, obviously, there is some increased maintenance effort because we need to have a time period whereas system five-minute scripts and system D service files and, you know, we just can't get around that, right? Because whatever we end up switching to, we need to have that time period. So there's no way to get around that. But the long-term situation I imagine personally will be like non-Linux bugs today. So for example, let's be honest, I don't test my software that I maintain in Debian on K free BST or hurt at all. I rely on people who actually use it on these platforms to send me bug reports and then I will gladly merge the patches they provide or look into the problem if they can't figure it out. But it's handled best effort, right? If there's say 10 bug reports that have Linux specific problems, I will handle those before I look at the first K free BST problem. It's just not a priority. And I think that this is the only viable and realistic and pragmatic model that we can have for K free BST maintenance at large. So I say that's not a problem. Also I say that kernels are different and that's a good thing because the Linux kernel provides C groups on all these nice features which the other kernels don't provide. But then again the other kernels provide nice features. So for example, if I were to install a K free BST box, I could probably use CFS. Now I could also use that on Linux but that would be more complicated and stuff. There's a feature that I can't have on Linux which is PF, like the packet filter on K free BST. And you know the different kernels and the different distributions that we offer, they are different and that's good. We should keep that diversity. Now why not make Debian a good Linux distribution and a good K free BST and hurt distribution? This does not include that we need to use the same init system on all of them. Also there's an asterisk behind that point because I only care about the good Linux part to be honest. I leave it up to the others who are passionate in the K free BST and hurt part to make it good there. So debugging is kind of an interesting issue because I think that many people are so used to running in its scripts with sh-x and see what it actually does and where it goes wrong and that's just an issue that you won't have to do with systemd. It's not that you cannot do it, it's you won't have to because all the issues that you would typically debug with sh-x, systemctl status will actually tell you. You can actually see what command systemd tried to start to bring up the demo and you will see the exit code with which they exited. You can see the log output of the demos. You don't need to s trace a demo because it locks into a weird file that's not set up properly and you can't catch the standard error. That's just all things that will not happen in systemd. Now in case you actually need to debug something that is in early boot or somewhere where systemctl status won't help, you can always boot with the kernel parameter systemd.loglevel equals debug on your kernel command line and it will increase the debug log level and just log all the stuff. Interestingly, as was mentioned in two talks already, the journal will include log messages from the early boot. You will actually get a much better picture of what is happening and all the stuff that is happening in systemd has timeouts which are, as far as I know, 90 seconds and afterwards you will just get a rescue shell. In case there is really something that's really, really stuck, like a device not appearing but it needs to appear like your root file system is not there because you made a mistake in configuration, you will get a rescue shell and can try to fix it and then boot into your system and actually fix it properly. Some people were under the impression that in systemd everything is implemented in C so you would need to debug the C source code and that's complicated and more complicated than shell. I don't necessarily agree but looking at the C code is I wrote rarely required. I would actually say it's never required but I didn't want to put it on the slides because that's, you know, too hard a statement. I have in the entire history of debugging boot problems with systemd I think looked at the source code once and I can't imagine that for any of you it's going to be required so that's not a concern. Also what's interesting is that you can if you have some race conditions in your boot or you're not quite aware of the order in which things are happening and you want to have a tight grasp on that you can boot with systemd.confirm underscore spawn equals one and you can say yes or no to each and every service when it starts and that might help you out with your specific problem. Also in newer versions actually in 204 only which is currently in the bin experimental there is a thing called debug shell which you can enable and then you can switch to a debug shell very early in the early boot. Some people were afraid of cycles like you have all these dependencies and there might be a dependency cycle in there and then your system might be broken but that doesn't happen because cycles are broken automatically by systemd so whenever there's a cycle it gets resolved in some way which might obviously not be the best way it might not actually solve the problem but at least it will boot and then you can actually fix the problem. Also if all else fails you can just boot with systemd.unit equals rescue.target and all these tips and tricks I just gave are also presented in a nice fashion on the free desktop wiki on the link I give here so there's really a lot of documentation available on how to debug all these issues and you know I'm confident that debugging is just as easy if not easier than with the current in a system we have. Now I have one more slide that I just want to get out there why we would need to switch to systemd because that wasn't clear to some people in the survey but it's not a top concern so let's just go over that quickly and then we can answer your questions. Systemd provides a reliable and clean service management so it actually has a defined environment it does not leak your stuff that you use as an administrator in your shell into the services we can finally introspect all the services we can look at the status we can you know clearly stop them all that kind of stuff we have beautifully simple service files which are the equivalent of an init script just look at a few of them you will see that they're really simple to understand for each and every one of you that will make maintenance cost a lot less in the future. It has better hotplug think of laptops especially but in my case I also use systemd on a Raspberry Pi I use it on all my service and all my virtual machines it works beautifully everywhere and last but not least we will eventually arrive at a unified in a system across the Linux distros or at least across the most important ones so that actually lowers the barrier for new people to Debian because you know some people might consider switching from their current distribution but then they see oh it's all different it uses this old init system I don't know how to deal with that you know think of all the people that will actually grow up with systemd there's already people I talked to that only know systemd all right so that's the slides part of my talk as always please talk to us if you have any questions there's an IRC channel there's a mailing list there's my blog that you should follow if that kind of thing interests you and now I'll be happy to answer your questions question I think you you should explain why we should adopt systemd as a default why we can't keep the current situation where we have six five minutes by default on systemd as an alternative right so so as far as I understand the question is why would you why would we should why we should make it the default and not just have both of them supported and the answer is pretty obvious because maintenance of two different init systems is kind of complicated and we can accept that in the short term but we will not accept that in the long term many people have actually been asking me when can we finally make some decision in that area just because you know we want to have one init system that we can concentrate and focus on and not multiple init systems that are kind of supported and living there at the same time yes but you've already suggested that if we're going to continue to support non-linux kernels that the way you suggest we do that is by supporting more than one init system so for the average maintainer of a package in Debian it will never be the case that systemd is the only thing that they're able to support unless systemd chooses to also support the other kernels so it seems to me that you're just moving you know this burden of responsibility away and you know leaving it in the hands of every package maintainer in Debian to have to deal with multiple init systems instead of you know dealing with this somehow closer to the maintenance of the init systems themselves I don't know if that's necessarily you know a good choice or bad choice but you are clearly making a conscious decision to shift a burden of work which will never go away yes so that's a hard problem and question to answer I don't have a silver bullet for that there have been approaches of having a converter that would convert very simple service files into equivalent in its scripts I've seen that work and I don't think it's going to work unless somebody really spends a lot of time on that it was a summer of code project that is not in a viable state at all I do agree that you know some so some people were mentioning that we still have k3bsd and we still need to keep d in its scripts around but they will not be as important anymore as they are before because our major or most important platform which is Linux is running on system d so the issues that are more pressing now will become less of an issue later you know I I totally agree I don't I can't make it all go away but I think that's a good compromise to have you know that's all I can say sorry more questions over here somebody in the room microsoft hello yeah is somebody in this room using k3bsd in production really for something serious anyone okay yeah so if you actually look at the popularity contest numbers and I realized that they are skewed and you know opt-in and all that stuff you will see that there is about 70 installations of the k3bsd kernel whereas there are about 100 000 installations of the linux kernel you know just to give you some perspective I'm not saying that's the actual usage numbers question over here yeah so what is the what is the status of system d package and all the dependencies in in wheezy and jessie is it in any sort of usable state right now okay so the state in wheezy which is our latest stable release is pretty good I would say you can use system d there the version in there is 44 which is quite old by now but that's expected kind of a stable release we have the a much more recent version which is version 204 there's there was a huge gap because of dutif merge we have version 204 in WN experimental and that is mostly because it was a big change because you know dutif package was maintained separately and now it's not anymore it's team maintained by now so we have that in experimental we need to get a transition slot for libdutif 0 to libdutif 1 before we can upload it to unstable that request is already filed but there's not been any response so far but as soon as that happens and I'm fairly confident that from our side it can happen pretty quickly we will have system d204 in a reasonable shape and of course all the dependencies and everything that you need to run it as I already mentioned I'm running system d for over a year in production on all my machines so it's certainly usable in Debian does that answer your question all right so you said you looked at the dependency set and you've made a list which we don't have here but we can have a look and it wasn't excessive it was bigger but that's probably fair enough but my understanding did you look at the build dependency list because I know the recent fedora arm 64 bootstrap complained a lot about 400 build dependencies which is a problem for those of us that do bootstrapping now I realize that's a relatively minority interest but it is another problem bootstrapping is already very painful and if you can't get in its system until you've built 400 packages that's kind of annoying so but I don't know how bad the problem is with upstart to be fair so we should look at both of those yes it's it's something I'd like to know the answers to and I haven't looked in detail but I did get a lot of complaining from mr masters okay I have not looked in detail at the build dependencies for my personal builds and pbuilder it looks like a reasonable set of dependencies that are pulled in you know if there is any concern about that I'm sure upstream would be happy to help you out with that in fact planer wants to say something um so it's it's usual stuff autoconfin auto make and all these things which shouldn't be problem the problem that they probably were complaining about was um we build all our main page with doc book and that pulls in all the access all all style sheets and things like that but that's actually optional it's it's just that the rpm always build it with it so and yeah yeah so just to clarify I guess that's the problem's much worse in fedora because there's no cross building and there's no bootstrap minimal building mechanism yet so and we do have both of those things sort of nearly finished in debian so um that probably makes most of it go away and how hard is for someone to try it out let let's say I want to take a look at the thing as as you say you are using for a year in production but if I want to try it out is it possible for me to install it and maybe just replace the kernel in it yes in in fact that's just how you do it so if you want to try it out if anybody wants to try it out you just up get install system d um ideally from experimental um it's not as bad as it sounds um and then you will just modify your kernel command line to um include in it equals slash bin slash system d and you will boot up in system d and if you decide you don't want to boot up in system d anymore just you know remove that from your kernel command line you can obviously do that with the edit function and grab on a boot per boot basis so it's really really simple to try it out can I just comment on that for experience so I've been trying both upstart and system d on my laptop recently so the path of least resistance is just you just install system d and you don't even change the default line of the kernel yes just boot and in your grab or whatever you just edit the command line of the kernel and you add in it equal equals slash bin slash system d yes and if you forget about it the next boot you will get back on to system five so that's really easy to try out and not let's let's say not scary at all yes you will just notice that your next boot will be much slower and then you think oh yeah I need to add that flag okay more questions one more over here um in fact I think that not having system d as default has some drawbacks in the bugs affecting system d for example if you are using a vm2 on a crypt disk uh you need I didn't try maybe it's fixed in the packaging experiment but the one in unstable you uh you cannot boot so it is set up but it is because the integration of system d in Debian is not complete we are still using a lot of init script and the m2 is set up by the Debian init script yeah so the script disk the script setup is being worked I see in the main list but it's uh it's problematic to to not having more people working on system day because we we don't use it as a default yeah so the the lvm issue that you're speaking of is a bit of a pain point I've been trying to debug this um in the last couple of days and I'm working with somebody who actually can uh fairly regularly reproduce that problem actually because in oh you you can okay great so maybe we can have a look together and fix it um because I couldn't reproduce it um up until now um but I'm also using crypto and I have a few machines where I have lvm so in general this works it's just very specific setups that don't work more questions so uh I'm really a question from from IRC so the question is that uh instead of breaking the dependency loops during boot can it be made to reject to install such dependency loops when installing upgrading package like system VRC is doing um upstream wants to answer that out their microphone maybe oh no it works um so that's actually um pretty difficult because um we only check for dependencies between the stuffs you actually start right we don't really care if the entire network of of of dependencies you could theoretically have has any loops or cycles and we only care about the transactions that actually started and those of course we only know at boot time when we know which devices have shown up what you actually wanted to boot into so um it's it's a feature of system d that you can have as many cycles as you want as long as you don't have them and the stuff you actually try to execute all right more questions okay so this is probably not even for you but it's uh something that i'm asking myself uh clearly uh either system v or upstarch is a is a better thing than system v so but it's not clear to me who is the one who can make that decision on a technical standpoint so usually in they've been the maintainer that makes the decision and probably i'm asking this too early so but uh in this case i don't think there's anything in the eye that hard codes system v in it is just essential yes in the package maybe i'm wrong and i would like to someone to correct me so in this case i it's not clear to me how we are going to make that decision and uh for for myself i i don't really care much about both systems and i think most of the people that get involved in the flame you also don't can't can't also uh make an informal decision about that and i would like to to see how we are going to take the decision if if the system d and the upstart maintainers go to reach a conclusion or something else so i think it's unlikely that um the two maintainer teams will reach a conclusion um but um i actually i'm just going to work on how we can technically um make that decision in the next few days and then you know i can just propose it and we'll see what happens if somebody else wants to answer that please go ahead well i can try to well i think that what we are still lacking lacking is a detailed plan of what it means to make it the default i mean what in terms of uh what other packages need changes if any uh then um probably the well the way we well okay i shouldn't i try to answer that no but what's what will likely happen is that uh it will if we go to a technical talk technical committee at some point that's really likely because it's i would be quite surprised if we cannot find one developer will bring it to the technical committee and it just takes takes one so or the dpl yeah so the question is uh when when when is the best time to bring it to the technical committee also and i don't have a clear answer on that so maybe Bdale wants to answer we actually talked about this a little bit in the tech committee buff the day before yesterday i guess it was and i think you're the one who asked the question about you know what what do we actually need to do to bring it to that point and i think the advice you were given was probably very good which is to go look at the thing that we're currently discussing around limb jpeg because what it really comes down to is for the committee to be able to make a decision we have to understand what the implications are for the rest of the work that happens in the distribution and that largely comes down to what are the set of diffs that we're arguing about what packages need to be changed or updated what implications does this have for the installer system and things like that and so when lucas says you know we we sort of lack the the plan for you know what steps would be required to go from where we are now to the change that you'd like to see that's what has to get articulated and once that's articulated then we have a concrete thing that we're discussing and we're saying is this good is this bad are there problems are there still questions that need to be answered and that's something i'm confident that you know the distribution as a whole and certainly the subset of us that sit on the technical committee can wrestle with and try to make a good decision on but the problem right now is that it's all still sort of in the oh this is great oh this is great we ought to do this no way to do that and it's not in the form of you know sort of do we pick this set of diffs or that set of diffs to carry forward with the distribution and that's the kind of thing that would make this a crisper decision for us to try and wrap our brains around I will I will just state up front that I personally have you know I believe that the problem is that if the distribution decides to go forward with system D as a default that the attitude that you're currently putting forward about you know obviously we make Linux first and everything else a second-class citizen is something that many within Debian will have a very difficult time swallowing philosophically even if we all look at the numbers and go yeah I mean from practical standpoint that's right there is a big difference between sort of understanding and acknowledging that one of our kernels has the vast majority of the the user base and the difference between that and the sort of philosophical notion that we're trying to be supportive of you know alternatives and I think that the reason this is going to end up being such an incredibly difficult decision for the distribution to wrestle with is because what you would like to think of as being a simple technical choice is going to end up being a hugely philosophical decision about the extent to which we continue to try and treat other kernels as first-class citizens so related to that I wonder last year in just some in the google some of course someone tried out generating like a system five script from the system d service files so I know the project didn't go at that well but is the idea still viable or did you find any an inherent limitation that makes the idea not viable so the problem as I see it is that in order to have support for the features that you can express in a system d service file you would essentially need to reimplement large parts of system d and that's not a good idea right um don't you have maybe an 80-20 rule or something to figure out what's easily implementable and what's not um uh so we have around a thousand in its scripts in debbin currently and I haven't looked at the majority of those even I have looked at the ones that have the highest popcorn and that I use personally and that I think are important and those will not benefit from such a generator at all okay more questions so I guess this is it um thanks michael thank you very much