elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. It's like saying that windows programs work on Linux, you just have to use wine - it's sort of true for now, but it's not something you can rely on.

> And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd.

I remember multi-seat working fine long before either systemd or ConsoleKit, so that seems pretty questionable.

> I would advise those projects to put their money where their mouth is and either start making improvements to elogind, or develop a new login manager that better fulfills the needs of gnome.

"The needs of gnome" are a constantly moving set of goalposts under the control of RedHat. Gnome worked fine long before systemd and systemd has not noticeably improved it (if anything the opposite); there was no technical consensus that the current hard-dependency was necessary, it was forced through because RedHat wanted it that way. So they're not going to accept patches to offer compatibility with non-systemd, and if they do then they'll just find a different way to hard-depend on a different part of systemd.

Isn't that the whole reason for using another init? Because you see full compatibility with systemd as being undesirable and you have the means yourself to maintain things yourself using other solutions? I don't get it, it sounds to me like you're now saying the opposite of what you did before.

>I remember multi-seat working fine long before either systemd or ConsoleKit, so that seems pretty questionable.

Multi-seat might have worked but it did not do so securely. The issue is that you need a daemon to multiplex the display and input devices, and programs that want to request logins must be able to speak a specialized IPC protocol to that daemon. Otherwise all you have is a bunch of setuid root programs that do not communicate and can easily clobber each other at any time. Remember that the kernel does not have any built-in support for this, these are just device nodes in /dev like anything else, and in the old days the X server just used to run as setuid root at all times and sessions running in the background could read the keyboard whenever they wanted or take control of the display. The issue doesn't just affect multi-seat either. Even on your laptop you basically need a login manager to do secure screen-locking. There are an absurd number of ways that pure X- or Wayland-based screenlockers can be escaped. In an ideal world the kernel would probably prevent this stuff, but it doesn't right now, so login managers remain necessary.

>"The needs of gnome" are a constantly moving set of goalposts under the control of RedHat.

1. GNOME is an open source project not in control of any one company or organization, and anyone can contribute or fork the project if they so desire.

2. Nothing was "forced through" as the decision was agreed upon by the current and previous maintainers. If you disagree, you can revert to an old version as previously stated. This may be unpalatable to you but it is not realistically possible for anyone besides you to write code that you will agree with 100% of the time. It's up to you to make the tradeoffs you want on your system.

3. Also as previously stated, there is no hard-dependency on systemd. You can get it working with elogind. If you refuse to because you fear it will break in the future, that's on you. The fact is that it works now.

Compatibility is the only way it becomes possible to make those changes. E.g. in the pre-systemd days there were at least four different syslog systems and at least three different cron systems. But because they conformed to standard interfaces and were loosely coupled to the rest of the system, users were free to choose any of them, or to make their own. Same with desktop environments: you can run KDE or Gnome or Xmonad or whatever, but since they all follow common standards, any program works with any environment.

If the systemd people want to make a shiny new init with cool features, great. It's when they break compatibility with alternatives that I have a problem with it.

> 1. GNOME is an open source project not in control of any one company or organization, and anyone can contribute or fork the project if they so desire.

> 2. Nothing was "forced through" as the decision was agreed upon by the current and previous maintainers. If you disagree, you can revert to an old version as previously stated. This may be unpalatable to you but it is not realistically possible for anyone besides you to write code that you will agree with 100% of the time. It's up to you to make the tradeoffs you want on your system.

The fact is that most contributions are made by RedHat employees on RedHat time, so anything that can be decided by 51% of maintainers is under RedHat's control (and I can't do anything to change that since I can't outspend RedHat). There was a decision to adopt systemd but it was very much not a consensus; there was bitter disagreement at the time (and still is).

Forking by a minority is only practical if the system is made up of small components with standardised interfaces between them. Good open-source citizens follow those standards for the sake of allowing their users to do that (e.g. KDE migrated from DCOP to the technically inferior DBUS for the sake of being able to have common standards and compatibility with GNOME). If the whole system is a big ball of mud with no way to replace or decouple individual pieces, then you can't ever change or fix one part of it without forking the whole thing, and you don't have the Four Freedoms in any practical sense.

That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two implementations, systemd-logind and elogind. You can choose either one, and only the first one requires systemd. Or if you really want you can choose to write another implementation. Or you can choose to hack GNOME and remove the logind bits and just run your display manager and shell insecurely as setuid root. Or you can revert it to some old version when consolekit was still supported. Or you can just do nothing and wait for someone else to guess what it is you want. You have options. If none of these will please you then I think you need to adjust your expectations because you can't have it all.

>The fact is that most contributions are made by RedHat employees on RedHat time, so anything that can be decided by 51% of maintainers is under RedHat's control (and I can't do anything to change that since I can't outspend RedHat).

I don't see what this has to do with anything. It's open source. If you want to collaborate, you can submit a pull request, work with the maintainers and get them to spend their paid time reviewing and merging your code. You don't need to outspend them, the code is already written and every bit of it lands on github ready for you to use it. Them getting paid more only benefits you.

>There was a decision to adopt systemd but it was very much not a consensus; there was bitter disagreement at the time (and still is).

I can't speak for other distros but looking at the actual Debian votes on systemd (not flamewars on mailing lists), your statement does not seem to reflect reality. Systemd, as well as support for alternatives like elogind, was voted in with strong consensus. https://www.debian.org/vote/2019/vote_002

>Forking by a minority is only practical if the system is made up of small components with standardised interfaces between them.

Systemd is composed of several small components, and its interfaces have become standard across many Linux distros, so this shouldn't be a problem.

>you don't have the Four Freedoms in any practical sense.

It is not reasonable to expect that every single person will have the time and expertise to contribute to any given project, or that every project will be structured in a way that lets them accept maximum contributions. I don't mean to dismiss your frustration with being unable to contribute. I get that. But you continue to have the opportunity to do so and you will for as long as these projects remain alive. The code is not going to magically disappear one day and it's up to you to find the time to actually dive in. Good luck.

Is there any commitment to treating those as stable interfaces, with a decent deprecation cycle around any incompatible changes? If so then that's a big improvement; there certainly didn't used to be.

> I don't see what this has to do with anything. It's open source. If you want to collaborate, you can submit a pull request, work with the maintainers and get them to spend their paid time reviewing and merging your code.

I saw patches submitted and rejected on the grounds that the project leadership had no interest in supporting non-systemd (and/or non-Linux). Even if the leadership does want to accept a patch, that can take months; in my experience it's not worth making a change if you can't run it on your own systems without upstream getting involved. So if a project is large and not cleanly factored into smaller pieces with stable interfaces between them (or at least open to being factored that way in principle), then it's just not worth trying to contribute unless you can work on it full-time.

> It is not reasonable to expect that every single person will have the time and expertise to contribute to any given project, or that every project will be structured in a way that lets them accept maximum contributions. I don't mean to dismiss your frustration with being unable to contribute. I get that. But you continue to have the opportunity to do so and you will for as long as these projects remain alive. The code is not going to magically disappear one day and it's up to you to find the time to actually dive in. Good luck.

I believe in open source not because it gives me a chance to write code but because it lets me fix bugs or change behaviour that's bothering me. It's the "RMS printer driver" situation; if something goes wrong in Linux these days I feel like I'm no better off than I would be on windows. For the moment I'm using FreeBSD (and KDE) and I can still patch stuff without my patches getting broken every other month, but as things integrate more deeply with systemd it seems like a matter of time before the programs I use go Linux-only.

What do you mean with project leadership. If someone submits a patch, the maintainer(s) of the git module can obviously reject it if they don't want to maintain it. Unless they're persuaded because it's better for the project as a whole.

However, you talk about "project leadership". That doesn't really exist. There's loads of maintainers. There's a GNOME foundation, which mostly handles admin stuff, sysadmin stuff, etc. There's a release team. They ensure the various maintainers make releases, plus verify stuff actually builds.

If you help out in GNOME you're just a person in a big group of people. There's not really any "leadership", just loads of people who often agree, sometimes disagree, etc.

About BSD and non-systemd systems: I actually think it is possible for there to be better compatibility here eventually if someone builds more shims. BSD using Mesa for example is a really good thing for everyone. However FreeBSD and Linux have both refused to budge for quite a long time on various things and cgroups seems to have been the final nail in the coffin for any kind of expectation of modern cross-platform tooling. Everything now is container this, container that. The only non-systemd init that hasn't dragged their feet on this has been OpenRC, and even they still would not make any effort to be systemd-compatible because of objections over other things. So what is the solution here? Do you see how hard it even is to get people to run something like elogind on top of another init with another cgroup implementation? I don't blame the systemd developers for not bothering with that. It is not feasible to expect them to maintain everyone else's init as well as their own.

I checked the systemd contribution graph and it seems they have a large number of smaller contributions from outside developers, so the data does not really support your assertion about it not being worth it. https://github.com/systemd/systemd/graphs/contributors

Also, just going by the data, the repos for KDE (collectively) and FreeBSD (a monorepo, like systemd) are much, much bigger, just as tightly-coupled if not moreso, and get a lot more activity than the repo for systemd. It seems strange that you would pick those projects to contribute to.

You either hammer out a common interface with compromises from both sides, or you implement the parts you want as progressive enhancement from a lowest-common-denominator baseline. It's not easy, it's not glamourous, but it's the right way to do it. Look at how e.g. web standards stuff happens when there's disagreement between different browser makers.

> Also, just going by the data, the repos for KDE (collectively) and FreeBSD (a monorepo, like systemd) are much, much bigger, just as tightly-coupled if not moreso, and get a lot more activity than the repo for systemd. It seems strange that you would pick those projects to contribute to.

I'd disagree with the idea that KDE is more tightly coupled; in my (limited) experience it's very cleanly factored and it's clear where the interface boundaries lie. It's a big project but if you want to fork and patch one part of it you can do that.

FreeBSD is theoretically more tightly coupled than GNU/Linux, but in practice I've found a lot less of the kind of interface churn that you see in Linux. Linux went through two or three rounds of different audio APIs where on FreeBSD you still just use OSS. I've lost count of how many times the way you do network config on Linux changed - I genuinely can't set up a network on Linux any more - whereas in FreeBSD it's all just ifconfig. Linux forced a quick migration to HAL followed by an equally quick deprecation in favour of udev; FreeBSD is still using HAL. There's just so much more commitment to stable interfaces, both in theory - a deprecation cycle for even the kernel ABI - and in practical experience. Or maybe it's just that the project doesn't have enough manpower to churn as much as Linux does, but either way the end result is that I can patch my system and expect my patch to keep working.

That's because elogind is architecturally all wrong - instead of sticking to the defined stable public DBus interfaces of systemd, and implementing those independently from scratch, what they did was rip the implementation of systemd-logind out of the systemd package and hoping that the intentionally unstable internal interfaces in libsystemd that it relies on will continue to be provided.

> Gnome worked fine long before systemd and systemd has not noticeably improved it (if anything the opposite); there was no technical consensus that the current hard-dependency was necessary

There was a very, very simple reason for why Gnome depends on systemd-logind: nobody volunteered to maintain the ConsoleKit backend, or ConsoleKit itself for that matter, so it bitrotted and was eventually removed.

You do realize even the Linux kernel doesn't make any commitments regarding API stability, right?

That's kind of an explicit choice to allow the maintainers to move forward with the limited resources they have without too much red tape.

There's always *BSD, if you want compatibility back to the Sun days in some cases, (Win32 is another option). Linux is about being as modern as possible without having to worry much about backwards-compatibility and all the cruft that comes with having to maintain that.

It does for userspace APIs. Linus is notorious for chewing people out for breaking them (example: https://lkml.org/lkml/2012/12/23/75).

For most cases you would get better results by networking n cheap boxes rather than trying to buy a single beefy box to support n users on every dimension including perhaps even power usage if you used low power devices.

Contention for io is a problem. Everyone wanting to say decode video simultaneously is a problem. Browsers high ram usage is a problem.

This sentiment has always felt weird to me, as I have always seen UNIX as an OS that has been designed - from the ground up (in late 1960s) to support multiple concurrent users - whether it is via a serial terminal, and now multi-seat, VNC or an X terminal. By today's standards it's not even such a "beefy box" that can easily do that.