TL;DR - About switching from Linux Mint to Qubes OS from among various other options that try to provide security out-of-the-box (also discussed: OpenBSD, SculptOS, Ghaf, GrapheneOS)

  • N.E.P.T.R@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    3
    ·
    2 days ago

    I am excited to see Chimera Linux mature because iy seems like a distro which prioritizes a simple but modern software stack.

    Features of Chimera that I like include:

    • Not run by fascists
    • Not SystemD (dinit)
    • Not GNU coreutils (BSD utils)
    • Not glibc (musl)
    • Not jemalloc (mimalloc)
    • Proper build system, not just Bash scripts in a trenchcoat

    What I would like:

    • MAC (SELinux)
    • Switch to Fish over Bash (because it is a much lighter codebase)
    • Switch from mimalloc to hardened_malloc (or mimalloc built with secure flag). Sadly hardened_malloc is only x64 or aarch64
    • Hardened sysctl kernel policy
    • LeFantome@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      12 hours ago

      Chimera Linux is great. APK and cports are so good I cannot imagine going back to anything else.

      Bash is not the default shell though. Chimera uses the Almquist Shell from FreeBSD. Other Linux distros have “dash” which is basically an Almquist variant.

      Almquist is lighter than fish and fish is not POSIX compatible.

      Bash is available in the Chimera Linux repos of course and is required for many common scripts.

      “Not run by fascists”. Sometimes I wonder.

    • yazomie@lemmings.worldOP
      link
      fedilink
      arrow-up
      5
      ·
      1 day ago

      Chimera is a nice alternative to Alpine, have you thought of sending this feedback to Chimera’s dev?

      • N.E.P.T.R@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        3
        ·
        20 hours ago

        I thought about it (and I might still) but the project is still in beta and implementing sysctl and MAC would slow everything down development-wise. Switching to Fish would be easy and cool though.

    • Kajika@lemmy.ml
      link
      fedilink
      arrow-up
      9
      ·
      edit-2
      1 day ago

      What are the pros/cons of GNU coreutils vs BSD utils?

      EDIT : from their website : Desktop environment -> GNOME. What a choice, not for me.

      • LeFantome@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        12 hours ago

        First, I use either Niri or KDE Plasma on Chimera Linux. Both are just an “apk add” away. You do not have to use GNOME. There is even a KDE live image so you do not even have to run GNOME once to install if you do not want.

        I really like the BSD utils and have come to prefer them. Well written. Sleek. Well documented. The man pages are a walk through UNIX history. They feel “right” to me.

        That said, the BSD userland is frequently a pain when interacting with the rest of the Linux universe. You cannot even build a stock kernel.org kernel without running into compatibility problems. The first time I built the COSMIC desktop on Chimera, I had to edit a dozen files to make them “BSD” compatible.

        Sed, find, tar, xargs, and grep have all caused me problems. And you need bash obviously. But bash is no big deal because it has a different name.

        The key GNU utils are available in the Chimera repos. But you get files named gfind, gtar, gxargs, gsed, etc. so scripts will not find them.

        You often have to either add the ‘g’ to the beginning of utilities in scripts or edit the arguments to work with the BSD versions.

        I mean, most things are compatible and I bet most of the command-line switches you actually use will work with the BSD utils. But I would be lying if I did not say third-party scripts are a hassle.

        If I could do Chimera all over again, I would make it bsdtar and bsdsed (or bsed maybe) for the BSD versions.

        Maybe the regular names could be symlinks with sed pointing to bsdsed by default but you could point it to gsed instead of you want. The system Chimera scripts and tools could use the longer names (eg. bsdsed) instead of the symlinks. The GNU tools could be absent by default like they are now. That would be the best of both worlds. The base system would have the advantages of the BSD tools (like easier builds as outlined on the Chimera site), the system could be GNU free if you want, and you could have a system that actually works out of the box more often with third-party scripts.

        It pains me to say this. I would prefer not to use the GNU stuff but the GNU tools are the de facto standard on Linux and many, many things assume them. No wonder UUtils aims for 100% compatibility.

        Anyway, even with what I say above, Chimera is my favourite distro. The dev can be a little prickly, but they do nice work.

        • Oinks@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          1
          ·
          2 hours ago

          The GNU utils vs BSD utils issue should be easy to work around with a bit of symlinking and PATH modification:

          > type find
          find is /bin/find
          
          > type gfind
          gfind is /usr/local/bin/gfind
          
          > sudo mkdir -p /usr/local/opt/gnuutils/bin/
          > sudo ln -s /usr/local/bin/gfind /usr/local/opt/gnuutils/bin/find
          
          > PATH="/usr/local/opt/gnuutils/bin:$PATH" type find
          find is /usr/local/opt/gnuutils/bin/find
          

          or in script form:

          #!/bin/sh
          # install as /usr/local/bin/gnu-run
          # invoke as gnu-run some-gnu-specific-script script-args
          export PATH="/usr/local/opt/gnuutils/bin:$PATH"
          exec "$@"
          

          /usr/local/opt/... is probably not the best place to put this but you get the idea, you can make it work with POSIX tools. I don’t know that much about Chimera Linux but I’d be very surprised if nobody has thought of doing this systematically, e.g. as part of a distributable package.