You could even argue the point that how you see things like systemd is how you "were raised and grew up" into UNIX as well. Some of us grew up comfortably not minding standard UNIXisms and the classic design frameworks, while others may not have. The point is, if you stand for something, stand for it and stand by it, and be willing to be opposed. That's what having an opinion is all about.

There are many things I feel about systemd that it does well, but many it could do better, some it shouldn't do at all, and others it could do differently that would make it more acceptible rather than avoidable.

However, I've seen firsthand the problems init systems like systemd, runit, s6, etc. all try to solve and I've seen that one problem with systemd that, like other init systems, systemd could easily get around with some simple change.

As far as true benefits, I have yet to see them for myself. Speed and centralization is nice, but it's not what everyone wants or needs.

I thought I have answered that already, but maybe I made it not clear enough. The point is not what systemd gives you, the end user, the point is what systemd gives the developers of other projects. When other projects start to use what systemd offers you are in a lost position if no alternative is presented to those projects for the functionality they use provided by systemd. Even more so, if the already existing alternatives are not maintained anymore.
Indeed, I had those problems and if you have read my second post in that thread you linked to you can see that my problems were not caused by systemd, but by Gentoo still lacking NFS service files for systemd at that point in time. This is by the way fixed by now, NFS now comes with proper service files in Gentoo.
Please re-read my posts and the ones by Didier, I was merely reacting to his post. I do not think at all that you are childish because you oppose system, if you have valid reasons for that.
You missed the point again. Slackware works fine for now. But if more and more projects start to use systemd functionality because systemd provides functionality that is useful for them then in the future projects you might want to use will be broken in Slackware, unless there is a viable alternative presented to those projects. I am not preferring that you fade away and, frankly, I don't care about your opinion on systemd, but I think that it is very short sighted to think that alternatives to a project that is used by more and more projects are simply not needed. Slackware is a nice distro, but it is not the only one and it is dependent on other software projects. Pretending that what is going on in the Linux world will not affect Slackware for some reason is, IMHO, not something that is good for Slackware. Feel free to exchange Slackware with any other distro that wants to provide other solutions that systemd in the last sentence.

I have to ask, at which point would you consider a lack of functionality for example in KDE or xfce4-power-manager as serious enough to be harming Slackware?

The better question to that Tobi is what is needed to make them work without systemd? Once that can be settled on, the answer should become clear.

Offering a platform kit for developers is good and all, but it shouldn't obfuscate existing toolkits that can do the same work without being replaced outright. There's nothing wrong with coding for two standards which can be done currently, but forcing the issue to say there are no alternatives but systemd is ludicrous. Alternatives exist to actually say systemd is actually the alternative to the existing standard. The problem I see personally is developers getting complacent in going after one goal and ignoring others which only hurts the project's outreach.

The issue with session management we are plagued by because SDDM refuses to support ConsoleKit, is a nuisance but not enough to say "it harms Slackware". Nuisances that do not cripple the desktop itself, like session management, are not that important.
When KDE does not start anymore as a whole, or KWin no longer works, then the choices are: get rid of KDE or adopt systemd. My option would be to get rid of KDE from the core distro and start maintaining it outside of Slackware as a 3rd party add-on including systemd, but Pat is ultimately the one who decides about adding systemd and removing KDE. It's his distro, not mine, and I am already a sort of semi 3rd party repository manager anyway.
As I said earlier, this issue is not going to be relevant the next year or even two years. During that time, other implementations of systemd-logind (which is basically the only thing in systemd that is wanted by the stuff in KDE) could very well be available, and then the question becomes irrelevant.

4 members found this post helpful.

If KDE wishes to aim for systemd, as Gnome did, let them. As long as kdelib and the core libraries still work to import KDE applications to other desktops like Xfce, MATE, and Trinity, then it's no loss really.

1 members found this post helpful.

I don't know if that is and will stay possible, but that would fit my needs, as I occasionally launch a KDE app but never the KDE as a whole. I wouldn't really miss Kate (though it has a better syntax highlighting for shell scripts than geany, that helped me sometimes) or Konqueror (that displays some web pages better than Firefox), but I would certainly miss Lokalize, that I find better that poedit, e.g. as it can display the current column in the editor. I would have to learn to use either vim or emacs[1] and use their PO mode, and considering my age that's a real challenge

[1]Mentioning both editors should not trigger a new war between Lilliput and Blefuscu.

Funny!

;-)

Currently I think a good majority of Gnome 3 applications are importable to Slackware without the actual desktop handler (LFS does this actually), so as long as the minimal dependencies are met, the actual desktop environment generator app that runs on top of X is fickle.

I actually like Kate/Kwrite. Nice little editor but the newest 5.x version feels so different from the 4.x version.

For me that answer is already settled, of course you may see that different.
I think these are the available options:
- When a project relies on systemd functionality you can try to rip out the parts where that functionality is used. This may work for some projects, but not for others, mostly it depends on if you can live with reduced functionality.
- When a project relies on systemd functionality you can try to rewrite the parts where that functionality is used. This may be trivial in some cases, but not in others.
- When a project relies on systemd functionality you can try to convince the developers to not use systemd, possibly by pointing them to existing alternatives for that functionality, if those alternatives exist, together with actually maintaining said alternatives.
- When a project relies on systemd functionality you can try to come up with your own solution that offers systemd compatible interfaces. This overlaps a bit with the previous point, but this becomes a point on its own when you look at a kdbus and the lack of userspace components for it on non-systemd OSes.
- When a project relies on systemd functionality and older versions of that project are available that don't rely on systemd functionality you can try to keep this older versions alive and running.

All these points come essentially down to one thing: manpower is needed. All these points require work to be done.
I agree, nothing is wrong with coding for two standards, as long as those two standards are offering somewhat the same functionality. It becomes difficult to code for two standards that do not provide the same functionality, or when you come to a point where you suddenly do not face two, but six or more "standards" (see the NTP example in the blogpost of the KDE developer that was linked to earlier in this thread).
I disagree however with the statement that systemd as whole is an alternative to an existing standard. Certain parts of it may be such an alternative (logind <--> Consolekit, for example), while other parts are certainly not (timedated <--> six different NTP implementations with six different interfaces, the very definition of: not a standard).

Thanks for the clarification. However, when I see this:The question remains: who is providing those "other implementations of systemd-logind" when not those people that need it?

Huh! Who is working on a systemd-logind replacement, among others?: https://github.com/ConsoleKit2/ConsoleKit2
Oh, Thanks for that.

4 members found this post helpful.

the problem with the multiple tooklkit support it that if this is a compile time decision it leads to ugly and hard maintainable code.
developers in many project are happy that they can get rid of this code now, because in reality no developer maintains the 'exotic' (not so common) stuff .if you sit on a systemd machine its hard (read expensive) to test a non systemd behavior.
and/or often the 'exotic' (not so common) stuff influences and/or limits somehow the other code for the common cases.
So if developers say that they are happy to make 95% of all Linux users happy, you can not blame them or cry around how unfair this is. The only thing you can do is talk with them , send patches and ask if they would apply them.

The users being happy isn't the issue, it's keeping projects viable for standards across the board in UNIX so that projects can not only benefit but contribute back as well. Xfce only has one instance of a failure in this which is automounting in non-Linux systems due to the fact it uses udev as an event handler, such as FreeBSD.

By blatently sacrificing support in one area for a somewhat proprietary standard to one platform you cut off users and contributors as well by avoiding the open standard that's multi platform.

As far as replacements for logind go, several exist such as ConsoleKit2, loginkit, and systemd-shim. Currently we do have a build kit for ConsoleKit2 via my repository, but I don't know about attempting LoginKit yet or systemd-shim for a package. I did test Plasma's sddm and it refused to allow me a login to which it and all of KDE 5.x got ripped back out in favor of KDE 4.x. I could play around with loginkit this weekend and get a rough draft SlackBuild script created.

What exactly is the end-game with all these changes to 'new ways' anyway. What development point is the platform of linux trying to reach that it doesn't do now.

I suppose I mean, my slackware setup works and does exactly what I need - it has these days for example a first class word processor, image editor, web-server, video player, audio player etc... and choices of all these if I wanted to try others. Its networking is excellent, its remote connectivity is excellent, its security (over windows at least) is excellent (to me anyway). the functionality I get is first class. Im not sure I'm able to see what needs improving that would merit seemingly fundamental software like systemd etc.

When is the fundamental development of KDE, GNOME, or anything else ever enough for its purpose, short of improvements to security, removing bugs etc. What do people want. I just use openbox as my 'desktop'. That's it.

I'm not daft to think the world will stand still and not [allegedly] progress, but I must lack vision because I cannot see where a desktop, word processor and all the other stuff folk could mention for at least just an honest Linux experience these days, can go to deliver anything more than they give now. Years ago we might have asked, but is it something so remarkable being aimed for that is the goal these days.....if so what is it....will it move me!

Taking that a stage further, why is systemd or anything else required to improve my experience that I cannot do now for my business/private needs!

Linux is 'good' already. Slackware is 'good' already.

I'm sure I haven't worded what I mean too well, but I know what I mean :-)

Peace all.

1 members found this post helpful.