Threads for andir
-
That’s pretty depressing. IRC is one of the few protocols that is actually independently implementable and maintainable by almost anyone.
I think we’re seeing the rise of the nominally open but practically proprietary internet, thanks to the death of accessible protocols.
-
Fully agree.
It is sad to see many more communities vanish into some “protected” chat system. Many of them not even allowing 3rd-party clients…
I regularly struggle with opening all the Slacks, Discord, Gitter,… for all the communities that I am interested in. 5 years ago all I needed was the IRC client that also required a fraction of memory an CPU power.
-
At least for chat protocols, anyway. Time was when any home hobbyist could build a reasonable CPU out of transistors on breadboards, but nowdays only multinational mega-corporations have the resources and technology to build CPUs anybody wants to use. Even if you restrict yourself to multi-layer circuit boards and surface-mount components, you’re still nearly fifty years behind the curve.
-
Chat protocols, HTTP(2,3,QUIC) clients, web browsers. There used to be a healthy ecosystem around these, but now there’s just Google, and the competitor Google is funding to keep antitrust legislators at bay.
Forgetting FPGAs and Risc-V, which are helping in the CPU space: There are massive performance benefits to high end VLSI fabrication of complex chips. If the choice was less stark, I’d also be arguing strongly for ecosystem health and diversity over performance.
And yes, we have lost some of the diversity: PowerPC, Sparc, MIPS, Alpha, PA-RISC – the CPU space was better off when there was competition, instead of just X86 and Arm playing in disjoint sandboxes.
-
-
Possibly naive question: If your OS configuration is already reproducible and declarative because it is all managed by Puppet or Ansible (assuming you aren’t abusing those tools to run non-idempotent scripts), does NixOS bring a lot of extra value?
Using Puppet, Ansible, or Salt can sort of replicate the declarative nature of NixOS, but they fall short of duplicating all the behavior.
For example, if you’re managing a file or package with Salt, and you decide you don’t need it anymore, you have to remember to do
file.absent,package.absent, or similar to actually remove it from running systems. In NixOS you can just remove the declaration, and it will be removed from the active system. We’ve had many incidents at work caused by someone forgetting to remove a configuration file or systemd unit when no longer needed.Puppet/Ansible/Salt can still display a “hysteresis” effect: because they rely on e.g. apk, their reproducibility is kinda “best effort”. Notably, installing some package and then uninstalling it with them can leave your system (say, the /etc dir) in a different state than before, even if your “declarative” config is identical as it was before. With NixOS, identical config guarantees (via hashes and readonly mounts) exactly identical OS directory tree and to a much wider extent, including /etc, and fully accounting for removed files. There’s still a few things that are hard to avoid keeping modifiable (/var, $HOME, hardware, …), but other than that, it’s a very different level of immutability/reproducibility. That said, it necessarily makes NixOS more “total”, i.e. you either fully go with it, or not. (There could be ways to make this more gradual, but no such approach has been developed enough to be publicly usable by others yet AFAIK.)
To paraphrase a former coworker, Puppet needs to be run repeatedly until the log is all green. Nix only needs to be run once. (I will admit that systemd can get hung up and need multiple attempts to figure out its units, but Nix only needs one run to change which units systemd is working on.)
The main benefit of NixOS, if you got everything else replicated in Ansible/Puppet (which is very hard), is that you can do atomic upgrade and switches between systems. Nix also allows you to use a systems current configuration and copy it 1:1 to another machine and switch to that atomically.
Once you managed to declare all your system configuration with Nix you use the same expressions (and the already generated files in your Nix store) to produce Installer ISOs, VM Images, … without much hassle. This goes as far as testing a new configuration of your system in a VM that doesn’t require building a full VM image. Instead if can just mount the subset of paths required for the system into the VM. This allows you to iterate on the level of seconds instead of whatever Puppet/Vagrant allow you to do. In my experience the whole Puppet workflow is at least tens of minutes and might then still install something different every time (due to timing, package sources being upgrade halfway, …).
Don’t forget the developer goodies. I mostly use the Nix package manager on non-NixOS linuxes to quickly get to a project of mine and open a shell with all dependencies set just the way I need them to start working on that project. If you’re familiar with python’s virtualenv – it’s a similar experience but with all the C/system dependencies that you need.
With Puppet or Ansible I’d need to maintain separate setup scripts and documentation for dev and non-dev environments.
Not really. Of course assuming that Puppet or Ansible configuration is truly idempotent which is very hard thing to do. In the other hand achieving idempotency with Nix is much easier.