Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundle RStudio Desktop for Linux as a Flatpak, Snap, or AppImage #3079

Open
jmcphers opened this issue Jun 26, 2018 · 189 comments
Open

Bundle RStudio Desktop for Linux as a Flatpak, Snap, or AppImage #3079

jmcphers opened this issue Jun 26, 2018 · 189 comments
Milestone

Comments

@jmcphers
Copy link
Member

jmcphers commented Jun 26, 2018

As of this writing, we are currently building no fewer than five different versions of RStudio Desktop for Linux:

  1. for RedHat/CentOS based systems;
  2. for Ubuntu based systems;
  3. for OpenSuSE based systems with an old libssl;
  4. for OpenSuSE based systems with a new libssl; and
  5. for Debian 9+ based systems.

Despite this somewhat cumbersome matrix we still don't support many platforms and distributions.

This is a general issue with Linux applications, at least on the desktop; because of differing installation systems, packaging requirements, and system libraries, packages conforming to each system's idiosyncrasies are necessary.

Several attempts have been made to solve the problem by introducing an installation platform which encourages the bundling of dependencies (rather than relying on system versions), making application deployment on Linux more like it is on Mac/Windows. In true Linux fashion, there are many competing efforts:

Flatpak - https://flatpak.org/

Snapcraft - https://snapcraft.io/

AppImage - https://appimage.org/

We should evaluate these technologies in the next release cycle or so and see if any would be a good choice for RStudio Desktop (and in particular whether it'd allow us to simplify things or simply introduce a sixth variation!).

@btreut
Copy link

btreut commented Jul 28, 2018

what about a kind of voting/poll for getting some impression about which version would currently be most attractive?

Alexander Wilms aready provided a manifest for creating a flatpak of RStudio.

I would vote for flatpak. Who else?

@probonopd
Copy link

probonopd commented Aug 2, 2018

I would vote for #AppImage, because a properly built one will run on both Ubuntu and Fedora (and most other popular mainstream Linux distributions) out-of-the-box.

@KIC
Copy link

KIC commented Aug 3, 2018

I vote for snap as this seems to be the winning standard at least for developers. I have vscode, node and intellij via snap as well as a whole developers kubernetis single node cluster installed via snap.

@branchus
Copy link

I would vote the AppImage
Thanks

@btreut
Copy link

btreut commented Sep 5, 2018

today I found: another instruction for creating/installing rstudio flatpak. Does anybody have experiences with it?

@J-J-Chiarella
Copy link

if the straw poll is still on, I vote flatpak. It is the most "usable" to the largest group and offers the best system of sandboxing. AppImage has its pluses and is the most like a windows self-contained .exe, but there are reasons it hasn't caught on or undergone the intense development of flatpak or snap in the past couple of years.

@probonopd
Copy link

probonopd commented Sep 18, 2018

@J-J-Chiarella AppImage is seeing great momentum with more and more upstream applications using the format and is being developed actively in the community (over 3,600 stars on GitHub). Unlike the other two solutions, it is not pushed by one of the large Linux distribution companies, and hence does not have the same level of PR though.

The point, however, is: Flatpak/snap (deep system integration) one the one hand and AppImage (portable one-file apps) on the other hand serve different purposes. So why not have both.

@Enchufa2
Copy link
Contributor

Snap was designed with application stores and communication interfaces between apps in mind, while Flatpak was developed with graphical applications and runtimes in mind. IMHO, snap is best suited for servers and in general for headless devices, while Flatpak is best suited for desktops.

E.g., Fedora just released Fedora Silverblue, a variant of Fedora Workstation which is an immutable OSTree-based image + Flatpak for desktop apps (+ Fedora Toolbox to enable containerised mutable development environments).

@JBuursma
Copy link

I thank the RStudio team for considering this issue. I know Linux users are probably a small percentage of your user base & the competing standards makes supporting them hard (the fact that the first three comments gave three different preferences is so classic), so I appreciate your efforts.

Question: what problem(s) are you trying to solve by supporting another packaging format? The first sentence of this thread mentions the desire to support as many distros as possible. Which distros are not currently supported that you want to support? I don't see Arch there, but I believe RStudio is in the AUR. So... Slackware? Puppy Linux?

In my mind, the biggest pain point of the current RStudio packaging approach is not which distros are supported (I mostly live in deb land, so I'm feeling sufficiently supported), but greater user-friendliness. I would love a packaging format that was able to update automatically without having to manually redownload a binary from the RStudio download page every so often. I know that both snap & flatplak have this feature (although for some distros you might have to manually run snap refresh or flatpak update). Does AppImage?

I also think AppImage is less broadly user-friendly in that it doesn't automatically install to the system menu like snap & flatpak do. Downloading, chmod'ing, and running from the terminal means it might be great for power users & certain specific use cases, but be otherwise less friendly. (Different purposes, as probonopd says.)

Again, thanks for your consideration and your great software.

@jmcphers
Copy link
Member Author

what problem(s) are you trying to solve by supporting another packaging format?

  1. Reduction of the number of platforms we have to build and test for. A relatively self-contained image would reduce development complexity and allow us to better focus our testing efforts.
  2. Insulation from system dependencies. External libraries change in incompatible ways often on Linux; a recent example is libgstreamer-0.1, which RStudio depends on, but which Debian removed in Debian 9. When Debian removed it, we had to scramble to make custom Qt 5 builds compatible with Debian 9, and produce a new, separate RStudio release for Debian 9 users. Most of these package formats bundle dependencies to an extent, which helps slow down the treadmill.
  3. Improved installation (and possibly upgrade) experience for end users: just download and run it, like you can on Mac and Windows. If you're on a non-mainstream distribution, or an usually old or new one, or have trouble with dependencies, installation can be a challenge. Most of these alternative packaging formats help provide an escape hatch for this long tail.

@wilx
Copy link

wilx commented Nov 26, 2018

Gstreamer 0.1 has been dead for years now. Why are you depending on technology that has become obsolete in 2012?

@jmcphers
Copy link
Member Author

jmcphers commented Nov 26, 2018

We aren't any more, but old versions of RStudio needed it since they were built on (even older) versions of Qt, which in turn included (even older) versions of QtWebKit that required it. RStudio 1.2 uses QtWebEngine instead, which has no libgstreamer dependency.

@JBuursma
Copy link

It's always a bit "brave" to drop support for a format you've already been supporting, :-) and I'm not sure whether any of these three new choices would extend well to a "non-mainstream distribution, or an usually old ... one". But, I would think that supporting Flatpaks or Snaps going forward would at least reduce the number of new strange configurations you might have to add. For example, if a situation like that with libgstreamer-0.1 ever happened again, you could decide not to create another deb format and direct people to a Snap package (for example) instead. It's hard for me to imagine most users not preferring that to another deb or rpm to manually download.

@probonopd
Copy link

I would love a packaging format that was able to update automatically without having to manually redownload a binary from the RStudio download page every so often.

Check https://github.com/AppImage/AppImageUpdate/

I also think AppImage is less broadly user-friendly in that it doesn't automatically install to the system menu like snap & flatpak do.

Check https://github.com/AppImage/appimaged or https://github.com/TheAssassin/AppImageLauncher/

@btreut
Copy link

btreut commented Dec 7, 2018

I have tried the manifest of Alexander Wilms for creating a flatpak for RStudio and have tried to write up, what I did in the Endless community forum. RStudio works in Q4OS (which is a Trinity based Debian clone). Now, after having found the infos about Single-file bundles, I am trying to create a rstudio flatpak bundle. If I succeed and it works on Endless, I will provide it for some limited time for testing.

@btreut
Copy link

btreut commented Dec 11, 2018

I was able to install the rstudio bundle in endless. It starts up without problems, but since I am still a R newbie: is there any test suite, which I could use to check that everything (or better most things) are running correctly?

In any case: everybody who is interested is invited to fetch that bundle from here: ftp://ftp.lrz.de/transfer/flathub/rstudio.flatpak. It will stay there for some weeks, but it will be deleted by our central site admins without notice if they need the space. Beware: if you do a directory listing of the parent, i.e. ftp://ftp.lrz.de/transfer/ you will not see anything.

@probonopd
Copy link

probonopd commented Dec 11, 2018

Now, after having found the infos about Single-file bundles, I am trying to create a rstudio flatpak bundle

Have you looked into the AppImage format as well? These are single-file bundles that can actually be executed without the need for installation or special management tools. Just download, make executable, and run. Optionally users can, if they so desire, extract the contents from the AppImage.

@btreut
Copy link

btreut commented Dec 12, 2018

No, I did not look at appimage. I need flatpak, since afaik it is the only package format for EndlessOS.

@probonopd
Copy link

I have never tried Endless OS (because my Acer computer that was advertised to come with it turned out to come with a broken Linpus Lite Linux instead) but possibly AppImage might work there, too.

@btreut
Copy link

btreut commented Dec 12, 2018

hmm, for me it was the other way: I expected linpus and got endless. May impression is: EndlessOS is fascinating system despite it supports only flatpak out of the box. Maybe I could pack AppImage on top of flatpak, but honestly I think this would be a kind of an overkill, since both intend to solve similar problems ...

The people of flathub say that they would prefer a pull request from upstream. I think this is quite reasonable. But since there was no progress since months, I tested Alexander Wilms yaml manifest on my own with quite some success, see my notes in the Endless Community Forum. But I would prefer to run some kind of test suite before saying: RStudio flatpak runs flawlessly.

@btreut
Copy link

btreut commented Dec 17, 2018

RStudio flatpak runs at least on two quite different platforms, see some test results at R Studio Community using R4DS as tutorial.

@btreut
Copy link

btreut commented Dec 20, 2018

You can download the rstudio.flatpak and join testing, see my previous post for the ftp-address.

@Enchufa2
Copy link
Contributor

Thanks, I'll try to find some time to test this and provide some feedback the next week.

@Enchufa2
Copy link
Contributor

Enchufa2 commented Dec 26, 2018

I've tried it and it seems to work ok (Fedora 29, R 3.5.1, KDE Plasma 5.14.4, Qt 5.11.1). The only thing is that 1.2 GB is quite a lot. Why is it so big compared to other bundles?

@J-J-Chiarella
Copy link

J-J-Chiarella commented Feb 2, 2023

any news about a flatpak/snap/appimage for RStudio after the changeover to posit?

I had followed this for a little while. For flatpaks (and snaps), the problems seem to be too much. For one, this requires having a set of all of the R packages to be in the same "universe" of the flatpak. The flatpak RStudio cannot access system-installed R packages freely.

AppImage (and snaps, for that matter) will not go anywhere as formats. Forget it. Anyone technically inclined enough to run AppImages and to stay on top of updates is probably compiling programs from the AUR or on Gentoo, anyway. Snap is an Ubuntu-only thing that even its derivatives have eschewed. Forget it.

Duplicating massive numbers of libraries and destroying integration of R, RStudio, and LaTex compilers ... for what, easier installation that is sandboxed?

Or should we give up waiting after more than four years?

I would rather see the dependencies broken up and made so that rstudio can be a package on Debian's servers. In the meantime, I will make do with adding an additional software source to get the "official" binaries. These come in Debian/Ubuntu and Fedora formats. If you run something else, you are probably technically knowledgeable to figure something out for your use case. Having reproducible builds of an open-source program should eliminate 99% of the security concerns that flatpak would solve.

@ilikegitlab
Copy link

I agree with the sentiment that creating parallel universes is a support nightmare. And despite the recent hype surrounding flatpaks and snaps, they are just not the right tool here. I've never understood why some projects don't work with downstream packagers more. They are free developers in a sense. You should facilitate that, not work against it.

The really bad issue (that I rather have a few bug report about) is that Rstudio is drifting to become so hard to build from source in a correct way that it will be soon removed from several distributions. Electron is mostly to blame for that.

@btreut
Copy link

btreut commented Feb 3, 2023

@J-J-Chiarella and @ilikegitlab there is an increasing number of distributions with immutable root filesystem and container technology for packaging applications, e.g. EndlessOS, Fedora silverblue, and SUSE alp. With these distributions it is impossible to use RStudio.
I am using EndlessOS as my main distribution, but when I want to use RStudio, I have to reboot to a standard Debian derivate, which I find quite annoying.

@ludvigng
Copy link

ludvigng commented Feb 3, 2023

For one, this requires having a set of all of the R packages to be in the same "universe" of the flatpak. The flatpak RStudio cannot access system-installed R packages freely.

Depends on where they're installed (and what they're built against I guess). In theory you should be able to access the entire host through /var/run/host if the flatpak is given host permissions. The bigger issue is for compiling packages, where you'd need the entire build environment accessible, which could be done with a runtime extension for the rstudio package.

Having reproducible builds of an open-source program should eliminate 99% of the security concerns that flatpak would solve.

Just a note, but the main point of using flatpak usually isn't for security. It's reliability for the developers, since they have a common runtime environment to target, rather than having to do workarounds for every distro and their releases. Reproducible builds do nothing to solve that.

@znmeb
Copy link

znmeb commented Feb 3, 2023

@J-J-Chiarella and @ilikegitlab there is an increasing number of distributions with immutable root filesystem and container technology for packaging applications, e.g. EndlessOS, Fedora silverblue, and SUSE alp. With these distributions it is impossible to use RStudio. I am using EndlessOS as my main distribution, but when I want to use RStudio, I have to reboot to a standard Debian derivate, which I find quite annoying.

I've never used EndlessOS or SUSE alp but I have used Fedora Silverblue, and if I recall correctly it was possible to install third-party RPM packages. That said, Posit probably needs to evaluate the payoff-to-effort ratio of packaging RStudio Desktop as a Flatpak and supporting it. The fact that there doesn't seem to be a community-contributed Flatpak already makes me suspect the payoff-to-effort ratio is low.

RStudio Desktop already runs on Debian, Ubuntu, Fedora and OpenSUSE, and it's in the Arch User Repository. Computers aren't very expensive; someone who needs both RStudio and Fedora Silverblue can easily set up an inexpensive RStudio Server and browse to it from their Silverblue desktop.

@ludvigng
Copy link

ludvigng commented Feb 3, 2023

I mean, that packaging effort needs to be weighed against the packaging effort of targeting those 4 different distros and the different releases they have, instead of just targeting one singular environment that doesn't change (freedesktop runtime has 1 release per year, but you can still target older runtimes, gnome has 2 per year and KDE is somewhere in between I think) and which would enable them to run on many more distros as a bonus. In the first post they outline that they're already bundling a lot of stuff to make this easier, but that it still takes work to ensure they stay compatible with whatever changes the different distros make.

@znmeb
Copy link

znmeb commented Feb 4, 2023

@ludvigng The packaging effort for amd64 for the open source version is already done and fully automated and set up with Jenkins. Push a couple buttons every time the source changes and all the tests run. Presumably the effort would be to build the same infrastructure for a Flatpak but they'd still have to test a bunch of places.

As an end user I'm fine with browsing to an RStudio Server, which you can get packaged for you as a Docker image from at least two places - the Rocker project and the OpenCPU project. That also has the advantage that if I need something beefier than my laptop I can stage a cloud server to run it. But Intel NUCs are so inexpensive I wouldn't bother with the cloud.

@ludvigng
Copy link

ludvigng commented Feb 4, 2023

Presumably the effort would be to build the same infrastructure for a Flatpak but they'd still have to test a bunch of places.

AFAICT, they already provide this on flathub, I think?

@btreut
Copy link

btreut commented Feb 4, 2023

AFAICT, they already provide this on flathub, I think?

yes the infrastructure is there, but the automation has to be set up. Some work has been done, see
https://github.com/HarryMichal/rstudio-flatpak and flathub/flathub#2597 but both appear unfinished.

@znmeb
Copy link

znmeb commented Feb 4, 2023

AFAICT, they already provide this on flathub, I think?

yes the infrastructure is there, but the automation has to be set up. Some work has been done, see https://github.com/HarryMichal/rstudio-flatpak and flathub/flathub#2597 but both appear unfinished.

Ah, so there is some community work towards this goal. I was building RStudio Server from source for Arm Linux for a while but abandoned it because the build process required third-party binaries that only exist for amd64. Sure, those components are open source and I could build them, but the payoff-to-effort ratio dropped below my personal threshold.

@ludvigng
Copy link

ludvigng commented Feb 4, 2023

Yeah, and I believe the main problem with those builds were how to manage R packages. Because if you want to build those from source you're going to have to include much much more in the R-studio flatpak, which is why I've suggested to make those dependencies as an extension like this podman extension for vscode or these extra crosswords for a crossword app. Combine with something like this COPR repo that supplies compiled versions of r-packages, and you have something pretty nice for end users.

People who want to develop packages or install them from source can install the build extension to the r-studio environment, people who just want to use r-studio for analysis can just use the r-studio flatpak without the extension and potentially install already compiled r-packages from a cran repo that targets the flatpak runtime, the r-studio devs can just target whatever runtime they like and know it'll work on pretty much any linux distro regardless of version, everybody is happy.

Personally, I've currently settled on running that COPR repo in a fedora container with r-studio for myself, but it's not really a good solution for people who just want something simple.

@znmeb
Copy link

znmeb commented Feb 5, 2023

@ludvigng The simplest solution for the end user not running a supported RStudio Desktop OS is an Intel NUC running RStudio Server. Do they have battery-operated ones? :-)

@firefoxlover
Copy link

firefoxlover commented Mar 12, 2023

To this day, Flatpak runs on all systems (even though Ubuntu needs like 3 commands to enable it), Appimage doesnt and Snap also doesnt.

Appimage

  • requires an outdated version of libfuse and has major issues because Devs try to avoid that
  • lack desktop support without a permanent service checking for changes, being a bit invasive in my eyes
  • They are very fast on their own, but dont share any libraries, which is suboptimal especially on low RAM
  • No repository with pgp verification e.g., being basically as insecure as Windows apps
  • no containerization natively, no GUI way to do it, not intended to do

Snaps

  • require system-level modifications of the filesystem, so they dont work on Fedora Silverblue/Kinoite or OpenSUSE microOS
  • There is no way to have an own snap store, so there are no free and secure repositories. People are forced to trust a closed source platform not to track them or change the apps updated there
  • They are often slower
  • Choosing to develop only them would be very controversial, as Canonical kind of tries to block off other package formats and forces users to use Snaps often (even if that may be comfortable, it still is a closed source repo)
  • No GUI containerization, not as easy as with Flatpaks

Flatpak

  • pretty easy to build (a file is already existing!)
  • easy setup on all distributions
  • userspace, no root requires (except for installing flatpak and adding repos)
  • very fast
  • good desktop integration, Appstarter, Theming, context menu
  • not controversial, free repos and the ability to have your own
  • cryptographically signed, secure updates, autoupdates possible
  • Good integration into GUI appstores

I vote for Flatpaks. On Fedora Kinoite I still have to use the .rpms which sucks a bit. Thanks for your work!

@firefoxlover
Copy link

You can use RStudio on OpenSUSE microOS (never heard of ALP) and Fedora OStree using their commands

OpenSUSE:

transactional-update pkg in packagename.rpm

Fedora OSTree:

rpm-ostree instrall packagename.rpm

@gianni-rosato
Copy link

I don't care how big a Flatpak package for RStudio ends up being, I'd use it. +1 for Flatpak being the only real option for a universal packaging format

@firefoxlover
Copy link

firefoxlover commented Mar 28, 2023

current workaround for me is to use Distrobox.

echo "alias rstudio='distrobox-enter Fedora -- rstudio'" >> ~/.bashrc
echo "alias rstudio='distrobox-enter Fedora -- rstudio'" >> ~/.config/fish/config.fish
distrobox create Fedora -i quay.io/fedora/fedora:38 #comment: updated to Fedora 38
distrobox enter Fedora
sudo dnf copr enable iucar/cran
sudo dnf install R-CoprManager R rstudio-desktop -y
distrobox-export --app rstudiodistrobox-export --app rstudio

This works on every immutable distro supporting distrobox and leaves your system untouched. Also the module installing process works well in Fedora and the COPR repo supplies all the nessecary packages. Having this seperated from your normal system is crucial, as these packages would completely blow up an image-based distro.

COPR repo

Comment: The COPR for cran is up to date, the other R rstudio-desktop are not, and these packages are in the Fedora repos. Also the cran COPR includes all R modules you would want to install.

As this concept all relies on normal installing, I guess its difficult to use in a Flatpak and very easy to use in a Podman container, that is made for exactly that. I will have to look at GUI lags.

Flatpak issues

So I try to install a package and this is completely integrated into the distro. The package gets installed by invoking the dnf command and actually using the available repos to get it. This is possibly a complete dealbreaker for Flatpak.

The Flatpak would be totally great though. It would need a different module installer, downloading the binaries to a folder inside the container, and linking some files so they work as they should. I dont think this is really difficult, but it would need a distro-independend package manager. At the moment this is the distros package manager, downloading executable binaries, nothing more.

Appimages

But this packaging should already exclude Appimages, as they are just one file. Maybe using a seperate appimage for installing modules could work, but that would need bigger changes probably not worth it. Appimages have no real use, Flatpak is just better. Shared Libs, autoupdates, appstores, custom repos, repos at all, with that comes cryptographic verification, isolation, no dependency on outdated packages.

@btreut
Copy link

btreut commented Mar 28, 2023

@firefoxlover I am experimenting with a Debian container in distrobox & Rstudio, it started quite promising, but I encountered problems with this approach. For details see 89luca89/distrobox#668, any ideas how to resolve that issue are very welcome.

PS: I followed the instructions of @firefoxlover for creating a Fedora container for rstudio with success, Although I did not try too much stuff until now, I encountered no apparent problems with it. I successfully installed the R packages tidyverse, shiny and learnr without the problems I encountered in the Debian box. It was not even necessary to install missing operating system packages with dnf (it was necessary in the Debian box to install several packages with apt), these were installed automagically by the RStudio package installation .

@gianni-rosato
Copy link

The bottom line is making a distrobox is not user friendly. It'd be much nicer to have a Flatpak app

@btreut
Copy link

btreut commented Mar 30, 2023

... making a distrobox is not user friendly. It'd be much nicer to have a Flatpak app

although I agree with the latter, I have to admit that the procedure outlined by @firefoxlover is not very demanding and worked like a charme (except that I had to replace distrobox-export --app rstudio-desktop by distrobox-export --app rstudio). It required approx. 2GB of disk storage.

@firefoxlover
Copy link

lol my commands where a mess. Should work now.

@relbus22
Copy link

@firefoxlover

echo "alias rstudio='distrobox-enter Fedora -- rstudio'" >> ~/.bashrc
echo "alias rstudio='distrobox-enter Fedora -- rstudio'" >> ~/.config/fish/config.fish

May I ask, what are these two lines for?

@btreut
Copy link

btreut commented May 19, 2023

May I ask, what are these two lines for?

to call rstudio easily on the command line (bash/fish)

@firefoxlover
Copy link

firefoxlover commented May 19, 2023

@relbus22 I echo = repeat the words in brackets. Using >> I can append the output of the echo to a file. > would write it to that file and overwrite whats there, >> puts it to the end of the file.

~ is short for the users homedir, also /home/$USER or with the manual name.

I use bash as system shell, as everything works. But fish is way nicer for normal usage, as long as I dont execute complex bash commands in it, that are just different on fish. Mainly it looks nice, has easy configs, autocompletion, better TAB preview and thats it.

So I add the alias to both my configs. The configs are loaded with the shell, as if the commands were executed manually. This means the aliases and way more are applied with the shell.

@relbus22
Copy link

I use bash as system shell, as everything works. But fish is way nicer for normal usage, as long as I dont execute complex bash commands in it, that are just different on fish. Mainly it looks nice, has easy configs, autocompletion, better TAB preview and thats it.

@firefoxlover thank you for replying. Good to learn some bash.
I have wondered for some time about fish and zsh who use linux, how do they go about installing stuff and do all sorts of shell things usually available in bash?

@relbus22
Copy link

Hi y'all,

I made three short videos to show how to install RStudio on a distrobox in a GUI way using a software celled BoxBuddy:
1st video
2nd video
3rd video

Both DistroBox and Box Buddy are available in many distros, to download:
https://podman.io/docs/installation
https://github.com/89luca89/distrobox#installation
(QT creator for linux is needed for BoxBuddy, I can't remember but I think so)
https://github.com/Dvlv/BoxBuddy

@firefoxlover @btreut Did you manage to daily drive RStudio from a distrobox? How was your experience

@btreut
Copy link

btreut commented May 23, 2023

...daily drive RStudio from a distrobox? How was your experience

@relbus22 not yet daily drive, only from time to time, since I am still learning R & RStudio. As far as I can see, RStudio is a bit demanding and it is running a little bit slow. This might be caused also by my low end notebook (Celeron N3450 and only 4 GB RAM).

@aiqc
Copy link

aiqc commented Jan 13, 2024

Flatpak seems here to stay. Devtools and mainstream apps alike have adopted it: VS code, pycharm, sublime text, podman, slack, chrome, spotify, vlc, zoom, firefox, postman, discord, etc.

Docker just put flatpak on their Q1 roadmap:
docker/roadmap#593

@firefoxlover
Copy link

firefoxlover commented Jan 14, 2024

Docker Desktop which is just a GUI client. They are not putting Docker into Flatpak, which makes no sense.

It would be best if RStudio could install the modules inside its data directory (~/.var/app/...). I think that is compliant with how Flatpak works, does not require additional packaging and does not rely on static permissions to directories outside the sandbox.

It would be best for RStudio to implement xdg-desktop file pickers, so that it doesnt need any static permissions apart Network.

QGis, another app that also uses modules and that I currently run through Distrobox, has a Flatpak that just needs some fixing.

Distrobox is another distro on top of your Distro. Extra RAM consumption and pretty inefficient. Also it has no GUI permission system and still relies on individual Distro packaging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests