A long time ago, when NixOS was more fun, the installer device used to have rogue running on tty8, so you could play while waiting for the installation to finish.
interestingly, this does not work on tty1. tried with rogue and btop.
on other tty - it works fine, but on tty1 - service does work, you can see program draw it’s stuff on top of boot messages still being printed, but then it switches to black screen and blinking cursor.
You can spin up as many vms or containers as you want, backup them, clone them, move them between nodes (if you have more than one). You can easily create ceph storage and use it e.g. for backups, there’s also support for zfs.
I run NixOS on my home lab. Unless you’re trying to coordinate a load of high-availability containerised servers, there’s no real point using proxmox or any other virtualisation and orchastration frameworks.
The only benefits I can see of running some enterprise ready virtualisation/orchastration/whatever system is:
The additional isolation you get from using container virtualisation (hardly needed on a home server, but also: NixOS Manual, and Security - Official NixOS Wiki if you decide you do need it).
If you know you’re going to eventually have a cluster and don’t want to have to reconfigure everything to support it.
the conflicts does fix the problem!
i wonder why this is not required for ttys other than 1.
And how exactly does it work that i state the conflicting service? why the ordering is correct by default and tty1 is not disabling my service instead?
It’s a little mysterious to me too, but I believe that systemd has some baked-in logic for tty1. It’s autostarted very early. For any other systemd conflict between services, I’d also want to add after = [ the-other-service ]; to the one that should win, to make sure that the other service doesn’t shut down that one. I’ve never needed that with getty@tty1, but it wouldn’t hurt to add.