Nix vs not Nix seems like a parallel to Infrastructure As Code (terraform for example) vs Cowboying the AWS Console. Is that a fair comparison?
Yes that is a fair comparison. In the latter you have to write down or remember what you did to reproduce it, and even if you make a script it could screw up and leave your system in a bad state.
That script can also stop working or misbehave once the underlaying system state changes, e.g. as the repository packages get updated.
Not really, unfortunately. In my opinion, Nix is more like using Haskell instead of whatever language your team is using to write software.
Re:My First Impressions of Nix
by SuperSandro2000 on Monday June 19, 2023 @11:11AM
(#36391953)
I got pretty far the first year without really writing much nix code at all.
Re:My First Impressions of Nix
by ParetoOptimal on Monday June 19, 2023 @04:11PM
(#36395912)
> Nix is more like using Haskell instead of whatever language your team is using to write software.
In my professional experience, this has worked well :)
Re:My First Impressions of Nix
by LMYahooTFY on Monday June 19, 2023 @11:12AM
(#36391961)
As someone who seems to be going along a similar path (started as a dev, no one was around to do sysadmin so I did it, and now in trying to modernize a bunch of really old/unpatched servers running a legacy system I'm learning how to devops) I feel better knowing I'm not alone in this struggle.
Re:My First Impressions of Nix
by Gravityloss on Monday June 19, 2023 @12:50PM
(#36393291)
Yes. Think if you coordinated a software project with email and a Sharepoint folder for the code.
Then you use git.
Current server state management is the former. Nobody knows what is running where and if some performance differences over time or between servers exist, how can it be bisected etc...
That's simple: nix is a package manager and the language used by the package manager, NixOS is a Linux distro.
> It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist.
From someone who is working as a DevOps Engineer for some years and managing Linux servers for a few years longer that thought is incredible naive. The problem of undefined and undocumented system state is a fundamental problem I encounter everywhere especially bad with legacy systems. I often do things on them blind and just pray for the best outcome, realising months later that some system was broken by one change I did and no one realised that for months.
> I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold less and the learning curve doesn't require half a decade. Got stuff to do!
I thought the same first but unwedging Debian once a week on a different system is also not fun and a waste of time and having servers in some undefined state and no one who how the config is supposed to be and why or when it got changed, too.
The result in the end is that every system is different and unique and your Ansible playbook to run a common and good thought out task succeeds on 15 VMs and sometimes completely blows up the 16th because no one could have thought that the state of configuration there is so widely different.