dd_ · HackerTrans

3 yıl öncediscuss

I think C++ really just has bad defaults for many of its features. It's understandable given the age of the language, but I wish compiler developers would agree on a set of new default attributes for various language features and make a flag to enable them. That way, older style code can still compile but newer code isn't cursed with explicit attribute hell.

dd_

3 yıl öncediscuss

You're not wrong overall, but your example is. In the build environment, the current time is set to the epoch which removes that variability.

An upcoming feature of nix is content addressed builds which use the output hashes to determine the store path. This should make it much more transparent which builds are reproducible and which are not.

dd_

4 yıl öncediscuss

Well they are - but there are a couple of things blocking it from becoming the default. I think the main thing is this PR: https://github.com/NixOS/nix/pull/6530 - Eelco Dolstra gave a talk on this recently as well if you wanna know more: https://www.youtube.com/watch?v=JE-vLFMTXxM

Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/NixOS/nix/pull/6583

dd_

4 yıl öncediscuss

I don't know if packages should necessarily be moved out of nixpkgs since I doubt most people who don't use nix would want to maintain flake.nix in their project, nor would users want to have 30+ flakes in their inputs. However, I can see a good case for separating the package definitions from the nixos modules and the stdlib (mkDerivation, stdenv, etc). Maybe there could be a flake for each.

As for keeping up with PRs and other responsibilities, that seems to be one of the stated goals of the this new Nix Team. I guess we'll see how they intend to handle this soon.

dd_

4 yıl öncediscuss

A few of these problems are fixed with flakes - namely the dramatically improved composability. It becomes much simpler to understand how to use something when you are able to work on it in isolation. With the previous mono-repo nixpkgs assumption, you were basically required to not only learn nix-lang, but also nixpkgs and the nixpkgs workflow making it much harder to grasp the fundamentals.

With flakes, it is now significantly easier to create an standalone package or module for your specific needs since you import it just like nixpkgs. It also means that software doesn't have to be part of nixpkgs to be usable on the system - if a git repo has a flake it's just a matter of adding it as an input. Flakes represent such a massive improvement to the way that you interact with nix, I sincerely hope they become the default here soon. In the meantime, it is well worth your effort to learn them even if they aren't 'required' yet.

Unfortunately all of this is contingent on being able to grok the language in the first place which is where the documentation really falters. The nix pills talk about the basics of the language but it is very difficult to make anything useful without importing some libraries (i.e. nixpkgs) - and these libraries are not very well documented. I am aware of a documentation team being formed to help address this but it still remains the number one issue with nix, especially for newcomers. The unfortunate thing is that there are so many moving parts that it will take a considerable effort to explain the entire ecosystem without being overwhelming but still providing enough intuition for newcomers to get things done with Nix.

If anyone is interested, a recent SoN talk was given about efforts to improve the documentation. It touches on many of the things I bought up here: https://www.youtube.com/watch?v=WFRQvkfPoDI

dd_

4 yıl öncediscuss

As someone who has been using NixOS for a couple of years now, I really want to say how appreciative I am of everybody for making noticeable improvements to the system on a somewhat regular basis. The nix command keeps on adding great new features like flake templates and bundling as well as just being more user friendly (error messages, actionable hints, etc.) Additionally, tools like nix-ld [1] make nix more usable than ever with software from external sources. Things just keep on getting better for NixOS users!

Despite the reputation, I feel that NixOS or some derivative of it has the power to become the best distribution for non-technical users in the long run. What NixOS has done is effectively built an interface to every component of a modern Linux system, all that needs to be built is a user application to take advantage of it. Of course, there still needs be some improvements in Nix itself for it to blossom into its final form, but I really see a path to greatness here.

I have often thought about creating a simple unified Win2K-esq or BeOS-like X11 WM/DE specifically for NixOS but unfortunately I lack the time/motivation.

[1] https://github.com/Mic92/nix-ld

comments