The Tragedy of systemd

right thanks everybody for coming and please welcome dinner rice so I know this may come as a shock to some of you but I have opinions so this is one of those talks where I started you know I had a kind of idea and I came up with the title and suddenly it all started to really come into place because you know especially when I looked up what tragedy what wikipedia said the tragedy meant which is a form of drama based on human suffering that invokes an accompanying catharsis or pleasure in audiences and I figured that was enough suffering in this whole subject to go around and you know hopefully I can deliver some pleasure on to my audience another big influence on this talk is a piece that everyone should have read by now and if they haven't please go read it it's by Oren sure it is called contempt culture the gist of that piece is that people use contempt as a social signifier it's and the piece itself is largely based around language communities so the Python community rags on the purl community and the purl community rag on the pH of he community and so on and so forth but a lot of the concepts in it are largely applicable outside of that and the last concept that really fed into this talk was change change is a tricky thing has changed threatens what we find familiar and familiar is nice familiar is comfortable but that doesn't always mean that it is good and it certainly doesn't mean that it is still good now if it's been around for a long time so someone also told me that tragedies come in five five acts so let's start with Act one so in the beginning there was eunuchs well there was a lot more before that but for the purposes of this we're gonna start with eunuchs eunuchs was a happy accident if it had not happened at the place that it did in the time than it did in the way that it did it just would not have turned into the thing that it did it was a reaction to a bunch of previous systems in that it was brutally simple they looked at a whole lot of the other systems that were on offer at the time and went you know what this is just trying to do too much we can be better than this we just start with the small stuff and work from there and it takes this brutally simple approach to bootstrapping itself and especially in bootstrapping user space this is the manual page for a net it says in it is a voted and last step is the boot procedure generally its role is to create a process for each type Pro moving on when it comes up multi-user it invokes a shell with input taken from the file at housekeeping functions for several times the creative process for each type right sorry that's seventh edition UNIX from 1979 it you know it the thing is though it still sounds pretty much like what the old-school in it does but one thing that you know I really bumped on when I was reading through this is the phrase housekeeping functions like mounting file systems and starting daemons there were two things that one I mean it it would the main the main thing that really got me on that was that they'd lumped those two together and I'll get back to that in a sec though but given the context of what demons meant at that time this is the PS output on PDP 1170 running seventh edition unix as you can see there's not much going on there in it has been forked several times to two actors four terminals or typewriters you've got cron there and updates job is to write this file system super block out every once in a while so that it doesn't go away and the things you know it didn't change all that much over time like this is VAX eleven seven thirty running four point three bsd and as you can see things haven't changed all that much we've actually got a proper getty there and for those who don't know getty is the thing that handles serial consoles which something you should ask grandfather about or grandmother sorry and it's got a route d in a nine eight d and a couple of telnet DS and that's kind of where things started to get interesting because I net D is was the kind of a service super demon if you like its job was to listen on all of the sockets that something could connect on and fork off a process to talk to it when it came along and that worked really well up until the internet happened just before I move on big thanks to the living computers Museum and labs who gave me access to those machines to get the the screenshots they will also give you access to if you ask them nicely I'm for whatever you want to do on a PDP 1170 so the internet happened that I net D model was great when what you were doing was dealing with a small amount of stuff going on like the amount of traffic that goes over a telnet connection is not actually all that much and there's not a lot of state going on that isn't ephemeral if the connection drops then you just reconnect and you get your state back some other way same with FTP same with pretty much everything that dinette D handled the web looked like it would work that way and then it became really really really popular and so you end up with situations where forking off a process to handle every single connection doesn't really scale that well then you also get these rather annoying things like databases where you have a ton of persistent state and you don't really want them to go away in between in vacations and so this leads us to what we know these days as a service it's kind of a superset of a daemon there quite often encompasses multiple demons or a whole bunch of clones of a demon or various various things like that a contiguous set of processes and behaviors and in it old-school in it can start these things but they don't really get involved with managing them after that they just kind of stand them up and then walk off and if it falls over they go and even with system five features like init tab which can restart things because the only thing that is the gets restarted properly on old-school UNIX systems is get E Getti will get restarted as terminals come and go with system v init tab let you specify other process to do that but again it's just if this process crash has restarted it's not particular the granular and that's not the only thing that in it and etc RC had to do so coming back to this quote it conflates mounting file systems and starting daemons these I think are two separate but very kind of related things one of them is system configuration and by configuration I don't mean editing files in etc I mean like you know when when a pilot lands a plane they put the plane into a landing configuration with the slats and the flaps and various settings system configuration is making sure that your file system is mounted that your interface is configured these things are kind of set and largely forget but it conflates these with service bootstrap which is start that daemon and then walk off and don't care anymore and this gets commingled in a bunch of ways that we don't often see because we're really familiar with it and it really gets in the way of things like automated service management because that's not there in this set up and that's where things like upstart and system D start to show up because they deal with the services that services that need a more active management before we move on to other things let's look at some other operating systems Windows NT had a very strong will has a very strong service model that came with it from the very start a lot of it was based around a particular process called SVC host which led to a whole bunch of things like security issues and stuff like that but in general its service model including starting stopping restarting auto restarting and all that was there from the beginning and a lot of this comes from it's sort of heritage as being coming from one of these way too complicated operating systems the UNIX was railing against another operating system that has a very good service model at least these days is Mac Oz and its derivatives like I asked watched us TV us and car us and whatever else is coming down the pipe when they release stuff so Mac haces application model also gives you a bunch of interesting stuff in that it allows you to have a much richer interaction with your host Mac OS and iOS applications generally take the form of an application delegate that receives a whole bunch of calls in from a surrounding environment that tells that the things are happening like you started you're going to quit now the system's running low on memory and if you don't do something about it I'm going to kill you things like that the other thing that came out of Apple was launch D which is a good point to go to act - so what even is system D when you actually get down to it so starting off launch D launched he showed up in macaws Tiger it rapidly took over most of their the sort of service handling stuff in Mac OS and it replaced almost every single what I would call event handling daemon in the entire system so it took over in it it took over cron and at it took over I net D and it expanded from this I net D like concept to go hang on I've got all of these sort of service providing daemons that form part of the system that don't need to be running all the time but they need to be brought up when we need them and so it can listen on not only TCP ports and UNIX sockets but also mark ports and things like that so that it can start these service demons as they're needed and once you've got that you don't need to start them at boot time and that speeds the whole thing up it also can restart things if they need it if they do need to be started then it can watch the process if the process exits it restarts it great so the idea of launch D was to move as many system services as possible into these demons that could then be started as needed because when you think about it the actual underlying system when you're talking about a system like Mac or Windows or even like Linux if you're running a desktop spin with gnome or KDE or something on it is a lot bigger than you think so on Mac OS the services get started with something asked for them which means you improve boot times you improve Parkins sumption you can improve security by making the access to these things granular and Apple can do a lot of this because it's got this pervasive use of mark ports and messaging systems underneath it that it can use to do this one of the things that I pointed out because this talk started out as a as a keynote for BSD conference one of the things that I'd like to point out here is a lot of the bsd people who like to gripe about systemd if you actually say oh you could you could you know why do we do launch it yeah like launch D and it's like you realize that system D is basically a ripoff of launch D right because five years after launch D this guy that no one's heard I've called Leonard puttering was looking at upstart and a couple other things and didn't quite like what he saw up start which was a an older startup mechanisms usually used on Ubuntu I think it was event-driven like launch day and system D it still used shell scripts it could handle more event types than an int which is not hard but lennart seemed to feel that it didn't do enough with dependency ordering and had a bunch of other things missing and so you can find this blog post this is basically where he introduced the notion of system D it goes into detail about the rationale behind it and so a couple of interesting quotes for a fast and efficient boot up two things are critical to start less and to start more in parallel it doesn't really go into it's not overly concerned with boot speed but that sort of gets a gets in and as a side thing and in its system that is responsible for maintaining services needs to listen to hardware and software changes this is exactly a kind of thing that the Mac OS and iOS do really really well when you are a modern operating system you live in a much more dynamic environment and yes even if you are running on a server or a virtual machine then you used to and a lot of these things need to be dealt with and a lot of these things come in as events that need to get handled and so if you move from the notion of system bootstrap to I'm going to handle events then system D does that really well and he literally sites launched D as an inspiration in this is this kind of logic new it is not it is basically launched D and I get the impression sort of from this that Leonard Leonard likes a lot of what Apple does even if he doesn't like their implementations of it because his previous projects before this were an implementation of apples Bonjour system and an audio system that he directly compares to apples core audio so we've kind of evolved here from a service manager to a system manager and again there's parallels with Apple here because system D like even though it started as an init system sort of rapidly spiraled out and started taking on other things which you know in one way as a fairly logical reaction to this we're going to react to system level events but I think what they rapidly came across is an idea that it took me a while to again on to to a lot of people think of a system as having two parts user space and kernel you know the kernel looks after the hardware and things like your TCP stack and user space runs daemons and whatnot but a lot of things that used to be static in the kernel are now a lot more dynamic I still remember building my own FreeBSD kernels and basically having to say this card is on this is in this slot with this irq and this kind of stuff and now that's all dynamic and it can change a lot more networking is a lot more dynamic DHCP my pv6 Auto config all these kind of things are more dynamic time is more dynamic some aspects of device handling you know all of these things are a lot more dynamic now and we need a way of strapping these things together so we can manage them that doesn't involve installing 15 different packages that all behave differently and so what that ends up becoming is what I term the system layer which is a bunch of stuff which might be running in user space or might be running in kernel space but is providing systemic level stuff as opposed to the stuff that you're writing or using directly so this could include things like network manager and you dev and a whole bunch of things and systemd as a project ends up complementing the linux kernel by providing all of this user space system layer it doesn't do it in a way though that is familiar to everybody who's used to the old way of doing it and but it does mean that people can stop reinventing this by strapping together 15 different disparate packages that all have different configuration file formats and different behaviors that can be a possible source of angst but it does sort of explain a bit better the reason why you would inhale that other functionality so how does this work in reality so system they actually got fairly widely adopted not universally these are all of the the dates of which system D entered particular distributions and between these distributions here you're covering like the bulk of the installed base of Linux I would suggest I don't know that for sure but you know some will probably come up and tell me if I'm wrong Debian is an interesting one on that one because they had a very long debate about whether to take it in which was understandable given that they have multiple kernels that they run on the you can get Debian on the FreeBSD kernel if you so desire and there's a you know there are a bunch of arguments there and the really nasty bit is that they ended up going with it but a lot of the people involved in steering that discussion ended up resigning and yeah so the next bit that I want to go through is some of the more common arguments against system D that people tend to advance it violates the UNIX philosophy this this this one I often find is predicated on the notion that system D is one binary because you know if you were good if you were to have a DHCP client and NTP client you know that all in one binary yes I would agree with you that that would be a bit silly but it's not a bunch of separate binaries that are all in the one project and being a BSB person I do kind of understand the notion that you want to bring a bunch of disparate code into one repository to manage it centrally and the next one is that it's bloated and monolithic again it's not really a monolith I can kind of understand why people get bent out of shape that it's inhaling a bunch of other projects functionality but I do understand why they're doing it to some extent and so you know I'm not particularly worried about that it's buggy its software the thing that the thing is though that this argument comes in a bunch of forms I mean yes system D has bugs and yes they're going to stand out because it is such a core component to that level but they all they're also seem to be a sub variant of this we're like oh well if you're gonna write an init you have to be you know this bug free in order to drive which makes it really raises the bar to replacing that particular bit of code and I don't think that's the right way to do it and I mean that it also has a reasonably good failure mode where just instead of actually crashing and taking the system down it'll go catatonic so you can at least choose the point at which you reboot but in general I mean I do sympathize with some of the bugs although there was a recently a rather fun an instance where there was a bug in Journal D that I believe led to code execution some little-known hacker named Matthew Garrett pointed out that in his opinion at least the moral is don't use system D the moral is you know maybe don't use C for these things to which there was a responsive of you know actually it means don't use system D and so on so forth - which Matthew replied with this which needs a little bit of explanation in that Howard Chu is the chief architect of the open LDAP rotate and that link was to a list of CVS in open LDAP all software has bugs some bugs are gonna be security issues systemd does have some fairly impressive bugs like that Journal debug that were allocating memory on the stack don't do that but that said I think that there's an important distinction to be drawn between system D the implementation and system D as a set of ideas on top of that another another one that people like to come up with is this one I'm not going to defend limits approach to community interaction but what I will say is you know you have to admire the willpower and determination of someone who at work one day goes I'm gonna write my own in its system actually know it's going to be a full on system layer for Linux and takes it to his management and goes hey I'm gonna do this and they go no and he goes no way and then he comes back with it and it works and then he gets it put into pretty much every major Linux distribution there is something to be impressed by in that even if you're not impressed by his attitude on the github bug tracker or whatever else another one that is particularly interesting to me is it's not portable now this interest to me because for those who don't know I'm a longtime FreeBSD developer systemd is aggressively Linux specific it uses a whole bunch of Linux specific process maintenance hooks that just aren't present on other systems and so if it becomes the sort of established way to manage services it runs the risk of isolating the other platforms that don't have those things but it gains a bunch of really important functionality from those things cgroups is a really interesting thing you could argue that it should stick to more UNIX II interfaces doing these things but the reality is that UNIX is dead so UNIX was all about maintaining portability across a pathologically diverse range of platforms when when the UNIX notion came out when POSIX first showed up what it was there for was to make it so that if you wrote code on 4.3 BSD on your VAX I don't know if POSIX was around at that point but it was not too far off it would also run on sun offs and ax and whatever digital UNIX was called at that point and so on and so forth like there was just these enormous lis disparate range of of UNIX platforms of things could run on and so everyone kind of needed to agree on how to do that these days I think you've basically got Linux and some rounding errors I'm sorry to all of the Solaris devotees out there and I'm saying this as someone who has spent a large amount of his time and knows a significant amount of his career to FreeBSD FreeBSD is no longer in a position where it can go hang on we should do this with an interface because the entire Linux community would just go oh I don't care whereas Linux can go okay here's cgroups take it or don't it's an interesting position to be in the so we've got we've gone from this pathological diversity or a pathological monoculture where one platform can effectively dictate what the terms are system D gains a great deal from unique using things that are not Unix and one of the things that I pointed out when I first gave this talk is that this doesn't have to be a net negative because it means that FreeBSD and the other projects could also feel similarly liberated and try and create whatever they wanted to without having to go hang on what does Unix think of this so and cgroups is the thing I keep coming back to it is cigarettes is a really powerful mechanism for creating manageable groups of processes I mean previously came up with jails ages ago but when I look at jails they're a lot less flexible and a lot less granular than what you can do with things like cgroups another thing that I think that systemd gets really right is the notion of user level units as if you want to do a user space daemon as in a daemon that starts up and runs as you without you having to become root to install it on you know FreeBSD that's really hard you basically have to write in a shell script that's then gonna sudo su as you and do all that kind of stuff with system D I can just drop something in a directory in my home directory and if the things set up right it just starts I mean the other way you can do that is to play around with cron but playing around with cron is can be fun so it all comes back to change system D represents a large amount of disruptive change which brings us to the actual tragedy of the piece so yeah people have a complicated relationship with change I like to say that nerds especially have a really complicated relationship with change we love it to pieces changes awesome when we're the ones doing it [Music] as soon as change is something that's coming from outside of us it becomes untrustworthy and it threatens what we think of is the familiar people like me grew up with a notion of you know in it runs RC and RC runs a bunch of shell scripts and then the system works and that familiar might be you know it might be good to us because it's under way under stand it it's our comfort zone it's what we're used to but I think at this point like a system bootstrap that relies on shell scripts and relies on understanding how those shell scripts work and interact and are ordered is kind of like you know the old tired old blankie that we maybe should have you know handed off about 20 years ago and you know persistently represents change and it resent it represents a really disruptive level of change and it represents change that was pushed on us by people like Leonard pottering whose ability to have sympathy with the people whose ease asking to change doesn't appear to be the greatest but what this leads to is a knee-jerk reaction because the lack of sympathy isn't just on Leonard's side the reaction the reaction to system they've got a little bit over the top in some places I think abuse is not cool no one needed to send death threats to leonard puttering over a piece of software [Music] and it's not just abuse contempt is not cool and this was one of the things that I really wanted to ram home when I gave this talk at bsd can freebsd should not be proud of the fact that we don't have a system d we should see that as we're lacking something like we stop if we see if we're mocking system mocking that the fact that linux has system D and all those poor Linux users with their terrible software then it means that we're treating it as a joke and not as a source of ideas and that doesn't just apply to FreeBSD it applies to pretty much anyone who sits there going oh no that system DS terrible it's like no look at it a bit and one of the biggest problems that I had with the FreeBSD community on this one was things like this because to me this says on behalf of my community come join FreeBSD we'll never change we refuse to move forward into the future yeah anyway and so really what I want people to do and they look at saying like system D whether they like it or whether they don't and especially if they don't is why why did system D show up why is system D important it's thinking about that means that you suddenly go hang on so is system D solving a problem what problem is it solving could I solve it better because one of the solutions if you don't like system D is to go and make your own at the very least you're going to find out how much fun that is and then another angle on this is that it's not just about us Greybeards the next generation of people who are coming into IT coming into software engineering coming into systems administration they don't necessarily think about the systems they're running in the way that we do or that I do they see a lot more api's in the sense of like web api is like the you know 20 years ago me going oh yeah I can spin up a UNIX machine by punching a HTTP API on it on a bookstore that would blow me away back then and also things like containers thinking in containers ends up making you end up thinking quite a lot differently than thinking in not containers so and so forth and so this brings us to the last bit what does systemd have that we could learn from or what does it offer us so this this is a section in the original talk where I basically told a bunch of BS D people what they could do if they had something like that but I think there's a bunch of interesting like if you if you go up to the higher level of what system D has there's a bunch of really interesting stuff to think about messaging transports this fret system D makes heavy use of D bus I'm not a big fan of D bus but I am a big fan of messages Apple uses mark to do the same kind of thing one of the things that I told the BSD people was basically we should write our own message transport my version if I were to write one would be kernel resident rather than user space and it would allow a lot more sort of security and authentication and access control elements on the actual bus endpoints but you people can write your own because once you've got a message transport it's a lot easier to write an RPC framework and the question is why would why do you need this and the answer is because if you you need a leveling mechanism to make the kernel and user space operate at the same kind of level as far as the code above them is concerned you don't want to know whether a particular service that you're talking to is handled by the kernel or by user space you just want it to happen you want to be able to send out an API request that says okay network interface take this IP address and just have it happen you don't want to have to worry about you know am I talking to the kernel or not the other thing that systemd gives that a lot of previous systems didn't give you as a proper service life cycle you know as I said Windows had this from inception inception Matt sort of organically grew it and then once they did once they came up with launched you sort of massively pushed towards it and and does this without you having to install a you know one of several different systems that all work differently like open RC or or run it or supervisor D or any of these ones automation via API sounds blithe but once you can automate the setup and configuration of a system through an API that isn't sort of having to shell out into system calls or anything like that you've basically written most of what an appliance vendor would need in order to make a really good appliance so you can think that things like open on wrt could use it but then in my case I used to work for a company that made large storage appliances would have made our job a ton easier to have that kind of thing and I think the last really important thing that things like system D enable through the use of things like C groups and stuff like that is containers I think containers are really interesting not because I think that they are the savior of security or anything like that but just because they provide you with a way to to encapsulate things in a way that's quite cool and so system D providing the system layer gives you a more consistent platform for doing that kind of stuff and the the barrier to entry for building something on top is like an appliance is massively reduced but again system D doesn't have to be the only implementation of this you should go and explore but moving on I think that the way system D names devices is actually really good and I say this is someone who used to spruik the freebsd notion that every ethernet driver should have its own name but and while i also did not like the solaris naming scheme of like c 0 t0 4 disks I think that having consistent names that are generated on physical attributes of the device is a lot better than having them named after what random order they happen to show up in I also think that system DS model of logging is really good binary logs are not a bad thing as long as you have the tools to pull them apart but having append-only logging in a system like that especially append-only logging that can be shipped off somewhere else easily is I think very handy but the other thing is that with containers and a whole bunch of other things you get a new model of an application an application no longer has to be a single binary or a single binary that starts off other things it can be an encapsulated series of things that are managed as a unit I think that's really powerful I think it would be really interesting also to look further on at how you would do a Mac off style application on a platform like Linux being able to provide a lot more feedback from the host system about what's going on so that it can react to it so at the beginning of this talk I showed the Wikipedia definition of tragedy and it mentioned that it was causing catharsis in people so definition of catharsis meaning a purification or cleansing would be purification implication of emotions particularly pity and fear through art or any extreme change in emotion what I hope that this talk has provided is a removal of fear and particularly a removal of pity of system D and the people who actually use it the world is changing around us and we can either get with the change or we can try and resist it and this applies in so many ways it's not just software there are a whole bunch of changes that go on that we should we really need to logically evaluate and work out whether we're on the right side of we can try changes you don't have to commit to them until you know that they work I mean a lot of lot of distributions had other systems that they replace this and B with and worked with it so yeah what I would challenge everyone here is look at system D and try and find at least one thing that you like and then go see if you can implement it thank you [Applause] yeah I'll do some questions okay we'll put some time first of questions please tried to make sure that they are actually questions I've given this talk before and as you can imagine I occasionally get diatribes in the form of questions not in the form of questions they would have would it have been feasible for launch D to have been ported across to Linux and would there have been any advantage or disadvantage and and doing so given that Apple had already done some of the work and presumably that was open sourced as well so the problem so if system D is aggressively Linux specific launch DEA's aggressively apple specific its it uses it it deals in all with a lot of mark ports and it also is I mean there's Apple have done some work to try and make it portable I know that they offered to try and make all the Lib dispatch bits and all everything that we would need in order to do that on freebsd but it did never quite it sort of petered out because I think they're focusing on making sure that it works well for them which is fair enough in the same way that system D tends to try and work well for Linux I know you said that containers enable a whole new way of thinking about applications that can now be managed as a unit we just spent the last couple of decades getting really good at dynamic library management now this is starting to look more like DLL hell what are your thoughts on this well I think in a so DLL hell to me is more having five different versions of a library and always having your applications pick the wrong one I think containers explicitly avoid that particular version of it that said I think there's a different version of it where you might have different versions of the container running and that kind of stuff but I think that containers explicitly avoid them the same way that go tends to avoid that kind of problem by statically linking everything would you be willing to come to Linux plumbers conference this year in Lisbon Portugal and run a system D micro conference library talk to Kay and Leonard they said they might show up to but hey I really enjoyed that and I really appreciate your talk that many of us really really love change we're we're the ones saying hey you should change and we don't like it when things change on us do you feel there's been any kind of chilling effect with the reaction to systemd being so hostile that may be causing other people who have good ideas about how to do stuff saying well I'm not gonna stick my head over the parapet and I'm just gonna get shot it's possible I mean whenever you're touching code like that it's gonna it's going to cause angst I think the overreaction to system day like you know the the stuff that Leonard copped I think is good is gonna have some effect on that kind of stuff I mean the other thing though is it literally writing that kind of stuff is a lot harder than you think that doesn't mean you shouldn't try but really I think one of the the challenging prospects of bringing something like that into the world is managing the people that you're trying to accept the trying to get to accept the change and that requires a certain level of social ability that is beyond I mean he'll I don't think I'd do a very good job of it and it's one of the reasons why pushing for that kind of change in FreeBSD was something that I kind of wasn't sure how to achieve and so I resorted to just yelling at them in a keynote as a FreeBSD curious Linux user where's FreeBSD at with the next-generation clone in it there's a project called open RC that handles some of the service management bits but in terms of a holistic notion of a system layer they're a long way from that and that I think is one of the things that I find frustrating in this discussion in any discussion around this is there are far too many people who immediately default to this notion that system D is only about starting and managing services when in my opinion if you're really going to do that kind of thing you need to look at the whole thing that doesn't necessarily mean you have to do it all in one project but you have to do it with a level of holistic intent if that makes sense because you want it to be somewhat uniform and manageable thank you for expressing better than I could and much better than I can be bothered a lot of thoughts that I've had as well as you said systemd kind of swallowed up a whole bunch of previously separate system services do you have any opinions on whether they all make sense or some of them make sense and others less so okay so here's an interesting thought experiment if system D had not brought those things in but had instead worked on defining an API by which those services could be managed then they possibly would not need to be in the same project because you wouldn't be needing to keep the same level of control you could have a bunch of implementations of say the network manager API or the time management API or that kind of thing that would be interchangeable to some extent I can kind of see why they didn't go that route in that it's not immediately obvious until after you've done the first thing like once once you've pulled everything in gone oh crap we need to be able to manage that too and we need to be able to manage that and we need to be able to manage that and so you brought everything in together at that point you kind of go oh hang on if we'd actually just define the interfaces a bit better than maybe we could have avoided that that's the kind of thing that you see in sort of as an afterthought but yeah it's I think I can see the lot I can see logic as to why they would have done what the everything is there that's that they're brought in but whether they need to be there in the long terms and it's an interesting question and if you were to write your own implementation of that kind of thing then there are ways that you could avoid having to pull all those things into one thing I probably know or at least could imagine what the will you think advantage of using CMD on embedded devices as opposed to desktop and servers to start with I can think of being able to restart your surfaces on embedded devices that no one's gonna be monitoring but what are you thoughts on this if your embedded device has any level of dynamism in its environment like if things are getting plugged into it then that gives you a hook to do that if you have the the AP is for managing things like that it means that the code that you have to write in order to implement your embedded device is hopefully less it's that kind of thing you mentioned that you're given a similar talk to some FreeBSD developers or FreeBSD users yeah it did you get a lot of pushback on there and if so was there a major category of pushback that they specifically got are the only real pushback that I got was ok we were on board with the notion that we need something like it but as long as it's not system D which you know are oh well no there was an attempt to do that and including porting over a Marc ports compatibility layer so don't joke thanks for that given the interactions between the community and the system D team in both directions have not always been the most positive to put up mildly you know we're in a situation where the system D team doesn't really listen to or take on board community concerns but at the same time the community is not really listening to the system D team and their vision what needs to change both in the community and say this room and broadly and also in the system D team in order to facilitate a better working relationship going forwards that's a really tricky one that's what I'm asking it so one thing could do is watch Adam Harvey's talk about version upgrades language version upgrades because in it he discusses this notion that you have to give people reasons to change as well as just beating them around the head to say don't do that having a combination of those things would be good I think the problem that I mean I am I'm speaking from a position of profound ignorance here but where I in the system the author's position having a whole bunch of community people coming to me and saying I want X Y and Zed and they want a B and C and these people want something else and at least five of these things conflict with each other that's a really hard set of constraints to try and work within and so I can see that there would be a temptation to just tell them all to get nicked that doesn't mean that that's the right thing to do I do agree with you that the the relationship between the author's and the community seems fraught I think I don't really know the right way for them to fix it but it probably involves a lot more a lot more sympathy on both sides to some attain to that are there any particular areas you think systemd should go a lot further in I would very much like to see the messaging and RPC stuff become a lot more pervasive and a lot more thought about if that makes sense I mean I'm sure they are thinking about how that works they've been multiple attempts to get a a D bus style transport into the kernel I think that having that even if it's not necessarily D bus would be a really interesting thing to play with because it puts a lot of code on the same level and it also allows a lot more yet control and interesting security features that you could do by having it in the kernel all right we're out of time so thank you Ben [Applause] [Music] oh thank you very much

Channel: linux.conf.au 2019 — Christchurch, New Zealand

Views: 425,608

Rating: 4.6394367 out of 5

Keywords: lca, lca2019, #linux.conf.au#linux#foss#opensource, BennoRice

Id: o_AIw9bGogo

Length: 47min 18sec (2838 seconds)

Published: Thu Jan 24 2019

Reddit Comments

[u/lewisaro]

Started watching this earlier however haven't finished it yet.

I have been studying systemd a fair bit recently.

$unpopular_opinion I find working with it convenient.

[u/person7178]

Is this the same talk he did in 2018?

[u/TooEarlyForMe]

I really don't like framing this whole debate/situation as "well you just need to get over it". This is turning what is a technical discussion into some kind of feels journey that ultimately takes us nowhere.

I don't have a problem with systemd, but telling people that do have a problem with it that they just need to move on and get "catharsis" is pretentious.

[u/smog_alado]

Changing topic, I liked how the Unix v7 refers to the ttys as "typewriters", which is actually where that acronym comes from. (circa 2 min mark)

[u/wsppan]

Great talk! Made me reexamine my prejudices against systemd. Well done!

[u/Sprocketvgc]

Isn't this the same talk that was given at BSDCan last year?

Excellent watch either way.

[u/McDutchie]

I stopped listening after "UNIX is dead", around the 22:00 mark.

"All we have left is Linux and some rounding errors"? That's hilarious. On the desktop, macOS (which is definitely UNIX, and is in part based on FreeBSD) has many times more users than Linux does. On mobile, we've got Android, which is "Linux" only in the most technical sense of the word, and it does not use systemd.

The BSDs are also a lot more alive than he claims. Without them, Linux would have to do without essentials like OpenSSH.

This is a propaganda speech, nothing more.

[u/[deleted]]

[removed]

[u/SpaceboyRoss]

Saw that video like 2 days ago lol. It’s really good, I’ve been getting into these kinds of videos and they’ve been teaching me a lot.