• @_cnt0@sh.itjust.works
    link
    fedilink
    474 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
      cake
      link
      fedilink
      124 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
        54 months ago

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

        • ZephrC
          cake
          link
          fedilink
          164 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
            74 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.

            • ZephrC
              cake
              link
              fedilink
              54 months ago

              That’s totally fair. I’m not some weird evangelist or anything. I just like options and think OpenRC is kinda neat. There’s nothing wrong with systemd, and honestly it’s more work using other options. Not for the actual init system, but for some of the other stuff systemd does. I’ve had to learn cron, and that has been… interesting. It feels like all of the documentation around cron just assumes you already know how cron works. I’m still not sure if I’m doing it right, but I’ve had a good time and my computer works, and really that’s good enough for me.