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.

  • pongo1231 [none/use any]@hexbear.netEnglish
    25·
    7 days ago

    Welp if Guix is really the way to go I sincerely hope someone smart cobbles together a Nix -> Scheme translation layer or something. Would be an extreme shame to lose the entire ecosystem of nixpkgs & all kinds of random projects providing flakes to fascists.

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

      Both Guix and Nix evaluate derivations which are a standardized format. Guix just doesn’t evaluate Nix derivations because it doesn’t implement a Nix DSL interpreter and it doesn’t use the same package repository (nixpkgs).

      There are a lot of benefits to using scheme and you don’t have to be an expert in Scheme to create packages (I wasn’t when I started out and anyone who claims to be an expert in either Nix or Scheme gets laughed out the room).

      comparison

      This is the hello world package in Guix

      (use-modules (guix packages)
             (guix download)
             (guix build-system gnu)
             (guix licenses))

(define-public hello
  (package
    (name "hello")
    (version "2.12.2")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "1aqq1379syjckf0wdn9vs6wfbapnj9zfikhiykf29k4jq9nrk6js"))))
    (build-system gnu-build-system)
    (synopsis "Example GNU package")
    (description
     "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

      This is the hello world package in Nix

      {
  callPackage,
  lib,
  stdenv,
  fetchurl,
  nixos,
  testers,
  versionCheckHook,
  hello,
}:

stdenv.mkDerivation (finalAttrs: {
  pname = "hello";
  version = "2.12.2";

  src = fetchurl {
    url = "mirror://gnu/hello/hello-$%7BfinalAttrs.version%7D.tar.gz";
    hash = "sha256-WpqZbcKSzCTc9BHO6H6S9qrluNE72caBm0x6nc4IGKs=";
  };

  # The GNU Hello `configure` script detects how to link libiconv but fails to actually make use of that.
  # Unfortunately, this cannot be a patch to `Makefile.am` because `autoreconfHook` causes a gettext
  # infrastructure mismatch error when trying to build `hello`.
  env = lib.optionalAttrs stdenv.hostPlatform.isDarwin {
    NIX_LDFLAGS = "-liconv";
  };

  doCheck = true;

  doInstallCheck = true;
  nativeInstallCheckInputs = [
    versionCheckHook
  ];

  # Give hello some install checks for testing purpose.
  postInstallCheck = ''
    stat "''${!outputBin}/bin/${finalAttrs.meta.mainProgram}"
  '';

  passthru.tests = {
    version = testers.testVersion { package = hello; };
  };

  passthru.tests.run = callPackage ./test.nix { hello = finalAttrs.finalPackage; };

  meta = {
    description = "Program that produces a familiar, friendly greeting";
    longDescription = ''
      GNU Hello is a program that prints "Hello, world!" when you run it.
      It is fully customizable.
    '';
    homepage = "https://www.gnu.org/software/hello/manual/";
    changelog = "https://git.savannah.gnu.org/cgit/hello.git/plain/NEWS?h=v%24%7BfinalAttrs.version%7D";
    license = lib.licenses.gpl3Plus;
    maintainers = with lib.maintainers; [ stv0g ];
    mainProgram = "hello";
    platforms = lib.platforms.all;
    identifiers.cpeParts.vendor = "gnu";
  };
})

      A lot of the same skills and concepts transfer over, so if you’re comfortable with Nix you don’t have to lose all your skills and start over. I personally find the Guix package definition a lot more understandable than the Nix one.

  • loathsome dongeater@lemmygrad.mlEnglish
    15·
    7 days ago

    From what I have seen this corporation called Determinate Systems was always at the front and centre of Nix itself. I don’t know if it is because of hard work or marketing. The most popular installer for NixOS is built by them and they slowly changed its defaults to using their proprietary services (they have a proprietary daemon and that flakehub bullshit).

    I am hoping Lix can be Nix for normal people.

    Side note: I found Nix very confusing the one time I tried it and the determinate bullshit was definitely one of the lowest points.

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

      Determinate Systems have been using the Nix trademark to advertise to potential enterprise clients. Unlike Lix which distinguishes itself entirely from cppnix. DT Nix is marked as the “objective” Nix and makes breaking changes from cppnix that not everyone agrees with (going all in on flakes, lazy trees breaking determinism)

      Lix has repurposed the detsys installer for themselves so detsys can go fuck itself.

      The NixOS foundation board is one guy. The SC (steering committee) is a libshit democracy where most volunteers don’t care or want to avoid (SC is a rubber stamp veto or pass rather than a coordinator). Nixpkgs has its own technical team and exists as an entity all into itself.

      Detsys should be banned from the community but all the NixOS people are detsys people so fascist hellhole here we go!

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