Again.

Rather than keep moaning and whining, get your thumbs out of your ass and start filing bug reports. The way to get support for ConsoleKit2 into an application is to tell the developer that this is requested. Otherwise they will never know that this is beneficial.
A sane person will not look here in LQ's Linux section and read your incessant rants filled with capitals and colored bold texts. Unless they are masochistic or mentally unstable.

Rather than keep complaining and demanding that Slackware switches from ConsoleKit2 to elogind, why not actually assist Slackware by lobbying your beloved "poor application" developers to add support for ConsoleKit2? that way, you can actively work to prevent a future where Systemd-logind has become the de-facto session/seat management solution and no other implementations are accepted.

Being OK with 'vendor lock-in' in open source software, just because no one bothered to stop talking out of their asses and take action, that's almost criminally insane.

9 members found this post helpful.

Can you confirm if it's as stable or works as well as the client?

Also, I would caution using skypeweb to record calls. Especially the latest version of Chromium [69] has issues with Pulse and I wouldn't like to try recording calls through skypeweb on it. I acknowledge that only a few people will need to record their calls, but for those that do, this information may prove useful.

I'll also throw in a link to my video on recording Skype client calls in Slackware.

1 members found this post helpful.

It works for all I do with it sometimes, but I am not regular skype user. Usually just some other person insisting me to do web chat over skype.

being a noob on this topic, but very interested though, why is ConsoleKit2 the technical better, and more sustainable, solution than elogind?

4 members found this post helpful.

The elogind sources are copied verbatim out of the systemd source tree and then modified to work standalone i.e. not requiring the rest of systemd. However, elogind still requires a OS configuration that enforces systemd runtime mounts and cgroups making it look a lot like systemd is present anyway.
The danger is that at some point the systemd developers make an incompatible change in their code which makes it impossible for Slackware and other non-systemd distros to keep using elogind.
On the other hand, ConsoleKit2 is independent from systemd, and its implementation of the relevant portions of the logind d-bus API is independent of the implementation of systemd-logind or elogind. Any program which wants to use the logind API for seat and session management information and to get early warnings of system shutdown or power setting changes, needs do nothing more than make the right DBus calls into the system. The only caveat is that D-Bus is an architectural disaster, and an "API" is not actually fixed because the implementors of that API can use free text strings to name their service (org.freedesktop.login1 versus org.freedesktop.ConsoleKit for instance). Therefore any such program needs to add a block of code that iterates through the known implementations of the logind API (systemd-logind or ConsoleKit2) and connect to the one it finds. This is trivial, and every sane programmer who wants his software to be used as widely as possible without enforcing vendor lock-in, can simply honor the requests to add support.

That's the story for open source code. Adding support for ConsoleKit in Skype which is a closed-source implementation using open source code and then some other stuff, will be a lot harder because there is no public repository and we can not contribute patches.

If you look at ConsoleKit2, it has a git repository, and it has been accepting and implementing all the patches that were submitted to make it work better in Slackware. The fact that development is slow, may be caused by the fact that the developer of ConsoleKit2 is also the lead developer of XFCE. He works on ConsoleKit2 only if asked or if bugs are found. So I would ask of you all, to submit proposals and patches.

16 members found this post helpful.

According to this post, the logind dependence may actually be coming from Electron, which is used by Skype. So if they add in support for ConsoleKit2, then maybe in a future version of Skype this issue will go away automatically without Microsoft having to do anything other than use a version of Electron with the fix. It would also avoid the issue in other Electron-based apps.

1 members found this post helpful.

Do not know how to multi-quote on here so the above is mangled.



The offending software was Skype btw and not ConsoleKit2. Which was fixed on the innocent side very quickly, Skype has been wonky on Linux since day one. What software depends on Skype? Nothing. What software depends on ConsoleKit2? A vast ecosystem. So remove the piece effecting the rest of the system instead of a user land piece of crap? That is not good reasoning.



I see elogind and I assumed systemd for some reason. It is about as valid an assumption as your FUD.



No, the switch away from XFree86 was purely due to licensing issues and a perceived moral authority of the GPL.



DarthVader you seem to be the type that will fix something not broken and therefore will break it. The lack of activity for ConsoleKit2 tells me they are doing the correct thing and not fixing something that is not broken.

2 members found this post helpful.

That's easy for you to say, but companies who make money is NOT going to change their protocol to accommodate the minority. You will either get on board or get thrown overboard!!!!!!! Microsoft know what they're doing and its sad. This is just the beginning.

1 members found this post helpful.

For Electron's developers to accept an eventual proposal for the ConsoleKit2 support, I believe that the Electron application must be capable to actively deny the computer's Suspend and Shutdown over ConsoleKit2 API.

Using the Skype as an example, imagine that Skype must be capable to disable the system's automated suspension, hibernation and shutdown while the user have a really long conversation while using his Bluetooth headset and apparently the computer is unused for a long period of time.

However, I am afraid that only (e)logind can do that for real.

Well, we should have expected those things since long time, considering the bells ringing everywhere.

As much as I dislike Microsoft ways, its mandatory for a computer in my household to have Windows on it (Business Purposes). Skype is a necessity for some of us. My wife do business conferences along with other things. The ones who don't care, this topic is not for you.

Sarcasm: We should tell our bosses they need to switch their client and see how for we get. Lol

1 members found this post helpful.

You are right. Microsoft has been doing this for decades, and they have been pushed back. Open Source has changed the landscape and it was the work and sacrifice, it is heroic, of people helping other people.

I remember when half the things or more we take for granted did not work on any Linux and it took many, many, hours researching and pouring over text files, writing scripts, all kinds of crazy things to get something to work. It is not that doom and gloom as it is amazing in just 18 years the hardware and software has improved drastically.

You may mean it is the end. Think. How many alternatives to Skype is there in the last 2-5 years?

We know that Microsoft provides Skype for at least one non-systemd Linux distribution (Android). It's impossible to tell without insider knowledge, but perhaps it would be easy for them to provide more generic non-systemd Skype binaries as well. Filing relevant bug reports with them seems worthwhile -- not much effort involved, with real potential to solve the problem entirely.

2 members found this post helpful.

I would not call Android as being Linux distribution like Slackware or whatever. It is completely different.

Imagine a very limited Linux system like our initrd (and using BusyBox too) which brings up the Android desktop made in Java.

However, Android has a very complicated set of features and permissions for apps, where are also tons related to Power Management.

Long story short, on Android platform I guess that the Electron apps talks directly with the desktop services.

Yeah, man! Nothing is broken and everything works perfectly!

In fact, who need to do something useful with his computer? Let's open it and just stare at login console for one hour or two.