ChromeOS will soon be developed on large portions of the Android stack
blog.chromium.org
blog.chromium.org
https://source.android.com/docs/core/architecture/kernel/gen...
As others have already mentioned, just stating the facts about long-term support: chromebooks have much longer support than Android devices. Both looking at the 99-percentile, the median, and the 1-percentile.
Chromebooks don't get stupid bugs that require workarounds in userspace like: - BPF maps being broken because someone at Mediatek ran some proprietary static analyser and blindly pushed some fix - Camera only works properly in the OEM app - GL drivers are upgraded once every blood moon and very OEM has its custom GL version - Treble doesn't break because Samsung decided that mount loops were dangerously insecure at a time it wasn't required - You don't need to keep workarounds for mainline kernels that you can't upgrade, because Google/Android forbids you to upgrade your kernel [1]
Android deprecates driver after 3 years [2], so vendor need to do a lot of work on a very frequent basis. As an OEM, I just want to do my (painful) contributions to mainline, and have them maintain it. Android actively hinders me from doing that.
As an Android OS developer, I could go on and on and on about the stupid issues that Android kernels get that Chromebooks don't. All of those issues would happen just exactly the same on Fuchsia.
I'm not saying ChromeOS' development method works for smartphones, it doesn't. I'm not saying it is desirable, I think it isn't (because it completely kills most innovation). But ChromeOS handles fragmentation better than Android on every single criteria you could imagine.
[1] Google/Android added a bunch a new stupid policies that actually prevent me from upgrading kernels on deployed devices
[2] Yes there is actual planned obsolescence nowadays in Android. It wasn't the case few years ago where obsolescence was accidental
Anecdotal counter-point I have a colleague with a Samsung Galaxy Tab A 8" 2019 (SM-T290), and after just 3 years it became absolutely unusable, even after a factory reset. And it's "by design": it shipped with 2GB RAM, which was usable in Google/Android 9 (shipped OS), but just completely dead on Google/Android 11 (updated OS). Obviously I saved that device from oblivion with a Google-less Android that takes half as much RAM.
The bus on these older model chromebook devices had a choking issue where the kernel would fully saturate the transfer bus and cause a cgroup scheduling strategy to give full priority to the processes using the bus at the expense of the gui. Solutions to this problem include a new NVME or software level cgroup reconfiguration of the kernel to revert scheduling priority to equal across all cgroups.
Or it could be something else entirely, but last time i had this issue and bug hunted it the finding was as stated above.
[1] This is improving greatly in the last year or two, but that probably wouldn't have made it to your chromebook.
I also have a Lenovo Ideapad Chromebook running on an Intel 4020 with only 4GB. Despite being slow hardware, it runs circles around the Duet. The 4020 can be sluggish at times, but it never had the big slowdowns of the Duet. It could even run Visual Studio Code at acceptable speeds. Something was very wrong with the Duet. Usually Chrome OS is good on lower end hardware.
Technically this one would possibly not be in Fuchsia, though Google let OEMs put so many hooks everywhere in the system that tbh it would still be possible to do this kind of fuckups
> - Camera only works properly in the OEM app
Fuchsia or not, if Google allows OEMs to add custom vendor calls from OEM app to camera driver, then OEM will still be allowed to do that. They could already forbid it in Android and choses not to.
> - GL drivers are upgraded once every blood moon and very OEM has its custom GL version
GL has nothing to do with the OS, GL vendors pretty much ship the same GL across all OS
> - Treble doesn't break because Samsung decided that mount loops were dangerously insecure at a time it wasn't required
This would definitely still happen (in other ways), by all the hooks that Google leave to OEMs to implement their own security systems (and Samsung is the company who brought SELinux in Android, so even though they do a lot of shit, let's not completely ignore them)
> - You don't need to keep workarounds for mainline kernels that you can't upgrade, because Google/Android forbids you to upgrade your kernel [1]
This one, ironically, would STILL HAPPEN, at least if we extrapolate how Android team work. When building Android from main, you get 10000 as SDK version number to explicitly mention that this is a development tree not to be used.
Fuchsia theoretical advantage should be that one will be able to upgrade the kernel without upgrading the drivers. But again let's extrapolate what Android team does: They create new API versions every year or more, and PLAN THE OBSOLESCENCE of those API versions within 3 years. So currently when an OEM write their drivers, they get kernel security patches for 6 years after the release of the "original" kernel of that version. With Fuchsia you get down to 3 years.
I want to re-iterate that even though from that perspective, ChromeOS' approach is ideal, it has issues wrt innovation. I believe that the ideal situation is an open but centralized approach like what we have currently with DKMS on GNU/Linux distributions. Except let it focus on LTS Linux kernel versions, and have flags on the DKMS to allow switching to newer LTS. Here "open" doesn't necessarily mean community-led. It can be very well just be that each vendor is responsible for its own product. So like Mali is responsible for their mali kernel driver, BOE is responsible for their panel driver, etc...
> Availability of software and firmware updates
> (a)
> The latest available version of the firmware shall be made available for a minimum period of eight years after the placing on the market of the last unit of a certain product model, free of charge or at a fair, transparent and non-discriminatory cost. The latest available security update to the firmware shall be made available until at least eight years after the placing on the market of the last product of a certain product model, free of charge.
(b)
> Information on the minimum guaranteed availability of software and firmware updates, availability of spare parts and product support shall be indicated in the product information sheet as from Annex V of Regulation (EU) 2019/2013.
https://eur-lex.europa.eu/eli/reg/2019/2021/oj
I can't find all of it, but part of it is triggered by EU environment protection directives.
Also the type of updates guaranteed for 10 years on ChromeOS are not the feature update type that require upgrading the actual OS, just security and bugfix patches.
The Shield was released in May 2015 and its latest software update has an Android security patch level of April 2022 and was released November 2022. No more updates seem to be forthcoming. Notably, all Shield TVs today are vulnerable to remote code execution when displaying a malicious WebP image [0], a widespread issue uncovered last year.
Apple released the Apple TV HD two months after the Shield TV, but it still receives the latest tvOS updates to this day and will be receiving this year's new tvOS 18 [1] [2]. It received a fix for that WebP issue the same day as supported Macs, iPhones and iPads did last September.
Even the best Android device examples with good vendor support still seem to be falling short. The Shield TV is still capable streaming hardware in 2024 used by many people, but it's sitting there doing that while missing important security patches unbeknownst to the users.
[0]: https://blog.isosceles.com/the-webp-0day/
[1]: https://www.macrumors.com/2024/06/10/tvos-18-compatible-appl...
[2]: To be fair it's the only Apple A8 device that receives support until today. The iPhone 6 with the same chip was launched mid 2014 and received its last update in early 2023.
It's really silicon manufacturer's fault for not wanting to mainline and long-term support their BSP, not Google's.
the solution is to get everyone on the same kernel, which is then updatable - not hack together something that kinda works on top of a never updated snowflake
You keep the binaries, you get to maintain them and solve their problems. Seems fair.
you have to not understand the first thing about kernel drivers to even consider binary drivers upstream. for starters, who provides a new binary when the api change every every new kernel version?
If you're talking about something like Ubuntu, there's a tonne of work that goes into making sure it works with ..say.. a random three year old laptop with all the binary blobs in place.
Try getting something like wifi or Bluetooth working on some weird ARM dev board and suddenly there's no vanilla Linux unless you're willing to write device drivers.
But that work gets done and "users" of Ubuntu or Debian or Arch get to use it from the sources they trust (aka Ubuntu, Debian or Arch). I'm not claiming to have a full understanding of how every package or kernel module Debian or Arch or Fedora ships works. But I'm trusting Debian or Arch or Fedora for my packages. If it comes to light that debian or fedora maintainers had no idea that they shipped a malware in a release, then I'll seriously question going with that distribution in the future. And without sounding facetious, that has happened multiple times in past especially with debian. But the times it happened it was clear to me that it was merely a mistake rather than extreme incompetence or malice.
With Android, you have Google, which despite the general HN rhetoric I personally trust to not ship straight up malware. But when we're talking about Android that's not what we're talking about. We're often talking about binary ROM blobs from random XDA or RW users. Funny thing is 20 years ago, I'd have shouted about what's the difference between a random anon on XDA or WZBB providing a ROM blob. But now I know better.
depends; but may i suggest starting at kernel.org then look at 'linux from scratch'/gentoo then maybe slackware; surely not ubuntu
hardware is either supported or not.
the "work" you mention on old wifi cards is to get a driver that was never contributed in any official way. hence unsupported.
Linux have more hardware support out of the box than anything, ever.
just educate yourself before purchasing.
no sympathy. you're also out of luck using old hardware in the first place because the manufacturer wants you to buy the new version. they will help you LESS than Linux devs. you're point is very unhelpful to the discussion, unless you got drivers updates from the manufacturer
They accept only code which they will be able to maintain, yes. That excludes spaghetty or implementations of complex undocumented APIs that are useless without a binary blob. Nothing unreasonable about that.
Is this supposed to be impressive? My current PC is over four years old and I'm in no rush to replace it. The same Linux distribution runs of decades old HW.
Books Browsers Cameras Document readers File management Journals Mail Photos Presentations Spreadsheets Whiteboards Word processors
One hour 39 + 39 seconds in the demo
Didn't Google push for mainline integration at some point to completely avoid the need for manufacturer specific BSPs?
Samsung offers 7 years of major version upgrades on their flagship lineup starting with the S24. It is not retraoctive, although their 5 year policy has been in place for 2021 devices.
It's unlikely that they will offer security patches beyond that point and the mid-range segment still only gets 4/5 years.
Chinese OEMs offer "major" upgrades for longer, however they achieve this by backporting both Android mainline and proprietary features to older versions of Android, along with security patches.
As in all things relating to anything stated by Google with respect to the privacy, availability or expected lifetime of a consumer product, the maxim is not even "trust but verify", it should be "distrust, watch carefully, and assume the worst".
Seems like they a) delivered more than initially promised, b) did not drop it just a year after release. How long a support period do you think they actually promised, and where did they promise it?
[0] https://www.androidpolice.com/2016/10/19/pixel-pixel-xl-guar...
[1] https://9to5google.com/2019/12/02/google-pixel-no-updates/
To my understand in Linux most drivers are codeveloped with the kernel as it does not have a stable interface for drivers (one might say that it is a pro as it discourages proprietary drivers)
High fives!
My main Linux computer died a year ago and I needed something to write emails and browse on, so I ran out to Costco and got a Chromebook, expecting it'd tide me over until I could figure out a replacement computer.
I'm still on the $250 Chromebook machine. It does everything I need and I'm pretty amazed at that. I've been doing some side projects with Elixir/Phoenix and it's not the speediest machine for sure, but it's quite serviceable. And for that price... that's amazing.
I went full Linux on it using MrChromebox[0] a few years back with zero complaints.
I've ended up gifting the 4 or 5 budget chromebooks to nephews , pre-installed with Crouton / Crostini set up and accounts on leetcode / hackthebox to train on.
It's remarkable how capable Chromebooks are. I tried using my $600 iPad Pro to code on and I never found it to be as capable as my $200 chromebook
If the future ChromeOS-Android hybrid (ChAnroid?) loses Crostini Linux, but is able to run Android applications then Termux might be a good option depending on the task.
Aside: this ChromeOS-Android merge brings to mind the Chenjesu-Mmrnmhrm merge to create the Chmmr in SC2. Maybe the ChromeOS-Android merge will similarly yield a wonderful hybrid result?
It does seem that new Android lets you turn off the phantom process killer, so maybe there's hope, but still Termux is forced to target an old API version and can't be published on Google Play.
settings put global settings_enable_monitor_phantom_procs false
The more pressing issue at this time is: https://github.com/termux/termux-app/issues/2155
I'm having a Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch moment here
Crouton / Chrostini seem to have a lot of dependencies on the current ChromeOS platform that would be costly to migrate.
Being careful not to make any pronouncements here since I do work in the group, but no, not really.
Crostini is just a fairly standard VM manager with a handful of custom virtio and IPC mechanisms (some of which are really clever, to be fair). It doesn't require much of anything that hasn't been in the upstream kernel for years. And Crouton is just a community-maintained Linux chroot. People (including me) were doing exactly that kind of hack on rooted android devices more than a decade ago.
I'm aware of android terminal apps, but they typically connect to a remote terminal via SSH.
Does android boot into a terminal like a typical linux device? I thought it booted into fastboot
> I'm aware of android terminal apps, but they typically connect to a remote terminal via SSH.
You certainly can run a local terminal (I think I've seen it baked in as part of developer options, but also as an extra app), though if you don't have root it is somewhat restricted in what you can actually do.
> Does android boot into a terminal like a typical linux device? I thought it booted into fastboot
I think you're slightly misunderstanding how boot works on both Android and Desktop Linux. The kernel is perfectly happy to run whatever you want on such displays as are available. Android tends to boot from firmware (which also implements fastboot) to a bootloader to the kernel and the kernel brings up the system with SurfaceFlinger (the Android display manager) owning the screen. On desktop linux there's more diversity; you can have the kernel initially hand your screen to the old in-kernel virtual terminal, the newer KMS implementation of a terminal ( https://wiki.archlinux.org/title/KMSCON ), or to Xorg or a Wayland compositor (in that case, optionally using plymouth or the like to replace even the earliest text messages). (Actually, full disclosure: I'm only about 70% sure I've got that sequence right. The point is that even desktop linux is perfectly capable of booting only in graphical mode; booting to a text terminal is available but optional.)
TL;DR: Google is consolidating behind the whims of the hardware org, which are orthogonal to OS' that can't ship (what ppl outside Google call Fuschsia), and here, OS' that can't sell premium 1st party hardware. The old platform org head left recently, combine that with the CEO's eagerness to display Efficiency™ and the lack of interest the CEO has in practical work, that means VP shuffle people around to keep constant/shrinking headcount and the CEO loves it.
I don't know anyone outside the Fuchsia team that takes it seriously.
A big advantage of Android is the implementation of intents (also compared to Apples new crippled intents API), which may turn out to become the deciding factor in the race towards the winning AI Agent OS, as it may enable AI to use programs programmatically
Because they are panicking and need to add AI faster than Apple and Microsoft across their whole portfolio.
As building an OS is no simple task, this all could mean nothing and the project might be heading to the graveyard slowly.
I noticed the same, too, it was hyped as the next OS now about a decade ago, and it doesn't look like it will be a significant player any time soon. I assume it's still in the evaluation, prototype phase, probably tons of issues.
I heard here and there that some exotic glorified home tablet thingy is running it, but I don't think you can really go to a local consumer electronics store and find something with Fuchsia running on it.
I don't necessarily think it's going to be a major success, but it's already been more successful than this implies.
(Bias, was on the Fuchsia team many moons ago)
There is not much actual difference between "I heard here and there that some exotic glorified home tablet thingy is running it" and "There are multiple devices that have shipped with Fuchsia on it in the home ecosystem over the last 5 years".
Would love to hear where it was actually used, searching for it, I really only found a handful of examples.
I was an active Flutter community member and it was driving me crazy how people would say "Flutter is great because Fuchsia also uses Flutter", and all I thought "show me one person who is using Fuchsia at this whole conference / meetup".
So it would be Android, Chrome-on-ChromeOS in an AVF VM, Linux-on-ChromeOS in another AVF VM, Windows in a third AVF VM, etc.
The question is will they also throw out the ChromeOS userspace components and replace them with the android userspace?
If so, this is effectively an announcement that ChromeOS is discontinued but those devices will now be migrated to run android.
https://android.googlesource.com/platform/system/update_engi...
Many Android specific changes though.
[0]https://source.android.com/docs/core/virtualization/architec...
[1]https://www.androidauthority.com/chrome-os-on-android-hands-...
There are also tools available like Andronix.
I personally haven't tried them, just figured I'd leave the information here for people interested in it who want to explore the options.
The ux is kind of junky, but if you're mostly using the browser or some remote desktop / ssh it's feasible at least.
Battery life not so much.
[1] https://chromium-review.googlesource.com/q/status:open+-is:w...
Looks like we can try to infer the real intention of the convergence from this project. It might make business sense to maintain 3~4 different OS, each targeting different user segments. But there is no reason to have one more different tech stack per each OS across everything.
My memory was maintainers on the linux side had an issue with wakelocks maybe? At one point google going to some pretty serious lengths to try to integrate / upstream some stuff and it getting totally shot down.
My own view was there was a bit of a missed opportunity there
At this point, Androids kernel is only a fork of upstream Linux kernel because Google employs so many kernel devs that some features are developed downstream first, then upstreamed once kinks are worked out after shipping in devices on tighter deadlines than upstream.
ashmem is user space shared memory with permission controls. It was replaced(ish) with memfd with the addition of F_SEAL_FUTURE_WRITE in 5.1 (it took a shockingly long time for that to finally have feature parity but hey better late than never)
ION is the special allocator that was replaced with dmabuf.
Also ARM, qcom, etc... all love playing with the scheduler or making other changes which typically happens downstream first for time-to-market reasons before being upstreamed. eg, ARM's EAS / energy aware scheduling I think actually shipped to users prior to upstream accepting it.
Linux at that time was very much unequipped at handling low power devices well (e.g. Wakelocks have already been mentioned).
Simplifying engineering effort and merging the stacks, that I can understand.
Thousands of distros and not the one that would take off. Sad!
And now, with this announcement, the moment has passed.
I tried to make a custom container that would run under the regular ChromeOS crosvm, all the "agent" stuff for e.g. transporting wayland over virtio is brittle crap that crashes with no useful error if you don't invoke it perfectly correctly.
What I want is the idea of wayland-over-virtio to be reimplemented by others.
... that would just be Linux then? GalliumOS was Ubuntu for Chromebooks (with ChromeOS patches for touchpads etc). Mainline Linux is good enough nowadays for most things.
Several companies offer custom ChromeOS images with their own tools and one was even purchased by Google, but they focused on centralised management for classrooms etc.
Maybe it is more about the business model. ChromeOS runs efficiently on low-cost hardware for a small license fee (?), and get almost guaranteed updates. In exchange, customers sell their souls (actually, data) to Google. Won't happrn with Linux. But undeniably it sells and works well enough for ChromeOS.
You mean "ChromeOS community", right?
They had to get ahead of rampant internal rumors that were leaking externally (c.f. comment of mine a couple weeks back https://news.ycombinator.com/item?id=40580163)
Let's stop begging at the table of big-tech for software scraps.
There's been plenty of HN readers on here over the years touting Fuschia as the next big thing to displace Linux/MacOS/Windows due to the Pure Microkernel Design(TM), mish-mash of C++/Golang/Rust in said microkernel, and the fact that it's a Google Product. All the things HN loves.
Google's operating system is android. it has won. extend that architecture to the chromeos.
There was a time when the chrome team were walking around telling everyone native android development was a dead end and chrome would take over everything. Then Google had some reorgs, certain people ascended to control both android and chrome, and suddenly android was a good thing.
There's technical merits to both platforms. The fact that Google had/has multiple Linux distributions all competing is ridiculous. I personally worked on HW products that used... (counts fingers) 4 of them? And then toss Fuchsia in there, too...
Android has its place on mobile, but we see how well it has gone for Microsoft trying to take a single OS and make it work across mobile/tablet/laptop.
Also WRT your problems: In case you did not yet, switch to Pipewire. When I did that a couple of years ago, my BT Audio experience went from bad to really good.
https://chromeos.dev/en/posts/androids-bluetooth-stack-fluor...
For example, I have JBL headphones, that work perfectly in the A2DP mode; but switch to HFC for the mic, they will work for a few minutes, then drop off and stay that way until reboot.
That's with Ubuntu. With Android, no such problem.
Catastrophizing maybe a little bit, but this sounds like turning their back on the broader ecosystem to go wander off for good in the 3rd rate sandbox they built themselves. Android has spent years trying to figure out our to have a secondary display, and the only thing they could manage was to mirror the display, almost certainly in sizable part because Android's boutique homebrew display services are so absurdly constrained. Marrying yourself to this boat anchor of a tech stack is the worst possible move ChromeOS could be doing.
Google's Not Invented Here has always been exceedingly high. ChromeOS has been one of the only attempts Google has made to play well with others, to carve some kind of middle path. It's hard to read this as anything but Google giving up & deciding to go it alone.
They should have done the exact opposite. They should have made Android start using ChromeOS. Or just stay the course. Yeah it's costly having parallel efforts, yeah, but holy heck these feel like existential stakes if you get it wrong, and no longer having anything that interoperates with the rest of technology seems like an obviously hideously bad idea, trusting everyone will adopt your stuff seems bad; Microsoft for example has finally dug themselves out of this hole with WSL, but Google already has a very respectable sensible option they seem like they are about to kill.
Also, seems likely Google was lying a month ago when they said ChromeOS on Android was just a demo. This announcement shows it was their battle plan. Just, not to users benefit, not as a "your phone can also...". https://news.ycombinator.com/item?id=40380022 https://www.androidauthority.com/chrome-os-on-android-proof-...
It only took two months since teams were merged for this awful no good way to throw away so much greatness to go public. https://www.tomsguide.com/ai/android-and-pixel-teams-merge-i...
They created something, only to never ever use it in public eye. To go keep reinventing and keep NIH'ing. The android virtualization stack is fucking wild, and hardly used, offers such a meager fraction of what ChromeOS was doing.
Not a bad callout, but this seems like a particularly glorious & vicious slam... that doesn't change the big picture on iota.
Containers on UNIX and mainframes predate Google's existence.
It probably would work out better in the long run considering I keep on seeing more pushes to have Android be usable on "desktop sizes", which with their mostly Wayland stack on ChromeOS would allow a lot of desktop native apps to mostly work.
The other problem is that other vendors do not provide chromeos versions of their tools. Looking at you Fortinet and your vpn.
Now, a ChromeOS Notebook or even better an Android Tablet with a ChromeOS style Desktop mode getting the GrapheneOS Treatment would be an instant buy for me.
But I'm struggling to think what a 64gb of RAM with a GPU Chromebook could do that the current ones can't do? If it's run Linux, why not just get a Linux laptop?
Maybe Vulkan support through Linux (only HW accelerated OpenGL GLES works right now for me)
(Qubes is close, but does not verify the whole stack against hashes stored in a secure enclave on every boot. Also, Qubes has a much lower bus factor.)
You can maybe get this with some Linux laptops, idk. The Thinkpads we have at work that "support" Linux have known Bluetooth issues; if I ever have trouble hearing someone in a remote meeting, it's someone with a Thinkpad.
If you buy something like a Dell, you might encounter more rough edges, although it's generally not as bad as it used to be 1-2 decades ago.
I don't quite understand why it couldn't accept a larger internal hard drive, but if it could I don't know why "up to 1 TB of NVME storage" would be their marketing copy.
[0]https://frame.work/blog/introducing-the-framework-laptop-chr...
>Memory and storage are socketed, enabling you to load up whenever you’d like. The pre-built configuration comes with 8GB of DDR4 and 256GB NVMe storage and can be upgraded to up to 64GB of DDR4 and 1TB of NVMe storage.
Screen was super nice though. It was never worth $1000
We have a few in the office and they are surprisingly OK. Let down more by the weaker processor (i3 instead of i5) but workable for a lot of things.
(because even back in the day, if the phone was powerful enough to run java, it was powerful enough to compile java)
"Industry forms consortium to drive adoption of Rust in safety-critical systems" (2024) https://news.ycombinator.com/item?id=40680722
That’s true today but what about in the future
It is also going to be a bitter pill for many Chrome OS people, who were often defined by a distaste for Android that verged on the absurd, and caused an awful lot of political nonsense. Android is far from ideal, but Chrome OS was better in one sense only: security.
Controversially I believe the most viable future Linux desktop is likely to be based on the Android stack, especially the app packaging, but with the entire “java” layer removed.
What would replace all the APIs provided by the Java layer? Compared to what you find in traditional Linux desktops, the Java APIs are
1) comprehensive, providing a one-stop shop for basically all core app functionality; desktop Linux has no equivalent of the Android SDK or the Windows API.
2) versioned, with strong backward compatibility.
Linux desktops have no well-defined "minimum API version" that developers can target like they can on Android.
The key problem with desktop Linux is the entire distro concept. Just have the kernel, some services (the android ones like binder, surfaceflinger etc) and go from there. Iirc that isn’t far from what firefox os was, only they insisted on everything being browser based.
The Java API on android is thinner than it looks, and contains most of the serious problems, such as the entire UI stack. Now that Swift has grown static Linux support that would probably make most sense as the first class target for API consumption.
Of course they do: "Ubuntu 16.04+", " Debian 11+", "RHEL-like 8+". If you can use a single distro (which you're proposing anyways with Android), it's not hard. Sadly LSB didn't really work out so you don't have a more portable solution, but that just means that we're stuck with the status quo and not better.
Don't you think this is a pretty major feature?
Android does a huge amount more, especially around media and general hardware support (such as nn accelerators) which make security much harder but are also necessary for deploying modern applications.
https://www.chromium.org/chromium-os/chromiumos-design-docs/...
https://news.ycombinator.com/item?id=36998964 :
> Students can't run `git --help`, `python`, or even `adb` on Chromebooks.
> (Students can't run `git` on a Chromebook without transpiling to WASM (on a different machine) and running all apps as the same user account without SELinux or `ls -Z` on the host).
> Students can run `bash`, `git`, and `python` on Linux / Mac / or Windows computers.
> There should be a "Computers for STEM" spec.
Docker containers can be run on Android with root with termux:
- https://gist.github.com/FreddieOliveira/efe850df7ff3951cb62d...
Podman and podman-desktop run rootless containers (without having root).
containers/container-selinux: https://github.com/containers/container-selinux/tree/main .spec: https://src.fedoraproject.org/rpms/container-selinux/blob/ra...
"The best WebAssembly runtime may be no runtime" https://news.ycombinator.com/item?id=38609105 : google/minijail, SyscallFilter=,
E.g. https://vscode.dev/ runs in a browser tab on a Chromebook and supports Pyodide and IIUC hopefully more native Python in WASM support soon?
Hopefully Bash, Git, and e.g. Python will work offline on the kids' Chromebooks someday.
Its neat to be able to just carry around a mini desktop computer
Uhm, is there any plan to bring some openess to it so one can actually run python and do ML without using some alternative hack? How is the state of these things nowadays for chrome os? Haven't played with it in ages.
Is it just because it's easy, somebody picked it a while ago, made something influential, and now everybody uses it because everybody uses it?
- python integrated well with lesson plans instructors had
- python integrated well with the software math departments were using (like MATLAB)
- python had a very easy to use interpreter environment that worked well on linux, mac, and windows
- python had (for the era) a massive standard library, making it way easier to consume and process
common data file formats like XML or CSV without having to install any extensions
(installing extensions usually required admin permissions and... very few at school had those for very good reasons)
- exposing c/fortran libraries into python was pretty straightforward to do and was relatively stable compared to alternatives.
- tcl - somewhat popular for embedding but didn't really have a standalone interpreter that made it easy to interact
with and the syntax didn't really look like C, and really not much of a library to work with
- lua - similar to tcl, popular for embedding but didn't have a popular standalone runtime and interpreter.
syntax was closer to C though. didn't have much of a library to work with
- ruby - had a runtime for experimenting but a less stable API for integrating, plus the language was pretty
different from C. the library was large but had a larger reliance on installing extensions than python at the time.
- perl - both unstable and had a horrible reputation by this point as a standalone language that outside of some obtuse
systems scripting, most people didn't want to touch this with a 12-foot pole. standard library was small and relied a lot on extensions.
- php - similarly unstable (at the time... i think 5.3 had just come out) and had a horrible reputation... also not even
sure it had a runtime that worked outside of an apache/nginx context... exposing a c library to PHP at this time was pretty
straightforward though. relied very heavily on extensions at this point.
- javascript - node.js hadn't come out at this point... so the idea of running javascript outside of a browser window wasn't really a thing yet.
I believe that led to a first-mover advantage that has held over time.
And the little scripts I write at work tend to grow and then turn into full-fledged services in a shorter period of time than it would've taken to set up the C++ or whatever boilerplate.
Huh? Please elaborate. The backwards compatibility is excellent. The core has been rock solid since the 90s. Especially compared to Py -2-to-3- thon.
Also, python is just the glue, the work happens in libraries.
And I think Python's package management and parallelism are both awful in ways that could've been avoided, or fixed during that huge breaking Py2->3 change. And I prefer JS syntax. But it still works.
Ew. ChromeOS was always a beautiful contrast to Android, running mainline kernels instead of Android's hacked up mess.
Actually that was pretty much true of the rest of the stack as well - ChromeOS was almost a normal(ish) GNU/Linux, running Chrome on Wayland on ~Gentoo. Android, in the meantime, NIHed the whole stack. I had always dreamed that one day Google would rebase Android to use a ChromeOS base running apps through a compatibility layer. This... feels like the Bad outcome.
This is at least partly because the two are distributed very differently, with Chrome OS on a much shorter leash than Android, even with Play services.
With Chrome OS devices Google can push updates to any device whenever they want, whereas with Android it was often up to the manufacturer, or even carrier, which many Googlers (not all) considered to be a mistake.
But this is also the Chrome OS achilles heel because support for esoteric third party hardware blocks is the Android killer feature and now more important than ever.
I wished and hoped for the same (or at least, for ChromeOS to not get cannibal'd by Android). But...
> This... feels like the Bad outcome.
Realistically, running apps inside of a language runtime (VM) is bad enough for an embedded device (the HP Dynamo-like gymnastics to speed up ART, notwithstanding)... and here we were wishing each app ran in its own guest OS?
And: The strange case of VMs on telephones, https://apenwarr.ca/log/20100826
You could beat all of this into submission but you'd end up rewriting a lot of stuff anyway, because those things need to be designed with it in mind (PulseAudio never had a concept of permissions and in practice you had to live with that until PipeWire was written from scratch.) The Linux desktop is a big project with a lot of stakeholders in various projects and many of these ideas only really came into the desktop realm in the past 15 years or so. This means progress is relatively slow all things considered, compared to something like Android or ChromeOS, with unified teams and top-down vision, which is why they have more or less completely replaced the entire Linux desktop in that same timeframe and even delivered on things it still doesn't have like HDR, per-application sandbox and permission models, etc.
I do think that in the server space, you can produce reasonably secure and trustable Linux systems based on available distros. But on the desktop, well, it's not so hot.
Wait until you discover exploits for the rust Runtime
>no accessibility
AtSPI, speech-distpacher.
>no fine-grained permissions system,
ACLs.
>no normal cross-application communication
DBUS did that.
>No userspace resource control (cgroups are cool, but they are not exposed)
Unless you use Plan9/9front, every Unix and even NT it's like that.
Inb4 sandboxing and X.org easy eavesdropping, upon running any unsupervised malware as your user account, you are powned under every OS (by default) as you can just tgz the Chromium/Firefox/SSH profile from $HOME and rsync+netcat/NNCP the whole pack over the net. Everything else it's snake oil.
That literally wouldn’t work on Android, or ios. And android’s solution is very elegant, and only relies on standard linux interfaces, so there is zero reason why running every process under a new, dynamic user is not the default way of interaction.
It's hard to not cynically read this as "we're making it easier for our partners to ship devices with vendor kernels".
I'm pretty shocked. I would've bet good money at this having gone the opposite direction, with ARC already on ChromeOS, etc.
blinks rapidly
edit: I guess if you squint really hard to read "Windows" as "PC-style operating systems" (or "general purpose computing") it makes sense?
The Google userland programs are removed but the kernel and drivers are retained.
This frees up lots of storage space to be filled with the owner's choice of open source userland programs.^1 Read-only filesystem, "powerwashing" system recovery, open source bootloader. Chromebook without the Chrome.
Not for commercial use but for recreation and experimentation. For commercial/educational use people can use a Chromebook from Google. I have heard that some people own more than one computer.
What some (not all) computer users want is an inexpensive portable computer that has excellent hardware support in the Linux kernel. These users users are capable of administering their own computer and have no inclination to let a so-called "tech" company remotely install software on their computer at any time ("updates"), use a web browser distributed a so-called "tech" company, store their personal files in "the cloud", i.e., data centers belonging to so-called "tech" companies, remain "logged in" to servers operated by so-called "tech" companies 24/7, and so on.
These users want a "Chromebook from scratch".
Source-based, but Google does not control the source.
1. If an owner wanted to retain some of those Google-authored userland programs, it may be possible for the owner to compile them herself, e.g.,
Google has obviously been working on AI stuff for quite a while. I mean Gemini exists, to pick the most obvious example. And since the industry is so gung ho on AI you know they were going to be pushed on device/OS integration pretty soon no matter what.
Microsoft recently announced their new Copilot PCs. In some ways that was a hardware announcement but they also got something of a blackeye for the recall feature.
Two days after Apple announces all sorts of AI features on all their OSes (except vision) coming to many of their devices soon this announcement suddenly shows up?
They’re the only big company with a consumer OS who hasn’t announced their plan yet. This feels a little bit like a “don’t forget about us“.
I will be very curious to see what they do when they put out more concrete information.
Next 5 years will be much more interesting than the 2 years before.
It will likely be at least a year before Google manages to get a good version out the door. You can preview the desktop mode with floating windows on beta, but it's very buggy. May not even come to Pixel 8 officially, only for Pixel 9.
https://android.googlesource.com/platform/packages/modules/V...
What's special in Android is multi-process. All (Kotlin/Java) apps fork from the same base runtime image, regions of which are CoW'd when mutated.
After a bit of reflection, here are a few of the things I recall hating:
* Really difficult to intercept HTTP requests, especially when testing. JS makes this easier, and obviously much more insecure, but getting things done...
* The permissions landscape always felt like it was shifting. Chrome apps have their own issues, but I still get confused when I see a permissions dialog on Android. I am sure there are good privacy reasons for all of the permutations, but I bet the permissions were not created by the same PM at Google each time.
* When I last did Android the layout system was converging to constraint layout, and it was an improvement over the prior ones. But, when I compare that to the simplicity of flex or grid layouts in HTML, I prefer those.
* All the damn targets for compilation. It is so much easier to just have to build to a webview that runs on whatever architecture you need than to figure out arm or x64.And the latest APIs are very sexy.
x86 has been pronounced dead many times, yet hasn't yet happened. Maybe this will be the one but against all odds, and reason, x86 has continued to thrive.