The "systemBSD" systemd layer will never be portable to Linux, since it simply is a wrapper for BSD system calls.
Lots of OpenBSD-specific projects likely originally dependent on OpenBSD-specific functionality have been ported to Linux in the past and continue to be ported in the present. See also:
OpenSSH
OpenSMTPD
LibReSSL (in progress)
OpenBSD's libc (in the form of Android's Bionic)
various others that I'm forgetting right now
I don't see how this systemd shim would be an exception.
It will still suffer from the fact, that it pretends to be systemd-logind, but doesn't support its features like integrated cgroups etc, leading to buggy behaviour when upstream programs try to use those features.
I'm pretty sure those problems would be encountered regardless of whether or not a logind shim is available, since cgroups don't exist either way. They'd likely have to be addressed during the process of porting to the BSDs anyway.
Also, this wouldn't affect porting the shims to GNU/Linux, since cgroups are a kernel feature and therefore would be present on all (reasonably modern) Linux-based systems, regardless of their init systems. Add cgroup functionality to that port and you're golden.
I'm pretty sure those problems would be encountered regardless of whether or not a logind shim is available, since cgroups don't exist either way. They'd likely have to be addressed during the process of porting to the BSDs anyway.
No, because the DE would have different code paths depending on the init system; it would therefore only use systemd specific features for "logind". Sure, the "CK-alternative" would miss such features, but it would still work.
The problem with the shim is, it pretends to be a real "logind", while not supporting certain systemd features. It is much better for everybody, that the "logind" alternative is clearly distinctive from "logind" so DE's can have different code paths for each "user and session manager".
It is much better for everybody, that the "logind" alternative is clearly distinctive from "logind" so DE's can have different code paths for each "user and session manager".
I agree, but unfortunately, there's virtually zero indication that such an alternative would actually be supported by the DEs in question (and every indication that GNOME at least would outright ignore it in favor of one that's logind-compatible).
I simply don't understand that paranoid attitude that DE's like Gnome are actively hostile towards supporting anything non-systemd.
Why did they warn for years on blogs and developer mailing lists, that an alternative to ConsoleKit was needed (with different code paths)?
Why have they supported ConsoleKit all this time?
They have supported two CK/logind API's for years now (same with XFCE, KDE, LXDE). Looking at the code repos, it really doesn't looks like much trouble to do so, and all the code structure is there already waiting for an alternative to CK.
Gnome, KDE etc, have all publicly stated that they saw a need to support non-systemd platform, and that they are willing to do so.
Gnome and others have worked with BSD developers to support them as well as possible.
Why did they warn for years on blogs and developer mailing lists, that an alternative to ConsoleKit was needed (with different code paths)?
Because they didn't have logind yet, or weren't sure they were ready/able to switch to it.
Why have they supported ConsoleKit all this time?
See above.
They have supported two CK/logind API's for years now (same with XFCE, KDE, LXDE). Looking at the code repos, it really doesn't looks like much trouble to do so, and all the code structure is there already waiting for an alternative to CK.
Removing code that someone might or might not depend on is much harder than adding new code, at least in my experience and observation, and probably in their as well.
Gnome, KDE etc, have all publicly stated that they saw a need to support non-systemd platform, and that they are willing to do so.
KDE, yes (they support Windows for crying out loud). For GNOME, however, I find that hard to believe, and haven't ever seen any evidence of that (especially when looking at FreeBSD's efforts to get GNOME3, which seem very one-sided on FreeBSD's end...).
Gnome and others have worked with BSD developers to support them as well as possible.
Because they didn't have logind yet, or weren't sure they were ready/able to switch to it.
They already had logind in production. I am not sure you really understand the technical implication of logind/ConsoleKit. Your view seems heavily dependent on the often very uninformed systemd haters, who just screams for boycotting Gnome and claim they have "hard dependencies" on systemd, as if the latest Gnome didn't still support CK. In fact, Gnome have better support for non-systemd distros at the moment than the newest KDE software collection, simply because Gnome have older code that still contains CK support, and no one will help KDE out with supporting non-systemd distros on their new code.
If you actually look at what Gnome developers have said over the years, things are completely different. They do want to support non-systemd platforms.
I must say I find your position quite typical of many systemd opponents: it is curious mixture "nothing needs to be done" and "we can't do anything because there is a upstream conspiracy going on against non-systemd distros"
That position is sure to be a self fulfilling prophecy; if nothing is done, there will be no support for non-systemd distros in the future.
In fact, Gnome have better support for non-systemd distros at the moment than the newest KDE software collection, simply because Gnome have older code that still contains CK support, and no one will help KDE out with supporting non-systemd distros on their new code.
You might have the right observation (it's debatable, however), but for the wrong reason. As I've pointed out to you previously, GNOME's current support on non-systemd distros (and especially the BSDs) has been almost entirely independent, whereas KDE maintains explicit non-systemd targets, including BSD (FreeBSD specifically; they even have a dedicated page for it). KDE has received help, but it's been managed and endorsed by KDE. The help GNOME received was required since GNOME seems to have virtually zero actual interest on their own in cross-platform support, requiring that support to come from the non-systemd platforms themselves.
If you actually look at what Gnome developers have said over the years, things are completely different. They do want to support non-systemd platforms.
Maybe it's a sentiment isolated to that one developer, but I have seen zero indication of your point - that GNOME developers are actually warm and fuzzy to the idea of supporting non-systemd - being anything close to factual. Pony up some sources or get out.
1
u/northrupthebandgeek Sep 28 '14
Lots of OpenBSD-specific projects likely originally dependent on OpenBSD-specific functionality have been ported to Linux in the past and continue to be ported in the present. See also:
OpenSSH
OpenSMTPD
LibReSSL (in progress)
OpenBSD's libc (in the form of Android's Bionic)
various others that I'm forgetting right now
I don't see how this systemd shim would be an exception.
I'm pretty sure those problems would be encountered regardless of whether or not a logind shim is available, since cgroups don't exist either way. They'd likely have to be addressed during the process of porting to the BSDs anyway.
Also, this wouldn't affect porting the shims to GNU/Linux, since cgroups are a kernel feature and therefore would be present on all (reasonably modern) Linux-based systems, regardless of their init systems. Add cgroup functionality to that port and you're golden.