They have virtually no moderators (they all quit because they were burnt out and manipulated), filled with racist lmayo, and are associated deeply with anti-migrant violence and warmongering (Anduril) who hire people straight out of NixOS to build weapons to fund imperialism everywhere.

Go use Guix instead (they don’t rely on free GitHub credits or limitless AWS S3 buckets) and are objectively superior on a technical standpoint (no “experimental features” that everyone considers stable) and don’t give any shit about nonfree software unless you provide it, or only contribute to nixpkgs (collective infra) and outside projects like Lix/Snix.

Avoid the NixOS community at all costs if you value your emotional labor. Even the chuds have done this with things like Determinate Systems Nix (“Nix without the drama”) and making their own corpo shill platform called “flakehub”

Source: A former NixOS community member (me)

There is no liberalism anymore, only fascist cultural hegemony that will take over every space it can.

  • sudoer777@lemmy.mlEnglish
    12·
    7 days ago

    Guix isn’t technically superior though. It doesn’t have Flakes, has 1/100 of the packages (and many are outdated), tons of issues and merge requests get ignored, had nowhere near the same level of ecosystem and integrations, and on aarch64 half the time I’ve tried to use it, some major dependency is broken so half the packages it does have don’t compile. I started out with Guix and even tried contributing, and these problems became way too annoying to deal with.

    • hello_hello [comrade/them]@hexbear.netOPMEnglish
      15·
      7 days ago

      Guix doesn’t have flakes because it has already standardized project management through channels (which are far more flexible and don’t break cross comp fundamentally)

      NixOS has embarassingly not resolved this issue in YEARS despite it being major pain point.

      tons of issues and merge requests get ignored

      Yes their team is far smaller and they have less resources so they have to choose which efforts to focus on first. Rebuild cycles are far longer because they don’t depend on unsustainable S3 compute. They also don’t abuse GitHub’s free CI pipeline and then have no roadmap for getting off of the platform (NixOS is not developed on NixOS)

      Its also unkind to look at a large issue tracker and imply that the maintainers are irresponsible. Im a NixOS contributor and let me tell you that the same sort of thing happens here (we have 5K PRs some of them stale for years that solve current issues or add new features)

      The fact is that nixpkgs (the largest Nix consumer) does not use flakes because it isnt usable for them. Guix has no such issue.

      and on aarch64 half the time I’ve tried to use it, some major dependency is broken so half the packages it does have don’t compile

      Contributions welcome. Also Aarch64 support is a second tier and Guix has always only advertised x86_64 because they literally don’t have the same amount of resources or volunteers. They have two volunteer run CI farms that use Guix vs AWS from Nix (I mean no wonder NixOS are corporate lackeys)

      At least they don’t depend on Zionist tech oligarchs (if Microsoft GitHub became unusable or untenable then NixOS grinds to a fucking HALT)

      I started out with Guix and even tried contributing, and these problems became way too annoying to deal with.

      Well I recommend looking at it again, they have switched to using Codeberg instead of a mailing list and there have been a lot of package improvements.

      • sudoer777@lemmy.mlEnglish
        6·
        7 days ago

        Guix doesn’t have flakes because it has already standardized project management through channels (which are far more flexible and don’t break cross comp fundamentally)

        So here’s my Nix system configurations organized in a Flake: https://git.sudoer777.dev/me/nix-system-configurations

        It does the following things:

        • Can use the same configurations for NixOS, home-manager, nix-darwin, nix-on-droid, etc.
        • Can import modules for home-manager/NixOS/etc (i.e. stylix, catccuppin) which automatically configures/unifies settings. Or ones (i.e. Niri, impermanence) which adds new settings.
        • Can easily use Nix expressions (and reuse them) to configure most of my programs.
        • Can add other flakes without having to add all of its dependencies
        • Can separate everything into different files.
        • Can export stuff for my flake and import it into other flakes. Can add configuration options so other flakes can modify the configuration.
        • Can import the same Flake twice but on different branches (i.e. if nixpkgs fucks up a package I can use a previous version or the master branch which might have the latest one that isn’t in unstable yet)
        • Can easily wrap programs or create new ones that apply configurations for the CLI environment (i.e. my library that wraps Helix and has options to enable programming languages which automatically sets up the language servers, grammar checking, and linting: https://git.sudoer777.dev/me/nix-flake-base)

        There aren’t many resources for Guix/Guile, and I’m having trouble figuring out how I can do the same thing there. This was as far as I got; I couldn’t find a way to cleanly import other projects like I can with Flakes, and even just for the lockfile I had to implement it manually (look at older commits since I have been deleting stuff as I’ve migrated it to Nix): https://git.sudoer777.dev/me/guix-home-laptop

        Yes their team is far smaller and they have less resources so they have to choose which efforts to focus on first.

        That is a big problem when it involves the most important piece of software that makes your computer functional and you build all of your workflows around.

        Its also unkind to look at a large issue tracker and imply that the maintainers are irresponsible.

        Contributions welcome.

        I tried packaging Typst for them (the IRC/mailing list was barely helpful so I had to match it as close to the docs as I could) and it took them literally a year to respond (rejected and it being ignored for this long doesn’t exactly feel “welcoming”). For bug reports (including ones making the tool completely unusable), I don’t think I ever got a response either. For the biggest one, I eventually found where the problem was after a ton of hunting around and finding a single person on some obscure place with a similar problem (related to 16k page sizes), I think I updated the issue with that information, I’m not sure where it’s at now.

        Compare with Nixpkgs, I have submitted update requests for multiple packages, and I’ve always gotten a response within 12 hours, and they have always gotten resolved in a few weeks at most, and that’s with me not doing anything. I’ve never needed to submit bugs surrounding the tool usability on aarch64 because it’s never had problems (I use Lix).

        Admittedly Typst is very complex to package, but so is everything else that isn’t packaged, and the project needs to have a better way for people to contribute if it wants to grow.

        Also although I would want to contribute more, I don’t have time to package like 50 different things, and if I did, I’m not sure why I should focus on Guix over something more interesting like a new kernel with significant security improvements (i.e. Genode).

        They have two volunteer run CI farms that use Guix

        I forgot to mention that their web servers keep blocking my IP for some reason so I have a hard time accessing them.

        they have switched to using Codeberg instead of a mailing list and there have been a lot of package improvements.

        That sounds like a good thing. Maybe things have improved since I last used it.