this post was submitted on 13 Jan 2025
358 points (94.3% liked)
Linux
49016 readers
832 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Has anyone had good success with setting up a development environment in an immutable distro? I love the entire concept because it fits with a lot of my other software preferences, but the tools for containerized dev environments felt frustrating.
Like, what do you do for your editor? vscode + devcontainers feel like the best option, but it's rough when I need other IDEs (like I use some of the Jetbrains products). Stuff like toolbox works well too, but to get an editor in that, you have to install it in each one, or make a container that has it built in.
Otherwise, I'll stick with plain Fedora — I use flatpaks for all of my apps anyways (except my editor)
i started learning rust with nixos, you can declare a shell.nix with everything needed for the environment, and those things will only be available in that folder.
there are caveats and annoyances to this like building a python environment costed me some time, because python packages sometimes require compling and all the shared libraries in nix are not in the right path (because you can have multiple versions installed) so you need to set some env vars to patch this.
nothing that gpt cannot solve.
Personally, I have found the developer experience on Bluefin-dx (the only one I’ve tried…) to be…. mixed.
VSCode + Devcontainers, which are the recommended path, are pretty fiddly. I have spent as much time trying to get them to behave themselves as I have actually writing code.
Personally, I’ve resorted to using Homebrew to install dev tools. The CLI tools it installs are sandboxed to the user’s home directory and they have everything.
It’s not containers - I deploy stuff in containers all the time. But, at least right now, the tooling to actually develop inside containers is kind of awkward. Or at least that’s been my experience so far.
I think the ublue project is fantastic and I really like what they are doing. But most of the world of developer tooling just isn’t there yet. Everything you can think of has instructions on how to get it going in Ubuntu in a traditional installation. We just aren’t there yet with things like Devcontainers.
Using brew is the recommended method on uBlue, so you're already doing the right thing.
That being said, I use Jetbrains and devcontainers on Bluefin-DX and it's been flawless for me, straight out of the box.
Hmmm, interesting. I like brew, for sure. And devcontainers worked ok for me when I was working on something by myself.
But as soon as I started working on a side project with a friend, who uses Ubuntu and was not trying to develop inside a container, things got more complicated and I decided to just use brew instead. I’m sure I could have figured it out, but we are both working full time and have families and are just doing this for fun. I didn’t want to hold us up!
Our little project’s back end runs in a docker compose with a Postgres instance. It’s no problem to run it like that for testing.
Maybe a re-read of the documentation for devcontainers would help…
I use Jetbrains, devcontainers, and distrobox on Bluefin-DX and it has been flawless out of the box. There's a single command to install the Jetbrains toolbox, which let's you then manage all their apps.
Couldn't recommend it enough, made my development lifecycle so easy.
How do you use the Jetbrains tools with distrobox? So far I've manually installed the toolbox inside my distrobox, but that doesn't seem to be the preferred approach.
No need for distrobox for that - it's a built-in
ujust
command, put there by the creators of uBlue. It really has everything you need out of the box.More info in the docs: https://docs.projectbluefin.io/bluefin-dx#jetbrains
Yes, I got that running - but how do I then allow the Jetbrains tools to use CLI tools in the distrobox?
For distrobox, you can export your CLI tools, then use them anywhere in your system:
Alternatively you could
distrobox enter
from the Jetbrains terminal.I would generally use
brew
for installing system-wide CLI tools, and use a devcontainer if I want to have a specific dev environment for a project.I do my main development with Bazzite. I use the Neovim flatpak for my editor and toolbox for builds and such.
Running cli apps like neo vim from a flatpak is frustrating... "flatpak run com.something.neovim" is just the worst way to handle things. Complete deal breaker.
Why is it a bad way to handle things?
I have an alias set up and SDKs enabled. The experience is indistinguishable from a regular install. But you could also layer it onto the os image or install it in user space if you don't like flatpaks for the extra resource usage or something. That's a complete non issue for me though.
That's not indistinguishable - that's you working around the problem of running
flatpak run some.domain.IForget
(which - BONUS is case sensitive which is awesome) to run neovim.Snaps install a binary you can run. Flatpaks make you remember the 3 part domain to run things. So you setup aliases after installing things to run them, and if you uninstall them you need to remove your aliases. It's a complete own-goal by the flatpak developers that this mess exists and is completely unnecessary. Simply providing an option to create and manage a script in .local/bin or something would be all it takes to make flatpaks usable from the CLI in a way that isn't obnoxious.
That's a good point. I should have said "indistinguishable after some tinkering". You raise a valid complaint, though it's not a deal breaker for me.