Announcement

Collapse
No announcement yet.

Arch Linux Is Switching To Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Rallos Zek
    replied
    Reason number 105 - 106 why SystemD is rubbish

    If your kernel doesn't have /proc/sys enabled it tries to read the boot_id and instead of deciding it isn't available it aborts the systemd journal and spews crap all over the screen, and leaves nothing logged.


    systemd is very hard to debug. It's also got some really dumb flaws - eg if the journal dies all your services get SIGPIPE and die horribly too. syslog gets elementary stuff like that right.


    As shown in the above thread the philosophy behind SystemD is so short-sighted and retarded it makes me think Lennart Poettering is just a troll working to undermine the UNIX ecosystem.

    But like I said before what did you expect from the same person who wrote PulseAudio? Another broken, this time hard to debug, binary mess.

    Only fools use binary tools for system administration!

    Leave a comment:


  • Xake
    replied
    Originally posted by energyman View Post
    No, but does that mean that just because LP is putting out lots of code any of it is any good at all?
    Then why are devs and distributions picking it up and using it if it is so horrible?

    Leave a comment:


  • Kano
    replied
    As i do not use arch or fedora i wanted to try systemd on debian wheezy. Well there systemd is really outdated and full of bugs. It did not work on my box with ssd, there i never got any input device as long as systemd was installed (even when i booted via sysvinit). On my system with hd it worked but well, you dont break any record booting from hd. On a different system it booted, but not always, well most likely you have to use a very recent systemd not an old one. I would like to see a current systemd in debian experimental to do better tests. Basically i highly doubt that you can gain so much by using it. When a default install with lots of services running can be booted within 5-8s and you gain maybe 2-3s it is not really critical. When i dont use grub but use linux in efi stub mode i save at least 5s at startup, much more than systemd will give you but of course i would like to try it - but without changeing the distro. They could provide a debian repo with snapshots as well.

    Leave a comment:


  • PeterKraus
    replied
    This thread is just too funny.

    As long as the transition is painless, I couldn't care less what init system is the PC using.

    Besides, Michael, you could have at least checked what init is Arch using now, not just assume it's sysVinit....

    Leave a comment:


  • Zorael
    replied
    I've been running it on Kubuntu for a while now, and it works very well. It was a royal pain to get set up though; lots of core stuff have upstart as a hard dependency. Moreover many installation scripts call upstart's initctl directly, so I had to write a wrapper to fix package installation. So currently upstart stays installed alongside it currently. Preferably init implementation packages should provide an 'init' virtual package, but I don't see Canonical having any interest in anything other than upstart, so I'm not holding my breath.

    As a small note, the systemd in Debian's repositories (44?) is ancient.

    Originally posted by TobiSGD View Post
    The real problem with systemd is not that it is another init system. If it would be and it worked fine there would be no reason not to use it, except if it just doesn't fit your needs.
    The real problem is that the developers want systemd to be more than an init system. They also want it to be a replacement for udev (udev is now integrated into systemd, will work outside of systemd, but will not get any changes for this "outside of systemd"-function), a system logger, a session manager and whatever the developers come up in the future.
    This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.
    In a sense yes, and in a sense no.

    Remember that /bin/systemd is not all of systemd! The project strives to supply reference implementations of common functionality, but the accusations of monolithically trying to do everything is sort-of true yet largely unwarranted. Inarguably, beyond the pid 1 init system you have those services that set the hostname, the almost-syslog journal, readahead, random seed saver/loader, dumbed-down bootchart, login session manager (think ConsoleKit's ck-list-sessions), etc etc. But not only are they all compile-time options; they're also easily disabled in runtime.

    Regarding udev, the "system and service manager" that is /bin/systemd wants to monitor software and hardware events (as reported by udev), so as to be able to act thereupon. As far as I understand, the codebase became so tightly shared with udev that marrying them into one was deemed the best course of action. Given sane packaging udev shouldn't necessarily depend on systemd, though the other way around will very very likely apply.

    Code:
    [email protected] /main/src/systemd$ ./configure --help
    [...]
      --disable-ima           Disable optional IMA support
      --disable-selinux       Disable optional SELINUX support
      --disable-xz            Disable optional XZ support
      --disable-tcpwrap       Disable optional TCP wrappers support
      --disable-pam           Disable optional PAM support
      --disable-acl           Disable optional ACL support
      --disable-audit         Disable optional AUDIT support
      --disable-libcryptsetup disable libcryptsetup tools
      --disable-binfmt        disable binfmt tool
      --disable-vconsole      disable vconsole tool
      --disable-readahead     disable readahead tools
      --disable-quotacheck    disable quotacheck tools
      --disable-randomseed    disable randomseed tools
      --disable-logind        disable login daemon
      --disable-hostnamed     disable hostname daemon
      --disable-timedated     disable timedate daemon
      --disable-localed       disable locale daemon
      --disable-coredump      disable coredump hook
      --disable-gudev         disable Gobject libudev support [default=enabled]
      --disable-keymap        disable keymap fixup support [default=enabled]
    [...]
    Code:
    $ systemctl list-units --all --full | grep '^systemd'
    systemd-ask-password-console.path              loaded active   waiting       Dispatch Password Requests to Console Directory Watch
    systemd-ask-password-wall.path                 loaded active   waiting       Forward Password Requests to Wall Directory Watch
    systemd-ask-password-console.service           loaded inactive dead          Dispatch Password Requests to Console
    systemd-ask-password-wall.service              loaded inactive dead          Forward Password Requests to Wall
    systemd-binfmt.service                         loaded inactive dead          Set Up Additional Binary Formats
    systemd-fsck-root.service                      loaded inactive dead          File System Check on Root Device
    [email protected]                  loaded inactive dead          File System Check on /dev/sda2
    [email protected]                  loaded inactive dead          File System Check on /dev/sda4
    systemd-initctl.service                        loaded inactive dead          /dev/initctl Compatibility Daemon
    systemd-journal-flush.service                  loaded inactive dead          Trigger Flushing of Journal to Persistent Storage
    systemd-journald.service                       loaded active   running       Journal Service
    systemd-logind.service                         loaded active   running       Login Service
    systemd-modules-load.service                   loaded active   exited        Load Kernel Modules
    systemd-random-seed-load.service               loaded inactive dead          Load Random Seed
    systemd-random-seed-save.service               loaded inactive dead          Save Random Seed
    systemd-readahead-collect.service              loaded active   exited        Collect Read-Ahead Data
    systemd-readahead-done.service                 loaded inactive dead          Stop Read-Ahead Data Collection
    systemd-readahead-replay.service               loaded active   exited        Replay Read-Ahead Data
    systemd-remount-fs.service                     loaded active   exited        Remount Root and Kernel File Systems
    systemd-shutdownd.service                      loaded inactive dead          Delayed Shutdown Service
    systemd-sysctl.service                         loaded active   exited        Apply Kernel Variables
    systemd-tmpfiles-clean.service                 loaded inactive dead          Cleanup of Temporary Directories
    systemd-tmpfiles-setup.service                 loaded active   exited        Recreate Volatile Files and Directories
    systemd-udev-settle.service                    loaded active   exited        udev Wait for Complete Device Initialization
    systemd-udev-trigger.service                   loaded active   exited        udev Coldplug all Devices
    systemd-udevd.service                          loaded inactive dead          udev Kernel Device Manager
    systemd-update-utmp-shutdown.service           masked inactive dead          systemd-update-utmp-shutdown.service
    systemd-user-sessions.service                  loaded active   exited        Permit User Sessions
    systemd-initctl.socket                         loaded active   listening     /dev/initctl Compatibility Named Pipe
    systemd-journald.socket                        loaded active   running       Journal Socket
    systemd-shutdownd.socket                       loaded active   listening     Delayed Shutdown Socket
    systemd-udevd-control.socket                   loaded active   listening     udev Control Socket
    systemd-udevd-kernel.socket                    loaded failed   failed        udev Kernel Socket
    systemd-readahead-done.timer                   loaded active   elapsed       Stop Read-Ahead Data Collection 10s After Completed Startup
    systemd-tmpfiles-clean.timer                   loaded active   waiting       Daily Cleanup of Temporary Directories
    I simply chose to not build some of the tools; vconsole, quotacheck, hostnamed, timedated, localed, coredump; since I don't need them. If I was installing from a package and they had all been prebuilt for me;
    Code:
    $ sudo systemctl disable systemd-readahead-{collect,drop,replay}.service
    rm '/etc/systemd/system/system-update.target.wants/systemd-readahead-drop.service'
    rm '/etc/systemd/system/default.target.wants/systemd-readahead-replay.service'
    rm '/etc/systemd/system/default.target.wants/systemd-readahead-collect.service'
    So in summary, the systemd project tries to modularly provide everything you need to get a fully functional userspace set up. The systemd binary doesn't bloat itself with those bits; it merely sets itself up as a service monitor that in turn starts them. And you can opt out of (almost) all of it and use dedicated daemons instead.

    As for software design, Poettering seems to be of the opinion that UNIX philosophy shouldn't be in the way of smart ideas. The same for portability, apparently; "dumbing it down" to adhere to the lowest common denominator, such as by not using control groups, has its drawbacks.

    Leave a comment:


  • TobiSGD
    replied
    Originally posted by 89c51 View Post
    Apart of the "Unix philosophy" bullshit is there any technical reason not to do it?
    May be the reason that it is in no way a good idea to replace several mature programs with a hyped one, so that a single point of failure can bring your whole system down? Have problems with systemd? Well, look at the logs! Oh, wait, the logger is a part of systemd, .. . There is an endless way of putting such combinations together.
    By the way, think about how much GNU/Linux you would have today without the "Unix philosophy bullshit".

    I see people saying here "It will be standard soon!". May I ask what gives you the impression? The distributions that have the most users and the most derivatives (Ubuntu and Debian) are not using it. I would like to see a statistic how many distributions (with an estimation of their user bases) in reality do use systemd and how many use different init systems before talking about standards. Who declares such standards (Red Hat, the ones with the largest revenue or Canonical, the ones with the largest userbase, or Debian, the one were most distros are built upon, or Slackware the oldest alive distribution, or ...)?

    Leave a comment:


  • tstrunk
    replied
    Originally posted by TobiSGD View Post
    This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.
    I disagree that introducing systemd is against the KISS philosophy:
    Many packages nowadays are tailored towards it (udev was mentioned in this thread). Starting daemons without systemd will be the non-standard way in years to come. Archlinux has always been about keeping packages mostly vanilla, i.e. minimum amount of patches, pushing really needed fixes upstream.
    Therefore they have a good reason to go to systemd: it will be standard soon and require the least amount of work, also on the dev side.

    Leave a comment:


  • 89c51
    replied
    Originally posted by TobiSGD View Post
    The real problem with systemd is not that it is another init system. If it would be and it worked fine there would be no reason not to use it, except if it just doesn't fit your needs.
    The real problem is that the developers want systemd to be more than an init system. They also want it to be a replacement for udev (udev is now integrated into systemd, will work outside of systemd, but will not get any changes for this "outside of systemd"-function), a system logger, a session manager and whatever the developers come up in the future.

    This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.

    IMHO, with the change to systemd Arch developers have lost any reason to keep this line on their Wiki:

    I am glad the the developers of my preferred distro are not willing to make the change to systemd, because they really follow the KISS principle and the Unix philosophy.
    Thanks, Mr. Volkerding.

    Apart of the "Unix philosophy" bullshit is there any technical reason not to do it?

    Leave a comment:


  • TobiSGD
    replied
    The real problem with systemd is not that it is another init system. If it would be and it worked fine there would be no reason not to use it, except if it just doesn't fit your needs.
    The real problem is that the developers want systemd to be more than an init system. They also want it to be a replacement for udev (udev is now integrated into systemd, will work outside of systemd, but will not get any changes for this "outside of systemd"-function), a system logger, a session manager and whatever the developers come up in the future.

    This stands in direct opposition to the Unix philosophy (one tool for one purpose) and even more in direct opposition to the KISS philosophy.

    IMHO, with the change to systemd Arch developers have lost any reason to keep this line on their Wiki:
    The following five core principles comprise what is commonly referred to as the Arch Way, or the Arch Philosophy, perhaps best summarized by the acronym KISS for Keep It Simple, Stupid.
    I am glad the the developers of my preferred distro are not willing to make the change to systemd, because they really follow the KISS principle and the Unix philosophy.
    Thanks, Mr. Volkerding.

    Leave a comment:


  • WorBlux
    replied
    Originally posted by johnc View Post
    So what makes systemd so awesome?
    I starts up services massively in parallel. Socket based activation allows you to start a service before it's dependencies are fully initialized. Things will stall only if you fill up the socket pipeline or a response is required.

    Services are controlled by putting them in c-groups, they can't escape control of the init system.

    You can boot to a X without starting any shells.

    Use of autoFS, allows you to continue even though some disks may not be initialized, you only stall if some piece of critical data is missing.

    Read-ahead can optimize disk access to further decrease boot times.

    Integration into other methods of starting services. A service can be started at boot because it is a dependency of another, in response to a hardware event, or as a cron job.

    Potential to be not just an init manager, but a session manager as well.

    Searchable logs

    And in general a more integrated, yet still modular core system, that is smaller and easier to manage than if they were completely separate as they are now.

    The potential to standardize certain config files and init files across distros.

    Minimal distruption to current practices (system V compatibility, as well as most modules supporting prior interface methods)

    Leave a comment:

Working...
X