As I understand it, yes, albeit it's much easier at Google than some places. Google is pretty much a supercomputer with a company built around it; the Chromebook can serve as your terminal into that supercomputer, accessing your files, codebase, and other resources all remotely.
You can request the computer you want. They will push you towards Chromebook but you can pick a normal Linux machine or a MacBook or even a Windows computer (don't do this).
I used a Windows laptop for some time. It made browser testing in IE significantly simpler and otherwise worked fine for running Chrome + remote access to workstation. It was also the only model offered with a garaged stylus, which I used and tested quite a lot.
I used that laptop to skip over the lousy overheating butterfly MacBook generation. Now I have an M1 Pro MacBook like everyone else.
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.
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
> 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)
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]
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.
But that doesn't solve because containers and vms aren't on and aren't supported for their accounts.
A school chromebook's access to containers could be controlled by setting the containers.conf repo URL to a Container Image Repository controlled by the school. GitHub, Gitea, and GitLab all support storing (OCI) container images.
An instructor would import a container image with an associated Pull Request that causes an Action to run to (1) scan the container and its SBOM Software Bill of Materials; before (2) hosting the container image for the students and (3) regularly (along with e.g. Dependabot, which for security regularly checks for references to outdated versions of software in GitHub repos) .
GitHub Project Templates are designed to be forked; e.g. like an assignment handout to be filled out (that already has an /.github/workflows/actions.yml and README.md headings). Cookiecutter is another way to create a project/assignment/handout/directory/git_repo skeleton; with jinja2 templates to generate file names like `/{{name}}/README.md` and file contents like {% if name %}<h1>Hello World, {{name}}{% endif %} . jinja2 is a useful skill also for ansible [collections of roles of] playbooks of tasks.
It would be helpful to be able to provision [Android and Chromebook] devices with [Ansible] like it is possible with Mac, Windows, and Linux devices (without a domain controller; decentralizedly and for bootstrapping). It appears that there happens to be no way to `adb install play-store://url` with Ansible, but there is news about Ansible support for Enterprise Chromebooks.
There are [vscode] IDE mentions in the chromebook git repos IIRC. The [vscode] [docker/podman extension] could work with aforementioned functionality to limit which containers can be pulled or are running at a given time.
USE CASE (for a "STEM workstations for learning" spec): Create a minimal git repo project from a project template with cookiecutter-pypackage or similar.
A minimal project [template] would have at least:
/README.md # h1, badges, {{schema:description}}, #install, #usage, #license, #citation
/LICENSE || /COPYING # software/content license terms
/devcontainers.json # for vscode and other IDEs
/environment.yml # which packages to install (conda, pip, repo2podman)
[/src]/example/__init__.py
[/src]/example/main.py
/tests/
/tests/__init__.py
/tests/test_main.py
/example/tests/ # this dir would ship with the package, so that that tests Could run in production
/example/data/ # will be installed in site-packages
/data/ # will not be installed in site-packages without a special setup.py
/docs/
/docs/conf.py # sphinx
/docs/index.rst # .. include('../README.md') .. toctree:: # sphinx
/docs/_toc.yml # jupyter-book
/docs/_quarto.yml # quarto
/docs/_metadata.yml # quarto
# When we need to vendor _other projects in
# we then need src/ (and/or lib/) for _those (and maybe ours_ 2)
[/src][/example]/tests/
[/src][/example]/tests/__init__.py
[/src][/example]/tests/test_main.py
[/src][/libexample2]/COPYING
This is a very common workflow for STEM (PyData) software; how is it done with Win/Mac/Lin (and bash and git) and how do we do this with our Chromebook with no Terminal or Containers?
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.
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)
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?
>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.
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)
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.
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>
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.
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.
My daily driver right now is a mid-tier Tiger Lake board. You can get the equivalent for sub-$300 on Amazon. The client doesn't need to do much in the modern developer flow, running a browser, an X server and an ssh client is 90% of anything that needs to happen, with the occasional Linux Wayland client from the VM thrown in (Thunderbird for personal mail, occasional use of Audacity, stuff like that).
I have a couple of Samsungs and a Pixelbook. You can BYOD with Chromebooks, too, so you can pick smaller, lighter ones or ones with bigger screens than the standard offerings if you’re willing to pay for it.
Not exactly. There are some ways to install GNU/Linux distros on Chromebooks, the Eupnea project's Depthboot script[1], for example, lets users build/run a distro by extracting the rootfs from an ISO file, and apply Chromebook-specific patches, like using ChromeOS' kernel, using keyd to make patches to support the Chromebook keyboard's action keys, and much others.
(Disclaimer: I'm the current maintainer of the Eupnea project.)
If the question is about Google, they use the Chromebooks to connect to cloud hosted dev environments. Often these days that's the internal cloud based IDE whose UI is VSCode based.
For many legacy command line tasks, you SSH to a cloud workstation. More than ever though, you can get away with a lot of programming tasks without ever touching a terminal.
For those who really want a traditional Linux Desktop environment, you use Chrome Remote Desktop to connect to the same cloud VM that you SSH to.
