6 ms·

Mind if I ask what, in particular, is making you move?

icebraining 10y ago
I'm not rxlim, but considering that the release after Wheezy - Jessie - introduced systemd as the default init systemd, it's not hard to guess.
- SteveNuts 10y ago
  I went into systemd with an open mind, hoping the changes would be worthwhile to learn. I've come out the other end looking for alternatives... In the meantime I'll stick to an OS that uses init, and hope systemd get's better given enough time.
  - icebraining 10y ago
    I know I pulled it in, but I was hoping to avoid another systemd discussion myself, just trying to answer vmateixeira :)
  - Z-Widwil 10y ago
    Having just set up a Debian server this weekend (Windows dev diving into Linux for the first time), can I ask what the main difference between init and systemd are? Mostly from a operational/security stand point.
    - barrkel 10y ago
      Init-scripts are a bunch of file system conventions and shell scripts; it's an imperative way of bringing a system into a particular state (networking, services etc.). Init itself is the very first process the the OS executes; all processes in -nix are created by forking. When using init-scripts, init is extremely simple. Systemd replaces init and uses a declarative approach for the system and its services, and the dependencies between the services (replacing init-scripts). Systemd is more complicated but can do more stuff, like initialize things concurrently. Functionality that used to be implemented in services themselves (e.g. restarting, recovery) is migrating into systemd, and systemd is acquiring more and more logic. Some people feel that this is contrary to the *nix philosophy and is not architecturally sound. Operationally, instead of using shell scripts and symlinks designed to be sorted in a particular order (normally maintained using other tools), you use descriptions of how the service should start and what it depends on. Security-wise, systemd is a bigger hairier ball, so it probably has bugs. But it also implements stuff once, whereas before implementations were distributed and of variable quality. So the variance in security level is probably lower with systemd, but depending on your mix of services, the mean may be higher or lower. And you don't get to control it.
      - jcrites 10y ago
        One of the most informative writings I've read on the topic of systemd and its benefits and comparison with other tools was written by Russ Allbery, which explains his contribution to Debian's choice to adopt it [1]: > I did a fairly extensive evaluation of both upstart and systemd by converting one of my packages[] to a native configuration with both systems. []I tried to approach each init system on its own terms and investigate what full, native support of that init system would look like, both from a Debian packaging perspective and from an upstream perspective. I also tried to work through the upgrade path from an existing init script with an external /etc/default configuration file and how that would be handled with both systemd and upstart. > I started this process with the expectation that systemd and upstart would be roughly evenly matched in capabilities. My expectation was that I would uncover some minor differences and variations, and some different philosophical approaches, but no deeply compelling differentiation. > To my surprise, that's not what happened. Rather, I concluded that systemd has a substantial technical advantage over upstart, primarily in terms of available useful features, but also in terms of fundamental design. The essay goes on to elaborate on the details. I personally found this and other writings a compelling argument in favor of the approach. Another useful article was "Why systemd?" [2]. There's also the blog post series "Systemd for Administrators" [3]. What systemd strives for makes a lot of sense to me. It allows you to describe the startup of services with declarative configuration in a simple and easy-to-understand format. Systemd is natively integrated with OS namespaces, cgroups, and the process hierarchy. Russ gives an example in his essay of how this allows systemd to track and display more information about daemons than the alternatives. It might be more complicated than the alternatives in one sense, but that buys you the power to do things like: activate services on-demand, when requested by a client; automatically launch services per user session, and clean them up on logout; concurrently start services for a fast boot; consign managed services to an OS namespace. By supporting these features in the init and process management system, it frees individual services from redundantly building this logic in their shell scripts and daemonization routines. That reduces complexity, and makes the entire system more feature-rich, more secure, and easier to manage. As far as security, systemd makes it substantially easier to employ kernel namespace, cgroups, capabilities, and other isolation facilities with simple configuration switches. Let's say that we'd like to run some daemon with a private /tmp directory for isolation. This is as simple as adding "PrivateTmp=yes" to its configuration. What if we want to change the run-as user, or even launch the service in an isolated user namespace? Perhaps we want the daemon to have a private network or private /dev? It's as simple as setting User=, PrivateUsers=, PrivateNetwork=, PrivateDevices=, etc. respectively: [Unit] Description=Demo service [Service] Type=forking ExecStart=/usr/sbin/my-daemon -d User=foo PrivateTmp=yes PrivateUsers=yes PrivateNetwork=yes Take a look at all the options you can apply in [4]. CPUAffinity=, CapabilityBoundingSet=, IOSchedulingPriority=, etc. It's great to be able to set all of these options in a single consistent place for all daemons. [1] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html [2] http://blog.jorgenschaefer.de/2014/07/why-systemd.html http://blog.jorgenschaefer.de/2014/07/why-systemd.html [3] https://gist.github.com/bcremer/8cdf6900c35dda65f387 https://gist.github.com/bcremer/8cdf6900c35dda65f387 [4] https://www.freedesktop.org/software/systemd/man/systemd.exec.html https://www.freedesktop.org/software/systemd/man/systemd.exe...
    - digler999 10y ago
      without realizing it you casually strolled into one of the biggest points of contention and controversy in computing history. Systemd came out a few years ago, and wars were fought over it. It fixes a lot of bugs that perennially came up with run scripts, but it's also a huge monolithic program that is in charge of nearly everything on your system. That's about all I'll say on it, because it's almost as divisive as the Israel/Palestine conflict.
      - zer0t3ch 10y ago
        > it's almost as divisive as the Israel/Palestine conflict But who doesn't love a good bit of conflict, amirite?
  - sedachv 10y ago
    I looked into this a little bit. Alternatives include OpenRC (complements but does not replace init), runit, upstart (looks like most distributions that used upstart are switching to systemd), and GNU Shepherd. I am looking at trying out GNU Shepherd as it is the init system of the Guix distribution, so you get both Nix-style package management and an init system that is not systemd, both written and configured in Guile Scheme. https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/
  - roi 10y ago
    Let me recommend Void Linux. Its init system is runit, which is djb daemontools based and super simple. I switched a couple of months ago from Arch, and was surprised at how easy it was, and how completely useless (at least for my use case) all the systemd steaming mess had proved in retrospect to be.
  - zer0t3ch 10y ago
    As someone who basically started getting into Linux with Systemd (I had dabbled before, but not in-depth) I love it. Mind expanding on what you don't like about it? One thing I do remember before Systemd though was the fact that every service was essentially a glorified bash script, and I hated that. With Systemd, there seems to generally be a much more clear-cut definition of how things operate, without all the cruft.
    - saghm 10y ago
      One of the big issues a lot of people have (or at least had, back when it was first becoming a thing) was that systemd uses binary log files rather than traditional text ones, which makes them harder to deal with (e.g. you can't `tail` or `grep` them, at least not directly). Another common gripe is that while it started out as an init system, a rather large portion of userland on a typical system depends on one or more systemd components directly or indirectly, making it somewhat difficult to avoid it if you'd prefer not to use it. My biggest issue with systemd is that when something goes wrong, it's pretty impossible to tell why. As an example, virtually every system I've used with systemd after a few months starts to have different services fail to stop on shutdown, causing a timeout of (by default) one-and-a-half minutes. From searches that I've done online, I don't seem to be the only person who runs into this, but I haven't found any good solution, leaving me with the options to reduce the timeout to something more manageable, force shutdown my laptop literally every time I'm done using it, or sit through 90 seconds of systemd trying and failing to stop whichever service is failing that time. Maybe I'm just lucky, but it's fairly rare that any of my non-systemd systems is unable to shut down properly once, let alone every single time consistently.
      - BuuQu9hu 10y ago
        tail: journalctl -f Personally, I found journalctl much better than text based logs. For the timeouts, I think try the systemd-bootchart thing.
      - totony 10y ago
        Apparently you can use "strings /run/journal/..." But journald lacks way more than simple text files. I tried to "mute" a process and redirect output to a file, because it was counting in the maximum journal size, and found it to be impossible "by design". Had to use an actually good log daemon, but it seems quite hard to just disable journald and not lose any log.
- mentat2737 10y ago
  Wheezy was my last one as well. I fully migrated my personal laptop to FreeBSD (as TrueOS) a few weeks ago, after using it as my second OS at home. And because I need Linux for work, I migrated to Devuan on my workstation, as I need to use Ansible and Docker in a stable way as part of my DevOps job.

I'm not rxlim, but considering that the release after Wheezy - Jessie - introduced systemd as the default init systemd, it's not hard to guess.

SteveNuts 10y ago
I went into systemd with an open mind, hoping the changes would be worthwhile to learn. I've come out the other end looking for alternatives... In the meantime I'll stick to an OS that uses init, and hope systemd get's better given enough time.
- icebraining 10y ago
  I know I pulled it in, but I was hoping to avoid another systemd discussion myself, just trying to answer vmateixeira :)
- Z-Widwil 10y ago
  Having just set up a Debian server this weekend (Windows dev diving into Linux for the first time), can I ask what the main difference between init and systemd are? Mostly from a operational/security stand point.
  - barrkel 10y ago
    Init-scripts are a bunch of file system conventions and shell scripts; it's an imperative way of bringing a system into a particular state (networking, services etc.). Init itself is the very first process the the OS executes; all processes in -nix are created by forking. When using init-scripts, init is extremely simple. Systemd replaces init and uses a declarative approach for the system and its services, and the dependencies between the services (replacing init-scripts). Systemd is more complicated but can do more stuff, like initialize things concurrently. Functionality that used to be implemented in services themselves (e.g. restarting, recovery) is migrating into systemd, and systemd is acquiring more and more logic. Some people feel that this is contrary to the *nix philosophy and is not architecturally sound. Operationally, instead of using shell scripts and symlinks designed to be sorted in a particular order (normally maintained using other tools), you use descriptions of how the service should start and what it depends on. Security-wise, systemd is a bigger hairier ball, so it probably has bugs. But it also implements stuff once, whereas before implementations were distributed and of variable quality. So the variance in security level is probably lower with systemd, but depending on your mix of services, the mean may be higher or lower. And you don't get to control it.
    - jcrites 10y ago
      One of the most informative writings I've read on the topic of systemd and its benefits and comparison with other tools was written by Russ Allbery, which explains his contribution to Debian's choice to adopt it [1]: > I did a fairly extensive evaluation of both upstart and systemd by converting one of my packages[] to a native configuration with both systems. []I tried to approach each init system on its own terms and investigate what full, native support of that init system would look like, both from a Debian packaging perspective and from an upstream perspective. I also tried to work through the upgrade path from an existing init script with an external /etc/default configuration file and how that would be handled with both systemd and upstart. > I started this process with the expectation that systemd and upstart would be roughly evenly matched in capabilities. My expectation was that I would uncover some minor differences and variations, and some different philosophical approaches, but no deeply compelling differentiation. > To my surprise, that's not what happened. Rather, I concluded that systemd has a substantial technical advantage over upstart, primarily in terms of available useful features, but also in terms of fundamental design. The essay goes on to elaborate on the details. I personally found this and other writings a compelling argument in favor of the approach. Another useful article was "Why systemd?" [2]. There's also the blog post series "Systemd for Administrators" [3]. What systemd strives for makes a lot of sense to me. It allows you to describe the startup of services with declarative configuration in a simple and easy-to-understand format. Systemd is natively integrated with OS namespaces, cgroups, and the process hierarchy. Russ gives an example in his essay of how this allows systemd to track and display more information about daemons than the alternatives. It might be more complicated than the alternatives in one sense, but that buys you the power to do things like: activate services on-demand, when requested by a client; automatically launch services per user session, and clean them up on logout; concurrently start services for a fast boot; consign managed services to an OS namespace. By supporting these features in the init and process management system, it frees individual services from redundantly building this logic in their shell scripts and daemonization routines. That reduces complexity, and makes the entire system more feature-rich, more secure, and easier to manage. As far as security, systemd makes it substantially easier to employ kernel namespace, cgroups, capabilities, and other isolation facilities with simple configuration switches. Let's say that we'd like to run some daemon with a private /tmp directory for isolation. This is as simple as adding "PrivateTmp=yes" to its configuration. What if we want to change the run-as user, or even launch the service in an isolated user namespace? Perhaps we want the daemon to have a private network or private /dev? It's as simple as setting User=, PrivateUsers=, PrivateNetwork=, PrivateDevices=, etc. respectively: [Unit] Description=Demo service [Service] Type=forking ExecStart=/usr/sbin/my-daemon -d User=foo PrivateTmp=yes PrivateUsers=yes PrivateNetwork=yes Take a look at all the options you can apply in [4]. CPUAffinity=, CapabilityBoundingSet=, IOSchedulingPriority=, etc. It's great to be able to set all of these options in a single consistent place for all daemons. [1] https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html [2] http://blog.jorgenschaefer.de/2014/07/why-systemd.html http://blog.jorgenschaefer.de/2014/07/why-systemd.html [3] https://gist.github.com/bcremer/8cdf6900c35dda65f387 https://gist.github.com/bcremer/8cdf6900c35dda65f387 [4] https://www.freedesktop.org/software/systemd/man/systemd.exec.html https://www.freedesktop.org/software/systemd/man/systemd.exe...
  - digler999 10y ago
    without realizing it you casually strolled into one of the biggest points of contention and controversy in computing history. Systemd came out a few years ago, and wars were fought over it. It fixes a lot of bugs that perennially came up with run scripts, but it's also a huge monolithic program that is in charge of nearly everything on your system. That's about all I'll say on it, because it's almost as divisive as the Israel/Palestine conflict.
    - zer0t3ch 10y ago
      > it's almost as divisive as the Israel/Palestine conflict But who doesn't love a good bit of conflict, amirite?
- sedachv 10y ago
  I looked into this a little bit. Alternatives include OpenRC (complements but does not replace init), runit, upstart (looks like most distributions that used upstart are switching to systemd), and GNU Shepherd. I am looking at trying out GNU Shepherd as it is the init system of the Guix distribution, so you get both Nix-style package management and an init system that is not systemd, both written and configured in Guile Scheme. https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/
- roi 10y ago
  Let me recommend Void Linux. Its init system is runit, which is djb daemontools based and super simple. I switched a couple of months ago from Arch, and was surprised at how easy it was, and how completely useless (at least for my use case) all the systemd steaming mess had proved in retrospect to be.
- zer0t3ch 10y ago
  As someone who basically started getting into Linux with Systemd (I had dabbled before, but not in-depth) I love it. Mind expanding on what you don't like about it? One thing I do remember before Systemd though was the fact that every service was essentially a glorified bash script, and I hated that. With Systemd, there seems to generally be a much more clear-cut definition of how things operate, without all the cruft.
  - saghm 10y ago
    One of the big issues a lot of people have (or at least had, back when it was first becoming a thing) was that systemd uses binary log files rather than traditional text ones, which makes them harder to deal with (e.g. you can't `tail` or `grep` them, at least not directly). Another common gripe is that while it started out as an init system, a rather large portion of userland on a typical system depends on one or more systemd components directly or indirectly, making it somewhat difficult to avoid it if you'd prefer not to use it. My biggest issue with systemd is that when something goes wrong, it's pretty impossible to tell why. As an example, virtually every system I've used with systemd after a few months starts to have different services fail to stop on shutdown, causing a timeout of (by default) one-and-a-half minutes. From searches that I've done online, I don't seem to be the only person who runs into this, but I haven't found any good solution, leaving me with the options to reduce the timeout to something more manageable, force shutdown my laptop literally every time I'm done using it, or sit through 90 seconds of systemd trying and failing to stop whichever service is failing that time. Maybe I'm just lucky, but it's fairly rare that any of my non-systemd systems is unable to shut down properly once, let alone every single time consistently.
    - BuuQu9hu 10y ago
      tail: journalctl -f Personally, I found journalctl much better than text based logs. For the timeouts, I think try the systemd-bootchart thing.
    - totony 10y ago
      Apparently you can use "strings /run/journal/..." But journald lacks way more than simple text files. I tried to "mute" a process and redirect output to a file, because it was counting in the maximum journal size, and found it to be impossible "by design". Had to use an actually good log daemon, but it seems quite hard to just disable journald and not lose any log.
mentat2737 10y ago
Wheezy was my last one as well. I fully migrated my personal laptop to FreeBSD (as TrueOS) a few weeks ago, after using it as my second OS at home. And because I need Linux for work, I migrated to Devuan on my workstation, as I need to use Ansible and Docker in a stable way as part of my DevOps job.