For one thing, I don't want apps overriding the powersaving settings that I have set. For another, even if what you say is true, it is still better for the app to at least run even if that particular "feature" doesn't work.

1 members found this post helpful.

I have dealt with Microsoft, and if its broke, you pay to get it fixed. This is just one of the reasons I started learning Linux. How much more do I need to spend just to have my computer run the way I want it to?
I'll probably end up on Apple's bandwagon if Microsoft don't get it together. Only then, when companies start losing money then they want to get their act together.

Well, sometimes is a useful thing.

You do not want your computer to auto-suspend after 30 minutes when you watch a movie, right?

Speaking of video-players like MPlayer or Xine, did you know how they do that?

There is a little and very known design issue on X11: the mouse can be moved not only by user, but also by applications. BUT the power management knows only that the mouse had been moved somehow.

And that's right on what MPlayer do. While playing movies, every minute it moves the mouse with 1 pixel. Left and right. Left and right.

The fun part is that that design issue does not exists on Wayland. Guess how they resolve that keeping the system alive on demand?

I am not a connoisseur of the Electron inner design, BUT apparently the NodeJS has a big "feature" : everything runs in a single thread for real. In a event loop.

AND if NodeJS goes down, the entire app goes down. Literally.

I observed this while working with NodeJS server apps. You can made even sites ran by NodeJS.

BUT, if in a PHP site something crash, the HTTPD survives well. Dies only that particular thread.

In a site running on top of NodeJS, if something goes nuts, the web server kicks the bucket unless you handle properly the exceptions.

1 members found this post helpful.

Personally, I use xautolock and a script that watches for CPU activity to enable/disable screen locking and suspending. It works exactly as I want it to, and I don't want apps overriding this behavior. Probably all the more reason to stay away from Electron-based apps, IMO.

1 members found this post helpful.

Thanks a lot for taking the time to explain this!

6 members found this post helpful.

For those of you using Chromium on their systems and satisfied with what Skype Web offers, here is what you can do to get something which almost looks like the desktop application (which also is just a modified Chromium with power management awareness, plus some JavaScript):
The "#" are of course the indicators for the root prompt, the hash characters are not to be typed in.

After running the above commands, look for the new menu entry "Skype Web" in the Network submenu. Start it and go through the Skype configuration once.
All subsequent start-ups, the Web app should just load and log you in.
You'll have a Chromium window with all the browser controls hidden so that it looks like a real application.

I will probably add this to my Plasma5 Live ISO instead of the actual Skype.

16 members found this post helpful.

For the pragmatic among you there is also the option of an old Nokia or Microsoft Lumia phone. 735 recommended. You can get good deals on ebay, and they're a very good phone, if you don't care much for app availability. (At 8GB storage is quite low). Windows 8.1 and 10 for mobile come with Skype included, and it works well. I use it to keep in touch with one contact. Microsoft are still updating these phones as well.

1 members found this post helpful.

I wonder how a proposal to implement whatever is needed from the systemd-logind/elogind implementation into ConsoleKit2 would be received? I guess "whatever is needed" isn't well defined but could at least start by meaning whatever is needed to satisfy "Software X" e.g. skypeforlinux; then extended to more software as needs arise (as seems inevitable). If the main developer is so otherwise busy, it would, of course, need contributions from people who might know how to go about it and are sufficiently motivated to bother. Any takers?

chris

1 members found this post helpful.

Well, two years back when I wanted to test Wayland in KDE and found that that requires a logind DBus service, I just emailed Eric Koegel and asked what he thought of the idea to extend the existing ConsoleKit2 functionality with the minimally required logind API services. I thought that was a good idea and went on with it. At a slow pace perhaps, but those are his own time constraints. Code contributions are usually accepted, I think Robby Workman and I contributed some in the past.
An idea would be to ask him if he could implement "org.freedesktop.login1" as a clone of "org.freedesktop.ConsoleKit" and make it configurable during compilation to enable this. Then, ConsoleKit2 would be sufficient to get Skype and possibly other programs to work on Slackware and other non-systemd distributions.
But the better approach would be to open bug reports for every program that only looks for "login1" and not for "ConsoleKit".

2 members found this post helpful.

Eric, with all respect due, the "org.freedesktop.login1" vs. "org.freedesktop.ConsoleKit" paths is a big mistake for everyone who worked in the past with APIs as programmer, does not matter the programming language.

Let's put blunt the current state. ConsoleKit2 (clone) vs. (e)logind (original) is not a novelty in the open source world.

For example, we can look to MySQL (original) and MariaDB (clone), which happened also for political reasons. True, they was not about "systemd sucks!" but still being political.

BUT, the idea that every application to be modified as to chose between MySQL and MariaDB APIs, that will be at least strange, and certainly in the web-development world will produce hilarity.

Sometimes is not even about political reasons, but purely technical ones. See the NVIDIA OpenGL implementation vs. Mesa OpenGL.

Same should be with the ConsoleKit2. And I believe that one of the reasons WHY nobody use it, excluding us, is because that "requirement"

How should behave ConsoleKit2, from my humble experience with APIs?

It should respond to "org.freedesktop.login1" just like (e)logind, because an API is not only about methods, but also about namespaces or paths. And leaving political slogans away, de facto that "login1 API" is exactly the one given by systemd-logind. Is their own invention and we, we try to implement it in another ways.

And of course to fully implement that "original" API before to add its extensions. Even it is about NOOP stubs.

Additionally, there should be a way for the client applications to query information about the "server" and its features.

Imagine that in the web-development world, you open a connection to a MySQL server. Does not matter for HTTPD and/or PHP that it is MySQL or MariaDB on the other side. Then, the application has the ability to query the information about the server type, version, features.

Same happens on OpenGL, where the application have the ability to query the information about OpenGL implementation and features.

Just like the OpenGL, we can implement a querying method (or several), from where the client application can get information about the real server implementation behind DBUS and the available features.

Even better, if we stop treating the systemd developers as blood sucking devils, we may try to propose to them to adopt themselves a similar querying.

Another idea (regarding overlapping over DBUS namespace) is the ConsoleKit to made at startup a check to see if there's something which responds on "org.freedesktop.login1" - that could be a systemd-logind, elogind or whatever future alternative. Then if the DBUS namespace (path) is populated, our ConsoleKit to refuse to start.

The same proposal we can made to elogind (and probably they will like it), even I am not sure if something like this will be also accepted by systemd developers.

This way we can keep a single server alive responding on "org.freedesktop.login1", even the user try to consecutively start several implementations (like I do myself today with elogind after ConsoleKit2)

The ideas from my previous post was supposing that Slackware Team intends that ConsoleKit to be a fully replacement and alternative to (e)logind.

That said, the Slackware Team initiative to develop his own LOGIND looks a bit strange for me, considering that Patrick Volkerding said multiple times that just like many has the Not Invented Here Syndrome, he has one named Invented Here.

Meanwhile, myself I am in a perfect vendor lock-in produced by this very choice, of ConsoleKit2 vs. (e)logind, and still the fresh released skypeforlinux-8.31.0.92 needs elogind to work in my computer. And I suspect that many other applications will misbehave in future, for same reasons.

Until then, how I fail to have radical views about something even in real life, I have to chose between the (minimal features of) ConsoleKit2 and full fledged elogind, then now I wonder how I move the entire system to elogind.

After the efforts of @chris.willing to make elogind more Slackware-friendly, and looking to the efforts of Widya Walesa from there: https://github.com/w41l/kde-elogind, the movement from ConsoleKit to elogind is considerable more simple than grabbing the Bible and going from porch to porch to evangelize the ConsoleKit2 true name, just like Jehovah's Witnesses.

BUT, that probably is worth for another thread.

Anyway I plan for future to use my own KDE4 build after it will be removed or replaced by the wonderful Plasma5 as everyone expects, so a handful of additional packages does not scare me.

We are not developing our own "Slackware logind", instead we asked the developer of one of the programs we are already using to help us and other non-systemd distros by extending functionality of his program. The goal is to prevent a (systemd) vendor lock-in. Don't try to turn the argument around to use it against me please.

The beauty of Slackware is not just that it is free, but also that you can adapt it to whatever you want it to be. You can switch to Dlackware if you want to use the real thing (systemd) or you can replace ConsoleKit2 with elogind and stuff will just keep working.

Again. We do not need to fix ConsoleKit2, we need to ask 3rd parties to add support for ConsoleKit2 as an alternative implementation of the logind D-Bus API. ConsoleKit2 supports all of the logind API that non-systemd distros need.

Feel free to replace ConsoleKit2 with elogind.
Or, create that .desktop file I shows a few posts earlier, switch to Skype Web and be rid of the proprietary requirements.

Please do not.

Who's stuck in the past now? I assume you still have not removed your thumbs from your ass. If you want Plasma5 to support features you think are lacking, you submit bug reports and feature requests. Find more people who need what you need, let them subscribe to your requests, and that gives your requests a bigger weight.
Not doing anything except writing bold red-colored propaganda texts in a forum not visited by any KDE developer, is not going to help you.

4 members found this post helpful.

while this might be theoretical true, maybe, it will not work in reality on scale.
This is exactly the point why some software never made it onto Linux.
Because software vendors said 'there are so many flavours' ..... and they are somehow right.

if ConsoleKit2 is not a drop in replacement, don't blame software vendors. Because I would know what I would tell you if you ask me to implement an other interface than that the huge majority of the Linux community agrees on.
If you or I like this agreement is irrelevant, ignoring it means either be locked out or accept a lot of work around and maybe second class solutions.

Is ConsoleKit2 this what all non systemd distros agree on? because if not, there is not much hope, maybe some Software will implement ConsoleKit2, but for sure never all.

2 members found this post helpful.

At least Linux From Scratch, CRUX, Devuan, Gentoo and Debian offer ConsoleKit2 in their repositories (Gentoo and Debian have this as alternative to systemd). Those are major players.

The Gentoo Wiki mentions "The planned multi-seat feature is not fully implemented. At the moment all local sessions are in Seat1, all other sessions are in Seat2". Otherwise the implementation is complete. This is the area where knowledgeable Slackers can assist Eric Koegel, the CK2 developer, with completing the implementation.

2 members found this post helpful.

than this is good, and needs to be nailed down and some more publicity, so that this can be added to issues like the one for skype on vendor pages.
because this would limit the choice to 2 and not to N and this is good

btw, there is a debian based windows subsystem Linux and its based on debian, but removed systemd, but dosnt use Devuan for reasons. wonder what they use if they need something like ConsoleKit2

1 members found this post helpful.