On Sat, 4 May 2024, Maciej Nasinski wrote:
Hey Vladimir,
Thank you for your answer.
GitHub codespaces are "a separate computer" and are free for students and the
educational sector.
Hi Maciej,
What I was suggesting is that instead of encapsulating the application
in a container that runs on the same physical hardware as other
containers, you would be more secure to use a dedicated computer for the
application.
best
Vladimir Dergachev
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
>
>
>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
