Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacem...
  • ancap shark@lemmy.today
    5·
    6 months ago

    What you’re refering to as Linux, is in fact, Systemd/Linux, or as I’ve recently taken to calling it, Systemd + Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning Systemd system made useful by the Systemd corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX

  • Olap@lemmy.world
    3·
    6 months ago

    When does systemd stop? Linux without it is increasingly looking unlikely in the future. Are we not worried about it being a single point of failure and attack vector?

    This isn’t a moan about the unix philosophy btw, but a genuine curiosity about how we split responsibilities in todays linux environment.

    • NateNate60@lemmy.world
      2·
      6 months ago

      SystemD will consume the entirety of Linux, bit by bit.

      • In 2032, SystemD announces they’re going to be introducing a new way to manage software on Linux
      • In 2035, SystemD will announce they’re making a display system to replace the ageing Wayland
      • In 2038, the SystemD team announces they’re making their own desktop environment
      • In 2039 SystemD’s codebase has grown to sixteen times its size in the 2020s. SystemD’s announces they’re going to release replacements for most other packages and ship their own vanilla distro.
      • In 2045 SystemD’s distro has become the standard Linux distribution. Most other distros have quietly faded away.
      • In 2047, SystemD announces they’re going to incorporate most of GNU into SystemD. Outrage ensues from the Free Software Foundation, which vehemently opposes this move.
      • In 2048, Richard Stallman dies of a heart attack after attempting to clone SystemD’s git repo. SystemD engages in a hostile takeover and all resistance within the FSF crumbles
      • In 2050, SystemD buys the struggling RedHat from IBM for $61 million.
      • In 2053, most world governments have been pressured into using SystemD.
      • In 2054, Linus Torvalds, fearing for his life, begins negotiations to merge kernel development into SystemD
      • In 2056, the final message on the Linux kernel development mailing list is sent.
      • In 2058, Torvalds dies under suspicious circumstances after his brand-new laptop battery explodes.
      • In 2060, SystemD agents assassinate the CEO of Microsoft.
      • In 2063, after immense pressure from SystemD-controlled human rights organisations, Arch developers discontinue development.
      • In 2064, the remaining living Debian developers release the next stable version of their clandestine and highly illegal distro.
      • taladar@sh.itjust.works
        2·
        6 months ago

        I think you might want to recheck the ages of some of the people in your timeline, most of them aren’t that young anymore.

        • TheGrandNagus@lemmy.worldEnglish
          0·
          6 months ago

          Debian in many ways isn’t as slow-moving as people think.

          For example, they moved to Wayland by default (for Gnome anyway) in 2019. A number of well-known distros likely won’t have that until 2025/2026 or beyond.

          • 0x0@programming.dev
            0·
            6 months ago

            Sadly they’ve been dropping archs throughout the years, meaning they’re no longer the distro you can use to run on “anything” from a pi to a mainframe…

            • yoevli@lemmy.worldEnglish
              1·
              6 months ago

              Doesn’t trixie still support like a dozen arches? I think one of the more recent deprecations was MIPS BE which is functionally obsolete in 2024, at least insofar as practically no one is using it to run a modern distribution.

              • CrazyLikeGollum@lemmy.worldEnglish
                1·
                6 months ago

                Bookworm, Trixie, and Sid all currently support a total of 10 different architectures.

                And looking through the Wikipedia article for Debian’s version history, most of the dropped architectures were functionally obsolete when they were dropped, or like the Motorola 68000, when support was added. (notable exceptions being IA-64 which was dropped 4 years before intel discontinued it, SPARC which is still supported by Oracle, and PowerPC.)

              • 0x0@programming.dev
                0·
                6 months ago

                If your bar is “modern distribution” stick to Ubuntu.

                If you want to maintain older hardware Debian used to be a go-to solution.

  • KISSmyOSFeddit@lemmy.world
    2·
    6 months ago

    It’s still missing core functionality for an init system, like a display server protocol, compositor, desktop environment and web browser smh.

    • million@lemmy.worldEnglish
      0·
      6 months ago

      I read the original mastodon post by the developer of run0 and I am still don’t understand what the problem with SUID is.

      Whats an example of an attack that would work with sudo and doas (which also uses SUID) and not on run0?

    • d3Xt3r@lemmy.nzM
      0·
      6 months ago

      Agreed, this is a nice inclusion. I also hate sudoers with a passion - I already use doas but it’s not standard (in the Linux world anyway), but with systemd providing an alternative means that it’ll become a standard which most distros would adopt, and I hope this means we can finally ditch the convoluted sudoers file once and for all.

        • NekkoDroid@programming.dev
          0·
          6 months ago

          The thing with this is: its just a symlink to the systemd-run binary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debian systemd package includes systemd-run.

          I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is makepkg that should never be executed as root, but does internally call some things with elevated privileges (mostly pacman to install and remove packages). Currently it checks for sudo and if not falls back to su, but maybe it might be worth considering changing su for run0 if its guaranteed to be there.

        • d3Xt3r@lemmy.nzM
          1·
          6 months ago

          doas is quite popular in the BSD world, and was ported to Linux a few years ago (via the OpenDoas project).

          For starters, it’s is a lot smaller than sudo - under 2k lines of code vs sudo’s 132k - this makes it lot more easier to audit and maintain, and technically less likely to have vulnerabilities.

          Another security advantage is that doas doesn’t pass on the environment variables by default (you’d have to explicitly declare the ones you want to pass, which you can do so in the config).

          The config is also a lot simpler, and doesn’t force you to use visudo - which never made sense to me, visudo should’ve just generated the actual config, instead of checking it after the fact. Kinda like how grubby or grub2-mkconfig works. But no need for that complexity with doas.

          Eg, the most basic doas config could just have one line in the file: permit: wheel. Maybe have another line for programs you want to run without a password, like permit nopass dexter cmd pacman.

  • gandalf_der_12te@discuss.tchncs.de
    1·
    6 months ago

    I honestly started out not liking systemd at all, mostly due to the reports that it did waaay to much, but nowadays, I like the concept.

    It is basically officially moving daemon management from a script-based approach to a table/database-based approach. That improves static analyzability, therefore increasing clarity, and probably even performance.

    I agree that we should abandon scripts and move towards declarative software management, and abandoning sudo for a more declarative system seems like a good step to me.

  • ouch@lemmy.world
    1·
    6 months ago

    How does systemd-run/run0 handle what /etc/sudoers currently does?

    I’m disappointed in how little technical discussion there is in this thread.

    • chameleon@kbin.social
      1·
      6 months ago

      Looking at the implementation, it doesn’t really implement sudoers or tools like sudoedit in any way. systemd-run has already been an existing tool for quite some time and this is really just a different CLI for it. That tool asks systemd to make a temporary new service and immediately run it. That, in turn, requires blanket yes/no approval for org.freedesktop.systemd1.manage-units via polkit.

      So with run0, you can either do everything or you can do nothing. In-betweens are just not a thing at the moment. There’s very little new backend code running as root.

      run0 bash should behave very similar to something like systemd-run --uid=0 --gid=0 --wait --same-dir --send-sighup --pty --pipe --collect bash and the majority of those options have been available for quite a while.

        • LemmyHead@lemmy.ml
          1·
          6 months ago

          Actually no. The thing is just that systemd handles so many things that makes the lives both developers/distro maintainers and users easier, but most of it happens in the background. You can forget about having to learning complexer tools, just do it all via systemd

    • corsicanguppy@lemmy.ca
      01·
      6 months ago

      Systemd has always been about “don’t ask questions or well call you obstructionist and old”.

  • SuperSpruce@lemmy.zip
    1·
    6 months ago

    I’m no Linux expert, but I’ve never had any problems with sudo, it just works. Shouldn’t systemd have higher priorities on their mind? This feels like change for the sake of change. And if this does happen, I sincerely hope that it just works, like sudo.

  • secret300@lemmy.sdf.org
    0·
    6 months ago

    But for why (I’m commenting this before reading) wouldn’t it make more sense to home I’m the scope of systemd so it can be easier to maintain? Why have it do everything?

    • August27th@lemmy.ca
      0·
      6 months ago

      Why have it do everything?

      Isn’t the guy behind systemd a (former?) Microsoft employee? I feel as though that might offer a clue as to why the trajectory towards bloat.

        • LemmyHead@lemmy.ml
          0·
          6 months ago

          Why do you consider it as poisoning? I’ve heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?

          Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they’re a very welcomed feature imo

          • PseudoSpock@lemmy.dbzer0.com
            0·
            6 months ago

            By itself, solely doing init, it would have been fine, however, binary logging (even if you eventually end up with a text log, that’s wasting disk space on a binary format no one wants or needs), and it didn’t stop there. He keeps replacing Linux subsystem after subsystem, and many of those replacements are not progress, just duplication of effort and creates more ways for configuration drift.

            • LemmyHead@lemmy.ml
              01·
              6 months ago

              You can still forward to text syslog or to a central logging server like Loki if working with multiple hosts. I still don’t get the issue with binary logs.

              • PseudoSpock@lemmy.dbzer0.com
                1·
                6 months ago

                Yes, and many distros have that out of the box… But they don’t have it sent to keep the binary journal as close to empty as possible. So you end up with twice the space in use for logs. As for the issue with binary logs, text logs can be read by far more tools and utilities, rather than just journalctl and pipes.

                • LemmyHead@lemmy.ml
                  11·
                  6 months ago

                  You can set the space limit for journals logs really low then, to avoid double space usage. As for the last argument, that also was an issue for me years ago because not all tools were compatible with the journald format, but that’s since long fixed now and I’ve not experienced any issue for a long time. Journal logs provide a standard format for all applications, so third party tools don’t need to be compatible with every log format of your applications. And it also comes with great additional features like -b or --since etc. So I still don’t get the issue here

            • ProtonBadger@lemmy.ca
              01·
              6 months ago

              Here is the rationale for the Journal. In short it is really not that simple and it has a lot of advantages over simple text files and it saves disk space.

  • vsis@feddit.clEnglish
    0·
    6 months ago

    Oh, it’s gonna use polkit. Sudo bloat is a grain of sand compared to polkit.

    Why people want to replace sudo with polkit? Visudo is no near as obscure as configuring polkit.

    I hope distro maintainers don’t follow this.

    • Shareni@programming.dev
      0·
      6 months ago

      Systemd monolith - worst thing to have ever happened to Linux

      Wayland monolith - best thing to have ever happened to Linux

      • drwankingstein@lemmy.dbzer0.comEnglish
        0·
        6 months ago

        I think wayland has potential but in it’s current state it’s just half baked. Once more protocols get merged, maybe in a decades time Wayland should be quite flexible and robust.

          • drwankingstein@lemmy.dbzer0.comEnglish
            01·
            6 months ago

            It does have potential. I think anyone denying that is simply wrong. the issue with wayland is purely how slowly it moves and the fragmentation. Now the fragmentation is actually in large part due to how slowly it moves. There are numerous WIP protocols that will greatly decrease fragmentation when all are merged.

            I can’t wait because it seems like it will happen in the short future of one or two decades xD