• Tartas1995@discuss.tchncs.de
      link
      fedilink
      arrow-up
      2
      ·
      8 months ago

      The argument is basically that it does too much and as the motto of Unix was basically “make it do 1 thing and that very well”, systemd goes against that idea.

      You might think it is silly because what is the issue with it doing many things. Arguably, it harms customization and adaptability, as you can’t run only 2/3 of systemd with 1/3 being replaced with that super specific optimisation for your specific use case. Additional, again arguably, it apparently makes it harder to make it secure as it has a bigger attack surface.

      • fruitycoder@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        8 months ago

        Sustemd is modular though, you don’t have to use every subsystem. The base init system and service manager is very comprehensive for sure.

              • ozymandias117@lemmy.world
                link
                fedilink
                English
                arrow-up
                1
                ·
                edit-2
                8 months ago

                At a high level, microkernels push as much as possible into userspace, and monolithic kernels keep drivers in kernel space

                There are arguments for each e.g. a buggy driver can’t write into the memory space of another driver as easily in a micro kernel, however it’s running in the same security level as userspace code. People will make arguments for both sides of which is more secure

                Monolithic kernels also tended to be more performant at the time, as you didn’t have to context switch between ring 0 and ring 1 in the CPU to perform driver calls - we also regularly share memory directly between drivers

                These days pretty much all kernels have moved to a hybrid kernel, as neither a truly monolithic kernel nor a truly micro kernel works outside of theoretical debates

  • Lightfire228@pawb.social
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    I feel like the people who complain about systemd have never tried to mess with sysVinit scripts before

    6+ years ago, I was trying to configure a touchscreen HAT for a raspberry pi, and dicking with the init.rc script was a massive pain

    • Meansalladknifehands@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      8 months ago

      The alternatives to systemd isn’t init.d or some other legacy init systems. I use runit, pretty easy to understand and use. Stop being lazy dude

  • GreatDong3000@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    Hi am noob why systemd bad? I use Debian, is fucked?

    Honestly I’ve been hearing about this for a while now but never bothered to check, I’m too lazy for that.

    • Queue@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      It’s not inherently bad, it “fails” the Unix Philosophy of “Do one thing and do it well” but since Linux’s kernel is:

      • Unix-like, not Unix
      • Fails this philosophy, as it does more than one thing but does all of it pretty well
      • systemd is just a bundle of tools that do one thing and do it well under one package, like Linux’s kernel

      It used to be a mess, but that’s solved. The biggest reason to avoid systemd is mainly user preference, not anything malicious. 90% of current distros use systemd as its easier for the maintainers and package programmers to build for the general than each package and each distro having their own methods of how to do an init system and other tasks.

      How Debian and Arch and Gentoo and Slackware and other big distros worked was different, and the maintainers of those packages had to know “Debian’s way” and not a general way that most places accept. Systemd actually solved the Too Many Standards! issue.

      I’ve never really seen a big argument against systemd, but maybe I’ve just not heard it.

      • thisbenzingring@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        back when you had an init system and you got it just the way you wanted it, you would be pissed that you had to move to systemd

        now its there when you install and it is stable so it isn’t a big deal. But old beards hate change.

  • _cnt0@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    I’d like to propose a new rule for this community:

    People criticizing systemd to the extent where they promote alternatives (regressions), have to provide proof that they have or are maintaining init scripts for at least ten services with satisfying the following conditions: said init scripts must 1.) be shown to reliably start up the services and 2.) not signal their dependencies to early and 3.) gracefully stop the services 99.9% of the time. People failing to satisfy these conditions are not allowed to voice their opinions on how arbitrary init systems are better than systemd. Violations of this rule will be punished by temporary bans and forcing the violators to fill the entire canvas of a blackboard with “‘do one thing and do it well’ is a unix principle, not a linux principle” in fine print.

    More lines of semi-reliable init scripts have been written by package maintainers, than lines of systemd code by Poettering & Co, and that while achieving far less. The old init systems might have been simple, the hell of init scripts wasn’t.

    • ZephrC@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      8 months ago

      That might have been true a decade ago. I don’t actually know. I do know that modern init scripts for modern alternatives to systemd are barely longer than systemd service scripts though. So that’s kind of an insane take.

      • waitmarks@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        can you give examples of some? Not trying to bd sarcastic, i do just want to see what alternatives are doing.

        • ZephrC@lemm.ee
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          Sure, that seems pretty reasonable. Here’s the init script for sddm:

          #!/usr/bin/openrc-run
          
          supervisor=supervise-daemon
          command="/usr/bin/sddm"
          
          depend() {
              need localmount
          
              after bootmisc consolefont modules netmount
              after ypbind autofs openvpn gpm lircmd
              after quota keymaps
              before alsasound
              want logind
              use xfs
          
              provide xdm display-manager
          }
          

          That’s it. That’s the whole thing.

          That’s a pretty simple one though, so here’s Alsa. It’s a more complex one:

          code
          #!/usr/bin/openrc-run
          # Copyright 1999-2019 Gentoo Authors
          # Distributed under the terms of the GNU General Public License v2
          
          alsastatedir=/var/lib/alsa
          alsascrdir=/etc/alsa.d
          alsahomedir=/run/alsasound
          
          extra_commands="save restore"
          
          depend() {
          	need localmount
          	after bootmisc modules isapnp coldplug hotplug
          }
          
          restore() {
          	ebegin "Restoring Mixer Levels"
          
          	checkpath -q -d -m 0700 -o root:root ${alsahomedir} || return 1
          
          	if [ ! -r "${alsastatedir}/asound.state" ] ; then
          		ewarn "No mixer config in ${alsastatedir}/asound.state, you have to unmute your card!"
          		eend 0
          		return 0
          	fi
          
          	local cards="$(sed -n -e 's/^ *\([[:digit:]]*\) .*/\1/p' /proc/asound/cards)"
          	local CARDNUM
          	for cardnum in ${cards}; do
          		[ -e /dev/snd/controlC${cardnum} ] || sleep 2
          		[ -e /dev/snd/controlC${cardnum} ] || sleep 2
          		[ -e /dev/snd/controlC${cardnum} ] || sleep 2
          		[ -e /dev/snd/controlC${cardnum} ] || sleep 2
          		alsactl -E HOME="${alsahomedir}" -I -f "${alsastatedir}/asound.state" restore ${cardnum} \
          			|| ewarn "Errors while restoring defaults, ignoring"
          	done
          
          	for ossfile in "${alsastatedir}"/oss/card*_pcm* ; do
          		[ -e "${ossfile}" ] || continue
          		# We use cat because I'm not sure if cp works properly on /proc
          		local procfile=${ossfile##${alsastatedir}/oss}
          		procfile="$(echo "${procfile}" | sed -e 's,_,/,g')"
          		if [ -e /proc/asound/"${procfile}"/oss ] ; then
          		    cat "${ossfile}" > /proc/asound/"${procfile}"/oss 
          		fi
          	done
          
          	eend 0
          }
          
          save() {
          	ebegin "Storing ALSA Mixer Levels"
          
          	checkpath -q -d -m 0700 -o root:root ${alsahomedir} || return 1
          
          	mkdir -p "${alsastatedir}"
          	if ! alsactl -E HOME="${alsahomedir}" -f "${alsastatedir}/asound.state" store; then
          		eerror "Error saving levels."
          		eend 1
          		return 1
          	fi
          
          	for ossfile in /proc/asound/card*/pcm*/oss; do
          		[ -e "${ossfile}" ] || continue
          		local device=${ossfile##/proc/asound/} ; device=${device%%/oss}
          		device="$(echo "${device}" | sed -e 's,/,_,g')"
          		mkdir -p "${alsastatedir}/oss/"
          		cp "${ossfile}" "${alsastatedir}/oss/${device}"
          	done
          
          	eend 0
          }
          
          start() {
          	if [ "${RESTORE_ON_START}" = "yes" ]; then
          		restore
          	fi
          
          	return 0
          }
          
          stop() {
          	if [ "${SAVE_ON_STOP}" = "yes" ]; then
          		save
          	fi
          	return 0
          }
          

          That’s definitely longer than a systemd service, but you’d have to write an awful lot of them to be more code than all of systemd. Overall the entire /etc/init.d folder on my PC where all the init scripts even for the stuff I’m not using are stored is a grand total of 147.7 KiB. Not exactly an unmanageable amount of code, in my humble opinion.

          • waitmarks@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            8 months ago

            Its certainly easier to read than most old init scripts and I can see why some distros and openbsd would pick it over systemd for more control. I’m not likely to pick a distro that uses it anytime soon, but i can see why some do.

  • ᕙ(⇀‸↼‶)ᕗ@lemm.ee
    link
    fedilink
    arrow-up
    0
    arrow-down
    1
    ·
    8 months ago

    anyone ever seen a goldwing? it was supposed to be a motorcycle but for some reason has a fridge, microwave and what not added.

    it is still a motorcycle. you can ride it. it starts right away and has all sorts of extra functions.

    and now look at it. it is an ugly piece of engineering that only the weirdest of people like.

    dont ride a goldwing. dont use systemd.

    • JungleJim@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      No clue about motorcycles but those things look neat and win awards. I want one now. Thanks for turning me on to this neat bike.

    • WillBalls@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      What are you talking about? The goldwing has been consistently hailed as one of the best touring motorcycle for almost 40 years. Every long distance rider I’ve spoken to says the goldwing is their favorite bike for cross country rides, and the ones who have sold theirs for a BMW or Harley touring bike have expressed regrets about changing.

      Just because something has a lot of features, doesn’t mean it’s bad.