Live data from Hacker News

ChromeOS is Linux with Google’s desktop environment

aboutchromebooks.com

131–140 of 194 posts

Re: ChromeOS is Linux with Google’s desktop environment

#131
post #5

No. Chrome OS is an OS using the Linux kernel and a custom userland. Android is also not "Linux".

Chrome/Linux instead of GNU/Linux?

Remember, GNU is a collection of packages. ChromeOS still has GNU utilities built in, therefore, it is still running on GNU/Linux. Now, if Google made a GNU replacement, then the ChromiumOS kernel would have been named Chromium/Linux, or Chrome/Linux.

Re: ChromeOS is Linux with Google’s desktop environment

#132

Earlier quoted context omitted.

Incorrect. If it runs the Linux kernel, it is Linux. Period. End of story. Android is Linux.

What do you think is incorrect, exactly? ChromeOS is a GNU/Linux distribution - a Linux kernel with GNU and other userspace components on top - derived from Gentoo. Android, it's true, is a non-GNU Linux distro, which does use mostly custom userspace parts over the Linux kernel. I wasn't intending to discuss Android, just to point out that ChromeOS is a GNU/Linux system, and a surprisingly vanilla one at that.

>ChromeOS is a GNU/Linux system

Personally, it doesn't qualify as GNU to me as the only GNU software included AFAIK is Bash. To me GNU requires coreutils to be there and usable.

Re: ChromeOS is Linux with Google’s desktop environment

#133

Earlier quoted context omitted.

Yes. The chromeOS Flex installer image can be written to a USB drive and then booted from your usual computer. https://support.google.com/chromeosflex/answer/11552529 You can unzip this archive and write the unpacked BIN to a USB flash drive using `dd` like you would for Ubuntu. You can also just follow the Google instructions. https://dl.google.com/chromeos-flex/images/latest.bin.zip

Great! Will try that since I see is an official documentation. I assume yes, but do you know if it is mandatory to have to login to the OS with a Google account? Or can be used with a local/offline account? I prefer the later.

Yes, it's necessary to have a Google account for the typical case.

You can login as a guest, but the data created in that session isn't saved – it's "ephemeral."

Re: ChromeOS is Linux with Google’s desktop environment

#134

Earlier quoted context omitted.

Couldn't agree more. I recently bought a cheap $200 Chromebook and I have to say that it outperforms my high end Windows + WSL2 machine from work for programming related tasks. Linux just works without all the WSL issues, I can run Visual Studio Code, Docker and anything that I tried so far. It's actually a delight to work on. I can only imagine how much better yet it will be with a top tier Chromebook

Do you have VSCode and Docker installed on the Chromebook? I have been interested in buying a Chromebook for dev purposes.

Yep, just launch the built-in Linux VM (i.e. search "linux" in settings and click one or two buttons).

Then install VSCode and Docker as you would on any Linux system.

You can then launch them from the ChromeOS desktop environment as if they were native ChromeOS apps. It's really quite seamless, much more so than WSL (and better performance IME).

Re: ChromeOS is Linux with Google’s desktop environment

#135

The team has both made a ton of effort switching off their proprietary Skia based rendering tech and adopting standard Wayland, and has put forward huge effort to making running incredibly well integrated real Linux containers just work. The headline is true. ChromeOS is Linux with Google’s desktop environment. But it obfuscates the details. It's a damned by omission statement. It has some really good sauce to help y…

Echoing: doing some "deep" troubleshooting of an issue on my Chromebook (since like 2006 + crouton/crostini), I read about their newer security/architecture for Linux apps running in chrome.

https://chromeos.dev/en/linux/linux-on-chromeos-faq#why-run-...

...see also the linked: "security" and then "glossary" to get a feel for the component complexity.

It is pretty astounding, and astoundingly complicated, but mostly transparent as to how the host + guest integrate.

Yeah, you can run "Inkscape" and the GUI just "shows right up" on the chromebook... but there's like 18 layers of security mitigations and complexity with virtualized device drivers and audited communication channels that are all (nearly) completely invisible to make it look like "it's just running /usr/bin/inkscape on the same machine, what's so hard about that?"

Re: ChromeOS is Linux with Google’s desktop environment

#136

Earlier quoted context omitted.

I meant to say that it "outperforms" less in terms of speed (although it's not bad relative to the price of the laptop) but more in terms of developer experience. Everything just works in Linux and it's fast compared to WSL which I get constant issues.

This sounds like it is more about GUI latency due to a more agile desktop environment. Sort of like how a Pentium 3 feels snappy on Windows XP and yet, this 13th Gen Intel Core i5 on Windows 11 feels sluggish. There is WAY more processing power on my newer machine but it doesn't translate to a snappy interface.

Nope, WSL(2) is just slow in weird ways. Launching a GUI-less Python interpreter takes several seconds for me on a powerful workstation.

Re: ChromeOS is Linux with Google’s desktop environment

#137

Earlier quoted context omitted.

I loved Chromebooks. However I've been pretty turned off by them when my Chromebook which was working perfectly fine recently told me it's not getting security updates anymore. Now because the OS and browser are the same machine, the whole system is insecure. Next laptop will be a framework, so I guess I'll see how that goes.

They've extended updates recently https://support.google.com/chrome/a/answer/6220366 For old models as well

Not for the ones that ended support this August.

I have a kevin (Samsung Plus v1) and flashed it with libreboot for Linux at that point.

Re: ChromeOS is Linux with Google’s desktop environment

#138

Earlier quoted context omitted.

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 devpo…

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.

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 :

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

Re: ChromeOS is Linux with Google’s desktop environment

#139

I wonder why MS don't compile VS Code directly for ChromeOS?

You've been able to use vscode on ChromeOS for several years: https://code.visualstudio.com/blogs/2020/12/03/chromebook-ge... I've used it a lot - works great.

Yeah, I always felt it was a kludge though to have to run it through Crostini rather than native. Felt like laziness on MS part when they easily have the resources to make it a native app.

Glad to hear it works well, though!

Re: ChromeOS is Linux with Google’s desktop environment

#140
post #118

Earlier quoted context omitted.

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. Ser…

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.

Post reply on HN