systemd is basically a self-contained operating system at this point...
The first sentence on the systemd project overview is:
systemd is a suite of basic building blocks for a Linux system.
After describing the init system it goes on to say:
Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
systemd is intentionally a much bigger project than just the systemd init system.
This is what annoys me about that debate. Systemd arguably _is_ a better init system. But no one asked for a new logger, network config, time daemon, cron, etc.
Now you're saying that's always been the intention? Perhaps, but this was not emphasized by the systemd team.
That said, at one point the Apache Foundation was just about a web server and the GNU project was just about a compiler.
I'm not arguing for or against systemd here, I'm just saying that the days of thinking about systemd as just an init system are over. They're building an entire framework for a Linux distro. You can agree or disagree with that, but talking about systemd today as an init system that has sprawled is obfuscating the situation. The systemd maintainers today are clearly trying to go beyond just an init system.
The acronym itself is actually a big hint that this is incorrect.
https://groups.google.com/forum/#!msg/net.unix-wizards/8twfR...
>To begin with, GNU will be a kernel plus all the utilities needed to
>write and run C programs: editor, shell, C compiler, linker,
>assembler, and a few other things.
Their dhcp client violates various security best practices in the name of speed (the whole thing was reminiscent of the Apple debacle related to iOS wifi).
And their DNS client quietly grew a cache susceptible to poisoning. A problem known about and solved for a decade in DNS circles.
The debian technical committee vote on upstart vs systemd was split 50:50.
Well, that's a stretch really. systemd is more like tightly coupled systems eating up more and more services and rewriting them systemd way. Things that do look like blocks (udev, journal, logind) are "take systemd way, or nothing".
Uselessd is a basic building block.
"German language source code comments are not acceptable in the systemd source tree, according to our coding style conventions. In preparation for merging LibreOffice into systemd I have thus started translating a few of their source code comments from German into English." - Lennart Poettering
( https://forums.gentoo.org/viewtopic-p-7767336.html#7767336 )
Quite a few kernel devs NAKed it on basic security issues, serious design flaws, unnecessary complexity, and unwillingness to explain why kdbus is necessary (that is, why existing features were not inadequate). Instead of taking that hint addressing the serious design problems, GHK (et al) did the usual systemd-cabal tactic of pretending design doesn't matter, indirectly implying their existing design must be perfect and not open for discussion. They patched a few superficial bugs, made some vague posts on LKML about how the finished most of the outstanding issues (wtf/), as if the NAKs never happened. It's currently unclear what will happen now.
Then Lennart announces that the latest systemd has kdbus support force-enabled, while suggesting that distros should start testing kdbus with an out-of-tree patch to the kernel...
Just like this NTP server issue, the only thing that matters to Lennart is his own world. The issues and concerns of other people are never his problem.
kdbus is a new feature. It is normal that it takes time to develop and has bugs and issues along the way. Linus specifically requested that it be enabled in systemd so that it starts to get more testing and exposure.
Constructing a grand conspiracy around kdbus is ludicrous.
Like most systemd apparatchik, this post uses incorrect assumptions, multiple disparaging remarks, and a lot of broad, non-specific claims to try and re-frame the discussion.
> "drama"
As others in this thread have pointed out, the NTP issue is NOT about technology. Quite a few of the higher-profile problems with the systemd "cabal" are social/management problems, and like clockwork, whenever they are brought up people like you try to force the conversation away from those problems by insisting that the conversation can only be about "technical" issues. Often this is accompanied with blatant straw-men arguments, which is, unfortunately, a common tactic in many internet arguments.
I discussed Lennart's attitude, because that's the topic of the thread. Reputation matters, and the handling of this NTP issue is yet another data point.
> kdbus is a new feature
Obviously.
> It is normal that it takes time to develop and has bugs and issues along the way. L
Of course. Is it normal for the person submitting to completely ignore those issues? The fact that there were issues is not the problem. I'm talking about what happened afterwords, which was a confusing and unusual disregard of quite a few of the most serious issues brought up on LKML ( http://lkml.iu.edu//hypermail/linux/kernel/1504.1/03981.html ), and a disregard for regular kernel submission process ( https://lkml.org/lkml/2015/4/23/281 ).
This is a side issue, though, as my point was that the systemd cabal already made a lot of headway towards the "systemd-kernel" joke.
> grand conspiracy
What grand conspiracy? I'm talking about widely-known public statements, like the recent systemd v221 announcement, where Lennart said, "We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions..."
This is especially amusing coming from someone who jsut accused me of focusing on "drama".
> Linus specifically requested that it be enabled
Unless I missed something, Linus only discussed that after Andy Lutomirski's question about systemd v221 (and the above quote requesting distributions to start testing now).
> actual technology
You want a discussion on the technology of kdbus? Then how about this question: why, exactly, is wrong with the already-existing TIPC plus a userspace library? It's been in the kernel for a while now? If it is indeed missing an imporant feature, would it not make more sense extend the features that already exist?
https://lwn.net/Articles/551969/ has GregKH talk about both Gnome's plans for a Android-like app containerization system, as well as the automobile industry wanting a higher performance dbus so they can replace QNX with embedded Linux.
Frankly i have come to read anything coming out of Gnome and Freedesktop as coming out of RH via a sock puppet.
Thing is that it may not be a willed plan inside RH. But they have enough people on payroll involved in both projects, and others, that it becomes a subconscious lockstep.