The core program is exactly the same, built from the same source code, using the same build script, just with different default settings and configs (mainly turning off all telemetry and changing the branding).
The big difference is when it comes to extensions. VSCodium does not have access to the official Microsoft extension marketplace or any of the closed source Microsoft extensions. Most Open Source and third party extensions are available, but a few will be missing, with the biggest one probably being the Remote Development tools.
I guess you can't really blame VSCode for this, but the flatpak system in general, if it doesn't allow normal filesystem access.
That said...
> There is a philosophical argument that you should avoid VS Code because it is controlled by Microsoft [...]
is to me not a mere philosophical argument, but one of harsh practical reality. Your team uses vscode, your boss might think MS actually cares about developers instead of using them as a means to an end (selling shit to the c suite)... Just say no. GoLand is the better IDE anyway.
Most tools that benefit from your current environment are lacking in flatpak. Basically any IDE is going to feel awful without the proper tools. I can't run c++ in CLion without the proper tools, and good luck installing them.
Developer setups are the foremost use case for toolbox (atomic Fedora) or distrobox [0].
Dev toolchains are infamous for pulling a ton of stuff into your system, and certain languages make switching versions a pain as well. So you install your IDE and whatever flavour of the month tools you need in a distrobox container, using regular dnf packages, and keep your base system clean. With distrobox you can give those tools a separate $HOME as well, in case they litter your main one with dotfiles and dotfolders.
If you work on a certain project long-term, you can then clone the distrobox and keep it around as-is, to ensure against breaking changes in some of your tools.
I’ve been learning Mac app development for fun and one interesting part to me is that apps by default can only read and write files inside a “app sandbox” in ~/Library/Containers/com.your.app.Name
But the process to request access to files is totally seamless to the user. If you present an “open” or “save” dialog, they can pick any file or directory and the system returns a URL object with a capability attached that allows R/W access to that URL. Then you need to save the URL+Capability in app storage if you want to access the file or directory again without prompting.
The system will also pop up authorization dialogs if you use syscalls to look around at the desktop, etc saying “AppName is requesting access to the desktop” etc. For those grants to well-known paths I don’t think you need to explicitly save a capability; the “App Sandbox” is seamlessly extended.
I haven’t needed to interact much with $PATH and subprocesses but it seems like you can spawn subprocesses from $PATH, and they inherit the app container permissions.
I looked at Flatpak and it seems like they do a similar thing with file open dialogs seamlessly granting access, but maybe totally ban executing process paths outside the flatpak container? Or maybe flatpak always runs in a chroot which makes it awkward to make subprocess spawns work because the subprocess would have unexpected stuff where it expects to find its support files?
I don’t think VS Code is a sandbox app on Mac either but I wonder if it’s more workable than Flatpak
It's indeed an inconvenience with developing with Flatpak, but assuming someone still wants to do it, here's what one can do to make it practical (as far as it can be):
Get your development tools as a flatpak runtime extensions
Try to do everything inside the flatpak'ed tool (so e.g. with VSCode, use the terminal built in it, rather than a separate one)
If you need some tooling from the host, you can bind-mount them in. Just note that they probably have to be somewhere outside /usr because that's where Flatpak mounts its usual runtime
16 comments
[ 2.6 ms ] story [ 34.8 ms ] threadI consider vscodium to solve that problem by integrating with the operating system.
https://vscodium.com/#use-a-package-manager-deb-rpm-provided...
Since Fedora 39 does not default to a flatpak in the case of VScodium, it also solves the problem you describe.
The big difference is when it comes to extensions. VSCodium does not have access to the official Microsoft extension marketplace or any of the closed source Microsoft extensions. Most Open Source and third party extensions are available, but a few will be missing, with the biggest one probably being the Remote Development tools.
That said...
is to me not a mere philosophical argument, but one of harsh practical reality. Your team uses vscode, your boss might think MS actually cares about developers instead of using them as a means to an end (selling shit to the c suite)... Just say no. GoLand is the better IDE anyway.Dev toolchains are infamous for pulling a ton of stuff into your system, and certain languages make switching versions a pain as well. So you install your IDE and whatever flavour of the month tools you need in a distrobox container, using regular dnf packages, and keep your base system clean. With distrobox you can give those tools a separate $HOME as well, in case they litter your main one with dotfiles and dotfolders.
If you work on a certain project long-term, you can then clone the distrobox and keep it around as-is, to ensure against breaking changes in some of your tools.
[0] https://github.com/89luca89/distrobox
I’ve been learning Mac app development for fun and one interesting part to me is that apps by default can only read and write files inside a “app sandbox” in ~/Library/Containers/com.your.app.Name
But the process to request access to files is totally seamless to the user. If you present an “open” or “save” dialog, they can pick any file or directory and the system returns a URL object with a capability attached that allows R/W access to that URL. Then you need to save the URL+Capability in app storage if you want to access the file or directory again without prompting.
The system will also pop up authorization dialogs if you use syscalls to look around at the desktop, etc saying “AppName is requesting access to the desktop” etc. For those grants to well-known paths I don’t think you need to explicitly save a capability; the “App Sandbox” is seamlessly extended.
I haven’t needed to interact much with $PATH and subprocesses but it seems like you can spawn subprocesses from $PATH, and they inherit the app container permissions.
I looked at Flatpak and it seems like they do a similar thing with file open dialogs seamlessly granting access, but maybe totally ban executing process paths outside the flatpak container? Or maybe flatpak always runs in a chroot which makes it awkward to make subprocess spawns work because the subprocess would have unexpected stuff where it expects to find its support files?
I don’t think VS Code is a sandbox app on Mac either but I wonder if it’s more workable than Flatpak
Get your development tools as a flatpak runtime extensions
Try to do everything inside the flatpak'ed tool (so e.g. with VSCode, use the terminal built in it, rather than a separate one)
If you need some tooling from the host, you can bind-mount them in. Just note that they probably have to be somewhere outside /usr because that's where Flatpak mounts its usual runtime