It would be the exact same amount of effort you'd use to get new software on other distros. Both Arch and NixOS have very straightforward methods of installing new software that aren't any more difficult than doing so on Debian or some other distro. Both Arch and NixOS support independent package managers like flatpak and snap + they support Appimages.
I'd also add that OP doesn't even need to use NixOS to use nix packages, whereas Arch or Debian would require systems based on those distros. So if anything NixOS tries to make it very easy to add and configure software. Where does all the effort come in?
Pretty neat. You can use this with RPCS3. Unfortunately it's probably a matter of time before Take-Two/Rockstar ruin all the fun as they've historically done with fan projects.
For what it's worth, I don't understand the nix language or all the package manager functions in their entirety. I generally use what I need and that's it. Most information I've required that is nixpkgs-specific I was able to find in the manual. home-manager has one as well and it's been the best reference for me.
If so, how does that solve the problem of clutter in $HOME ?
If it wasn't clear from my message, the problem(s) these tools are solving for me would be 1. not having to keep track of my dotfiles and their directories, and 2. not storing configuration files directly on the disk I use for the $HOME dir. I'm not claiming these tools would solve clutter in the $HOME dir. Further, I think it should be alright for me to share tools for managing configuration files in your home directory in a discussion that directly relates to that subject.
So you create a symlink from $HOME/.program.ini to something in the nix store?
Normally it's the other way around. When you use nix and home-manager, you're technically generating files that will live in the nix-store and nix/home-manager will take care of symlinking those files to locations in your $HOME dir.
My particular use-case is that I want persistent configuration files that are shared throughout a handful of devices on my network. To this end, I use some home-manager symlinks that lead to a network folder where all these various directories and configuration files actually live. I edit those configurations in a single place and their changes propagate across the network to all the devices that would use them.
You can manage symlinks pretty easy with home-manager. I'd personally setup symlinks for these app configuration directories if I don't want them storing files directly on the disk I use for $HOME. It's also done in a delcarative way that can persist across multiple computers.
Or they can keep using the same engine with the same issues because gamers will definitely buy their next title en-masse despite the previously mentioned issues. Eg. Starfield
Is this IDE going to make it impossible to install the Rust plugin in their other IDEs? Like is there anything preventing a user from continuing to use the Rust plugin and CLion after this has been released?
Almost all of these IDEs have language-specific features in them. PyCharm has Scientific tools (like SciView) for generating graphs using code and data. Rider features a pretty nice Windows Form builder for generating and creating GUIs for applications. Etc.
I can't imagine it being very useful or practical to unload all these language-specific plugins each time you open the program to write in a language that can't utilize those features.
That's correct. Even with this backtrack, it's a safe bet that they'll likely re-introduce this same policy with different wording once they believe their consumers have calmed down.
What an interesting year. This has to be the 4th or 5th large tech-centric company that's
introduced some really shitty policy
pissed off it's consumers
then backtracks to some degree after backlash
Just like every other company that's done this, the backtrack is likely meant to appease the consumers before the policy gets re-introduced later. Perhaps with slightly different wording.
Yeah, this is something I'd expect to see on Moral Orel.