4 ms·

The VS Code Flatpak is useless

17 points by zbentley 2y ago

theandrewbailey 2y ago
If I need VS Code, I reach for VSCodium. https://vscodium.com/ https://vscodium.com/
- nitinreddy88 2y ago
  You didn't even read the article. Did you? How vscodium solves the problem of author?
  - RunSet 2y ago
    > Ultimately, it comes down to this: Flatpaks run isolated from the host OS, which is fundamentally incompatible with developing code in an IDE. I consider vscodium to solve that problem by integrating with the operating system. https://vscodium.com/#use-a-package-manager-deb-rpm-provided-by-vscodium-related-repos https://vscodium.com/#use-a-package-manager-deb-rpm-provided...
    - davidt84 2y ago
      VSCode provides packages too. The problem is the OS defaulting to a flatpak.
      - RunSet 2y ago
        I credited the article's author with being able to summarize their problem. Since Fedora 39 does not default to a flatpak in the case of VScodium, it also solves the problem you describe.
- Waterluvian 2y ago
  Is there a complete listing somewhere of exactly what’s different between the two, both in terms of features and end-to-end experience?
  - dagw 2y ago
    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.
- lc64 2y ago
  It's not the topic of the article.
deleted 2y ago
[deleted]
isoprophlex 2y ago
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.
ramon156 2y ago
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.
- piaste 2y ago
  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. [0] https://github.com/89luca89/distrobox https://github.com/89luca89/distrobox
jitl 2y ago
On the subject of containers for security: 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
muep 2y ago
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
hackeraccount 2y ago
You can't fix the problems they're talking about with Flatseal?
- prophesi 2y ago
  Thank you for this, I knew you could configure flatpak installations but never thought to seek out a GUI to simplify the process.

17 points by zbentley 2y ago

theandrewbailey 2y ago

If I need VS Code, I reach for VSCodium. https://vscodium.com/ https://vscodium.com/

nitinreddy88 2y ago
You didn't even read the article. Did you? How vscodium solves the problem of author?
- RunSet 2y ago
  > Ultimately, it comes down to this: Flatpaks run isolated from the host OS, which is fundamentally incompatible with developing code in an IDE. I consider vscodium to solve that problem by integrating with the operating system. https://vscodium.com/#use-a-package-manager-deb-rpm-provided-by-vscodium-related-repos https://vscodium.com/#use-a-package-manager-deb-rpm-provided...
  - davidt84 2y ago
    VSCode provides packages too. The problem is the OS defaulting to a flatpak.
    - RunSet 2y ago
      I credited the article's author with being able to summarize their problem. Since Fedora 39 does not default to a flatpak in the case of VScodium, it also solves the problem you describe.
Waterluvian 2y ago
Is there a complete listing somewhere of exactly what’s different between the two, both in terms of features and end-to-end experience?
- dagw 2y ago
  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.
lc64 2y ago
It's not the topic of the article.

deleted 2y ago

[deleted]

isoprophlex 2y ago

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.

ramon156 2y ago

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.

piaste 2y ago
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. [0] https://github.com/89luca89/distrobox https://github.com/89luca89/distrobox

jitl 2y ago

On the subject of containers for security: 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

muep 2y ago

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

hackeraccount 2y ago

You can't fix the problems they're talking about with Flatseal?

prophesi 2y ago
Thank you for this, I knew you could configure flatpak installations but never thought to seek out a GUI to simplify the process.