111–120 of 336 posts
If you you are cut from the internet or end up with a very slow connection you can end up totally blocked. As a minor configuration change can require you to download a lot of data.
I also found out there is not much you can do to protect you from this.
Earlier quoted context omitted.
That is not why neither Bazel or Buck was created.
It's not? I recall reading that coping with a variety of languages was one of the main motivations, but do correct me if I'm wrong and you have a citation.
I found getting started quite easy. But then you discover there are like 4-5 different ways to manage packages and not much consensus in the community on what the correct way is. That was kinda discouraging
0. If you're new and on the fence about using flakes, go ahead. (If you know you don't want them, fine.)
1. Prefer declarative installation to imperative installation.
2. If a module exists, prefer using it to configure a package to just adding that package to a list of installed packages.
3. 'Native' packages are better than 'alien' packages.
3a. Packaged for Nix is better than managed externally. (I.e., prefer that programs live in the Nix store rather than Flatpak or Homebrew.)
3b. Prefer packages built from source to packages carved out of foreign binaries.
4. Prefer to just rely on Nixpkgs for things that are already in Nixpkgs; only bother with other sources of Nix code (likely distributed as 'flakes') if you know you need them.
5. Prefer smaller installation scopes to larger installation scopes— when installing a package, go with the first of these that will work: per-session (i.e., ephemeral dev env) -> per-user -> system-wide).
6. Prefer Nixlang to not-Nixlang (YAML, JSON, TOML, whatever).
7. If you're not sure, go for it.
If you follow these guidelines you'll make reasonable choices and likely have a decent time. The most important rule is #1, so once you know your OS, your task is to make sure you have at least one module system available to you. (On NixOS, that's NixOS and optionally Home Manager. On other Linux, that's Home Manager. On macOS, that's Home Manager and/or Nix-Darwin.)
After that, everything can find its natural place according to the constraints above. If you need to break or relax a rule, it'll be obvious.
Inevitably you'll end up with things installed in a handful of ways and places, but you'll know why each thing belongs where it is, and you can leave yourself a note with a '#' character anywhere that you think a reminder might be useful. :)
Earlier quoted context omitted.
> I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason. My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. They’re just an interface for a decentralised module system. You can use them, they’re feature-complete, and they don’t align with nixpkgs: it doesn’t make sense for individua…
> My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Flakes aren't default due to political reasons.
Earlier quoted context omitted.
For those pesky random executables there's a couple of escape hatches -- buildFHSenv and nix-ld. This is also predicated on good provenance of the executables in question. One should probably not even ldd sketchy binaries: https://jmmv.dev/2023/07/ldd-untrusted-binaries.html
Even proper packaging is far easier compared to other package managers. Typical distros push users away from packaging their own software, so users end up relying on ad-hoc solutions instead. Nix instead makes packaging easier by having proper tools to abstract away the nitty gritty details. For random binaries, autoPatchelfHook works miracles.
Earlier quoted context omitted.
> I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason. My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. They’re just an interface for a decentralised module system. You can use them, they’re feature-complete, and they don’t align with nixpkgs: it doesn’t make sense for individua…
> My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Flakes aren't default due to political reasons.
Can you share some examples of such problems?
I've been using nixOS on my laptop for over a year now and I still don't have an answer for 'my version of firefox/darktable has a bug in it, but I can't update it without upgrading the entire rest of all the software installed on my machine.' I keep thinking there has to be a way around this, but it doesn't seem like there is one that's clean and not hacky / brittle. Other than that I love it, but that's a pretty hu…
The problem really stems from how tightly entangled packages are to the nixpkgs source tree. Nix offers the most foundationally modular system possible, and it organizes its packages in a monolithic source tree! This means that despite installed packages being totally isolated in the /nix/store/, the package source (what Nix calls a "derivation") is semantically tied to whatever specific dependency version was implemented in the contemporary nixpkgs source. If you want to provide users more than one version of a package inside the same source tree, you must put the version in the name, like SDL2 or python3.11.
I started this GitHub issue a long time ago: https://github.com/NixOS/nixpkgs/issues/93327. Somewhere buried inside may lie the answer to your question. Either way, I have mostly given up on wrapping my head around the current ecosystem of half-baked solutions to this mess; despite still actively using NixOS in ignorance.
Earlier quoted context omitted.
It's not? I recall reading that coping with a variety of languages was one of the main motivations, but do correct me if I'm wrong and you have a citation.
They do hermetic builds so that it is viable at large scale via granular caching. They were made to make that work at those scales, with pretty much zero consideration for any external package managers or anything like that
The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too hard to figure out. The documentation is terse and the community answers are often not enlightening.
A big complaint of mine is that the builds should be reproducible, but I find I sometimes need to run `nixos-rebuild switch` several times to get a successful build. The error messages mysteriously resolve themselves. For me, this doesn't pass the bar for being considered reproducible.
Don't get me started on using an NVIDIA graphics card also. Granted, part of my difficulties is that I was running Wayland, which doesn't have the best NVIDIA support, but I felt like I was just doing an exhaustive search through the potential config settings to see what worked. Ultimately, I found just the right combination of settings to get everything working buttery smooth. I ripped out the NVIDIA card and put an AMD card in.
Earlier quoted context omitted.
They do hermetic builds so that it is viable at large scale via granular caching. They were made to make that work at those scales, with pretty much zero consideration for any external package managers or anything like that
Hm, I did some searching. Bazel's FAQ mentions multi-language support prominently, but only suggests speed and reliability as the initial motivations. I'll edit my post.