devpod

st thread on the GitHub Project; saving to the server runs the (container,command) Actions with that revision of the git repo. Somewhat-equivalent GitOps CI Continuous Integration workflows (without Bazel or Blaze or gtest or gn, or GitHub Enterprise or GitHub Free due to the kids' intererests) that might be supported at least in analogue by Education and Chromebooks: k8s with podman-desktop in a VM, Gitea Actions (nektos/act; like Github Actions), devpod devpod: https://github.com/loft-sh/devpod : > Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use any cloud, kubernetes or just localhost docker. (with devcontainer.json, like Github Codespaces) devcontainer.json is supported by a number of tools; e.g. VScode, IntelliJ,: https://containers.dev/supporting repo2docker has buildpacks (like Heroku and Google AppEngine). repo2docker buildpacks should probably work with devcontainer.json too? repo2docker docs > Usage > "REES: Reproducible Execution Environment" describes what all repo2docker will build a container from: https://repo2docker.readthedocs.io/en/latest/specification.h... jupyterhub/repo2docker builds a Dockerfile (Containerfile) from git repo (or a Figshare/Zenodo DOI) that minimally has at least an /environment.yml and /example.py (and probably also at least a /README.md to start with), and installs a current, updated version of jupyter notebook along with whatever's in e.g. /environment.yml per the REES spec. [1][2][3] [1] repo2docker/buildpacks/base.py: https://github.com/jupyterhub/repo2docker/blob/main/repo2doc... [2] "Make base_image configurable" https://github.com/jupyterhub/repo2docker/commit/20b08152578... [3] repo2docker/buildpacks/conda/environment.py-3.11.yml: https://github.com/jupyterhub/repo2docker/blob/main/repo2doc... [4] "When to use [TLJH or Z2JH]" https://tljh.jupyter.org/en/latest/topic/whentouse.html SLSA; Supply-chain Levels for Software Artifacts: https://security.googleblog.com/2022/04/how-to-slsa-part-2-d... https://slsa.dev/blog/2023/06/slsa-github-worfklows-containe... How do ContainerSec, DevOpsSec, and UI/UX apply to getting a perhaps necessarily at least sometimes restricted set of containers provisions to support STEM lab module workflows for learning? 1. Instructor: Specify e.g. docker.io/busybox:latest, and docker.io/buildpack-deps:container_tag as the necessary containers for the course/module/day 2. Student: Login to that context (as allowed by domain policy if necessary), have the container images pulled according to idk like a syllabus.yml before the schema.org/CourseInstance :eventSchedule :Event begins or at the start of class per a distributed URL/QRcode. 3. Student: Review and manage which containers are running with something like the podman-desktop indication bar applet. 4. Student: git push a repo of notebooks to be graded with ottergrader, okpy, nbgrader (and get feedback on a Pull Request) Gaps/Challenges/Opportunities: Instructors don't have CI workflows implemented in curricula, but easily could create a git repo that works with repo2docker and/or devcontainers.json. Education Organizations don't have control over which containers are running on students' managed workstations, do have such monitoring for which apps are so errantly provisioned; and so students don't have containers but do have apps. Android Apps are installed as APKs, which are a ZIP file with a manifest. Binaries on Android devices will not run without SELinux labels. SELinux labels for executables on Android can only be granted by (root or) a the process that installs the APKs. This means that other installers like pip and apt (in Termux or any app off the Android Google Play Store with the new SDK) cannot work in an Android App in a VM on a Chromebook. This means that e.g. Termux could work from the Play Store only if they repack every installable package as an APK on the Play Store. Python is installable with Termux on Android with Fdroid; but the Fdroid Android App repository ("Allow third party sources" (with a different cert trust root)) doesn't work on Chromebook Android, so FWICS you can't install Python with Termux apt on a managed Chromebook, and you can't keep sideloaded APKs from Fdroid updated with an unmanaged Chromebook: a [Google] dev would just use containers in a VM (or CI) instead. JupyterLite and VScode.dev work in a browser tab because everything is compiled to WASM (WebAssembly), but the browser traps shortcuts like Ctrl-P. So then you might say, "wrap JupyterLite in Electron or similar so it works offline as an app with all the keyboard shortcuts that you need". (Electron apps run a web app locally in a browser without the chrome (the address bar and back buttons); but if 5 apps each depend upon unique copies of Electron that they must repack and that users must keep updated, app sizes are suboptimal due to lack of a proper package dependency model for Android APKs.) Flatpack is neat, supports package dependency edges, and supports having multiple versions of a package installed, but most flatpaks have similar boundary violations where the guest container is insufficiently isolated from the host machine. VScode flatpak, for example, can call commands on the host with `flatpak-spawn` or `host-spawn` or the additional package for the vscode flatpak copy of the `podman-remote` go binary. distrobox and fedora/toolbox make it easy to mount your entire $HOME into the container with the correct UID and file permissions: `distrobox create arithmetic; distrobox enter arithmetic` provisions a container and opens an interactive shell within the container. ChromiumOS's zygote messages also cross container/vm boundaries IIRC. gvisor is considered good enough to contain containerized workflows for shared multitenant workloads at Google; and so it should also probably be useful for getting devcontainers.json and at least vscode working on Chromebooks for the kids.

, with many more features to come. I've gotten tons of good feedback from folks here in the past for other OSS projects, so I'm hoping to get some thoughts on this new project today. What do you think? Open for any feedback - even if you think DevPod sucks, let me know.