On Sun, 05.10.14 12:20, Martin Steigerwald (mar...@lichtvoll.de) wrote: > > However, I also believe that the change we are making is for the good, > > and even though it might not be obvious to many immediately, it brings > > major benefits when administering machines, and they massively > > outweigh the disadvantage of changing things. And apparently I am not > > entirely alone with this, as the folks who make technical decision for > > the various distributions ended up deciding in favour of systemd in > > most cases. > > Why do you believe so? What key points make you believe so?
Believe what precisely? Why I believe systemd is better than sysvinit? Well, that's a big question, and I am pretty sure already well enough discussed elsewhere, that we really do't have to repeat this here. > Here the feedback I read over and over again is that you and RedHat basically > forced the systemd decision onto other distributions. While I do not see how > you actually can be powerful enough to do that, as we live in a free will > zone. I do see tendencies that more and more stuff *depends* on systemd cause > it needs features only available there. Well, we provide good APIs. We provide them for a reason, because applications benefit from them. App developers see that, so they adopt them. That's pretty natural and obvious, no? If you want to know more, about why they do that, then ask them. What I find so puzzling about certain aspects of the criticism is that some people apparently assume that logind and similar things were entirely redundant, and that the APIs that it provides were so redundant, that one could trivially write the same app, but not make use of them... This idea that logind had exactly no merits, and was little more than just an evil tool to drive systemd adoption... > Dependencies like this actually create some force to adopt systemd. Well, I certainly don't force anybody. We provide APIs for technical reasons, and because we believe that people might benefit from them, even need them. And apparently I am not too wrong with that, after all they tend to adopt them... > Now I know ConsoleKit isn´t developed anymore, but also I never got why a > logind implementation needs to depend on systemd base package in such a way > that at least in Debian systemd package has to be installed if someone wants > to use GNOME. Well, logind talks to systemd to manage user sessions and user processes in cgroups. That's why it depends on systemd. And since only systemd implements that, we couldn't even support anything else even if we wanted. Our intention with systemd is to provide a strong platform. One platform. If people want to use our code in other contexts, then that's totally fine, but please understand that I am not going to do any work for that, I am not going to maintain it, and I don't want to see that in my code. > Much of the feedback is related to that. Many would appreciate something like > systemd if it just did *services* stuff. That is also what seemed to have > motivated the dev behind the use less d fork. Well, I am sorry, but systemd is more than that. If systemd is no what people want, they can roll their own thing, can continue to use sysvinit, or even fork systemd, That's completely OK. But for what we have in mind for systemd it's definitely a goal to make Linux more attractive for developers, by providing a good set of core OS APIs that people can just make use of, instead of a zoo of things that are combined in wild combinations. > > The current increase noised level around systemd adoption I attribute > > to three things: the fact that RHEL7 is out now, the fact that due to > > the adoption of systemd as default by Debian and Ubuntu the folks who > > ignored the discussion so far now are faced with this change, and also > > to a big part to certain "columnists" who in the interest of > > generating traffic to their sites try to create a hubbub out of very > > little. > > > > Anyway, long story short: we knew what we did, and yeah, I read > > feedback, even if it is written in a hateful style, and we learn from > > it. > > Well, I for myself have been concerned and surprised by *such an mount* of > uproar. Not even GNOME 3 triggered anywhere near that amount of threads and > mails. Well, I am not sure this is really that way. GNOME 3 noise was pretty bad too, maybe you just weren't involved so closely... But even if it wasn't, our stuff touches most of the Linux community, which is larger than the GNOME community. > And I worry regarding various attempts to replace systemd functionality (by > systembsd services) and by use less d or using different inits. I think quite > some of them are based on solid technical arguments. I wonder whether systemd > might be missing out on something here. Well, some competition would be great. I am pretty sure that uselessd is not based on solid technical arguments though, and pretty sure it's maintainer will figure that out pretty soon too... Anyway, more power to him, at least he does soemthing, and isn't just one of the do-nothing complainers, even if I certainly disagree with much of his technical reasonings and decisions. > > Well, note that systemd used for user services actually saves you > > resources, as the systemd binary only needs to be mapped into memory > > once and then is shared between all user instances and the system > > instance. > > But what about the argument of stability? Arguably a 1,3 MiB binary have more > chances for bugs and security problems. What happens if PID 1 crashes? I > heard > about that systemd would in some circumstances have the chance to get > restarted. So far we are doing pretty well with stability. And why would be multiple different binaries from different projects be any more stable than a single one we reuse at multiple places? systemd does a lot more than sysvinit. It's larger because of that. That's hardly surprising. systemd is a fraction in size of the Linux kernel. If something in the Linux kernel goes wrong it's a lot worse than if it goes wrong in PID 1. If the Linux kernel can manage the stability, so can we for systemd. (Heck! even wpa_supplicant has more lines of code and binary footprint that the systemd binary!) > And… with two binaries and a library or so… wouldn´t the result – i.e. the > memory footprint – the same? Except some per process data area all would be > mapped once. Not following? Are you suggesting that systemd would be more stable if we built the systemd binary in two versions and would link the common code as shared library? I am sorry, but that's not really how this works... > > Well, some is valuable and important, but much certainly isn't. The > > 200nd complaint that systemd was "monolithic" or so is something I am > > genuinely not interested in anymore, for example... > > Why do you think there is no point or vadility in it? Because it has been discussed 199 times before. Because it isn't true, unless you define what "monolithic" means to your own taste? I mean, I am pretty sure the "monolithic" argument is really not about anything technical. It's more about the fear that the systemd folks monopolize too much influence over the whole system, and that they'd rather see that splinter. I can understand that feeling. We try to work against it, by diversifying who can commit to systemd and things like that, but ultimately, if people don't like if only the systemd group pushes the OS forward all alone, then we can do little about it. People would have to actually do something on their own, and if people just talk and don't act, then yes, there will be only us left... We will not split up systemd into multiple tarballs or repos, just to create fake sense of "bazaar"... The stuff we do is supposed to be streamlined, and uniform in its appearance. While you can adjust it pretty neatly to your specific needs by picking only the components you care about it, ultimately whether it's one repo or more, or one tarball or multiple is just a boring technical detail that matters only for building things and reusing code... > systemd does a lot. And an 1,3 MiB binary is a hug binary size for something > that started out as managing services and sessions via control > cgroups. Well, it does a lot more these days. The Linux kernel also started out pretty small too. Nowadays it does a lot more, which makes it so unversially applicable. I figure systemd goes a similar path. (Though hopefully will never grow as massive, complex and monolithic as the kernel...) Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel