About a year ago I started experimenting with the whole container-based workflow thing. I don’t know how much time I’ve spent on setting up various programming environments, and there’s always hurdles like getting a flatpak editor have access to java and actually be able to run javafx programs. And with distroboxes, what if my code needs access to a database that is started in a docker container on the host system, do I install docker inside the distrobox? I’ve had so many configuration issues. Every time I try I come back to debian stable and it feels like home.
Containers are over hyped. They are so stupid for home use. People put init systems in containers, then run the entire pile of shit in Docker as root, and talk to me about security and resource isolation. And then all these shit Alpine containers with that MUSL joke. You really can’t take any of it seriously anymore. These people want Windows or a mobile phone.
Flatpack is using OCI so they can publish their shit on any registry. Just another way to pollute an existing ecosystem with garbage nobody really needs. Easing the installation of crap onto your system is not a goal worth pursuing
Flatpak’s usefulness for programming depends on the IDE and language. IDEs like VSCode largely suck because they are not designed to work in flatpak. But some languages still do work well in them, such as Rust, since Flathub provides the Rust SDK and dependency management is done with cargo. But it sucks for C++, where you typically install dependencies using your system package manager.
IDEs like Gnome Builder are pretty good. It’s designed to work within the flatpak sandbox. Even when running as a flatpak, you can choose to build things using containers or your host system. And of course also build using the Freedesktop runtimes.
I recently setup JavaFX with the flatpak version of VSCodium and have it working pretty well. You first need to install the Java SDK from Flathub, set an env variable to tell VSCode to load the SDK. The more annoying part was JavaFX since it’s not part of the JDK anymore. I just downloaded the JavaFX tar, extracted to a directory called JavaFX, and set $JAVAFX_HOME to point to it. Since VSCode has host filesystem access, it can access it. Few more steps than traditional Linux, sure, but still easier than MacOS and Windows.
For JavaFX I ended up putting both JDK and JavaFX in my home dir and pointed vscodium to the right paths, I could get programs to compile but for some reason it would not let me open windows from inside, complaining that DISPLAY was not set or available iirc, even though I did set the env variable inside. Either way, I’m not ready for this container work-flow. Though I suspect that I could get used to better practices. Do you install git and your editor of choice separately in all dev containers? Like, how much of the tooling should be inside or on host?
Ah I had the same issue. JavaFX still uses X11. By default VSCode only lets X11 be used if Wayland is not available (this is the X11 fallback permission). Disabling X11 fallback will let VSCode use Wayland and let JavaFX use X11. I might make an issue for this on the flatpak’s GitHub asking for this change.
Honestly, the truth is that setting up containers for development will always be a hassle. My low tech way is just to make a distrobox container with its own home folder, install an IDE in it, and install packages. The more proper way to do it would create your own containerfile to build your container for developing.
VSCode also has its DevContainers extension but that doesn’t work in VSCodium and does some weird things.
About a year ago I started experimenting with the whole container-based workflow thing. I don’t know how much time I’ve spent on setting up various programming environments, and there’s always hurdles like getting a flatpak editor have access to java and actually be able to run javafx programs. And with distroboxes, what if my code needs access to a database that is started in a docker container on the host system, do I install docker inside the distrobox? I’ve had so many configuration issues. Every time I try I come back to debian stable and it feels like home.
Containers are over hyped. They are so stupid for home use. People put init systems in containers, then run the entire pile of shit in Docker as root, and talk to me about security and resource isolation. And then all these shit Alpine containers with that MUSL joke. You really can’t take any of it seriously anymore. These people want Windows or a mobile phone.
Flatpack is using OCI so they can publish their shit on any registry. Just another way to pollute an existing ecosystem with garbage nobody really needs. Easing the installation of crap onto your system is not a goal worth pursuing
Flatpak’s usefulness for programming depends on the IDE and language. IDEs like VSCode largely suck because they are not designed to work in flatpak. But some languages still do work well in them, such as Rust, since Flathub provides the Rust SDK and dependency management is done with cargo. But it sucks for C++, where you typically install dependencies using your system package manager.
IDEs like Gnome Builder are pretty good. It’s designed to work within the flatpak sandbox. Even when running as a flatpak, you can choose to build things using containers or your host system. And of course also build using the Freedesktop runtimes.
I recently setup JavaFX with the flatpak version of VSCodium and have it working pretty well. You first need to install the Java SDK from Flathub, set an env variable to tell VSCode to load the SDK. The more annoying part was JavaFX since it’s not part of the JDK anymore. I just downloaded the JavaFX tar, extracted to a directory called JavaFX, and set $JAVAFX_HOME to point to it. Since VSCode has host filesystem access, it can access it. Few more steps than traditional Linux, sure, but still easier than MacOS and Windows.
Not sure about your database situation though.
For JavaFX I ended up putting both JDK and JavaFX in my home dir and pointed vscodium to the right paths, I could get programs to compile but for some reason it would not let me open windows from inside, complaining that DISPLAY was not set or available iirc, even though I did set the env variable inside. Either way, I’m not ready for this container work-flow. Though I suspect that I could get used to better practices. Do you install git and your editor of choice separately in all dev containers? Like, how much of the tooling should be inside or on host?
Ah I had the same issue. JavaFX still uses X11. By default VSCode only lets X11 be used if Wayland is not available (this is the X11 fallback permission). Disabling X11 fallback will let VSCode use Wayland and let JavaFX use X11. I might make an issue for this on the flatpak’s GitHub asking for this change.
Honestly, the truth is that setting up containers for development will always be a hassle. My low tech way is just to make a distrobox container with its own home folder, install an IDE in it, and install packages. The more proper way to do it would create your own containerfile to build your container for developing.
VSCode also has its DevContainers extension but that doesn’t work in VSCodium and does some weird things.