The Politics of systemd Part 3

[axl]

[Fitzcarraldo]

[axl]

[Fitzcarraldo]

[axl]

[Yamakuzure]

[Fitzcarraldo]

[Tony0945]

[Anon-E-moose]

[Yamakuzure]

[Tony0945]

[Tony0945]

[Fitzcarraldo]

Yamakuzure,

For info, since June 2017 LightDM also supports ConsoleKit2. See the commits on the LightDM site listed at https://launchpad.net/bugs/1631707

[Yamakuzure]

[Anon-E-moose]

[Naib]

I don't understand why they would link... its a bus ...
_________________
#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]

[Anon-E-moose]

Writing software that's modular isn't very hard, it does require a little forethought but it's not that difficult.

One can write code where, say Oracle for example, is sprinkled all through the codebase, OR
one can write code that stays within it's modular area and talks to an interface thus being able to be swapped out with anything else that talks to that interface.

If systemd were written properly then the individual pieces could have been separated out.
Don't like binary logging, then use something else that writes to the "logging interface", etc.
But when you do that, you don't have the ability to lock people in to your software even if they don't use 80%-90% of what is offered.

Systemd as simply an init system, seems to be a good idea and had they stopped there, it would have been fine.
Then they could have had another module that does logging, networking, and all the other stuff they've tried to shove into the monolithic monstrosity that they keep trying to convince others is modular, when it truly isn't.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

[Tony0945]

[Yamakuzure]

[krinn]

[Anon-E-moose]

dbus in and of itself is not a problem, using for everything just because ... is the problem.

Systemd init OK
binary logging OK
Now need dbus to talk to logging section ... oh wait dbus isn't started yet ... oh wait we'll try and shove some half-assed approach into the kernel to fix that problem
INSTEAD of rethinking the need for dbus, by either buffering the messages or using the kernel built in printing function.

Do I really need dbus to have the login module to talk to a piece of software? Or can I use existing IPC mechanisms that already exist in libc or the kernel?
If I'm trying to log in, and say kde isn't up and running, does it matter whether I use an IPC that doesn't have 2 endpoints or dbus who will ignore that fact?
I'm not going to log into kde either way, but one can be far more convoluted than the other.

The problem is ill thought out problems with even more ill thought out solutions.

Having a hammer in the toolbox doesn't mean it's the right solution for every problem. Not every problem is a nail.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

[steveL]

[steveL]

[steveL]