The Politics of systemd Part 3

pjp · Administrator Joined: 16 Apr 2002 Posts: 20521

FYI, I merged a few posts here from the "SystemD free system/gentoo".

If some replies here seem out of place, that may be why. A couple/few of them are old enough to exist in this thread several pages back, so they'll likely go unnoticed here.
_________________
Quis separabit? Quo animo?

Yamakuzure · Posted: Mon Jul 30, 2018 10:53 am Post subject:

Naib · Posted: Mon Jul 30, 2018 12:17 pm Post subject:

but isn't that because aspects of the "linux desktop" has evolved to a swarm of processes that need to intercommunicate. CORBA and DCOP provided aspects of this but clearly didn't scale otherwise KDE & GNOME would not have opted for a common solution. Now maybe DCOP was more capable than CORBA (that would explain why some KDE dev's were more vocal in replacing DCOP than GNOME developers were in replacing CORBA).

Such an architecture requires a more complex communication stack and maybe DBus over-engineered the problem... they definitely implemented it poorly. The concern is such a bus is becoming used more and more and systemd heavily relies on it. From their perspective they are blind for the period between the kernel launches init to the point the file-system is mounted and dbus is up and running and as such there will be some push for a kernel-level IPC. Does it need to be as complex as DBus --> KDBus --> Bus1 ? dunno but their architecture will push for something that can accept dbus-like message it so init and udev can communicate before mount & dbus is live. Could they push dbus packets over some other kernel IPC? of course they can (you can push usb over tcp/ip transparently to the host machine) now whether systemd would accept this before handing over to userland is a different question
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

Anon-E-moose · Posted: Mon Jul 30, 2018 12:46 pm Post subject:

Naib · Posted: Mon Jul 30, 2018 1:10 pm Post subject:

Anon-E-moose · Posted: Mon Jul 30, 2018 1:23 pm Post subject:

IT was meant to be funny, thus the lol.

From what I remember the "spec" was done long after it had been implemented and put into play in the linux world, thus the reason for much of the convoluted and downright crappy code in parts of it. It should be combed through with a fine toothed comb and rewritten to be clean from the start, following a proper spec. JMO.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

Naib · Posted: Mon Jul 30, 2018 1:38 pm Post subject:

oh I get that, but good old Poe's law ... some people may take understanding for acceptance & advocating.

The spec probably was written and formulated after the fact as every single part of linux has been ad-hoc organic growth. No proper system design. Fantastic problem report management does make up for this.

I agree with actually stepping back looking at the use cases, looking at what problems such as dbus is meant to solve and seeing if dbus actually meets them would be advisable but who is going to do that? especially when what exists "works™" The fact one of the arguments to force in kdbus was performance related highlights this and iirc Linus stepped in an actually looked at the userland side of things and listed out a lot of implementation issues which would speed up dbus.

This removed their argument that the need for kdbus was performance related as userland could be improved, in some places trivially (iirc systemd has a separate implementation that appears quite lean: sd-bus but cannot be used alone) yet they are still pushing for an in-kernel IPC and the present argument is early interprocess communications bespoke to systemd
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

Anon-E-moose · Posted: Mon Jul 30, 2018 1:56 pm Post subject:

IIRC the early need for dbus/kdbus/<bus-1/whatever the latest is> was predicated on the need for messages, for logging early in the boot process.
As Linus and others pointed out, that's kind of what the print functions in the kernel were for, not for a log per se, but so that users could see what was going on.

It's funny that unix has been around for a very long time (computer time) and has gotten by without the need for an init system to send messages to a log mechanism early in the boot process.

OTOH, I don't see the push for kdbus/bus-1 to be included in the kernel in the last year.
Now what that means, I'm not sure, they could have given up, they could be rallying for an even greater push to have it included, or perhaps RH will simply install it in their kernels and let the rest of the linux ecosystem do what they want. Time will tell on this aspect.
Part of the lack of push, is I think they've worked on the internals of d-bus to make it faster.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

Naib · Posted: Mon Jul 30, 2018 2:07 pm Post subject:

I think you are right, not only in re-grouping for a different way to force something into the kernel (whether it is needed or not is a different story... I wouldn't be surprised if an argument along the lines of virtualization and logging will be played) but also in improving dbus.

bus1 as a kernel IPC hasn't seen much activity, but dbus-broker ( https://github.com/bus1/dbus-broker ) and sd-bus (system-d implementation of dbus) have with an aim to be faster and lightweight.

At least they took on board the criticism of solving the problem in kernel-space when user-land had so much still to offer.
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

axl · Veteran Joined: 11 Oct 2002 Posts: 1146 Location: Romania

axl · Veteran Joined: 11 Oct 2002 Posts: 1146 Location: Romania

I got here in 99 because I was tired to compile cyrus-imapd and postfix and amavis and php manually in slackware. it was horrible work with terrible inconsistency in libraries even in short periods of time like 6 months.

I still remember now, my mom was doing the christmas tree and I was compiling gentoo right next to it. that was my 99 x-mas gift. gentoo.

People need to be comfortable with just /bin/sh as init. and go from there. build everything ground up.

and also be placed mid systemd and figure that out.

I think everyone should do both. And I really do not think anything will change in the next 10 years. Both schools of thought are here to stay. Both types of system coexist.

And if you want to work in the field, you need to be comfortable with both.

Besides, it's just a stupid simple layer. Doesn't help at all with "services". I call em daemons. It's what they were originally called and I still think it's fitting. People still dont know how to control em. rely on "service manager". poor delusional people.

Yamakuzure · Posted: Tue Jul 31, 2018 9:15 am Post subject:

krinn · Watchman Joined: 02 May 2003 Posts: 7470

khayyam · Posted: Tue Jul 31, 2018 11:20 am Post subject:

fredbear5150 · Tux's lil' helper Joined: 11 Oct 2003 Posts: 113

pjp · Administrator Joined: 16 Apr 2002 Posts: 20521

Merged previous 6 posts from systemd or openrc.
_________________
Quis separabit? Quo animo?

Anon-E-moose · Posted: Tue Jul 31, 2018 4:31 pm Post subject:

steveL · Posted: Sat Aug 04, 2018 2:01 am Post subject:

steveL · Posted: Sat Aug 04, 2018 2:05 am Post subject:

steveL · Posted: Sat Aug 04, 2018 3:43 am Post subject:

mv · Watchman Joined: 20 Apr 2005 Posts: 6780

steveL · Posted: Sun Aug 05, 2018 1:22 am Post subject:

Tony0945 · Posted: Sun Aug 05, 2018 2:36 am Post subject:

axl · Veteran Joined: 11 Oct 2002 Posts: 1146 Location: Romania