I am playing around with Fedora Silverblue and openSUSE Aeon and I really like the painless updates.
Still, my daily driver for some years now is Debian, and I have a decent setup via Ansible - everything just works for me.
My question is mostly to long term Linux users, which use Linux in a professional context and jumped from a distribution like Fedora, Ubuntu, openSUSE or Debian to NixOS, Silverblue, Aeon etc.
What is your experience? How did your workflows change on your immutable Linux distribution? Did you try immutable and went back to a more traditional distribution - why? How long are you running the immutable distribution and what issues and perks did you run into?
yep…same here.
Also, I use VSCode which incorporates all the toolings that I have installed and also frequently use in a terminal. For an immutable system, I’d have to use the Flatpak version of VScode, which cannot access these toolings from the host.
So, no immutability for me now.
This isnt’t the case for NixOS. I use VsCode and all I need to do is open it by typing “codium .” after direnv loads the flake file which points to all of my dependencies. I don’t use flatpak and I’m able to provision ALL of the tooling in a way that lives with the project rather than on my machine, needing to be manually updated.
Also, on nixos you don’t have to do that if you are lazy and can just install dependencies in your global config. Yeah its less optimal, but I’m too lazy to make flake files for each project.
When you say “with the project”… you mean, you load up a typescript project, so you can use npm, etc. but you cannot use golang toolings within that same VScode window, and vice versa?
His config loads npm and stuff when he is in the project directory. So anywhere outside of that directory, its like its not installed.
This. It allows me to be incredibly flexible and granular about exactly which software is installed in which environment. I could dream up the most obsolete (or vaporware or anything in between) tech stack imaginable and bind that to a flake and lock it then not have to worry about the rest of my system being contaminated with those unusual dependencies. It’s like what Docker dev environments and devcontainers are attempting to do but 1000x more elegant and reproducible.
Lol… as someone who jumps around between toolings all the time, this is anything but “flexible” for me.
I might write an app that uses web tech for the frontend and golang for the backend, and suddenly decide to throw in a flutter version for mobile.
But if it works for you, great.
Lol!
Maybe I’m reading that wrong…if not, I’m kind of dumbfounded how you can somehow take away from what I said that this technology doesn’t make that 1000% easier than your current method.
Say I wanted to suddenly throw in a flutter version for mobile, I could just add a flutter input and output into the flake and suddenly I’d have that tooling.
I suspect you misunderstand how it works.
How does your old school manual install method make that easier?
Full disclosure: I honestly don’t care if you use it one way or another. I’m just hoping to educate you (or anyone reading along) about the true nature of the widely misunderstood tech we’re talking about.
It’s all good, man. I’m not saying that my way is the right way, and your’s is wrong, and I love being educated.
What I mean, is, I have all the toolings already there without having to set them up, once I feel I need them.
So the discussion is more about having things set up globally vs. scoped.
NixOS is hard to explain.
I also did not get it at first, but got into a 101 session at cfgmgmtcamp last year and then it clicked.
I would suggest looking at YouTube videos like this one and try to understand what NixOS really is.
It is a pity really that it is not more approachable, the project would have more success if it is somehow easier to explain to others that are new to it :).
You can actually use distrobox to set up a regular version of Fedora, set up VSCode there using the official Microsoft RPM and keep all your code in there.
I know, but then again… it’s just another layer of maintenance.
Don’t get me wrong. Distrobox is a wonderful piece of software. I use Arch inside DB to run some non-crucial stuff that’s not available in the fedora repos/copr, like lycheeslicer.
But having a working and reliable code environment is something I’d really not want to babysit.
Yeah I’ve run into the same problems, really annoying when I can’t find a workaround but it’s getting easier as time goes on