So, no more working Skype for Slackware 15? The older versions crash because the new GLIBC, the newer ones needs systemd-logind
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It may do, but you first have to have it installed on your smartphone. Seeing as I don't use a smartphone, I can't use Viber, therefore I will continue to use Skype.
How about some important people for us, to switch from radical systemd hate to just a moderate systemd hate?
You know, just like the other non-systemd distributions do, I do not ask them to wear t-shirts with Pottering...
I don't hate systemd, I just don't trust it. So I'm not even a moderate hater, but a skeptic. Seeing as systemd acts as userspace, I don't want to be skeptical of something so integral to my system. Additionally, SysV is much, much more stable.
Last edited by Lysander666; 09-29-2018 at 07:17 AM.
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.
A program announces itself on the D-Bus so that other programs can check for its presence and act accordingly. ConsoleKit2 and (e)logid both do this. It is up to the programs that require the functionality, to check for either or all of them. If they only check for (e)logind then I consider that a fault. If they check for both (perhaps in the order (e)logind --> ConsoleKit2) and use the first one that answers, we all win. That is what co-operation is all about. Programmers should accept that people have different opinions and preferences for their OS or distro, and should not be so presumptuous as to decide what is best for the users (support only systemd, boo ConsoleKit2 is what I would call presumptuous). KDE checks for both of them. And even if some of their developers are presumtuous and make decisions we do not like, we can talk to them and convince them to change their ways (that is how COnsoleKit2 support was added in the first place).
Quote:
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.
That way you would not be able to install both ConsoleKit2 and elogind or systemd. Blame the D-Bus inventor. If an application finds "org.freedesktop.login1" it will rightfully conclude that it will be talking to systemd-logind (or its offshoot elogind which is the same code).
Quote:
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.
Yes, and programs do these queries to determine the system's capabilities. Checking OpenGL capabilities works just fine, D-Bus is a disaster, and a fork like MariaDB is something that happens regularly to software and other programs will have to work with that. Nothing new.
Quote:
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.
You ever roamed the bug trackers where Poettering and friends rule? No chance in hell that what you want is going to happen.
Quote:
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.
Exactly, because why would they? They want to "control PID 1" and will not accept other implementations. That is the whole point behind their replacement of all kinds of system daemons with systemd.
Quote:
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)
A program announces itself on the D-Bus so that other programs can check for its presence and act accordingly. ConsoleKit2 and (e)logid both do this. It is up to the programs that require the functionality, to check for either or all of them. If they only check for (e)logind then I consider that a fault. If they check for both (perhaps in the order (e)logind --> ConsoleKit2) and use the first one that answers, we all win. That is what co-operation is all about. Programmers should accept that people have different opinions and preferences for their OS or distro, and should not be so presumptuous as to decide what is best for the users (support only systemd, boo ConsoleKit2 is what I would call presumptuous). KDE checks for both of them. And even if some of their developers are presumtuous and make decisions we do not like, we can talk to them and convince them to change their ways (that is how COnsoleKit2 support was added in the first place).
this might go for OS software like KDE that decide to support as much systems as possible, but not for Software where devs have a hard time to make it also work on Linux.
And we are back at the problem why some software never make it onto Linux,
Also, it's often a heroic effort of single developers to make some software available on Linux, and the thank you is a shit storm of a people that shout loudest. Result: management says never again.
Quote:
Originally Posted by Alien Bob
That way you would not be able to install both ConsoleKit2 and elogind or systemd. Blame the D-Bus inventor. If an application finds "org.freedesktop.login1" it will rightfully conclude that it will be talking to systemd-logind (or its offshoot elogind which is the same code).
so here we come closer, its not just detecting an alternative service, it migt be talking 2 different languages.
Back to the problem why some software never comes to Linux.
Quote:
Originally Posted by Alien Bob
Yes, and programs do these queries to determine the system's capabilities. Checking OpenGL capabilities works just fine, D-Bus is a disaster, and a fork like MariaDB is something that happens regularly to software and other programs will have to work with that. Nothing new.
the OpenGL is an example where it doe not work just fine. Just ask KDE devs, or game dev engines writer
Quote:
Originally Posted by Alien Bob
You ever roamed the bug trackers where Poettering and friends rule? No chance in hell that what you want is going to happen.
Sorry Eric, a bad example. Slackware doesn't even have an bug tracer, and Slackware devs that are here are not known to be the friendliest persons on the planet. In opposite to Slackware systemd is an open place
And btw, I visited the place, and read there, Pottering is very professional in handling this. For all the shit he got , inclusive dead threads, he is astonishing patient and professional.
In the Slackware world users can say something, and they are not just ignored by the official 'devs', they get a load of shit from technical total unskilled self declared knights of Slackware that are on the top peek of the Dunning–Kruger wave.
But of course, haters are going to hate and find the one sentence they can put out of context to put their beliefs on.
Quote:
Originally Posted by Alien Bob
Exactly, because why would they? They want to "control PID 1" and will not accept other implementations. That is the whole point behind their replacement of all kinds of system daemons with systemd.
It's a bit more than just having pid1. And if you dig into the concepts behind it, there is a lot of interesting and good stuff form system design point of view.
Quote:
Originally Posted by Alien Bob
I think you live in a world where I do not live.
don't we all do this?
My take on this: Slackware does from time to time state some strong opinions.
Years ago it was PAM. And what was the outcome? A distro that did not work for a lot of people anymore, and the arguments used by Slackware community to defend this decision? You can read it up here, some of the most embarrassing threads full of FUD and technical nonsense have been created on this topic. I spare now to mention the multi-lib decision.
Seriously, I have nothing against deciding for or against a technology, but in the Slackware world, things tend to become nearly a religious topic.
And if things works on most other distributions, and my job/hobby is not to make Slackware working or something on Slackware working, than it's very clear that the alternative is that the use case for Slackware becomes for more and more people less and less (but this is a topic already handled in a different thread)
At the end, evolution will show who/what is right, and the used systems in 10 years will tell us which decisions of today have been wise and which not.
Sorry Eric, a bad example. Slackware doesn't even have an bug tracer, and Slackware devs that are here are not known to be the friendliest persons on the planet. In opposite to Slackware systemd is an open place
Is this a bad joke or are you just trolling? Have you ever actually reported issues for either? Personally I'm banned from the systemd bug tracker for disagreeing with Poettering's assessment to not fix an issue.
In the Slackware world users can say something, and they are not just ignored by the official 'devs', they get a load of shit from technical total unskilled self declared knights of Slackware that are on the top peek of the Dunning–Kruger wave.
It's safe to say a Slackware user in general is not technically unskilled. Their area of expertise might not be yours, but that doesn't mean they're technically unskilled. And for every Slackware user beneath you there's sure to be many above you who could say the very same about your own skills.
Quote:
My take on this: Slackware does from time to time state some strong opinions.
Years ago it was PAM. And what was the outcome? A distro that did not work for a lot of people anymore, and the arguments used by Slackware community to defend this decision? You can read it up here, some of the most embarrassing threads full of FUD and technical nonsense have been created on this topic. I spare now to mention the multi-lib decision.
Seriously, I have nothing against deciding for or against a technology, but in the Slackware world, things tend to become nearly a religious topic.
Religious zealotry is often found in those who hate it the most.
Last edited by Gerard Lally; 09-29-2018 at 07:11 PM.
this might go for OS software like KDE that decide to support as much systems as possible, but not for Software where devs have a hard time to make it also work on Linux.
And we are back at the problem why some software never make it onto Linux,
Also, it's often a heroic effort of single developers to make some software available on Linux, and the thank you is a shit storm of a people that shout loudest. Result: management says never again.
I think that you need to have a good story and be able to withstand a shitstorm if you create something which is not universally accepted. You found that out when you wrote software, I found that out when I contributed to Slackware. You need to stick to your beliefs and accept that not everyone agrees.
Quote:
Sorry Eric, a bad example. Slackware doesn't even have an bug tracer, and Slackware devs that are here are not known to be the friendliest persons on the planet. In opposite to Slackware systemd is an open place
My experiences are completely different. Glad you can communicate with them.
Quote:
And btw, I visited the place, and read there, Pottering is very professional in handling this. For all the shit he got , inclusive dead threads, he is astonishing patient and professional.
Here I disagree. Patient and professional is not the same as listening and cooperating. This guy is paid by Red Hat to do this job. I am not paid to visit this forum and share my opinions and assist others. I am patient with people who come for help and show they want a two-way discussion instead of spoonfeeding. I can argue with people that have opposite opinions as long as the arguments are not religious, fanatical or dogmatic. But I do not have to be 'professional' since I am just another enduser here.
Quote:
In the Slackware world users can say something, and they are not just ignored by the official 'devs', they get a load of shit from technical total unskilled self declared knights of Slackware that are on the top peek of the Dunning–Kruger wave.
But of course, haters are going to hate and find the one sentence they can put out of context to put their beliefs on.
If Slackware were an enterprise distro the story might be different. But this is a distro created by people with a strong passion, for a small group of people who find that that passion matches theirs. Strong opinions are the result, What did you expect? Roses?
Also, there is only one "official dev" and that is Patrick. My sigature states that my opinions are mine alone and do not reflect Slackware's position. Please always keep that difference in mind.
Quote:
It's a bit more than just having pid1. And if you dig into the concepts behind it, there is a lot of interesting and good stuff form system design point of view.
I will not deny that some of the design principles are solid, but the execution is faulted.
Quote:
My take on this: Slackware does from time to time state some strong opinions.
If you mean: me, please make that distinction. Slackware (aka Patrick) does not voice strong opinions here.
Quote:
Years ago it was PAM. And what was the outcome? A distro that did not work for a lot of people anymore, and the arguments used by Slackware community to defend this decision? You can read it up here, some of the most embarrassing threads full of FUD and technical nonsense have been created on this topic. I spare now to mention the multi-lib decision.
Seriously, I have nothing against deciding for or against a technology, but in the Slackware world, things tend to become nearly a religious topic.
And if things works on most other distributions, and my job/hobby is not to make Slackware working or something on Slackware working, than it's very clear that the alternative is that the use case for Slackware becomes for more and more people less and less (but this is a topic already handled in a different thread)
At the end, evolution will show who/what is right, and the used systems in 10 years will tell us which decisions of today have been wise and which not.
But Slackware evolves as well. The decisions made along the road are not based on public votes, and any decision that has been made will be met by people who do not like what has been decided. Slackware is not Debian, and there's a single strong will with a clear vision who makes those decisions. You either go with them, or you defend your position with good arguments (and then you either convince people or not). But the end result is created by one man, and that means not everybody will get everything they wanted.
"Skype for Life" is the last unifying UI/client.
I suppose that "Skype Classic" will become harder, and harder to "keep up" for Repo sources.
As I can't imagine it being any "easier" or "better" for the Linux camp.
"Skype for Business" is AWEFUL.
I get a single chat window and the "history" is all screwed up.
To see what happened at 8am, I have to open the /msg from 8AM (or whatevs timestamp, then I can read the content of the /msg
Every single /msg is also emailed to me.
stuff is broken in current throw some money at the team Like I did every little bit helps. or down load Kubuntu like I do and boot to it when I want things to work. then boot back to slackware when I need to have raw tools for devel.
stuff is broken in current throw some money at the team Like I did every little bit helps. or down load Kubuntu like I do and boot to it when I want things to work. then boot back to slackware when I need to have raw tools for devel.
"Stuff is broken in current". If you know that already, point everyone to the fix please?
While i might agree or not to one side or the other, I find this kind of threads both useful and telling.
On one side, there are users who want Slackware to be less like Slackware and more like some other distro, yet they continue to sit on Slackware.
The Slackware appeal is strong?
On the other side, there are users with the sleeves rolled up, who word their opinions based on what they've done.
the charcoal of our Slackware locomotive
But in the end, threads like this not only are exciting to read (to me at least) but also provide useful insight of the Slackware development mechanics and engineering decisions.
To the OP:
Sir, If You really don't mind systemd, why not make a list of packages from Dlackware and "have it on"?
Why must it be the vanilla mint install to make You and You alone happy?
Or, is Skype, perhaps, shipped with Windows? (no) or OSX (rofl!)
See? nobody cares to include it all, nor make it easy to have it all. Yet still the (not paid!) Slackware makes it easy to have it most.
As AlienBOB stated - if you don't care to make it more easy for Slackware to do so, why don't You go places elsewhere and use Your excellent persuade power on other people - You are really great at persuading?
In the end, maybe they will turn out easier to persuade?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.