> 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).
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.
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.
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.
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 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.
> 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.
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.
"<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".
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.
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.
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..
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.
"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
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".
Readit News
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).
> 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.
> 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.
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.
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.)
literally the entire linked article is about them doing this work
True, but what about running Firefox natively, without the sandbox?
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.
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.
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.
"<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"
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".
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.
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.
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...)
Archive link: https://archive.is/WC3qp
"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?"
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.
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 someone would write this article.