13 ms·

I love nix. I have also wasted far too much time trying to write my own expressions when just typing “brew install ___” would have let my get back to work. My

I love nix. I have also wasted far too much time trying to write my own expressions when just typing “brew install ___” would have let my get back to work. My biggest issue with homebrew is you’re always at head and you always upgrade the world. This is not good when you want repeatable things to happen. My second biggest issue with nix is you can pin things, but it’s pinned to some obtuse hash of the world. I build embedded code and I just want my toolchains to work perfectly, including avoiding the weird cmake bug in >3.25 that keeps dropping —std=20 from my arguments and then failing to build my “modern” c++ code. The amount of work this takes is too damn high with both brew and nix. Previously, I worked on and delivered a developer command line Swiss Army knife type tool, you have probably seen them. They do everything from build, docker, package, test, submit code, tail logs, etc. These have a ton of dependencies, and when you support Macs you end up using homebrew. Your install can then be broken by someone brew installing something mundane in their own machine. Not good. I tried to use nix for this, but packaging coverage wasn’t enough so I ended up wasting time packaging my own dependencies. Not good. I ended up putting a parallel brew repo up in my private git repo, then using a hidden brew that wasn’t on the user’s regular path to install the tools I needed at the right versions, and only upgrade them after I’d confirmed they worked. Still a waste of time and space but at least it didn’t suck up weeks of my time. I’m back in a similar space. I’ve got a complex set of tooling I want to share the install with to my teammates so we don’t have random issues with it, and we’re on Mac, Linux, and Windows. I just want to pin to version numbers (and a bunch of it is python with version pinned requirements, installed by scripts that someone wrote who doesn’t use nix and expects a global imperative environment) so I’m back to hosting my own brew repo. This is really what nix should make trivial but to me it’s a leaky abstraction. I keep having to look under the hood and do my own work to make it function.

Izkata 3y ago
> I have also wasted far too much time trying to write my own expressions when just typing “brew install ___” would have let my get back to work. Part of why I still just use nix-env instead of doing it the "right" way - it provides that simple "just install it" interface.
wrs 3y ago
At some point is it easier to use Docker to maintain a stable runtime environment for the tools than to try to deal with three different native OS environments? That is, wrapping “docker run” with scripts so it looks like native commands. People do this to make a consistent “k8s toolbox”, for example.
- mikrl 3y ago
  I’ve been intrigued by Fedora Silverblue but never got round to trying it out, though I’m tired of potentially fighting with NVIDIA drivers whenever I update my kernel (linus_torvalds.mp4) Have you looked into it all? I think it uses flatpak and containerizaton to separate the base OS from everything else. Not sure if it would help with my driver issues though.
  - akvadrako 3y ago
    What you are looking for is UBlue, https://github.com/ublue-os/main https://github.com/ublue-os/main. It's a variant of Silverblue with Nvidia drivers built in.
    - markhahn 3y ago
      should have been called greenblue no?
- MarkMarine 3y ago
  The PITA to get a debugger working on a dev board over UART does not need docker added to the mix.
  - ktm5j 3y ago
    Don't you just need to mount the UART device file to the container using a `-v` volume flag? That doesn't seem like a big deal if your container saves you from doing the PITA setup part.
    - 3y ago
nurple 3y ago
Flakes help a lot with granular version pinning. It feels weird to have multiple nixpkgs at different commits as inputs, but it's not too bad if you imagine them each as a distinct flake repo for the version of package you need (and name them accordingly).

Izkata 3y ago

> I have also wasted far too much time trying to write my own expressions when just typing “brew install ___” would have let my get back to work. Part of why I still just use nix-env instead of doing it the "right" way - it provides that simple "just install it" interface.

wrs 3y ago

At some point is it easier to use Docker to maintain a stable runtime environment for the tools than to try to deal with three different native OS environments? That is, wrapping “docker run” with scripts so it looks like native commands. People do this to make a consistent “k8s toolbox”, for example.

mikrl 3y ago
I’ve been intrigued by Fedora Silverblue but never got round to trying it out, though I’m tired of potentially fighting with NVIDIA drivers whenever I update my kernel (linus_torvalds.mp4) Have you looked into it all? I think it uses flatpak and containerizaton to separate the base OS from everything else. Not sure if it would help with my driver issues though.
- akvadrako 3y ago
  What you are looking for is UBlue, https://github.com/ublue-os/main https://github.com/ublue-os/main. It's a variant of Silverblue with Nvidia drivers built in.
  - markhahn 3y ago
    should have been called greenblue no?
MarkMarine 3y ago
The PITA to get a debugger working on a dev board over UART does not need docker added to the mix.
- ktm5j 3y ago
  Don't you just need to mount the UART device file to the container using a `-v` volume flag? That doesn't seem like a big deal if your container saves you from doing the PITA setup part.
  - 3y ago

nurple 3y ago

Flakes help a lot with granular version pinning. It feels weird to have multiple nixpkgs at different commits as inputs, but it's not too bad if you imagine them each as a distinct flake repo for the version of package you need (and name them accordingly).