AntiX – Systemd Free

Forum Forums New users New Users and General Questions AntiX – Systemd Free

  • This topic has 5 replies, 3 voices, and was last updated Nov 4-7:34 pm by olsztyn.
Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #13010
    Member
    olsztyn

      Not a problem, just a question:
      My strong feeling tells me I should appreciate Systemd-free concept. In my limited so far understanding this approach retains true to Unix simplicity of text control files, rather than complexity of systemd program, although I may be wrong or oversimplifying…
      Now, to better understand:
      – Does this not entail better reliability?
      – Do we lose some functionality or compatibility of some applications?

      Thanks for shedding some light on this and Regards…

      Live antiX Boot Options (Previously posted by Xecure):
      https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

      #13036
      Member
      fatmac
        Helpful
        Up
        0
        ::

        Using systemd creates a single point of failure, as with Windows Registry, not a good idea to my mind.

        There were some recent reports of more bugs being found in the systemd code too.

        Linux (& BSD) since 1999

        #13073
        Anonymous
          Helpful
          Up
          0
          ::

          Ask a simple question (or 2), receive a not-so-simple response…

          ( copypasting a portion of the page from http://without-systemd.org/wiki/index.php/Arguments_against_systemd )

          systemd suffers from scope creep. It overreaches, way beyond providing an init system
          ^————————v
          systemd provides an UEFI boot loader, systemd-boot (previously gummiboot)
          systemd provides a login manager, systemd-logind
          systemd provides a syslog daemon, systemd-journald
          systemd provides a mount front-end, systemd-mount
          The udev sources were merged into the systemd source tree.
          systemd provides systemd.timer timer units, intended to replace cron and at
          systemd provides a D-Bus client library, sd-bus
          systemd developed an in-kernel D-Bus implementation (kdbus). They tried to get it merged into the kernel, failed, and are now trying again with BUS1.
          systemd provides automount via systemd.automount to substitute autofs
          systemd provides a caching DNS resolver, systemd-resolved
          systemd provides a network manager and DHCP client, systemd-networkd
          systemd provides a HTTP server for journal events, systemd-journal-gatewayd (can be disabled with remote compile option)
          systemd functionality now even includes IP Forwarding, IP Masquerading & Basic Firewall Controls
          systemd init requires (even on a server) a library for rendering QR codes

          .

          ———————— Issues
          fsck cannot be cancelled (used to be possible via C-c or c on the console). 7f110ff9b8, Fedora#719952
          systemd defaults to Google’s DNS nameservers. e16cb2e4ef, Debian#761658
          systemd defaults to Google’s NTP servers, which serve leap-smeared time. GitHub#437
          systemd by default uses Predictable Network Interface Names, which are actually less predictable when you only have one interface per type.
          systemd by default kills background processes after the user logs out. 97e5530cf2, Debian#825394
          “In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.” -Poettering[6]
          As systemd depends on many files on a rootfs, in case of any problems with rootfs, it is not able to control processes and (cleanly) shutdown/reboot when Crtl-Alt-Del is pressed.[7]
          systemd-resolved breaks the traditional glibc behavior by skipping a DNS server in all following queries, if it does not respond once. GitHub#5755, [8]

          ———————— Conceptional problems
          Do not parse “debug” command line parameter – Response on LKML Response: That is the expected current behaviour, “debug” can cause “too many” messages to be useful anymore if things are broken.
          journal ip anonymization — It’s very difficult to use systemd/journal on a privacy-aware system or infrastructure.

          ———————— Poor design
          Among the systemd files is a filename that starts with a hyphen! – This causes all sorts problems as it will usually be interpreted as the start of a command option when used on the command line. You don’t even need to specify the filename for it to cause problems as it will affect commands that use globbing. Not to mention that the file in question, “-.slice”, they refer to as the “root slice” which causes confusion as the term “slice” has been used for decades as an alternative way of referring to a disk partition yet their usage is completely unrelated.
          systemd mounted efivarfs read-write, allowing motherboard bricking via ‘rm’ See also No POST after rm -rf / – Lennart’s argument for mounting /sys/firmware/efi/efivars as read/write as a default behaviour doesn’t hold water. Yes it’s true that some tools may need to write to it but those tools are not needed for the general running of a system. efivars should not even be mounted as read-only by default. Those tools that need to write to efivars will generally only be invoked by a system administrator. A competent sysadmin will know how to mount efivars with read/write permissions when they need to to use those tools. The only reason to mount efivars by default is for convenience. This is by no means a good reason. From a security perspective, mounting efivars by default should be strongly discouraged as it breaks the principle of least privilege. Lennart goes on to state that systemd needs to write EFI variables. This demonstrates yet another example of scope creep and thus poor design.
          https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=28640752854
          https://bugzilla.redhat.com/show_bug.cgi?id=1170765
          https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720

          ———————— Scope creep leads to (has led to these, documented) vulnerabilities
          systemd-resolved DNS cache poisoning
          To run systemd properly in container a FUSE LXCFS had to be created, and surely its own share of vulnerabilities:
          LXCFS before 0.12 does not properly enforce directory escapes CVSS 4.6
          The do_write_pids function in lxcfs.c in LXCFS before 0.12 does not properly check permissions CVSS 7.2
          systemd vulnerability allows attackers to hack Linux machines via malicious DNS response
          Remote code execution via DHCPv6

          ———————— Absurd bugs and responses
          freedesktop#74589 Unchecked null pointer dereferencing in PID 1 not considered a serious issue.
          openSUSE#918226 systemd segfaults after updating from 208-23.3 to 208-28.1
          GitHub#2402 Mount efivarfs read-only – Doing rm -rf / bricks your computer
          Debian#776171 Unable to shutdown
          freedesktop#61191 systemd-journald eats 100% CPU
          freedesktop#64116 Corrupted binary logs
          GitHub#5644 tmpfiles: R! /dir/.* destroys root, also see systemd again (or how to obliterate your system)
          GitHub#6237 systemd can’t handle the process previlege that belongs to user name startswith number, such as 0day
          GitHub#2039 Default value of RemoveIPC doensn’t allow to use third party daemons. — “This is an issue tracker, not a support forum.”
          GitHub#8596 redhat#1494014 systemd incorrectly unmounts a reused mount point after a device removal / systemd automatically unmounts filesystem mounted using “mount <mountpoint>” command
          Github#9602 systemd won’t allow the system to start if the system is configured correctly (/etc/localtime as a symlink) (you can even use systemd’s tool to configure it!)
          how to crash systemd in one sweet (works as any user, not just root) and response and rebuttal
          systemd v228 local root exploit
          systemd Using 4GB RAM After 18 Days of Uptime
          Phoronix – Screen locking issues (including a security issue) with gnome-shell — remained unfixed for over a year
          SoylentNews – PID 1 segfaulting on upgrade; journalctl usability issue – bug report still marked as “NEW”
          “Tried to boot my laptop from a cafe…”

          ———————— Unprofessionalism
          Lead systemd developer doesn’t understand su, expects it to do something else and then labels it a “broken concept” – su isn’t supposed to inherit cgroups or audit, those concepts are relatively new and arrived well after the creation of su. TTYs were originally physical devices so of course su is supposed “inherit” the same device otherwise it would be truly broken. Pseudo TTYs emulate real TTYs so their behaviour is obviously expected to be identical. su really is just a simple mechanism that calls setuid(2) in order to switch to another user. If he needs to write a new utility to handle scenarios that su was never designed to handle, no problem, but to label it as a “broken concept” demonstrates a lack of understanding of what su actually is.

          #13074
          Anonymous
            Helpful
            Up
            0
            ::

            For further reading, here’s a list of articles which present various criticisms of systemd

            EWONTFIX – Broken by design: systemd
            EWONTFIX – systemd has 6 service startup notification types, and they’re all wrong
            systemd: The Biggest Fallacies
            Debian Bug #762194 “Automatic switch to systemd on wheezy->jessie upgrades”
            “On the architecture of systemd, I have a legitimate concern with the scope…” article, plus infographic
            Erosion of Choice?
            Combatting revisionist history (debian forum: 2015)
            Debian init system debate: arguments against systemd (and upstart)
            systemd: harbinger of the linux apocalypse infoworld.com article
            (anti) systemd articles by Steve Litt
            Laurent Bercot’s (anti) systemd page
            preserve freedom of choice of init systems
            systemd: Please, No, Not Like This
            The bad side of systemd: two recent systemd failures
            “…There are several problems with systemd unrelated to code quality…”
            systemd is the best example of Suck (explained by suckless.org)
            Patrick’s playground – systemd propaganda: It’s a crap!
            Fast boot? in-the-wild discussion (workarounding slow OOTB systemd boot) “Performance tuning the boot process”
            systemd: Assumptions, Bullying, Consent
            Open letter to the Linux World
            an experience shared by software engineer on systemd
            systemd pitfalls (July 2017)
            systemd Or Poettering, Name Your Poison
            another list of technical points explaining why systemd is bad (by boycottsystemd.org)
            Ts’o and Linus And The Impotent Rage Against systemd
            A realization that I recently came to while discussing the whole systemd controversy (by Theodore Ts’o)
            systemd Forward Secure Sealing of System Logs Makes Little Sense
            journald and rsyslog
            What I don’t like about journald / Linux Journal
            Why I dislike systemd
            Top 5 systemd troubles – a strategic view for distros
            systemd sucks (experience of galexander)
            Lamest Vendor Response 2017 #PwnieAwards goes to Lennart Poettering for systems f*ckups photo
            Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise
            systemd requiring CAP_SYS_ADMIN weakening container safety in coreOS/rkt
            Problems with systemd and Why I like BSD Init (by Randy Westlund)
            Debian Bug #668001 “debootstrap: cant install systemd instead of sysvinit” (2014 mailing list thread, 100+ msgs)<br>
            “systemd” and “zeitgeist” daemons as great security risks
            A timesyncd total failure and systemd’s complete lack of debugability
            Systemd’s DynamicUser feature is (currently) dangerous

            #13079
            Anonymous
              Helpful
              Up
              0
              ::

              Does this not entail better reliability?

              Maybe try rewording the question. I can’t identify any “reliability” I’m missing in the absence of systemd.

              Do we lose some functionality or compatibility of some applications?

              non-systemd users experience lost compatibility with debian-packaged products as a result of introduced declarations (hardcoded) stating systemd “dependence”. To date, repackaging by antiX, by devuan, and by a few other parties has preserved the usability and functionality of all, or nearly all, packaged applications. This (the successful UNbundling, the removal of newly-introduced systemd dependent code within a package) underscores 2 points: 1) valid alternatives to systemd exist, and 2) the systemd dependence declarations introduced by the debian packager(s) have typically been avoidable — representing their willful choice rather than a necessity.

              The sole functionality I recognize that I’m “missing” as a systemd outsider is Docker.
              Knoppix 8.3 (via a script named “knocker”) has achieved “Docker without systemd”; antiX does not yet have that capability.

              #13086
              Member
              olsztyn
                Helpful
                Up
                0
                ::

                Thanks very much for all this info! It will take me some time to study but study I will… This is good stuff to understand and in my limited understanding I think I agree systemd is the wrong path, particularly such complexity creates problems.
                In my ‘reliability’ question I meant just that. Such complexity, trying to do too much is likely to result in reliability issues. I strongly feel Linux should follow ‘keep it Simple’ path.

                Live antiX Boot Options (Previously posted by Xecure):
                https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

              Viewing 6 posts - 1 through 6 (of 6 total)
              • You must be logged in to reply to this topic.