| View previous topic :: View next topic |
| Author |
Message |
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
 Posted: Sat Nov 28, 2015 1:23 pm Post subject: KDE and systemd |
 |
|
This thread is a fork of the "The Politics of systemd" thread dedicated to discussing the future of KDE with regard to systemd.
Eventually, I also would like to create a wiki page which would fully document the KDE & systemd issue for those of us who are concerned about the current trends...
Meanwhile, let me provide two quotes recently posted in the aforementioned thread and that are directly relevant to this new one:
| gwr wrote: | David Edmundson from KDE, concluded that "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit".
http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
Looks like more 1:1 integration directly with systemd without any room for other alternatives. |
and
|
|
| Back to top |
|
 |
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
| Posted: Sat Nov 28, 2015 1:42 pm Post subject: |
|
|
Also, another, related topic that could be discussed here:
Do long-term KDE users consider switching to another (more lightweight) Desktop Environment (DE) in order to remain systemd-free?
What KDE feature would you miss that is not found in alternative DEs? |
|
| Back to top |
|
|
baaann
Guru
Joined: 23 Jan 2006
Posts: 558
Location: uk
|
| Posted: Sat Nov 28, 2015 2:24 pm Post subject: |
|
|
This thread from the comments on David Edmundsons blog suggest that KDE are going in with their eyes open and appreciate the threat of lock in
| Quote: |
Arne Babenhauserheide • 10 months ago
Would it be an option for you to add some of the tools which reimplement the logind API to your test matrix?
Similar for other useful tools to which people write replacements?
That would give people the choice to use other tools without adding complexity to your code.
(discussions can help find the clearest question)
3 •Share ›
Arne Babenhauserheide Arne Babenhauserheide • 10 months ago
This is the single question to which I would really like to get an answer: Will you test against API-compatible replacements for the systemd tools you want to use?
I won’t write anymore in any of the other threads here to avoid drowning this question in the noise.
3 •Share ›
Arne Babenhauserheide Arne Babenhauserheide • 9 months ago
to reiterate why I ask this: If you say that systemd is THE ONE STANDARD, then multiple implementations should be possible (as that’s a key aspect of a standard).
If you can’t test against other implementations, then I cannot trust the tools to stay usable separately; which means that if the systemd tools you use should at some point require systemd as PID1 and/or Gummiboot as bootloader, I would be forced to either ditch KDE without having enough time to invest into alternatives while I still have a working, updated desktop or heed all rules the systemd developers choose to force on me.
4 •Share ›
davidedmundson Mod Arne Babenhauserheide • 9 months ago
Sorry, I missed your first question.
Realistically we're talking about the snapshot of the login1/timedate1 specs as of now. I follow what happens in that BSD shim. We tend to have a good relationship with most packagers (certainly I do with one BSD guy) if he tells us something is broken, we'll fix it in the final release.
We had a discussion at the Plasma sprint now, we'll be dropping legacy support in 5.5; over 6 months from now. We're trying hard to not screw any hard working distros over.
I can't promise we won't break it accidentally, we do it with the build system. I can say we won't do it deliberately; and certainly this should be done in a way that won't affect users.
However, if a distro doesn't make any effort then they will get left behind with an old Plasma. I don't want to let any one group ruin the experience of anyone else.
Also to reiterrate a key point this has _nothing_ to do with what's on PID1. Ubuntu had Systemd's logind whilst using Upstart on Ubuntu 14.10 successfully.
•Share ›
Arne Babenhauserheide davidedmundson • 9 months ago
Thank you for answering!
You’re answer resolves most of my worries, and I’m sorry that I wrote in such a confrontational style. The whole stuff about systemd gets to me. I won’t go into reasons - they do not matter here. Instead I’ll share your answer with other people who are concerned by your blog post to resolve needless worries there, too. We can’t deny that systemd exists and that some of the features it made widespread are useful, so it’s good to see that adoption of the API does not have to lead to lock-in.
PS: I guess you mean “to not screw”, not “to now screw” ← I’d suggest editing that, otherwise I’m sure it will be misused to fuel fear.
PPS: My worry is that if you make Plasma dependent on the implementation of tools in systemd, you lose the power to decide whether this change means something for PID1. If the tool changes to require systemd in PID1 and old versions do not get security fixes anymore, you can’t decide not to follow that without investing additional work. I don’t mean the rhetorical “you”, but really you: I trust KDE developers to act in my interest as user, so I want you to stay in control of what KDE requires.
•Share ›
davidedmundson Mod Arne Babenhauserheide • 9 months ago
RE: PS Thanks 
RE: PPS.
Speaking honestly I have concerns about the "lock in" too, but I think the best way to fight that is to embrace it so we're on the inside and part of that community. We can't stand on the sidelines and then complain in 5 years that it doesn't do what we want.
1 •Share ›
Arne Babenhauserheide davidedmundson • 9 months ago
the lock in fears is why I asked for testing independent implementations (though it took me a few messages to realize that this is what actually solves the issue best since you consider the existing implementations to be technically inferior): There are people who already do the hard work of providing API-compatible replacements. They ensure that useful concepts in systemd can actually bring Free Software forward on the long term. |
|
|
| Back to top |
|
|
evoweiss
Veteran
Joined: 07 Sep 2003
Posts: 1678
Location: Edinburgh, UK
|
| Posted: Sat Nov 28, 2015 4:22 pm Post subject: |
|
|
| augustin wrote: | Also, another, related topic that could be discussed here:
Do long-term KDE users consider switching to another (more lightweight) Desktop Environment (DE) in order to remain systemd-free?
What KDE feature would you miss that is not found in alternative DEs? |
Before this systemd debacle I switched from KDE to Openbox. I do not miss any aspect of KDE and I run a very bare version of Openbox (no file manager, run almost everything from the command line, etc.) The funny thing is that my wife who mainly uses windows, has had no problem adjusting to it.
Best,
Alex |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy
|
| Posted: Sat Nov 28, 2015 5:01 pm Post subject: |
|
|
| evoweiss wrote: | | augustin wrote: | Also, another, related topic that could be discussed here:
Do long-term KDE users consider switching to another (more lightweight) Desktop Environment (DE) in order to remain systemd-free?
What KDE feature would you miss that is not found in alternative DEs? |
Before this systemd debacle I switched from KDE to Openbox. I do not miss any aspect of KDE and I run a very bare version of Openbox (no file manager, run almost everything from the command line, etc.) The funny thing is that my wife who mainly uses windows, has had no problem adjusting to it.
Best,
Alex |
if you do want a filemanage: PCman-fm (the qt variant does have some extra shinies). It can operate as an automounter as well.
I have used openbox for possibly a decade now and its how much do you want the system todo for you w.r.t. control
openbox+pcman-fm+lxpanel+obmenu-generator is <3
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
lost+found
Guru
Joined: 15 Nov 2004
Posts: 509
Location: North~Sea~Coa~s~~t~~~
|
| Posted: Sat Nov 28, 2015 7:10 pm Post subject: |
|
|
| augustin wrote: | Also, another, related topic that could be discussed here:
Do long-term KDE users consider switching to another (more lightweight) Desktop Environment (DE) in order to remain systemd-free?
What KDE feature would you miss that is not found in alternative DEs? |
Gentoo KDE is modular, so hopefully the separate applications keep running without the unwanted stuff. I'm quite happy running some KDE applications under FVWM-Crystal now. |
|
| Back to top |
|
|
madjestic
n00b
Joined: 10 Oct 2013
Posts: 53
|
| Posted: Wed Dec 02, 2015 12:06 am Post subject: |
|
|
Xmonad is perfect for emacs users. I mean it in a good way. Or for those who prefer doing most things with keyboard or want to avoid unnecessary keyboard to mouse hand switching. It's lightweight, customizable; very snappy: if you think KDE is snappy - try xmonad  After being a KDE user and having gone xmonad-only for the last 2 weeks, I am surprised to find myself not missing a thing. With an exception of a handful of components, this system is kde/plasma free now. |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Thu Dec 03, 2015 11:21 pm Post subject: |
|
|
| I most definitely will switch desktops, and I am a long time KDE user. |
|
| Back to top |
|
|
Linubie
Guru
Joined: 11 Jun 2004
Posts: 383
|
| Posted: Thu Dec 03, 2015 11:24 pm Post subject: |
|
|
Razor-qt seems to be a good alternative for KDE, but haven't tested yet.
_________________
Mircosoft software is like having sex with a stranger, you always have to be careful not to get infected with something... |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2301
Location: Adendorf, Germany
|
| Posted: Fri Dec 04, 2015 7:54 am Post subject: |
|
|
And where do you get it that running systemd as your init system will become mandatory for KDE to work any time soon? Or any time at all?
From Bug 355892 - missing suspend/hibernate with upower 0.99.3 and Devuan :
(The bug opener reports that with upower 0.99.3 but without systemd, suspend and hibernate no longer work. Big news as we gentooers know this for years.)
| Martin Gräßlin 2015-11-26 09:24:21 UTC wrote: | | huh? You might be interpreting too much into this. Please step a little bit away from the "systemd conspiracy" if I might call it that way. We absolutely don't care what init systems our users use - not our business. |
| Sebastian Kügler 2015-11-26 13:14:22 UTC wrote: | KDE has not thrown out anything. We have explained the problem and proposed three different solutions to you:- Using systemd
- Using ConsoleKit2
- Using upower <=0.9.23
|
Actually the latter is what we do on gentoo with sys-power/upower-pm-utils.
As these posts are rather recent, and the blog post that started these scare tactics about KDE going the gnome way is over 10 months old, I daresay a systemd free KDE will be available for a long long time.
There was, of course, Martin Gräßlins Blog about the benefits of systemd and upstart (almost two years old now) that stirred many concerns, available for read in the comments. However, one comment was easy to overlook but nevertheless rather illuminating: | Elias Probst 31.12.2013 wrote: | Reading the comments shows a lot of misconceptions about +Martin Gräßlin's proposal:- KDE SC will still allow to use the old-way to startup a KDE session, as it will still ship the X11-way of doing it for *BSDs. If you want to use a modern Wayland/systemd stack you're fine by using the defaults. If you don't want to: use the old X11/script startup stack.
- KDE SC won't enforce using systemd as init-system by this change. Instead, it will use parts of systemd which are completely independent from the init-system being used to handle the startup of the KDE session. If systemd is being used as an init-system, that's a plus because of some systemd integration effects, but that's all about it.
|
So maybe it is a bit early to take flight in panic.
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Dec 04, 2015 5:03 pm Post subject: |
|
|
| gwr wrote: | | I most definitely will switch desktops, and I am a long time KDE user. |
++
Been using it since 1998, and I'd be sad to switch, but I had so much hassle with semantic-craptop, that I switched from KMail to mutt.
That was not easy: I really loved KMail.
I really love kate, too, but would switch desktops in a heartbeat if they tried to force systemdbust on anyone.
I don't think they will, though; yes, you occasionally hear from some overenthusiastic nub about how systemdbust (in some form or another) will sort out all their problems. But there are an awful lot of wiser heads involved with KDE, who don't get out much in public.
The other thing to bear in mind is that KDE is a showcase for Qt; that is its main purpose as far as the company behind it is concerned.
(Trolltech, or Nokia, last I heard.)
And Qt is nothing if it is not multi-platform; that was the point of more modularity in KF: to make it work elsewhere besides *nix.
Given that, I really do not think KDE the project will tie itself to systemdbust: that would tie it to Linux, and lose it some of its core users.
The discussion about APIs is simply sad, but can best be resolved by simply specifying what they need as an API, along with an ABI commitment.
Or at least, a sane ABI-versioning, rather than "what Lennart feels like this week: do it this way, for He Hath Spoken."
"..until we change everything round again, usually by subsuming your project. Welcome to Lennux: catching up to Winbloze, one crippled upstream at a time." |
|
| Back to top |
|
|
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
| Posted: Tue Dec 08, 2015 10:42 am Post subject: |
|
|
I'm quoting Steve from the systemd thread, with emphasis added :
| steveL wrote: | | gwr wrote: | David Edmundson from KDE, concluded that "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit".
http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
Looks like more 1:1 integration directly with systemd without any room for other alternatives. |
Yup; the sad part is how lame that post is, yet it will be used as pretext: "see, we have another KDE developer putting the case for systemdbust, it must be right.."
The reason it is so lame, is because all of the use-cases he discusses, should have been worked out at an ABI level, way back when kde-4 was being conceived, and they dropped the far-better and more performant dcop for dbus.
ABI level, in the same way that LADSPA quietly sorted out pro-audio plugins, on a cross-platform basis: specifying a useful API, simplifying to the bare minimum required, while not leaving out anything needed. Only needing one revision in a decade, to take account of usage-feedback.
LADSPA has been superseded by LV2, with extensions. The interface is still very "simple".
The truth is that not everything even needs a random desktop bus; and where it does, we should use TIPC, a proven (cross-platform) pub/sub channel that is already in the kernel (for over a decade.)
(k)Dbust developers were told this back in 2012, so there is no excuse for their shameful avoidance of prior-art.
For instance, the simplest application would be email notification; how the backend scans for, or receives, new data is irrelevant. A simple specification of the functional API needed, which any group of Gentoo users (on real hw) could do, add some supporting data structures, and leave it at that.
Any lib can provide that functional interface, and it can interface to any process providing the backend data, however it likes.
Personally I quite like the idea of an inotify watcher; and I don't see any need for a fandango of crappy network-protocol undesign shoved onto the local machine to facilitate GPL-evasion, when basic POSIX IPC is much cleaner, and works cross-platform.
Still, whatever floats your boat: just stop pretending that a complete lack of understanding of modularity and userland *nix programming is an excuse for idiotic mis-design.
If you want pub/sub, so the email watcher can just send to N random processes it does not need to know about, use TIPC already.
Though really I only want one "client": the systray applet displaying the data. And it seems simpler just to let it get its own info, using the lib and no other processes.
And doesn't that just sound like your email client?
Others may differ ofc: that's the beauty of an ecosystem. Let it work for us. |
https://en.wikipedia.org/wiki/D-Bus
According to wikipedia, dbus is developed by Red Hat as part of the freedesktop.org project.
I don't know what motivated KDE developers to switch to dbus, and how much, if at all, the freedesktop people lobbied the KDE developers to make the switch.
I don't know either how this switch to dbus ties in with the wider debate about systemd and other freedesktop components (such as Wayland).
https://community.kde.org/KWin/Wayland |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy
|
| Posted: Tue Dec 08, 2015 11:26 am Post subject: |
|
|
Well KDE used DCOP & gnome used bonobo/CORBA arch. dbus was the design by committee to expand on their capability and come to a unified solution
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
Last edited by Naib on Tue Dec 08, 2015 1:23 pm; edited 1 time in total |
|
| Back to top |
|
|
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
| Posted: Tue Dec 08, 2015 12:51 pm Post subject: |
|
|
| Naib wrote: | | Well KDE used DCOP & gnome used bonobo/CORBA arch. Kdbus was the design by committee to expand on their capability and come to a unified solution |
Oh yes! Now that you mention it, I remember reading about it.
Are d-bus and kdbus the same thing?
Is this related to the kdbus in the Kernel thread?
I am not in a position to judge the design of dbus, but at least Steve, above, does not seem to like it. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy
|
| Posted: Tue Dec 08, 2015 1:23 pm Post subject: |
|
|
sorry typo... meant to write Dbus... KDbus is basically Kernel Dbus
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Dec 08, 2015 4:21 pm Post subject: |
|
|
@augustin: background on DCOP (and why it was so much better than dbust.)
Sorry if that's a re-iteration of something you've already read; I'm getting lost in all these threads about the same thing.;) |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 497
Location: Gainesville, FL, USA
|
| Posted: Tue Dec 08, 2015 10:31 pm Post subject: |
|
|
I've done some bit of desktop scripting and I have memories of its having been much easier and more straightforward in KDE 3--so much so that I've avoided doing much of it at all with KDE 4.
I can see from all of this that DBus represents a lowest common denominator: the product of too many cooks in the kitchen. Now was the IPC mechanism in Gnome really so messy that it made the soup come out so badly? Could it be, since KDE is (and Gnome once was) meant for cross-platform use, that DBus allows for interoperation with busses in other systems like Windows?
If that's the case, what an irony! A system promulgated (maybe that's a better word to use for it than "designed") to enhance interoperation now becomes exclusive to Linux.
So now the official GNU desktop won't be able to work with the standard GNU kernel and tries to avoid the official GNU shell. |
|
| Back to top |
|
|
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
| Posted: Wed Dec 09, 2015 4:41 am Post subject: |
|
|
| steveL wrote: | @augustin: background on DCOP (and why it was so much better than dbust.)
Sorry if that's a re-iteration of something you've already read; I'm getting lost in all these threads about the same thing. |
Thanks. I remember that interesting thread. I knew I had read somewhere something from you about DCOP. 
Thanks for the reminder. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Dec 09, 2015 12:10 pm Post subject: |
|
|
| miket wrote: | | I've done some bit of desktop scripting and I have memories of its having been much easier and more straightforward in KDE 3--so much so that I've avoided doing much of it at all with KDE 4. |
Exactly; I'd only just found out about it in 3.x, and was dying to play with it in 4.x as I'd been working on update, so wanted to call out.
| Quote: | I can see from all of this that DBus represents a lowest common denominator: the product of too many cooks in the kitchen.
Now, was the IPC mechanism in Gnome really so messy that it made the soup come out so badly? |
Not at all; it was a full-fledged ORB (CORBA implementation); in fact that's a good point. It would be easy enough to run DCOP over it, since IDL is IDL.
| Quote: | | So now the official GNU desktop won't be able to work with the standard GNU kernel and tries to avoid the official GNU shell. |
Or indeed any shell, because "shell is bad" since we can't write it.
Funny how they never say that about C++ or Java where I'd actually have some sympathy with the position that "it's a bad language"; albeit due to usage in Java's case, it's proprietary, so that usage was intended(!). Nearly as shocking as MFC.
@augustin: no worries :-) |
|
| Back to top |
|
|
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2301
Location: Adendorf, Germany
|
| Posted: Wed Oct 19, 2016 10:52 am Post subject: |
|
|
I am currently running the most recent KDE Frameworks (5.27.0), Plasma (5.8.2) and Apps (16.08.2) on openrc.
Yes, there is some (optional!) dependency on logind via polkit, and I am actually trying that, too.
Thanks to the kde overlay, I am using sys-auth/polkit-0.113-r200:kde with USE="elogind" and sys-auth/elogind-219.12-r2:kde.
So people are out there being aware that logind might be beneficial, while running a fully fletched systemd is not.
However, regarding your wiki page, although elogind makes loginctl available, the mentioned "loginctl unlock-sessions" doesn't magically work. SDDM stil goes with ConsoleKit, so "loginctl list-sessions" prints an empty list.
But luckily it isn't necessary at all:
As you must have ConsoleKit running, you can use ck-list-sessions to find your locked session, note the session number, and then use | Code: | | dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Session<session_number> org.freedesktop.ConsoleKit.Session.Unlock |
to unlock the session without logind being used or even installed.
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Wed Oct 19, 2016 5:43 pm Post subject: |
|
|
I stopped using kde with kde 3.8 branch.
the only software i need is k3b. And the k3b dependency hell / building is a nightmare. This is the case for several years. I am now on kde 9999 ebuild now. k3b pulls in ~100-200 unneeded junk packages. In the past I removed half of it and k3b still worked. I do not bother anymore with kde 9999 ebuild. kde has a very poor dependencies for kde packages for serveral years.
So the software which should be remade is k3b for a Desctop environment free package. k3b should only depend on qt or gtk and thats it. with the smallest possible dependencies... |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9320
|
| Posted: Wed Oct 19, 2016 8:05 pm Post subject: |
|
|
| Roman_Gruber wrote: | | k3b pulls in ~100-200 unneeded junk packages. In the past I removed half of it and k3b still worked. I do not bother anymore with kde 9999 ebuild. kde has a very poor dependencies for kde packages for serveral years. |
Way to go.
In the past, every KDE based software depended on the huge kdelibs blob. People complained.
In the present, KDE based software depends only on those split libraries that it really needs (of course, 'more' dependencies). People complain. |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 31354
Location: here
|
| Posted: Fri Oct 21, 2016 10:30 am Post subject: |
|
|
| asturm wrote: | In the past, every KDE based software depended on the huge kdelibs blob. People complained.
In the present, KDE based software depends only on those split libraries that it really needs (of course, 'more' dependencies). People complain. |
People always complain, no matter what 
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
