My problem with NixOS is the second you try to go "outside the guardrails", the difficulty increases 100x

ivanjermakov 9 hours ago | parent | next [-]

Kind of the same for docker? Plopping a docker compose file and setting up few environment vars vs writing dockerfiles from scratch.

▲

cromka 8 hours ago | parent [-]

Not really. No. You can easily checkout repo containing the Dockerfile, add a Dockerfile override, change most of the stuff while maintaining the original Dockerfile instact and the ability to use git to update it. Then you change one line in docker-compose.yaml (or override it if it's also hosted by the repo) and build the container locally. Can't imagine easier way to modify existing docker images, I do this a lot with my self-hosted services.

▲

Ambroisie 7 hours ago | parent [-]

I'll be honest, that does not sound "easy".

It is straightforward, but so is the NixOS module system, and I could describe writing a custom module the same way you described custom Docker images.

	▲	jerf an hour ago \| parent \| next [-]
		It isn't the absolutely easiest process. But it works on Ubuntu, it works on Debian, it works on Mac, it works on Windows, it works on a lot of things other than a Nix install. And I have to know Docker for work anyhow. I don't have to know Nix for anything else. You can't win on "it's net easier in Nix" than anywhere else, and a lot of us are pretty used to "it's just one line" and know exactly what that means when that one line isn't quite what we need or want. Maybe it easier after a rather large up-front investment into Nix, but I've got dozens of technologies asking me for large up-front investments.
	▲	Xraider72 3 hours ago \| parent \| prev \| next [-]
		This is a familiarity problem. I've never used NixOS and all your posts telling me how simple it is sounds like super daunting challenges to me versus just updating a Dockerfile or a one liner in compose that I am already familiar with, I suspect its the inverse for you.
	▲	maccard 4 hours ago \| parent \| prev [-]
		If that’s not easy I don’t know what is.

▲

lilyball 5 hours ago | parent | prev [-]

Is it? Why? If a NixOS module doesn’t support what you need, you can just write your own module, and the module system lets you disable existing modules if you need to. Doing anything custom this way still feels easier than doing it in an imperative world.

▲

maccard 4 hours ago | parent | next [-]

> you can just write your own module, and the module system lets you disable existing modules if you need to

That sounds about 100x more difficult to me

▲

Scandiravian 3 hours ago | parent [-]

I can see your point that it can be daunting to have all the pain upfront. When I was using Ubuntu on my servers it was super simple to get things running

The problem was when I had to change some obscure .ini file in /etc for a dependency to something new I was setting up. Three days later I'd realise something unrelated had stopped working and then had to figure out which change in the last many days caused this

For me this is at least 100x more difficult than writing a Nix module, because I'm simply not good at documenting my changes in parallel with making them

For others this might not be a problem, so then an imperative solution might be the best choice

Having used Nix and NixOS for the past 6-7 years, I honestly can't imagine myself using anything than declarative configuration again - but again, it's just a good fit for me and how my mind works

▲

onionisafruit 3 hours ago | parent [-]

In the NixOS scenario you described, what keeps you from finding an unrelated thing stopped working three days later and having to find what changed?

I’m asking because you spoke to me when you said “because I'm simply not good at documenting my changes in parallel with making them”, and I want to understand if NixOS is something I should look into. There are all kinds of things like immich that I don’t use because I don’t want the personal tech debt of maintaining them.

▲

Scandiravian 2 hours ago | parent | next [-]

I think the sibling answer by oasisaimlessly is really good. I'd supplement it by saying that because you can have the entire configuration in a git repo, you can see what you've changed at what point in time

I'm the beginning I was doing one change, writing that change down in some log, then doing another change (this I'll mess up in about five minutes)

Now I'm creating a new commit, writing a description for it to help myself remember what I'm doing and then changing the Nix code. I can then review everything I've changed on the system by doing a simple diff. If something breaks I can look at my commit history and see every change I've ever made

It does still have some overhead in terms of keeping a clean commut history. I occasionally get distracted by other issues while working and I'll have to split the changes into two different commits, but I can do that after I've checked everything works, so it becomes a step at the end where I can focus fully on it instead of yet another thing I need to keep track of mentally

	▲	Scandiravian 2 hours ago \| parent [-]
		I just realised I didn't answer the first question about what keeps me from discovering the issues earlier The quick answer is complexity and the amount of energy I have, since I'm mostly working on my homelab after a full work day Some things also don't run that often or I don't check up on them for some time. Like hardware acceleration for my jellyfin instance stopped working at some point because I was messing around with OpenCL and I messed up something with the Mesa drivers. Didn't discover it until I noticed the fans going ham due to the added workload

▲

oasisaimlessly 2 hours ago | parent | prev [-]

Not OP, and not a very experienced with NixOS (I just use Nix for building containers), but roughly speaking:

* With NixOS, you define the configuration for the entire system in one or a couple .nix files that import each other.

* You can very easily put these .nix files under version control and follow a convention of never leaving the system in a state where you have uncommitted changes.

* See the NixOS/infra repo for an example of managing multiple machines' configurations in a single repo: https://github.com/NixOS/infra/blob/6fecd0f4442ca78ac2e4102c...

▲

jbstack 3 hours ago | parent | prev [-]

"Just" write your own module?

Have you seen how bad the Nix documentation is and how challenging Nix (the language) is? Not to mention that you have to learn Yet Another Language just for this corner case, which you will not use for anything else. At least Guix uses a lisp variant so that some of the skills you gain are transferable (e.g. to Emacs, or even to a GP language like Common Lisp or Racket).

Don't get me wrong, I love the concept of Nix and the way it handles dependency management and declarative configuration. But I don't think we can pretend that it's easy.

	▲	femiagbabiaka 2 hours ago \| parent \| next [-]
		The documentation is not great (especially since it tends to document nix-the-language and not the conventions actually used in Nixpkgs), but there are very few languages on earth with more examples of modules than Nix.
	▲	fijiaarone 3 hours ago \| parent \| prev [-]
		I’ve never seen nix, but I’d rather learn “yet another language” than fight yet another yaml syntax.