[westurner]

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]

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]

>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]

Virtually any Linux distro can be turned into a managed OS.

[westurner]

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)

[beanjuiceII]

I think you are greatly over simplifying it

[Dylan16807]

The fact that they're managed isn't the problem, it's the type of restrictions that google is enabling. Both the schools and google are at fault.

You say "important and desirable manageability features" in your other comment and I strongly disagree. Disabling the web inspector is not important and it is the exact opposite of desirable.

[westurner]

The relevant question is whether students are empowered to do actual STEM work (in git, with python, and notebooks and/or an actual IDE) in application of the K12CS Q12 STEM curricula.

There should be a specification of things that we need the computers we buy for the students to support; a rubric to consider in acquisitions and discussions with vendors attempting to solve for the needs of education and learning.

Seriously, compare the results of canned flash games (with metrics) vs locally coding math to do a scientific experiment or solve immediately-graded exercises with code.

I've reviewed the curated app catalogs here and TBH the tragic gap is perhaps at "how to computer math" [in notebooks in a version controlled (e.g. git) repo] [in Python [with JupyterLite or vscode.dev w/o devpod/codespaces [due to Chromebooks]]]; just a video of Arithmetic in notebooks instead of a calculator.

GeoGebra and Desmos are neat. Geogebra has a CAS (Computer Algebra System) built-in, but it's not Python with test assertions. And when the canned math app e.g. fails with weird complex exponents of e, it's a good idea to reach for Python (or Julia, or R, or) instead of only the apps in the Play Store.

Exercise: Install Git and Python (maybe in Termux from Fdroid) on a Chromebook, then run repo2podman {with a FamilyLink account,}

Exercise 2: Create a Jupyter Notebook on a Chromebook and save it to work on from home {with Gapps Edu and Family Link} when Colab isn't allowable and JupyterLite doesn't have a gdrive plugin yet.

Containers in a local devpod (~codespaces) VM for the students might solve.

This should also work on computers to support real-world STEM workflows:

  <alt-tab> make test
  make clean

  <alt-tab> <up arrow> <enter>

[ajross]

OK, you're simply having a different argument, and I frankly don't even disagree. "Schools should let kids run stuff in Crostini" is something I think we can both get behind.

But nonetheless schools don't (and never have, FWIW), and it's not the OS's fault that they use important and desirable manageability features to do it.

[westurner]

If schools could afford it, they would probably get value from GitHub/GitLab/Gitea for all students. And then would they get value by provisioning containers to grade students' code with Kubernetes (k8s) and GitHub/GitLab/Gitea?

Internally, Google has a huge git monorepo and gn and IIRC gerrit for code review (?) and externally many repos in various orgs on GitHub (some now contributed to e.g. the Linux Foundation's CNCF).

A Google Colab JupyterLite-edition could optionally integrate with Google Classroom.

There's an issue in a repo re: a JupyterLite gdrive extension and fs abstraction so that it would work with other non-git cloud storage providers.

vscode.dev supports git commit and git push from the browser tab to GitHub, which can then run the code with GitHub Actions. vscode.dev can also connect to GitHub Codespaces (or devpod). GitHub Codespaces spawns a container in GitHub's k8s cloud for interactive use with {VScode, Jupyter, and IIRC SSH} instead of batch headless use with logs like GitHub Actions.

You can write a simple git post-receive hook script in .git/config that runs a script on every push to the repo, and then later realize why each execution of a post-receive hook needs to run the job in an isolated container to prevent state leakage between invocations of the script; there should be process and data storage isolation for safe and secure GitOps.

Research institutions like e.g. CERN and ORNL have e.g. GitLab with k8s; there, pushing to a Pull Requests branch can cause a build to run the tests in a container auto-provisioned somewhere in the private cloud and report the results back to the Pull Request thread. UCBerkeley developed ottergrader (to succeed nbgrader and okpy) to grade Jupyter notebooks in containers (optionally with k8s, or locally) and post the scores to e.g. Canvas LMS.

Can the students grade their own work with containers in Crostini/Crouton//ARC without homomorpohic encryption (like Confidential Computing) running potentially signed but unknown code on their local workstations?

JupyterLite and vscode.dev+jupyter+pyodide work in Chrome on Chromebooks today, but it's really suboptimal from a mainframe-era perspective.

[fragmede]

> gerrit for code review

Gerrit was deprecated a while ago.