- cross-posted to:
- linux@programming.dev
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
- linux@programming.dev
You must log in or register to comment.
Skipped to the “ugly” part of the article and I kind of agree with the language being hard?
I think a bigger problem is that it’s hard to find “best practices” because information is just scattered everywhere and search engines are terrible.
Like, the language itself is fairly simple and the tutorial is good. But it’s a struggle when it comes to doing things like “how do I change the source of a package”, “how do I compose two modules together” and “how do I add a repo to a flake so it’s visible in my config”. Most of this information comes from random discourse threads where the responder assumes you have a working knowledge of the part of the codebase they’re taking about.
Meanwhile me as a barbarian installing Debian and copying my ~/.bashrc file if not just remounting
/home/in the new installation every few years.One of my machines i’ve been just upgrading in place since debian 8. No need for new installation
Debian isn’t barbaric at all.
I like the idea of nixos, but I feel like it makes a bunch of daily sacrifices in order to optimize a task I do once every few years? I hardly ever get a new computer, but I install/uninstall/update/tweak packages on my system all the time. With a dotfile manager and snapshots, I get most of the benefit without any of the drawbacks.
I feel like setting up a new machine is just the easiest to explain.
Personally, I find dotfiles messy, as you often just want to change one or two settings, but you always carry along the whole file with all kinds of irrelevant other settings. This also makes it impractical to diff two versions of those dotfiles, especially when programs write semi-permanent settings into there.
I guess, your mileage will vary depending on what programs or desktop environment you use.
For example, I love KDE, but they really don’t do a good job keeping the config files clean. Nix Plasma-Manager generally fixes that, and for example allows defining the contents of the panel in a readable form.For DevOps, it provides consistency for every CI run and production deployment, especially when a whole system needs to be shipped.
Loved nixOS but couldn’t install PIA VPN gui and disliked the workarounds. Also doing .net dev was more awkward than I liked so went back to Arch and wrote some scripts to install all the packages I want instead. Love the idea of nixOS though.
It also is an option to ensure everyone has the same dev environment.
Meh. So is docker.
The docker is not bare metal though.
sigh, yes it is.
Does it matter if the overhead is practically irrelevant?
The biggest downside to containers vs. Nix for me is that Nix can produce binaries for Linux and macOS, whereas docker only helps with Linux unless you can perform literal magic to cross-compile your project on Linux for macOS.
Containers also don’t give you reproducible environments, and Nix does.
That said, Nix documentation is ass, so I usually end up going with containers because they require far less suffering to get working because writing a containerfile is much easier than guessing how to hobble together a Nix flake with a mostly undocumented language.
Containers also don’t give you reproducible environments, and Nix does.
Of course it does. 🙄
Care to elaborate? Containers give you repeatable environments, which are not the same thing as reproducible environments.
It could if there are issues accessing hardware directly. Overhead is, as you said, not that important.
Personally, the stepping stone I needed to know about is Nix Home-Manager, which basically allows you to manage your dotfiles independent of the distro. From what I understand, if I do switch to NixOS, I’ll continue using this code with just some minor tweaks.
But yeah, I agree with the verdict in the post. I like it a lot, but I would not have made it past the initial learning curve, if I didn’t happen to be a software engineer. Sysadmins will probably be able to figure out how to put it to use, too. But it’s just not for non-technical Linux users.
Agreed with the article. There’s lots to dislike about Nix, but even with those downsides, NixOS is still better than any OS I’ve tried. Install an update and it’s borked? No worries. New PC and you want everything set up just like your old one? Copy one file over and it’s set up for you.
Copy one file over and it’s set up for you.
So, I’ve only played around with NixOS on a Raspberry Pi, but… Don’t people usually split their config up in multiple files, and then store than in a Git repository?
The process then still is: check out that Git repository, except there’s another step: copy over your private key so that you can decrypt your secrets.
Is that correct? Or did I make things needlessly complex for myself?
The process then still is: check out that Git repository, except there’s another step: copy over your private key so that you can decrypt your secrets.
I store my secrets in a separate private git repo and automatically decrypt them with my hardware key (https://github.com/balsoft/nixos-config/blob/master/modules/secrets.nix) so for me it’s literally just plug in my yubikey and
nixos-install github:balsoft/nixos-config#hostnameHow do you access the private Git repo then? Don’t you need a secret to access it?
I don’t have any secrets in my config or a private key or anything and I’m currently running 4 servers from the same config (it used to be 8 or even more machines at some point even, including desktops).
But yes, it’s a multi-file config, it would be absolutely crazy to not split it up with how large it is.
Is that just because your four servers aren’t used for anything that need a secret? e.g. I wanted to put my wifi password in there, and the password for my user account.
This is a well-written post. I agree that “friction” involved with small changes and incompatibility with some Linux binaries are significant downsides. I think NixOS makes a lot of sense for development environments, but it’s not my preference for a personal device
