A friend on one of my Matrix channels is really into nix, and I’ve been absorbing just a little by osmosis. It seems like, as someone who runs pet computers, that nix would handle a lot of my configuration management needs.
I’m completely bought into the Nix philosophy, but in practice Nix is still terribly painful to use. Every time I’ve tried to use it, I end up pulling at this infinite-length thread–something that seems like it’s going to take a few minutes always has one or two issues that beget their own issues and several days later I need to package some obscure C dependency with its own bespoke build system that just assumes certain files live in certain paths on the file system (and moreover, packaging itself is enormously painful for many reasons, not least of which is that it involves referencing nixpkgs, which is poorly organized, poorly documented, and dynamically typed although I’m of the impression that the team is working to gradually improve the organization).
My dream project is inventing a light-weight layer on top of Arch Linux (I suppose it could be distro-agnostic, but that isn’t a primary goal), that would give 90% of the awesome of Nix while religiously sticking to simplicity. I think a declarative configuration layer is the most important piece, but I’m not sure how to adapt this to the fast-moving Arch, so that the maintainer workload would still remain minimal.
I haven’t used Arch, so I can’t sepak to it, but I think Nix could be 100x better if (1) they didn’t invent their own language and instead used something more familiar to developers (2) they used a statically typed language so it was easier to figure out what functions accept/return (3) documented their packages better (4) improved nixpkgs organization.
From there, there are still tons of other issues, but at least they’re not confounded by the aforementioned. On a meta level, it seems like the Nix community really struggles to make progress on these kinds of things. I’m not sure if it’s a lack of interest or what, but these issues have been around forever–at a certain point you have to look at the people and processes that are governing the project (and I say this with all humility as someone who would probably be shit in a maintainer role; criticizing is easier than doing and all that).
I like this idea of “it shouldn’t be harder than by hand”. In reality sometimes it’s hard to do things “right” with automation because of incidental issues (managing repos or the like), but there’s a lot of interesting design space between “everything done by hand” and “all provisioning is automated”.
It does feel like “pets+” can be easily reached by allowing… some templating? Or like “run this command to get the result of something for the destination file”. One might say that this is heading towards salt/puppet territory, but the lack of a coordinating node seems to resolve a huge chunk of the complexity IMO.
One magical thing that would be cool to see in this vein: some sort of ssh layer where you can log into a machine, have everything be recorded, and then your sessions are saved in a nice editable format with logs about what happened, so you can edit them down to “configuration”. Note taking without the tedium and forgetting stuff! Bonus points for a layered FS to support this somehow
I use NixOS/home-manager for a few years already with a similar objective (managing multiple “pet” systems). Just a quick comparison between the two (based on the Design Overview from README):
Runs locally on a single machine: # pets -conf_dir /etc/pets vs # sudo nixos-rebuild switch --flake /etc/nixos#hostname
One directory holds the full configuration of the system: /etc/pets vs /etc/nixos
No variables, no templates, just plain static config files: Nix DSL supports all of those
No dependencies between different components: vs Nix DSL allow this if you need
A single one-shot program reading the configuration directory and applying changes: pets vs nixos-rebuild (however you also need to learn the other nix commands for special purposes, and it is kinda messy right now)
Changes are applied only if basic syntax checks pass: also valid for Nix
Main interaction mechanism inspired by vim modelines: vs Nix has its own DSL
Now, I am not trying to detract of the approach. In general this seems like an interesting project, but in my years of experience of managing “pets”, one thing that I sorely missed was a template system. In most cases I want to share 99% of my configuration in all my systems, but it is the remaining 1% that is not shared that gets tricky.
Some programs like your $SHELL allow you do to it since the configuration language is the same as the scripting language, so you can pretty much write some code that allow you to load configurations e.g. per hostname. However some less flexible configuration formats doesn’t allow it at all, and this is where having a template system helps.
Before using Nix I used GNU Stow for the same purpose, started to write my own template system, almost switched to Ansible (that is designed more to manage “cattle” systems) before switching to NixOS (and eventually home-manager), the last one gave me templates for free (and of course many more features).
I am deeply invested in the Nix ecosystem to change right now and I really like the experience even with the rough edges, but at least for my use cases I wouldn’t use this project because of the lack of templates.
I really dislike the cattle vs. pets analogy, because it reenforces a speciesist world view that sadly is very prevalent in almost all parts of the world.
Ehhhhhh… I mostly agree in this instance, but this is unfortunately not a great line of argument to take in general. You can apply the argument to any kind of human discrimination in history, and it’s just as true. If you describe something as “X for white’s, not spic’s” people will generally understand the meanings behind it, but that doesn’t mean you couldn’t do better.
Reproducible and non-reproducible configurations. The key feature of cattle that we are trying to isolate is the ability to spawn new machines with a known-good configuration on a reliable basis; in other words, cattle are reproducible.
Other than it is a really bad analogy in general. In most situations it’s just “now your cluster is the pet”. It’s also bad because it somehow makes it sound that holding cattle is easier than a pet.
On top of that it’s in the same line as tons of other lines meant to shut people up before arguing, so you don’t have to know what you are talking about.
A similar one is that complaining about the term serverless is like complaining about horseless carts, when in reality it’s more like calling a cab “carless”.
I really think those statements and analogies do the industry a huge disfavor and that they should be abandoned altogether. Not because analogies are always bad (they are pretty much always imprecise though), but because they don’t even serve the purpose of analogies which is explaining things well. We have good analogies in IT, that mostly work, from cryptographic keys, to files, directories (or folders if you are into that). What they have in common is that they explain something better than any technical terms. Cattle and pets don’t. They at best make bold claims about how things work, but tend to easily break no matter what direction you go. Think about protecting your cattle or your pet. How does analogy even work in terms of security, which is a big part. For files again, it works. Putting the file into the trash bin, and even retrieving it, emptying it, all works pretty well. Also protecting your file works well with analogies.
I think the difference is that some of these “bad” analogies are being mostly used for marketing and like mentioned to bring points across when you lack good arguments.
This is for people who need to administer a handful of machines, all fairly different from each other and all Very Important. Those systems are not Cattle! They’re actually a bit more than Pets. They’re almost Family. For example: a laptop, workstation, and that personal tiny server in Sweden. They are all named after something dear.
They’re almost Family
Sounds like a good motivation to murder them personally and replace with Cattle provisioning.
Backups are great, until you want to upgrade to a new version of $software or $os. Then the backup needs to be applied, but are you sure each part needs to be there? Or that you didn’t miss something?
Additive configuration, like we use for cattle, will work when you change something underlying, like the OS.
disagree, cattle techniques don’t mean you can’t have extensible config management
although Chef isn’t easy to learn for a lot of folks, i’m glad i already know it, it’s easier to see when you have exactly as much extensibility as you need in your config management and not more than that… just like writing good software
Slight disagree on the idea and completely disagree on the threshold. In my experience, cattle management is extremely worth it on anything above 1. Otherwise at some point a change will be made to one of the hosts but not the other, or multiple things will change out of order. It’s basically inevitable with enough employees and time.
For the idea itself, I’m finding it worth it to manage everything that way. After a disk failure I could rebuild my home server in minutes from the NixOS description, rather than trying to recover backups and figure out exactly how things were configured.
Maaaaaybe. Ansible does pretty well for me with about 4 pets of various kinds. Some effort goes into making sure they are all quite similar though: all run Debian, they’re all within one version of each other, all have the same copy of my home dir on it even if they only need a few bits of it, etc. Each just has their own little config file that layers atop that general setup.
Hard agree. And that’s what I like about this post. But I think having systems that are very easily replaceable pays off even at small scale. Like someone offering me 3 free months of hosting for my lone cloud server if I move to their platform.
I’d also rather use the larger ops tools: if only because you’ve got more chances to encounter them elsewhere, and that’s knowledge you’ll be able to reuse. Pets would not work for me, but I’m sure it’ll be useful to someone else. I’ll stick to ansible playbooks for now.
Yeah, even if it’s one app, I’d rather make a terraform / ansible deployment strategy because I’ll be able to recreate it when requirements inevitably start requiring redundancy or what have you.
The drawings are wonderful!
A friend on one of my Matrix channels is really into nix, and I’ve been absorbing just a little by osmosis. It seems like, as someone who runs pet computers, that nix would handle a lot of my configuration management needs.
I’m completely bought into the Nix philosophy, but in practice Nix is still terribly painful to use. Every time I’ve tried to use it, I end up pulling at this infinite-length thread–something that seems like it’s going to take a few minutes always has one or two issues that beget their own issues and several days later I need to package some obscure C dependency with its own bespoke build system that just assumes certain files live in certain paths on the file system (and moreover, packaging itself is enormously painful for many reasons, not least of which is that it involves referencing nixpkgs, which is poorly organized, poorly documented, and dynamically typed although I’m of the impression that the team is working to gradually improve the organization).
My dream project is inventing a light-weight layer on top of Arch Linux (I suppose it could be distro-agnostic, but that isn’t a primary goal), that would give 90% of the awesome of Nix while religiously sticking to simplicity. I think a declarative configuration layer is the most important piece, but I’m not sure how to adapt this to the fast-moving Arch, so that the maintainer workload would still remain minimal.
I haven’t used Arch, so I can’t sepak to it, but I think Nix could be 100x better if (1) they didn’t invent their own language and instead used something more familiar to developers (2) they used a statically typed language so it was easier to figure out what functions accept/return (3) documented their packages better (4) improved nixpkgs organization.
From there, there are still tons of other issues, but at least they’re not confounded by the aforementioned. On a meta level, it seems like the Nix community really struggles to make progress on these kinds of things. I’m not sure if it’s a lack of interest or what, but these issues have been around forever–at a certain point you have to look at the people and processes that are governing the project (and I say this with all humility as someone who would probably be shit in a maintainer role; criticizing is easier than doing and all that).
I like this idea of “it shouldn’t be harder than by hand”. In reality sometimes it’s hard to do things “right” with automation because of incidental issues (managing repos or the like), but there’s a lot of interesting design space between “everything done by hand” and “all provisioning is automated”.
It does feel like “pets+” can be easily reached by allowing… some templating? Or like “run this command to get the result of something for the destination file”. One might say that this is heading towards salt/puppet territory, but the lack of a coordinating node seems to resolve a huge chunk of the complexity IMO.
One magical thing that would be cool to see in this vein: some sort of ssh layer where you can log into a machine, have everything be recorded, and then your sessions are saved in a nice editable format with logs about what happened, so you can edit them down to “configuration”. Note taking without the tedium and forgetting stuff! Bonus points for a layered FS to support this somehow
I use NixOS/home-manager for a few years already with a similar objective (managing multiple “pet” systems). Just a quick comparison between the two (based on the Design Overview from README):
# pets -conf_dir /etc/petsvs# sudo nixos-rebuild switch --flake /etc/nixos#hostname/etc/petsvs/etc/nixospetsvsnixos-rebuild(however you also need to learn the other nix commands for special purposes, and it is kinda messy right now)Now, I am not trying to detract of the approach. In general this seems like an interesting project, but in my years of experience of managing “pets”, one thing that I sorely missed was a template system. In most cases I want to share 99% of my configuration in all my systems, but it is the remaining 1% that is not shared that gets tricky.
Some programs like your
$SHELLallow you do to it since the configuration language is the same as the scripting language, so you can pretty much write some code that allow you to load configurations e.g. per hostname. However some less flexible configuration formats doesn’t allow it at all, and this is where having a template system helps.Before using Nix I used GNU Stow for the same purpose, started to write my own template system, almost switched to Ansible (that is designed more to manage “cattle” systems) before switching to NixOS (and eventually home-manager), the last one gave me templates for free (and of course many more features).
I am deeply invested in the Nix ecosystem to change right now and I really like the experience even with the rough edges, but at least for my use cases I wouldn’t use this project because of the lack of templates.
I really dislike the cattle vs. pets analogy, because it reenforces a speciesist world view that sadly is very prevalent in almost all parts of the world.
I like it because it refers to a perspective shared among those who see it. Even those who disagree, understand the meanings behind it.
Ehhhhhh… I mostly agree in this instance, but this is unfortunately not a great line of argument to take in general. You can apply the argument to any kind of human discrimination in history, and it’s just as true. If you describe something as “X for white’s, not spic’s” people will generally understand the meanings behind it, but that doesn’t mean you couldn’t do better.
You could have a pet cow.
[Comment removed by author]
What would you rather use instead?
Plants vs. crops, maybe?
roses and potatoes
Calling my desktop a rose seems unfair to roses.
I like that, maybe even garden vs farm?
I really like this
Reproducible and non-reproducible configurations. The key feature of cattle that we are trying to isolate is the ability to spawn new machines with a known-good configuration on a reliable basis; in other words, cattle are reproducible.
I really like that term. It also doesn’t take size into account so much and it leaves the question how these goals are achieved wide open.
I mean, the very point of this system is to make reproducibility easy…
Clusters and individual machines?
Other than it is a really bad analogy in general. In most situations it’s just “now your cluster is the pet”. It’s also bad because it somehow makes it sound that holding cattle is easier than a pet.
On top of that it’s in the same line as tons of other lines meant to shut people up before arguing, so you don’t have to know what you are talking about.
A similar one is that complaining about the term serverless is like complaining about horseless carts, when in reality it’s more like calling a cab “carless”.
I really think those statements and analogies do the industry a huge disfavor and that they should be abandoned altogether. Not because analogies are always bad (they are pretty much always imprecise though), but because they don’t even serve the purpose of analogies which is explaining things well. We have good analogies in IT, that mostly work, from cryptographic keys, to files, directories (or folders if you are into that). What they have in common is that they explain something better than any technical terms. Cattle and pets don’t. They at best make bold claims about how things work, but tend to easily break no matter what direction you go. Think about protecting your cattle or your pet. How does analogy even work in terms of security, which is a big part. For files again, it works. Putting the file into the trash bin, and even retrieving it, emptying it, all works pretty well. Also protecting your file works well with analogies.
I think the difference is that some of these “bad” analogies are being mostly used for marketing and like mentioned to bring points across when you lack good arguments.
Backyard vegetable patch vs industrial farming.
Sounds like a good motivation to murder them personally and replace with Cattle provisioning.
Cattle techniques aren’t really worth it until you have somewhere between 30 and 100
Or you have 1 machine that when it dies will take you a week to recreate
Such a machine should have backups in place, no?
Backups are great, until you want to upgrade to a new version of $software or $os. Then the backup needs to be applied, but are you sure each part needs to be there? Or that you didn’t miss something?
Additive configuration, like we use for cattle, will work when you change something underlying, like the OS.
FreeBSD and NixOS both let you keep the last old version around and reboot into it whenever you want. Others may or may not.
disagree, cattle techniques don’t mean you can’t have extensible config management
although Chef isn’t easy to learn for a lot of folks, i’m glad i already know it, it’s easier to see when you have exactly as much extensibility as you need in your config management and not more than that… just like writing good software
Slight disagree on the idea and completely disagree on the threshold. In my experience, cattle management is extremely worth it on anything above 1. Otherwise at some point a change will be made to one of the hosts but not the other, or multiple things will change out of order. It’s basically inevitable with enough employees and time.
For the idea itself, I’m finding it worth it to manage everything that way. After a disk failure I could rebuild my home server in minutes from the NixOS description, rather than trying to recover backups and figure out exactly how things were configured.
I’ve embraced this strategy as well now for at least the last decade, just swapping out nix for a config management system.
I keep backups of data (ex. Fileserver), but not system/program state. I could never go back, it feels wasteful of time and disk space now.
Maaaaaybe. Ansible does pretty well for me with about 4 pets of various kinds. Some effort goes into making sure they are all quite similar though: all run Debian, they’re all within one version of each other, all have the same copy of my home dir on it even if they only need a few bits of it, etc. Each just has their own little config file that layers atop that general setup.
Not everything has to efficient on an industrial scale.
Hard agree. And that’s what I like about this post. But I think having systems that are very easily replaceable pays off even at small scale. Like someone offering me 3 free months of hosting for my lone cloud server if I move to their platform.
Mental note: Never letting you take care of my cat. :-P
Good thing we’re not relatives. /s :)
I’d also rather use the larger ops tools: if only because you’ve got more chances to encounter them elsewhere, and that’s knowledge you’ll be able to reuse. Pets would not work for me, but I’m sure it’ll be useful to someone else. I’ll stick to ansible playbooks for now.
Yeah, even if it’s one app, I’d rather make a terraform / ansible deployment strategy because I’ll be able to recreate it when requirements inevitably start requiring redundancy or what have you.