Lacros on Chromebooks transition plan won’t be quick | Hacker News Reader

Lacros on Chromebooks transition plan won’t be quick

aboutchromebooks.com

> So how does a browser that should provide a fully integrated experience on a Chromebook do the same? That browser has to communicate with the operating system which provides some of that functionality. Google has had to create much of that functionality for an external, or non-integrated browser over the past three years.

Does this also mean it would be feasible to port Firefox and have it be the native and default browser on ChromeOS with the same OS integration as Chrome? That would be pretty cool. (I'm aware that there are ways to run Firefox on ChromeOS today).

It's already possible to run Firefox on chromeOS, see https://support.mozilla.org/en-US/kb/run-firefox-chromeos

> with the same OS integration as Chrome?

This, however, would require a lot of changes in chromeOS itself that Google won't do. It would be possible in a fork of chromeOS, though that would be a lot of work and would involve adding several APIs to Firefox that chromeOS relies on.

> It's already possible to run Firefox on ChromeOS

True, but what about running Firefox natively, without the sandbox?

You mean running without the VM?

Sandbox doesn’t mean non native, Chrome itself is arguably running in a sandbox.

As my original comment said very clearly, I am aware that you can run Firefox on ChromeOS today. That's not what I'm talking about.

> This, however, would require a lot of changes in chromeOS itself that Google won't do

Lacros is exactly those changes, though. That's my point. Google already did the work to add all the integration points you need to integrate a browser into the OS.

> Lacros is exactly those changes, though.

Lacros doesn't give Firefox the APIs that ChromeOS utilizes from Chrome that Firefox lacks. E.g. web battery API, web bluetooth API, web USB API, etc. These are the changes I'm referring to. That's my point. That's what I mean when I said:

> [this] would involve adding several APIs to Firefox that chromeOS relies on.

It's possible to run a virtual machine on ChromeOS, and within that virtual machine it's possible to run Firefox. This is not the same as running Firefox. A ton of things (like drag and drop, video calls, and some aspects of rendering) are subtly broken. There is no hardware acceleration. Performance is atrocious; expect 15 FPS video maximum. There is a separation between Firefox and the rest of the system, with two filesystems and links opening in the wrong software. Accessing any hardware peripherals such as security keys, cameras, or microphones is unreliable at best.

To anyone who has never had the misfortune of using a Chromebook: this stuff works terribly. Don't listen to anyone telling you otherwise.

(I think it's actually a container rather than a virtual machine.)

It is a VM though with a light weight VMM

> crosvm is a custom virtual machine monitor that takes care of managing KVM, the guest VM, and facilitating the low-level (virtio-based) communication.

However the actual application is run within a container inside that VM - if I understand correctly.

https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con...

Firefox had an OS, and it was rebranded to KaiOS, which is still extant and active today.

FirefoxOS/KaiOS, however, is targeted only for feature phones, and therefore, resource-constrained systems. I did enjoy one such phone, and it had a fairly decent browser, though I can't say that it had any Firefox-like features that I could identify, because it was so incredibly minimal.

The browser might be OK. The rest of the OS is absolute hell. Missed opportunity.

> would require a lot of changes in chromeOS itself that Google won't do.

literally the entire linked article is about them doing this work

> literally the entire linked article is about them doing this work

Lacros doesn't give Firefox the APIs that ChromeOS utilizes from Chrome that Firefox lacks. E.g. web battery API, web bluetooth API, web USB API, etc. These are the changes I'm referring to. That's my point. That's what I mean when I said:

> [this] would involve adding several APIs to Firefox that chromeOS relies on.

It does seem that way, at least assuming that the APIs are stable - and I assume they will be since the whole point is that both sides won't have to coordinate their releases.

I suspect "stability" will look a lot different from Windows though. They won't be supporting old versions of the API for 30 years but maybe 3 months, since both browser and OS are still expected to be kept up to date for security reasons and supporting old versions of code is onerous.

Edit: found this -

> The API boundary initially will be semi-stable: it will tolerate 1-2 milestones of version skew. We may allow larger amounts of skew in the future.

FF would have a hard time keeping up I think.

I imagine that as things stabilize Firefox will be able to handle it. After all, it needs to be manageable by the Chrome team too. Unless the Chrome team is given hidden notice about API changes well in advance, which seems sort of unlikely.

Every time an API changes, whether by a little or a lot, the FF team has about 2 months to deal with it. You think that's going to happen? There's just a squad of engineers sitting around doing nothing at all times, waiting for the next emergency to drop? The amount of resources moz would need to allocate to this project (which has little purpose given alternatives) would be prohibitive.

> Every time an API changes, whether by a little or a lot, the FF team has about 2 months to deal with it. You think that's going to happen?

Yes? That doesn't sound that hard. Browser release on a tighter cadence than that. And it's just starting off at 2 months.

> There's just a squad of engineers sitting around doing nothing at all times, waiting for the next emergency to drop?

Uh... no? They would be normal FF engineers who would sometimes get a release ticket that says they need to update to a new API...

> The amount of resources moz would need to allocate to this project (which has little purpose given alternatives) would be prohibitive.

Totally disagree. This sounds like something engineers could take as a chore.

The fact that you think this sounds easy makes it apparent how little experience you have in this domain.

The domain of writing software against an API?

> In the current situation, whenever the Chrome browser needs an update, say for a security patch, Google has to push that to Chromebooks in a ChromeOS update.

Surely they saw this coming from a long way away. It makes me wonder about the conversations that set them down this path in the first place.

I guess it started something like:

"<Insert your favourite emacs is an OS/window manager/whatever>"

"Uh, wait, what if the browser was actually the OS? After all most people work in the browser most of the time right?"

"<Mind blown meme>"

"How hard would it be to run chrome directly kn hardware?"

"Nah, just put a little Linux kernel and a bit of strictly necessary user land and we can pretend chrome runs natively"

... Time passes

"We need a file manager, we need a notification bar, we need a dock, we need a clipboard, we need support for Android apps, we need ... an OS that's not just a browser"

> "We need a file manager, we need a notification bar, we need a dock, we need a clipboard, we need support for Android apps, we need ... an OS that's not just a browser"

That's what 100% absolutely kills me with Chrome OS. When I first used the CR48 it felt like a companion device to my main desktop Chrome environment. Now it's trying too hard to be a primary device, and now with Google deploying Android tablets and Chrome OS-powered tablets it's like nobody knows what platform needs to be on what endpoints anymore. Will the laptop run Chrome OS? Lacros? Android? Who knows!

I really really wish I could have a ChromeOS fork that goes back to the simple "the browser window is the OS, no more, no less".

The ones that enabled them to launch the most popular Linux distribution in the world by far? One that's really really hard to break because it uses phone-like A/B partitioning with read-only OS installation making separately updateable system browser hard.

It was a tradeoff, and a good one based on history. Remember that, as long as the device isn't EOL, ChromeOS updates with the same cadence as Chrome the browser.

In US, in the world, not really.

I'm not following. Is there a particular market you feel isn't getting updates? I'm sure there are exceptions somewhere (I'm certainly no expert, I do firmware) but effectively there are no market-specific ChromeOS builds. A Chromebook is a Chromebook anywhere in the world, and gets the same images off the same internet as any other Chromebook.

Chromebooks are only relevant in the US school market, not "most popular Linux distribution in the world", unless we are talking about the usual World == US as in some sport activities.

Chromebooks are most used Linux distribution across any kind of metrics and locales.

From American point of view, surely.

Building the browser in allows for tighter integration, which I imagine is particularly important for an OS that's as constrained as ChromeOS (there are no native apps on the host that can just read/write to whatever files - it's not a typical Linux distro).

So the upside is a super constrained host, the downside is that any native app needs to be built in and shipped with the system. This means Chrome updates tend to be a few days to a few weeks behind on ChromeOS, which I don't think is a crazy trade-off. The major issue is that a few weeks is usually enough time to weaponize an exploit, although weaponizing one against Chrome on ChromeOS does feel particularly difficult and probably more than a few weeks of work to deliver reliably for end-to-end exploitation.

I think it's pretty typical to make decisions early on in a project based on expediency, especially when you don't know how popular that project might end up being.

The article actually understates how long this has been in the works. A predecessor of lacros was started around 2015ish. It's not an easy change to make on a fast-moving codebase.

I believe this would a great thing.

Make IETF standard for cloud notebooks

- If there is an username/password then

- Login from the screen

- If the backend (dropbox or MS or nextcloud or webdav) supports

* Drive(or storage) then it is loaded into a file manager

* Password manager -> it is loaded

* Bookmarks etc

This would mean they can claim that chromebooks are

- NOW UNIVERSAL

- No lockin

- No monopoly

- if other OEMs want they can replace the browser and ship it

(I discussed this with Firefox management that they should build this cloud notebook instead of boot2gecko-firefoxOS but...)

We are back at the network computers all over again.

Think it is great to go back to mainframe days. But the law makers need to provide some safety from AI/ML eating into privacy and law enforcement snooping.

Do you think there are many sales lost of chromebooks because there is lockin? I think most people care way less about that then you would hope.

This site is absolute cancer. Always amazed how people manage to break scrolling, a feature that comes for free with every web page.

Archive link: https://archive.is/WC3qp

JFC. Stop talking before they turn scrolling and the back button into microtransactions.

This reminds me of when Internet Explorer and Explorer in Win9x got integrated and "couldn't get separated". Then Google did the same thing with ChromeOS and now they are reverting on this decision..

Twice, that was the same on Android.

I think google did that because they did not use X windows. Purposefully. They specifically used Chrome's UI with some patches in-house so that it is slim and the login/bootup does not flicker like typical linux.

For those, like me, who wasn’t familiar with Lacros, here’s an official document from the Chromium project: https://chromium.googlesource.com/chromium/src/+/main/docs/l...

Somewhere inside Google:

"What if -- and stay with me here lads, this is a doozy of a brainwave -- what if we shipped ChromeOS as like a regular OS, a regular Linux distribution, with Chrome on top as an app?"

To be fair, I remember "desktop Linux" when I got my cr-48 and Linux has come a long way since then.

I think you're being a bit cheeky but I see the ChromeOS devs as pretty pragmatic. They shipped functional Linux and built a lot to make it work. And seem smartly open to re-using standard Linux bits where possible. For example, this move, or them adopting Wayland for their own presentation layer now that is mature enough, etc.

it was genius, IT admins didn't deploy Linux laptops they deployed chrome browsers everything ran on already. The management on Chromebooks is great and instant. I'd be very worried the nix world hasn't learnt anything yet from the Chromebook ux

I tend to come up as UNIX critic, however during university I was actually a UNIX zealot for the most part.

My critics and re-focus on Apple, Google and Microsoft ecosystems, steam from having discovered the alternative universes happening outside Bell Labs, being a fan of UNIXes that went their own way like NeXTSTEP, NeWS, A/UX, Irix, Solaris, instead of being yet another UNIX System V clone in user/developer experience.

Not sure if GNU/Linux has learned much from ChromeOS/Android UX, given the current state of desktop fragmentation.

> Not sure if GNU/Linux has learned much from ChromeOS/Android UX, given the current state of desktop fragmentation.

Maybe after 3 decades it is time to stop viewing "GNU/Linux or Linux" as a single entity/organisation. This is such a naive view.

This rant all over again is like complaining that the IT industry is fragmented and we have Google, AWS and Microsoft fragmenting the cloud offering, or that Render and Fly.io should not exist because Heroku was already there and people should just work for Heroku and make it a better product. Or that Apple and Microsoft should be working together. Or that Microsoft, Sony and Nintendo should stop duplicating their efforts and only offer a single, well made game console. Why have we so many cars brands? Why can I buy so many different yogurts?

That is why "The Year of Desktop Linux" has already happened, as VMs being shipped in macOS and Windows.

Interessly enough there are more of those at FOSDEM, than people carrying proper GNU/Linux laptops.

I went to fosdem for the first time this year. I had heard the stories, but most laptops I saw did appear to be running linux. Though maybe it is because I don't care about the big web dev and related rooms.

Natively, or as VM running full screen?

How many are using laptops from their employer (possibly with mandatory OS)?

How many of those attend FOSDEM with work laptops?

Would sound logical if their employer pay them to work on open source stuff?

Idk, but from the people I know that were there, most of them were running their own laptops, though that might not have been a representative sample.

Pretty sure most were running natively, but idk, I didn't ask them.

Well, it's semi-normal Gentoo that gets updated by replacing the OS partition :V

Current partition scheme would require updating to make way for replacing Chrome separately but is doable (I have non-Chrome but using same codebase setup that does swap components this way on OEM partition).

And then they'd say "wow yeah that's a great idea, it'll solve a couple of problems we have - but it's tricky, because the tight integration was how we got around the initial constraints we had, so it's going to take some time".

And then someone would write this article.

The side has some serious design issues making it basically unusable in some browsers...

How long until I can download and run Edge on Chrome OS?

Also why not just replace it with Android like "Andromeda" was supposed to do? Chrome OS already supports android, Chrome is already and android app, why not combine efforts?!

I wouldn’t want an Android version of Chrome as the main browser for a laptop OS.

Serious question: why would anyone want to run Edge? Most people in tech use Edge exactly once: to download another browser.

Firefox I can understand, but Edge?

I use edge for MS Teams, office 365 and anything that use microsoft ssO on my linux works computer. I don't want to taint my firefox profile/experience with microsoft stuff, and I figured the microsoft stuff will be better tested on edge than anything else, especially teams videocalls. Since my company mandate the use of microsoft stuff I decided to put everything behind Azure SSO with Edge for linux and keep everything else on firefox.

The only thing I use behind Azure SSO that is not on edge is AWS because I take advantage of the multi containers extension to run several profiles in parallel. But for that I use another browser, librewolf.

I use Edge sometimes, I like the tabs on the side and the PDF reader supports annotating the PDFs with text and drawing which is a great feature and keeps me using it for reading. Otherwise it's a Chromium browser, so it's not a hardship to use it. Too bad they removed the EPUB reader functionality when going Chromium.

The PDF reader is also the reason I use it. Switch it to cover mode and span the pages. It's better than Chrome's reader, IMO.

You can already download and run Edge on Chrome OS; it's as simple as `apt install microsoft-edge-stable`. All devices made since 2019 should feature support for a Linux VM (Termina) that runs a Debian container by default. I've been using it to run Edge since Microsoft released their Linux version back in 2021. It's inefficient and still suffers from UI bugs but it gets the job done.

How does this change affect Chrome OS's UI? I was under the impression that most of their system UI was written in html/css and displayed by the built-in Chrome browser? Is this incorrect?

I don't think that's the case, but in general this should be an invisible change to users - the main thing being that their browser will update more quickly and without any change to the OS.

> In the current situation, whenever the Chrome browser needs an update, say for a security patch, Google has to push that to Chromebooks in a ChromeOS update. That takes more time and effort than it does for the Chrome browser on Linux, macOS, and Windows.

Oh no, nobody could see this would be the natural outcome of deeply integrating your browser into your OS. mild shock

Yeah, especially Google. They definitely don't have any experience with a common mobile OS and the need to update the system web view independently from the base os. /s

Reply on news.ycombinator.com