Hi,
I am a 3d artist who works in the Architectural Visualization field. My work is primarily done in Blender and a bit of Davinci Resolve and Krita. Currently, it is done on Arch due to me needing up to date packages.
Recently, my Arch system broke and I had to reinstall. This prompted the thought of NixOS as I heard it has good stability while being a rolling release. I also really like the declarative nature of it judging by some videos on YouTube I have watched.
So my question is NixOS a good distro for artists? It seems to be mainly targeted toward developers which I am not one. I have a bit of programming experience in Python and Bash for Blender plugins and automation on my system, but that is the extent of my knowledge.
Another concern I have is all the drama around NixOS. Does this impact anything in any kind of way? It seems to have far more drama that something like Arch.
Those apps work fine, resolve might be annoying depending on what GPU you have, but if you got it working on Arch it should continue to work on NixOS as they’re both just Linux distros at the end of the day.
I’ve little experience with the plugin ecosystem for these apps, though, so I can’t comment on that.
You may find the configuration syntax a bit challenging at first, it’s quite unlike imperative languages. I don’t think NixOS is any more targeted at any particular demographic than Arch, is, though, and besides the initial learning curve I don’t think someone competent enough to do bits of programming and manage an Arch install should struggle.
The distro is definitely different - you’ll have to get used to not editing files by hand. But you sound like you’d manage. For artists in general? I’m not sure I’d recommend either of Arch or NixOS, neither is suited to someone who doesn’t like getting their hands dirty.
I think that’s just perception because the forums are more accessible and the distro is newer/seeing more growth. Arch had its fair share of flame wars when it was the new kid on the block.
You can largely use NixOS while ignoring the community, if that’s your preference, though the distro does by nature of how it functions encourage upstream contribution much more than Arch.
Nix (including Nix-on-Arch, for the part of the setup that you let it manage; however, I would expect GPU setup to be lots of work for Nix-managed applications on non-NixOS Nvidia GPU with proprietary drivers) is good at rollbacks and at sidestepping most of the package conflicts (as in, you can have two programs running at once that require different versions of glibc).
The idea in terms of declarativity and rollbacks is indeed «reboot after update should be as close to a reinstall that keeps $HOME and /var/ as possible» (of course a lot of stuff can be updated without reboot).
So you can write code, and learn new programming languages. This probably puts you closer-than-the-median to developer (among the desktop Linux users) by now.
You should probably consider your system configuration to be a plugin for a codebase in a weird programming language with its own weird library. It’s even true. You won’t develop large pieces of code with complicated architecture there unless you actively want to, but there will eventually be a bit of messy but not-too-complex code.
Note that this means that almost anything that has ideas about how plugins are installed imperatively now needs to be adapted to the declarative management of the same. Nix is a bit extreme in terms of read-only package directories after installation, so it is not always simple. You should check (maybe in a VM) if there is any plugin support for packages where you need it, and maybe be ready to imitate the existing plugin packaging to add the plugins you need. (Hopefully the big picture is there and you will just need to copy-paste then fill in the source and the dependencies).
Having «Help» and «Meta» in the same Discourse frontpage feed by default (with the same zero commitment barrier for joining in the discussion — which is obviously necessary for the Help part) probably keeps drama more active and definitely keeps drama more visible. I think the packages you need most all have multiple maintainers, so the natural risk, drama or not, of the package just getting left without any interested people capable of keeping it up to date, is lower.
I guess if drama on the homepage of the Discourse instance that also hosts «Help» is mentally hard to ignore for you, this drawback of drama could be a relevant consideration.
Be aware that NixOS has a bit of a different update cadence than Arch Linux, and it might take slightly longer for the latest update to hit NixOS than Arch.
Nix reproducibility means that a certain end-user package with a certain hash is also specifying all the dependencies it’s pulling in. Nix is really source-based, even if it also supports binary caches so that end users can almost always get away without compiling with more straight-forward setups. However, it also means that compute for building Nix packages is more demanding on the build infrastructure and it can take a bit for everything to go through PR → merge → build stages. For declaring a NixOS system, you also typically want to be on the nixos-* branches which run additional tests to help ensure that the combinations of dependencies/dependers all build nicely together, so it can sometimes take a little bit before a package update gets swooped up into a nixos-* branch.
nixos-unstable is the rolling-release-ish style branch which from my understanding is more-or-less guaranteed to get feature updates, but backports to stable branches like nixos-25.05 also generally happen with popular packages like blender. Sometimes they even land in the stable branch slightly sooner for reasons that I don’t fully understand.
The nice thing about Nix is that you can also have nix-shells or nix develop environments or devenv etc. These are ephemeral shells which install certain versions of packages. For art assets, where sometimes the version of software can change the render, I personally very much prefer to be able to have a per-project shell that encodes the exact software used in it’s production, versus a system-wide install. I will generally use the nixos-* branches for these as well, but you can technically use the nixpkgs-* branches as well which should have package-specific updates land somewhat sooner.
This also`means that «is available» is a complicated notion!
There is a PR with the new version and it is clear it just changes the version and the hash and you can reasonably easily build it locally and use it
(There is no PR, but you see a minor release with an important bugfix and it does work if you just update version and hash)
The update is in the master branch
The update is in the master branch and available from the binary cache
The update is in the unstable channel
«Almost no package conflicts» and «whatever, can roll back» mean that as long as the update looks understandable enough to you to be sure it is not malicious / super misguided, you can learn how to try it without waiting for it being in the channel and the official binary cache. (Trying PRs against Nixpkgs that you do not understand is not recommended, of course)
On the other hand, it means if you care about fresh versions, you will probably need to learn what exactly all of the above means, to be able to track and forecast the progress
I mean, in fairness, all of that is true on Arch as well. You could totally use PKGBUILDs that haven’t yet made it into the repo at your own risk, as well. Only reason nobody does that is because it’s not as cleanly exposed as nixpkgs.
That doesn’t mean we should be recommending grabbing random patches manually to your average user. I’d advise against following any of this until you’re very comfortable with the nix packaging story. Even then, at best you’re getting stuff like 3 days quicker.
I don’t think there is a meaningful difference in package update cadence between the distros. Sometimes nixpkgs will be a day or two ahead, sometimes Arch. The common automation will often make up for any difference in build speed, and even then, nix’ caching means that we’re probably compiling faster a lot of the time one way or another. At that point we’re talking differences of a few dozen minutes, anyway, the main bottleneck will always be manual steps, which are much more common in the Arch world, so if anything I expect nixpkgs to be slightly more up-to-date on average.
As a user, I think you should stick to stable, and only if you realize that a specific package updates less frequently on stable than what you need for your use case, should you learn how to grab that specific package from unstable (and maybenixos-unstable-small if you’re working in an environment where you need to desperately avoid ever being exposed to zero-days, but that’s not what you’re doing here).
You should really not be touching any of the other things as a user, those are for distro developers. Just wait the day or two for them to get stuff ready, that’s how you’re using Arch as well.
I think it’s fair to warn a new user that running the stable branches will either cause an issue with their stated requirement of “needing up to date packages” or push them into some of the corners of NixOS land that are somewhat more powerful (both in ability to solve problems and cause problems). Learning some method of installing software from multiple nixpkgs branches is definitely a rite of passage in NixOS land. In some cases, it’s easier to just run nixos-unstable and watch the thread on breaking changes.
If I were you I would first try a more stable distro and use the nix package manager, along with home-manager for declarative configuration. You can get 95% of the value of declarative configuration, all the while having a stable system that is not so alien and still having access to fresh packages as nixpkgs. Unless you want to jump in the deep end and learn through trial by fire, in which case have fun
They’re using arch, I don’t think stability is a priority
But also, NixOS is only as unstable as your update frequency, or if running stable, every 6+ months.
But yeah, if you need up-to-date packages, it’s more likely that you would want to run nixos-unstable and be able to handle some level of “breakage” (which are primarily just eval/build errors that don’t break your system, rather prevent you from upgrading until you/nixpkgs corrects them).
Yes, that is what I said. There is no meaningful difference between the rolling package set (i.e. nixos-unstable) and Arch.
To expand on my point, since it’s clearly hard to understand, I still think you should generally use stable if you’re a normal user who doesn’t want to deal with breakage, even as a former Arch user. Breakage (not bugs, but deliberate incompatible changes) is more common on NixOS than Arch IME, simply because nixpkgs also maintains a library of nix code. This breakage is usually evaluation time, so it only prevents updating, but it confuses the hell out of new users and can be annoying to deal with.
This doesn’t mean you can’t always have the latest blender on a stable install. If you don’t need stability guarantees for a specific package and always want the very latest, you set:
{
# Or whatever other mechanism you use to propagate a
# second channel, ideally via `_module.args` at which point
# this line still works
pkgsUnstable ? import <nixos-unstable> { },
...
}: {
environment.systemPackages = [
pkgsUnstable.blender
];
}
As long as you limit the number of packages for which you do this to end-user facing stuff, it’s unlikely you’ll ever run into issues, save for those caused by breaking changes to the packages themselves, which you’re explicitly opting into by doing this.
If you don’t want stability guarantees for your OS in general, you can also just run unstable, but you’ll have to change your configuration much more frequently and won’t have any update notes to guide you through that, so I don’t recommend new users do that. Doesn’t mean you can’t, and plenty of folks do.
Sure? I still think per-project shells are better for art projects, and keeping it out of systemPackages entirely, but that’s my preference.
I also don’t think it’s crazy for me to let a new user understand a bit about the cadence on stable vs unstable, nor do I really want to debate about what constitutes a meaningful difference. An Arch user makes none of these decisions, a NixOS user will need to, and based on their requirements it’s worth letting them know that they will have to reach beyond stable through some mechanism. It’s worth understanding that there are different ways, with different pro-cons.
Maybe this is important, but I’m willing to bet it isn’t. Forgive me a crotchety old-man-yells-at-cloud moment: I would genuinely challenge people running unstable to demonstrate what it is that they thing in terms of tasks that they can do on unstable, but not stable. Note: that I don’t count “running the latest version of a particular software” as a task. It’s a means not an end. I am willing to be almost every person with kernelPackages_latest couldn’t actually tell the difference day to day vs running the LTS. Obviously someone in the peanut gallery is going to say their special hardware that released 3 seconds ago is only available on the latest rc mainline, but I think that’s a tiny minority. I’m not an artist, but I do primarily run nixos for work (distributed systems engineer) I exclusively run stable, and I have never once been blocked from doing anything. I am sure Davince 19 → 20 has some features, but are people really changing their workflows so much every month that they need to be on that cadence?
We see a lot of people pass through here sad because they jumped on unstable and then found themselves having to ride the train of breaking changes. I’m absolutely team stable (unless you developing nixos).
EDIT: fwiw I think informing people of their choices is great. I just wish the community at large didn’t bias so heavily towards ricing the bleeding the edge.
Call it a difference of opinion, but I generally think telling people what they want to do is stupid just doesn’t get us very far. I suppose that’s my “old man mellows out with age” moment. I’m generally much more open to telling people that xyz isn’t the tool for the job, or asking if the goal is really what they’ve asked and if they’re open to a different way.
Yes? I’ve definitely run into some issues or missing functionality with software (resolve specifically, even) that motivated me to use the next version. (With backups, since switching versions mid-project is always risky.) Or you might work on a team where everyone must have the same version (at least the same major version but sometimes more granular).
Version releases have new functionality, that’s why (other than marketing) companies bother to release new versions of software.
I don’t think engineering is anything like video editing or illustration w.r.t software used. Engineering is by design (and by law) a slow-moving discipline, the latter is quite the opposite.
And I don’t think it’s anyone’s job to demonstrate to a random individual on the internet why their usecase is necessary before getting help.
Yep, I think it’s worth explaining, so hence I expanded on it. Your initial comment just reads like getting an up-to-date Blender would be difficult on NixOS, which I think is far from true. The extra context from @7c6f434c made that seem even more complex.
See my other comment on the two alternative approaches that I think a relatively novice user could use to accomplish that, and my opinion on which I think they should take. That doesn’t work out of the box, to be fair, I should get around to that FAQ entry on the wiki I wanted to write about this.
Edit: Added an FAQ entry - we should probably work on cleaning up that page, and create sub-pages for each heading, instead of what that currently is. But that’s a separate issue. I’d also like a heading on npins, but I’ve not used them and I think they’re anyway still a bit too complex to use ootb because there’s no support for it in nixpkgs itself.
Thank you all for responding. All of this really helps.
The primary up to date packages I need are drivers. I have a Nvidia GPU and Wayland. The experience on Debian with Nvidia is terrible. I know NixOS 25.11 is right around the corner so that will likely have the drivers I need to have a good experience on Wayland.
I might try Nix on Arch. I heard home-manager is really good at managing the user space overall and integrating with other things like SystemD.
I don’t really care about the drama. My concern is Nix in the long-term. I originally heard about all this drama last year. Like the founder stepping down, core mantainers leaving, criticisms with the SC. moderation team, and Determinate Systems. All of these impact the project. This has been the most drama I have even seen any FOSS project have. I just don’t want to be running NixOS one day on my systems and NixOS suddenly vanishing.
Ah. Yeah, that’s the easiest way to run into issues on NixOS, and frankly linux land in general.
Things have gotten a lot better, but depending on the specific GPU and whether you use PRIME or not it may be nontrivial.
Feel free to reach out if you end up needing a hand, I think I’ve figured it out properly for modern GPUs, and while I’ve attempted documenting things there’s still a lot that just isn’t easy to write down.
I’d definitely recommend unstable with that setup, at least initially, it’s possible to get the latest drivers on stable (I do that), but it takes some downstream work.
Maybe I should upstream a “latest” driver for stable and actually make sure that stays maintained…
So I am a 3d artist and I used to use nixos for quite a bit so here is my experience on it:
Blender works well as long as you use blender-bin from nix warez
All blender plugins work ofc
Davinci works well as well except if you rely on reactor for davinci, reactor does not work in my experience
Krita should work as well tho I didnt use it much
So most of your software should indeed work.
I am also gonna mention why I eventually left it as this part prolly will relate to you as well:
I moved my compositing part to nuke, now the issue is nuke doesnt run on nixos and gd trying to get distrobox run with nvidia drivers and cuda (couldnt do it myself nor find resources on it)
Same as above but I wanted to move my texturing part to mair
Also same as above lol but I needed speedtree.
So hope this helps, I would say nixos is friendly to artists as long as you dont need the industry standard
I would broaden this to say “as long as you don’t need software you can’t independently compile downstream”. This is true for a bunch of software that isn’t “industry standard”, too
Running proprietary software can indeed be painful; this shouldn’t be all too surprising, your software vendor almost definitely targets ubuntu and you probably can’t expect it to work on other distros reliably (even Arch will run into ABI compat issues whenever there is a gcc update).
You do have options besides distrobox, though, e.g. steam-run would probably work for the type of software you mention. Definitely less plug-and-play than other distros if your vendors don’t target NixOS, though.
I guess here’s another FAQ page to write; the list of workarounds for running precompiled binaries targeting FHS distros.
