Hey Vladimir, Thank you for your answer. GitHub codespaces are "a separate computer" and are free for students and the educational sector. The GitHub codespaces are a cloud service that can be created anytime, with a specific setup behind it (Dockerfile, settings.json, renv.lock, ...). The machines GitHub codespaces offer are quite decent (4core 16GB RAM 32GB Memory). You can destroy and recreate it anytime you want to. You run GitHub codespaces from a web browser, but as Ivan stated, you may need a decent computer to handle them, even if all calculations are done on the cloud. I use GitHub codespaces for all my University projects with my friends. It is great that I do not have to explain many things nowadays to older stuff as many things are automatic on GitHub codespaces.
KR Maciej Nasinski University of Warsaw On Sat, 4 May 2024 at 18:53, Vladimir Dergachev <volo...@mindspring.com> wrote: > > > On Sat, 4 May 2024, Maciej Nasinski wrote: > > > Thank you all for the discussion.Then, we should promote "code > awareness" and count on the CRAN Team to continue their great work:) > > > > What do you think about promoting containers? > > Nowadays, containers are more accessible, with GitHub codespaces being > more affordable (mostly free for students and the educational sector). > > I feel containers can help a little bit in making the R work more > secure, but once more when used properly. > > I think it is not a good idea to focus on one use case. Some people will > find containers more convenient some don't. > > If you want security, I am sure containers are not the right approach - > get a separate physical computer instead. > > From a convenience point of view containers are only ok as long as you > don't need to interface with outside software, then it gets tricky as the > security keeping things containerized starts interfering with getting work > done. (Prime example: firefox snap on ubuntu) > > One situation where containers can be helpful is distribution of > commercial applications. Containers allow you to freeze library versions, > so your app can still run with old C library or a specific version of > Python. You can then _hope_ that containers will have fewer compatibility > issues, or at least you can sell containers to your management on this > idea. > > But this is not really a good thing for an open source project like R. > > best > > Vladimir Dergachev > > > > > KR > > Maciej Nasinski > > University of Warsaw > > > > On Sat, 4 May 2024 at 07:17, Vladimir Dergachev <volo...@mindspring.com> > wrote: > > > > > > On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote: > > > > > Dear Maciej Nasinski, > > > > > > On Fri, 3 May 2024 11:37:57 +0200 > > > Maciej Nasinski <nasinski.mac...@gmail.com> wrote: > > > > > >> I believe we must conduct a comprehensive review of all > existing CRAN > > >> packages. > > > > > > Why now? R packages are already code. You don't need poisoned > RDS files > > > to wreak havoc using an R package. > > > > > > On the other hand, R data files contain R objects, which contain > code. > > > You don't need exploits to smuggle code inside an R object. > > > > > > > I think the confusion arises because users expect "R data files" > to only > > contain data, i.e. numbers, but they can contain any R object, > including > > functions. > > > > I, personally, never use them out of concern that accidentally > saved > > function can override some functionality and be difficult to > debug. And, > > of course, I never save R sessions. > > > > If you need to pass data it is a good idea to use some common > format like > > tab-separated CSV files with column names. One can also use MVL > files > > (RMVL package). > > > > best > > > > Vladimir Dergachev > > > > > > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel