You are not logged in.
Pages: 1
I just noticed on this roadmap
https://wiki.xfce.org/releng/4.14/roadmap
that systemd is listed along with consolekit under "dependencies (tbd)." MX-15 and future developments are systemd free, though we have a couple of files that other applications need to find present, so this raises some future concern for us and our users (70,000 downloads from SourceForge and counting).
1) What exactly does "tbd" indicate?
2) Is consolekit an alternative being considered?
3) Can distros influence the decision?
What do others here think of having such a dependency?
Last edited by Jerry3904 (2016-07-04 15:08:42)
MX-23 (based on Debian Stable) with our flagship Xfce 4.18.
Offline
1) I've removed the tbd. There's some talk of just targeting 3.20 as a minimum for Gtk, but we'll see.
2) Consolekit and Consolekit2 will be fully supported.
3) You can always raise concerns on the xfce4-dev mailing list or irc channel.
Offline
But isn't systemd a good thing?
Curious,
MDM
Offline
@EtI: thanks for the response, we will have to think on how we want to pursue this some more.
@MDM: depends on the viewer, I guess. There's a huge online discussion of it out there.
MX-23 (based on Debian Stable) with our flagship Xfce 4.18.
Offline
Looking back, I see this post from ToZ:
Xfce supports systemd if its installed. If not, it will use the alternatives (e.g. upower). As far as I can tell, only two components come with systemd support - xfce4-power-manager and xfce4-session.
So, if your system doesn't use systemd, then Xfce won't use it.
As for a systemd dependency, thats up to your distro (Ubuntu Linaro) and how it defines it.
Xfce does not have a dependency on systemd.
Is everything there now void? It would be great if the bolded sentence could remain true in Xfce 4.14...
MX-23 (based on Debian Stable) with our flagship Xfce 4.18.
Offline
Probably best to wait for Eric to post again, but my understanding is that both systemd and consolekit will be supported and Xfce will not be dependent on either but will require one to work properly.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
That would explain the slash, which I did not get--i.e., = "or"
MX-23 (based on Debian Stable) with our flagship Xfce 4.18.
Offline
Correct, systemd or consolekit wise, things should work the same as in 4.12.
Offline
Most excellent, thanks!
MX-23 (based on Debian Stable) with our flagship Xfce 4.18.
Offline
But isn't systemd a good thing?
MDM
Most people think so, but there's a small, vocal minority with an irrational hate for it, just as there is with SELinux. Personally, I wasn't to thrilled when my distro (Fedora) adopted it, but I accepted the fact that it was there and I've learned to live with it.
Registered Linux user #470359
Permanently recovered BOFH
Any advice in this post is worth exactly what you paid for it.
Offline
Oh. I admit that I get somewhat uncomfortable when I think about SELinux, but this is mostly the "general" sort of uncomfortableness that one gets when thinking about a situation in which he/she trusted a well-known burglar to provide the keys/locks/security for his/her home, as opposed to a specific one.
Regards,
MDM
Offline
So my take on systemd is that some newbie programmer didn't want to learn legacy init idiosyncrasies (process to process dependencies), and instead implemented an init that explicitly stated/required dependencies. That's cool, but this introduced a lot of per process init overhead. This is mitigated(somewhat) by the fact that systemd is multithreaded. Sadly, the new paradigm suggested/required that the init process be completely broken down into sub-components, which with the added overhead completely spent any performance gains provided by multi-threading. In short, best case it's a wash, but a well thought out sys-v approach will totally annihilate systemd.
Offline
Pages: 1
[ Generated in 0.023 seconds, 8 queries executed - Memory usage: 563.01 KiB (Peak: 579.85 KiB) ]