KDBUS Merging Prospects Get Debated

[duby229]

How is that sidestepping the argument? He claimed he disagreed that systemd being more than an init system is a problem.
You're wanting him to acknowledge that systemd being more than a stupidly simple init system is a problem and he won't. That's not really his problem, that's yours, because it means you can't advance your argument against him.

I don't think anybody said anything about stupidly simple. In fact everybody wants a capable init whether they know it or not. But systemd aint that, it's a whole lot more then that.

[tinko]

In which case it seems pretty obvious that systemd is over stepping the bounds of what it should be. It is supposed to the lowest level of userspace, isn't that exactly where it should be provided?

EDIT: I agree the kernel needs an IPC, but no way should it be kdbus. If systemd needs it then they can abstract it from a standardized kernel IPC.

Who sets the bounds for systemd? The systemd-developers provide free software, all relevant GNU/Linux-distributions adopt it. On what exactly can you base a standard by which you can decide that systemd is overstepping the bounds? All the opposition, all the people who think that systemd is doing it wrong, that adopting the systemd-related projects drives linux into the wrong directions, etc. etc. fail to create a large distribution that does this stuff right and has all the users flogging to them. What does that tell you about the majority situation? I adopted stuff like systemd or pulseaudio happily because it solved real-world problems.

Besides, the kdbus-developers do almost exactly what your asking for. kdbus is not exactly pulling dbus into the kernel. It is a transport layer on top of which (abstracted from the kernel interface kdbus) you can have a dbus implementation that is more powerful than the old dbus-daemon.

[duby229]

Who sets the bounds for systemd? The systemd-developers provide free software, all relevant GNU/Linux-distributions adopt it. On what exactly can you base a standard by which you can decide that systemd is overstepping the bounds? All the opposition, all the people who think that systemd is doing it wrong, that adopting the systemd-related projects drives linux into the wrong directions, etc. etc. fail to create a large distribution that does this stuff right and has all the users flogging to them. What does that tell you about the majority situation? I adopted stuff like systemd or pulseaudio happily because it solved real-world problems.

Besides, the kdbus-developers do almost exactly what your asking for. kdbus is not exactly pulling dbus into the kernel. It is a transport layer on top of which (abstracted from the kernel interface kdbus) you can have a dbus implementation that is more powerful than the old dbus-daemon.

That's not true at all. If people listened to what you just said they'd be totally misinformed, in fact lied to.

You really need to read this document....

https://lwn.net/Articles/619069/

[gens]

Not so much to fuzz about any longer, right?

not really
only a complete idiot would use a protocol like dbus for performance reasons
and he will still probably merge it, but only because its from GKH

so you can count that there will be even more half arsed coders who don't know how computers work telling you that your computer sucks because it can't run a simple program

progress, people, its progress

[phrx_reader]

Who sets the bounds for systemd? The systemd-developers provide free software, all relevant GNU/Linux-distributions adopt it.
.

Yes, you are right: forcing them to!

Besides, the kdbus-developers do almost exactly what your asking for. kdbus is not exactly pulling dbus into the kernel. It is a transport layer on top of which (abstracted from the kernel interface kdbus) you can have a dbus implementation that is more powerful than the old dbus-daemon.

I wonder how come some people never see the bulb glowing: Just enhance AF_UNIX within the IETF, no need for *bus shit at all! Some links:

https://lwn.net/Articles/641491/

https://dvdhrm.wordpress.com/2015/06/20/from-af_unix-to-kdbus/

[MoonMoon]

Yes, you are right: forcing them to!

Oh, this again. Would you please enlighten us how they have forced distributions like openSuse or Arch to use systemd?

[Awesomeness]

Oh, this again. Would you please enlighten us how they have forced distributions like openSuse or Arch to use systemd?

Didn't you know that Red Hat does reverse vendor lock-in? They want their customers to switch away from RHEL to competing, fully compatible distributions.

[dungeon]

Oh, this again. Would you please enlighten us how they have forced distributions like openSuse or Arch to use systemd?

The same way they forced: pulse, kms, composition, gtk3, wayland... pick you poison, it only depends how much people are affected by some of those forced things

[tinko]

That's not true at all. If people listened to what you just said they'd be totally misinformed, in fact lied to.

You really need to read this document....

https://lwn.net/Articles/619069/

Your reference is somewhat outdated, check this document instead:

https://github.com/gregkh/kdbus/blob/master/doc/kdbus.xml

Especially the fourth <para> is relevant to the statement that you're challenging..

[MoonMoon]

The same way they forced: pulse, kms, composition, gtk3, wayland... pick you poison, it only depends how much people are affected by some of those forced things

Please describe that way, I am not aware of it.