How KDE Plasma 5 Optionally Uses systemd

[Slartifartblast]

Uhm, I don't expect any direct dependencies (not mandatory ones, as long as distros will package it correctly), there were always abstractions like Solid etc.
Hopefully they will keep it that way or limit it only to desktop (Plasma + kwin), not libraries and applications (well, as long as they want to keep them running in MacOS and Windows too).

I really wish the KDE team would stop wasting their time with MacOS and Windows, just concentrate solely on Linux and BSD.

[erendorn]

so just please stop saying that systemd lets you run X rootless
it was made possible by other people for other reasons
systemd just glued it together and said "i did it, it was all me"

Nobody says it was all systemd. Just that systemd glued it together and thus lets you run X rootless. Given all the pieces are there, other projects should be able to easily let you do that too.

[Emdek]

I really wish the KDE team would stop wasting their time with MacOS and Windows, just concentrate solely on Linux and BSD.

AFAIK they more like attracted new developers that way instead of "wasting" time of existing team.
It has some good aspects, like requiring to create code that doesn't need to depend directly on platform specific stuff (well, even kwin has to be more flexible due to Wayland).

[cocklover]

Well KDE is the most BUGGED Desktop enviroment(included all apps) and bloated, and Developers give a sh1t. The most used distro of KDE is Kubuntu and it sucks, really. Not sure how Cannonisoft is dealing with systemd cause we are in alpha 2 of 15.04 and there are no testing systemd, 15.04 it was planned to use systemd by default but what can you expect from a Marketing corportaion with the most advanced software project is a plugin for compiz. NetRunner KDE is the most bloated KDE distro, and Manjaro KDE is next

[gens]

Nobody says it was all systemd. Just that systemd glued it together and thus lets you run X rootless. Given all the pieces are there, other projects should be able to easily let you do that too.

Michael said it multiple times
iirc lennart did as well (many blogs and "articles" on teh internets did for sure)

in fact i never ever read anything from lennart where he said anything like "this code just glues what was there", it's always "systemd-somethingd lets you do this amazing new thing"
(i'm sure this sentence will bring out SJW-s, never the less it's the truth)

you don't need other projects, at least not if you have only one user on your computer
only a couple chown commands are needed (arch wiki had a nice explanation)

also, ofc, if logind does it as console-kit did, then it's not a good solution

[jrch2k8]

for multiple users, as i understand yes
and i doubt logind handles it better then console-kit
(can't find any documentation on how it actually works, so can't be sure)

in my opinion a "proper" solution would be a small multiplexer-like input daemon that passes input events based on current permissions
(like what X does, but more isolated and fully multi-user aware)
even better if it were an in-kernel mechanism, as that would bring latency and overhead to a bare minimum
this would also cut-out some code out of X

PS plasma 5 works fully with just linux, and will continue to do so

Well certainly input is one of the problems to solve but is the least problematic, certainly KMS helped but you are seeing the problem from the wrong angle, i mean yes rootless + logind or old consolekit + kms helps multiseat scenarios but this is not the root of the problem, the main problem is security.

X11 is really really insecure and if you add root access to it, becomes a real pain in the arse, additionally X wasn't originally designed to handle multiple inputs/outputs smartly and it requires exclusive access to hardware interfaces directly into the root window to later be routed internally by sort of a proxy inside X which ends making X even less secure since this internal proxy can be cheated on and capture focus, framebuffers, etc.(and can't be fixed without breaking the X11 protocol).

So all this years of changes to the graphic and input stacks + Xorg are basically to cheat X into believe it has exclusive root access to the hardware when is not true in reality and a cool side effect of that is to allow "smart ish" multi input/output support.

about logind the answer is yes it does it 20 billion time better, if you ever had to suffer the horrible pain of needing to access consolekit directly you will understand why, even worse if you needed policykit integration after that(i remembered and dropped some blood tears, uggh) but well the point is logind is actually very good overall and the API is awesome and has the plus of very easy integration with other security frameworks effortlessly compared of the old burn in hell console kit ways.

about your multiplexer thing, the problem never was multiple input or output sources, evdev handle that in the kernel perfectly fine since lot of time ago, the problem per se is X on one side and permissions on the other, X simply cannot understand 2 input sources over 1 or multiple framebuffers in parallel (and the frontbuffer Sync doesn't make it any easier btw) and that on itself require very creative set of solutions(many already in Xorg 1.17 like per CRT buffers) to create a parallel feel using clever serial events handling, the Permision problem is not related of who can access which input/output (in this particular case) per se, the problem is X has 1 session per server(this is the hard part), so if userA have a mouse and userB have a trackpad X can only request events from the logged session(userA for example) not both since originally X was designed to administer the hardware directly from userspace(<--- this is one of the main reasons X needed a root user to begin with and VT-config was not smart enough to handle multiple input per session outside serialTTY), so session managers like logind or the dead consolekit are needed to handle the session access to hardware securely and transparently while providing an easier API to access it(compared to each application adding its own code to handle the hardware). Xorg developers took that idea and find a way to cheat X into think its on control of the hardware while logind actually handles the session and the hardware availability(very interesting study case btw) <-- very rough explanation and non native english speaker here, so don't take very word literally is a general idea, you can check mailinglist or code for deeper information

as a note systemd and logind uses namespaces all over the place (network namespaces and process namespaces) with cgroups, if you could be more precise about what you meant?

Btw libinput is not a parallel/new/alternate solution or anything like it, is just a higher common API over evdev, basically to avoid that every developer have to invent the wheel again for every input device class and since it turned out pretty good everyone is excited to use it in a standard fashion(is pretty good to unify the input stack instead of have 50 drivers in X + wayland compositorS) but rest easy, it interface evdev kernel module directly and it requires a session manager(since logind is the only choice but is trivial to support any other in the future and no consolekit is not an option since is unmaintained for several years)

[TheBlackCat]

I really wish the KDE team would stop wasting their time with MacOS and Windows, just concentrate solely on Linux and BSD.

As someone who is forced to use windows on some computers due to a lack of drivers for certain hardware, being able to use my KDE applications (particularly kate, kfind, kompare, and filelight) on those computers is a massive benefit to me.

[Steffo]

I was thinking of giving KDE another try with KF5 / plasma-next, but if they follow this path i'll stay with using some KDE applications in a WM.

LOL, don't you have other problems?! KDE in a WM, because of systemd?! Oo

[The Solutor]

A waste of time from the KDE team.

Surely one of the upcoming systemd releases will include it's own integrated version of Kde

[geearf]

I think this quote is important too:

Longer term, we can investigate replacing parts of kded, the KDE daemon with systemd directly, providing a single common way to manage all services.

Since I use systemd, I don't mind at all, but I'm sure some will, and what about BSDs?