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.
_______________________________________________
Ad?lie Users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
