Kdbus Will Likely Be Merged Into The Kernel This Year

[curaga]

unable to even maintain critical existing infrastructure like ConsoleKit. If you don't want to use systemd on your Desktop PC, you have to use ConsoleKit, but no-one have bothered to maintain it for +1? years.

> people don't want tentacle monster
> you expect them to use bloated needless lib instead

Just like PAM and HAL, there was zero need for *Kit either. There's no point making it be a "logind or consolekit" question, when the best option is "neither".

[silix]

Currently, it is possible. But, the way things are going, I am not sure if it will be possible in the future.

looks like the pace and model of development in the FOSS world as of late, has made you blind to a simple fact - ten (or five, or even only one) year ago software, is still software that can be used as is, doesnt cease to exist just because new software comes out , and may suit you better than newer sw
you dont need to think only in terms of "generations", "ecosystem snapshots" or somethink alike as long as existing binaries work...

[oleid]

What a bullshit argument. systemd is being shoved down everyone's throats. If someone doesn't like ubuntu's file manager, they can use one of the dozens other file managers.

No it's not. This "being shoved down everyone's throats" happens only because nobody steps up and implements the needed infrastructure. Seriously, why *must* the logind maintainer, which also works on systemd implement stuff for you who doesn't like systemd? I think providing support your responsibility. And it is quite possiple! The interface of systemd and logind is quite stable, c.f. http://www.freedesktop.org/wiki/Soft...tabilityChart/ !

The same will happen in the future, if you'll be forced to use Wayland, because nobody will maintain the X11 code anymore.

It's free software. If you don't like it, either fork it or provide patches.

[oleid]

>Just like PAM and HAL, there was zero need for *Kit either. There's no point making it be a "logind or consolekit" question, when the best option is "neither".

I really like PAM, although I find it hard to debug. But does it really provide the same functionality than logind, as stated here?

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Desktop_Migration_and_Administration_Guide/logind.html

[interested]

My problem with systemd it is that it is pretty much imposed. I haven't checked myself but I have read that udev is pretty much coupled with systemd making it hard to offer and maintain an alternative.

The inventor and maintainer of udev decided that his project should be part of systemd because that was the best direction for his project. Everybody is free to fork his project and maintain it themselves, which I believe some are also doing,
They don't make anything hard, in fact udev's Open Source license makes it easy to do.

systemd itself is doing his job correctly but I wish that it would be respectful to the unix philosophy.

What Unix philosophy? The one that consist of random unattributed quotes, copy-pasted from random sites? There never was a School of Unix philosophy. A Holy Book of Unix have never existed.

It is trivial to make systemd fit with "Unix philosophy"; first of all, systemd is a collection of tiny small executables, each doing a specific thing, secondly, it is developed in unison with a vision, just like all other Unix tool collections was. You could go on and on how Unix'y systemd was, but it doesn't really matter, since "Unix Philosophy" is a content free term, and because Linux isn't Unix and never was. The recursive acronym, GNU, stand for "GNU's Not Unix".

The fact that it just keep growing and takes over many critical system functionnality without making it easy to cherrypick alternatives is what is pissing me off and probably many other systemd haters. This is what makes it being call a cancer.

It should be easy to use systemd as a init process while keep using syslog.

Heck, glibc dev delibarate for weeks before changing internal details to not break valgrind or other system tools.

Why can't the systemd devs be more considerate with people that do not want everything centralized into a single point of failure like Windows like they seem to aim?

Actually, systemd makes it extremely easy to pick alternatives to all its functionality; almost all its features can be configured away since small embedded systems is a key target for systemd. One of the few things it has to have is journald, but you don't have to use it as syslog, but can use it only as a transporter of log-messages to eg. syslog.
So it is trivial to make systemd without eg. "logind" or "localectl" and make your own alternative solutions instead. But yeah, that means someone actually have to work on alternatives, and it appears that very few people have such a scratch to itch.

But really, systemd have finally gotten Linux logging right. It was truly a mess before, and so many projects have tried and failed to improve logging on Linux before. Binary log files is something many people will be automatically sceptical about. I was too in the beginning, but that was only until actually played around with it; the index makes it insanely powerful and the journaltctl tool is just superb, with tab-completion everywhere. It is truly a technical superior way of doing logging, and is brilliantly executed too.

Systemd is just technically superior in everything it does compared to everything else in Linux, and it offer huge advantages compared to the status quo. That is why so many distros are switching over to it.

[interested]

What a bullshit argument. systemd is being shoved down everyone's throats. If someone doesn't like ubuntu's file manager, they can use one of the dozens other file managers.

But, if one doesn't like systemd, will it be possible to use Linux (in the very near future), without being forced to used systemd?

Currently, it is possible. But, the way things are going, I am not sure if it will be possible in the future.

Systemd is winning over more and more distros because it is simply superior to everything else. If you in the future can't find a distro that isn't systemd, then clearly that is because nobody cares about developing a non-systemd distro.

The reason you can choose between different file-managers in Ubuntu, is because people have actually made alternative file-managers. But very few people seems to actually care about making an alternative to systemd as a Linux plumbing system.

That makes trouble for Upstreams developers like KDE and Gnome, eg. KDE needed a new graphical login manager instead of KDM and started from scratch. To make a modern DE, KDE had two options when it came to multi-user login management; ConsoleKit and logind from systemd. But ConsoleKit have been unmaintained for years, no one is even promising to maintain it. That effectively led to the only sensible conclusion for KDE, that they wouldn't use their precious developer time supporting old abandonware that nobody seems to care for. So the new KDE DM only support systemd, simply because no other maintained alternative exist.

Such scenarios will be repeated over and over the next couple of years; everything new is easy to make on the new de facto Linux plumbing system, and the alternatives simply aren't being made or even maintained.

[justmy2cents]

You mean me? I'm sorry I brought up some arguments
It's not easy, it's trivial! Just enable it!

systemctl enable rsyslogd
systemctl start rsyslogd # or reboot

Done! At this point both journald and syslog will do the logging. You can disable journald's storage in it's configuration file if you wish, then it keeps some log lines in memory, only for output at e.g.

systemctl status rsyslogd

I guess systemd cares for it's users the same way. But why should the systemd developers do the programming for people which don't want to use systemd? It's as if you ask the Ubuntu developers to create a port of their file manager to the toolkit "TK" in order to make Annabel happy.

i'd just correct to even simpler version. since systemd maintains sysv command compatibility you can use service as before. lots of people are scared of "need to learn new...."
chkconfig rsyslogd on
service rsyslogd start
will work as well. only difference is that you'll see new command line systemd is deferring to

[curaga]

I really like PAM, although I find it hard to debug. But does it really provide the same functionality than logind, as stated here?

https://access.redhat.com/site/docum...de/logind.html

Multiseat is a completely valid usecase, so users who want multiseat should install logind. But it is not an argument to force it on the majority who do not require multiseat.

Likewise, I fully support those who want to use Bluetooth headsets with runtime audio redirection - they should install Pulseaudio, since nothing else provides that functionality as well. But again, no need to force it on non-BT owners.

[LightBit]

At first I was sceptical about Kdbus, but then I realised Linux allready has many bigger and more complex things in kernel.
I prefer microkernel, sadly there is no practically usable open source microkernel.

[anda_skoa]

Do you mean binder rather than intents? Intents certainly use binder but they also use ashmem for allocation.
Dbus is serialized XML, iirc, but kdbus is moving to the gvariant serialization (not XML amongst other things).

D-Bus uses a binary protocol: http://dbus.freedesktop.org/doc/dbus...ssage-protocol

XML is only used for files describing D-Bus interfaces. Most client libraries have tools to generate code from those file which allows application developers to do "method calls" instead of constructing and sending messages.

That part is still valid with kdbus, since it only changes the internals of the message bus.

Cheers,
_