NixOS and the Art of OS Configuration (2018)
rousette.org.uk
rousette.org.uk
I started my Nix journey a little over a year ago, and I regret not having switched sooner. A package-manager that also ships an operating system that can be customized from the bootloader up, using a purely functional programming language is the perfect configuration management tool!
It does have some rough edges, and I did lose some hair figuring things out early on, but it has been getting better with each passing day. Pretty much the entirety of my setup at home is now built by Nix and runs NixOS, including my Macbook Air (runs NixOS on ZFS), and two Mac-Minis that PXE-boot a custom NixOS served by a Raspberry Pi 4 running a custom NixOS configuration that also acts as a firewall connecting wirlessly to my ISP's router. The Mac-Minis also double as build machines which makes for a pretty smooth experience when I'm building anything on my work laptop (a 2020 Macbook Pro running Big Sur) that I dock with my CinemaDisplay, which is wired thru an unmanaged switch to the rest.
So far I haven't missed any packages that I could not find in nixpkgs, or customize just the way I wanted to. The community is pretty responsive and quick to merge any pull requests for fixes/upgrades. I would whole-heartedly recommend switching to Nix/NixOS/Nixpkgs.
I haven't been this happy and giddy with a new piece of technology since I completely eliminated Windows for Ubuntu back in 2009.
There was a learning curve that took several months, but now that I've got everything I had on Ubuntu running smoothly on NixOS, I could never go back. And this for my daily driver, not a server or anything.
My favorite part is how it enables rapid experimentation with different build configurations, without any concern about borking the current working build.
If the new build breaks something, a single command rolls it back to the prior working build.
If the new build crashes the system, just reboot and choose the prior working build in GRUB. When you're logged back in, call the rollback command to point the system back to the working build.
This makes learning and testing both Nix itself and your particular system build faster, easier, stress-free, and just downright fun, which is invaluable.
Declarative, deterministic, immutable OS builds is a significant step out of the tarpit of software complexity.
Yeah, it took a few months to learn, and there are still lots of rough edges, but going back to a non-Nix linux distro would feel like going back to windows. I agree with the sibling comment that it makes me feel happy and giddy, like no other technology I've learned recently.
And it's honestly not that hard to package things that aren't yet Nixified. Any C project is easy - I've learned more about cmake from mkDerivation that anywhere else.
And overlays make it easy to make tweaks to a build without straight-up forking. Beautiful!
This is something I find really fascinating about Nix (or more precisely nixpkgs) that gets overlooked a lot: it is essentially a giant database that documents how different build tools work, how different projects are built, and so on, in an exhaustive and consistent manner.
That can be an extremely valuable resource to have in your back pocket, even if you're not actually using Nix!
Nix+home-manager allows me to have all productivity tools consistently available across all platforms with minimal effort [1].
Dotfiles/shell config lives in a separate folder [2] and is not managed in nix.
Tangent: Secrets are are encrypted with git-crypt (https://github.com/AGWA/git-crypt) and live in the same repo [3]. I generate GPG keys for every new host I am working on and check in the public keys to the repo as well, then "approve" them from an authorized host using `git-crypt add-gpg-user ... && git push` [4]. This gives strong encryption without managing passwords by hand. [Copy of private key is kept in bitwarden as backup].
Getting the hang of Nix took me a while. I wrote-up my journey to get the latest-gratest emacs installed here [5]. But now I am over the bump, and it's adding value to my workfows. E.g. I switched some projects from docker to nix-shell for lightweight virtual-envs, e.g. [6].
[1] https://github.com/HeinrichHartmann/dotfiles/blob/master/nix...
[2] https://github.com/HeinrichHartmann/dotfiles/tree/master/.sh...
[3] https://github.com/HeinrichHartmann/dotfiles/tree/master/sec...
[4] https://github.com/HeinrichHartmann/dotfiles/tree/master/pub...
[5] https://www.heinrichhartmann.com/posts/2021-08-08-nix-emacs/
[6] https://github.com/HeinrichHartmann/HeinrichHartmann.github....
maybe best to avoid that https://en.m.wikipedia.org/wiki/Me_Too_movement
PS: I do like the idea of NixOS and its USPs which are indeed unique :)
For me what's stopping me is the learning curve. I don't mind learning per se but if I put the time in it I'd like it to be for something that's useful in more places. Like ansible.
BSDs don't face that kind of integration challenge, since they can just ship ZFS support directly in their kernels. They have recently faced an integration challenge of their own, though: rebasing their ZFS implementations on OpenZFS (f.k.a. ZFS on Linux).
Anyway ZFS is great and I hope OpenZFS' multiplatform support gets so good it can become popular on Linux, *BSD, and macOS all at the same time. :D
I noticed that most "hip" people use ZFS, but based on my meager research it seems actually recommended and designed for "big" data-center setups.
Why is ZFS good for small PC setups?
---
If am being honest I just want something that works reliably, is easy to extend and doesn't require maintenance. Maybe ext4 is good enough?
ZFS is mature and featureful, and it's easy to performance tune specific subdirectories using 'datasets' (on BTRFS you can do some of the same stuff with 'subvolumes'). It has good utilities for backup, including over the network. It always supports up to date, efficient compression (these days, zstd). It's good at pooling, so you don't need LVM if you want to be flexible about 'partitioning'.
One genuine advantage it has over BTRFS other than stable softraid support is that it's cross-platform among Unices, including (in incipient form) even macOS. So experience you gain in administering it would be transferable that way. (OTOH, Windows has a pretty mature BTRFS driver, but ZFS on Windows is even more recent (and difficult) an effort than ZFS on Mac).
Truthfully, ext4, BTRFS, and ZFS are all fast and stable, and once you set them up your filesystem, you'll probably hardly think about it. (If you go with ext4, I'd set it up on LVM to make it easier to extend or 'repartition' in case you wanna structure things differently or add another distro or whatever.)
Linux's heritage and continued use as a server OS makes it rich with fast, reliable, flexible, feature-complete filesystems. All three of your options here are better than what's on offer on any Windows or Mac desktop, so you kinda can't go wrong, so don't overthink it. Just pick something you feel like learning or whose documentation strikes you as agreeable and interesting. Whatever you choose will serve you fine until your disk dies or you get bored. :)
Depending on whether you mean "used by more people" or "applicable to more problems"... if the latter, tools like morph or NixOps might be of interest to you, which essentially extend Nix to "across multiple remote machines", which means that de facto you end up with an orchestration tool like Ansible or Puppet.
Right, but FreeBSD isn't Linux, if you want both ZFS and the Linux ecosystem, then I would argue NixOS is the best at that right now.
I tried Ubuntu and ZFS recently in a VM just to see how it worked. The installer handles a simple, standard ZFS config just fine. But if you want to do anything more complex, then you're doing manual configuration, at which point it's better to just use NixOS, where all the manual config is done in the main NixOS config file.
I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.
[0] which are already an overengineered and under-delivering solution in my opinion.
For me, the benefits outweigh the quirks of the language. As my alternatives to manage multiple machines consist of: wonky Bash scripts, similar tooling but bolted-on on top of the distro and with no built-in rollbacks (Ansible, Puppet, etc.), or trying to get everything right manually, Nix does not seem like the worst out of this bunch.
If someone could make a user-friendly implementation of the Nix concept I think it would be very popular.
Nix is different, unapologetically so, that's the issue. And if it had to be more orthodox to win over a few more itinerant users that would make the whole thing pointless.
Ultimately I want less complication in my life, not more, and Nix very much does not provide that from what I can see.
Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?
But the thing about Nix is that it just adds even more complexity. As was mentioned elsethread, in order to be effective with Nix you need to understand all the complexities of Nix and Linux. And the thing about Linux is that we have a ton of adequate recipe books out there already.
Nix offers a way to easily customize and override said "reasonable defaults" across packages written in different programming languages and compiled using a variety of build toolchains. Doing so requires using a common language for expressing defaults and overriding them. IMO, that is not adding complexity, but taming it to make it reasonably easy for individual developers and teams, small and large.
I'd argue that the traditional stack relies on way too many tools, each designed for a limited purpose, and making a LOT of assumptions about the target system. This IMO is far more complex than learning one language and framework.
It absolutely doesn't. I'm someone who is fairly fluent with Nix, and in comparison the complexities of running a non-trivial docker-compose setup gives me nightmares. Luckily I basically never have to worry about that though.
I like to compare it to fossil fuels and global warming. Traditional systems get one started quick, but eventually build a large fragile system that gets harder to fix/rebuild the longer it goes on.
Nix is different, it forces you to do your work upfront. But once setup, you pretty much can (and to my attestation do) forget it is in place. You do have to learn setting a anything a and everything. But you only do it once. If the house burns down, you don't need to remember what you had. You don't need to remember what to setup in what order. You don't have to find out you forgot something in the middle of something else. In other words, the onus is no longer on you.
That last sentence is incredibly liberating. I stopped worrying having black screens after updates and pretty much stopped having rescue disc, because rescue functionality comes built in the system. It sounds cultish, and it kinda is, but as I said in previous comment on Nix, it is the worst system management tool, except all the others.
Nix takes a very different approach to system configuration than the traditional ways. Because it treats the entirety of the operating system (bootloader, kernel, user-land, services, account management, etc.) as a single composable unit, it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone. The deviation from the Unix Filesystem Hierarchy is, IMO, required to make systems more composable and maintainable, and is inherently a good thing in the long run. Portable development environments eliminate "works-on-my-laptop" scenarios and ensure everyone on the team is always in sync with each other and CI/CD. Reproducible builds that can be rolled back after a botched deployment are a huge win. And delivering all of these features in a single tool requires breaking some of the old rules, and that is always met with resistance due to the inertia of "it works fine for me".
To be honest, there is no reason why you should give up what works well for you. Having said that, for those that are looking beyond the traditional tools like shell-scripts, Ansible, Chef, Puppet, and others, Nix offers all that is needed to easily build and maintain composable software stacks. Docker comes close to delivering some of the same features as Nix, but comparing the two is a bit like comparing system configuration using shell scripts to Chef/Ansible.
Yes; one does have to learn a new language and its idiosyncrasies. But that is also true of things like Rust. As a seasoned C programmer, I am able to write "good" C code. But that is not a statement about C's ability to scale to larger teams. Rust requires developers to give up their old ways of thinking and "give in" to the Rust-way. The longer you fight the borrow-checker, the more painful it gets. But once you give in, you are able to write code that is safer for use within large teams, thus delivering more momentum in the long run. It is not that it can't be built with C; it requires a communal way of thinking about software complexity that is forged by experience and tempered by camaraderie, and tools like Rust and Nix are excellent supplements.
I do agree with you that the documentation leaves a lot to be desired. I've always considered the FreeBSD Handbook to be the gold-standard for technical documentation and Nix has its work cut out to reach that stage of maturity. But I have full confidence in the Nix community's ability to deliver.
On the other hand, one of Nix's greatest strengths is that in many respects, its innovations are conservative. It brings software building and distribution forward in terms of reproducibility and isolation (like containers do) but (unlike containers) also retains the traditional package management virtues of granularity, efficiency, and sharing common resources (dependencies) when possible.
This is pragmatic.
Nix somewhat reminds me of the kinds of mindsets that enjoy learning Vim/Emacs, or learning how to use 40%-sized keyboards like the Planck. -- I think it takes curiosity to be interested in that kindof stuff.
This is fair, but keep in mind that package managing is only a small part that what Nix solves, and it is a much superior solution than anything else that I know (Docker for example is not really reproducible because you can't trace all dependencies; this seems like a philosophic issue but I saw some containers breaking because some dependency inside the container was updated without nobody knowing).
If we take NixOS, it also solves the issue with configuration, and with some auxiliary tools it also solves issues with deployment. You have alternatives for both of the issues too, but the fact that NixOS is much more integrated than any tooling (like Ansible, Puppet, etc) means you have much more flexibility. Also, don't forget atomic upgrades and fallback.
Eventually, instead of "wasting time", NixOS starts to save time by becoming the most reliable OS you ever used: you will never waste time anymore reinstalling your system from scratch, or if your hardware broke, you will never waste days trying to get your system to the same way it was. Also, because nixpkgs is enormous, you also tend to save time by not looking at "oh, this program seems cool, how can I install it on my computer since I never heard of this XYZ language?", and them installing the package manager from the language in 5 different ways because you have no clue. And even when you need to package the program yourself, nixpkgs has many abstractions that makes it much easier.
So instead of wasting time, Nix and NixOS is an investment. You may choose to invest your time right now to save later or not. Either way is fine.
Just to finish the topic, I fully concur yo you that we as a community needs to have better documentation.
While there are definitely a lot of remaining documentation and usability issues with Nix as it stands today, the core model is far from 'overengineered' - if anything, it's orders of magnitude less complex than the organically-grown cobbled-together pile of tools and conventions that 'traditional' distros are made out of.
Nix having a well-defined, complete, specified-upfront, coherent model doesn't make it 'overengineered'; it just means that the tools were designed from the start to help you manage the complexity of system management, rather than just kind of leaving it implicit and letting the end user and/or packager deal with the fallout later through an ever-growing collection of workarounds and patches and scripts.
It's completely valid to decide that NixOS is not (yet) for you due to the learning curve that still exists; I frequently warn people away from NixOS (when they are not prepared to deal with that) for this precise reason. But please don't conflate that with 'bad design'.
This is kinda nuts to me. Every time I use a system that doesn't offer proper package management, it makes me wish I had a decent package manager. What do you think is better than a modern package manager for solving the same problems?
There are few bad sides to NixOS though.
The community consists mostly of programmers, which means I am missing some creative tools (mockups, mindmaps, ..). In the future I will be able to provide/build them myself, but it is not a smooth transition from my previous arch setup.
Also the whole documentation sucks: There are three (!) official manuals + the home-manager manual + Nix pills + YT + random blogs where I have to piece everything together.
Still I find NixOS superior to every other OS (windows, linux) I have tried so far. I just feel free and am not afraid to fuck up anything [2], as I can just go to a previous generation when it doesn't boot.
Lastly, I can save my whole config in git and am free to try new tools -- If I don't like them, I just remove their line in my config. No more chasing after random install folders! (Except in home..)
[1]: https://github.com/driusan/lmt [2]: All the "hacker" stuff: kernel modules, network hardening, ...
I just played around with R the other day and it would use MD too to generate HTML/PDF.
It uses Knitr.
The reason I chose lmt is that it correctly keeps the markdown language syntax of the code blocks. That means I can put my literate config into my Zettelkasten [1] or [2] and watch it pretty-print in the browser.
There are also literate [3] and org-babel [4], but I don't think they are future proof. .lit is a random format and .org basically requires Emacs+orgmode.
1: https://github.com/srid/emanote
Literate/.lit: I don't know, I guess not.
Emacs/orgmode: Yes, this also does syntax highlight. And you can edit the code-block in a separate window as if it was a "real" source code file. I've been using this for almost two years now. Personal opinion: I don't think the benefits of Emacs outweight the cons.
Until you have to install the latest NVidia drivers, I suppose.
1: https://nixos.org/manual/nixos/stable/#sec-x11-graphics-card...
This applies regardless of whether you are packaging/updating something in the package set yourself, or using something that someone else packaged.
The same happens on all package managers...
But I'm seeing so much Nix news these past few weeks, I guess it'll be better in a few years!
The difficulty comes from the advanced topics. Modularizing your setup, writing your own packages, generally going off the beaten path.
I did not do any of that (yet). I will in the future, but I am fine with my low-level setup. One machine, one user. A bit later I moved to Nix Flakes (which is just an additional wrapper file around the previously written config) and added a few overlays.
My trick: I downloaded every single public "NixOS" dotfile repository I could find, and then just used "ripgrep" to find anything I was interested in.
Another cool trick I read is setting up a VM to test a small config and get a feeling for it, and then decide if yo want to proceed.
SO many times in the past, I'd be concerned about installing new things because they'd break my otherwise pristine developer environment. Yes, rvm/nvm/virtualenv and others help, but they fail to hold a candle to the nix-shell!
Yeah this part is messy, and why I always disclaim that I had a learning curve of several months to make the transition. However, my system setup is a little more complex than the standard install - mirrored ZFS root drives on dual m.2 drives, with mirrored boot partitions. That wasn't in the docs, needed a blog post to explain it [1].
>I also really don't like wasting so much time on tinkering with my system the way I used to do.
I've found that once you get everything configured to your liking, you spend similar or less time tinkering than on other OS's, just because the entire system config is captured in a single config file now. There's some up-front learning and work required, but after that it's smooth sailing.
[1]:https://elis.nu/blog/2019/08/encrypted-zfs-mirror-with-mirro...
https://nixos.org/manual/nix/stable/
https://nixos.org/manual/nixpkgs/stable/
https://nixos.org/manual/nixos/stable/
Anyone looking into transitioning to NixOS should take a leisurely weekend and just read through all three of those first. Being at least familiar with all of what's there will make getting up and running a lot smoother.
Any time you need a package that's not in nixpkgs, feel free to submit a packaging request for it:
https://github.com/NixOS/nixpkgs/issues/new/choose (Issues -> New Issue -> Packaging Request)
Especially if you explain that it's a popular tool in the creative community, that kind of thing is useful for the Nix packaging team to be made aware of. Even if someone doesn't package it right away, there's a good chance it will make it into the next 6-month release cycle.
1. It is simple and fast to install. People make NixOS feels like black magic. NixOS is easier to install than Arch linux. Just do 3 things. Partition your disk, create the nix configuration file and finally run the command "nixos-install" command. Let me explain with a lil more explanation:
a. Partition your disk with parted or cfdisk and mount it (mentioned in docs https://nixos.org/manual/nixos/stable/).
b. Generate configuration file which has the biggest myth around it. My god, this is dead simple and could install it in 5-10mins after doing it just ONCE (This obviously excludes time needed to reading up about NixOS to be familiar with it, but trust me it is not hard for a first time installer). You literally run the command "sudo nixos-generate-config" and it generates a config file in .nix format and YOU DONT HAVE TO START FROM SCRATCH AT ALL. And you don't need to know nix programming language. It has all the settings needed in the config file and all you have to do is uncomment the necessary stuff. The sound, grub, wifi etc.
c. Then run the command "nixos-install".
2. The second point was supposed to be that it is a point release and thus have old packages and hence not a rolling release. This was based on the package search that firefox and some other packages are one version behind even on unstable repo 2 days ago. But just as I typed this, I double checked and Firefox 93 is in stable repo (21.05) and so are some of my other packages. I went back to Arch and was gonna ditch nixos due to this. So this is huge. I probably gonna install NixOS on my laptop now. DO correct me if I am wrong on this please. Because this is the only thing that is stopping me from using NixOS.
Cos in Linux distro context, debian or nixos unstable repo just means it is not yet tested for the specific distro. But in fact the packages itself would be latest stable versions from upstreams.
I did read my reading but it is really blurry and hard to find information on how often the packages gets updated.
I also would like plain upstream versions of software without a distro doing any changes. And with NixOS and Nix, this is perfectly capable of fixing even the remote issues of instability that usually happens with Arch Linux.
I only had issues a couple times with broken packages, then you can either not update at all or remove those packages. It should also be possible to keep the older version of those packages in the nix config but I did not look into it.
But if possible can you also elaborate on "pretty much" yes part? What is the catch or what am I missing?
A lot of updates do get backported to stable branches and you can do it yourself pretty easily if you need an update, so running stable for servers makes sense. But for a desktop I prefer the rolling release, always updated model.
Cos in Linux distro context, debian or nixos unstable repo just means it is not yet tested for the specific distro. But in fact the packages itself would be latest stable versions from upstreams.
The usage of "unstable" itself is from an era where even stable versions broke a lot. This is not the case anymore. And stable repos breaking more than unstable repos in some distros atleast proves it.
NixOS benefits from the fact that it has unit tests and that all packages are built in a consistent way across all packages.
Archlinux is a bit more stable then NixOS unstable, but not significantly so. But more importantly if you do somehow manage to update to a broken build, it's take less than a second to roll back to exactly where you were before hand.
The distinction also matters less on NixOS anyway, since you can (generally) freely mix and match packages from different releases.
Lots of Nix packages are totally unmodified, but many also have to be patched in able to cope with the read-only package store.
On the other hand, NixOS is, like Arch, a distro without any defaults aside from systemd. So Nixpkgs doesn't include patches that try to reshape upstream packages for the sake of some particular vision of the ideal desktop experience or whatever.
But with Nix, you can be more flexible and mix packages from stable and unstable channels very easily. In my case, the kernel and desktop environment comes from the stable channel while the rest comes from unstable.
Step 2 is doing a lot of work here. It's pretty 'draw the rest of the fucking owl'.
Using NixOS as a personal desktop for doing development can take a lot of work. You can expect it to take more work than just making the same setup in Arch linux, or whatever.
My experience with Nix is that it's 95% wonderful, 5% very painful. -- Navigating the painful parts of Nix requires understanding what's going on with the Linux parts, with the Nix parts, and with the parts of whatever you're trying to do. (Whereas with other OSs, you can generally get by with copy-pasting from StackOverflow).
Especially given that Nix requires use of a pure functional language, and that there are few tools developers are willing to put effort in to learn, Nix really stands out as unfamiliar.
This is very true. Having used NixOS as my main OS for 5 or 6 years now, the encouraging thing is that the '95%', the 'happy path' is growing all the time. It'll never be 100%, but more and more people will find that Nix's 95% covers 100% of their own use cases. (This is especially true as Flatpak matures and gains popularity, making it more and more useful as an escape hatch for running oddball software that Nixpkgs contributors haven't had a chance to wrangle yet.)
Not really. Most distros aren't fully set up from the moment you complete a base install. Similarly, all you need for a base install of NixOS is to enable (1) a desktop environment, (2) a text editor, (3) a web browser, and (4) probably NetworkManager. In practice, this is a matter of uncommenting three or four lines from the template that nixos-generate-config gives you. Then after the install, you go about making everything comfy, just like with any other distro.
There are still debates in the community over what the stable distribution is "for", so you may occasionally see some inconsistencies in what gets bumped and what doesn't.
[1] https://guix.gnu.org/manual/en/html_node/Miscellaneous-Servi...
The OS configuration of Guix is declarative, like that of NixOS:
https://guix.gnu.org/manual/en/html_node/Using-the-Configura...
However, it was designed to be more hackable and easy to inspect, which is facilitated by the fact that it's integrated in a general-purpose language.
As an example, that allows the `guix system` to verify properties before you deploy a system: that the config does not refer to non-existing file systems, that the initrd doesn't lack modules needed to mount the root file system, that there are no references to undefined system services, etc.
Inspectability is best illustrated here:
https://notabug.org/civodul/guix-explorer
Another big difference is that the relation between services in Guix is explicit, as can be seen above. Conversely, a NixOS service can modify anything in the whole system config, which can make it harder for users to understand how the final config came to be.
Side effect (NixOS users will understand): someone writing a Guix service doesn't have to worry about `mkIf` and other contrived constructs, they won't even have to care about fixed points and infinite recursion. :-)
What about application files? I.e. backing-up/restoring firefox. In it's simplest form it's copying ~/.mozilla which I appreciate is no different than copying a dot file. Does nix have a way to restore app artifacts?
> Does nix have a way to restore app artifacts?
Not really. The Nix store is read-only, so if your dotfiles are in the Nix store, running applications can't write to them. There's a lot of stuff in ~/.mozilla that Firefox expects to write to during operation. There are aspects of Firefox that you can configure in Nixpkgs, including bundling extensions and setting defaults, but ~/.mozilla is not like ~/.vimrc, so it's not suitable to generation by Nix in the same way.
At least for me, this is even better than backup/restore. Generally I don't want to preserve cache or cookies between installations, I just want my config there.
Yeah, I agree. NixOS even includes a module for easily hosting your own Firefox Sync server, too! So I guess in terms of use cases the solution is actually more or less complete.
2. you don't need to "translate" any existing config files, it's perfectly fine to use them as-is.
Either you write the dotfile directly in your config (Nix syntax) or you write the file like normal, and then tell HM to store it. I like the second version better, as I find it more natural.
The problem with the "baking" approach is that it is very annoying to do a small change to a config: you have to rebuild the system every time.
[1]: https://rycee.net/posts/2017-07-02-manage-your-home-with-nix...
What are obscure programs few people need or use?
Thinking back about my studies in computational linguistics, Praat and Wavesurfer popped into my mind.
Both available. Wow. That's seriously impressive.
That is, if I did replicate the more important pieces of my current environment, could I then install NixOS and replicate that state to bare metal with minimum downtime?
The environment itself worked fine on both OSes, but if you're not sure if you'll like it, trying it on NixOS is way safer than anything else.
The base setup works fine though, I've only had some core functionality break once, and that was after an upgrade to a new NixOS version - the progress display integration thingem for the file manager was broken.
Arguably dom0 of QubesOS really ought to be NixOS, too. Maybe in 4.2?
(P.S. Loving this BSaG blog!)
Or what Arch has become.
But I want to believe
I do wish our line of work would formalize into an international guilds so apprentices help learn to maintain this stuff on their way to becoming "journeymen", somehow.
What has Arch become? I've been using it for 10 years and the only thing I can think of that has changed is the init system.
Using Arch as a server can be a headache. Just today I updated a Arch VM running postresql. Postgresql needs to previous version present to do the upgrade. I had actually skipped a version (11 to 13) so Arch no longer had version 11 in the repos and old packages had broken dependencies.
I ended up just installing the Nix package manager on the system. I started a shell with Postgres 11 & 12 both present to do one upgrade. Then I used another shell with 12 & 13 to do the final upgrade. It took like 10 minutes vs the hour I had spent trying to rollback packages on Arch.
> We told you Arch would be bad at this
does not refute (or even contradict)
> Arch is bad at this
The cost of Arch's KISS philosophy is a system that is uniquely brittle among Linux distros in a number of ways, and Arch users are totally unwilling to admit this except in the form of blaming users for having bad experiences.
It's an operating system, not a disney movie. Not sure what sort of redemption arc you are waiting for. If you are curious, try it. If not, then don't. What's all this business about believing ?