Hugely infeasible because of binary blob device drivers, but I'd love to see something like ChromeOS Flex for phones to bring a clean version of Android to older phones.
Chrome OS should be available as an Android applications. Let me use either AR glasses or a next dock with my phone. Looks like Google might do this since they just enable display out on the Pixel 8.
You can already do this with Samsung Dex. I've been on S23 and now S24, Dex is mature and works great. Don't have a laptop anymore. Simply boot up code_server in termux and use a web browser.
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.
Weirdly, that once existed for Windows: https://web.archive.org/web/20150323075241/https://www.howto... was basically Chrome OS as a Windows 8 app, but you'd launch it and it went fullscreen and gave you basically a Chrome OS interface. It was weird but I seem to recall it working okay.
I wonder what this means for Lacros (Chrome as a Wayland application compositing to Ash-Chrome). Would this just be using Surfaceflinger and the Android version of Chrome? Does this deprioritize regular Chrome for Linux?
I think these are quite interesting questions. Chromium just spent a lot of effort to get stock Chromium working as a ChromeOS client, rather than it purely being available as part of ChromeOS itself. Is that ... pointless now in the face of a rebase on Android? Seems like it will end up being a win for a narrow window of devices?
(I was thinking about this, and maybe it's intentional. Make Chrome a first class citizen on formerly-ChromeOS. Make ChromeOS a generic base for AVF VMs. Maybe they even have cros working so well that they can do crostini inside an AVF VM?
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.
> we’ll be embracing portions of the Android stack, like the Android Linux kernel and Android frameworks (...) for Chrome OS
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.
Semi-related question: Why did the ML people choose Python and make it so intertwined with ML? It seems like a bad choice because it's slow and bad at integrating with hardware, the actual hardcore ML stuff gets offloaded to C, which creates a weird system with two languages and a weird build step to achieve one thing. If I knew nothing about the ecosystem of available libraries and was asked to pick a language to use for ML, Python would be fairly low down the list.
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?
IMO, it makes more sense to think about Python or another high level language as glue code for all these C/Rust/Cuda/OpenCL kernels. Why would you choose something like Rust to also write the glue code in? Most people will be slowed down quite a bit by the language overhead, and the people writing this code need results last month.
Python is a great language for ML because it allows gluing stuff together quickly. Using a 100% statically compiled language would slow things down, and the typing wouldn't help much because most languages can't properly type check tensor operations, and ones that can (like C++) tend to have awful compile times. The state of the art is tracing the execution and compiling it to a ML-specialised compiler (XLA for Jax, torch.compile for Torch), which is much harder or impossible to do in a compiled language.
Julia doesn't have broad adoption because it's too specific, and C++/Rust are more cumbersome, also Python for data science and ML was popular before Rust or Julia even existed. Python's biggest advantage is that it's good enough for general usage while also being convenient for data science.
Well that's the problem. Part of why Python is nice for ML stuff is because it was adopted for several other purposes too. I've never used Julia but have used niche things like Erlang, and there's always more friction that way.
What else? NodeJS would be sorta viable, but event loop doesn't mix well with this kind of workload, which is a moot point anyway because Python and all the killer libs like Numpy predate NodeJS.
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.
Because modern ML is a descendant of data science/stats work being done in systems like MATLAB and R. Numpy and scipy were great libraries, and Python was a high-level language that statisticians could use, but also a reasonable enough choice to code a backend for a service in. If the field descended from systems programmers doing high-performance computing, a different language choice would probably have been made, but prior to deep learning becoming popular, compute was not nearly an obvious blocker to improved model performance.
I went to college starting 2007 (right when CUDA was released) and recall a few things about python that made it attractive in both the comp sci and math departments at my school.
- 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.
Around 2007, the main competitors in the scripting space had a lot of issues:
- 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.
If one were looking to expose CUDA to programmers who didn't want to work in C during this era, I'd argue that python was just the best option at the time.
I believe that led to a first-mover advantage that has held over time.
The usability without extensions part is underrated. Whether I'm a beginner in school or a pro trying to hammer out a quick script, I would prefer the thing that doesn't make me jump through hoops to deal with CSV JSON XML etc. Far more important than the language syntax or other things.
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.
Perl6 is no Perl it has been renamed to Raku. The rest of the Perl5 environment it's ultra-compatible with previous releases.
Albeit compiling PDL it's rough case.
You look like never touched Perl seriously, Raku it's still a hard deviation.
No one used Perl6 on real life environments. It's the Duke Nukem Forever of the programming languages.
Using Perl6 as an argument on Perl5 it's like bashing the simple and clean ANSI C giving C++ as the example and its the crazy redundant features as a rant.
We're talking about the choice of Python for ML when CUDA came along, nearly 20 years ago. Upthread, alaties said:
> Around 2007, the main competitors in the scripting space had a lot of issues: [...]
> Perl [...] unstable
RadiozRadios replied:
> Huh? Please elaborate.
I did.
In 2007, Perl 6 was not Raku, it was intended to be the next major version of Perl. But it had been in development for ~7 years already, couldn't be relied on or predicted, and had become a bit of a joke. Since Perl 6 was still supposed to be the future of Perl, in 2007 Perl very much seemed unstable and unsuitable as a foundation for ML research.
I agree on Perl's choice. But Perl5 was granted as an stable platform, kinda like AWK, pretty much unlike Perl6, which wasn't the future of the current Perl5 at all, except for the hype.
It's largely because Python had excellent numeric libraries, like NumPy and SciPy. You could script Fortran linear-algebra kernels to crunch your numbers fast in a high-level language, and that's a killer app in the ML space.
On ChromeOS you have access to a fully featured Debian Linux in a VM with WSL-style seamless passthrough. Though on the graphics side only OpenGL and Vulkan are passed through.
They can have up to 64 gigs of RAM, but internally apparently they only support up to 1TB hard drive [0], and while you can have "external" hard drives in the expansion modules, you are giving up IO to have it (half the IO slots if you wanted to get all the way to 3 TB)
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.
Here is the paasage. My interpretation of it is different from yours.
>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.
Hard to say but the "up to" may be only the limit the framework company wants to stock and sell.
With regards to the memory I went looking and the framework has 2 ddr5 laptop dimm slots. The largest I was able to find were 48 gb modules so the physical limit may be 96gb.
And as a closing note, this was the first time I really looked at the framework laptop page. And while I am still not sure about the build quality or the usefulness of the "ports". the number of guides and photos of laptops under surgery sold me, I think I found my next machine.
> Hard to say but the "up to" may be only the limit the framework company wants to stock and sell.
It has to be something like that. That's a standard length M.2 slot...
> https://community.frame.work/t/will-framework-chromebook-wor...Installed WD Black SN850X 4 TB (WDS400T2X0E) on my Framework Chromebook. I’ve been using it for a month and a half now. Everything is fine. The only point, probably due to which the use of such disks is not officially recommended, is the excessive reserved space for the OS. Apparently this is a legacy of the times when disks in Chromebooks were of small sizes. If you are happy with the situation where a quarter of the disk will be idle for technical reasons, then you can take it.
your google fu is stronger than mine. I specifically tried to find such a thread and failed. Well done! The stocking argument makes sense to me, and makes more physical sense as well, since, as actual hardware limitations, both the RAM and storage limits would have been highly unusual and would have almost certainly needed to be purposefully implemented for some reason.
I'm curious, why? I can completely understand an "iPad Pro" version of a Chromebook. Something that is an incredible version of a limited device.
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?
Chromebook means hardware + software are packaged, which means someone is making sure they work properly together. That's the biggest differentiator.
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.
Lenovo Thinkpads have traditionally been a pretty safe choice for Linux, probably because they're popular with Linux devs. Pretty sure what's what Google buys for their corporate Linux laptops too.
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 thought about Thinkpads just before you replied and edited to mention the issues I've seen with them. Yes you're right, Google buys them, and they have minor problems, but I've never owned one personally.
MacBook is what I've got, but if you specifically need lots of RAM and/or a dedicated GPU, that disqualifies it. 64GB RAM isn't even an option in the $3000 model. Also, maybe you want to run Linux for whatever reason, without experimenting with Asahi. Apple Silicon chips are awesome, but this is the downside.
And Surface runs Windows. Gonna plead the fifth on that.
ChromeOS is more secure than any Linux distro for web browsing and other "user-facing" roles.
(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.)
I don't want to deal with maintaining a pure Linux laptop, and I don't want to be limited by OSX/Windows (for different reasons). Chromebook, by far, is the easiest to get good amount of linux for development without much issues ... with some limitations. It also works with docker/podman for the cases I care, so was simply looking for upgrade of my great (and still used to this day) Chromebook Eve (16GB RAM, 512GB SSD) - I really only wish it was bit faster, bit more memory, and I can still live really with 512GB SSD if I have to.
Maybe Vulkan support through Linux (only HW accelerated OpenGL GLES works right now for me)
You'll need to check for compatibility, but ChromeOS Flex should work on many laptops that would otherwise come with Windows. It runs terribly inside a VM, though, so it's hard to try out before installing, but if you have a leftover SSD laying around you could try swapping the storage and installing it on whatever laptop you use now.
Hard to believe it was only a little over ten years ago that the first Chromebook Pixel came out with its generous 4GB of RAM. It's a shame the battery life on it was only about 4 hours on anything other than ChromeOS (which got maybe closer to 6), because I absolutely loved the form-factor of that first model.
It was utterly useless though. It significantly predates all the valuable features that came to chromeOS later, like running any android app. I bought one used and it was impossible to troubleshoot any of it's problems because "just a normal linux distro" has always been a lie. Linux is as much the stuff built on top of the Kernel as it is just the kernel. All that stuff was basically impenetrable unless you were a Google ChromeOS dev. By the time ChromeOS was actually useful, that machine could barely run a single YouTube tab.
Screen was super nice though. It was never worth $1000
I paid $800 for a barley-used one off Craigslist. True, it lacked the Android features (which even the 2015 model might have had? Certainly the successor Pixelbook did), but it was perfectly serviceable for my uses with crouton on it. And when it eventually went out of support, I removed the write-protect screw and loaded a standard BIOS onto it so that I could then install Linux Mint. It was a capable machine for several more years, marred primarily by that poor battery life.
I got one in 2018 for $200 and it was okay as a netflix and Youtube machine, and nothing more. The Linux features were harder to activate and use than just buying a used Thinkpad for also $200, with a way better processor and twice as much memory, so I eventually did that to replace it and should have done that first. It aged like raw meat for being a "premium" product.
Mine in particular died a slow and painful death. The thermal paste had aged out, and the fan died, though was cheap and easy to replace, but even after, it still was nonfunctional, as it would die after being on for just a few minutes. Because it was running Linux with weird userland stuff like Crouton, it was devilishly hard to debug. I also just do not know how to debug Linux nearly as well as I understand Windows "internals".
It's too bad because it was a pretty laptop with a very nice screen.
A bunch of the models still only ship with 4GB RAM today! 8GB is just recently more common I'd say, but still plenty of 4GB ones out there you can buy brand new.
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.
Wow, this is a big announcement for sure. Not much details but I'll definitely following chromium's code review system[1] closer now (Large parts of ChromeOS are developed in the chromium monorepo).
No details on why the Android stack is somehow more magical for AI? ... Or did they just fire all the ChromeOS devs and need to share resources with Android now? Why not Fuscia for something new?
Probably more of an internal mandate that everything needs to consider how it can integrate/improve on AI so they included some lip service in case a VP reads this.
Probably CrOS team doesn't have enough manpower to implement necessary local ML infrastructure and want to borrow Android's. Or at least they're using this as an excuse for paying off long standing organizational tech debts.
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.
Let's not be obtuse -- if you're familiar with internal info on this, you should/could understand exactly what I'm talking about. If you're just trying to do a drive-by dunk about spelling, and just thought it was cute to add on "internal" while doing so...more power to you, I guess.
Yes, there's an extra S in Fuchsia so I'm 3 trolls in a trench coat pretending to be me.
I hope your day gets better! However you're feeling, it's temporary, it's not worth trolling and doing a know-nothing thing in public, it's too demeaning to yourself.
People can see my comment, profile, and site, and then see you're completely anonymous.
Then they're left with either: A) you're so hung up on an extra S you're lying on purpose B) you're a vindictive liar: you don't care enough to find out who I am, even though it's right in my profile, but you do care enough to pretend it's unknowable or C) youre having some sort of psychotic break from reality
You seem to be very troubled to resort to such childish attacks because my opinion differs from yours. You've presented no evidence that you have any internal knowledge of Fuchsia.
Okay so you're still refusing to acknowledge who it is? Great talk, thanks for your thoughtful contributions. Btw, you haven't expressed any opinion here other than "THERES AN EXTRA S" and some weird insistence you can't figure out who OP is. idk what conversation you're inventing in your head, but it really is embarrassing, especially when they clearly had the scoop on the news by a couple weeks. Nobody can take you seriously here, it's obvious trolling
Both of my Nest devices that got the update were bricked into an unrecoverable state. Forums and Reddit are full of similar stories. "Shipped" is a very generous label.
I don't know anyone outside the Fuchsia team that takes it seriously.
They're a troll with an extreme sense of grievance and unclear motivations. Perhaps this whole extra-S thing is actually it, but I hope not, for their sake.
That is the reason they cannot achieve it. Territorial claims and wars. Group and team efforts. leadership buy in. the more money those guys are paid, the less team works they produce.
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
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.
It might be your bias, or even mine, but in my opinion, what you and I are saying are pretty much the same...
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".
You can go to a normal store and buy a device using fuchsia today, it's just not advertising that is the OS under the hood. That is why I do not think what you said is the same thing.
They updated their Google nest smart display to fuchsia a couple of years ago. I can't find the write up at the moment, but it was quite the engineering feat and the software engineers were quite nervous the day of OTA.
Fuchsia is just a parking lot project with lofty goals to keep talented engineers from going to other companies. The only thing it will ever ship to is EOL Nest/Hub devices.
A while back they were privately demoing ChromeOS alongside android on phones to enable a better desktop experience. They're also enabling display port on the new Pixel. My guess is they are making ChromeOS more like Android to make that process easier.
Does this imply that Crostini/ Crouton / Linux developer mode will go away? I'm quite proud of the development I've done on a $200 chromebook and it was one of my favorite features.
They don't provide a lot of detail, but moving to a new OS platform would mean migrating functionality, and often that means dropping less popular features.
Crouton / Chrostini seem to have a lot of dependencies on the current ChromeOS platform that would be costly to migrate.
> 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.
If anything, the work on top of pKVM has very nearly brought the same feature to Android already, though they haven't to my knowledge finished executing on that vision.
Of course, running a custom VM image like crostini would require system level support but that doesn't seem like it would be a problem or outside the scope of the avf architecture.
The ChromeOS team is pretty conservative with major feature releases and generally won't make something available by default until it goes through a ton of testing internally and with external testers.
ChromeOS is quite different that other Linux based OSs in that it's supposed to "just work".
ChromeOS VMs use Wayland over VirtIO for the GUI. Quick search tells me at least some people think Android has made design choices that are difficult to use Wayland with. Anyone know better?
FWIW this part is true, but sort of mixed up. It's not really "wayland" that's at issue (Wayland surfaces are just shared memory like they are with any other compositor). It's that the Android GPU HAL wasn't designed with the sharing of contexts in mind, and so getting accelerated rendering out of the VM isn't a natural thing.
And this isn't my area, and I have no expertise to offer except to say that I too am hopeful folks work this out in both a HAL- and open-source friendly way.
And also to say that I'm running routine wayland apps on a chromebook every day and they render and composite just great with Mesa/LLVMPipe contexts, even things like e.g. STL slicers you'd expect to want the GPU. The need for acceleration is real, but limited to some special use cases.
> is there an android terminal? I'm only familiar with debugging mobile devices over adb and it's restricted.
> 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.)
Look it's a bunch of theory right now. From what I can tell, your examples would still need integrating into AOSP-- not something that is running right now. I may have a different definition of "shipped" but this wouldn't meet my bar and seems to be more work.
It's possible you are a wizard and I'm a novice so I can't wait to see your demo soon.
No, it's not a theory; I'm describing to you how Android has worked for at least the last decade. If you have an Android phone, this is how the device in your hand works today.
It appears that you and I are having different conversations. I said that 1. it is currently possible to run a terminal on Android, which lets you run commands as an unprivileged user on the Android system, and 2. both Android "typical" Linux are perfectly capable of booting into a graphical environment, though non-Android Linuxes frequently allow you to boot to a virtual terminal as well preferentially. Having gone through the whole thread, I guess by "is there an android terminal?" you actually meant to ask "is there an android terminal that gives you a shell inside a transparent VM like ChromeOS does with Crostini?" If that's what you mean, then it's true that that's less developed (though it does exist - https://www.esper.io/blog/android-dessert-bites-13-virtualiz... is one of the better practical guides I've seen for "how do I run a linux VM on my phone?"). Although if that's the main thing you're asking about, I don't understand why we're talking about boot processes at all; VMs in both Android and ChromeOS (and server and desktop Linux, while we're mentioning) are more or less just fancy user applications, they don't affect the boot process.
ChromeOS Linux Developer Mode is Debian containers in LXC (with ability to run custom containers existing but being very painful). Anything else than a real VM running LXC-style containers means the feature would be going away.
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?
You can run a full VSCode on Crostini -- the "real" Electron app -- but not on Termux. There are ways around it like using code-server on a Linux environment, but far from the same thing.
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.
The issue you linked is more or less resolved at this point. If you find Termux processes being killed, just run this command over adb shell and you're good:
settings put global settings_enable_monitor_phantom_procs false
Google added this setting in response to a bug report submitted by a Termux maintainer. It's also persistent, so you only have to run the command once.
> I'm quite proud of the development I've done on a $200 chromebook
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.
Same story here, except my quick and temporary purchase was about five years ago. It's been my daily driver for off-desk work ever since. It's still snappy and the battery life is great, too.
I went full Linux on it using MrChromebox[0] a few years back with zero complaints.
It's uncanny how many devs have a story like this. There's something about compiling software on a barebones machine, almost like restoring an old VW and taking it to the track.
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
It's great for reducing distractions and getting a better feel when the code you're writing is slower than it ought to be. My desktop is an M1 Mac Mini, which has been phenomenal, but it can certainly hide inefficiencies in code.
Once I get my office situation set, I want to start doing everything on an RPi.
I had the same thought reading the title, but then remembered Crostini is a container running in a VM (Goddammit), so they can keep it intact, at least if they want so.
Well, this is a slap in the face. ChromeOS has had a long-standing tradition of requiring device kernels to be in their tree. Giving them a better shot at long-term/community/Linux support.
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.
I don't think this will go away since Google makes the call about what core hardware you are allowed to put into a Chromebook. After all they have to provide 10 years of updates.
Most likely something like Qualcomm (or another similar vendor) saying that they refuse to provide the vendor kernel, and will just ship Windows on ARM instead.
Hmm, maybe they are referring to a specific branding used on recent models, e.g. a "Windows on Snapdragon" sticker similar to "Windows 8 Ready" and stuff.
Linux laptops still tend to be special order or niche brands, but there is nice positive traction in that space.
This is quintessential MSFT. I have absolutely less than zero doubt that there is a informal/formal agreement that they're called such. They always pull this crap. And then their OEMs realize later that the "Windows 8 Ready" sticker is almost more of a pariah.
Wow uhh this is horrifying. ChromeOS was becoming a very competent capable FreeDesktop style host, with excellent work in cros (for secure virtualized access to sound, GPU, encoders, storage) and moving towards standard Wayland compatibility. As the Linux ecosystem got better, so too did ChromeOS. There's so much Google didn't have to reinvent, so much driver work & projects like LXC containers they could benefit from. Throw all that out, I guess.
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.
Not sure you can make this move an example of them having a very high ‘not invented here’ thing going on, given that Androids’ commercial competitors are windows and iOS
It's somewhat unusual for Google to open source and mainline this bit of functionality. Last time I heard, Google's internal production Linux kernel still has 9000+ patches[0] on top of vanilla Linux. And I'm still waiting for them to open source switchto[1].
And for a brief couple years Google had an offering the world could use that exposed that invention. Via the stock, well respected LXC tool.
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.
Cgroups is a kernel feature, parent is talking about the userspace stack for managing containers. Google uses LXC in crosvm, and didn't have to program it from scratch.
I somewhat secretly hope that they move their ChromeOS display stack over to Android (with compatibility shims where obviously needed).
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 timing of this really makes it feel like a “I’m still here!” message after Apple’s announcements. If this was planned before Apple’s announcements I would think there would be more details.
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.
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.
> we’ll be embracing portions of the Android stack, like the Android Linux kernel and Android frameworks, as part of the foundation of ChromeOS.
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.
> Ew. ChromeOS was always a beautiful contrast to Android, running mainline kernels instead of Android's hacked up mess.
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 tend to not believe that it's just that, because even Google's own phones have never run mainline kernels outside of experiments that never actually shipped to end users.
It cuts both ways. Desktop linux NIHed a bunch of basic features in some buggy, insecure C code that barely works. Like, it has absolutely zero security, no accessibility, no fine-grained permissions system, no normal cross-application communication, no userspace resource control (cgroups are cool, but they are not exposed)..
Okay, except that... almost none of that is true? Desktop Linux started early enough that I don't think it could have NIH issues and has mostly iterated ever since; I grant that maybe it could have picked up something like GNUstep, but that's not obviously a good idea in hindsight and definitely wasn't at the time. And Linux is doing fine on security, is definitely behind on a11y but still has it, and mostly does cross-app communication through dbus. I will grant that resource control is underdeveloped (though I'm not aware of any other desktop OS doing it better?), and permissions only really became a thing recently with flatpak.
Linux is behind other OSs at this point in terms of desktop security and hardening; there are of course ever-evolving mitigations for things like memory safety issues, but everyone has that, and more broadly the standard Unix permission model in the single-user system where every application has more-or-less unlimited access to everything else under your account, is very dated. In practice given a random Linux dev installation, it's morally equivalent to a workstation where you only use root. Flatpak-on-everything is like the absolute bare minimum for a comparison to ChromeOS or Android if we're being honest, and still many apps still aren't designed around supporting things like XDG Portals so permissions are typically much more coarse-grained than necessary. Not to mention the general atrocity that is setuid.
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.
That's what power users do when say 'Linux in insecure because wih $HOME you can loss all you real life assets'. Wel, first at all, anyone with at least two neurons would create separate users for work, financial/goverment data and gaming/leisure/casual browsing.
> I had always dreamed that one day Google would rebase Android to use a ChromeOS base running apps through a compatibility layer
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?
This is an obvious precursor to the rumoured desktop mode coming to Pixel phones.
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.
Not if the price is confining yourself to only loading web pages with the odd api extension.
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.
I don't develop on Android so I have no perspective on whether it's a better situation, but as a user of both Android and ChromeOS on the daily, my impression of ChromeOS is that it is minimally intrusive, updates instantly, sleeps and wakes instantly, switches users instantly. My impression of Android is updates take forever, there are 90 minutes of hideous jank after a restart, and it takes 15+ minutes to take a bug report. But I have no way of telling from this announcement which parts of the Android tech stack are responsible for it being a pyramid of jank. However it sounds like Android has won an internal turf war and it seems inevitable that their user-oblivious development and release process will eventually tarnish ChromeOS.
So I used to be an Android dev and left years ago because of how mismanaged their upper levels of the stack became. Their Java API was never good (j2me was cleaner) but somehow the extensions rarely represented an improvement and just introduced more new problems.
The low level pieces of Android have dramatically improved over the years though, and are clearly battle tested at enormous scale. Binder, of recent security problems, is functionally very useful. The graphics system handles DRM and HDR on different hardware surprisingly well these days, and even the audio stack is far less annoying than it used to be. Considering that Android devices are expected to run continuously this is no small achievement. Some years ago I wrote and deployed Android code that decodes and plays video, with audio, constantly, for months on end, synchronized to an external clock, on a random cheap OEM board, while downloading the next one over a flaky network, with relatively minor alterations to the OS being necessary. It may be possible on other things but I would probably still be debugging it.
ChromeOS threat model: After remote code execution exploit in some Chrome process + chained sandbox breakout exploit + chained privilege escalation to root/kernel mode, the user should be safe again after rebooting the device.
I don't understand what you're suggesting. ChromeOS has an extensively documented threat model and it is, quite unarguably, vastly more intimate and well defined than any comparable desktop solution in the FOSS world. ChromeOS also has more tight distribution and product requirements for official devices which helps it even further, even compared to something like Android, because OEMs can't shit it up so easily e.g. longer security lifecycle, open bootloaders, mandatory hardware for verified/secure boot, etc.
>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.
> Linux desktops have no well-defined "minimum API version" that developers can target like they can on Android.
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.
For your point 2, I had to stop them from throwing that out of the window all the way back circa 2.3.
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.
Is this Google acknowledging the same thing that Apple has: that x86 is a dead end and ARM is required for high-quality, portable device experiences? Hence optimising for an Android tech stack vs going further down the ChromeOS/Linux path.
I think the first proclamation about how x86 has reached its end I read was in 1992 when the DEC Alpha came out. (It's possibly of course there were even earlier ones.) The chorus became louder when Intel successfully convinced the entire world IA64 will work just as well as it is shown in a PowerPoint despite the failure of Multiflow, Cydrome and their own i860. The new shiny is always shiny... but it doesn't mean it's that much better. You mistake a very tight integration of the stack from silicon all the way up to UI for some miraculous efficiency of ARM vs x86. This is not so.
"The reports of my death are greatly exaggerated ..."
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.
Would be great if chromeos flex would start supporting organisation provided wifi credentials - currently only device generated keys are an option, meaning one has no idea whatsoever if keys generated are actually good enough or are just looking random while generated might be generated predictably. No idea, as it's a black box. Allow organisations to generate keys off device and allow these to be uploaded to the device, and then we can start considering it.
The other problem is that other vendors do not provide chromeos versions of their tools. Looking at you Fortinet and your vpn.
somewhat related, I'm curious what the future of fuchsia is? I would have imagined that transitioning Chromebook to fuchsia would be possible at some point, but going to android makes it seem less likely?
Does this mean that multi-threaded Chromebook applications go away? Android doesn't really do threads in the usual sense. It mostly uses a hack involving multiple processes. And the "main thread" is very special.
This is not really moving ChromeOS to Android, but rather using their Android Bluetooth component over the crusty Linux blueZ-thingy. And they even talk about the possibility of running the Android Bluetooth component on normal Linux. So there would be no ‘threading’ like repercussions as far as I would see?
How do you mean? You can spin up threads using stock Java API or pthread on NDK. (If you intend to run them in the background your app will need an active foreground service to not get killed, though). As far as the "main thread", I don't think that's unusual for most user interface frameworks.
From what I have heard from Google employees, no one at Google really cares about it. It is used in one of their smart speakers and maybe another nest thing. I would not at all be surprised if it winds up in the google graveyard.
Contrast this to something like the Zig or FreeBSD Foundation, which are specifically created to further a technical system and immune to quarterly re-orgs.
Let's stop begging at the table of big-tech for software scraps.
> 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.
If I had to choose, I would much rather do HTML+JS apps than Android+Java/Kotlin. I know there are a million good reasons why someone could say Android is a better platform than the web, but after working as a Java/Android developer for 5 years, I still don't believe that. I'm a little saddened to hear this, but I imagine there is more to the story. And, I was thrilled when Android apps could run on Chromebooks.
Why do you believe that? Kotlin is probably the best language I’ve ever come across - and compose multiplatform is _fantastic_ and solves a lot of problems that nothing yet has.
I agree, Kotlin is great. It's just the Android platform that I find really frustrating. Now that you ask, I am struggling to say concretely what I dislike about it as a developer, maybe that is the trauma. It is my daily driver as a phone and I definitely prefer the openness of Android to iOS.
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.
477 comments
[ 0.27 ms ] story [ 328 ms ] threadIt 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...
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.
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?
Also, python is just the glue, the work happens in libraries.
https://info.juliahub.com/case-studies
Likewise I wouldn't use Python for anything besides teaching programming, or scripting OS tasks and native 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.
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.
You look like never touched Perl seriously, Raku it's still a hard deviation.
No one used Perl6 on real life environments. It's the Duke Nukem Forever of the programming languages.
Using Perl6 as an argument on Perl5 it's like bashing the simple and clean ANSI C giving C++ as the example and its the crazy redundant features as a rant.
We're talking about the choice of Python for ML when CUDA came along, nearly 20 years ago. Upthread, alaties said:
> Around 2007, the main competitors in the scripting space had a lot of issues: [...]
> Perl [...] unstable
RadiozRadios replied:
> Huh? Please elaborate.
I did.
In 2007, Perl 6 was not Raku, it was intended to be the next major version of Perl. But it had been in development for ~7 years already, couldn't be relied on or predicted, and had become a bit of a joke. Since Perl 6 was still supposed to be the future of Perl, in 2007 Perl very much seemed unstable and unsuitable as a foundation for ML research.
Well, it's as true of Guile as it is of Tcl and Perl...
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.
With regards to the memory I went looking and the framework has 2 ddr5 laptop dimm slots. The largest I was able to find were 48 gb modules so the physical limit may be 96gb.
And as a closing note, this was the first time I really looked at the framework laptop page. And while I am still not sure about the build quality or the usefulness of the "ports". the number of guides and photos of laptops under surgery sold me, I think I found my next machine.
It has to be something like that. That's a standard length M.2 slot...
> https://community.frame.work/t/will-framework-chromebook-wor... Installed WD Black SN850X 4 TB (WDS400T2X0E) on my Framework Chromebook. I’ve been using it for a month and a half now. Everything is fine. The only point, probably due to which the use of such disks is not officially recommended, is the excessive reserved space for the OS. Apparently this is a legacy of the times when disks in Chromebooks were of small sizes. If you are happy with the situation where a quarter of the disk will be idle for technical reasons, then you can take it.
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?
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.
And Surface runs Windows. Gonna plead the fifth on that.
(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.)
Maybe Vulkan support through Linux (only HW accelerated OpenGL GLES works right now for me)
Screen was super nice though. It was never worth $1000
Mine in particular died a slow and painful death. The thermal paste had aged out, and the fan died, though was cheap and easy to replace, but even after, it still was nonfunctional, as it would die after being on for just a few minutes. Because it was running Linux with weird userland stuff like Crouton, it was devilishly hard to debug. I also just do not know how to debug Linux nearly as well as I understand Windows "internals".
It's too bad because it was a pretty laptop with a very nice screen.
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.
https://www.ebay.com/itm/335423020537
[1] https://chromium-review.googlesource.com/q/status:open+-is:w...
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 hope your day gets better! However you're feeling, it's temporary, it's not worth trolling and doing a know-nothing thing in public, it's too demeaning to yourself.
People can see my comment, profile, and site, and then see you're completely anonymous.
Then they're left with either: A) you're so hung up on an extra S you're lying on purpose B) you're a vindictive liar: you don't care enough to find out who I am, even though it's right in my profile, but you do care enough to pretend it's unknowable or C) youre having some sort of psychotic break from reality
I don't know anyone outside the Fuchsia team that takes it seriously.
Because they are panicking and need to add AI faster than Apple and Microsoft across their whole portfolio.
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
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".
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.
Of course, running a custom VM image like crostini would require system level support but that doesn't seem like it would be a problem or outside the scope of the avf architecture.
ChromeOS is quite different that other Linux based OSs in that it's supposed to "just work".
https://www.gfxstrand.net/faith/projects/wayland/wayland-and...
And this isn't my area, and I have no expertise to offer except to say that I too am hopeful folks work this out in both a HAL- and open-source friendly way.
And also to say that I'm running routine wayland apps on a chromebook every day and they render and composite just great with Mesa/LLVMPipe contexts, even things like e.g. STL slicers you'd expect to want the GPU. The need for acceleration is real, but limited to some special use cases.
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.)
It's possible you are a wizard and I'm a novice so I can't wait to see your demo soon.
All of the concepts as you've described will take some dev time to actually turn into a product.
It took Google years to make Linux VMs part of the ChromeOS product and that was with a working hack solution already available for them.
My point is that your theory will not be shippable on day one.
https://termux.dev/en/
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?
I'm having a Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch moment here
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.
The more pressing issue at this time is: https://github.com/termux/termux-app/issues/2155
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.
[0] http://mrchromebox.tech/
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
Once I get my office situation set, I want to start doing everything on an RPi.
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?
Linux laptops still tend to be special order or niche brands, but there is nice positive traction in that space.
Next 5 years will be much more interesting than the 2 years before.
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...
[0]: https://lwn.net/Articles/871195/
[1]: https://www.youtube.com/watch?v=KXuZi9aeGTw
https://lkml.org/lkml/2020/7/22/1204
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.
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.
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.
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.
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.
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
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.
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.
The low level pieces of Android have dramatically improved over the years though, and are clearly battle tested at enormous scale. Binder, of recent security problems, is functionally very useful. The graphics system handles DRM and HDR on different hardware surprisingly well these days, and even the audio stack is far less annoying than it used to be. Considering that Android devices are expected to run continuously this is no small achievement. Some years ago I wrote and deployed Android code that decodes and plays video, with audio, constantly, for months on end, synchronized to an external clock, on a random cheap OEM board, while downloading the next one over a flaky network, with relatively minor alterations to the OS being necessary. It may be possible on other things but I would probably still be debugging it.
https://www.chromium.org/chromium-os/chromiumos-design-docs/...
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.
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.
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.
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.
The other problem is that other vendors do not provide chromeos versions of their tools. Looking at you Fortinet and your vpn.
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.
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.
Its neat to be able to just carry around a mini desktop computer
After a bit of reflection, here are a few of the things I recall hating:
And the latest APIs are very sexy.
https://web.dev/blog/new-in-the-web-io2024?hl=en