YTread Logo
YTread Logo

The Tragedy of systemd

May 05, 2020
Well, thank you all for coming and please welcome Dinner Rice, so I know this may surprise some of you, but I have opinions, so this is one of those talks that I started. You know I had some kind of idea and it occurred to me. the title and suddenly everything started to fit because you know, especially when I looked up what

tragedy

Wikipedia said

tragedy

meant, which is a form of drama based on human suffering that invokes a catharsis or pleasure in the audience and I thought That's enough suffering on this whole topic and I hope I can bring some pleasure to my audience.
the tragedy of systemd
Another big influence on this talk is an article that everyone should have read by now, and if you haven't, please read it. it's because of Oren it sure is called contempt culture, the essence of that piece is that people use contempt as a social signifier and the piece itself is largely based on linguistic communities, which is why the Python community faces to the upside down community and the upside down community to the pH of the community and so on, but a lot of the concepts in it are largely applicable outside of that and the last concept that really fueled this talk was change, change is something complicated, has changed, threatens what is familiar and familiar to us.
the tragedy of systemd

More Interesting Facts About,

the tragedy of systemd...

It's nice, it's familiar, it's comfortable, but that doesn't always mean it's good and it certainly doesn't mean it's 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 get started. with the first act, so at the beginning there were eunuchs, well there were many more before that, but for the purposes of this, we'll start with the eunuchs. The eunuchs were a happy accident if it hadn't happened in the place it happened in at the time it did in the way it did it just wouldn't have become what it did, it was a reaction to a lot of previous systems in the sense that it was brutally simple, they looked at a lot of other systems that were on offer at the time and we went, you know what this is just trying to do too much, we can be better than this, we just start with the small things and work from there and you need this brutally simple approach to boot and especially at boot. userspace this is the manual page for a network that says it is voted and the last step is the boot procedure generally its function is to create a process for each type Pro and continues when multiuser appears, invokes a shell with input taken from the file in the cleanup functions for several times the creative process for each type, sorry, it's the 7th edition of UNIX from 1979, you know, although it still sounds pretty close to what the old school does, but one thing.
the tragedy of systemd
What I really came across when I was reading this is the phrase cleanup functions like mounting filesystems and starting daemons. I had grouped those two together and I'll come back to that in a second, but given the context of what daemons meant at the time, this is the output of PS on PDP 1170 running 7th edition Unix, as you can see, not much is happening . there it has been forked several times into two actors, four terminals or typewriters, you have cron there and the updates job is to write this super locked filesystem from time to time so it doesn't go away and the things I know it didn't change a lot over time so it's VAX eleven seven thirty running four point three bsd and as you can see things haven't changed much we actually have a proper getty there and for those who don't I don't know Getty is what handles consoles serial, something you should ask grandpa or grandma about, sorry, and it has a route d in nine eight d and a couple of telnet DS and that's where things started to get interesting because I net D was the kind of super service daemon, if you like, its job was to listen on all the sockets something could connect to and fork a process to talk to it when it appeared and that worked great until the internet happened just before moving on, thanks to the Museum of Living Computers and the labs that gave me access to those machines to get the screenshots which they will also give you access to if you ask nicely.
the tragedy of systemd
I'm in favor of whatever you want to do. a PDP 1170, then the Internet happened that the Net D model was great when what you were doing was dealing with a small amount of things like the amount of traffic that goes through a telnet connection is actually not that much and there isn't a big deal. many states that are not ephemeral, if the connection drops you just reconnect and recover your state another way, same with FTP, same with almost everything dinette D handled on the web seemed like it would work that way and then it became very, very, very popular and therefore you end up with situations where splitting a process to handle each connection doesn't scale as well, then you also get these pretty annoying things, like databases where you have a bunch of persistent state and I really don't want them to disappear over the holidays, so this brings us to what we know today as a service: it's a kind of superset of daemons that often spans multiple daemons or a bunch of clones of a demon. or several things like that, a contiguous set of processes and behaviors and in it, the old school may start these things, but they don't really get involved in managing them, after that they just pick them up and then they leave and if it falls down, they leave and even with the five system features like the home tab which can reset things because the only thing that resets correctly on old school UNIX systems is get E Getti will reset as the terminals come and go with the system v.
The startup tab allows you to specify another process to do that, but again, it's only if this process has been restarted, it's not particular how granular and that's not the only thing RC had to do in it, etc. Going back to this quote, merge the assembly file. systems and startup daemons, I think they are two separate but very related things, one of them is system configuration and by configuration I don't mean editing files etc. I mean, when a pilot lands a plane, he puts it down. in a landing configuration with the slats and the fins and various configurations, system configuration is making sure that your file system is mounted, that your interface is configured, these things are set and largely forgotten, but you combine them with the boot service, which is starting that daemon. and then we leave and we don't care anymore and this gets mixed up in a lot of ways that we don't often see because we're very familiar with it and it really interferes with things like automated service management because that's not there in this setup and that's where Things like upstart and system D start to appear because they take care of services that need more active management before moving 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 went with it from the beginning, a lot of it was based on a particular process called host SVC that generated a lot of things like security issues and things like that, but in general its service. model that includes start, stop, restart, auto restart and everything that was there from the beginning and a lot of this comes from its heritage, coming from one of these overly complicated operating systems, the UNIX was criticizing another operating system that has a A good service model, at least these days, is Mac Oz and its derivatives, as I asked them, they watched us on TV and in the car and whatever else is coming up when they release things, so the model The Mac app application also gives you a lot of interesting things in that regard. 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 large number of calls from a surrounding environment telling you that things are happening as you started. I'm going to close now, the system is running out of memory and if you don't do something about it, I will kill you. Things like that. The other thing that came out of Apple was the D release, which is a good point to take action. - So what is the D system when you really get down to it? Upon release D, it appeared in Macaws Tiger and quickly took over most of the service handling type stuff in Mac OS and replaced almost everything I would call the system-wide event handling daemon, for which took over it, took over cron and then took over I net D and expanded from this I net D type concept to keep waiting.
I have all these types of service that provide daemons that are part of the system and that don't need to be running all the time, but need to be activated when we need them and therefore can listen not only on TCP ports and UNIX sockets, but also mark ports and things like that. so so you can start these service daemons when they are needed and once you have them you don't need to start them at boot time and that speeds everything up, you can also restart things if they need to. you need to start them, then you can watch the process, if the process exits it restarts it great, so the idea of ​​starting D was to move as many system services as possible to these daemons which could then be started as needed because when you think en is the actual underlying system when you talk about a system like Mac or Windows or even like Linux if you are running a desktop with gnome or KDE or something like that it is much bigger than you think, in Mac OS the services start with something that they they asked, which means it improves boot times, it improves Parkins consumption, it can improve security by making access to these things granular and Apple can do a lot of this because it has this widespread use of brand ports and messaging below. that can be used to do this, one of the things I pointed out because this talk started out as a BSD conference keynote.
One of the things I'd like to point out here is that a lot of the BSD people that I would like to complain about

systemd

if you really say oh could you? Could you know why we launched it? Yeah, like the D release, and it's like you realize that the D system is basically a copy of the D release, because five years after the D release, this guy. which no one has heard I called Leonard puttering he was looking at upstart and a couple of other things and he didn't really like what he saw, which was an older boot mechanism usually used in Ubuntu.
I think he was driven by events like the launch. day and system D still used shell scripts, it could handle more event types than an int, which isn't hard, but lennart seemed to feel like it didn't do enough with dependency order and was missing a lot of other things, so you can find In this blog post, this is basically where he introduced the notion of D system, goes into detail about the rationale behind it and therefore a couple of interesting quotes for a quick and efficient startup. Two things are essential: start less and start more in parallel.
It doesn't really come in, it doesn't care too much about the boot speed, but that comes in and as a secondary thing and on your system that is responsible for maintaining services you need to listen to hardware and software changes, this is exactly one type The truth is that Mac OS and iOS work really well when you have 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 addressed and a lot of these things are presented as events that need to be handled, so if you go from the notion of system startup to I'm going to handle events, then the D system does it very well and literally sites launched D like inspiration in this, this is this kind of new logic, it's not, basically D was released and I get the impression that Leonard Leonard really likes what Apple does, even if he doesn't like their implementations.
This is because his previous projects before this were an implementation of Apple's Bonjour system and an audio system that directly compares to Apple's core audio, so here we have evolved from a service administrator to a systems administrator and again there are parallels with Apple here. because system D likes, even though it started out as a startup system, it quickly snowballed and started taking on other things that, in some ways, you know, as a pretty logical reaction to this, we're going to react to system-level events, but I think what they came up with quickly is an idea that took me a while to come back to because a lot of people think that a system has two parts, userspace and kernel.
You know, the kernel takes care of the hardware and things like your TCP stack and your user. space runs daemons and all that, but a lot of things that used to be static in the kernel are now much more dynamic. I still remember building my own FreeBSD kernels and basically I have to say this card is in this slot with this irq and this kind of stuff and now everything is dynamic and can change a lot more the network is a lot more dynamic DHCP my pv6 autoconfiguration everything these kinds of things are moredynamic time is more dynamic some aspects of device management you know all of these things are much more dynamic now and we need a way to put these things together so we can manage them that doesn't involve installing 15 different packages that behave differently and so So that ends up becoming what I call the system layer, which is a bunch of things that could be running in user space or could be running in kernel space but that provide things at a systemic level instead of the things you're writing or using directly, so this could include things like network manager and its development and a bunch of stuff and

systemd

as a project ends up complementing the Linux kernel by providing this whole userspace system layer, although it doesn't do it in a certain way. familiar to everyone who is used to the old way of doing it, but it means that people can stop reinventing this by throwing together 15 different packages that have different configuration file formats and different behaviors which can be a potential source of distress, but De It kind of explains a little better why you would inhale that other functionality.
So how does this actually work? So the system was actually adopted quite widely, not universally. These are all the dates that system D entered particular distributions and between them. The distributions here that you're covering are like most of the Linux installed base. I would suggest that I don't know for sure, but you know some will probably come and tell me if I'm wrong. Debian is interesting in that sense. because they had a very long debate about whether to accept it, which was understandable given that they have multiple cores running. You can get Debian on the FreeBSD core if you want and there are plenty of arguments.
And the really unpleasant thing is that they ended up accepting this, but many of the people involved in leading that discussion ended up resigning and yes, the next thing I want to analyze are some of the most common arguments against the D. system that people tend to say violates the UNIX philosophy, this I often find is based on the notion that system D is a binary because you know if you were good if you had a DHCP client and an NTP client, you know that all in a binary, yeah, I would agree with you that that would be a little silly, but they're not a bunch of separate binaries that are all in one project and, being a BSB person, I understand the notion that you want to bring a bunch. of disparate code into a repository to manage it centrally and the next thing is that it's bloated and monolithic again, not really a monolith.
I can understand why people are warping and inhaling a lot of functionality from other projects, but I do it. I understand why they're doing it to some extent, and just so you know, I'm not particularly worried about them having bugs in their software. The thing is that this argument comes in several forms. I mean, yes, the D system has bugs and yes, they will stand out because it's a core component at that level, but they all seem to be a subvariant of this as well. We thought, well, if you're going to write an opening, you have to do it.
You know, this bug is free to drive, which really raises the bar for replacing that particular piece of code and I don't think that's the right way to do it and I mean it also has a reasonably good failure mode where It's just that instead of crashing and disabling the system it will go catatonic, so at least you can choose the point at which to reboot, but overall I understand some of the bugs, although there was a pretty funny case recently. where there was a bug in the D Journal that I believe led to the execution of the code, a little-known hacker named Matthew Garrett noted that, in his opinion, at least the moral is not to use the D system, the moral is that maybe you don't. use.
C for these things to which there was a response of, you know, it actually means not using the D system, etc., to which Matthew responded with this that needs a bit of explanation, since Howard Chu is the main architect of the open LDAP rotate and that link was to a list of CVS on open LDAP all software has bugs some bugs will be security issues systemd has some pretty awesome bugs like that journal debug that was allocating memory on the stack don't do that but That said, I think there's an important distinction to be drawn between System D, the implementation, and System D as a set of ideas.
In addition to that, another one that people like to propose is this. I'm not going to defend limits. approach to community interaction, but what I will say is that you have to admire the willpower and determination of someone who one day at work is going to write my own into their system, in fact I know it will be a complete layer of the system for Linux and he takes it to his management and says "hey, I'm going to do this" and they say no and he doesn't go and then he comes back with it and it works and then he puts it on almost every major Linux distribution out there. something that should impress you, even if you're not impressed by its attitude on the github bug tracker or anything else, another one that's particularly interesting to me is that it's not portable, now this interests me because for those who don't know I'm a Long time FreeBSD developer. systemd is aggressively Linux-specific, it uses a lot of Linux-specific process maintenance hooks that simply aren't present on other systems, so if it becomes the kind of established way of managing services, you risk isolating the other platforms that don't have those things, but you get a lot of really important functionality from those things, cgroups, it's a really cool thing.
You could argue that you should stick to more UNIX II interfaces that do 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 the notion of UNIX arose. when POSIX first came out, what it was there for was so that if you wrote code in 4.3 BSD on your VAX I I don't know if POSIX existed at that time, but it wasn't far away, it would also run on sun offs and ax and like it was called digital UNIX at the time, and so on, as if there were these huge disparate lists.
A variety of UNIX platforms could be run, so everyone needed to agree on how to do it these days. I think you basically have Linux and some rounding errors. I'm sorry to all Solaris devotees and I say this as someone who has dedicated a lot of his time and knows a significant part of his FreeBSD career. FreeBSD is no longer in a position where it can hold out, we should do this with an interface because the entire Linux community would just say oh I don't care, while Linux can work fine, here are the cgroups, whether they take it or not, it's an interesting position to be in, so we've moved on from this pathological diversity or a pathological monoculture where one platform can effectively dictate what the terms are.
The D system gains a lot from only using non-Unix things and one of the things I pointed out when I first gave this talk is that this doesn't have to be a bad thing because it means that FreeBSD and the other projects might also feel equally liberated and try to create whatever they wanted without having to wait what Unix thinks of this and cgroups is what I keep coming back to, cigarettes are really I mean I previously thought of prisons a long time ago, but when I look at prisons, they are much less flexible and much less granular than what you can do with things like cgroups, another thing I think systemd is very right about is the notion of user-level units, like if you wanted to create a userspace daemon like a daemon which starts and runs just like you without you having to become root to install it.
You know, FreeBSD, that's really difficult. I have to write in a shell script that I then sudo su like you and do all that kind of stuff with system D. I can just put something in a directory in my home directory and if things are set up correctly it just starts, I want say the other way around. What you can do is play with cron, but playing with cron can be fun, so it all comes back to change. The D system represents a lot of disruptive change which brings us to the real tragedy of the piece, so yes, people have a complicated relationship with change.
I like to say that nerds especially have a really complicated relationship with change, we love it, change is amazing when we are the ones making it, as soon as change is something that comes from outside of us, it becomes unreliable and threatening what we think is that well-known people like me grew up with the notion of which you know, runs RC and RC runs a bunch of shell scripts and then the system runs and that familiar might be, you know, might be good for us because it's up and running, get it, it's our comfort zone, it's what we go to. we're used to it, but I think at this point, as a system boot that is based on shell scripts and is based on understanding how those shell scripts work and interact and are ordered, it's kind of like You know, that tired old blanket that maybe we should have given ourselves about 20 years ago and you know it persistently represents a change and it is resented because it represents a really disruptive level of change and it represents a change that was driven by people like Leonard. pottering whose ability to sympathize with people whose ease in asking for changes does not seem to be the best, but what this leads to is an instinctive reaction because the lack of sympathy is not just on Leonard's side, the reaction, the reaction to system They have a bit overdone in some places.
I think abuse is not good, no one needed to send death threats to Leonard, playing with software and it's not just abuse, contempt is not good and this was one of the things I really wanted to make clear when I gave this talk at BSD. FreeBSD shouldn't be proud of the fact that we don't have a system. We must see that, since we are missing something, we stop if we see if. We are mocking the system, mocking that the fact that Linux has system D and all those poor Linux users with their terrible software means that we are treating it as a joke and not as a source of ideas and that simply does not apply . for FreeBSD applies to almost anyone who sits there saying oh no, that DS system is terrible, it's like you don't look at it one bit and one of the biggest problems I had with the FreeBSD community in this case was things like this because to me this says on behalf of my community, join FreeBSD, we will never change, we refuse to move into the future, yes, anyway, and really what I want people to do and watch say like the D system, they like it or not. t and especially if they don't it's why system D appeared why it's important system D is thinking about that means you're suddenly left waiting so system D is solving a problem what problem is it solving could it solve it better? one of the solutions if you don't like the D system is to go and create your own, at least you'll find out how fun it is and another angle to this is that it's not just about us Greybeards.
The next generation of people who get into IT, get into software engineering, get into systems administration, they don't necessarily think about the systems they run like we do or like I do, they see a lot more APIs in the sense of like the Web API. it's like, you know, 20 years ago, I was like oh yeah, I can run a UNIX machine by putting an HTTP API into it in a library that would blow my mind back then and also things like containers, thinking about containers ends up doing you end up thinking. very differently than thinking about non-containers and so on and this brings us to the last part of what systemd has that we could learn from or what it offers us, so 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 lot of interesting things like if you go up to the top level of what the D system has, there's a lot of things really Interesting things to think about about messaging transports, this D fret system makes heavy use of the D bus.
I'm not a big fan of the D bus, but I am a big fan of messaging. Apple uses mark to do the same sort of thing, one of the things I told the BSD people was that we should basically write our own message and port my version. If I wrote one, it would be kernel resident rather than userspace resident and would allow many more security, authentication and access control elements on the actual bus. endpoints, but you can write your own because once you have a message transport it is much easier to write an RPC framework and the question is why would you need this and the answer is because if you need a leveling mechanism to make the kernel and userspace operate at the same level when it comes to the code above them, you don't want to know if a particular service you're talking to is handled by the kernel or by userspace,you just want to make this happen, you want to be able to send an API request that says, "OK, network interface," take this IP address and just make it happen, you don't want to have to worry about, you know, am I talking to the kernel or not? ?
Another thing that systemd offers is that many previous systems did not give you a proper service lifecycle. Like I said, Windows had this from the start. Matt grew it organically and then once they did that, they came up with the launch. somehow you pushed it massively and do it without you having to install one of several different systems that work differently, like open RC or run it or supervisor D or any of these, automation via API sounds joyous, but once You can automate the installation and configuration of a system through an API that does not require shelling out system calls or anything like that.
You've basically written most of what a device vendor would need to do a really good job. appliance so you might think that things like open on wrt could use it, but in my case I used to work for a company that made large storage appliances. It would have made our job a lot easier to have those kinds of things and I think the last really important thing that things like The D system is enabled by using things like C groups and things like that, containers. I think containers are really interesting, not because I think they're the savior of security or anything, but just because they give you a way to encapsulate. things in a way that is quite interesting, so system D, which provides the system layer, gives you a more consistent platform to do that kind of thing and the barrier to entry for building something on top of it is like a device that is greatly 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 the way system D names devices is really good and I say it's someone which used to express freebsd's notion that each Ethernet controller should have its own name, but while I also didn't like the Solaris naming scheme of disks like c 0 t0 4, I think having consistent names that are generated on physical attributes of the device is much better than having them named according to the random order in which they appear.
I also think the DS system logging model is really good. Binary logs aren't a bad thing as long as you have the tools to separate them, but having an append-only log on a system like that, especially append-only. I think logging that can be easily shipped somewhere else is very useful, but the other thing is that with containers and a lot 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 with other things, can be an encapsulated series of things that are managed as a unit.
I think it's really powerful. I think it would be very interesting to also look further into how a non-Mac style app would be made on one platform. like Linux can provide a lot more feedback from the host system about what's happening so it can react to it, so at the beginning of this talk I showed Wikipedia's definition of tragedy and mentioned that it was causing catharsis in people, so Catharsis definition meaning a purification or cleansing would be an implication of purification of emotions, particularly pity and fear through art or any extreme change in emotion. What I hope this talk has provided is the removal of fear and in particular the removal of pity from the D system and the people who actually use it, the world is changing around us and we can accept the change or we can try to resist it and this applies in many ways, it's not just software, there are a lot of changes that are happening that we should really need to evaluate logically and determine if we are on the right side.
We can test changes that you don't have to commit to until you know they work. I mean, a lot of distros had other systems that I replaced this and B with and I worked with it, so yeah, what I would challenge everyone here is to look at system D and try to find at least one thing that you like and then see if you can implement it. . Thanks, yes, I'll do some. questions, okay, we'll spend some time on the questions first, please try to make sure they are actually questions. I've given this talk before, and as you can imagine, I occasionally get rants in the form of questions, not in the form of questions you would ask.
Would it have been feasible for the D release to have been ported to Linux? Would there have been any advantages or disadvantages to doing it given that Apple had already done some of the work and presumably it was also open source, hence the problem? so if system D is aggressively Linux-specific, aggressively releases DEA, Apple-specific, uses it, deals in all of a lot of brand ports and it's also, I mean, Apple has done a little bit of work to try to make it portable . I know they offered to try to do all the Lib dispatch bits and everything we would need to do it in freebsd, but it never made it, it kind of sold out because I think they are focusing on making sure it works well for them, which is Fair enough in the same way that system D tends to try to 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 that we just acquired over the last two decades. Really good at dynamic library management. Now this is starting to look more like DLL. What do you think about this? Well, I think in a DLL for me it's more about having five different versions of a library and your applications always choosing the wrong one. I think containers explicitly prevent that particular version that was like, I think there's a different version where different versions of the container might be running and that sort of thing, but I think containers explicitly prevent those in the same way that tends to do it.
Avoid that kind of problem by statically linking everything. Would you be willing to attend the Linux Plumbers conference this year in Lisbon, Portugal and run a library of System D microconferences? I spoke to Kay and Leonard, they said they might attend, but hey, I really enjoyed it. and I really appreciate your comment that many of us really love change. We're the ones who say, "Hey, you should change," and we don't like it when things change for us. Do you feel like there's been some kind of chilling effect? The reaction to systemd being so hostile may be causing other people who have good ideas about how to do things to say well, I'm not going to stick my head over the parapet and get shot, that's possible, I mean, whenever you want.
Touching a code like that is going to cause distress. I think the overreaction to the system's day, like you know, the things that Leonard copied, I think are good, will have some effect on that kind of thing. I mean, the other thing is. Literally writing that kind of thing is a lot harder than you think, that doesn't mean you shouldn't try, but I really think one of the challenging aspects of bringing something like that into the world is managing the people you're trying to do. to accept the attempt to come to accept the change and that requires a certain level of social skill that is beyond.
I mean, I don't think I would do very well and that's one of the reasons to push. because that kind of change to FreeBSD was something I wasn't sure how to accomplish, so I resorted to yelling at them at a keynote as a curious FreeBSD Linux user, where is FreeBSD with the next generation clone? a project called open RC that handles some of the aspects of service management, but in terms of a holistic notion of a system layer they are very far from that and I think that is one of the things that I find frustrating in this discussion at any time.
The discussion around this is that there are too many people who immediately adopt this notion that system D is just 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 everything. 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 something consistent and manageable. Thanks for expressing yourself better than I can and much better than I can be bothered with, a lot of thoughts I've had and like you said, systemd swallowed up a bunch of previously separate system services.
Do you have any opinion on whether all of them make sense or some of them? sense and others not so well, so here's an interesting thought experiment, if system D had not built in those things but 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 need to maintain 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 see why they did it. Don't go down that route because it's not immediately obvious until you've done the first thing, like once you've got everything out, oh shit, we need to be able to handle that too and we need to be able to handle that. and we need to be able to manage that, so you put it all together at that point and said, oh, wait, if we had defined the interfaces a little better than maybe we could have avoided, that's the kind of thing. You see that as an afterthought, but yes, I think I can see everything.
I can see the logic of why they would have done what's all there, meaning they brought them in, but they do need to be there. long term and it's an interesting question and if you were to write your own implementation of that kind of thing then there are ways you could avoid having to roll all that stuff into one thing. You probably know or at least can imagine what the will will be. For starters, he believes there is an advantage to using CMD on embedded devices rather than desktops and servers. I can think about being able to reset your surfaces on embedded devices that no one is going to monitor, but what do you think about this if your embedded device has any? level of dynamism in your environment, like you connect things to it, that gives you a hook to do it, if you have the AP it's to manage things like that, it means that the code you have to write to implement your device will hopefully integrated is minor, is it that kind of thing that you mentioned, that you had a similar talk with some FreeBSD developers or FreeBSD users, yes, you got a lot of negative reactions there and if so, was there a major category of negative reactions that they? specifically I got are the only real rejection I got.
It was okay, we agreed with the notion that we needed something like that, but as long as it's not the D system, which you know, well, no, there was an attempt to do that and include portability. about a port compatibility layer Marc so don't be kidding thanks for that given the interactions between the community and the D system team in both directions have not always been the most positive to tolerate gently you know we are in a situation in which the system The D team does not really listen or take into account the concerns of the community, but at the same time the community does not really listen to the system D team and its vision of what needs to change both in the community and in this room and in general and also in the D system team to facilitate a better working relationship in the future, that's really complicated, that's what I'm asking you, so one thing you could do is watch Adam Harvey's talk about version updates, language version updates, because in it he discusses this notion that you have to give people reasons to change, as well as just hitting them over the head to tell them not to do that, having a combination of those things would be good.
I think the problem I'm talking about is that I'm speaking from a position of There is profound ignorance here, but in the system, the author's position has a lot of people in the community coming to me and saying: I want X Y and They and Zed want a B and C and these people want something else and at least five of these things conflict. each other, it's a really difficult set of limitations to deal with and work with, so I can see that there would be a temptation to just tell everyone to go with the flow, that doesn't mean that's the right thing to do.
I agree with you that the relationship between the author and the community seems strained. I guess I don't really know what the right way to fix it is, but it probably involves a lot more sympathy on both sides to get it done. any particular area where you think systemd should go much further. I would really like to see messaging and RPC stuff become a lot more ubiquitous and a lot more thought put into it, if that makes sense. I mean, I'm sure you're thinkingAs to how that works, there have been multiple attempts to introduce a D-bus style transport into the core.
I think having that, even if it's not necessarily a D bus, would be something really interesting to play with because it puts a lot of code on the same level. and it also allows for a lot more control and cool security features than you could do by having it in the kernel. Okay, we're out of time, so thanks Ben, oh, thank you so much.

If you have any copyright issue, please Contact