6 ms·

So the impression that I'm getting is that some people just want Jessie to be released, even if some packages only run correctly under systemd; others wish for

by Shish2k 12y ago

So the impression that I'm getting is that some people just want Jessie to be released, even if some packages only run correctly under systemd; others wish for debian to enforce "every package must run correctly under every init system" (excluding things like init-system management tools, which are clearly tied to their system). I wonder, how much difference does it make either way? What packages which only support systemd are we actually talking about, and how much work would it be to untie them?

pantalaimon 12y ago
> What packages which only support systemd are we actually talking about Gnome, Wayland, KDE > how much work would it be to untie them? a lot
- KayEss 12y ago
  That sounds like a pain for my desktop, but implies there's still hope to use a simpler init on my servers so long as the coupling doesn't increase.
  - ultramancool 12y ago
    My advice: consider a move to FreeBSD on servers. I know it might seem drastic, but if you're looking for a simpler init system, they've probably got a closer philosophy to you anyways. That's what I've found at least, their rc system is dead simple, like Arch used to be before they started making changes to allow for systemd. I miss the day's of arch's rc.conf.
    - KayEss 12y ago
      I clearly need to learn a lot more about FreeBSD (and it's cousins) but unfortunately we're committed to Docker for server deployments.
  - efaref 12y ago
    Debian's sysvinit script wrappers were not in any way simple.
  - lucian1900 12y ago
    But servers is precisely where systemd is particularly useful. Having tools to interact with the init system and proper logging are invaluable.
    - edwintorok 12y ago
      Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. Sure there is some additional information that systemd stores in logs that syslog wouldn't, but implementing that could've been done while keeping the main log text-only (eg: have an id for each logline in your human-readable text logs, and have the binary/index etc separate that refer to that id).
      - pessimizer 12y ago
        >Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. No need to be quite so weaselly: 'Many disagree...' is something I'm pretty sure you could provide references for if pressed.
        felixgallo 12y ago
        Hi, I've run infrastructure and software projects involving thousands of machines for companies with over a trillion dollars in asset under management. Binary logs and putting coredumps in your journal are stupid and anyone who does that doesn't understand the first thing about running systems.
        EmanueleAina 12y ago
        I'm not a professional sysadmin (at least not at your level) seriously curious why a binary log is so bad. I guess in big deployment logs are collected to a central location, so I don't understand the "corruption" issue many people usually raise. Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.
- VLM 12y ago
  There is an architectural failure if your desktop environment depends deeply and inseperably (product tying) on how you spawn processes at boot. systemd may or may not suck and I'm not discussing that aspect in this post. What definitely horribly sucks is product tying a desktop environment (you know, cut and paste, drag and drop, background images, window animations) deeply in with the earliest intricacies of the boot process.
  - pantalaimon 12y ago
    systemd provides a lot more than spawning processes at boot. It aims to provide all essential operating system deamons and a common userspace interface for them.
    - vertex-four 12y ago
      Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Is it going to end up that if I want configurable logins (a la PAM), or to access a SMB file server, I need to use systemd as my init system, log management system, and whatever else?
      - pessimizer 12y ago
        >Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Farther than that, I bet. It's pretty safe to assume that all of those things are already written on a few informal systemd roadmaps.
        Shish2k 12y ago
        I really hope that that's a joke that didn't translate well into text, as taking it literally, I would suggest seeing a doctor about that paranoia :S
      - Xylakant 12y ago
        If at some point that is considered as "essential" as in "I can't boot a system without", then maybe. However, there's a way to avoid that path: Write a better init system than systemd. Or contribute the extra effort to make sshd, pam, samba, wayland, gnome, kde work without systemd. All that systemd does is offer a service. It seems to pay off for gnome and kde to rely on that.
- edwintorok 12y ago
  I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal. For example policykit was broken and things like mounting USB devices or managing VPN connections didn't work. That is finally fixed and with latest cgmanager from unstable, and policykit-1 from experimental those things work again. The only noticable loss compared to systemd is the lack of 'Suspend/Hibernate' in the KDE menu, but you can still use 'pm-suspend' from the cmdline, or even with 'qdbus' and the systemd specific dbus API, so in the end this should be fixable too. So I wouldn't put KDE into the same bucket as Gnome, its dependencies on systemd seem to be mostly indirect: * policykit, which started to depend on systemd-logind instead of consolekit. Works with cgmanager+systemd-shim as replacement * upowerd doesn't support suspend/hibernate anymore but apparently, so apparently systemd specific dbus methods have to be used now. Also Gnome3 works under OpenBSD (with consolekit?), and there is definitely no systemd there, although it might not be the latest version: http://callfortesting.org/gnome3/ http://callfortesting.org/gnome3/
  - smosher_ 12y ago
    > I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal. I'm having a similar experience with systemd. I had problems with USB storage (seems fixed now) and I'm still having problems with networking. DBus went haywire, not sure if it's in a sensible state yet or not. I haven't been using VPN connections or suspend. This isn't exactly a nightmare scenario. Most of the evident problems with systemd seem to be fixable. I can't say I'm impressed. I'm also having a hard time remembering why it was so important to move away from sysv init in the first place.
edwintorok 12y ago
IANADD, but actually I like this alternate proposal better: http://article.gmane.org/gmane.linux.debian.devel.vote/17248 http://article.gmane.org/gmane.linux.debian.devel.vote/17248 "Debian's standard requirement to support smooth upgrades from wheezy to jessie still applies, even when the system is booted with sysvinit." I think that is a sensible requirement as upgrading from sysvinit-core to systemd-sysv was quite problematic (wouldn't boot if you had some entires in ftab, etc.), and some may want to stay on sysv at least for an initial reboot.

by Shish2k 12y ago

pantalaimon 12y ago

> What packages which only support systemd are we actually talking about Gnome, Wayland, KDE > how much work would it be to untie them? a lot

KayEss 12y ago
That sounds like a pain for my desktop, but implies there's still hope to use a simpler init on my servers so long as the coupling doesn't increase.
- ultramancool 12y ago
  My advice: consider a move to FreeBSD on servers. I know it might seem drastic, but if you're looking for a simpler init system, they've probably got a closer philosophy to you anyways. That's what I've found at least, their rc system is dead simple, like Arch used to be before they started making changes to allow for systemd. I miss the day's of arch's rc.conf.
  - KayEss 12y ago
    I clearly need to learn a lot more about FreeBSD (and it's cousins) but unfortunately we're committed to Docker for server deployments.
- efaref 12y ago
  Debian's sysvinit script wrappers were not in any way simple.
- lucian1900 12y ago
  But servers is precisely where systemd is particularly useful. Having tools to interact with the init system and proper logging are invaluable.
  - edwintorok 12y ago
    Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. Sure there is some additional information that systemd stores in logs that syslog wouldn't, but implementing that could've been done while keeping the main log text-only (eg: have an id for each logline in your human-readable text logs, and have the binary/index etc separate that refer to that id).
    - pessimizer 12y ago
      >Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. No need to be quite so weaselly: 'Many disagree...' is something I'm pretty sure you could provide references for if pressed.
      - felixgallo 12y ago
        Hi, I've run infrastructure and software projects involving thousands of machines for companies with over a trillion dollars in asset under management. Binary logs and putting coredumps in your journal are stupid and anyone who does that doesn't understand the first thing about running systems.
        EmanueleAina 12y ago
        I'm not a professional sysadmin (at least not at your level) seriously curious why a binary log is so bad. I guess in big deployment logs are collected to a central location, so I don't understand the "corruption" issue many people usually raise. Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.
VLM 12y ago
There is an architectural failure if your desktop environment depends deeply and inseperably (product tying) on how you spawn processes at boot. systemd may or may not suck and I'm not discussing that aspect in this post. What definitely horribly sucks is product tying a desktop environment (you know, cut and paste, drag and drop, background images, window animations) deeply in with the earliest intricacies of the boot process.
- pantalaimon 12y ago
  systemd provides a lot more than spawning processes at boot. It aims to provide all essential operating system deamons and a common userspace interface for them.
  - vertex-four 12y ago
    Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Is it going to end up that if I want configurable logins (a la PAM), or to access a SMB file server, I need to use systemd as my init system, log management system, and whatever else?
    - pessimizer 12y ago
      >Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Farther than that, I bet. It's pretty safe to assume that all of those things are already written on a few informal systemd roadmaps.
      - Shish2k 12y ago
        I really hope that that's a joke that didn't translate well into text, as taking it literally, I would suggest seeing a doctor about that paranoia :S
    - Xylakant 12y ago
      If at some point that is considered as "essential" as in "I can't boot a system without", then maybe. However, there's a way to avoid that path: Write a better init system than systemd. Or contribute the extra effort to make sshd, pam, samba, wayland, gnome, kde work without systemd. All that systemd does is offer a service. It seems to pay off for gnome and kde to rely on that.
edwintorok 12y ago
I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal. For example policykit was broken and things like mounting USB devices or managing VPN connections didn't work. That is finally fixed and with latest cgmanager from unstable, and policykit-1 from experimental those things work again. The only noticable loss compared to systemd is the lack of 'Suspend/Hibernate' in the KDE menu, but you can still use 'pm-suspend' from the cmdline, or even with 'qdbus' and the systemd specific dbus API, so in the end this should be fixable too. So I wouldn't put KDE into the same bucket as Gnome, its dependencies on systemd seem to be mostly indirect: * policykit, which started to depend on systemd-logind instead of consolekit. Works with cgmanager+systemd-shim as replacement * upowerd doesn't support suspend/hibernate anymore but apparently, so apparently systemd specific dbus methods have to be used now. Also Gnome3 works under OpenBSD (with consolekit?), and there is definitely no systemd there, although it might not be the latest version: http://callfortesting.org/gnome3/ http://callfortesting.org/gnome3/
- smosher_ 12y ago
  > I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal. I'm having a similar experience with systemd. I had problems with USB storage (seems fixed now) and I'm still having problems with networking. DBus went haywire, not sure if it's in a sensible state yet or not. I haven't been using VPN connections or suspend. This isn't exactly a nightmare scenario. Most of the evident problems with systemd seem to be fixable. I can't say I'm impressed. I'm also having a hard time remembering why it was so important to move away from sysv init in the first place.

edwintorok 12y ago

IANADD, but actually I like this alternate proposal better: http://article.gmane.org/gmane.linux.debian.devel.vote/17248 http://article.gmane.org/gmane.linux.debian.devel.vote/17248 "Debian's standard requirement to support smooth upgrades from wheezy to jessie still applies, even when the system is booted with sysvinit." I think that is a sensible requirement as upgrading from sysvinit-core to systemd-sysv was quite problematic (wouldn't boot if you had some entires in ftab, etc.), and some may want to stay on sysv at least for an initial reboot.