I for one am waiting for systemd homed.
As always with anything about systemd, it's impossible to know if it's satire without looking at the source code. Sometimes, not even then.
Home in Nix – dotfile management
31–37 of 37 posts
Re: Home in Nix – dotfile management
#32I tried out Nix recently, with the intention of using it to get declarative management of my user account. I discovered too late that Nix basically has no support for this. While NixOS has some very nice features for declarative setup, user environment management boils down to terminal commands for "install package X, remove package Y". The mentioned home-manager seems more of an awkward hack than a good solution in…
The mentioned home-manager is more of an awkward hack than a good solution in my view. Tt's not actually immutable, but just dumps down files into $HOME, That's actually not true. Each home-manager generation is immutable and in the Nix store. E.g., the last two generations on my MacBook: home-manager generations | head -n2 2019-12-23 12:05 : id 12 -> /nix/store/6rig5ip0swmnnfcvgm221n5lig3xsh18-home-manager-generatio…
> Now, 1.5 year later, I like Nix as a language. It's just a small, functional language.
If nixos used a different language (e.g. gluon), do you think you would have become more comfortable quicker?
Re: Home in Nix – dotfile management
#33My $HOME is a git repo for my dotfiles, with a .gitignore containing just "*". Simple, zero abstractions, no need for additional management.
Further, you can create a bare git repo and make $HOME it's working tree.
More details here [1].
Re: Home in Nix – dotfile management
#34Earlier quoted context omitted.
The mentioned home-manager is more of an awkward hack than a good solution in my view. Tt's not actually immutable, but just dumps down files into $HOME, That's actually not true. Each home-manager generation is immutable and in the Nix store. E.g., the last two generations on my MacBook: home-manager generations | head -n2 2019-12-23 12:05 : id 12 -> /nix/store/6rig5ip0swmnnfcvgm221n5lig3xsh18-home-manager-generatio…
> Now, 1.5 year later, I like Nix as a language. It's just a small, functional language. If nixos used a different language (e.g. gluon), do you think you would have become more comfortable quicker?
Nix as a language is tiny. If you know functional programming at all you won't have any trouble with it and can "learn" it in days if you put in the effort. NixOS isn't complicated because of the language.
Re: Home in Nix – dotfile management
#35My $HOME is a git repo for my dotfiles, with a .gitignore containing just "*". Simple, zero abstractions, no need for additional management.
funny enough, this technique is also described here : https://drewdevault.com/2019/12/30/dotfiles.html
Re: Home in Nix – dotfile management
#36Earlier quoted context omitted.
The mentioned home-manager is more of an awkward hack than a good solution in my view. Tt's not actually immutable, but just dumps down files into $HOME, That's actually not true. Each home-manager generation is immutable and in the Nix store. E.g., the last two generations on my MacBook: home-manager generations | head -n2 2019-12-23 12:05 : id 12 -> /nix/store/6rig5ip0swmnnfcvgm221n5lig3xsh18-home-manager-generatio…
> Now, 1.5 year later, I like Nix as a language. It's just a small, functional language. If nixos used a different language (e.g. gluon), do you think you would have become more comfortable quicker?
I don't know Gluon (from a quick glance, it looks similar to Haskell and ML). But I do not think it will help much. Nix is a small, lazy, functional language. Being a lazy functional language, it will be more difficult for people without a FP background. But laziness and purity provides a lot of benefits.
I think the problem is more about documentation and expectations:
- Nix only has a small number of builtins. A lot of useful functions are in nixpkgs. As a consequence, you often have to look in two places to find if there is an existing function that does what you want to do. Added to that, some functions are undocumented and can only be discovered through the REPL or by reading the relevant nixpkgs sources. Then some functions do have documentation, but the documentation is very terse, does not contain good examples, etc. I think things would be clearer if Nix had a documented standard library and nixpkgs would only be focused on providing package derivations and NixOS modules.
- Expectation-wise: I think a lot of people do not expect to have to learn a new language when starting to use a package manager and/or distribution. This leads to treating derivations akin to RPM spec files (which is what I did in the beginning), which becomes frustrating very quickly.
Disclaimer: I am by no means a Nix expert. These are my observations from learning Nix myself since last year.
Re: Home in Nix – dotfile management
#37Earlier quoted context omitted.
> Now, 1.5 year later, I like Nix as a language. It's just a small, functional language. If nixos used a different language (e.g. gluon), do you think you would have become more comfortable quicker?
I don't know Gluon (from a quick glance, it looks similar to Haskell and ML). But I do not think it will help much. Nix is a small, lazy, functional language. Being a lazy functional language, it will be more difficult for people without a FP background. But laziness and purity provides a lot of benefits. I think the problem is more about documentation and expectations: - Nix only has a small number of builtins. A lo…
> Nix is a small, lazy, functional language. Being a lazy functional language, it will be more difficult for people without a FP background. But laziness and purity provides a lot of benefits.
Many functional languages have lazy evaluation, and they do provide benefits. However, unfortunately, this concept has leaked into other areas of programming. In particular, many database ORMs use lazy evaluation to pull data. In one step, you create a database query, then pass that off to another function or class. Then, when it's off in another package and evaluated the query is made.
The main problem with lazy evaluation of database queries is that it treats a database evaluation like normal code, even though under the hood there may be network access, caching, and if you're not careful duplicative database pulls.
Generally, there should be a rule in programming languages that when you make a network call, the programmer has clear visibility into when that is happening. Hiding it with fancy syntax is more of a negative than a positive.