• 1 Post
  • 144 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle










  • Separate your system and user lists. Use home-manager for example for your user packages. I think separating those configs is the official recommendation.

    As for the rest, I’m using nix on MX because of declarative package management. Screw going back to imperative and having to remember what packages to install. If it’s something I use often it goes on a list, if I don’t nix shell comes to the rescue.

    I’d rather mess around with dev envs for nix than distrobox.








  • I’m going to have to come back to Nix/NixOS in a bit.

    Use nix + home-manager first for sure. It’s far easier, and you can slowly get into it while making a list of bleeding edge packages.

    I’ll probably wait until the official docs catch up as it appears that they are quite a bit behind

    Skip them altogether when you’re starting out. I gave up on trying nix the first few times due to how bad they are. zero-to-nix.com is better for learning the basics of nix.

    That and I’m not sure how I feel about a DSL for package management. I’d much rather use JSON or YAML, or even INI or TOML.

    The closest you can get is home-manager with a list of packages in a json-like format. It’s really not practical to develop a declarative system without a programming language. A basic example would be variables, more advanced would be to write a wrapper that modifies the package so it automatically runs the required cli commands to use your dediated gpu and nixGL with specific packages (nvidia-run-mx nixVulkanNvidia-525.147.05 obs for example).

    It’s sort of like IaC where you’ve got terraform (dsl), pulumi (various languages), and cloudformation (json/yaml). Can you guess which one is universally despised?

    Maybe if I were a LISP or Haskell guy.

    Then you’d use guix and a dsl made within an actual programming language (much better approach IMO).