

Omarchy is basically where someone takes Arch Linux and says “I want it to have this window manager, this terminal emulator, these programs installed by default and to have this configuration” and shares it with other people. Since Arch by itself is pretty bare-bones, this sort of thing can be useful for people who want to use Arch but don’t want to spend the time making a functional system. Since you’re using NixOS, I’m sure you’ve seen other people’s .nix files being shared. This is similar to that, but more formal and because Arch doesn’t make it as easy as Nix, it’s shared as its own distribution instead.
Because the goal of Omarchy is just to make something bare-bones into something immediately usable, it’s more meaningful to compare NixOS to Arch Linux directly. The most fundamental difference between the two is the package manager, so the way software installations are managed. All package managers have to (usually) download a package and, if needed, its dependencies, extract it to somewhere on the file system where it can find it, run an initial setup script, make it so that you can run the executable by name instead of needing the whole path, and do some bookkeeping so that it knows what is installed, and so, what needs to be kept up to date, what can be removed etc. But there are different approaches you can take to achieve this.
Nix, as I’m sure you’re aware, is a declarative system where you write a program (even if it doesn’t always look like one) in a functional language, and when you update the system it runs that program, which outputs what is basically a list of packages (among other things) and then it compares that list to the installed packages and installs/uninstalls/updates packages so that it matches the list.
On the other hand, Pacman, the Arch Linux package manager, is a more traditional imperative system, where you explicitly tell it to install/uninstall/update packages.
There are other differences, like how Nix can have multiple versions of the same package installed, but Pacman only supports one, and there are differences in philosophy between package repositories on when packages should be updated, whether to allow proprietary software etc.


Not every software company is a game developer, and even at home, not every programmer plays games on their PC that require a powerful GPU. If everyone working on, for example, business software all of a sudden needs a gaming PC that will be constantly running an AI model, that will greatly increase costs, both in terms of procurement of equipment and electricity. An increase in demand for powerful GPUs in fields that traditionally had no need for them isn’t exactly going to improve the hardware cost situation either.
Whether you run the model locally or you leave it to a company, someone is going to have to pay the cost.