Earlier quoted context omitted.
I do get the theoretical annoyance of how it’s technically not reproducible, but in practice most containers are pulled and not built from scratch. If you’re really concerned about that apt-get then besides a container registry you’re going to host a private package repository too, or install a versioned tarball from a public URL, but check the hash of whatever you’re downloading and put that hash in the dockerfile.…
The issue is it's why are you trying to be reproducible. The best use case is proving authenticity: that the source code became the binary code as written, but we're so far away from that that it's not realistic. My dream system would be CI which gives me a gigantic object graph and can sign the source code from the ground up for every single thing including the compiler, so when a change happens you can drill down t…
Nix – Death by a Thousand Cuts
321–330 of 336 posts
Re: Nix – Death by a Thousand Cuts
#322The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".
I think that's a bit reductive, but I get the intent. A lot of people see systemic problems in their development and turn to tools to reduce the cognitive load, busywork, or just otherwise automate a solution. For example "we always argue over formatting" -> use an automated formatter. That makes total sense as long as managing/interacting with the tool is less work, not just different work. With Nix I still think it…
Quickly skimmed through the Flox site and it looks like it’s based on Nix. The problem with the competitor https://www.jetify.com/devbox and most likely in Flox is that Nix makes trivial environment setup really easy but when you need something more complex it falls apart because the Nix packages are often unmaintained and simply broken.
Re: Nix – Death by a Thousand Cuts
#323The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".
Nix currently has the most packages of any distribution, see https://repology.org/ The model of having packages on Github with pull requests scales very well. Therefore, you could argue that people are getting things done with Nix.
How many of them actually work though? If you end up having to go fix upstream packages then having a tool manage your environment is not useful since you still have to understand the domain.
With Nix I usually ended up in a situation where I had to both figure out how to configure my environment _and_ fix the upstream Nix packages. At that point it’s just easier to stick to Homebrew and some custom shell scripts.
Re: Nix – Death by a Thousand Cuts
#324I'm relatively new to nix, and this cut close: > At this point NixOS has been around for 2 decades, but it still feels like it has not settled on good recommended workflows for incoming users. Yes. This was a major pain point when I was getting started. The IRC community has been helpful in this regard. I also really don't like that nixpkgs serves as both a lib and a package set. Be one! I don't want "special" inputs…
> good recommended workflows for incoming users Users of what exactly? Workflows for configuring a desktop to play Steam games is vastly different from workflows for managing a cattle fleet of enterprisey servers.
[deleted]
Re: Nix – Death by a Thousand Cuts
#325Earlier quoted context omitted.
To counterpoint this, I'm an happy nixos desktop user. It's not perfect, but still vastly better than a non declarative distro for my taste.
Seconded. I switched to NixOS a year ago after an apt install broke my system one too many times, and so far I've been very very happy with it. I've broken things, but being able to roll back to an exact duplicate of the previous state has been a lifesaver. I can't imagine wanting to go back to repairing broken apt installs.
This is very curious to me as someone who has used Debian based distros almost exclusively for essentially 20+ years (earlier on was mostly Ubuntu, now just vanilla Debian ever since the whole Snap situation) on all of my servers, VMs, containers, and various desktops. To my memory I’ve never had to fix a system due to a broken apt install, certainly not enough times to be so frustrated as to move to another distribution. On top of that, nowadays I have things configured so a new BTRFS snapshot is created on any apt install/upgrade commands so I can just rollback to the previous snapshot if I did run into any issues, which I haven’t ever needed to do. Though that seems to solve the same issue that rolling back in nix does?
I absolutely believe you’ve had this problem, but I’m struggling to understand the issue you’re describing. How exactly is an apt install breaking your whole system? I don’t even really understand how an apt install could break an entire system rather than just failing to install the package. Did you mean to say dist-upgrade or something? Are you using Debian or a downstream distribution? If Debian, are you running Sid or is this happening on unstable/stable? I’m just really curious about this situation.
Re: Nix – Death by a Thousand Cuts
#326I'm a NixOS user and contributor. This post is fair. Nix is very flexible, and it hasn't yet stabilised on a firm set of recommendations for a happy path. Going on a whim: * Use nixos-unstable. It's defacto stable, and gets much more attention than nixos-stable. * Use flakes. * Don't use multiple versions of nixpkgs. In the rare case a package is failing to build, then raise an issue, or wait, or rollback. * On NixOS…
This sounds like a great idea! How do I do it? (The unstable stuff and using modern techniques? How do I even know what's modern?)
I currently have a spare laptop lying around. I popped in the latest NixOS ISO and just gave it a spin. Some things I noticed:
- The installer only allows to install on ext4 unless you manually partition the disk? I thought it was 2025, not 2005.
- Is there no way to search for packages without a browser?
- I found boot.grub.* and boot.systemd-boot.* - what if I want to use refind? What about Limine?
- How do I know if any given program goes into programs.programname.enable = true or into environment.systemPackages = with pkgs; [ programname ]?
- Why is the ISO furnishing me with a configuration.nix when everyone says to use flakes instead of that? How do I switch?
I'd preferably be able to answer those questions without reading a 300 page handbook. I've been using a lot of Linux distros over the last 30 years and the above questions have usually bean answerable on a headless system with the supplied documentation. I understand that Nix is a paradigm shift compared to "classic" distros, but that only puts the onus more in Nix to be discoverable.
Re: Nix – Death by a Thousand Cuts
#327Earlier quoted context omitted.
I think that's a bit reductive, but I get the intent. A lot of people see systemic problems in their development and turn to tools to reduce the cognitive load, busywork, or just otherwise automate a solution. For example "we always argue over formatting" -> use an automated formatter. That makes total sense as long as managing/interacting with the tool is less work, not just different work. With Nix I still think it…
Quickly skimmed through the Flox site and it looks like it’s based on Nix. The problem with the competitor https://www.jetify.com/devbox and most likely in Flox is that Nix makes trivial environment setup really easy but when you need something more complex it falls apart because the Nix packages are often unmaintained and simply broken.
It uses Nix under the hood.
I would argue that Nix does not make trivial environment setup easy. One of the reasons I love Flox for my own development is that I can just "flox install" packages. That doesn’t really exist for project-specific packages with Nix ("nix profile install" exists, but that installs globally). I would say give Flox a try and see if you actually run into issues. If you do, we're pretty good about fixing them as they come up.
It has also not been my experience at all that Nix packages are "often unmaintained and simply broken." I use Nix every day for work, and I use it to configure all of my personal machines (on both macOS NixOS). Can't say that's ever really been a problem for me.
Re: Nix – Death by a Thousand Cuts
#328Earlier quoted context omitted.
I think that's a bit reductive, but I get the intent. A lot of people see systemic problems in their development and turn to tools to reduce the cognitive load, busywork, or just otherwise automate a solution. For example "we always argue over formatting" -> use an automated formatter. That makes total sense as long as managing/interacting with the tool is less work, not just different work. With Nix I still think it…
I just started using Flox last weekend and so far it has been quite nice experience. There are two things I don't like, though: 1) The Homebrew package is a cask that installs also Nix. While I like Flox, I don't want my systems to be married to it. Yes, I know about install option with "generic Nix", but I'm using Homebrew with Brewfile both in macOS and Linux, and I would like the Homebrew package to be just Flox.…
There’s a small number of us working on the docs and we actually just did a pass over them before the holidays to evaluate how well they help users get things done. We took some action items from that that we’ll be working in over the next few months.
That said, the repo is public[1] and if there’s specific things you’d like to see or would find helpful you could open an issue. That would be really helpful, but there’s obviously no obligation to do so.
Re: Nix – Death by a Thousand Cuts
#329Earlier quoted context omitted.
What's been your strategy for doing this
Well the short answer is: I defined the workflow/process for our team, everyone bought in, and new people don't really have a choice but to follow along. The longer answer is, earlier in my career I ended up spending a not-insignificant amount of time helping people debug things, and about 70% of the time the issue was their local build environment. Everyone did it differently and it was very messy. I only made a few…
> Your local folder structure must mirror exactly the structure in our central repo
Do you use a monorepo at work, or do you have like a repo for a 'local dev environment' or something like that?
Re: Nix – Death by a Thousand Cuts
#330Earlier quoted context omitted.
Quickly skimmed through the Flox site and it looks like it’s based on Nix. The problem with the competitor https://www.jetify.com/devbox and most likely in Flox is that Nix makes trivial environment setup really easy but when you need something more complex it falls apart because the Nix packages are often unmaintained and simply broken.
It uses Nix under the hood. I would argue that Nix does not make trivial environment setup easy. One of the reasons I love Flox for my own development is that I can just "flox install" packages. That doesn’t really exist for project-specific packages with Nix ("nix profile install" exists, but that installs globally). I would say give Flox a try and see if you actually run into issues. If you do, we're pretty good ab…
In my case I couldn’t get Rust working and ran into strange compilation issues with linker errors with the MacOS standard libraries. Tried installing them from Nix which fixed some problems but caused other ones.
Everything just worked outside of the Nix environment so ended up dropping it.