3 ms·

You're blaming the wrong party here. The systemd project has no control over what Gnome relies on. They independently rely on systemd because it provides funct

You're blaming the wrong party here. The systemd project has no control over what Gnome relies on. They independently rely on systemd because it provides functionality that makes their lives easier, and it's their right to do that. If you want "up-to-date Gnome" to work on FreeBSD, go and write some code to help make it happen.

lmm 12y ago
What are my real options? I could write patches that reimplement the functionality that Gnome gets from systemd using lower-level functionality, in a cross-platform way. But those patches would be rejected; the Gnome project has decided to use systemd and would not want to duplicate its code. If I were to maintain my own gnome fork I would have to convince distributions to adopt it. I could write patches that add FreeBSD support to systemd. But those patches would be rejected - again, as a policy decision, systemd doesn't want to support FreeBSD. Thankfully in this case there is a fork, uselessd, but again, we need to convince distributions to adopt it or it's meaningless. The claim that Gnome "independently" relies on systemd is specious; there was a lot of lobbying and politics from the systemd side. My only practical option is to counter at the same level, and lobby Gnome (and linux distributions) to make the political decision to move away from systemd.
- nknighthb 12y ago
  It's even more specious than you think. Red Hat employees are the largest "contributors" to GNOME. It's effectively a Red Hat project. So, Red Hat project GNOME relies on Red Hat project systemd, and Red Hat employees won't allow systemd to be portable to competing platforms. Convenient.
- chousuke 12y ago
  The real option actually is to bring up FreeBSD to the level that it can provide the same functionality (specifically, dbus interfaces) as systemd and Linux. Gnome depends on systemd features because they're useful and solve real problems. As it is, FreeBSD can't provide those features. You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternative to offer, it's just talk. As far as I know, Gnome does currently have fallbacks (with reduced functionality) on non-systemd systems, so it's not the case that they just ignore things. However, I perfectly understand why they would not bother with duplicating code just to support systems that aren't good enough. EDIT: I'm apparently not able to respond to the reply below me for whatever reason, but... It's been said many times that making systemd portable makes no sense, which is why it provides interfaces. And regarding the interfaces, which part of them, exactly, are not stable? There's a very reasonable interface stability promise, which to my knowledge has held, so far.
  - lmm 12y ago
    FreeBSD can and does provide these interfaces. We've had e.g. cgroups-equivalents for years. The reason systemd doesn't run on FreeBSD is pure politics, not technical - after all, if it were technically impossible to implement systemd on FreeBSD, there would be no need for a policy of refusing patches. > You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternative to offer, it's just talk. The problem isn't that the interfaces are particularly bad, it's that they're not standardized. If systemd would offer standardized interfaces that let me offer a compatible alternative that would be fine. But they don't. Trying to remain compatible with software that will make no effort to provide compatibility from its side is a mug's game.
    - cwyers 12y ago
      http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html "That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, ..." It's not just cgroups.
      - lmm 12y ago
        I guess uselessd is fundamentally impossible then, along with other systems that provide the same functionality. Again, if it were impossible there wouldn't need to be a policy against it.
        cwyers 12y ago
uselessdguy 12y ago
Except that Lennart Poettering (at the least) was directly involved in negotiating the dependency on systemd's libraries for the GNOME stack: https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html https://mail.gnome.org/archives/desktop-devel-list/2011-May/... Considering GNOME is part of the new school design philosophy in general and largely developed by Red Hat employees, it's inevitable that it would have happened anyway, but the systemd developers were directly complicit in speeding it up.
- chousuke 12y ago
  That's a proposal. And it's not like Lennart was being somehow subversive. He explicitly states the following: > systemd is Linux-only. That means if we still care for those non-Linux > platforms replacements have to be written. In case of the timezone/time/locale/hostname mechanisms this should be relatively easy > as we kept the D-Bus interface very much independent from systemd, and > they are easy to reimplement. Also, just leaving out support for this on those archs should be workable too. The hostname interface is documented > in a lot of detail here: http://www.freedesktop.org/wiki/Software/systemd/hostnamed http://www.freedesktop.org/wiki/Software/systemd/hostnamed -- we plan to > offer similar documentation for the other mechanisms. I'm really not seeing any foul play anywhere; RH tried Upstart (they even used it in RHEL6), found it lacking, and out of that came systemd. The thing is, the systemd project is far more ambitious (which is good) and not content with just providing an init system. I personally don't see anything wrong with that (a well-integrated core userland for all Linux distros? Yes please), but you obviously do. I think your project is ultimately not going to gain much traction it's simply ignoring most of the goals of the systemd project. It might have side-effects on how systemd develops though, but I can't really say. It seems to me that Lennart's personal goal is to make the perfect OS as he visualizes it. He's doing work to make it happen, and he's gaining support because the code is useful to other people. If people outside of Linux circles want to get involved in standardizing core DBUS interfaces (which they should, because pretty much everyone seems to use DBUS) and things like daemon startup notification, they should get involved with the systemd project and discuss the interfaces, not just tell people not to use them... That ship has already sailed. Systemd is rapidly becoming the de facto standard, and that progress is not suddenly going to stop because minorities complain too loudly. :)

lmm 12y ago

What are my real options? I could write patches that reimplement the functionality that Gnome gets from systemd using lower-level functionality, in a cross-platform way. But those patches would be rejected; the Gnome project has decided to use systemd and would not want to duplicate its code. If I were to maintain my own gnome fork I would have to convince distributions to adopt it. I could write patches that add FreeBSD support to systemd. But those patches would be rejected - again, as a policy decision, systemd doesn't want to support FreeBSD. Thankfully in this case there is a fork, uselessd, but again, we need to convince distributions to adopt it or it's meaningless. The claim that Gnome "independently" relies on systemd is specious; there was a lot of lobbying and politics from the systemd side. My only practical option is to counter at the same level, and lobby Gnome (and linux distributions) to make the political decision to move away from systemd.

nknighthb 12y ago
It's even more specious than you think. Red Hat employees are the largest "contributors" to GNOME. It's effectively a Red Hat project. So, Red Hat project GNOME relies on Red Hat project systemd, and Red Hat employees won't allow systemd to be portable to competing platforms. Convenient.
chousuke 12y ago
The real option actually is to bring up FreeBSD to the level that it can provide the same functionality (specifically, dbus interfaces) as systemd and Linux. Gnome depends on systemd features because they're useful and solve real problems. As it is, FreeBSD can't provide those features. You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternative to offer, it's just talk. As far as I know, Gnome does currently have fallbacks (with reduced functionality) on non-systemd systems, so it's not the case that they just ignore things. However, I perfectly understand why they would not bother with duplicating code just to support systems that aren't good enough. EDIT: I'm apparently not able to respond to the reply below me for whatever reason, but... It's been said many times that making systemd portable makes no sense, which is why it provides interfaces. And regarding the interfaces, which part of them, exactly, are not stable? There's a very reasonable interface stability promise, which to my knowledge has held, so far.
- lmm 12y ago
  FreeBSD can and does provide these interfaces. We've had e.g. cgroups-equivalents for years. The reason systemd doesn't run on FreeBSD is pure politics, not technical - after all, if it were technically impossible to implement systemd on FreeBSD, there would be no need for a policy of refusing patches. > You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternative to offer, it's just talk. The problem isn't that the interfaces are particularly bad, it's that they're not standardized. If systemd would offer standardized interfaces that let me offer a compatible alternative that would be fine. But they don't. Trying to remain compatible with software that will make no effort to provide compatibility from its side is a mug's game.
  - cwyers 12y ago
    http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html "That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, ..." It's not just cgroups.
    - lmm 12y ago
      I guess uselessd is fundamentally impossible then, along with other systems that provide the same functionality. Again, if it were impossible there wouldn't need to be a policy against it.
      - cwyers 12y ago

uselessdguy 12y ago

Except that Lennart Poettering (at the least) was directly involved in negotiating the dependency on systemd's libraries for the GNOME stack: https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html https://mail.gnome.org/archives/desktop-devel-list/2011-May/... Considering GNOME is part of the new school design philosophy in general and largely developed by Red Hat employees, it's inevitable that it would have happened anyway, but the systemd developers were directly complicit in speeding it up.

chousuke 12y ago
That's a proposal. And it's not like Lennart was being somehow subversive. He explicitly states the following: > systemd is Linux-only. That means if we still care for those non-Linux > platforms replacements have to be written. In case of the timezone/time/locale/hostname mechanisms this should be relatively easy > as we kept the D-Bus interface very much independent from systemd, and > they are easy to reimplement. Also, just leaving out support for this on those archs should be workable too. The hostname interface is documented > in a lot of detail here: http://www.freedesktop.org/wiki/Software/systemd/hostnamed http://www.freedesktop.org/wiki/Software/systemd/hostnamed -- we plan to > offer similar documentation for the other mechanisms. I'm really not seeing any foul play anywhere; RH tried Upstart (they even used it in RHEL6), found it lacking, and out of that came systemd. The thing is, the systemd project is far more ambitious (which is good) and not content with just providing an init system. I personally don't see anything wrong with that (a well-integrated core userland for all Linux distros? Yes please), but you obviously do. I think your project is ultimately not going to gain much traction it's simply ignoring most of the goals of the systemd project. It might have side-effects on how systemd develops though, but I can't really say. It seems to me that Lennart's personal goal is to make the perfect OS as he visualizes it. He's doing work to make it happen, and he's gaining support because the code is useful to other people. If people outside of Linux circles want to get involved in standardizing core DBUS interfaces (which they should, because pretty much everyone seems to use DBUS) and things like daemon startup notification, they should get involved with the systemd project and discuss the interfaces, not just tell people not to use them... That ship has already sailed. Systemd is rapidly becoming the de facto standard, and that progress is not suddenly going to stop because minorities complain too loudly. :)