Coinciding with the start of a new week is a software update for Chromebooks. A new Chrome OS 101 update is now rolling out to supported devices on the Stable Channel. Short of a brief announcement post, Google hasn’t provided details of what’s in this Chrome OS 101 update. I see Lacros mentioned dozens of times in the log I created though.
First things first for Chrome OS 101
It also appears some devices didn’t receive the initial Chrome OS 101 upgrade earlier this month.
Some owners of the Lenovo Chromebook Duet, for example, didn’t get their software version flipped to 101. This time around, those small Chrome tablets do get the update. That’ includes the dark boot screen, productivity launcher and other features we’ve been enjoying for a few weeks. Oh, the branding change of ChromeOS is there too.
Lacros is everywhere, hinting at a release soon
I also noticed a slew of references to work on Lacros, which is the Linux browser that Chromebooks will use instead of the native Chrome OS browser. Google is in the process of decoupling of the browser from the platform for several reasons.
Those code changes along with several mentions of Chrome OS 103 suggest to me that this transition may be starting in the next 6 to 8 weeks. Of course, I couldn’t wait. I’ve been running the Lacros browser full time on my Chromebook since Chrome OS 100.
I still wouldn’t recommend others follow suit just yet. That’s mainly because I don’t want to be responsible for any issues you might experience.
Still, the number of those issues that I’ve seen over the past few months has diminished. Suffice it to say, Lacros is coming along nicely!
Other Chrome OS 101 bits
Aside from the many Lacros changes, there’s also the inclusion of a ”Plan B”. No, it’s not a backup plan in case the Lacros rollout doesn’t work. This has to do with WebRTC, or Web Real Time Communications.
According to the WebRTC spec, Plan B has been in the works for nearly 30 releases. You might not be affected by though, based on the description:
People who use multiple audio tracks or multiple video tracks on a single PeerConnection will have to test their product under Unified Plan, and adapt accordingly. In the case where a call is initiated from a non-Chrome endpoint and replied to by Chrome, the form of the offer may have to change. People who do detailed SDP parsing and care about msid attributes will have to check that their parsing code picks up the new format (a=msid). The details on whether changes will be needed and how the apps need to change will be application dependent. We think that almost all applications that use only a single audio and a single video track per RTCPeerConnection will be unaffected by the change.
Unless you’ve been communication over multiple tracks on the same connection then, you probably won’t notice any changes. This is more of a service provided / developer change.
A behind-the-scenes fix for the Password Checker feature is also in Chrome OS 101. Apparently, the checker would loop endlessly when scouring your passwords against databases with known compromised credentials.
