4 ms·

But aren't devs also provided with: SSH, CI build minutes, and GCP budgets for containers and VMs? To actually dogfood Chromebooks internally like Chromebooks

But aren't devs also provided with: SSH, CI build minutes, and GCP budgets for containers and VMs? To actually dogfood Chromebooks internally like Chromebooks for Education and for Families, Google would need to deny its devs containers behind a greyed out "Turn on Linux" button and deny them access to Colab notebooks and AI platform etc (while only allowing Play Store apps); nothing to SSH to, no notebooks, no devpod, no local git repos (!), no local terminal to run e.g. pytest tests with, no devtools JS console, etc.

nolist_policy 3y ago
I'm pretty sure the grayed out "Turn on Linux" button due to policy setting by the organization managing the Chromebook.
ajross 3y ago
I don't follow? Software developers... aren't students or children. It's a different market with different product segmentation and feature sets, it just happens to run on the same hardware and OS. And it's true that schools and parents often demand that their kids not hack stuff that the "admins" don't understand. And maybe that's bad or misguided or whatever. But it's not a statement about using a Chromebook as a developer client, which IMHO works very well.
- westurner 3y ago
  The kids can't code locally on a git repo on Chromebooks and run make; they don't even have a terminal. Googlers only code remotely on Chromebooks. The kids MUST be able to run `pytest arithmetic.ipynb` on whichever platform. (It was not appropriate for Google 2016-2020 (?) to decide that we should all accept WASM runtime vulnerabilities in sandboxed browser processes running as the same user instead of per-app SELinux contexts like Android requires since 4.4+, or instead of containers and VMs like almost all of Google's hosted apps and internal systems) Cannot believe there's not even a JS console on these for the kids (because "Inspect Element" and "Turn on Linux" are blocked for them all)
  - ajross 3y ago
    I'm still not understanding the criticism. You're saying it's bad that kids can't hack on their school-supplied/parent-managed computers. And... I think I agree, as far as it goes. But you're responding to a thread saying "Chromebooks are good for Developers", where's it's just not responsive. There's absolutely no reason schools or parents can't hand kids unmanaged/unrestricted Chromebooks; they just choose not to (for some good and some bad reasons). Take that up with schools and parents, I guess?
    - riversflow 3y ago
      >There’s no reason schools or parents can’t hand kids unmanaged/unrestricted Chromebooks Holy cow. Are you serious? Kids break stuff for fun. This is basically a “You’re holding it wrong” argument. Schools are gonna have heavily managed chromebooks, because it’s the reality on the ground that they can hardly afford anything, much less insane IT support for every student. Like, kids are going to actively sabotage the software on their school equipment if they can as a way to avoid doing schoolwork. This was common when I was in high school over a decade ago, they solved it with Deep Freeze software and extremely restrictive Microsoft policies. Google is the one with a wealth of IT and developer talent, not school systems. They are making the product, not the schools. Devs have to come from somewhere, and going out a limb here, I don’t think smartphones (the other computer that [low income] students are likely to have access to) provide an on ramp for developers, so it would be good if these chromebooks did.
      - scheeseman486 3y ago
        Virtually any Linux distro can be turned into a managed OS.
        westurner 3y ago
        Something could manage access to and the run state of containers (just like APKs and other apps running without `ps -Z`) so that the state of the machine can be reset. And then an instructor could specify policy that would affect which apps and containers run on the machines attached to the management domain (e.g. at test-taking time and also all of the times) Comparing etckeeper and rpm-ostree's diffs of /etc lately (where e.g. LVM or btrfs CoW snapshots would need eventual compaction)
anonacct37 3y ago
Not exactly but the equivalent yes. Workstation and VMs. All tests and builds are basically run in borg by default. For most Google developer developing on a Chromebook basically means running ssh and chrome remote desktop.
- westurner 3y ago
  For students, unless there are allocated server resources with network access, it SHOULD/MUST scale down to one local offline ARM64 node (because school districts haven't afforded containers on a managed k8s cloud for students at scale fwiu, though universities do with e.g. JupyterHub and BinderHub [4] and Colab). For Chromebook sysadmins, Instructors, and Students learning about how {Linux*, ChromiumOS, Android, Git, Bash, ZSH, Python, and e.g. PyData Tools supported by NumFOCUS} are developed, for example; When you git commit to a git branch, and then `git push` that branch to GitHub, and create a Pull Request, GitHub Actions runs the (container,command) tasks defined in the YAML files in the .github/workflows/ directory of the repo; so `git push` to a PR branch runs the CI job and the results are written back as cards in the Pull Request 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 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 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.html#specification 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/repo2docker/buildpacks/base.py https://github.com/jupyterhub/repo2docker/blob/main/repo2doc... [2] "Make base_image configurable" https://github.com/jupyterhub/repo2docker/commit/20b081525785fdc6ac524e06150028796b8787ec?diff=unified https://github.com/jupyterhub/repo2docker/commit/20b08152578... [3] repo2docker/buildpacks/conda/environment.py-3.11.yml: https://github.com/jupyterhub/repo2docker/blob/main/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 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-details.html https://security.googleblog.com/2022/04/how-to-slsa-part-2-d... https://slsa.dev/blog/2023/06/slsa-github-worfklows-container-based 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.
deleted 3y ago
[deleted]

nolist_policy 3y ago

I'm pretty sure the grayed out "Turn on Linux" button due to policy setting by the organization managing the Chromebook.

ajross 3y ago

I don't follow? Software developers... aren't students or children. It's a different market with different product segmentation and feature sets, it just happens to run on the same hardware and OS. And it's true that schools and parents often demand that their kids not hack stuff that the "admins" don't understand. And maybe that's bad or misguided or whatever. But it's not a statement about using a Chromebook as a developer client, which IMHO works very well.

westurner 3y ago
The kids can't code locally on a git repo on Chromebooks and run make; they don't even have a terminal. Googlers only code remotely on Chromebooks. The kids MUST be able to run `pytest arithmetic.ipynb` on whichever platform. (It was not appropriate for Google 2016-2020 (?) to decide that we should all accept WASM runtime vulnerabilities in sandboxed browser processes running as the same user instead of per-app SELinux contexts like Android requires since 4.4+, or instead of containers and VMs like almost all of Google's hosted apps and internal systems) Cannot believe there's not even a JS console on these for the kids (because "Inspect Element" and "Turn on Linux" are blocked for them all)
- ajross 3y ago
  I'm still not understanding the criticism. You're saying it's bad that kids can't hack on their school-supplied/parent-managed computers. And... I think I agree, as far as it goes. But you're responding to a thread saying "Chromebooks are good for Developers", where's it's just not responsive. There's absolutely no reason schools or parents can't hand kids unmanaged/unrestricted Chromebooks; they just choose not to (for some good and some bad reasons). Take that up with schools and parents, I guess?
  - riversflow 3y ago
    >There’s no reason schools or parents can’t hand kids unmanaged/unrestricted Chromebooks Holy cow. Are you serious? Kids break stuff for fun. This is basically a “You’re holding it wrong” argument. Schools are gonna have heavily managed chromebooks, because it’s the reality on the ground that they can hardly afford anything, much less insane IT support for every student. Like, kids are going to actively sabotage the software on their school equipment if they can as a way to avoid doing schoolwork. This was common when I was in high school over a decade ago, they solved it with Deep Freeze software and extremely restrictive Microsoft policies. Google is the one with a wealth of IT and developer talent, not school systems. They are making the product, not the schools. Devs have to come from somewhere, and going out a limb here, I don’t think smartphones (the other computer that [low income] students are likely to have access to) provide an on ramp for developers, so it would be good if these chromebooks did.
    - scheeseman486 3y ago
      Virtually any Linux distro can be turned into a managed OS.
      - westurner 3y ago
        Something could manage access to and the run state of containers (just like APKs and other apps running without `ps -Z`) so that the state of the machine can be reset. And then an instructor could specify policy that would affect which apps and containers run on the machines attached to the management domain (e.g. at test-taking time and also all of the times) Comparing etckeeper and rpm-ostree's diffs of /etc lately (where e.g. LVM or btrfs CoW snapshots would need eventual compaction)

anonacct37 3y ago

Not exactly but the equivalent yes. Workstation and VMs. All tests and builds are basically run in borg by default. For most Google developer developing on a Chromebook basically means running ssh and chrome remote desktop.

westurner 3y ago
For students, unless there are allocated server resources with network access, it SHOULD/MUST scale down to one local offline ARM64 node (because school districts haven't afforded containers on a managed k8s cloud for students at scale fwiu, though universities do with e.g. JupyterHub and BinderHub [4] and Colab). For Chromebook sysadmins, Instructors, and Students learning about how {Linux*, ChromiumOS, Android, Git, Bash, ZSH, Python, and e.g. PyData Tools supported by NumFOCUS} are developed, for example; When you git commit to a git branch, and then `git push` that branch to GitHub, and create a Pull Request, GitHub Actions runs the (container,command) tasks defined in the YAML files in the .github/workflows/ directory of the repo; so `git push` to a PR branch runs the CI job and the results are written back as cards in the Pull Request 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 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 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.html#specification 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/repo2docker/buildpacks/base.py https://github.com/jupyterhub/repo2docker/blob/main/repo2doc... [2] "Make base_image configurable" https://github.com/jupyterhub/repo2docker/commit/20b081525785fdc6ac524e06150028796b8787ec?diff=unified https://github.com/jupyterhub/repo2docker/commit/20b08152578... [3] repo2docker/buildpacks/conda/environment.py-3.11.yml: https://github.com/jupyterhub/repo2docker/blob/main/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 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-details.html https://security.googleblog.com/2022/04/how-to-slsa-part-2-d... https://slsa.dev/blog/2023/06/slsa-github-worfklows-container-based 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.

deleted 3y ago

[deleted]