51–60 of 361 posts
As a NixOS user, I like this article a lot. But one thing stood out to me: > It also means that it's impossible to statically know what other packages a given package might depend on. Currently, the way this is implemented is essentially grepping a package for /nix/store/ to try to figure out what the dependencies are, which is obviously... not great. I'm not sure what the author is talking about here. He says it's i…
> But at the same time, I can patch the Python interpreter and then have some software running on my system actually use the patched version, since all of this stuff is configured through the same configuration system. If I want to do that, then I have to rebuild the entire system so as to use my patched version. This is because the NixOS "dependencies" are basically expressed as hashes of binaries. That is for me th…
This can be avoided my not overriding the package attribute, but instead creating a new one and then only using that as-needed. What you describe as a deal-killer is just purity and safety. Updating a build input gives no guarantee that the build output will be the same or even work. Sure, as smart humans we can say “I know this change does not impact X, so it’s fine”, but NixOS is based partly on the claim that we d…
It's not really "pure" since you are packaging software with side-effects to begin with. Even if you use the same text bit by bit it's also no guarantee that the output will be the same or that even it will work. You are still relying on some human claiming that it will do.
So the advantage is not really that big in practice, and the disadvantage means rebuilding the world on every low-level package change. Even Gentoo fares better in that regard.
And yes, I am aware that the deal-killer is at the core of these approaches, which is why I don't take them seriously.
"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…
It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.
> I'm going to keep using it, since I can't stand anything else after having a taste of NixOS This is how I feel about NixOS. I like what it gives me but I don't really like much else about it. Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure. Off the top of my head there are a couple of things I've hit a dead end on recently: - Packaging a Flutter desktop app…
Here is my attempt at solving this problem: https://github.com/CyberShadow/aconfmgr
"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…
It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.
1: Best resource I’ve found is this: https://teu5us.github.io/nix-lib.html
2: The status of lang2nix: https://discourse.nixos.org/t/status-of-lang2nix-approaches/...
- How big is Guix on GNU? Does it throw wrenches in your way if you do anything "unfree"? How easy is it to install the nvidia-drivers? - How is the package ecosystem? 20.000 official packages seems a little low? Are there community packages? How easy it is to create your own packages? Why is the Neovim package only at version 4.4 [1]? Isn't version 5 officially released? - How good is the documentation? - Is there a project roadmap? Are there any issues preventing adoption?
NixOS and Guix are nice! Guix folks are doing some wonderful work off late. I have used NixOS for a while. But for casual desktop GNU/Linux users, it seem like solving a problem that doesn't exist. Have been using Debian on all my computers since 1998. Unless you are using Debian unstable and updating it daily, I hardly hit any breakage. Servers and deployments is another story.
How does Guix compare to Nix? It seems like by using a scheme-based DSL instead of an ad-hoc configuration language, it solves one of the main complaints the author has about Nix.
Earlier quoted context omitted.
> I haven't found a clear list of packages that were going to be updated. The ideal here, IMO, is to use flakes and the nix-diff to compare the build before switching. E.g. nixos-rebuild --flake '.#myhost' build nix-diff /nix/var/nix/profiles/system result sudo nixos-rebuild --flake '.#myhost' switch Could do the same without flakes after the fact by running nix-diff on different generations in /nix/var/nix/profiles…
There's nothing there that needs flakes (an experimental feature which people should not enable without understanding the implications). You could build a system derivation and run a diff against /run/current-system on it. For what it's worth, nix-diff has very verbose output (it literally diffs everything that is different in the inputs & outputs). A slightly nicer way to diff systems is nvd[0] (example output[1]) w…
Haven't flakes been non-experimental since 2.4?
"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…
We already had JSON plus functions. We called it 'JavaScript' :)
Earlier quoted context omitted.
> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries. Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)
> Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.) Out of curiosity, are you talking about Typescript? Not really a framework, but I can't really think of a framework that 'won' in this sense for JS, and also compiles to JS. On the front-end there's Svelte, which is actually compiled with Javascript, and R…
But also things like Vue do their own compiling step too.