WEBVTT 00:00.000 --> 00:11.120 I kind of have a feeling you all know why you're here, but just in case somebody in the room 00:11.120 --> 00:18.560 is under 20 years old, Leonard has been quite a prolific contributor to a lot of open source 00:18.560 --> 00:25.640 projects and chances are that you actually run at least one simply two pieces of his 00:25.720 --> 00:30.840 software on your Linux distros, if you got their modern system, he's also one of the 00:30.840 --> 00:37.480 overall quite few people who have been given the honor of having specific distributions created 00:37.480 --> 00:43.480 explicitly not to include products, he has created. So he's going to talk about possibly 00:43.480 --> 00:58.120 them up. So we're talking about possibly the most controversial, but I will also argue 00:58.120 --> 01:05.160 the most interesting of the lot, namely system D, which is now 14 and Leonard will tell us a lot 01:05.160 --> 01:10.680 about what happened, what possibly did not happen and whatever he wants to tell us from top of that. 01:13.800 --> 01:24.360 That's a thing work, I think it does, right? So hi, I think this is the moment where all the 01:24.360 --> 01:28.040 Devon people need to start their sit-in protests or something like this. I hear that sit-in 01:28.040 --> 01:33.640 protests are the thing here, but yeah, oh they're apparently a single one showed up. 01:34.600 --> 01:58.840 Louder, this doesn't work, yeah, and apparently you need to turn it on. So okay, let's see if this 01:58.840 --> 02:03.960 works now. So what is system D again is my first slide to give you like bring everybody up to 02:03.960 --> 02:10.840 speed what this all is about. System D is a suite of basic building blocks for building a Linux OS that 02:10.840 --> 02:15.480 provides a system and serves manage that runs as P81 and start the rest of the system. This is 02:15.480 --> 02:22.440 verbatim copied from the system D website and it's I think it's pretty much accurate. So from a 02:23.320 --> 02:28.760 distant perspective this is all you need to know. This talk is about the last 14 years of 02:28.760 --> 02:34.120 system D and in a way also the next 14 years of system D. I will start out a little bit with the 02:34.120 --> 02:42.520 history, unlike how it came to be what it came to be and then which I find a lot more interesting 02:42.520 --> 02:47.320 is I kind of want to give a perspective on what's coming next, like what's in there for the next 02:47.320 --> 02:53.000 15 years and what we think system D is and what system D should become. So let's start first with 02:53.000 --> 03:01.080 the history. So yeah, system D has various predecessors. The most important one I guess is system 03:01.080 --> 03:08.040 five in it. It's really old, you know, I think the first commit, I mean it wasn't a commit back then 03:08.040 --> 03:16.120 because we didn't have really version control systems so well back then. But let's say the first 03:16.200 --> 03:21.240 trace of it that we could find of the implementation that was in use before a system D came 03:21.240 --> 03:27.480 along of so 1992 that's a long time ago. It's based on a design from system five 03:27.480 --> 03:33.720 unix which is even older from 1983. So this is really old stuff that came before. It's 03:33.720 --> 03:37.080 interestingly still maintained so there are a couple of people that have run people and things 03:37.080 --> 03:44.440 like that who maintain it. But yeah, it's old and this kind of like you notice it right like 03:44.440 --> 03:51.960 because a little bit are and like cryptic in a way and limited. Then in 2006 I 03:51.960 --> 03:56.680 canonical created something called upstart which was an inner system that was supposed to take its place. 03:56.680 --> 04:05.640 It was very modern by the standards of 2006 and yeah, it was it found slow adoption and 04:05.640 --> 04:11.720 went to of course where they started it and later lived on on rail but yeah. 04:11.880 --> 04:19.240 Automally died in 2014 so just looked about eight years and I think we played a role in that I 04:19.240 --> 04:26.920 guess. While a system five in it is kind of yeah I don't know it's it's a design from 983 04:29.640 --> 04:35.880 as you can indicate it but so the question is like of course if upstart was in using why didn't we 04:35.880 --> 04:42.360 all stick with upstart. I think that deserves an answer. From eye-opest perspective this upstart 04:42.360 --> 04:48.680 seeing didn't really solve the problem that we saw that a service manager in its system should actually 04:49.960 --> 04:55.560 solve a meaning like it it worked that way that you tilt a system that when that happens you do this 04:55.560 --> 04:59.800 when that happened you do this. The basically meant that somebody needed to actually sit down like an 04:59.800 --> 05:04.680 administrator develop a type who would actually figure all of the things that can happen on the 05:04.680 --> 05:10.680 system and then glue these events and these actions together and then this is how the system would 05:10.680 --> 05:18.680 be booted up. We saw that this manual configuration of the action like the event and the action thing 05:18.680 --> 05:24.520 that's that's that's to manual. It shouldn't be that way. Our thinking was you should just 05:24.520 --> 05:29.480 specify the goal and the computer figures out the rest. So there were other problems like slow 05:29.480 --> 05:36.680 development. I mean it was one person working on this and it's hard to to um yeah if you just 05:36.680 --> 05:41.800 one person there's also the problem was copyright assignment stuff so there was like a like a 05:42.760 --> 05:49.720 political barrier around adoption but yeah so eventually we figured we have this fundamental problem 05:49.720 --> 05:55.080 we have this legal slash social problem with it and it's a little bit moving to slow for us let's see 05:55.960 --> 06:02.200 um what do we can do about it so um we figured out like we created something new we first called a baby 06:02.200 --> 06:08.040 kid that's how my first commits were called baby kid it was kind of funny because you know back 06:08.040 --> 06:11.800 on the day all these little demons that showed up on the various limits distribution we're all 06:11.800 --> 06:16.920 called something kid. Most of them kind of died out again there's policy kids still there so it's kind 06:16.920 --> 06:22.760 of named poll kit. I think it's the thing that we imported from Apple but um yeah and then because 06:22.920 --> 06:28.840 this was supposed to be a process babysitter we called a baby kit you know it's kind of funny 06:28.840 --> 06:34.760 but every name did very soon to system mean I think not many people actually ever saw a uh this 06:34.760 --> 06:39.560 is a new tree when it was still called baby kid um we figured that if we call it baby kid it might 06:39.560 --> 06:47.080 not really find the the professional adoption we wanted it to find. So um yeah the basic concept of 06:47.160 --> 06:55.560 this is it was transactional system right so um it were to actually understand um the dependency stuff 06:55.560 --> 06:59.560 and would actually calculate on its own what it needs to pull in and things like that. The basic 06:59.560 --> 07:06.280 ideas were hashed out in 2009 that's actually 15 years ago right so uh you know when when they 07:06.280 --> 07:10.680 fastened people suggested I should do keynote here they already suggested to me 14 years and then 07:10.680 --> 07:15.560 every never have a question that until earlier this week when I actually sat down put the slides 07:15.640 --> 07:20.120 together figure it out it's not actually 14 years it's 15 years and it's kind of dumb because 07:20.120 --> 07:25.240 15 years would have been so much rounder um to put on this slide so yeah I mean then again on 2014 07:25.240 --> 07:31.800 we did the uh sorry in 2001 the later we did uh the first release so it's also 14 years it's not really 07:31.800 --> 07:36.680 wrong but uh 15 years it's kind of nicer. Anyway so we figured it all out like what we wanted to do 07:36.680 --> 07:41.480 like the basics um uh flying back from London's Plama's Conference with my colleague Kaisivas 07:42.440 --> 07:47.560 and yeah we wanted to like properly at least an all of you like doing a proper open source 07:47.560 --> 07:53.560 project like out in the open no copyright assignment make it LGPL and things like that so yeah first 07:53.560 --> 07:59.720 commit 2009 first release one year later um yeah and from the start out it was actually supposed to 07:59.720 --> 08:04.680 be more than an in-it system because we figured out like more than the actual P81 because we figured 08:04.680 --> 08:09.960 out like yeah one of solve boot then solve boot and boot is not just one process it's a it's a it's a 08:10.040 --> 08:13.720 serious of process that need to happen you need to mount stuff you need to file system check stuff you 08:13.720 --> 08:20.200 need to do all kinds of things so right from the beginning it was more than one binary so uh we 08:20.200 --> 08:25.480 figured like yeah let's see like we always try to do our homework right like uh you know people 08:25.480 --> 08:32.280 complain to us that we did like NIH like not demanded here syndrome stuff and uh sure to some 08:32.280 --> 08:37.560 degree everyone I guess is victim to this but uh I don't know like I I really tried to do my homework 08:37.880 --> 08:41.880 and every time we touch something to figure out what is the status quo what do the others people 08:41.880 --> 08:47.320 actually do before we do anything and we want to have good reasons why we do it differently um so yeah I 08:47.320 --> 08:51.560 guess the influence primary inference was it's in five in an upstart because that was what the 08:51.560 --> 08:56.280 distribution's back then we're actually using but uh much more interesting we found uh it was Apple's 08:56.280 --> 09:02.520 launchty that started in 2005 it had in particular one feature which we loved very much with was the 09:02.600 --> 09:10.120 socket activation concept um that basically is um the same like it actually existed and non apple 09:11.160 --> 09:15.320 unix before the two in something called i&d but Apple kind of pushed it to the limits and that 09:15.320 --> 09:21.320 was a really nice design because it kind of got rid to some degree from explicit dependency configuration 09:21.320 --> 09:25.480 anyway I'd like talking about this too much it's probably too technical I know this is a keynote 09:25.480 --> 09:30.200 so I probably shouldn't make it super duper technical but I just wanted to mention this one features 09:30.280 --> 09:35.640 that um we're actually like a lot about launchty there were other influences like uh Solaris SMF 09:35.640 --> 09:40.840 but the way I'm talking a lot if anyone has any questions um absolutely do interrupt me um I 09:40.840 --> 09:46.040 this probably gonna be difficult making this like a fully interactive talk where you you guys ask 09:46.040 --> 09:51.240 question I answer but at least I want to try so if anyone has a good question to us just show up 09:51.240 --> 09:57.080 and maybe we can answer that first um anyway so Solaris SMF was a major influence because it has 09:57.160 --> 10:01.720 all this enterprisey stuff and we wanted to go for enterprise two um like both Kai and I 10:01.720 --> 10:07.960 were working for rat hats so we wanted to uh yeah that was our focus um and we added a couple 10:07.960 --> 10:14.680 of original thoughts but um just a couple of them I mean I wouldn't claim that the concepts um 10:14.680 --> 10:21.800 that we um it's systemty is built from our purely ours they are not we looked at what is what's 10:21.880 --> 10:27.320 there and then tried to do maybe a little bit better at least in our eyes there's one major 10:27.320 --> 10:32.280 influence of credit which is Unix um I don't know what Unix really is like I think it's a religion 10:32.280 --> 10:37.880 to some to some is an operating system um Linux is of course not Unix it doesn't really 10:37.880 --> 10:42.840 share like at least not source code with it or anything typically not at least not in major ways 10:43.400 --> 10:50.360 it's only I a philosophy that it shares um one thing I'd like to point out is that most of 10:50.440 --> 10:55.160 the Unix systems that exists today like the BSDs in particular they generally have the Unified 10:55.160 --> 11:00.040 repository is kernel and use the space in one right um so you you get basically from the same 11:00.040 --> 11:04.840 source and with the same release cycles you use the space in your like the basic use the space 11:04.840 --> 11:09.320 and the and the kernel which is systematically different from how we do it on Linux right they're 11:09.320 --> 11:12.680 now in Linux everything's split up right like not even the kernel people and the lipsy people 11:12.680 --> 11:17.720 can really agree on everything um they're two separate repositories and if you build a distribution 11:17.800 --> 11:21.720 you need to pull from all these repositories and not just that they have different repositories 11:21.720 --> 11:26.600 they have completely different philosophies different licenses um different people who think 11:26.600 --> 11:31.480 differently that have different priorities I think it's uh it's a strengths of Linux that is 11:31.480 --> 11:35.160 it's that way because it's way more distributed it's also weakness of Linux because it basically 11:35.160 --> 11:40.680 means it's completely chaos in a way um but it is how it is um now in system D if it's used 11:40.680 --> 11:44.440 Linux in system D it's kind of it's kind of in the middle actually that thumb wire I mean we won't 11:44.520 --> 11:48.520 put the kernel in system D in the same tree but at least many of the basic building blocks that 11:48.520 --> 11:53.080 you need is like a logger um and a service manager and all of that kind of stuff are in the same 11:53.080 --> 12:01.000 repository so if you ask me a system D Unix on that level it's probably more Unix than Linux 12:01.000 --> 12:07.880 ever was before um is this truly Unix? No, absolutely not um but closer to Unix yeah 12:08.200 --> 12:15.880 um and then what the heck is Unix like people like the first thing that Unix comes 12:17.080 --> 12:21.000 to mind there is everything's a file I don't know my printer is not a file 12:22.040 --> 12:27.800 I find it a very very weird concept it's like somebody studied object orientation and then 12:27.800 --> 12:32.440 didn't understand it or something that they think that a printer could be a file but okay 12:33.400 --> 12:38.360 um then my questions of course like shouldn't running services be files too if every 12:38.360 --> 12:43.400 thing's a file system five and it's things no because there is no it's not exposed to the 12:43.400 --> 12:47.960 file system of a service is running right like there's no way how you configure that out you can 12:47.960 --> 12:54.600 maybe find a pit file and then make guesses or something um but in and system D actually yeah 12:54.600 --> 12:58.840 kind of is a lot that way because everything the system you manage is the service manager manages 12:58.920 --> 13:03.000 is actually exposed as a C group you know and C group are these kernel concepts that actually 13:03.000 --> 13:07.320 exposed in the file system and C group FS and they're always mounted and slashed the somewhere 13:07.320 --> 13:12.200 so in a way um yeah running services and system be like the inherent objects that we like the 13:12.200 --> 13:18.680 primary objects that we manage are yeah files if you say well well directories um but it's kind of 13:18.680 --> 13:23.640 same thing like I mean according to this weird object oriented approach of Unix but directory 13:23.720 --> 13:29.080 definitely is file right like even if a printer is weird anyway so uh is this Unix? 13:30.040 --> 13:34.920 I mean uh in a way you could say system these more Unix then system five in it is hence 13:34.920 --> 13:39.320 because we adopted the averaging as a file approach there but of course I'm not actually 13:39.320 --> 13:44.520 climbing that so it's system the Unix code wise legally no we don't inherit any code 13:44.520 --> 13:49.800 into like from Unix and the system D organization wise maybe real little bit closer actually 13:49.960 --> 13:55.880 to how the B is these managerly things but just a little bit um philosophically I guess obviously 13:56.440 --> 14:03.080 Unix inspired operating system and hence because we are Linux um yeah same thing 14:03.080 --> 14:08.280 same as well does it actually matters though I don't really think it does very much I mean it's 14:08.280 --> 14:13.720 so one thing that always comes to like the criticism of system is always comes up is this Unix thing and 14:13.720 --> 14:17.880 to me it doesn't really matter you know like these slides we're really about like pulling that 14:17.960 --> 14:25.960 apart like how much sense of nonsense that actually is but it's simply like in 1996 in 1969 14:25.960 --> 14:34.360 when Unix was kind of created um you know operating system designed and end that that way right 14:34.360 --> 14:40.040 like so it's a major influence but maybe other influences matter too like that came afterwards 14:40.040 --> 14:44.120 that might be actually more interesting so um I don't know so is it Unix? 14:45.080 --> 14:53.160 Maybe something in ways and otherwise probably not so um any questions to this point otherwise we'll 14:53.160 --> 15:00.520 continue with history there um so we talked about how baby could got created and the influences 15:00.520 --> 15:05.560 let's now see what happened next it became the default in the first distribution back in 2011 that's 15:05.560 --> 15:10.040 like 13 years ago now in fedora there was a first distribution that was a big win for us 15:10.680 --> 15:14.520 because for the first time um people would actually use our stuff by default and that was definitely 15:14.520 --> 15:19.400 always our goal to make something that is not just a niche but it's actually something that is mainstream 15:19.400 --> 15:26.600 can be used um open Susan and Arch Linux um follow Charlie after um year so um when they 15:26.600 --> 15:33.080 made it the default then rail like the big uh commercial distributions followed in 2014 um so that was 15:33.080 --> 15:38.360 uh when it started like the whole world started running on um uh system D um debut in Ubuntu 15:38.440 --> 15:44.840 and followed one year later there was probably the most uh complex win but by then um it's like 15:44.840 --> 15:50.520 all the big distributions uh as supported it um like the the commercial ones they all made it 15:50.520 --> 15:55.960 the default and the and yeah even in the ones that didn't make it the default it's at least available 15:55.960 --> 16:01.960 so yeah I guess that happened like in retrospect relatively quickly right like given that 2009 was the 16:03.000 --> 16:05.000 the um 16:09.240 --> 16:11.240 mall 16:13.080 --> 16:17.080 okay I think this which actually moves from time to time and it's own it's very confusing 16:19.080 --> 16:25.320 2019 we have a logo like um to be as banner designed a logo for us we actually have a brand website 16:25.320 --> 16:30.360 where it can actually download the logo and actually get told what system D Green actually is 16:30.360 --> 16:35.640 because this thing here that there is a system D Green um it's uh yeah I don't know 16:35.800 --> 16:39.160 think that Pantone has registered that color for us yet but it's it's what it is 16:41.160 --> 16:47.240 we even started our conference in 2015 to 2016 we had a system D.Conf it's kind of funny name 16:47.240 --> 16:50.840 you know because that's also the name of the configuration file of system D of course 16:52.040 --> 16:57.720 this later morphed into all systems go since 2017 which is kind of you know it's still the same 16:57.720 --> 17:02.040 conference but it's a wider focus right like because we figured out system D doesn't exist in a 17:02.120 --> 17:09.240 vacuum there are many projects around it that are equally relevant to building a basic OS so 17:09.240 --> 17:14.120 we decided to to widen the the focus and invite those people to and it's still going strong today 17:14.840 --> 17:20.040 in fact yeah this year it's gonna happen too like you should totally go there if you're interested 17:20.040 --> 17:27.160 in low level operating system kind of stuff use a space only though um so much about the history 17:27.720 --> 17:34.360 um let's see where are we today so I mentioned all major distributions use it most of them 17:34.360 --> 17:40.280 like in Picca the commercial ones already fall to it and this basically means yeah the world runs 17:40.280 --> 17:46.680 on it like Linux runs the world and system D2 a large degree too um so basically everything that 17:46.680 --> 17:51.800 is an Android probably runs system being away um it has a vibrant community I would claim like 17:51.880 --> 17:57.000 they're six core maintainers should do like reviews primarily they're 60 people of 17:57.000 --> 18:03.160 chromatic ss um two thousand six hundred contributors over the years um so I think that is probably 18:03.160 --> 18:08.600 one of the larger open source projects we have a six months primary release cycle I think that's 18:08.600 --> 18:12.840 actually not that great we should do it be doing better it's very hard to doing proper release 18:12.840 --> 18:17.160 management so for a large project and they're a regular minor style really the two that the 18:17.240 --> 18:24.840 distributions um except we we got the nations by SPI and grants by the STF so that we actually 18:24.840 --> 18:30.200 have a little bit of funding we used it for a couple of things where basically the core developers 18:30.200 --> 18:34.520 personal interest is not so much in these areas like for example we paid them to do our 18:34.520 --> 18:41.240 websites like to to rework our main page logic and things like that so the the if you go to the 18:41.240 --> 18:44.840 web that had now has this drop down box in the top right for example this is like this is 18:44.840 --> 18:48.680 super exciting to have but also not something that the core system to developers ever wanted to 18:48.680 --> 18:53.720 work on so we used our the grants that we got in the and the money that we got to native for that 18:55.320 --> 18:59.320 so 19:00.840 --> 19:04.760 so the question was regarding adoption in the embedded so I personally have person not embedded embedded 19:04.760 --> 19:09.400 guy but I mean it depends like what kind of embedded you know there's the super tiny embedded people 19:09.400 --> 19:14.600 who kind of from likely microcontrollers they don't care right but I think bigger embedded devices 19:14.680 --> 19:20.200 where you actually have a proper um uh system like they tend to all use that right like because 19:20.760 --> 19:24.680 you know like something that is important to us with system is that we try to make everything 19:24.680 --> 19:29.800 generic and we also do care right like this doesn't mean like if you if we really don't have any 19:29.800 --> 19:35.960 memory and like if you're too limited then maybe systems not this thing but I'm pretty sure that yeah I 19:35.960 --> 19:44.120 have slides later about size and things like that let's talk about that then um so what is system 19:44.920 --> 19:50.200 it's a suite of uh 150 separate binaries right like so uh we sometimes got this compliance 19:50.200 --> 19:55.480 a system with monolithic or something like this I don't know what it's monolithic about 150 separate 19:55.480 --> 20:00.440 binaries it's also quite modular right like uh it doesn't mean that every thing is modular 20:00.440 --> 20:05.080 that you can just take any part of it and use it in any other context but it means that uh to us it 20:05.080 --> 20:11.720 means that uh you know it's a suite of several different things and there's one central component 20:11.800 --> 20:16.440 that you can't really turn off which keeps everything together it's a glue in the metal but the the 20:16.440 --> 20:21.160 other stuff around it you can turn over a lot of it not all of it but a lot of it right like so uh for 20:21.160 --> 20:27.560 us that's uh actually quite modular um it's written almost entirely in sea I mean there are some 20:27.560 --> 20:33.480 exceptions that some stuff in uh pious and very experimented and rust a little bit but um it's ultimately 20:33.560 --> 20:41.640 a sea project um it is the common core of what a Linux based who has um needs at least to our 20:41.640 --> 20:46.840 point of view um like as mentioned we are like six people in the court team so we have uh not all 20:46.840 --> 20:52.840 this exact same uh view and things um but uh yeah it's still I think that that's something that we do 20:52.840 --> 20:59.960 agree on that yeah it's a it's a common core of uh what operating systems needs um and uh it covers 21:00.040 --> 21:05.320 a lot of basic west functionality like log and d for examples about user session management 21:05.320 --> 21:10.840 resolves these about DNS management like resolving network d about an basic network management 21:10.840 --> 21:15.960 and time sink d about clock and a home d about home management so it's like yeah there's lots of 21:15.960 --> 21:21.320 different components a lot of different buyers that take part of uh different things um as mentioned 21:21.320 --> 21:25.800 because it's modular and that our everyone of these components has found adoption all the distributions 21:26.120 --> 21:30.280 what I find particularly very interesting though is that all the distributions usually pick different 21:30.280 --> 21:35.720 components they adopt uh the ones that they don't um because I would normally adopt that they 21:35.720 --> 21:40.760 would kind of always go for kind of the same set of things that every one adopts and then the other 21:40.760 --> 21:46.680 parts that they don't but interestingly it's uh it's a way more diverse than that so yeah 21:47.400 --> 21:53.560 and this is later was talking about about the footprint um uh you know if you have 150 modules about this 21:54.200 --> 22:00.040 um uh let's talk about sizes about yeah how much dependency does it pull in how much code is it 22:00.040 --> 22:05.720 actually in sorry sorry slides and how much um is it going to be on disk if you actually run it 22:05.720 --> 22:12.440 so it's one a 690 okay um lines of code just to compare this like WPI supplicant you know that's a 22:12.440 --> 22:18.680 user space part of your Wi-Fi stack basically um it has like 460 k these days it used to be always 22:18.680 --> 22:23.160 my primary example of anyone asked me like how big a system to hear something I would always point 22:23.240 --> 22:28.200 to that because the the user space part of your Wi-Fi stack used to actually grow at the same 22:28.200 --> 22:32.200 rate as we did and was the same size and I said yeah it doesn't mean it cannot be that large 22:32.200 --> 22:38.840 if you just the user space side of your Wi-Fi stack um it has the same size um in the last three 22:38.840 --> 22:44.600 years of something we actually apparently accelerated so there's actually difference now um so uh let's 22:44.600 --> 22:52.120 that's actually three uh yeah 50% on top of what WPI supplicant brings you but still to compare this 22:52.200 --> 22:59.880 it's like half wood blipsy is so um yeah is that the lot I don't know is it a little I don't know 22:59.880 --> 23:05.960 it's it's it's not it's a lot even though we have 150 components that I think people might think 23:05.960 --> 23:12.280 it is on fedora a full blown install of just system D like fedora being there's just just generic 23:12.280 --> 23:16.600 distribution the tends to enable everything right like because as mentioned it's very modular 23:16.760 --> 23:21.640 but in system in fedora basically all the the modules that you can turn on are turned on 23:21.640 --> 23:25.640 so if you if you have the full blown install that's like 36 megabytes 23:26.680 --> 23:31.560 for comparison bash alone already takes eight megabytes right so is a lot I don't know it's a lot 23:31.560 --> 23:38.040 more than bash sure but uh it's also you know um when people compare like used to compare this 23:38.040 --> 23:43.880 to system 5 in it or something you know um system 5 in it wouldn't run without a shell right 23:44.600 --> 23:48.520 because all the in it scripts are our shell right like so it's a shell alone we're already 23:49.240 --> 23:54.200 eight megabytes then it's not that bad I think so is a big small I don't know it's 23:54.200 --> 23:59.800 certainly um okay uh what's also very interesting is of course looking at dependencies like what 23:59.800 --> 24:03.960 else does it pull in I kind of already indicated that with system 5 in it and it um something 24:03.960 --> 24:09.080 that we do in system D this there's heavily is actually that we pull in most of our dependencies like 24:09.160 --> 24:13.960 generally well very careful with dependencies because we know they when we add some library 24:13.960 --> 24:19.160 as a dependency system D then this will hurt everyone he uses Linux right like because they will 24:19.160 --> 24:24.920 come a dependency for them so um we always very conservative we had a very high like we need to 24:24.920 --> 24:30.200 really have strong reasons to pull something in um recently like two years ago something we switched 24:30.200 --> 24:36.360 over all of the dependencies that are not necessarily um and necessary to run the basic system 24:36.440 --> 24:39.960 into deal open one deal open for those who don't know is like this thing where you have a 24:39.960 --> 24:45.480 shell library but you don't actually uh link against a shell library but you just delay that until 24:45.480 --> 24:50.200 the moment you actually really need it and then you load it so what's the benefit of this it makes 24:50.200 --> 24:54.520 dependency weak right like because until that moment where you actually actually really can't do 24:54.520 --> 24:59.400 without that little library you're not going to pull it in um this is great for example let's say 24:59.400 --> 25:04.920 you do uh full disk encryption and you want to do that against your fido key you know many people do this 25:05.000 --> 25:09.400 but other people probably don't right like even from the people who use disk encryption not 25:09.400 --> 25:14.840 everybody wants to link their stuff against the fido stack so that's a deal open like just as an 25:14.840 --> 25:19.480 example a dependency for us so the basic means if you have the fido stack installed and system 25:19.480 --> 25:23.720 being installed it's just gonna combine itself to something that's really good if you don't have 25:23.720 --> 25:28.760 the fido stack stuff you can still use the disk encryption like by buying a bound to something else 25:29.160 --> 25:38.520 um in fact we we push the deal open saying so far that um there are nowadays um only three 25:38.520 --> 25:42.440 really required dependencies as glipsy lip mount and lip cap the other ones that aren't this 25:42.440 --> 25:46.280 either are like they are built-time optional right like it's people who actually want to 25:46.280 --> 25:50.120 as the Linux can use as a Linux but uh I think that's actually kind of nice right like that we 25:50.120 --> 25:55.880 don't have like uh like uh that much of a dependency footprint um yeah and we kind of thinking about 25:55.960 --> 26:00.360 getting rid of lip cap too actually um the deal open saying it's actually kind of interesting 26:00.360 --> 26:05.960 for another reason um uh you know this thing like uh like one was a two years ago something when 26:05.960 --> 26:12.120 the exact vulnerability I kind of hope that every one of you heard about this um system he was kind 26:12.120 --> 26:18.360 of indirectly involved in that because the people like because the attack that was done um was done 26:18.520 --> 26:26.040 on XZ but the attack surface was SSH and the reason why that worked is because system the like 26:26.040 --> 26:33.240 many some of the distributions linked SSHD against lip system D which pulled in lip XZ so um 26:33.240 --> 26:39.000 back then this was not a deal open dependency that's why this why this happened but um uh so system 26:39.000 --> 26:43.560 D was not it fault for like it wasn't not the thing there was a tact it was not involved in the attack 26:43.560 --> 26:50.920 in any way it was however was um in this case the the conduit like the reason why these two 26:50.920 --> 26:56.840 things ended up in the same process so um we saw it okay not our fault but also maybe we can do 26:56.840 --> 27:00.840 something about it and this is why we started pushing for a deal open so hard because it basically 27:00.840 --> 27:05.800 means until that point where XZ is actually needed will not gonna load it right so it's not gonna 27:05.800 --> 27:12.360 end up in the memory of SSHD because there's nothing in SSHD that uh would indirectly ask us to do this 27:12.440 --> 27:19.400 so um yeah deal open as both a footprint thing and a security thing actually so executive summary 27:19.400 --> 27:26.040 of all of this uh it's not that big it's not that tiny either um but I mean it does a lot so uh yeah 27:26.040 --> 27:29.960 I think they're good reasons it's good enough for inclusion in inner dees you know inner dees are 27:29.960 --> 27:34.760 these things that Linux computers need during early boot up to to to set up basic stuff 27:34.760 --> 27:38.600 they nowadays need to do a lot of stuff right like because you people use full disk encryption 27:38.600 --> 27:43.320 was phyto as I just meant like with your secret keys so they actually need to do all this right 27:43.320 --> 27:47.960 like they need to um start up find all the devices uh that are involved for your disk that they need 27:47.960 --> 27:52.120 for the disk and they need to find the phyto stick and all these kind of stuff um so that's actually 27:52.120 --> 27:57.160 yeah and then it can be arbitrarily complex um these days if you then think about complex storage 27:57.160 --> 28:01.160 but uh yeah so having system d and then it already makes actually ton of sense because it's 28:01.160 --> 28:06.120 so complex these days um system d is not gonna hurt you very much um it's all the like at least 28:06.760 --> 28:12.120 head-based distributions um are all on that and I understand your boot is gonna uh use that for 28:12.120 --> 28:15.560 inner dees as well um and it's good enough for containers right like you can you can run 28:15.560 --> 28:19.960 system d inside of a container if you want uh it's not gonna blow things up for you because as 28:19.960 --> 28:24.760 mentioned neither the size footprint is that big um and in come back containers die and that's not 28:24.760 --> 28:33.160 not the dependency trees so talking about um did this answer your question by the way um good um 28:33.320 --> 28:37.640 so uh uh it's the next question of where there's what actually belongs in system d because people 28:37.640 --> 28:44.120 always say oh my god scope creep and it's true like there is some scope creep there um but uh 28:44.120 --> 28:49.480 let's make clear what actually we think belongs in there and what doesn't right so uh we have a 28:49.480 --> 28:53.640 couple of requirements that we make right like uh I mean besides the fact that someone needs some 28:53.640 --> 28:58.920 maintain that stuff um it needs to be very very generic right like it it's not supposed to solve 28:59.000 --> 29:05.560 a problem for one user it needs to solve a problem for a lot of users and if it like most of 29:05.560 --> 29:10.520 users basically otherwise it doesn't doesn't really belong in system d it needs to be foundational right 29:10.520 --> 29:14.840 like it's never going to be the thing that the UI that that um actually interface with users so much 29:14.840 --> 29:20.520 but needs to be something that is relatively low level foundational it needs to be common right 29:20.520 --> 29:24.840 uh it needs to be something that it's not enough to be generic it also needs to be something that 29:24.840 --> 29:29.160 actually uh would be used by a lot of people it needs to have a future right like we're not going to 29:29.160 --> 29:33.880 add um support for the legacy technologies like if we already know at some point that some things 29:33.880 --> 29:38.120 not going to be the future we're not that interested in it it needs to be a reason to be clean right 29:38.120 --> 29:43.640 like we don't want to cut corners that's always the thing you know that's like you can deliver 29:43.640 --> 29:48.680 products quickly if you cut a lot of corners um that's not where we want to be with system d we want 29:48.680 --> 29:54.200 to do it uh probably and actually do somewhat clean by our standards and it needs to follow a common 29:54.280 --> 30:01.480 style we talk a lot of the later about the concepts that we keep on reusing and system d about 30:01.480 --> 30:09.960 configuration and things like this so uh yeah um do if people ask me personally for example um 30:09.960 --> 30:14.120 does this thing belong in system d this is what I want what answer to them like does it actually 30:14.120 --> 30:19.240 check all these boxes and if it doesn't know it's sparsion b system d but it should be something else 30:19.240 --> 30:23.880 if something does check all these boxes it still doesn't mean that it needs to be in system 30:24.600 --> 30:28.760 can still be maintained elsewhere that's not the problem but these other commands so 30:29.640 --> 30:35.880 next thing talking about concepts you know what what a system d um to us um beyond like this one 30:35.880 --> 30:41.720 implementation of a service manager and it's you know we didn't ever wrote them all down 30:41.720 --> 30:45.320 I mean you can distill them from our man pages and things like that in front of specifications we've 30:45.320 --> 30:52.520 wrote um so I can't um give you the the the whole list but I can give you examples like about 30:52.840 --> 30:58.040 concepts that we try to push with system d and that our core at all the stuff that we design 30:58.040 --> 31:03.000 inside of system d for example one of the concept that we base everything on it that there's a 31:03.000 --> 31:08.040 clear separation of what Etsy run and user are right um and we we build a lot of stuff on this right 31:08.040 --> 31:13.480 like so that we clearly say Etsy for configuration run is for for runtime stuff um that is 31:13.480 --> 31:18.040 not persistent and so let's use her as for the stuff that comes from the vendor right um 31:18.120 --> 31:23.400 this is a separation that was not traditionally followed to clearly on Linux right um it is nowadays 31:23.400 --> 31:28.520 and many distributions because we have user merch if you know what that is um these days but it's uh yeah 31:28.520 --> 31:34.040 everything in system d is designed that this um uh separation exists and we'll see like 31:34.040 --> 31:38.840 I have an example far as a down why this matters or a hematic user is a kind of the same 31:38.840 --> 31:45.320 same hematic user is like a concept that we we are trying to push with system d is that slash user alone 31:45.400 --> 31:50.280 is sufficient um like it has a sufficient description of the system that can be booted 31:51.160 --> 31:55.800 so that you can get rid of Etsy and var and everything else and the system will still boot up and 31:55.800 --> 31:59.480 create what it's necessary this is really nice property for us because basically means yeah 31:59.480 --> 32:03.160 you can package up the whole slash user drop it on another machine will boot up will 32:03.160 --> 32:07.480 instantiate everything and just work but yeah I don't want to really talk about these concepts 32:07.480 --> 32:12.200 in particular so much I just want to give an example about like because they they they kind of 32:12.280 --> 32:17.960 spill into everything else we do because um like it means like how configuration management needs to work 32:17.960 --> 32:22.360 like for example we cannot rely that a configuration file is actually existing we need to find like 32:22.360 --> 32:26.760 automatically if we see that some configuration file isn't there come up with same default that we can 32:26.760 --> 32:32.200 use instead um more specifically there for example I this thing that we always have in system 32:32.200 --> 32:37.560 the over and over again which is like this merging of drop in configuration files right like uh 32:37.640 --> 32:41.720 for example there's one component called temp files it's uh it's actually a little bit misnamed 32:41.720 --> 32:46.520 because it's not really about temporary files it's nowadays about any kind of runtime file that 32:46.520 --> 32:52.440 needs to be created at boot under circumstances um and it's one of many tools and system that 32:52.440 --> 32:58.120 expose this behavior that you can drop the configuration for them both an Etsy like an all three 32:58.120 --> 33:03.240 of Etsy and user lip and it's like run and they will be merged together right like so that you 33:03.240 --> 33:07.400 have one place where the administrator locally can put these files one place where the 33:07.480 --> 33:13.240 OS vendor can put these files and one place where local programs that need to to install them locally 33:13.240 --> 33:18.120 for a short time can place them and uh there's very clear way how you how they can override each other 33:18.840 --> 33:22.840 which one takes precedence of each other how you can master them and a couple of things like this. 33:22.840 --> 33:29.240 So for us it's the rule that any component as a system needs to follow this behavior and it's 33:29.240 --> 33:34.680 the uniformly um do this it's actually by the way it really nice concept that should find adoption 33:34.760 --> 33:41.080 and does find adoption um beyond system D uh itself. One more broader concept as well like for 33:41.080 --> 33:47.000 example system we very clearly say everything we do needs to have declarative um uh behavior right 33:47.000 --> 33:53.160 like you just write where you want to go um you don't write down code right like so for example 33:53.160 --> 33:57.560 in system D we generally say boot should not involve running a shell script because shell 33:57.560 --> 34:02.120 scripts are inherently imperative right um and that's that's that's not a way how you want to 34:02.120 --> 34:07.560 configure stuff we want to one or or even declare stuff we want that's that yeah it should be 34:07.560 --> 34:14.600 a statelessly declared and that goes into everything we do so um there are more concepts that we 34:14.600 --> 34:21.960 always have but having um these concepts in place permits us to do other stuff that is very easy for us 34:21.960 --> 34:26.920 that we're very hard to do before this like for example here I give one thing and system D for for 34:26.920 --> 34:31.240 for services that run the system we have this uh these options called protect home and protect 34:31.480 --> 34:39.480 system um which um are security knobs that that set up a sandbox for that service and uh by 34:39.480 --> 34:46.200 having made very clear that stuff has to be an Etsy run and user and that flash user is where 34:46.200 --> 34:51.880 the whole operating system puts should the vendor files we can just implement a sandbox very easily 34:51.880 --> 34:57.320 that isn't like like the class for example that there shall be no modifications made to the operating 34:57.400 --> 35:02.760 system itself or that even says there should be no modification that be made to Etsy like to 35:02.760 --> 35:07.320 the configuration right but very very clearly saying that these um these are three different things 35:07.320 --> 35:12.280 and they should be followed through and there should be nothing else that um I collide with these rules 35:12.280 --> 35:17.560 but we can have these high level um knobs and they have fully effect and other things that 35:17.560 --> 35:23.640 system D is actually standards you know we we often try to set standards by writing down specifications 35:23.720 --> 35:31.720 of uh of uh in a generic way how we do things um and we consume a lot of standards um so um like for 35:31.720 --> 35:37.720 example and we have Etsy OS S release the same like um pretty much all the distributions and even 35:37.720 --> 35:41.960 Solaris and PSDs adopted these days basically a little file that just tells you which operating 35:41.960 --> 35:47.320 system you're running was a couple of uh like metadata fields um yeah we've wrote this down 35:47.320 --> 35:52.280 wrote this specification wrote it like a thing like that all this evolution adopted then even the other 35:52.360 --> 35:57.480 uniques aside I'm okay it's a good thing let's do this so um we even create a new website for this 35:57.480 --> 36:03.480 is called the UAPI group where we have our place where there's so many people and people like close to us 36:03.480 --> 36:09.880 and other people um are invited to put these little specs right like that are somewhat informal right 36:09.880 --> 36:14.760 we don't do like complex standard processes but uh that it's very clear place to put these 36:14.760 --> 36:19.800 documentation so that people know how these things work um like he just has a random example there's 36:19.800 --> 36:25.080 a DDI spec for just cover up the discriminates it's a spec that we wrote but it's also 36:25.080 --> 36:33.720 imports like it's based on the UFI GPT like the good partition tail so yeah so my much 36:33.720 --> 36:41.480 show where we are um so now I want to talk about where the future is going I basically put four 36:41.480 --> 36:46.920 topics out of my slides I got like 50 minutes left so maybe we'll speed this up it's fine that like 36:47.560 --> 36:53.640 um I have like the off all four of these topics I have a lot of slides but it's not really 36:53.640 --> 36:58.760 my intention to cover them all um but at least I want to touch every one of these goals uh at least 36:58.760 --> 37:05.400 to some point so um I see four goals and challenges for the future system the way we want to take 37:05.400 --> 37:11.720 it that's my point of view I'm just one of the quarantined as a system D um others and in the team 37:11.720 --> 37:17.400 have slightly different opinions probably not widely different but let's just say these four 37:17.400 --> 37:23.560 on my personal goals and challenges and uh where I would take system D uh one of the first things 37:23.560 --> 37:31.000 is I want to do have boot and system integrity addressed um so boot and system D integrity um like 37:31.000 --> 37:37.000 it's basically this this cryptographic way how um the boot process of modern operating system tends 37:37.080 --> 37:45.640 to be protected so um that backdoring it is this is um harder um not impossible harder so all big oasis 37:45.640 --> 37:51.480 all big commercial oasis um have solfs at a long time ago sometimes in a long time sometimes 37:51.480 --> 37:58.040 a middle-long time but yeah it's always there in generic uh Linux though it doesn't really exist at 37:58.040 --> 38:03.560 least none of the of the generic distributions of the big ones tend to have adopted this at least 38:03.560 --> 38:10.040 not body fault it's a very serious situation because i think it actually matters a lot um i don't 38:10.040 --> 38:15.080 really understand why i mean i have parsed off of the reason i can see because it's like it makes 38:15.080 --> 38:19.240 things more complex uh because you need to think about cryptography and measurements and all these 38:19.240 --> 38:24.440 kind of things and everybody knows this i think there are certain cultural issues um to some level 38:24.440 --> 38:30.760 um found it on on just thought i guess from the FSF like because they claim like one component 38:30.840 --> 38:35.960 that you need for for boot and system integrity is a TPM right and the FSF painted as like this 38:35.960 --> 38:40.200 terrible thing that is all about DRM even though it's complete bullshit it's not about a DRM you 38:40.200 --> 38:46.360 can't really use that for DRM but uh what do i know um FSF seems to know this better i think like 38:46.360 --> 38:51.720 they put even the website about this that is so full of wrongness it's it's it's it's it's it hurts 38:51.720 --> 38:55.640 anyway so there's a certain cultural issues because a certain players and an open source kind of 38:55.640 --> 39:00.520 painted this as a devil's work and that it takes away your computers i don't think it does that you know 39:00.680 --> 39:07.000 the way how TPMs are designed um actually are very much compatible with our goals um other 39:07.000 --> 39:13.080 things is like a package-based world makes this kind of stuff a lot harder than uh needs to be and 39:13.080 --> 39:21.880 we live in a package-based world all the distributions used packages by default um so uh um so 39:21.880 --> 39:26.200 let's talk a little bit about the means again it means uh locking down the system what you can 39:26.280 --> 39:32.680 run on the system at boot time and during runtime so um it could for example mean that uh only the 39:32.680 --> 39:38.520 code that u s uh vendor considered okay could be run which is i guess to some point what windows and 39:38.520 --> 39:46.840 all these other um big companies run their system um under so it basically uh would mean that uh 39:46.840 --> 39:52.600 yeah your district decides what's safe to run was not or the other policies that uh you decide 39:52.600 --> 39:57.880 on what that uh does right um or a combination of both right like this is probably why we actually 39:57.880 --> 40:02.760 want to go like for example that distribution such as devion they generally that i mean this is kind 40:02.760 --> 40:07.720 of that what they do right they give they the vet packages and save this is good software um and we 40:07.720 --> 40:11.400 had gone assign it cryptographically and that gives you the guarantee that this is the version that 40:11.400 --> 40:16.040 the devion people actually saw that was good and other distribution basically do the kind of same thing 40:16.040 --> 40:21.000 right so um yeah in a way the policy number one is kind of like that but you also think uh it 40:21.080 --> 40:28.120 should be more restrictive um uh so that you actually can decide what's actually okay why does this all 40:28.120 --> 40:32.840 matter um i think they like the the primary use cases about keeping attackers out of your system 40:32.840 --> 40:37.240 and uh basically if always have a well known state you can return to where you know there's not 40:37.240 --> 40:43.320 gonna be anyone inside there because you can prove it um the the key fundamental thing that it wants 40:43.320 --> 40:46.920 to take here is consistency you know that if you have a cell on the internet and somebody breaks in 40:47.560 --> 40:52.200 that you know how to get the person out of there because you can reset the cell to define state and you 40:52.200 --> 40:57.240 know yes they like because it's software they will get access to to systems they shouldn't be 40:57.240 --> 41:03.560 getting access to but there should always be a bit way a sane a clean way a clear way um how you 41:03.560 --> 41:07.720 get back to a system where the attack is not in there anymore and you can update the software in 41:07.720 --> 41:11.880 in a safe way in the safe state so that you have the cryptographic guarantee that everything's in order 41:12.760 --> 41:17.080 um so yeah and other words is so that you don't have to always leave with your laptop around 41:17.080 --> 41:21.480 your pillow because you need to be afraid that somebody um modifies the bootloader to really 41:21.480 --> 41:28.440 into this new system so yeah it's it's like about like yeah even though you can leave your hotel 41:28.440 --> 41:33.880 your laptop and your hotel room you can have some assurance that it's not gonna be be 41:34.040 --> 41:39.560 back toward when you come back um i'm gonna skip a little bit about these slides um 41:41.560 --> 41:47.640 a lot of them let's uh talk about the next go actually you know i did a talk early about something 41:47.640 --> 41:51.880 related to this um so that's i'm kind of happy with skipping these slides um and there's gonna 41:51.880 --> 41:56.440 mean another one i think tomorrow um but yeah let's talk about the next go and challenge for 41:56.440 --> 42:03.480 system d number two um i think we should think about repeating our IPc system you know when we 42:03.480 --> 42:09.000 built a basic user space we have all these demons that they need to talk to each other and right 42:09.000 --> 42:12.680 now the thing that system uses is debuts right that gives it the thing that's there and everybody 42:12.680 --> 42:17.960 has adopted that but uh i think we should maybe refer to that and go to something that we could 42:17.960 --> 42:22.760 that's called varlink um um yeah i mean you know i've paid it this house here to tell you 42:22.760 --> 42:26.680 that i have millions of reasons to do this i don't really want to talk about all of them because 42:26.680 --> 42:32.120 there's not it to be supposed to be a talk about that but i think um the problem that we have 42:32.120 --> 42:38.040 with divas these days with the IPc are so many um and there are so much better options that we 42:38.040 --> 42:43.160 yeah we should start the process at least the new stuff that we're adding is more varlink 42:43.160 --> 42:48.840 than divas even though divas are never going to go away um of all these features that i listed 42:48.920 --> 42:55.320 there that i'm not going to go through i want to um uh talk about one specific one which is uh um 42:56.200 --> 43:00.360 this one now processing IPc requests in one service instance for connection which i find is like 43:00.360 --> 43:06.280 a little bit of a game changer for people who who uh like if you know how unics this build this 43:06.280 --> 43:12.760 is kind of awesome so you know and divas if uh if a service um if you ride a divas service you kind of 43:12.760 --> 43:16.920 are forced to have an event loop and instead of that event loop you need to to process all the 43:17.000 --> 43:22.280 crests coming in from from all the different clients that you have um and this makes writing uh divas 43:22.280 --> 43:27.160 demons kind of hard right like uh people do it but it's not trivial um because you always need to do 43:27.160 --> 43:32.200 things that are synchronously you need to um uh yeah have an event loop then if you want to pass 43:32.200 --> 43:35.560 data around you always have to put that in like this little bit of memory then pass it around 43:35.560 --> 43:39.880 from money and land to another it's a little bit easier with more money and programming languages but still 43:40.840 --> 43:48.360 um uh in borrowing however like to give you an example you know and consider classic 43:48.360 --> 43:53.880 unics tools right you receive some input and SDN some command parameters on a kernel command 43:53.880 --> 43:59.480 on a command line of that program and then the output goes to to SDL it's the it's a basic building 43:59.480 --> 44:05.560 block like how shell pipelines work these days um modern unics tools added one thing to that they 44:05.640 --> 44:12.920 generally um output jacens these days if you want to um many um also read jacens input so suddenly 44:12.920 --> 44:18.200 I think this is a big jump right like because previously you had all this chaos like could be anything 44:18.200 --> 44:22.600 or it could be basically text that is your input yet no no no no structural understanding of 44:22.600 --> 44:27.720 anything that we are processing there nowadays uh because this like for example here the find 44:27.720 --> 44:32.440 mount is this utility from utility linux that shows you the mount table um has a jacens which many 44:32.520 --> 44:38.440 many tools have these jacens which is these days with borrowing we now extend this concept right 44:38.440 --> 44:43.480 by one more thing instead of just having SDN like the input to the tool and the output to the tool 44:43.480 --> 44:51.960 uh doing jacens we also have the command parameters also uh in jacens so that you um yeah have 44:51.960 --> 44:56.280 suddenly everything in jacens you have the input the output and the uh command in jacens if you do 44:56.280 --> 45:00.360 it like this right like if you take a classic unics tool like for example find mount I mean okay it's 45:00.440 --> 45:05.720 not a classic unics tool it's classic linux tool but anyway um if you have that um you can 45:05.720 --> 45:10.040 trivily add a rolling support to that that you actually instead of reading all the commands from a 45:10.040 --> 45:16.600 from the command line you alternatively also read it from the jacen input um then this is already 45:16.600 --> 45:22.840 enough uh to be considered a rolling IPC service and then you can uh uh this is a small addition right 45:22.840 --> 45:26.920 like you just also read the command line from there because uh this basically means you can take that 45:27.000 --> 45:34.840 program and bind it to an AF unics is stream socket and suddenly your thing has become a uh IPC service 45:34.840 --> 45:40.840 and that is awesome because basically means that the traditional um uh unics tools all become IPC 45:40.840 --> 45:45.160 service very trivily and we have so many of those so that but suddenly become IPC services so that's 45:45.160 --> 45:50.200 kind of awesome uh I don't have that meant time to that anymore so let's go to the next um challenge 45:50.360 --> 45:58.040 in future uh which is rust difficult thing uh see as it limits I mean it's not much it's not a 45:58.040 --> 46:03.480 big thing for us um uh uh uh uh uh uh the limits of seas because like if you actually look at the 46:03.480 --> 46:08.520 the security vulnerabilities they are generally not memory management related and they are not 46:08.520 --> 46:14.120 that many easier right like uh like in 2020 for if I couldn't find a single one in 2020 we had three 46:14.120 --> 46:18.200 but like the vulnerabilities that we generally have in system the more logic errors they're not 46:18.200 --> 46:24.440 not errors in memory management so for us it's not not that uh love that uh much of a pressing 46:24.440 --> 46:30.440 problem um I think it's still thing it needs to be um addressed but it's not like that it's fire 46:30.440 --> 46:35.080 burning out on a hands or something like this uh we do think that the future rust uh it speaks 46:35.080 --> 46:41.000 probably rust um we started a little bit with oxidation but it's uh it's complex right like uh because 46:41.000 --> 46:44.920 first of all the build systems were just a matter because we will we have this project it's all 46:45.560 --> 46:51.400 and builds 100 binaries and shared libraries and kind of thing and we need like we cannot move from 46:51.400 --> 46:58.680 from sea to rust in one day we need this complex um uh uh like a slow movement process so uh um 46:58.680 --> 47:03.400 yeah this supposedly is less of a problem now because me so I'm again some rust functionality it's not 47:03.400 --> 47:09.800 all beautiful but at least it's there uh but we have more problems like for example the primary 47:09.880 --> 47:14.680 one of the system is 150 binaries and they are we're sensitive to footprint and uh issues that 47:14.680 --> 47:18.920 it was what I had it on this earlier slides right and we are heavily relying on shared libraries that's 47:18.920 --> 47:25.400 how our our footprint is so small is because yeah system you reuse is most of the code um uh that 47:25.400 --> 47:31.400 that's that's kind of the key to making 150 binaries small so uh we have internal libraries we have 47:31.400 --> 47:38.760 external libraries um and we use deal open heavily right so um dynamic libraries and rust are not there 47:38.840 --> 47:45.400 and there appears to be not much movement in this area so uh that's a big problem for us right 47:45.400 --> 47:51.720 like because in rust it's more like even though they do support shared libraries in some way 47:51.720 --> 47:56.200 it's the culture is definitely around static linking but that's would not work for us because it 47:56.200 --> 48:00.840 basically would mean if we start heavily static linking everything um the footprint of system we would 48:00.840 --> 48:04.440 close for the roof um and then everybody would hate us because they couldn't build internal 48:05.400 --> 48:11.800 anything anymore so yeah for us um this is this matters you know for the kernel people rust is 48:11.800 --> 48:16.120 way easier right because the kernel is a fucking static binary it's not much more than that it's 48:16.120 --> 48:22.040 super simple in that regard right for us not gonna work this way we need shared libraries um uh 48:22.040 --> 48:26.440 I don't see any other way I simply don't um and I know that rust people would disagree and say 48:26.440 --> 48:32.520 everything is static binary and you can do siblings of whatever else but I don't see that um but yeah 48:34.520 --> 48:42.040 rust people please do something about this um and I mean we're having to play ball but uh I want 48:42.040 --> 48:47.000 to be the ones who who uh pioneers this is not the problem that we want to solve I think that 48:47.000 --> 48:53.640 rust has to solve it first for us um or maybe I don't know zix solves that problem first um there's 48:53.640 --> 48:59.880 a chance of some competition there um yeah the last thing is more about moving to image based stuff 48:59.960 --> 49:05.320 away from uh package based stuff that I think I mostly run a run out of time so I would rather 49:05.320 --> 49:10.680 spend my remaining few minutes how many I have in questions um then let's just say the last 49:10.680 --> 49:17.080 challenge that I have here is about image based oasis and leave it at that um yeah if anyone has a 49:17.720 --> 49:41.880 question there's a question somewhere in the middle so yeah so the question was regarding 49:41.960 --> 49:46.600 grab I understand like uh like what our goal is with replacing grab or something like this I don't 49:46.600 --> 49:52.360 know I have not used grab in years um it's like uh I don't know I'm not a believe in grab as you 49:52.360 --> 49:56.680 might guess um I think it's all there the remaining issues are political um I say you know 49:56.680 --> 50:00.520 grab does a lot more in system the um like it has files system drives and whatnot I think 50:00.520 --> 50:04.760 most of these things that it does are kind of a mistake about not knowing what you actually want 50:04.760 --> 50:09.720 to do and how to do it securely I think for the general distributions uh you can switch to 50:10.040 --> 50:16.360 boot all day like as long as if you focus as EFI and EFI only that's nothing missing um and I 50:16.360 --> 50:21.560 kind of it's also sense you know with uh the other stuff that we're doing like regarding boot um they 50:21.560 --> 50:26.920 have to go there that way anyway if they want to have a second boot uh uh signed measured boot 50:26.920 --> 50:32.120 thing anyway I don't think this really is that compatible with the way how grab works but we'll see 50:32.120 --> 50:36.760 about that but uh let's maybe do talk about that otherwise I don't think I have a much time do I have 50:36.920 --> 50:42.360 time for one more question quick comment if you're want to leave already please use the 50:42.360 --> 50:54.360 dose in the back of the auditorium um what are the plans to fix the issues with the 50:54.360 --> 51:01.800 resolve D I see myself constantly uh restarting system D resolve D so the machine can 51:02.280 --> 51:08.920 uh resolve but you're having issues with resolve D I don't know like um it works fine for me let's 51:08.920 --> 51:14.840 say that I mean I'm aware that you know um uh some people have something but they generally use like 51:14.840 --> 51:18.760 more as a fancier features of system of resolve D like D and S seconds things like that and that's 51:18.760 --> 51:25.080 flaky that's mostly flaky because D and SX is really hard and and and real life because service 51:25.160 --> 51:31.480 a shit uh but I don't know like sounds like you should file a bug or something um uh you know 51:31.480 --> 51:36.920 nothing is perfect but I to my knowledge reasonably just worked for most people okay I think 51:36.920 --> 51:41.800 we'll go time for one more question so I'm going to steal that one okay so uh system this is 51:41.800 --> 51:45.880 goal the security features like put a comment so you've mentioned some of them and I found 51:45.880 --> 51:50.440 them particularly useful recently because we essentially big your demand that we got told to install 51:50.520 --> 51:55.480 a policy mandated route kit on some of our systems effectively and thanks to system DRA able to 51:55.480 --> 51:59.880 be in the drop it's also able to really defang the bloody thing the thing is a lot of those features 51:59.880 --> 52:15.000 are really hard for people to follow so yeah the thing is my question as far as I those security 52:15.000 --> 52:20.120 features are quite complex there's the analyzing so on are you planning to make it easier for 52:20.280 --> 52:26.680 people to try to ease those features in well I mean we have tools I'm not sure if anyone's still 52:26.680 --> 52:31.800 listens but uh we have system D analyzing these things but it's to some point in the communication 52:31.800 --> 52:35.400 issued a documentation issue and that's how we feel.