 Welcome once again to the tower the talk we're about to have is optimising boot time by Margarita Manterola and once again the IRC channel for questions is hash dc6-talks-tower. Thank you very much Margar. Okay this is above not a talk so it's not intended for me to come here and give you the magical solution I'm going to present some research I've made some suggestions and things that I've found and I'd like you afterwards to also propose ideas and present experiences that you've all had regarding boot speed. Mainly it's a question of usability since you are here with your laptops you probably boot your machine quite often and you probably complain of how slow it boots because most laptops tend to take about a minute in boot time and that minute seems like a very long time when you are eager to start working and you have to wait for the whole booting sequence to come up so that's why we want to make it better but we are not that bad these are the times that I took they were all done in the same computer in Pentium 3 so all these are freshly installed distributions well actually the edge installer was not working really really well that day so I had to manually install the desktop task because desktop task was not there but that's the only thing that I manually did and the Shen 2 I did not install myself because I'm not capable of installing it myself but I asked a very good friend of mine to install it in the same machine and it was freshly installed Shen 2 whatever that is so as you can see of the freshly installed distributions edge is the one that's doing better so we are not that bad from edge to search there's very little difference it's there hasn't been much of change this is of course with Exim for working properly if for some reason when the network comes up the interface is not configured Exim takes like one whole minute to time out but well this was with Exim working properly so we didn't have that problem it looks like the Ubuntu people made a lot of progress between Breezy and Dapper but we are still doing better and well with Shen 2 it's it's Shen 2 is twice here because Shen 2 has a nice configuration file something like etcrc.conf or something like that where you can configure how the boot process is going to work so freshly installed Shen 2 was kind of slow but after changing something like three variables in the config file we got a very fast boot for Shen 2 that's one of the nice things that of that distribution that you can just touch three variables and change the boot process completely it's like more than 20 seconds of the difference just changing three variables in a configuration file when you compared the startup times did you also compare to what services were being started by default or that were installed by default on the differences distributions because if one has an SQL server by default and the other does not that will impact boot times so did you look at that yeah sort of it's mainly freshly installed and I was aiming to a desktop distribution so Dapper and Edge installed almost the same services and with Shen 2 we installed only the desktop part so it's there might be a little bit more services than others but it's mainly the same thing because it's a desktop installation it does not have Apache or SQL server or anything like that well and well up there it's what I've been doing tweaking the installation of Edge so that it booted faster I got it to boot 20 seconds faster when the boot time is 60 seconds 20 seconds it's a big difference but it still is a lot of time 37 seconds it's a lot of time we should aim to get it as fast as possible like lower than 30 seconds we are competing against an unoperating system that boots in something like 10 seconds so we really want to make this as fast as possible so of course all that I did I did it with boot chart see I didn't time the time of the distributions with a clock I did all this with a boot chart so this is the boot chart of freshly installed Edge do you want the mic boots in 10 seconds uh Windows XP I don't think so uh yes it booted in my laptop when I bought it it booted in 10 seconds okay it usually loads the graphic interface but still loading all the services in the background so it doesn't really load in 10 seconds I know I know I know of course of course of course I'm talking about the user point of view I know I know it's crap I'm not saying it's a good operating system it's just that from the user point of view you have an interface in 10 seconds well uh we tried this uh with school and the thing is you have to be logged in that's the acid test you have to be ready to start a program as a user then you can say you have the boot everything ready thank you yeah okay well this this is up to gdm gritter it's not logged in if you count the time that gnom takes to start it's even more time I'm just waiting until gdm gritter runs and that's the point pointer if the measurement the measure the method you use to measure this gets you into this this kind of discussion you should probably find a point where you really started uh just arguing with you a little that you just are starting a program as a user thank you okay yes but well I was concentrating on boot time I also think gnom should try to start quickly yes they are trying to work on that okay so what's the what takes the time away this graph for if there are some people that haven't seen boot chart yet uh the blue thing is the sepe you use the pink thing here is waiting for the hard drive and this is reading order of the hard drive or something like that so we mainly don't want these kind of things where the cpu is not being used the hard drive is not being read or well here or here and here we have very little cpu and a lot of hard drive so this is hardware clock being synchronized all the distributions have this problem hardware clock takes around two seconds to synchronize and if you don't run it in background it's hold two seconds of nothing going on this is depth mode it's reading the whole module list and stuff it's about three seconds this is network coming up this is waiting for the dhcp server to give you an ip and afterwards running port map as you can see around here there are two slips there's one slip one in the dhcp script and another slip one in the port map script these slips are there so that services can be set up after the interface has come up or after port map has finished running and you might think that one slip one is not that bad because it's only waiting for one second but if we have one slip one here one slip one here and there's like another slip here although it's not in shellcode it starts to add up a lot of seconds of doing nothing so we don't want our cpu to slip at all and well finally gdm takes a lot of time like this place here is this place here and it's doing nothing but it's inside gdm it's not in a shell script it has a slip one but hard coded inside gdm so it's it can't be touched from a shell script so what i did to make it boot faster here's the boot chart for when it booted in 37 seconds was first start the network in the background so we don't have that hole here then remove depth mode from the boot process because we only need to run depth mode when we change the kernel so why run it every time the machine boots okay i know for a server i know that a server only reboots when the kernel changes but that's not the point no that's not the fact for a desktop what would happen if you put depth mod in the background what would happen if you were to put depth mod instead of removing it put it in the background just like you did with the network i didn't try it i think it would work okay does anyone think that it wouldn't work i just take it took it away because i think it was useless why run depth mode every time your machine boots if you only need to run it once when your kernel changes it's like such a waste of cpu and of disk reading so i took it away because i was bothered but it would probably run okay if you put in the background uh then running hardware clock in the background took six seconds away uh the boot chart showed three seconds of of uh gap but it took six seconds away to run it in the background uh i'm not sure if running hardware clock in the background uh is damaging in the days i've done i didn't find it damaging but i'm not completely sure so if you think there's a problem with running in the background please say so yeah okay sorry i'm just going to pass this on from irc um somebody has just said putting depth depth mod in the background won't work you need it completed for loading modules but yes removing it makes sense no just passing that on okay running hardware clock in the background is probably not the problem because it only the reason it takes so long is because it wants to properly sink or read the time at the moment it gets updated but the only thing you have is that you might have a slightly less accurate time in the during the boot process but that's should not be an issue definitely and surely if you run stuff like ntp it probably gets synced properly afterwards anyway so that's probably you could i think you could even just leave it out you could patch hardware clock to not try to do syncing and just read the time and then you might be one or two seconds off but that will get corrected later anyway okay so it's not damaging okay uh then this i found on a user list um searching for something like devian boot time or something like that i found the mail let's say point your shell to bean dash instead of bean bash and it took six seconds away this is the most trivial change i made i used update alternatives it was one comment line then pressing one button and and it took six seconds away i think that this is a change that should be made either by making dash the default sh or by making the need scripts use dash explicitly but one of the two has to be done because it's such a waste of time not to do it uh well then uh using parallel starting for the services at the same run level this is actually mangling with etc init d rc which actually has parallelized uh starting of the services already there uh it's just a variable that has to be changed i didn't know it either i started looking at the file to see what i had to change to make it start parallelized and i realized there was a variable there that actually did the show up it's just changing the value and it works uh well it took only two seconds away but then rearrange the services so that things start in a different order and especially this this hole over here was the gdm sleeping right so i rearranged the services so that when gdm is sleeping uh debuff is doing something i don't know exactly what but debuff is taking the cpu so it took other two seconds away okay so uh what i've been saying the problems that we need or may be able to solve to parallelize to to start the services in parallel we need to know what has to be started first and what has to be started second i did i did this by hand tweaking things changing them from the 20 to 15 or whatever but it was like a very dirty thing to do i only did to try to boot as fast as possible but to do it clean neatly we would need to uh know exactly what needs to be started before whatever else needs to start so uh this needs kind of a lot of work to show the dependencies of each script this is what shen to that currently it does it at runtime and doing it at runtime probably waste cpu time because it calculates the dependencies whenever the script and in each script needs to run it calculates the dependencies sees if the dependencies are already started and if they are started it starts and if they are not it starts it uh this works okay gen2 boot quite fast but uh it would be faster if the dependencies were hardcoded if we had a command like update boot dependencies or whatever that hardcoded the dependencies so that it started in the correct order yes nati okay passing on another few messages from irc um firstly boot script reordering could be done based on dependency info using i i ns serve secondly um the parallel booting can be enabled in et cetera default rcs but the parallel sorry yeah but the parallel boot system needs more testing before it can be made the default this is from the person who wrote the parallel boot feature okay uh okay so historically there have been problems with things like where in the sequence you start ntp based on the fact that people have very different ideas about what they're using their computer for and what's important and what's not as we go through thinking about this and thinking about how to maybe make the stuff configurable is anyone thinking about that notion that you know some people that we might need some concept of a usage profile mapped into this as well i mean the specific example of the time synchronization stuff some people want that started very early because they don't want any log entries on the system that uh don't have the right timestamps and as a result they're willing to push the network start stuff also very early on the other hand with a notebook or something the right assumption is no networking until very late in the process and you do dynamic device discovery and so forth these things create interesting trade-offs and sometimes even loops in the boot script dependencies yes well if we had the second point here a configuration file where you could specify your boot process it could be a nice feature to specify what priority network has or what priority whatever other things that we want to have priority have so that the yes so that they are started earlier regarding ntp when i was testing breezy my network was kind of clogged because i was downloading like three dvds from previous devcon from um for selling fedora that i don't have time to install it but anyway uh so the network was clogged so ntp couldn't reach the server and that like added like 20 seconds to the boot process because ntp was running in foreground and uh until it timed out after 20 seconds the the boot process didn't go on so that's the kind of bugs that we don't want uh then i tested breezy without uh with with the network not clogged the number i presented earlier was with the network working all right yes nati so this is actually just an aside from um from irec yet again saying could people in the audience when they're speaking please introduce themselves okay uh so it it would be nice to have script dependencies uh that someone from irec said that it can be done uh i didn't understand exactly how but it's good if it can be done uh and it would be really really nice to have a file where we can specify what kind of boot process we want um oops and finally uh the boot process is really very verbose it shows up a lot of info and when you're running it in parallel the info is like so much garbage because all the scripts are outputting the same to the same place at the same time and it's like it's useless so it would be nice if that could be selected or configured like passing an option when it starts that says verbose yes or either configuring it in the same configure file whatever but so that it's not so verbose it's easier easier to understand easier to see is if something is working or not and maybe not outputting so much might reduce a second or two i'm not sure but uh when you when you un-tar something and you use the minus b option you know that you are taking such a lot lot more time because you are outputting things so i think it might reduce a second or two not to house of output uh on other side note people embedded systems also um disabled the uh kernel message output and almost all of the boot output and they gained um multiple seconds i think at least uh three or four or so on a slow arm system just by not doing anything of kernel output um i'm peter the driver from belgium p2 at debion.org okay so probably not outputting things makes things things faster too so well mainly mainly this was what i was proposing uh going back to the previous slide is there any objection to making dash the default sh show i mean it's a great idea in practice the problem is that you will occasionally run into bugs with people who assume it was bash so you're just ask you're just um making it a little bit worse if such a bug happens which bugs um bashes them so you know of any kind um just there's all there's all different kinds um i run with with uh dash and i see maybe one a month or something it's not a big deal andrew mcmillan um wouldn't that just mean that the bugs would get filed against those scripts that might be a good thing okay so uh to whoever has the power of doing this i really want to ask to have sh point it to dash yes sorry again with the ilc one person one person comments um init dot d dependencies can be specified using lsb format and the reordering can be done using the ins serve package using the info to reorder the scripts and it is possible to to run init dot d scripts in parallel using serialized output from the using the start part option another person says yes um bash isms are already rc bugs which means most of them have already been fixed so about the dash uh change maybe it would be a bit less risky of breaking different things to simply have the init scripts that are critical for booting have hash bang bin dash at the top then it's very clear whatever interpreter you use and you can use dash for specifically that init script and not for anything else and uh of course it needs to have then a dependency on dash but well we need to do that anyway um i'm mad doc um this is basically what i was going to raise if we have dash as the default for init scripts we do need to add it to the base system which is something we just might want to consider because if we keep adding stuff to the base system we are effectively increasing the size of our minimal system which used to be 30 megabytes and is now well above 100 so okay uh does anyone who has a computer can tell me how much dash takes 160 kilobytes could we actually get rid of bash this is bedale i mean look if you're gonna change that if you're gonna change the default it's ludicrous to ship more than one shell in base essential right so you know if there's one that's faster and smaller than that kind of like feels reasonable for days i mean i'm not a bash bash or i actually like bash but let's be reasonable um the problem we have with that right now is that we've allowed people who have bashisms in their programs to just add a dependent uh make the hash bang line say bin bash so um there's lots of scripts out there that do just use bash and they don't even declare dependency on it because it's an essential so it would be a lot of work to move away from using it i think yeah if you're gonna move to it you certainly are talking about you know a policy change in that regard because i don't think you could tolerate that at least for innet scripts and stuff like that whether it would still be reasonable to invoke bash from you know post in scripts and things like that whether it would have to be added as a dependency it's not a trivial change but if we're talking about making changes you know to what's going to be used by the init scripts and that's going to lead us to think that having two shells and bases reasonable then i'm not sure we've finished solving the problem yet okay so maybe the solution for edge so that we don't make edge lag could be to file bugs to whichever init script is there that can work with dash and ask nicely that these init scripts run run with dash i will note that that a lot of us who worked on embedded have used ash for exactly this reason this is also much smaller footprint and you know appreciated by that as well so lots of people like like ash as opposed to bash for this sort of basis okay i'm not such a surely expert i don't know the difference between ash and dash in practice it did not cause us much trouble to to make our scripts work under ash as opposed to bash yes it's not exactly the same but neither was it a big hassle to to build build familiar to use ash instead of bash i'm jim get us i worked on the handhelds project and i'm currently still worried about keeping things small though not as small on the one laptop or child project okay another maria another remark would be that it definitely helps to use a small binary as possible for getting for booting faster so you could even think of using busybox for all the init d stuff if possible and the second thing you could do is minimize the amount of forking don't don't in scripts so don't use pipes when you don't really need them but try to use as much of the options of the single command use you use in the script that helps a lot as well saves multiple seconds all these tricks together uh peter reynolds in comments that um demian edu has been using dash as shell for several years already and it's not a big problem i have one more question about where to place the login story is it possible to move that even earlier to to give the user a kind of good feeling it is supposed to be possible i tried i move gdm very up the scale of the numbers i don't remember exactly which number i gave it i put it very very up the upper i could give it and it still came up last but it's supposed to be possible if you put it early it is supposed to come up early but it takes such a long time that it comes out last anyway uh i'm blars uh not using gdm maybe a way to significantly speed up your boot you know even if you do have to start x after you log in that way i i don't like any gdm or any of those i don't use them well yes of course uh but i was aiming to the whatever the user interface the user installation and users tend to like gdm or kdm but i like norm so i stuck with you know yeah just a really quick comment on the ash dash bash controversy um so actually currently in devian ash uh predepends on bash so there's uh sorry on dash ash predepends on dash so uh there's really no point in using ash instead of dash yeah but you just get an extra 16k instead of just having the whatever 93k it is installed okay uh wookie uh i'm wookie um yeah i was just going to follow up really on other embedded people who've who've mentioned all the all this stuff applies to small systems particularly we tend to really care we'd like boot seconds of two seconds boot times of two seconds rather than 35 um obviously that involves taking stuff out but there's a lot of people who've looked at p2 mentioned a couple of things there's a lot of things we can do you can there's kernel patches to make things boot faster and um obvious stuff like changing the shell but there's a whole load of research being done on how to make things boot as fast as possible and not all of that is applicable to desktop systems as well but some of it will be so if someone gets really enthused there is uh quite a lot of research being done and we could try and see how much of that we can use on general systems and the embedded people will be terribly keen to see essential reduced as much as possible and all these sorts of things are generally great so uh tiki g all we have to do now is make it happen yes exactly how do we make it happen how do we get uh whatever knowledge you have to the user system there isn't a simple answer to that question obviously um i mean what i would say is if someone's interested in this um i went to a talk about reducing boot time aimed at embedded systems and so anyone who is looking at this should read that document because it had loads of useful points um that will be a good start um i suppose we need to have a team or something really is is the only way to get it done because it does it crosses all aspects of the system so you've got to have people who know about this that and the other and know whether changing something is going to break a whole lot of other things and who's going to complain and as someone else pointed out there is a genuine problem of what is your target system is this a server a laptop or a tiny box uh and they don't have the same requirements so um we want to make as much possible as possible because we are supposed to be the universal oils and debbie and has so far had very much a kind of desktop and server focus and has largely ignored smaller machines and obviously we're keen to get as much stuff suitable for smaller machines in that doesn't break everybody else's systems as possible the website of the ce linux forum has a lot of tips which are which are mostly geared towards embedded systems but some of them should be applicable to and some of them we actually already implemented so that proves they are applicable to desktop systems uh if for the people who want to look it's like i think it's www.celinuxform.org and it's a wiki page and there must be a link on boot time optimizations and then you get the whole list and some have been implemented and some have hints on how much per how much time you could save by you implementing those um better ryan holds and comments on irc that six google summer of code projects propose to work on the boot system speed hi i'm ryan murray the gdm maintainer and i just like to say that the sleep that you are seeing is actually gdm waiting for the x server to be ready to use gm tries to talk to x when it fails it then sleeps and tries again and again so it's actually waiting for x to come up here and the sleeps uh there was one in earlier versions but in the current version and unstable and testing the sleeps have been removed from sort of the standard process so the only time it's sleeping is if x has not come up yet so anyone wanting to look into that part of reducing that time look at x not at gdm because it's just waiting for x okay uh just a comment to the previous comment uh i had to say something and i forgot what it was uh which was a previous comment summer of code right uh it's great that there's a summer of code issues and and people wishing to work on that but i think that this needs to be much more than just summer of code that every person that has an init script in the boot process has to be involved not only four or five students working and trying to earn some money during this summer yeah um i got smahinoz also comments that two of these six projects have a very good chance of being accepted it's great i just want to have the whole devian maintainers with the boot scripts uh also involved not not only the summer of code there was a comment over there no uh i'm just too stupid um yeah a few comments to several things that were mentioned here um for example uh the the fact that ash p depends on dash is uh because we have no ash anymore and it's just a dummy package so that's uh so we don't have any choice there anyway um and on the thing that uh script should use dash explicitly i think that's actually a bad idea um because if you ever change the default shell again you will have much much more trouble um so i think we should go for the clean solution here and uh just change the base system uh obviously that needs uh one release cycle to uh to really apply and i think don't think it would actually make it for edge but maybe that's just me being pessimistic um so um the i think the the uh more important problem on uh by uh of changing the default shell and kicking bash out of essential is um the whole um build thing because many um i think most of the this actual installed system is uh very bash bash cleans so that you can use dash instead but uh i think uh many of the devian rules files and stuff like that they still use bashisms and um if you kick bash out of the essential you will have many uh failures um on build time so you need to uh give um give you some time to fix all these failures yeah uh Clifford Beshears from linspire um the gdm maintainer has a good point x takes a long time to start you and after you get past the desktop on either no more kde or past the login screen you have another 15 to 20 seconds before you get a desktop and as long as we have Keith Packard and Jim get us in the back maybe they could tell us if they have done any research into optimizing the start of x because i've heard rumors that there are things you can do actually i had i had two comments i can certainly answer that question um the reason x takes a long time to start up is not x it's the desktop environment uh if you look at what gtk or kde does i can pass the buck because the next guy um if you look at what gtk does it's reading all of your gcon files which is about 300 or 400 separate xml files in your configuration and it reads a bazillion icon files it reads a million font files um it takes it takes the disk head and basically buck shots the entire hard disk because it finds files all over the file system so really at this point uh x login is completely seek limited um i don't know exactly what the desktop environments are going to do it's really nice to have your just your configuration spread all over like that because it makes configuring the system very robust because you have you have configuration for each application in a separate file and practically for every config variable it's in a separate file so it's a very robust environment but it means it's very slow to log in um there was one question about gdm sleeping um when i wrote xdm i actually changed the x server so that it would send a signal to the uh to the display manager um so if you ignore the appropriate signal uh tell the x server that the signal is ignored it will actually kill with that signal it's parent process so gdm can actually synchronously wait for the x server to become ready i don't i assumed it did that that's certainly been been in the in the xdm code base since about oh 1990 so uh but yeah x session login just takes a long time because genome and kde read a lot of files is this uh question to the well let me continue on on what what Keith's saying um if you uh have been watching Federico uh mania quintera's blog you will note that that replacing the genome session program with a shell script uh sped things up like six six seconds the genome session is has been sped up somewhat in the latest release but they still have stupidity inside of the gnome session um as far as some of the icon stuff i believe that there's been some patches for gdk that are may have already gone in at least in some distributions for for putting a lot of the icons and the like in um in a shared memory area so that you aren't at least reading it for each application so certainly um certainly i know that genome folks are working pretty hard to try to help this situation um but there's just you know there's lots more to be done um in all of this um jocelyn muet comments that uh the the file reading has been changed in gnome 2.12 and debian gconf has apparently received loads of optimizations and as for gnome session it is being rewritten peter dynaltz in comments that readahead and preload might improve the problem with reading files all over the disk uh juet was the is the gconf and gnome session maintainer so hello okay so uh i wanted to use readahead 2 but uh i read a lot of documentation and couldn't get it working but on this moment when the cpu is being used so much but the disk is mainly idle you could use readahead so that around this time when the disk is being used so much it does not cloud the cpu it will probably take some seconds away but it needs to be simplified so that it can be done easily was there another comment yeah um uh about uh yeah about the uh the dash i've never used dash but it seems like a trade off for increasing boot time but then you lose uh flexibility and features from the the uh the base system i mean if um if during the install if you use dash then the user accounts are populated with dash then and it sort of sets a precedence for for the uh the base system then i do think you need to necessarily change the default user shell but it's a question of what's actually inessential and what the scripts are using so certainly for an embedded system we'd like it if there wasn't bash there as a requirement but then we're not expecting the user to be sitting there at a shell playing around so sure on a desktop system if you're expecting people to drop into the shell and do stuff themselves maybe you want to make sure that bash is installed by default but that doesn't mean it needs to be inessential yeah i'm murray uh actually well i've got the mic um it's wookie again uh somebody mentioned over there that there is a problem with uh stuff at build time requiring essential features of bash which are complicated and fancy um but we don't care about that at all during boot time um that is a general problem that at the moment debian because everything's done natively has no concept of the difference between things you need when you're building versus things you need when you're running and uh it actually we probably need to make a distinction between those to solve a great pile of problems um but that's that's another big subject which we probably don't want to get into right now but um danny's doing okay no more comments i'm matt taggart one of the things i do is uh work on the linux standard based projects i can comment a little bit on the lsp file format uh the lsp is a developer standard and and what the lsp work group was facing when they came up with uh the standard for nitscripts is the fact that they're trying to come up with something that could be common across all the linux distributions so that developers um writing um applications and needing to install nitscripts could do it in a common way across all linux distributions because you have some linux distributions that are using system five and nitscripts you have others that are using other parallel init schemes um and then you also have different utilities you know in debian we have um update rc.d but in in red hat you have different things and so uh we needed one common way for people to be able to um install an init script on the system and then be sure that it would would work with system five or other things so the way it works is that um as an application developer if you're putting something on the system you use the lsp mandates that lsp compliant uh runtimes provide a command um to install the init script and it's up to the linux distribution to figure out to to provide that command and figure out what it does so in our case um it's just a wrapper around um update rc.d but you know red hat probably does something else because i think they use check config or something like that um so you you use this utility to install the init script and then the init script itself um at the very top in uh in some comments um there's some syntax that you use to tell it um you know not system five numbers about what order i want it started and you just say what your dependencies are so you set up these these comment fields um that can be parsed later on uh by the init program or or like you were saying if you could have all this stuff pre-compiled ahead of time so it didn't have to be recomputed on boot which also takes time you could do that um so if you maintain a package that uses init scripts uh take a look at the standard and basically you know even though in devian we're still using system five and um update rc.d you can put these comments in there and it will mean in in the future people will be able to uh turn on parallel init systems and and really speed things up a lot uh hello i'm uh philip hands i've recently been looking at uh packaging an alternative init called dep init which uh doesn't use the standard init scripts tool and you specify dependencies between every service and every you can depend on things like the existence of a root file system the rest of it uh and you start the system by instead of saying init three you say dep init gdm and uh it just does it uh it because it makes completely different assumptions from init throughout uh i can't see it being a candidate for edge really um but there will be interesting cross-pollination issues between what you're doing and uh getting this working so we should have a chat at some time uh do you have any idea of how long it takes to boot i've seen it boot a system but it's not a devian system it was uh limits from scratch system and it booted in about 15 seconds but it's quite a fast machine that was to a gdm uh login prompt yeah well it's it's difficult to compare from a linux from scratch but it's a nice the person that uh the person that built that is the person that wrote dep init and uh he has a very different way of looking at things so a lot of his assumptions will never work in devian but some of them are very interesting no more comments i'm done