• Tartas1995@discuss.tchncs.de
      link
      fedilink
      arrow-up
      4
      ·
      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
        2
        ·
        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.

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

        Unix was also made in 1969, Computers are a tiny bit more complicated now and expected to do slightly more than they did back then.

      • Possibly linux@lemmy.zip
        link
        fedilink
        English
        arrow-up
        1
        ·
        8 months ago

        You can in fact run 2/3 Systemd whatever that means. Systemd components are modular so you can run the base system by itself if you want to.

        Additionally systemd just works. You really don’t need to care about the details as running something like a web server or service is as simple as starting it. Dependencies are handled automatically.

      • MonkderZweite@feddit.ch
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        8 months ago

        More like it’s bad because of architecturial decisions (integrated init system; system state managemt in the same package as init and supervision), creating lots of unneeded complexity, number of CVE’s, how the developers behave (or don’t), and that you can’t have other init systems in the same repo without a fuckton of shims and wrappers.

        Sounds like valid concerns to me.

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

          That’s the problem with how most things Lennart designs are. They are typically 70-80 percent excellent ideas brilliantly architected, 10-20 percent decisions that we can agree to disagree on but well designed still, and ~10 percent horrifically bad ideas that he is unable to receive criticism on because of his standing, terrible attitude and ~90 percent good and acceptable ideas.

          Another problem is that they all seem to be designed in a way that they are the One True Way to do something and are designed to choke out any alternatives because Lennart Knows Best.

          I’m still ambivalent about having this much extra logic and complexity attached to my init system but the ship sailed long ago and I’m well into making lemonade at this point.

              • 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

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

      I been told it was to big, but if you look at the Linux Kernel, it is huge.

      People also love to say Unix, but Linux is not Unix.

    • SkippingRelax@lemmy.world
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      8 months ago

      In fairness reading this thread all I see is systemd good

      Why: i find sysvinit start up scripts too complicated to read/modify so let’s drop this gigantic mammoth that does a million other things on my lunux system so I don’t gave to learn how to write a shell script.

      I don’t have much skin in the game and have been out of the loop for many years but don’t find many of the arguments in favour of systemd very convincing

  • Johanno@feddit.de
    link
    fedilink
    arrow-up
    1
    ·
    8 months ago

    I am fine with systemd. It works. It is more complicated than init.d

    Before you copied some random file you edited and put it in init.d and it worked. Now you copy some systemd services file into systemd and run enable and start and it doesn’t work because you don’t know what you are doing.

    I didn’t know what I was doing in init.d too but now I have to learn systemd services. Once you know a bit it will work then (probably)

    • ebc@lemmy.ca
      link
      fedilink
      arrow-up
      1
      ·
      8 months ago

      I disagree. Before I had to copy and edit a huge-ass script (100+ lines) in init.d where 80% of it was concerned with PID files. I just want to start a process on boot, why is it so hard?

      Now I can look at the documentation and write a simple unit file myself. It’s like 4 lines.

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

      Before you copied some random file you edited and put it in init.d and it worked.

      Before you copied some random file you edited and put it in init.d and it appeared to be working but then failed in random ways the first time you restarted, the first time you rebooted, the first time you restarted it via sudo instead of directly as root since some environment variable differed,…

      So really it only appeared to be working in my experience because you had no real way to check.

      • Johanno@feddit.de
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        I mean it should be obviously clear that copying random files isn’t sth. You should do anyways

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

          Well, in this context what we are talking about is some random init script from some other service because nobody wants to write all that crap from scratch every time.

  • _cnt0@sh.itjust.works
    link
    fedilink
    arrow-up
    1
    ·
    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
            2
            ·
            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.

            • ZephrC@lemm.ee
              link
              fedilink
              arrow-up
              1
              ·
              8 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.

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

        people keep saying this, but what is their extinguish plan? how could they realistically extinguish linux? it’s not a company they can buy, or even a single thing they can ruin.

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

            That is my point, they have tried and failed completely before when their main product was windows licenses. Now, linux is incredibly important to their azure business, they wouldn’t want to potentially cause detriment to that and is far more important to them than windows licenses.

            Also why would we have to rip out systemd, even if they tried to claim ownership of it and make it proprietary, it could be forked from before the license change and we would keep on going like nothing happened.

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

                What are you even talking about? systemd is currently under an opensource license, they cant retroactively change that. Any changes would be for it going forward if it is even possible for them to buy the rights to it (which I’m not convinced it is as Lennart Poettering is not the sole contributor and Red Hat / IBM and many others also have a significant stake in it). Sun patented Java on it upon its creation and when oracle bought sun, they bought the rights to those patents. They aren’t comparable situations. Java was never open source, it was source available, but still proprietary.

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

        This sounds a bit ridiculous. If Linus started working at MS I wonder if people would suddenly think Linux was a MS project and start hating on it.

  • arc@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    8 months ago

    Kind of sad there are still people raging over systemd. When it flares up in discussions there is the usual debunked nonsense:

    • it only logs information to binary and this is somehow bad. Except it it can be configured to log to text as well and it uses binary so it can forward secure sign records to prevent tampering as well as offering database style query operations.
    • it’s insecure because the repo has millions of lines of code. Except that they compile into hundreds of small binaries running with least privilege, and often replacing the task of far more dangerous processes (e.g. there is an NTP client in systemd which sets the time and nothing else).
    • various rants about the primary author

    What is more bizarre is the nostalgia and hearkening back to sysvinit scripts when systemd didn’t replace sysvinit! Systemd replaced upstart which replaced sysvinit. Because writing 100s of lines of script to stop/start/restart a process sucked - insecure, slow, didn’t scale, didn’t capture dependencies and everyone knew it. Upstart was the first attempt to solve the issue and was used in Debian / Ubuntu, Fedora / Red Hat, openSUSE and others until systemd came along.

  • ᕙ(⇀‸↼‶)ᕗ@lemm.ee
    link
    fedilink
    arrow-up
    1
    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.

    • 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.

    • 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.

  • Pasta Dental@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    8 months ago

    Poettering and Systemd are amazing and Linux would not be as good as it is today without them. Whether you like it or not, we can’t have a fragmented ecosystem and expect people and companies to adopt it (see the 14 competing standards XKCD). Having one solid base that works the same on every client is like literally the base requirement for making a product for the said client. Systemd, flatpak, xdg-portals, pipewire and immutable distros all solve this.

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

      Here’s my hot take: I don’t care what operating system most people use. If people are happy on Windows, let them stay on Windows. That’s not my problem. When you say we need to make Linux less diverse and interesting to make number go up because more biggerer number more gooderer then suddenly that is my problem. You are trying to make my experience worse for the sake of something I do not care about.

      There is nothing wrong with systemd. Most people on Linux are using it, and that’s fine. Options are good too though. I specifically like Linux because it’s NOT a bunch of homogeneous lowest common denominator sameyness. That’s the very thing I don’t want.

  • 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
      1
      ·
      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.

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

        It also didn’t help that Poettering isn’t particularly popular on a personal level. I think there would have been a lot less drama if he had better people skills.

        • TxzK@lemmy.zip
          link
          fedilink
          arrow-up
          1
          ·
          8 months ago

          Yeah, but to be honest, I would have terrible “people skills” too if people sent me death threats over writing a free software.

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

      I believe partly because it takes over so many responsibilities that it becomes a requirement for things that don’t need to require it. Plus it diverged from the Linux principle of do only one thing.

      Also, afair, it was buggy for a while.

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

      TL;DR init system, services, sockets, slices, logs, boots, VM’s, containers… and that’s fantastic, for monolithic systems. journalctl go brrrr

      Strap in, folks. Old timer with a gavel to slam.

      When systemd is unfolded in full, people are sort of apt when they jokingly say “-Linux, or what I’d like to call gnu/systemd/Linux”. Some scream at the top of their lungs, yearning back to rc.0 days, “when everything was much simpler”… this is where the gavel comes down. There are so many improvements they are hard to list and if you asked me if I could go back, only with modern software, I would say nay… and here’s why:

      Running services is a whole mess more than just running background apps, and it’s intrinsically intertwined with what is known as the init system - no matter what some people may think. Init is the process of initializing (or bootstrapping) an operating system, and services are background services, but both are about managing the processes within the Linux stack - or the thread. Some say that systemd is doing more than it should, but systemd is not “crossing streams” when both init processes and services need to be managed in concert depending upon the way a system inits - because there’s more than one way to init.

      systemd manages init through scopes, slices and services, which combined create the hierarchy of processes used to bootstrap a system, get things up and running, with their relative permissions, in a given state, to facilitate a running and functioning system. Socket units handle socket files or destinations, and timer units handle event driven processes.

      It all comes together into a dependency chain that defines your running system, which is testable and manageable from a set of tools. systemctl is used to manage a running system, and I think it does a great job of it. Imagine fail testing a bunch of non-standardised, random rc bash script files that aren’t distro agnostic, along with whatever daemon runner you were using. It was a mess, and systemd sought to fix that - which imho it has. We view a booted Linux system and it’s process tree much differently through the systemd lens, which gives us a newfound focus that helps us better manage a running system.

      Also, logs are binary now… you’re all so spoiled and you don’t even know it. Do you remember 20GB txt files you absolutely had to open? Pepperidge farm remembers. Which brings us journalctl, which is just so good. It’s the swizz army knife of Linux logs. You can point it at anything. Specify -k for dmesg, a service using --unit, point to a binary in /usr/bin, select previous boot with -b -1, -f for follow, -e take me to the end of a log. If you haven’t learned how to use this tool, you are running blind. It whips every dang logging system out there. Going from systemd to windows events feels like going from a soft mattress to the inside of an iron maiden.

      systemd-boot is blazing fast. Don’t get me wrong, Grub2 is still fantastic as well (Apple seems to think so at least), but considering ease of us - as I often do - I’m inclined to prefer systemd-boot because of bootctl, because like journalctl, it’s a wonderful piece of kit for managing, analyzing and failtesting boot images, provides UEFI functionality and being a sort of one-stop shop for the boot process.

      Now we we’re seeing systemd managing VM’s (machinectl) and containers (containerctl), and honestly I’m all for it. Make my life easier. Please. Standardise that mess. And since it is standard, everyone supplies systemd units and because of the nature of systemd and it’s designs, it’s all fail-safed to hell and back. This is good. We want this. At least on the desktop, workstation, even some servers. For containers, embedded, not so much, as they aren’t monolithic systems. That being said, NixOS has proven that systemd isn’t a barrier to entry for new system paradigms either, so I feel those fears were unfounded.

      You get the theme here. Systemd is a system management suite, and not just a service runner or init system. It seems to grow and grow out of proportion, but at the end of the day, it’s about getting the system(s) and software up and running, as well as managing those processes and figuring out where problems lie. That’s what systemd does. It’s become part and parcel of a fully monolithic Linux stack, and in my opinion it’s a great project that makes our lives much easier.

      To me systemd is zen. It’s the cup of tea Linux always needed, and I’m not ashamed to say so.

      • Hapbt@mastodon.social
        link
        fedilink
        arrow-up
        1
        ·
        8 months ago

        @taanegl @DmMacniel omg i was so prepared to hear a anti-lennart-pottering rant about sysv init scripts
        thanks for what instead turned out to be a very thoughtful and educational text which i will now send to all these sysv ppl

  • vojel@discuss.tchncs.de
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    To me systemd is fine, I am not really emotional at init systems. But on the other hand Linux is about choice and systemd kills that in some way because it does so much more than just starting services. GNOME is unusable without systemd, which makes it a no choice if you go into another rabbit hole. It’s kinda weird how deeply systemd is integrated in Linux these days. What I really dislike is that the log is in binary format by default which makes it necessary to deal with another tool to read logs. But well software changes, so do tools. But honestly the devs acted like dick heads sometimes, so I think most of the antipathy comes from their behavior and well yes MS now kinda pushing systemd because poettering works for them. I have fear that MS forces the systemd devs to implement things you cannot simply opt out of because it is so tightly integrated. Maybe copilot for writing systemd unit files would be nice though :P

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

      well yes MS now kinda pushing systemd because poettering works for them. I have fear that MS forces the systemd devs to implement things you cannot simply opt out of because it is so tightly integrated.

      How has MS pushed systemd?

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

        That’s a nonsense spin of things. There wasn’t/isn’t a need for Microsoft to push systemd, because it had been adopted by all major linux distributions before Poettering even made the switch. It’s a straw that init system luddites clutch at.

  • 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