Is there a fundamental reason why Rstudio_Server seems to be the way Rstudio is run by pretty much everybody, rather than starting a Desktop with standalone Rstudio?
We have Rstudio installed on our systems, available through Thinlinc, including running it within an interactive Slurm job launched from Thinlinc. The same mechanism - load an rstudio module and launch - works just as well by letting OOD create the interactive desktop, and I wonder if I’m missing something that would make that a bad idea.
I apologize that I’m answering with a question, but are you asking why some centers use Rstudio as a standalone interactive app that launches rather than just running an interactive desktop that has rstudio on it?
Yes, I think that’s a good rephrasing - I’m asking if, instead of launching Rstudio_server in order to provide an Rstudio IDE to a user, it’s reasonable to use OOD to launch a standalone Rstudio within an XFCE (e.g.) Desktop.
We have users who like the OOD interface (they like it a LOT, THANKS!) but who want a more easily personally customizable Rstudio IDE. For instance, they want to be able to load LMOD modules and have them carried into the Rstudio session. That particular problem seems difficult with the Server, but easy with the standalone, and the standalone is as easy to launch from OOD as the Server is.
So, I’m thinking I must be missing something incredibly basic as to why all the conversation and examples and implementations are using the server.
For OSC - we use it primarily for web accessibility reasons. I.e., the web interface is more accessible than the VNC/desktop interface (which has no accessibility, screen readers cannot do anything with this).
But I feel like we (maybe just I?) found that out after the fact. Why it was initialized like that I can’t say - those folks have long since left the project. A quick spot check of our production app shows that the initial releases used some OOD mechanisms/facilities that don’t exist anymore and didn’t even have a submit.yml.erb for example (support for it came later I guess?)
I would also guess that other implementations & examples are just copying what we did initially.
Well, I guess that comes down to the center in the end. An interactive desktop works fine, but personally I don’t like them because you need to use a mouse pretty heavily and key mappings can go wonky and there’s just little things that can add up.
Running it as a standalone app that I can quickly work in and make choices at launch for compute power and length are also nice, combined with landing data output in locations i may want to use with the job composer or export. Also there’s things like if you need GPUs for what you are doing you can make that choice or whatever you need.
It sounds like your users want to run module commands while running rstudio is the issue though? This can be done from the app, we even provide a little description in the cards at OSC to show users how to do that. Here’s the code to OSC’s Rstudio app if your curious to see some of what it does:
As stated by others the first reason was due to the RStudio Server web interface being better, and more responsive, compared to VNC/XFCE/XServer setup with RStudio Desktop. This is pretty standard with any web based interface compared to GUI desktop apps. Mostly comes down to rendering and the lack of 3d acceleration for desktop apps whereas web apps have hardware acceleration locally from the browser.
Beyond that we found that RStudio Server containerized more easily, though it more or less requires containerization whereas RStudio Desktop doesn’t. We offer a base image for our users through our module system and then users can either bring their own or request specialized images from our software support team.
For implementing an RStudio Desktop OOD app you can base it off the way a lot of people have implemented MATLAB. I’ve included a link to both the apps we use at NMSU.