 Okay. Hi. I'm Leonard Patering and I'm going to do a talk today together with Kai who hid there in the first row. We're the guys behind system D or at least two guys behind system D. And yeah, the topic of the talk is going to be like the thought that we have made ourselves about why Debian should or should not adopt system D as a default. Of course, that's not really our decision and we are after all Fedora guys ourselves, but of course we are always interested in a healthy community and cooperating with everybody else. So yeah, the first part of the talk is going to be about the why and the second part of the talk is going to be about the why not. And yeah, we have a lot of ground to cover, but still if you guys have any questions, I would really prefer if we could make this interactive and you ask them right away. In the worst case, I might just say let's just cut that particular thing later, but hopefully we can make this more interactive than just me talking and you guys listening. So yeah, let's get started with the why. Oh, by the way, I tend to speak quite slow if it's too fast. If it's too fast for anybody, just tell me and I'll try to be slower. Okay, so the why. Let's first start with a little bit about the superficialities of the project. It is a very healthy open source project, we believe. It has a very large community. If you look at the statistics, we have 641 mailing list members, 424 good contributors of those 240 ones were already from UDEF. Of course, you cannot just, if you're just interested in the ones that are only committed to system, you cannot just subtract the 241 from the 424 because there are quite a few who contributed to both. We have 17 different good committers from a couple of different companies. We have 253 committers, or 30 contributors per month. Of course, the 17 good committers, like there's no denying most of the stuff that's done is done by me and by Kai and by Speakingyev and by Miha and a couple of others. Most of them work for Red Hat with some exceptions. But actually, among those 17 good committers, we even have people from Canonical, we have people from Intel. I don't think that Canonical people actually realize that they have committed access to system D. Well, it's a system D part. Anyway, but you guys have committed access to everything in theory. Anyway, so yeah, I think if you read it from that, it's a very healthy project. I'll leave it to you to figure out how that compares to that other competitor. We have no CLA, no copyright assignment. We're just the real open-source project. We are LGPL3, 2+, basically, like we don't want to have anything to do with politics, so we choose something that everybody can agree on, and that is while still copy left the most liberal form of copy left. It's inherently cost distribution. We have, of course, a lot of people from Fedora working on it, but the Arklinox people have adopted it, and has a lot of support for that. There are some patches coming from the Debian people, from the SUSE people who have adopted it as well. Everybody is on board and tries to pull into one direction. And of course, as mentioned, there are multiple vendors. You have Red Hat behind it, SUSE behind it. You have Intel behind it. You have quite a few other companies. You have a lot of embedded companies. You have the car companies. There's a lot of commercial power behind it. And everybody's welcome, and we mean that. We will, if you send us a patch, we will consider it. In the worst case, you will get an explanation why not, but usually, we'll try to accommodate for your needs. And we use Git, actually, for our community stuff, so we try to be, like, how an open source project should be. Just the thing that you can contribute to without syncing, because everybody knows Git anyway. Yeah, we do like community a lot. We have multiple HackFest per year, and we try to get everybody to attend. That sometimes even includes the fact that we sponsor people to come to our HackFest, like the last one we actually had last week in Brno. Like we even got, like in the previous one, we got a couple of people from ArcLinux attending. Actually, this one as well. And so, yeah, we truly want to be a healthy project there. And the HackFest are awesome. A lot of really constructive stuff always comes out of that. Yeah, of course, we participate in numerous conference over the year. We attend all the conference and try to make sure that everybody understands where we are going. And I can make themselves heard to drive it into the direction that they want. We make sure that we always present at the developer conferences that matter, like, I don't know, Plumber's Con, like this one, so that people can talk to us and we can talk to them. And we kind of figure out what people actually want from this stuff. Our focus is a service desktop cloud embedded, like Linux itself, basically. We don't focus on one specific part. And we are strong on those. Of course, as you might know, REL7 is going to ship system. REL7 is like the most famous for being a server operating system. It's relevant for the desktop. As you know, GNOME and T-Sync like that use a lot of system functionality simply because we provide a lot of functionality that others don't really do. Cloud is the same, embedded. It's actually very popular and embedded. Like there are companies to build it into wind turbines and, of course, the car companies to build it into cars and as built into toys and as built into, like, telescopes that look into the sky and all of that already now. There's a question over there. Yes, I'll try. I'll probably forget it in five minutes, but then tell me again. Yeah. It has more than three years of development. We started it even a little bit over three years ago. Nowadays, it's used in production as soon. Yeah, we're currently working on including it in REL7. So you'll probably see it on all your servers very soon, too. Yeah. So much about the superficial stuff, right? About the community things and how we do things and how we, yeah. Let's now focus a little bit more on technical things. So one thing that is actually, I think, one of the most important things, it's, we believe that system D is technically the right thing, the right design. Of course, it will have bugs like any software will, but at least phenomenally, our design is right. Of course, you can only say that this design is right. If you look at the other designs before, like there's, of course, system five in it, which I believe and most people probably believe at this point is systematically flawed because it doesn't react to the actual things that happen on the system, right? It assumes that hardware is mostly static, that devices like, like hard to show up at a very specific point in time and then are there and never change. And the ordering is very simplistic, I guess. With system D, all of that is not true. We actually can listen to devices showing up. And when we boot up the machine, we will actually wait for devices to show up, run the file system, checks on them, and mount them and things like that. So yeah, system D is about this is dynamic thing that can adjust to what's actually happening on the system, because systems work very different nowadays than they worked 30 years ago, because everything's dynamic and you add this and that and everything like that. Of course, if you compare it to the other contender, which is Upstart, we believe that I mean, the reason we initially created system D actually is because we believe that the upset design was wrong. A little bit about the history there. We started like I played around with a little project I called Babykit. It was back at the time where everything had to be a kit. This Babykit thing was supposed to be like an experiment how we think that it should work. And then Upstart came along and then I put that aside because we actually believe that Upstart would be the big and great future. However, over a year or so, and after talk, we're seeing Scott in a couple of times at the Plumbers con. We've eventually figured out that Scott's probably not giving us what we want and we believe that inherently it had the wrong design. The reason what exactly is broken there is basically what Upstart does is you have a language how you can express how events happen and what's supposed to be done that way. What system D does instead is you express relations between things. Now, one is a lot more flexible and powerful than the other, because in one thing you basically have the administrator to figure out what should happen or the developer, what should happen in which case. You write that down and then Upstart will just execute it. However, in the system D design where you have the dependency tree, basically you just say these are the dependencies and then the system will figure out what to do at what place. This has a couple of effects. For example, in system D, if you want to have a minimal boot, you want to just start that and that and that, it's a relatively easy thing to do because you simply look at the dependency graph, figure out what you want, pull in all the dependencies and run it in the right order. This of course has to be more difficult with Upstart because the after rules in the first place have to express what actually happens on the system. This eventually becomes even more problematic. For example, something very recent is the rearrangement of C groups. I'm not sure if you guys have followed that. C groups are the thing how you can attach a label to a set of processes and then option to set a couple of resource values to it. For example, you can say Apache gets as much CPU time as MySQL regardless how many processes Apache starts and how few MySQL will start. With the resource handling with C groups, you certainly have this problem that if you have multiple services which are basically should be handled the same way, you need to propagate certain things between these services. For example, if you have Apache and you have MySQL running in the same slice as we call it, then you need to make sure that either both of them have CPU limits applied on neither of them. This gets more complex as there's an entire dependency tree where you have to walk up the tree to the root and do enable and things like that. Now with system D with the design, this is very, very easy because we have the dependency tree so you can just walk it. Upstart again, this dependency doesn't exist and you cannot just do that. I don't know. I figure the upstart people will eventually figure that out themselves. But yeah, the summary of it all is, I can talk about that for a long, long time. I figure if you haven't looked at the details of what upstart and system to do there, you probably can't really deal with much of what I say in this regard. But inherently, we believe the upstart design was, and the system five minutes before it, was inherently flawed at its core. It's not how we should do these things. We should have a dependency tree so that we can figure out all the right things. And yeah, that's the reason why system D was invented and that why we believe that it technically is the right thing. And none of the current contenders, other contenders can do that. Be them system five minutes, upstart, open RC or whatever else you prefer. Yeah, it's used as API by other projects. I know that some people don't like with that fact. But the simple thing is like the lower level operating systems, they exist to provide services to applications making use of them. And that, of course, means that these applications need to use those things. Yeah, there's like a couple of different APIs. Of course, PID wants own APIs. There's a couple of other things like little mechanisms to change the time, to change locale settings, to change hostname of these kind of things. There's one little bit larger, one which maintains user session and these kind of stuff. It's all the things that we need nowadays and the desktop interface is actually need to interface with. So yeah, projects use our APIs, desktop projects as much as server projects actually, because we have these things in there called socket activation. I'm not going to go into much detail about what socket activation is. Suffice to say, it's a wonderful technology to make your system faster, more reliable and then things like that. So, but however to make use of this kind of socket activation, you need to patch your project in a certain way. Of course, those are system APIs. Anyway, so yeah, it's something why you want system D. Of course, yeah, simply to make, to be able to run these things on system D. And we actually believe that unification is a good thing. Of course, you can say, it's a weird way to unify things by starting yet another project, if all you wanted to make sure that everybody uses the same. But yeah, we believe that unification is the same, is a good thing. We don't need a thousand different implementations. Of course, while this is the worthy goal, we are of course quite far of that because, well, the most popular Linux distribution doesn't use it. But we still believe that it is helpful for application developers if they just have to focus on one API instead of a thousand. Yeah, then what's also interesting specifically for Devian is sometimes we push quite often, probably more than from any other distribution, we push Devian designs on system D defaults. This can be various different things, like for example, on many, many distributions, the way how the local host name was configured was completely different. Like Devian uses ETC host name, Fedora used something like ETC SysConfig network or something like that. And other distributions used something completely different for the most trivial setting of the system at all. And we looked at all of that and said, okay, if system D has to configure the host name at boot, then let's do that, but let's not support 20 different configuration formats of which 19 are completely moronic. So yeah, in this case, for example, we decided, yeah, the Devian one, which just ETC host name is the prettiest one, the simplest one, the most logic one, let's just make this the default. This doesn't mean that we immediately broke compatibility with all the other distributions, including our own. This just meant that, yeah, the Devian way how this was done was the best supported is the one that just works out of the box, but if people want to use something else they can still plug in whatever they want. Anyway, so ultimately, we do that all the time, like that there are specific Devian choices or from other distributions coming into them. I think in a summary probably adopted more Devian things than any from any other distribution, but yeah, so yeah, this might be something sympathetic. Already, yeah, this is the different thing used everywhere anyway, like log any time that the locality host named the Udev. As it turns out, system D, we had this little bit of a focus change, like originally we started out as purely an end system, and then we figured out, well, during boot, there's quite a few other things involved, and we turned it into this basic building block to build an operating system from. And then we added log in the time that the locality host named the already mentioned them in ULIFT, we merged into that. These tools are generally already also used by other distributions, like Ubuntu, for example, recently adopted log and D, and yeah, and simply because them the desktop's like to use these things and because they're saying it clean. Now, yeah, if you use all that stuff anyway, you might as well just use the real thing, right? If you look at Upstart, like or at Ubuntu, how they use, how they use all the system D components, they have all of these in there, and then they have a system D shim even, so that a couple of the other APIs are provided. So, I don't know. Anyway, so this is about more like the technical overall things, but a big thing we believe why system D should be defaulted is simply features. Simply because there are a lot of features that we can do that nobody else can really do. It's like hotplug, hotplug meaning like everything I already mentioned that is dynamic and system D and you can, we can run the entire boot up at the right time and then spawn fs check when the device shows up and things like that, which by the way is an actually interesting thing where I also believe that Upstart shows that it's a little bit too short in design, like for example the phase at boot up, which is like probably the most interesting part of this is where all the file systems show up, a file system checked and mounted, right? In a system D model we can actually express that with dependencies, right? We can say these devices have to show up, you have to run these file system checkers on it, then you assemble them and that's it. In Upstart they ship a tool called Montor, which implements that in C, which is, I don't know, it's chickening out, it's like they have this dependency system, like not dependency system, this event system and ultimately it's not sufficient to actually make this very, very basic thing work. Hi, I'm the Upstart maintainer by the way, my name is James Hunt. Mountall is a helper application that Upstart makes use of to avoid polluting PID 1 with additional complexity or additional library dependencies. It has a fantastic job, it can express everything you've just described the system D can do in terms of mounting with events. Yeah, well the system that doesn't pollute PID 1 was that either, but anyway, I think it's a bit of chickening out, you have this nice thing that you can express events with, but you can't even express the most core bit of it, that's something you do in a completely different binary. We run certain helpers out of process, that's not chickening out, that's to ensure system resilience to failure. Well, I mean, but you have already one event player, but anyway, let's discuss this maybe later, but it's like, I don't know. So multi-seat, multi-seat is something that isn't very like the core of what traditional Unix used to be, the entire terminal scheme that we have is something about multiple seats, of course, mostly tax seats, like you have a keyboard and a screen and that's about it, like the other hardware you have is basically a bell. With multi-seat support that's built into the system, you get all of that back, but in a modern way. So you get graphical stuff and you get all the fanciness that we actually tag through the device tree of UDef to which seat the specific device belongs, with the effect that you can have one machine with multiple seats and then even if you plug in a USB stick or your sound card into one specific seat, it will only show up on that seat and not the other ones. Resource management, which I think is absolutely at the core of everything that service management is about. Resource management being that you can say that Apache gets as much CPU as Apache or that you can pin, I don't know, Oracle to one CPU and something else to three different CPUs or that you can limit the memory of third and things. It's very much at the core of what administrators need to do about services. And systemally, all of that is built in. You have them as high-level properties. Logging. And systemally, everything is logged from the first moment of the boot. Meaning like if you use a systemally enabled in and around just like we do in Fedora, Dracut for example, like Harold's Dracut, then you actually get logging the same way as for later services already from the very earliest bits of user space. And this is actually incredibly useful because usually it's the hardest thing to debug if your machine doesn't boot up because it hangs somewhere in there in it already. So yeah, and the other thing is like consistently every single service gets connected to to the journal by default. I think that's true for upstairs as well nowadays, but we had that all for a long, long time already. But anyway, so the general theme here is everything's locked regardless like as soon as user space is up, everything is nicely split up, nicely indexed and ends up in the log files. We have nice things like watchdog support, right? We believe it's inherently important for service management. If you have a have a service, you need to make sure that it keeps running. And if it stops responding, then you probably should restart it. And on the same thing on the hardware is like if you have hardware like watchdog hardware like almost all modern computers have like even my laptop has hardware hardware watchdog. We should make use of that. In systemd we have that all built in, right? There's a hierarchical watchdog support. Basically, systemd will watch your services while the hardware watches systemd. And it's in the inner loop like of systemd right built in. It's something that came from the embedded people, but actually on the other end of the spectrum on the high availability server side, it's also incredibly useful because that's how you actually reach your 99.999 percent reliability. C groups, I think it's related to resource management thing. C groups is something that nowadays is used by all kinds of things like containers by virtualization like other kind of virtualization for service management and so on. With systemd it's built in, right? We use it in every possible way, which is really, really nice because actually services are tracked on the kernel level and we attach labels about which service it is to the processes and the kernel will actually inherit them natively inside. This has nice effects like on modern Fedora system you can actually type PS with a special parameter and we'll actually show you for each process to which service it belongs. This is like, it's actually incredibly, it was incredibly missing from traditional Unix because if you had Apache for example, Apache would fork off a lot of worker processes and those worker processes would fork off a lot of CGI scripts. Then you lost track about the relation of these worker processes and CGI processes to the original Apache because they could double fork and completely detach from the original session. With systemd that's not possible because we use C groups and everything like the definition of what a service is transcends the entire stack from the desktop to the services all the way to the kernel. Later on this will probably enable us to do all kinds of even more amazing things like hooking it up with a firewall and things like that. Yeah, there's really nice GNOME support. It's like all these things just work like GNOME can currently log to the journal and have it indexed. GNOME can make use of these time date hosts named D and blah, blah, blah. There's things that already mentioned quite a few of other things. GNOME is also very likely to move to systemd as a session manager because much of the problem set that you need to boot up the system is actually equally useful to boot up the session. The problems are the same. You need to start a couple of processes in the short time and you need to wait for them to happen the right time. There's nice features like FSS. FSS is something called forward secure ceiling. It's a technology like which is built into the logging system of systemd called journal. It basically allows you that if your machine is hacked, right, then you traditionally have the problem that the attacker will try to remove that change the log files like remove his traces from the log files so that you have no chance to actually figure out that it was broken into. The usual, the traditional way to deal with that is that you immediately log everything to a central log server. So if the attacker attacks your single server, then, yeah, all the traces of that are already at the safe location somewhere else so that you can actually trade that back. FSS is supposed to be an alternative solution to that. Won't solve the exact same problem. But it basically with cryptography it will make sure that through constantly changing ceiling keys that after the attacker broke into your system he can basically delete all the log files but he cannot change them anymore simply because the old keys that the stuff was sealed was are forgotten, right? So it's a very useful technology that's just there in systemd. We have profiling and debugging built in, right? In system 5 in it most people use Shell in a way or another to actually debug the system. In systemd that's actually the core part of what we do. So for example, you have interactive boot up. We have a tool called system that you analyze which actually can give you an entire dump of what the state is. It will give you output that you can put through GNU dot, or it's not GNU dot, but to that graphic thing that will show you the dependencies. It includes a boot chart implementation so that you can actually figure out what's actually slower than my boot. And so on and so on. It's all built in and it's all accessible as APIs to applications. Socket activation I already mentioned that probably not going into much detail, but it's a wonderful thing to make things more reliable. It allows you to do things like restarting a service without having to close the socket without losing connectivity. It does even stuff nowadays that you can have 20 containers listed on 20 IP addresses and ports. But instead of starting those containers right away, you can totally delay that until the first connection comes in. Which is a wonderful technique to drive up your density on the server because you can have a lot of containers and they take up very little CPU as long as they're not running. But to the user side it's completely invisible that they're not running and as soon as the first connection comes in, they're automatically started. Security is built in. Like there's for our security matters. So in system D, of course everything that system D does itself always runs at minimal privileges with no capabilities and things like that. But also for all the services we provide really nice settings you can set. For example, you can also change the capabilities of certain services. You can adapt, like you can make directories invisible for services. You can make directories read only for services. And there's quite a few other things. But I just built in and I made use of default. For example, in all of Fedora we nowadays ship things so that every service gets its own instance of slash TMP which solves a huge amount of security problems regarding slash TMP. So yeah, for us it matters that security is built in and it's actually we consider it part of service management and not an optional functionality. Something, yeah those are, these are completely random features that we just picked. There's a lot more in system D actually. So let's focus on three small things that are coming up very soon. There's one of them is apps. Apps in the sense having app images that are basically you can run on every distribution and they will just work in a secure container which we have been working on with the GNOME people. It's not quite right yet and will still take a while. But it's a real integrate very closely with system D simply because we believe much of the enforcement of the sandboxing needs to actually live in the kernel layer and needs to be facilitated by the lower levels of the stack and shouldn't be something that's just bolted on top. Of course apps are something like we believe it's actually important that if we do apps we need to do them right so that they work through all the distribution and not just one. And yeah. So the next thing is KDBus. KDBus is something we have been working on for the last months and it's actually in really nice shape already but not really shipped yet. KDBus is actually a port of Dbus into the kernel. There's traditionally this weirdness in Unix that most operating system started out with a good IPC system and then built everything on top of that. This is different with Unix because we never had a good IPC system. We had a couple of IPC primitives like FIFA's and then later on sockets but we never had a real IPC system with massive quality these kind of things. Like I mean they've probably heard people around here they're probably are fully aware that the way heard started out was a very good IPC. Now our approach to make Linux can have one standard API there for IPC is KDBus. KDBus basically translates the semantics that user space Dbus had into the kernel and it's really nice design. If you're interested then we can talk to you later about that. It's zero copy and you get it's really nice. It's highly efficient. It's even so good you basically open it up. The reason we want to have that is also for the app stuff because we believe it's like the primary way in and out of it should be the primary way in and out of the sandbox of a container and it has policy attached to it and you can actually use it to not only do control but you can actually pass real data on these kind of things. It's a fundamental step ahead. KDBus of course is something that is inherently the user space inherently built in system D because we use things like shortcut activation share a lot of code and things like that. So it's unlikely that anybody but system D systems will have this ever. Then we work with the Wayland people who have this log in D component which already manages seats and devices attached to seats and sessions and things like that. With the Wayland people we have been working on making sure that Wayland if it runs can run entirely in privileged but then it still needs a component that can actually give access to the actual physical devices the device notes. And the way we do like we came to agreement with the Wayland people in this regard is that log in D will just hand them out because it keeps track of that anyway and the code to actually open this would be very simple and log in D is privileged and Wayland wouldn't then have to be which of course is yeah it's really nice for robustness and security. Then we have integration with containers with NRAD and EFI which are all kinds of nice things like with containers for example we have defined a specification that most container managers nowadays follow how containers can pass the UAD into it and a couple of other things like how they have to set up the environment for a system the system so that everything just works because traditionally if you ran something inside of container you had to change the operating system first like we had to remove a couple of things from FSTAB and these kind of stuff and remove a couple of in it scripts with system D it is our absolute attention that things just work right so that we carefully made sure that on Fedora at least we can boot the same image on a bare metal on a KVM and in a container and it will just work and always boot up cleanly and there's integration with NRADs which is something that we did for for Drake it so yeah you can run system D inside of the NRAD which is incredibly useful it's one of the results actually Harald is going to do talk tomorrow about Drake and about this specific stuff but it's actually has this nice effect that nowadays Drake is faster in transitioning to the host OS like it shortens the overall boot time over the kernel doing it without NRAD at all right which is an amazing result and it allows NRAD systems to even do without shell scripts in the common cases yeah it's how things become fast there's integration with the EFI boot loaders and things like that surpass performance data around so actually system D already mentioned that it has all these profiling tools built in so after boot up you can actually type system D analyze and we'll tell you okay your boot up was slow because so much time was spent in the bias initialization so much time in the boot loader so much time in the kernel initialization so much time in the NRAD and so much time in the system D in the host so yeah it's nicely integrated all of this is kind of optional lose integration so there are no requirements made or anything like that and system D will boot in any case anyway we have integration with security frameworks IMA, SLNX Mac everything that people want to use they just work right and they have written in a way that all the security transitions happen at the earliest like policy loading things like that happen at the earliest possible point so that every user space code that runs will only run with the policy applied we have comprehensive documentation like we have a huge body of man pages some usually people figure that out like because most people say oh it's badly documented but if they actually look they will notice that we have man pages for almost like really everything and we have a series of block stories and there's lots of community documentation there's even like articles and papers whatever else you want and it's actually user friendly since we have been doing development of three years like for example journal control like you might guys might have heard of the journal like this logging framework of system D some people hate it just the idea but actually if people actually ever touch the interface how they can actually access the journal which is journal control they will notice it's an incredibly user friendly thing because you can filter very, very easily you can, you get colors you get auto-paging you get like separators when the reboots happened you get them everything is just really nice to use and most people who automatically say oh my god it's an awful idea doing binary logs and things like that soon as they get into touch with journal control notice it's actually friendly this doesn't mean that people wouldn't have to learn anything right it's user friendly but it's of course different from the stuff that was there before there's a certain learning curve there's a learning curve in everything we do believe though that the learning curve for the system need tools is much, much lower than the learning curve as for actually dealing with a classic system 5-init script the thing of course is that people currently most people know system 5-init scripts and system D is less known so yeah you should try it if you will figure out that it's actually much nicer that for example you see it in every possible way like for example system control status shows you the current status of a service now the most interesting thing about that is what we believe is that you actually see the log output of that service right what is it good knowing that the service is still running if you don't know anything of what it's doing usually what services are doing they're locked to the log files the system control status will always show you the last 10 log lines of everything it did so yeah it's incredibly useful you should really try it if you haven't something to say is we provide compatibility with system 5-init to a fairly large degree I can't read that okay we provide compatibility to a fairly large degree with 95% there's 5% we do not support and generally those are init scripts that do weird things like for example accepting additional parameters after the start thing on system 5-init command line basically which is outside of LSB so our approach there is yes we will admit not 100% compatible very few things are which are not system 5-init but we will document them in detail and we can say well in LSB this was already not supported so don't really have blame us the net effect of that is in Fedora we currently have more than 80% of the packages converted to system D but basically everything that matters is converted to system D and so this is really proven to actually work really nicely yeah I only got 10 minutes so let's skip this over a little bit faster I know Unix are not Unix I know that a lot of people think Unix is the only thing the only religion that is worth living for I don't know if you say it's not Unix and I can tell you 10 reasons why it is Unix like for example I don't know Unix means this thing that everything is a file in the file system system means that much more because we actually turn all the services into actual file like I have representations in the file system in the C-groups stuff and there's a lot of other things like for example the multi-seat stuff is something a truly Unix idea it was built into the terminals that have been invented like 30 years ago they kind of fell to the wayside people only used them for debugging service but that was about that we bring them back it was actually native multi-seat support that just works so yeah anyway I can give you some reasons why system D is more Unix than everything that came before in a way but then again I don't think that the question actually matters right Unix for us is an inspiration it's probably the biggest inspiration we have but ultimately our goal is not to be the best Unix our goal is to be the to write the best operating system so we look actually everywhere we look to Solaris we look to Apple like Mac OS we look to Windows even and if they have something that is nice that people are like then we should actually think about adding something similar to our stuff if it's really good and if it's what people want so yeah I don't think the question whether something is Unix or not matters but again I'm happy to fly this out with you because you still believe it's not Unix anyway there was I posted a blog story a couple of months ago about 30 myths about Unix about Linux one of them about system D one of them was about the Unix thing or not I invite you to have a look at that so the why not for us Linux is what matters that means yes it is true we do not care about portability to other operating systems meaning free beast or whatnot we care about portability absolutely but not about the other kernels yeah this is the thing that you get the reason we do this because we expose so much functionality that hasn't been exposed before like C groups and all the properties and all these kind of things we can't do that if we wouldn't decide on which kernel because much of the functionality is simply not a viable on the other kernels and I know that if people say C groups oh you could just use BSD jails it's just complete bullshit you can't do something very very different anyway so by like we actually have a goal to empower the administrator with all the functionalities that Linux provides them with and that's a lot of stuff and previously that was not visible because everybody tried to to use the minimal set of Unix only like POSIX but POSIX is a standard that is by definition minimal and always out of date so yeah for us Linux is what matters we actually want to give you the features the other thing is we work on one foundation of an OS not on hundred different foundations this means that we actually do remove options from time to time that doesn't mean that I mean most of the time these options really don't matter like for example in SystemD we have nicer support for the Utilinix version of Getty than of any other version of Getty like you know Getty is this weird thing that just asks for a password on the serial on any kind of TTY it's one of the most trivial programs in the entire stack right it just asks for a password and starts a session but there were so many different implementations like Mingetty and so on we just saying from the SystemD side okay we ship you everything so that A Getty just works out of the box if you want to do something else it's up to you can do that this is how you do it go ahead knock yourself out however we will only support like one because we think this one is the best one and this one is because it's a boring question nobody cares about what Getty is used because it's so trivial so yeah and SystemD is not a ready product right SystemD is something you have to build an operating system from like you have to build Damian from Fedora from or what not it's nothing that will it's nothing that you can install an existing system will just work it's not supposed to be it's something like this basic building block and not the house that you can build an operating system from and we are fast there's the progress of SystemD is there's a quick pace to it right we do releases frequently we do new stuff all the time we make decisions right because I mean often frequently in open source people are incapable of making decisions they instead of saying this is the way it goes they say well let's do everything to make everybody happy we're not like that we will make decisions yeah our upstream releases are focused on development right if you take the SystemD thing you get a series of releases and they will always bring new features usually slightly quite incremental but they are not the versions that are ultimately stable however we help you with QA right like for example we will adapt in SystemD now that for every commit that we make we will actually tag it with whether this is something to backport or not the reason why we do it that way instead of actually having a stable branch like most other projects do is because this is after all this basic building is basically that all the distributions have to incorporate it anyway and they should pick a version they think is relatively stable and this will for all the distribution usually be a different one however you want all of them have the chance to integrate the patches so instead of doing the QA entirely upstream we will help you to doing a downstream like for example I mean we support this now in RAL7 so we will have a lot of patches flowing into that we will tell you that upstream the ones that we support it but most likely you're running a different version anyway because Fedora throws it because Debian throws it at a different time than Fedora or RAL and yes so we do remove options from time to time from the base OS because we don't find them interesting but there's always the chance to re-edit locally or do something else yeah so you won't get everything you might want but you will get a lot of it and if you get something if you don't get something we'll at least get things that way and we will help you to find maybe a different solution or yeah try to find something how we can make this work so I already mentioned this there's a learning curve system D is different from system 5 however ultimately I believe the coming from 0 the learning curve to system D is lower substantially lower than coming from system 5 in it coming from going to system 5 in it anyway this is my last slide we're really happy about that specific participation in the system D project and we hope this will continue even closer than before most importantly we invite the Debian community to contribute more and join the project so that system D can actually be driven in the direction that Debian wants and open source it's generally the way that the people who write stuff usually decide more than others where things go we want system D to be this generic thing that everybody can use and drive in the direction currently there are people driving there are people from Intel driving in the direction there are people from Arc Linux pushing into the direction that they wanted yeah we would invite Debian even more than they already do to make it work for them the way they want and we'll make sure that we do the best make the best out of it so yeah we want you in the project and we want your influence in the project and that's all I have for now I think my time is over but do we have to leave the room immediately otherwise we could still do questions okay then let's do a couple of questions I see somebody raising his arm it should be I was just saying thank you Leonard for all your body of work on system D and everything and my question is when I've tried system D and ran into a failure mode where the system wouldn't boot and would say hang with a blank screen or without much information you can go off and look at the wiki and see various workarounds to figure out the bug but all these workarounds seem like things that an inexperienced system might have trouble with say if they were my mom being helped over the phone with a problem so is there any work on getting system D to boot to say a root shell if it's booted with an emergency parameter or something and always work and be able to let you debug it so in general that's what happens actually right you know if for example a hardest doesn't show up and we run into time out waiting for it we will put you in a shell we will give you a little bit of an 5 minute time out I don't know what the current time actually is and then there is a hint given now type journal control and you get actually the logs and what's nice again about system D is that even if this happens in an NDRD you get logs because traditionally or if it happens during early boot before syslog was started because in traditional unique system syslog would be started relatively late and only then you get logging and before you were a bit on your own it's if we managed to detect the error properly and usually we do because there are time outs on everything that we do then we also give you in one line when you got the shell type this and you see what actually happens and then you get the entire stream of logs from the kernel from the NDRD from early boot interleaved nicely and it hopefully gives you an idea of course looking at log files is a nice thing it's not always what people want because it's usually tears English language that people have time to understand we have a project there to make this more user friendly which is a daemon can actually attach a message ID to their messages basically they would say okay if the sector is bad the kernel could send a message ID for all messages which say that the sector is bad and then Journal and Control will actually already link that up with a catalogue entry which explains in more detail what's going on and includes hints what to do but it's actually empty still I mean there are basic texts in there but it's not super useful but I figure as we go ahead with REL this will probably be covering more ground and then systemally many of the errors are actually already equipped with message IDs and so yeah I figure that over time things will be much more nice in that way of course we will never be able to catch all errors like there's always things that you cannot catch but just mention it the thing is that as mentioned already profiling and debugging all these things are built in and there's you can boot with on the kernel command line with debug right and it will turn on kernel debugging it will turn on systemally debugging it will get really really elaborate thing on what's actually happening why systemally starting that and what's it doing now there and things like that so tracing, profiling debugging is all built in by default it's easy to reach and for example in the debug case we just hooked up a little bit more to it so that people should actually be able to discover that without having to actually check the documents if they are lucky enough to know the kernel debug option of course because Debian want to be the universal operating system and there are now other kernels coming for instance K3BSD or there are some activities as you heard and there are a lot of things so I do appreciate for the start to restrict on Linux on Linux kernel but is it compatible on the long term or for an operating system who want to be universal so I don't think that it makes sense to port Linux systemally to other kernels so it's not I mean we use so much functionality it makes things really really nice I don't think though that's much of a problem right if Debian managed to port the entire distribution to different kernels like you know having two different kernels is way more work like because you have the tool chain you have to have the build system and everything else than just supporting two different init systems so my recommendation for Debian anyway my recommendation was Debian would simply just I mean you have the system five init scripts and all the packages anyway so just leave them in and that's how I can support your other operating it's not my personal problem of distribution so I don't know I think we should really give people the chance to make use of Linux with all the functionality it has and not limit us to a more minimal thing just because some people use something else so one point that you made in your talk you said that that socket based activation would allow to improve density for containers that assumes delayed activation now one of the arguments that was made in discussions on Demi Devella is that socket based activation is not intended to lead to delayed activation and I think you can't have it both ways oh you can well you can't have it both ways simultaneously oh you can either either you are allowing delayed activation to enable your improved density as you say or you are spinning things up immediately and if you have any kind of high availability any kind of service monitoring your services have to spin up you can't simultaneously have the improved density from not having things spun up until they are needed if you care about them being available and proving that they are needed because in any sort of internet based service the most important metric is time to response just whether or not you can get a connection and obviously delayed activation means you don't have you are going to have delays while things are being spun up so my question to you is do you have anybody actually using this kind of density in production and what is their use case for that so there are a couple of people like who do do the service like they are for example a company called Pantheon which uses a lot of socket activation like that Pantheon does Drupal service where they basically socket activates this thing that you have a one click sign up on the website where you can say I want to have my own Drupal service 99% of those people never actually started up or if they do they started up once and never do that again so this is about of course if you do the delayed activation then you can do that only if you have a very uneven profile about who use what but as it turns out this is probably what most toasters have because websites are yeah so in general like system new services can have multiple triggers right they have can have a bus trigger a socket trigger a hardware trigger they can be started at boot up and system you will combine all that and spawn things on the first one that comes in so it's completely up to you if you use socket activation as an amazing paralysation technique that allows you to drop all the dependencies between services or if you use it as lazy activation to take okay thank you time is over okay then let me say one last thing if you guys have any questions and we'll probably be outside there on the green lawn and be happy to answer anything we have you might have so thank you very much for your time I hope this was helpful