Menu system on the left is missing the numbering (8)

docs.posit.co

Something I am missing here is the notion of Workbench being a collection of IDE's where ideally code should be developed but never really run at full scale - when it comes to scaling we probably should maybe focus on scaling for more concurrent users only and have a separate section on scaling individual codes.

For running at full scale we probably should point to continued use of Databases or even more importantly to use workbench jobs for this purpose or even run it completely non-interactively outside of Workbench on a scalable compute infrastructure (e.g. HPC cluster, dask, ...)

At some point we also should mention that I/O performance can be a big cause for performance degradation...

unless the python or R package is automatically using a parallel computing framework (e.g. DT thread ....)

maybe replace with memory ?

I think it would be good to have these exercises at least partially repeated in the RSPM module as well

Typically this is not possible with the R and Python versions provided by the OS. In order to have multiple versions of R and Python installed concurrently you will either build them on your own (possibly using environment modules integrated in EasyBuild or Spack) or use Posit provided R and Python software builds.

I think we can condense those two bullets by sayiing "A user needs a different version of R or Python because a package he would like to use requires it"

Also, I would add "A user cannot install a new R package due to missing system dependencies"

This section could benefit from significant tuning or possibly rewriting it.

While it is neat for the admin traing - how man of our customers use local user accounts (i.e. created via useradd) in our products ? I feel that most are directly going towards LDAP or AD...

Add something like that "The admins need to decide what to do with the data of locked users as part of their data management / backup policy".

replace with "stored on" ?

The diagram is ok but I wonder if we really should highlight SQLite here ? Also "OS File System" looks a bit unwieldy - I am sure we are not referring to an open source file system, right ;)

I wonder if we could simplify it by specifying * Workbench Web UI (rserver process) * Database to store metadata * various session types (jupyter, vscode, ...) (rsession process) * R and Python installation * maybe mention the workspace process

let's remove OS here

We are not talking about binary packages for all major linux distros here at all - would be worthwhile to hightlight this here as I sense this is a good selling point for PPM

Not sure if this is more misleading than helpful - maybe rephrase to "Host and manager external and internal R & Python packages in a controlled manner"

it would be worthwhile to have a highlevel overview of how all of those three products really interact with each other - maybe have a simplified version of the diagram that CS/Sales use for their introductory calls with new customers that highlights the data science journey through the product stack (e.g. workbench for the IDE, connect for hosting artefacts/outputs and Package Manager as more of an infrastructure/file share kind of service

Maybe a link to our own opinionated Python binaries would be good to have here ?

Maybe a link to our own opinionated R binaries would be good to have here ?

Maybe we should call this out a bit more by saying that the value-add of our commercial solutions is to enhance productivity and efficiency but in fact all the basic functionality is provided as open source at no charge (E.g. rstudio server, shiny, markdown, ...)

Not sure if we want to switch to "We" here.