3 ms·

> elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. You do realize even the Linux kernel doesn't make an

> elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. 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.

jude- 6y ago
> You do realize even the Linux kernel doesn't make any commitments regarding API stability, right? It does for userspace APIs. Linus is notorious for chewing people out for breaking them (example: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75).
- AsyncAwait 6y ago
  Yes, I should have clarified I meant kernel-level APIs, not userspace.
lmm 6y ago
> You do realize even the Linux kernel doesn't make any commitments regarding API stability, right? You say "even" the Linux kernel; actually most projects don't and Linux is a rare exception, and I do think it's a bad idea for both technical and nontechnical reasons. (Compare with GCC's refusal to offer a stable API between frontend and backend, which I'd argue is a big reason why LLVM is overtaking it). > There's always BSD, if you want compatibility back to the Sun days in some cases, (Win32 is another option). I actually do run FreeBSD these days; one of the reasons this issue still bothers me is that compatibility with BSD is likely to be collateral damage from the systemd push (it's getting harder and harder to run Gnome on BSD, for example). It was particularly frustrating that systemd basically killed off Debian GNU/kFreeBSD just as it was becoming a first-class architecture; that could have been the best of all worlds.

jude- 6y ago

> You do realize even the Linux kernel doesn't make any commitments regarding API stability, right? It does for userspace APIs. Linus is notorious for chewing people out for breaking them (example: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75).

AsyncAwait 6y ago
Yes, I should have clarified I meant kernel-level APIs, not userspace.

lmm 6y ago

> You do realize even the Linux kernel doesn't make any commitments regarding API stability, right? You say "even" the Linux kernel; actually most projects don't and Linux is a rare exception, and I do think it's a bad idea for both technical and nontechnical reasons. (Compare with GCC's refusal to offer a stable API between frontend and backend, which I'd argue is a big reason why LLVM is overtaking it). > There's always BSD, if you want compatibility back to the Sun days in some cases, (Win32 is another option). I actually do run FreeBSD these days; one of the reasons this issue still bothers me is that compatibility with BSD is likely to be collateral damage from the systemd push (it's getting harder and harder to run Gnome on BSD, for example). It was particularly frustrating that systemd basically killed off Debian GNU/kFreeBSD just as it was becoming a first-class architecture; that could have been the best of all worlds.