I kind of have a feeling you all know why you're here, but just in case somebody in the room
is under 20 years old, Leonard has been quite a prolific contributor to a lot of open source
projects and chances are that you actually run at least one simply two pieces of his
software on your Linux distros, if you got their modern system, he's also one of the
overall quite few people who have been given the honor of having specific distributions created
explicitly not to include products, he has created. So he's going to talk about possibly
them up. So we're talking about possibly the most controversial, but I will also argue
the most interesting of the lot, namely system D, which is now 14 and Leonard will tell us a lot
about what happened, what possibly did not happen and whatever he wants to tell us from top of that.
That's a thing work, I think it does, right? So hi, I think this is the moment where all the
Devon people need to start their sit-in protests or something like this. I hear that sit-in
protests are the thing here, but yeah, oh they're apparently a single one showed up.
Louder, this doesn't work, yeah, and apparently you need to turn it on. So okay, let's see if this
works now. So what is system D again is my first slide to give you like bring everybody up to
speed what this all is about. System D is a suite of basic building blocks for building a Linux OS that
provides a system and serves manage that runs as P81 and start the rest of the system. This is
verbatim copied from the system D website and it's I think it's pretty much accurate. So from a
distant perspective this is all you need to know. This talk is about the last 14 years of
system D and in a way also the next 14 years of system D. I will start out a little bit with the
history, unlike how it came to be what it came to be and then which I find a lot more interesting
is I kind of want to give a perspective on what's coming next, like what's in there for the next
15 years and what we think system D is and what system D should become. So let's start first with
the history. So yeah, system D has various predecessors. The most important one I guess is system
five in it. It's really old, you know, I think the first commit, I mean it wasn't a commit back then
because we didn't have really version control systems so well back then. But let's say the first
trace of it that we could find of the implementation that was in use before a system D came
along of so 1992 that's a long time ago. It's based on a design from system five
unix which is even older from 1983. So this is really old stuff that came before. It's
interestingly still maintained so there are a couple of people that have run people and things
like that who maintain it. But yeah, it's old and this kind of like you notice it right like
because a little bit are and like cryptic in a way and limited. Then in 2006 I
canonical created something called upstart which was an inner system that was supposed to take its place.
It was very modern by the standards of 2006 and yeah, it was it found slow adoption and
went to of course where they started it and later lived on on rail but yeah.
Automally died in 2014 so just looked about eight years and I think we played a role in that I
guess. While a system five in it is kind of yeah I don't know it's it's a design from 983
as you can indicate it but so the question is like of course if upstart was in using why didn't we
all stick with upstart. I think that deserves an answer. From eye-opest perspective this upstart
seeing didn't really solve the problem that we saw that a service manager in its system should actually
solve a meaning like it it worked that way that you tilt a system that when that happens you do this
when that happened you do this. The basically meant that somebody needed to actually sit down like an
administrator develop a type who would actually figure all of the things that can happen on the
system and then glue these events and these actions together and then this is how the system would
be booted up. We saw that this manual configuration of the action like the event and the action thing
that's that's that's to manual. It shouldn't be that way. Our thinking was you should just
specify the goal and the computer figures out the rest. So there were other problems like slow
development. I mean it was one person working on this and it's hard to to um yeah if you just
one person there's also the problem was copyright assignment stuff so there was like a like a
political barrier around adoption but yeah so eventually we figured we have this fundamental problem
we have this legal slash social problem with it and it's a little bit moving to slow for us let's see
um what do we can do about it so um we figured out like we created something new we first called a baby
kid that's how my first commits were called baby kid it was kind of funny because you know back
on the day all these little demons that showed up on the various limits distribution we're all
called something kid. Most of them kind of died out again there's policy kids still there so it's kind
of named poll kit. I think it's the thing that we imported from Apple but um yeah and then because
this was supposed to be a process babysitter we called a baby kit you know it's kind of funny
but every name did very soon to system mean I think not many people actually ever saw a uh this
is a new tree when it was still called baby kid um we figured that if we call it baby kid it might
not really find the the professional adoption we wanted it to find. So um yeah the basic concept of
this is it was transactional system right so um it were to actually understand um the dependency stuff
and would actually calculate on its own what it needs to pull in and things like that. The basic
ideas were hashed out in 2009 that's actually 15 years ago right so uh you know when when they
fastened people suggested I should do keynote here they already suggested to me 14 years and then
every never have a question that until earlier this week when I actually sat down put the slides
together figure it out it's not actually 14 years it's 15 years and it's kind of dumb because
15 years would have been so much rounder um to put on this slide so yeah I mean then again on 2014
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
wrong but uh 15 years it's kind of nicer. Anyway so we figured it all out like what we wanted to do
like the basics um uh flying back from London's Plama's Conference with my colleague Kaisivas
and yeah we wanted to like properly at least an all of you like doing a proper open source
project like out in the open no copyright assignment make it LGPL and things like that so yeah first
commit 2009 first release one year later um yeah and from the start out it was actually supposed to
be more than an in-it system because we figured out like more than the actual P81 because we figured
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
serious of process that need to happen you need to mount stuff you need to file system check stuff you
need to do all kinds of things so right from the beginning it was more than one binary so uh we
figured like yeah let's see like we always try to do our homework right like uh you know people
complain to us that we did like NIH like not demanded here syndrome stuff and uh sure to some
degree everyone I guess is victim to this but uh I don't know like I I really tried to do my homework
and every time we touch something to figure out what is the status quo what do the others people
actually do before we do anything and we want to have good reasons why we do it differently um so yeah I
guess the influence primary inference was it's in five in an upstart because that was what the
distribution's back then we're actually using but uh much more interesting we found uh it was Apple's
launchty that started in 2005 it had in particular one feature which we loved very much with was the
socket activation concept um that basically is um the same like it actually existed and non apple
unix before the two in something called i&d but Apple kind of pushed it to the limits and that
was a really nice design because it kind of got rid to some degree from explicit dependency configuration
anyway I'd like talking about this too much it's probably too technical I know this is a keynote
so I probably shouldn't make it super duper technical but I just wanted to mention this one features
that um we're actually like a lot about launchty there were other influences like uh Solaris SMF
but the way I'm talking a lot if anyone has any questions um absolutely do interrupt me um I
this probably gonna be difficult making this like a fully interactive talk where you you guys ask
question I answer but at least I want to try so if anyone has a good question to us just show up
and maybe we can answer that first um anyway so Solaris SMF was a major influence because it has
all this enterprisey stuff and we wanted to go for enterprise two um like both Kai and I
were working for rat hats so we wanted to uh yeah that was our focus um and we added a couple
of original thoughts but um just a couple of them I mean I wouldn't claim that the concepts um
that we um it's systemty is built from our purely ours they are not we looked at what is what's
there and then tried to do maybe a little bit better at least in our eyes there's one major
influence of credit which is Unix um I don't know what Unix really is like I think it's a religion
to some to some is an operating system um Linux is of course not Unix it doesn't really
share like at least not source code with it or anything typically not at least not in major ways
it's only I a philosophy that it shares um one thing I'd like to point out is that most of
the Unix systems that exists today like the BSDs in particular they generally have the Unified
repository is kernel and use the space in one right um so you you get basically from the same
source and with the same release cycles you use the space in your like the basic use the space
and the and the kernel which is systematically different from how we do it on Linux right they're
now in Linux everything's split up right like not even the kernel people and the lipsy people
can really agree on everything um they're two separate repositories and if you build a distribution
you need to pull from all these repositories and not just that they have different repositories
they have completely different philosophies different licenses um different people who think
differently that have different priorities I think it's uh it's a strengths of Linux that is
it's that way because it's way more distributed it's also weakness of Linux because it basically
means it's completely chaos in a way um but it is how it is um now in system D if it's used
Linux in system D it's kind of it's kind of in the middle actually that thumb wire I mean we won't
put the kernel in system D in the same tree but at least many of the basic building blocks that
you need is like a logger um and a service manager and all of that kind of stuff are in the same
repository so if you ask me a system D Unix on that level it's probably more Unix than Linux
ever was before um is this truly Unix? No, absolutely not um but closer to Unix yeah
um and then what the heck is Unix like people like the first thing that Unix comes
to mind there is everything's a file I don't know my printer is not a file
I find it a very very weird concept it's like somebody studied object orientation and then
didn't understand it or something that they think that a printer could be a file but okay
um then my questions of course like shouldn't running services be files too if every
thing's a file system five and it's things no because there is no it's not exposed to the
file system of a service is running right like there's no way how you configure that out you can
maybe find a pit file and then make guesses or something um but in and system D actually yeah
kind of is a lot that way because everything the system you manage is the service manager manages
is actually exposed as a C group you know and C group are these kernel concepts that actually
exposed in the file system and C group FS and they're always mounted and slashed the somewhere
so in a way um yeah running services and system be like the inherent objects that we like the
primary objects that we manage are yeah files if you say well well directories um but it's kind of
same thing like I mean according to this weird object oriented approach of Unix but directory
definitely is file right like even if a printer is weird anyway so uh is this Unix?
I mean uh in a way you could say system these more Unix then system five in it is hence
because we adopted the averaging as a file approach there but of course I'm not actually
climbing that so it's system the Unix code wise legally no we don't inherit any code
into like from Unix and the system D organization wise maybe real little bit closer actually
to how the B is these managerly things but just a little bit um philosophically I guess obviously
Unix inspired operating system and hence because we are Linux um yeah same thing
same as well does it actually matters though I don't really think it does very much I mean it's
so one thing that always comes to like the criticism of system is always comes up is this Unix thing and
to me it doesn't really matter you know like these slides we're really about like pulling that
apart like how much sense of nonsense that actually is but it's simply like in 1996 in 1969
when Unix was kind of created um you know operating system designed and end that that way right
like so it's a major influence but maybe other influences matter too like that came afterwards
that might be actually more interesting so um I don't know so is it Unix?
Maybe something in ways and otherwise probably not so um any questions to this point otherwise we'll
continue with history there um so we talked about how baby could got created and the influences
let's now see what happened next it became the default in the first distribution back in 2011 that's
like 13 years ago now in fedora there was a first distribution that was a big win for us
because for the first time um people would actually use our stuff by default and that was definitely
always our goal to make something that is not just a niche but it's actually something that is mainstream
can be used um open Susan and Arch Linux um follow Charlie after um year so um when they
made it the default then rail like the big uh commercial distributions followed in 2014 um so that was
uh when it started like the whole world started running on um uh system D um debut in Ubuntu
and followed one year later there was probably the most uh complex win but by then um it's like
all the big distributions uh as supported it um like the the commercial ones they all made it
the default and the and yeah even in the ones that didn't make it the default it's at least available
so yeah I guess that happened like in retrospect relatively quickly right like given that 2009 was the
the um
mall
okay I think this which actually moves from time to time and it's own it's very confusing
2019 we have a logo like um to be as banner designed a logo for us we actually have a brand website
where it can actually download the logo and actually get told what system D Green actually is
because this thing here that there is a system D Green um it's uh yeah I don't know
think that Pantone has registered that color for us yet but it's it's what it is
we even started our conference in 2015 to 2016 we had a system D.Conf it's kind of funny name
you know because that's also the name of the configuration file of system D of course
this later morphed into all systems go since 2017 which is kind of you know it's still the same
conference but it's a wider focus right like because we figured out system D doesn't exist in a
vacuum there are many projects around it that are equally relevant to building a basic OS so
we decided to to widen the the focus and invite those people to and it's still going strong today
in fact yeah this year it's gonna happen too like you should totally go there if you're interested
in low level operating system kind of stuff use a space only though um so much about the history
um let's see where are we today so I mentioned all major distributions use it most of them
like in Picca the commercial ones already fall to it and this basically means yeah the world runs
on it like Linux runs the world and system D2 a large degree too um so basically everything that
is an Android probably runs system being away um it has a vibrant community I would claim like
they're six core maintainers should do like reviews primarily they're 60 people of
chromatic ss um two thousand six hundred contributors over the years um so I think that is probably
one of the larger open source projects we have a six months primary release cycle I think that's
actually not that great we should do it be doing better it's very hard to doing proper release
management so for a large project and they're a regular minor style really the two that the
distributions um except we we got the nations by SPI and grants by the STF so that we actually
have a little bit of funding we used it for a couple of things where basically the core developers
personal interest is not so much in these areas like for example we paid them to do our
websites like to to rework our main page logic and things like that so the the if you go to the
web that had now has this drop down box in the top right for example this is like this is
super exciting to have but also not something that the core system to developers ever wanted to
work on so we used our the grants that we got in the and the money that we got to native for that
so
so the question was regarding adoption in the embedded so I personally have person not embedded embedded
guy but I mean it depends like what kind of embedded you know there's the super tiny embedded people
who kind of from likely microcontrollers they don't care right but I think bigger embedded devices
where you actually have a proper um uh system like they tend to all use that right like because
you know like something that is important to us with system is that we try to make everything
generic and we also do care right like this doesn't mean like if you if we really don't have any
memory and like if you're too limited then maybe systems not this thing but I'm pretty sure that yeah I
have slides later about size and things like that let's talk about that then um so what is system
it's a suite of uh 150 separate binaries right like so uh we sometimes got this compliance
a system with monolithic or something like this I don't know what it's monolithic about 150 separate
binaries it's also quite modular right like uh it doesn't mean that every thing is modular
that you can just take any part of it and use it in any other context but it means that uh to us it
means that uh you know it's a suite of several different things and there's one central component
that you can't really turn off which keeps everything together it's a glue in the metal but the the
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
us that's uh actually quite modular um it's written almost entirely in sea I mean there are some
exceptions that some stuff in uh pious and very experimented and rust a little bit but um it's ultimately
a sea project um it is the common core of what a Linux based who has um needs at least to our
point of view um like as mentioned we are like six people in the court team so we have uh not all
this exact same uh view and things um but uh yeah it's still I think that that's something that we do
agree on that yeah it's a it's a common core of uh what operating systems needs um and uh it covers
a lot of basic west functionality like log and d for examples about user session management
resolves these about DNS management like resolving network d about an basic network management
and time sink d about clock and a home d about home management so it's like yeah there's lots of
different components a lot of different buyers that take part of uh different things um as mentioned
because it's modular and that our everyone of these components has found adoption all the distributions
what I find particularly very interesting though is that all the distributions usually pick different
components they adopt uh the ones that they don't um because I would normally adopt that they
would kind of always go for kind of the same set of things that every one adopts and then the other
parts that they don't but interestingly it's uh it's a way more diverse than that so yeah
and this is later was talking about about the footprint um uh you know if you have 150 modules about this
um uh let's talk about sizes about yeah how much dependency does it pull in how much code is it
actually in sorry sorry slides and how much um is it going to be on disk if you actually run it
so it's one a 690 okay um lines of code just to compare this like WPI supplicant you know that's a
user space part of your Wi-Fi stack basically um it has like 460 k these days it used to be always
my primary example of anyone asked me like how big a system to hear something I would always point
to that because the the user space part of your Wi-Fi stack used to actually grow at the same
rate as we did and was the same size and I said yeah it doesn't mean it cannot be that large
if you just the user space side of your Wi-Fi stack um it has the same size um in the last three
years of something we actually apparently accelerated so there's actually difference now um so uh let's
that's actually three uh yeah 50% on top of what WPI supplicant brings you but still to compare this
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
it's it's it's not it's a lot even though we have 150 components that I think people might think
it is on fedora a full blown install of just system D like fedora being there's just just generic
distribution the tends to enable everything right like because as mentioned it's very modular
but in system in fedora basically all the the modules that you can turn on are turned on
so if you if you have the full blown install that's like 36 megabytes
for comparison bash alone already takes eight megabytes right so is a lot I don't know it's a lot
more than bash sure but uh it's also you know um when people compare like used to compare this
to system 5 in it or something you know um system 5 in it wouldn't run without a shell right
because all the in it scripts are our shell right like so it's a shell alone we're already
eight megabytes then it's not that bad I think so is a big small I don't know it's
certainly um okay uh what's also very interesting is of course looking at dependencies like what
else does it pull in I kind of already indicated that with system 5 in it and it um something
that we do in system D this there's heavily is actually that we pull in most of our dependencies like
generally well very careful with dependencies because we know they when we add some library
as a dependency system D then this will hurt everyone he uses Linux right like because they will
come a dependency for them so um we always very conservative we had a very high like we need to
really have strong reasons to pull something in um recently like two years ago something we switched
over all of the dependencies that are not necessarily um and necessary to run the basic system
into deal open one deal open for those who don't know is like this thing where you have a
shell library but you don't actually uh link against a shell library but you just delay that until
the moment you actually really need it and then you load it so what's the benefit of this it makes
dependency weak right like because until that moment where you actually actually really can't do
without that little library you're not going to pull it in um this is great for example let's say
you do uh full disk encryption and you want to do that against your fido key you know many people do this
but other people probably don't right like even from the people who use disk encryption not
everybody wants to link their stuff against the fido stack so that's a deal open like just as an
example a dependency for us so the basic means if you have the fido stack installed and system
being installed it's just gonna combine itself to something that's really good if you don't have
the fido stack stuff you can still use the disk encryption like by buying a bound to something else
um in fact we we push the deal open saying so far that um there are nowadays um only three
really required dependencies as glipsy lip mount and lip cap the other ones that aren't this
either are like they are built-time optional right like it's people who actually want to
as the Linux can use as a Linux but uh I think that's actually kind of nice right like that we
don't have like uh like uh that much of a dependency footprint um yeah and we kind of thinking about
getting rid of lip cap too actually um the deal open saying it's actually kind of interesting
for another reason um uh you know this thing like uh like one was a two years ago something when
the exact vulnerability I kind of hope that every one of you heard about this um system he was kind
of indirectly involved in that because the people like because the attack that was done um was done
on XZ but the attack surface was SSH and the reason why that worked is because system the like
many some of the distributions linked SSHD against lip system D which pulled in lip XZ so um
back then this was not a deal open dependency that's why this why this happened but um uh so system
D was not it fault for like it wasn't not the thing there was a tact it was not involved in the attack
in any way it was however was um in this case the the conduit like the reason why these two
things ended up in the same process so um we saw it okay not our fault but also maybe we can do
something about it and this is why we started pushing for a deal open so hard because it basically
means until that point where XZ is actually needed will not gonna load it right so it's not gonna
end up in the memory of SSHD because there's nothing in SSHD that uh would indirectly ask us to do this
so um yeah deal open as both a footprint thing and a security thing actually so executive summary
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
I think they're good reasons it's good enough for inclusion in inner dees you know inner dees are
these things that Linux computers need during early boot up to to to set up basic stuff
they nowadays need to do a lot of stuff right like because you people use full disk encryption
was phyto as I just meant like with your secret keys so they actually need to do all this right
like they need to um start up find all the devices uh that are involved for your disk that they need
for the disk and they need to find the phyto stick and all these kind of stuff um so that's actually
yeah and then it can be arbitrarily complex um these days if you then think about complex storage
but uh yeah so having system d and then it already makes actually ton of sense because it's
so complex these days um system d is not gonna hurt you very much um it's all the like at least
head-based distributions um are all on that and I understand your boot is gonna uh use that for
inner dees as well um and it's good enough for containers right like you can you can run
system d inside of a container if you want uh it's not gonna blow things up for you because as
mentioned neither the size footprint is that big um and in come back containers die and that's not
not the dependency trees so talking about um did this answer your question by the way um good um
so uh uh it's the next question of where there's what actually belongs in system d because people
always say oh my god scope creep and it's true like there is some scope creep there um but uh
let's make clear what actually we think belongs in there and what doesn't right so uh we have a
couple of requirements that we make right like uh I mean besides the fact that someone needs some
maintain that stuff um it needs to be very very generic right like it it's not supposed to solve
a problem for one user it needs to solve a problem for a lot of users and if it like most of
users basically otherwise it doesn't doesn't really belong in system d it needs to be foundational right
like it's never going to be the thing that the UI that that um actually interface with users so much
but needs to be something that is relatively low level foundational it needs to be common right
uh it needs to be something that it's not enough to be generic it also needs to be something that
actually uh would be used by a lot of people it needs to have a future right like we're not going to
add um support for the legacy technologies like if we already know at some point that some things
not going to be the future we're not that interested in it it needs to be a reason to be clean right
like we don't want to cut corners that's always the thing you know that's like you can deliver
products quickly if you cut a lot of corners um that's not where we want to be with system d we want
to do it uh probably and actually do somewhat clean by our standards and it needs to follow a common
style we talk a lot of the later about the concepts that we keep on reusing and system d about
configuration and things like this so uh yeah um do if people ask me personally for example um
does this thing belong in system d this is what I want what answer to them like does it actually
check all these boxes and if it doesn't know it's sparsion b system d but it should be something else
if something does check all these boxes it still doesn't mean that it needs to be in system
can still be maintained elsewhere that's not the problem but these other commands so
next thing talking about concepts you know what what a system d um to us um beyond like this one
implementation of a service manager and it's you know we didn't ever wrote them all down
I mean you can distill them from our man pages and things like that in front of specifications we've
wrote um so I can't um give you the the the whole list but I can give you examples like about
concepts that we try to push with system d and that our core at all the stuff that we design
inside of system d for example one of the concept that we base everything on it that there's a
clear separation of what Etsy run and user are right um and we we build a lot of stuff on this right
like so that we clearly say Etsy for configuration run is for for runtime stuff um that is
not persistent and so let's use her as for the stuff that comes from the vendor right um
this is a separation that was not traditionally followed to clearly on Linux right um it is nowadays
and many distributions because we have user merch if you know what that is um these days but it's uh yeah
everything in system d is designed that this um uh separation exists and we'll see like
I have an example far as a down why this matters or a hematic user is a kind of the same
same hematic user is like a concept that we we are trying to push with system d is that slash user alone
is sufficient um like it has a sufficient description of the system that can be booted
so that you can get rid of Etsy and var and everything else and the system will still boot up and
create what it's necessary this is really nice property for us because basically means yeah
you can package up the whole slash user drop it on another machine will boot up will
instantiate everything and just work but yeah I don't want to really talk about these concepts
in particular so much I just want to give an example about like because they they they kind of
spill into everything else we do because um like it means like how configuration management needs to work
like for example we cannot rely that a configuration file is actually existing we need to find like
automatically if we see that some configuration file isn't there come up with same default that we can
use instead um more specifically there for example I this thing that we always have in system
the over and over again which is like this merging of drop in configuration files right like uh
for example there's one component called temp files it's uh it's actually a little bit misnamed
because it's not really about temporary files it's nowadays about any kind of runtime file that
needs to be created at boot under circumstances um and it's one of many tools and system that
expose this behavior that you can drop the configuration for them both an Etsy like an all three
of Etsy and user lip and it's like run and they will be merged together right like so that you
have one place where the administrator locally can put these files one place where the
OS vendor can put these files and one place where local programs that need to to install them locally
for a short time can place them and uh there's very clear way how you how they can override each other
which one takes precedence of each other how you can master them and a couple of things like this.
So for us it's the rule that any component as a system needs to follow this behavior and it's
the uniformly um do this it's actually by the way it really nice concept that should find adoption
and does find adoption um beyond system D uh itself. One more broader concept as well like for
example system we very clearly say everything we do needs to have declarative um uh behavior right
like you just write where you want to go um you don't write down code right like so for example
in system D we generally say boot should not involve running a shell script because shell
scripts are inherently imperative right um and that's that's that's not a way how you want to
configure stuff we want to one or or even declare stuff we want that's that yeah it should be
a statelessly declared and that goes into everything we do so um there are more concepts that we
always have but having um these concepts in place permits us to do other stuff that is very easy for us
that we're very hard to do before this like for example here I give one thing and system D for for
for services that run the system we have this uh these options called protect home and protect
system um which um are security knobs that that set up a sandbox for that service and uh by
having made very clear that stuff has to be an Etsy run and user and that flash user is where
the whole operating system puts should the vendor files we can just implement a sandbox very easily
that isn't like like the class for example that there shall be no modifications made to the operating
system itself or that even says there should be no modification that be made to Etsy like to
the configuration right but very very clearly saying that these um these are three different things
and they should be followed through and there should be nothing else that um I collide with these rules
but we can have these high level um knobs and they have fully effect and other things that
system D is actually standards you know we we often try to set standards by writing down specifications
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
example and we have Etsy OS S release the same like um pretty much all the distributions and even
Solaris and PSDs adopted these days basically a little file that just tells you which operating
system you're running was a couple of uh like metadata fields um yeah we've wrote this down
wrote this specification wrote it like a thing like that all this evolution adopted then even the other
uniques aside I'm okay it's a good thing let's do this so um we even create a new website for this
is called the UAPI group where we have our place where there's so many people and people like close to us
and other people um are invited to put these little specs right like that are somewhat informal right
we don't do like complex standard processes but uh that it's very clear place to put these
documentation so that people know how these things work um like he just has a random example there's
a DDI spec for just cover up the discriminates it's a spec that we wrote but it's also
imports like it's based on the UFI GPT like the good partition tail so yeah so my much
show where we are um so now I want to talk about where the future is going I basically put four
topics out of my slides I got like 50 minutes left so maybe we'll speed this up it's fine that like
um I have like the off all four of these topics I have a lot of slides but it's not really
my intention to cover them all um but at least I want to touch every one of these goals uh at least
to some point so um I see four goals and challenges for the future system the way we want to take
it that's my point of view I'm just one of the quarantined as a system D um others and in the team
have slightly different opinions probably not widely different but let's just say these four
on my personal goals and challenges and uh where I would take system D uh one of the first things
is I want to do have boot and system integrity addressed um so boot and system D integrity um like
it's basically this this cryptographic way how um the boot process of modern operating system tends
to be protected so um that backdoring it is this is um harder um not impossible harder so all big oasis
all big commercial oasis um have solfs at a long time ago sometimes in a long time sometimes
a middle-long time but yeah it's always there in generic uh Linux though it doesn't really exist at
least none of the of the generic distributions of the big ones tend to have adopted this at least
not body fault it's a very serious situation because i think it actually matters a lot um i don't
really understand why i mean i have parsed off of the reason i can see because it's like it makes
things more complex uh because you need to think about cryptography and measurements and all these
kind of things and everybody knows this i think there are certain cultural issues um to some level
um found it on on just thought i guess from the FSF like because they claim like one component
that you need for for boot and system integrity is a TPM right and the FSF painted as like this
terrible thing that is all about DRM even though it's complete bullshit it's not about a DRM you
can't really use that for DRM but uh what do i know um FSF seems to know this better i think like
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
anyway so there's a certain cultural issues because a certain players and an open source kind of
painted this as a devil's work and that it takes away your computers i don't think it does that you know
the way how TPMs are designed um actually are very much compatible with our goals um other
things is like a package-based world makes this kind of stuff a lot harder than uh needs to be and
we live in a package-based world all the distributions used packages by default um so uh um so
let's talk a little bit about the means again it means uh locking down the system what you can
run on the system at boot time and during runtime so um it could for example mean that uh only the
code that u s uh vendor considered okay could be run which is i guess to some point what windows and
all these other um big companies run their system um under so it basically uh would mean that uh
yeah your district decides what's safe to run was not or the other policies that uh you decide
on what that uh does right um or a combination of both right like this is probably why we actually
want to go like for example that distribution such as devion they generally that i mean this is kind
of that what they do right they give they the vet packages and save this is good software um and we
had gone assign it cryptographically and that gives you the guarantee that this is the version that
the devion people actually saw that was good and other distribution basically do the kind of same thing
right so um yeah in a way the policy number one is kind of like that but you also think uh it
should be more restrictive um uh so that you actually can decide what's actually okay why does this all
matter um i think they like the the primary use cases about keeping attackers out of your system
and uh basically if always have a well known state you can return to where you know there's not
gonna be anyone inside there because you can prove it um the the key fundamental thing that it wants
to take here is consistency you know that if you have a cell on the internet and somebody breaks in
that you know how to get the person out of there because you can reset the cell to define state and you
know yes they like because it's software they will get access to to systems they shouldn't be
getting access to but there should always be a bit way a sane a clean way a clear way um how you
get back to a system where the attack is not in there anymore and you can update the software in
in a safe way in the safe state so that you have the cryptographic guarantee that everything's in order
um so yeah and other words is so that you don't have to always leave with your laptop around
your pillow because you need to be afraid that somebody um modifies the bootloader to really
into this new system so yeah it's it's like about like yeah even though you can leave your hotel
your laptop and your hotel room you can have some assurance that it's not gonna be be
back toward when you come back um i'm gonna skip a little bit about these slides um
a lot of them let's uh talk about the next go actually you know i did a talk early about something
related to this um so that's i'm kind of happy with skipping these slides um and there's gonna
mean another one i think tomorrow um but yeah let's talk about the next go and challenge for
system d number two um i think we should think about repeating our IPc system you know when we
built a basic user space we have all these demons that they need to talk to each other and right
now the thing that system uses is debuts right that gives it the thing that's there and everybody
has adopted that but uh i think we should maybe refer to that and go to something that we could
that's called varlink um um yeah i mean you know i've paid it this house here to tell you
that i have millions of reasons to do this i don't really want to talk about all of them because
there's not it to be supposed to be a talk about that but i think um the problem that we have
with divas these days with the IPc are so many um and there are so much better options that we
yeah we should start the process at least the new stuff that we're adding is more varlink
than divas even though divas are never going to go away um of all these features that i listed
there that i'm not going to go through i want to um uh talk about one specific one which is uh um
this one now processing IPc requests in one service instance for connection which i find is like
a little bit of a game changer for people who who uh like if you know how unics this build this
is kind of awesome so you know and divas if uh if a service um if you ride a divas service you kind of
are forced to have an event loop and instead of that event loop you need to to process all the
crests coming in from from all the different clients that you have um and this makes writing uh divas
demons kind of hard right like uh people do it but it's not trivial um because you always need to do
things that are synchronously you need to um uh yeah have an event loop then if you want to pass
data around you always have to put that in like this little bit of memory then pass it around
from money and land to another it's a little bit easier with more money and programming languages but still
um uh in borrowing however like to give you an example you know and consider classic
unics tools right you receive some input and SDN some command parameters on a kernel command
on a command line of that program and then the output goes to to SDL it's the it's a basic building
block like how shell pipelines work these days um modern unics tools added one thing to that they
generally um output jacens these days if you want to um many um also read jacens input so suddenly
I think this is a big jump right like because previously you had all this chaos like could be anything
or it could be basically text that is your input yet no no no no structural understanding of
anything that we are processing there nowadays uh because this like for example here the find
mount is this utility from utility linux that shows you the mount table um has a jacens which many
many tools have these jacens which is these days with borrowing we now extend this concept right
by one more thing instead of just having SDN like the input to the tool and the output to the tool
uh doing jacens we also have the command parameters also uh in jacens so that you um yeah have
suddenly everything in jacens you have the input the output and the uh command in jacens if you do
it like this right like if you take a classic unics tool like for example find mount I mean okay it's
not a classic unics tool it's classic linux tool but anyway um if you have that um you can
trivily add a rolling support to that that you actually instead of reading all the commands from a
from the command line you alternatively also read it from the jacen input um then this is already
enough uh to be considered a rolling IPC service and then you can uh uh this is a small addition right
like you just also read the command line from there because uh this basically means you can take that
program and bind it to an AF unics is stream socket and suddenly your thing has become a uh IPC service
and that is awesome because basically means that the traditional um uh unics tools all become IPC
service very trivily and we have so many of those so that but suddenly become IPC services so that's
kind of awesome uh I don't have that meant time to that anymore so let's go to the next um challenge
in future uh which is rust difficult thing uh see as it limits I mean it's not much it's not a
big thing for us um uh uh uh uh uh uh the limits of seas because like if you actually look at the
the security vulnerabilities they are generally not memory management related and they are not
that many easier right like uh like in 2020 for if I couldn't find a single one in 2020 we had three
but like the vulnerabilities that we generally have in system the more logic errors they're not
not errors in memory management so for us it's not not that uh love that uh much of a pressing
problem um I think it's still thing it needs to be um addressed but it's not like that it's fire
burning out on a hands or something like this uh we do think that the future rust uh it speaks
probably rust um we started a little bit with oxidation but it's uh it's complex right like uh because
first of all the build systems were just a matter because we will we have this project it's all
and builds 100 binaries and shared libraries and kind of thing and we need like we cannot move from
from sea to rust in one day we need this complex um uh uh like a slow movement process so uh um
yeah this supposedly is less of a problem now because me so I'm again some rust functionality it's not
all beautiful but at least it's there uh but we have more problems like for example the primary
one of the system is 150 binaries and they are we're sensitive to footprint and uh issues that
it was what I had it on this earlier slides right and we are heavily relying on shared libraries that's
how our our footprint is so small is because yeah system you reuse is most of the code um uh that
that's that's kind of the key to making 150 binaries small so uh we have internal libraries we have
external libraries um and we use deal open heavily right so um dynamic libraries and rust are not there
and there appears to be not much movement in this area so uh that's a big problem for us right
like because in rust it's more like even though they do support shared libraries in some way
it's the culture is definitely around static linking but that's would not work for us because it
basically would mean if we start heavily static linking everything um the footprint of system we would
close for the roof um and then everybody would hate us because they couldn't build internal
anything anymore so yeah for us um this is this matters you know for the kernel people rust is
way easier right because the kernel is a fucking static binary it's not much more than that it's
super simple in that regard right for us not gonna work this way we need shared libraries um uh
I don't see any other way I simply don't um and I know that rust people would disagree and say
everything is static binary and you can do siblings of whatever else but I don't see that um but yeah
rust people please do something about this um and I mean we're having to play ball but uh I want
to be the ones who who uh pioneers this is not the problem that we want to solve I think that
rust has to solve it first for us um or maybe I don't know zix solves that problem first um there's
a chance of some competition there um yeah the last thing is more about moving to image based stuff
away from uh package based stuff that I think I mostly run a run out of time so I would rather
spend my remaining few minutes how many I have in questions um then let's just say the last
challenge that I have here is about image based oasis and leave it at that um yeah if anyone has a
question there's a question somewhere in the middle so yeah so the question was regarding
grab I understand like uh like what our goal is with replacing grab or something like this I don't
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
might guess um I think it's all there the remaining issues are political um I say you know
grab does a lot more in system the um like it has files system drives and whatnot I think
most of these things that it does are kind of a mistake about not knowing what you actually want
to do and how to do it securely I think for the general distributions uh you can switch to
boot all day like as long as if you focus as EFI and EFI only that's nothing missing um and I
kind of it's also sense you know with uh the other stuff that we're doing like regarding boot um they
have to go there that way anyway if they want to have a second boot uh uh signed measured boot
thing anyway I don't think this really is that compatible with the way how grab works but we'll see
about that but uh let's maybe do talk about that otherwise I don't think I have a much time do I have
time for one more question quick comment if you're want to leave already please use the
dose in the back of the auditorium um what are the plans to fix the issues with the
resolve D I see myself constantly uh restarting system D resolve D so the machine can
uh resolve but you're having issues with resolve D I don't know like um it works fine for me let's
say that I mean I'm aware that you know um uh some people have something but they generally use like
more as a fancier features of system of resolve D like D and S seconds things like that and that's
flaky that's mostly flaky because D and SX is really hard and and and real life because service
a shit uh but I don't know like sounds like you should file a bug or something um uh you know
nothing is perfect but I to my knowledge reasonably just worked for most people okay I think
we'll go time for one more question so I'm going to steal that one okay so uh system this is
goal the security features like put a comment so you've mentioned some of them and I found
them particularly useful recently because we essentially big your demand that we got told to install
a policy mandated route kit on some of our systems effectively and thanks to system DRA able to
be in the drop it's also able to really defang the bloody thing the thing is a lot of those features
are really hard for people to follow so yeah the thing is my question as far as I those security
features are quite complex there's the analyzing so on are you planning to make it easier for
people to try to ease those features in well I mean we have tools I'm not sure if anyone's still
listens but uh we have system D analyzing these things but it's to some point in the communication
issued a documentation issue and that's how we feel.