Thank you very much for the clarifications Lee, I am sure many will find an interest in the content as well.
I only use openbox and borrow some desktop applications here and there from other desktop sets, like lxterminal and lxappearance. Some I have to admit instead of building on my own I borrowed from void-musl. So much of the ongoing change doesn't really affect me. If you only offered i3 and jwm that would have been fine and plenty for my needs, but I understand others prefer a more complete/full desktop.
The only sources of information about sddm and ck problems I have found relate to setup and possibly the existence of a .xinitrc calling up ck. Some DMs seem to have an internal dependency for ck-launch ck-daemon and if an auxiliary file/conf calls up ck from within a ck session that breaks ck. But I haven't had direct experience with sddm for a long while.
I would rather see development and energy spent on the core system, init/service management than getting a screenlocker working with live-video-feed. I assume there are reasons to focus some marketing efforts one direction or another and it is not really my business. I wish I had the abilities to contribute to the project but I am still in the learning process to reach stage 0.
It is not that I am leaving, it is more that I can not promote Adelie as much as I did. I like Kiss (k1ss.org) and ataraxia projects as well but Adelie had more intersection between what I at least wanted and expected.
I have barely gotten up by being slapped by Void's move to elogind, and now I get hit again :) Just when I had gotten s6 and 66 working on both and keeping up with development, now I have to go try to remove busybox from K1ss and try my luck there.
At least you haven't adopted .zstd compression, so there are still some score points for Adelie.
I'm really sorry to hear that you'll be
leaving us. None of us on the Adelie team are happy about the
ConsleKit2 and elogind situation either.
I led the most recent push to abandon ConsoleKit2 and I will
personally be taking responsibility for this situation moving
forward.
Unfortunately, none of the options we had here were good.
Our first option was to just keep using ConsoleKit2. But this is
just no longer feasible for us. Most upstream developers who were
using it have switched to logind's interfaces, so someone has to
patch upstream code to support ConsoleKit2. Gentoo decided to
abandon ConsoleKit2, and Gentoo was the largest Linux distribution
in both user base and developer base that was still using
ConsoleKit2. So Gentoo abandoning it meant that the largest base
of potential contributors had vanished, which means that we would
need to take on that responsibility if we wanted to continue using
ConsoleKit2. But Adelie only has about 5 core contributors, of
which only 1 can work on Adelie more-or-less full time. And we
already have to spend too much of the limited time we can devote
to package maintenance on other issues. Supporting musl very
frequently requires us to patch code, and it requires us to test
things thoroughly to detect potential breakage. Supporting big
endian systems like PPC32 and PPC64, also requires a huge amount
of effort -- you do not want to know how painful it is for us to
patch firefox's rendering code every time a new release comes out.
If we had more developers who could commit time to maintaining
ConsoleKit2 and support for it, then we would continue to support
it and commit to not having elogind.
Our second option was to just remove ConsoleKit2 and patch out the
few places that want (e)logind or ConsoleKit2. That patching would
still take significant development resources that we don't have.
Worse, this would prevent power management functionality from
working in desktop environments. One of Adelie's biggest goals is
to produce a desktop system that anyone can use regardless of how
much or how little experience they have with Linux. Not having
working power management in a desktop would at best look like a
lack of functionality and at worst look like a bug, and software
must work. So this wasn't an attractive option to us either.
Third, we could have made our own replacement for elogind. But
this would have required even more development time than the other
options, so this is just not an option.
Ultimately, we have to keep up with what our primary goals are: POSIX® compliance, compatibility with a wide variety of computers,
and ease of use without sacrificing
features, with minimal hardware requirements, truly libre
software, and standards compliance. There is nothing in those
goals that says we must avoid using elogind or even systemd.
Arguably, the "without sacrificing features" and "standards
compliance" goals say we should be using elogind.
As for the concerns about systemd, there is absolutely nobody in
the core team who would support switching to systemd as an init
system or even offering it as an option. Our long term plan is to
support s6 and OpenRC, and this will not change for as long as I
am involved in this project.
I would also like to address some of the points you rose in your
message:
On 25/07/2020 05:54, Fungi4All wrote:
I heard the justification that elogind was a good thing because we need wayland.
The decision had nothing to do with wayland. There are other issues
that have been slowing its adoption not just on Adelie but on other
distros, and ConsoleKit2 was not one of them.
What I am afraid will happen is not whether those who really need elogind will get elogind, but much of the stuff that doesn't really need it will also get it, forcing people like myself to have it because stuff stopped working.
These are the only packages that reference it as a dependency:
- bluez, though it's a notoriously bad piece of software anyway
- kscreenlocker, which needs it for managing access to the console
- plasma-desktop
- polkit
- networkmanager, which only uses it for session and suspend
tracking, and I think can work without elogind
- sddm, which is KDE's preferred login manager, but totally optional
if you want to run KDE.
As far as I can tell, they only need the dependency because of
shared libraries, and will still mostly work at runtime without
elogind running.
As of right now, elogind is not enabled by default.
And would stuff that need elogind work without having dbus? So dbus must be working for elogind to work so that other stuff will work as well.
You would still need to have dbus running, but it's far from the
only thing that needs dbus. And, again, elogind is only needed for
limited things like power management, session switching, and some
screen lockers. There are screen lockers like i3lock that don't
require it, and things like the shutdown command will work with
sysvinit or s6-linux-init without needing elogind or dbus.
So the trojan horse comes in layers. As long as the excuse that pid1 is not systemd we can be perceived as rebels. That is what devuan said, artix since day 1, and void much later, ataraxia, alpine, ... I think this only leaves Kiss-Linux out with the specific commitment to "not expect elogind ever to appear on the repositories" https://k1ss.org/software#3.0 and of course Obarun last but not least.
elogind is forked from systemd, and it's the only systemd daemon
that we will use, and even then it's just a fallback until a better
option becomes more feasible. We are still committing to not using
systemd as PID 1, not using systemd-journald, not using
systemd-networkd, not using systemd-homed, not using
systemd-machined, not using systemd-timesyncd, etc.
"But what is a distro to do, we can't rewrite and fork all upstream desktop stuff"
Drop Gnome from the repository, if you are supporting. If not, now you could!
KDE works on top of this hollier than crap QT platform, and elogind has penetrated right through this layer through dependent software and now plasma does not work without it. It does seem to work fine in obarun.
So drop KDE plasma, or at least any particular pieces of software that need it. There are choices.
"[E]ase of use without sacrificing features"
is one of our core principles, and so is giving people a real choice
in what desktop environments they use. We can't just refuse to
provide desktop environments because we don't like one piece of
software that they interact with. Doing so would be even more
hostile to users than supporting elogind.
But getting xfce4 applications to work with elogind and need it when they didn't upstream to me is a breach of contract.
I'm not sure what you mean by this, but we will not make things
depend on elogind that don't depend on logind upstream. There's just
no good reason to do that, and it would be a waste of everyone's
time.
I should have known 2 years ago when I first installed adelie and noticed that pretty much anything LXDE related was absent but LXQT buggy stuff was everywhere. So ultimate stability LXDE/XFCE4 was not a priority but lxqt and plasma were. That should have been a good indicator of where this was heading to.
There are people on the team who use Plasma and XFCE now. I don't
remember what the situation with XFCE was back in 2018. There are
some other window managers we maintain too. If we had contributors
who could maintain additional desktops, then we would have them and
support them at the same level as other desktops.