• 0x4E4F@lemmy.dbzer0.comOP
      link
      fedilink
      arrow-up
      10
      arrow-down
      4
      ·
      edit-2
      7 months ago

      Faster, more stable, no systemd, supports musl and architectures not usually supported by most distros. It’s probably the most stable rolling release distro out there.

            • flying_sheep@lemmy.ml
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              7 months ago

              I literally haven’t run into a single one in the whole time Arch has been using it.

              (I installed Arch shortly before it switched to systemd and have been using it since without pause)

              • 0x4E4F@lemmy.dbzer0.comOP
                link
                fedilink
                arrow-up
                1
                arrow-down
                1
                ·
                7 months ago

                You must be running hardware not older than 4 or 5 years. Try running it on hardware 10+ years old.

            • throwwyacc@lemmynsfw.com
              link
              fedilink
              arrow-up
              2
              ·
              7 months ago

              What are the systemd bugs that are so bad? I kinda get the bloated comment, but I don’t really mind when it serves its purpose

              • 0x4E4F@lemmy.dbzer0.comOP
                link
                fedilink
                arrow-up
                2
                arrow-down
                1
                ·
                7 months ago

                Closing handles on services that for god knows what reason, just hang. Also stopping and starting services again doesn’t always work as intended.

                • throwwyacc@lemmynsfw.com
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  7 months ago

                  That’s interesting. I’ve never had any issues with systemd directly mainly with poorly setup default configs I’m a big fan of a centralised place to manage services. Works super well with podman quadlets

                  But I’m not too invested use whatever works for you I reckon

                  • 0x4E4F@lemmy.dbzer0.comOP
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    7 months ago

                    I’m also a fan of centralized places to handle things (I prefer having just one package manager, not the package manager and flatpak and pip and god knows what else), but there are other init/service managers.

        • DickFiasco@lemm.ee
          link
          fedilink
          arrow-up
          15
          arrow-down
          1
          ·
          edit-2
          7 months ago

          The main benefit is that when people get tired of distro flame wars, they can move on to init system flame wars.

          • TheHarpyEagle@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            7 months ago

            I have no horse in this race, I don’t have strong feelings about it either way as long as it works. But I can’t help but notice that OP skipped replying to me.

            • flying_sheep@lemmy.ml
              link
              fedilink
              arrow-up
              3
              ·
              7 months ago

              OP said “bloated and full of bugs”.

              I’ve been using Arch since shortly before they started using systemd and literally never ran into a systemd bug.

              I have no clue at this point what “bloated” means. Maybe if everything works and you don’t have to hack up your own solution all the time, that’s “bloat”?

        • Yes. From their website:

          C library diversity

          Void Linux supports both the musl and GNU libc implementations, patching incompatible software when necessary and working with upstream developers to improve the correctness and portability of their projects.

          • mexicancartel@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            1
            ·
            7 months ago

            “Patching incompatible software”

            What does that mean? If glibc is supported why there is a portability issueand requirement of patches?

              • mexicancartel@lemmy.dbzer0.com
                link
                fedilink
                English
                arrow-up
                1
                ·
                edit-2
                7 months ago

                I have checked the void website and it does NOT support glibc. Here is it:

                Wait edit: there is musl variant and glibc variant…

                Incompatible software

                musl practices very strict and minimal standard compliance. Many commonly used platform-specific extensions are not present. Because of this, it is common for software to need modification to compile and/or function properly. Void developers work to patch such software and hopefully get portability/correctness changes accepted into the upstream projects.

                Proprietary software usually supports only glibc systems, though sometimes such applications are available as flatpaks and can be run on a musl system. In particular, the proprietary NVIDIA drivers do not support musl, which should be taken into account when evaluating hardware compatibility.

                glibc chroot

                Software requiring glibc can be run in a glibc chroot.

              • mexicancartel@lemmy.dbzer0.com
                link
                fedilink
                English
                arrow-up
                1
                ·
                7 months ago

                Well if glibc is supported all glibc softwares must work right?? Patching the software to support musl would not be needed if it does support glibc

              • 0x4E4F@lemmy.dbzer0.comOP
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                7 months ago

                Not just musl, software that depends on systemd (or parts of it) as well.

                We also need to patch binaries as well sometimes 😁. It is fun though, cutter and/or iaito are great tools.

        • 0x4E4F@lemmy.dbzer0.comOP
          link
          fedilink
          arrow-up
          2
          ·
          7 months ago

          Yes, there are basically 2 builds for every architecture. One is glibc, the other is musl. I haven’t used the musl builds that much, just toyed with them a few times (mainly because of lack of software), but if you only use open source software that doesn’t specifically depend on the GNU toolchain, yes, you can daily drive it, no doubt there. And yes, it is faster than the glibc builds.

            • 0x4E4F@lemmy.dbzer0.comOP
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              7 months ago

              The syntax is a bit different, but everything else, more or less the same. In fact, if you just wanna repackage a deb or an rpm, it’s even easier than in Arch, xbps-src can handle deb and rpm automatically, it detects dependencies and does repackaging on it’s own. You basically just have to feed it the deb/rpm file in a one liner, that’s it.

              I should probably give an example. Here is the template file (they’re called templates in Void) for Viber. You basically just feed it the deb, do a vcopy (copy operation specific to xbps-src) and that’s it, everything else regarding the repackaging is done automatically by xbps-src.

              • Thanks for the explanation. How does xbps-src handle dependencies? I.e. does it somehow detect the dependencies in the original package and find corresponding Void Linux packages? What about dependency versions? What happens if a dependency is not available in the Void repos?

                • 0x4E4F@lemmy.dbzer0.comOP
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  7 months ago

                  How does xbps-src handle dependencies?

                  Regarding feeding it rpm/deb packages, it reads the dependencies from the deb/rpm package and uses the equvalent names in shlibs (shared libraries). That’s basically a list of libs that some applications expect to find, so xbps-src just makes a symbolic link to the equvalent lib with the name that the app expects to find. Look at the example I gave above with libtiff.

                  Regarding everything else built from source, there are 3 types of dependencies, since the packages are built in a chroot: hostdepends - dependcies that are requires by the chroot system, makedepends - dependencies that are required to build the package, depends - dependencies that are required to run the package. The ones that are required just to run the thing are the just depends, the other 2 are required for building only.

                  What happens if a dependency is not available in the Void repos?

                  You find the equivalent lib in Void (the xtools package is a great help for a lot of things, including repackaging), add it to shlibs and that’s it. If it’s proprietery or Void doesn’t have it (higly unlikely if it’s open source… I have yest to run in a case like that), you have to put in the template as a distfile (if proprietery and only binary versions are available), or you have to compile from source (also done automatically by xbps-src once it detect there are distfiles for the lib and is not present in the repos).

                  Building from source is also easy in most cases (when no patches need to be applied). xbps-src has build styles (gnu-make, meson, etc.), so you just define that in the buildstyle parameter and it does everything automatically, including adding missing build dependencies.

                  xbps-src goes through a lot of trouble to make packaging and building as automatic as possible.

        • 0x4E4F@lemmy.dbzer0.comOP
          link
          fedilink
          arrow-up
          3
          ·
          edit-2
          7 months ago

          No, just bootup and general responsivness of the system. Software is still compiled by the ssme compilers used in other distros. Everything is not magically faster.

          Though on the musl build, yeah, it is faster. Trouble is, you can’t run glibc software on it. Through chroot, yeah, but natively, no.

        • 56!@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          7 months ago
          • The package manager is extremely fast
          • The lack of systemd reduces startup time
          • The musl libc marginally speeds up programs
      • TrickDacy@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        Interesting. I will have to try it some time. I just know on my raspberry pi 5, out of the few OSes I could get to run on it, Arch was the fastest and smoothest running, and gets updates all the time. All this, even though rpi5 is not even officially supported yet!