Google's brand new OS could replace Android The source code of Google's latest operating system has emerged, and it looks like all new code from the ground up. The Fuchsia project can be found here, and uses an entirely new kernel, "Magenta." It boots on ARM and x86, and the authors say they've managed to boot it on a Raspberry Pi. The IPC part is Mojo and higher up the …
Yeah, maybe, or people will buy a Chrome/Fuchsia book and a PS4. It does seem that MSFT is trying to leverage XBox to do something with Windows that requires a heavy desktop OS... because everything else works in a browser and you don't need Windows to run a browser. They were trying to use Office to fill that role, but then Google Apps started eating their lunch so they had to browserize Office... to some extent at least.
Can't get much info on it being in China, but I wonder how much of it will be proprietary. Running on both ARM and x86 architecture makes it an interesting product. Let's hope it can handle a bit more processing than the current Android crippleware. Would be interesting to see if it can build a little grid and share computing power over a network. Need more power to play VR games? Add another CPU unit. Would do wonders for sales levels of smartphones and low flops units.
Should be enough to feed video streams. Use composite video grids as well, rendering part of the screen rather than the whole thing per device.
The problem is telling it what to render. if you have a device 5m away you have a minimum 30 milisecond latency just for the round trip. That's before you've done anything.
They're saying the right things. A microkernel with drivers in userland is a good thing, so long as the microkernel implements IPC, which is where Mach went wrong. Linux is a clever and well-modified homage to a 1969 minicomputer timesharing system. A modern kernel built with security (don't put much into the kernel) and networking (all networking is IPC) in mind would be welcome.
A fresh start with a minimalist light solution would be nice, but I don't see why this would change anything wrt the pushback from equipment manufacturers and network operators that is slowing the rate of updates to a crawl. To combat this problem Google would have to establish completely new terms for distribution of the new system, terms they also could apply to Android if they wanted to.
>I don't see why this would change anything wrt the pushback from equipment manufacturers and network operators that is slowing the rate of updates to a crawl.
Because with a different OS architecture, you could update more parts without waiting for an SoC vendor to release a binary blob to an ODM.
I can't tell whether you're joking. QNX as a mobile OS died with Blackberry's smartphone ambitions and doesn't give Google the power to say We Art Better Than Thou and Smarter Than Thou 2.
To be fair, it's engineers like these that are the real engines behind OS design these days. I strongly suspect they've heard of QNX and considered it.
QNX is not getting much use nowadays, but it works really well (I am a BB10 user). BB should do something to open it back up, since they are not making much with it any more. Fuschia may well be similar, but not kept locked up by a company that can't figure out how to tie its own shoelaces even when it does have good products.
QNX didn't die. It's on ice and I'd bet that it's for sale if Google is buying.
I thought QNX was doing quite well, with the rise of IoT and flashy in car stuff? They seem to be hiring...
https://bb.wd3.myworkdayjobs.com/QNX
Even thought BB10 died I still think QNX could be quite a smart little buy for BB. It's a well regarded, small, battle tested RTOS that does seem to 'just work'
>I can't tell whether you're joking. QNX as a mobile OS died with Blackberry's smartphone
And QNX lives on as it has for decades, battle tested, real time - and a tenth the size of Linux. Google are happy of there are devices around that inform them about their users, but those devices don't have to be phones.
Still, it'll probably save them headaches if they roll their own OS.
QNX was for years also the power behind the Reuters trading interfaces because it was stable and worked *really* well. Not sure if it still is in use, but it was safe and very light.
I suspect that being secure is where it would go wrong with Google. Google needs your data, and needs to hand that data to others for its business model to work. It's not in their interest to make things too safe, unless "safe" means that only they can get hold of it, of course (hence the brute-forcing you into having a Gmail account - at that point you have agreed to their conditions).
Apple has been doing that since they introduced iMessage, though obviously the integration goes no further since they have no real desire to support other messaging like AIM (does anyone still use that?) or GTalk.
I'm really surprised Google never did this for Android, especially since SMS was often on per message pricing back in when Apple introduced iMessage. Even if Google doesn't do it, I find it hard to believe no one developed an Android app that does this...I'll bet there are a dozen of them to choose from.
That seems like a crazy excuse, especially since the Linux core of Android has essentially forked from Android some time ago. The real reason they can't distribute updates quickly is because they let the OEMs customize it, thus they depend on the OEMs to port their changes onto new versions before they can be released. Sometimes the carriers add their own customizations too, though presumably that happens less often now that more and more phones are bought for full price and unlocked, instead of the old "free/discounted phone if you sign a contract" days.
>How does using the Linux kernel prevent Google from distributing Android updates?
It sure doesn't on the Nexus line which is the only Android phones I would buy new under warranty (ironically you can also get even quicker updates out of warranty with Cyan and its ilk). Pretty much a no brainer to only buy new phones from the companies responsible for the OS itself if you want timely updates and support.
>The real reason they can't distribute updates quickly is because they let the OEMs customize it, thus they depend on the OEMs to port their changes onto new versions before they can be released.
Doug, you're forgetting a few stages, such as the chip set vendors creating binary blobs that are them passed onto the ODMs.
"Why would manufacturers be more keen to accept a demand for no proprietary drivers or other binary blobs in the new OS than in Android?"
I think the idea is that if more of these blobs can be moved to Userland, the kernel is easier to update whether they're updated or not. In other words, the kernel doesn't have to be held hostage by patent-protected hardware whose code is only provided in blobs at the manufacturer's pleasure.
Although it's not settled law, contributing code to the kernel triggers the surrender of enormous amounts of software AND hardware patent rights to Linux and anyone else who wants to use it, thanks to the GPL poison-pill-patent-clause license. This may well mean that Google needs to roll its own OS to get the features it needs, or else keep hands strictly off and wait for Linus to someday get around to it before they can distribute features and updates they'd like to see.
"...GPL poison-pill-patent-clause license...".
Oh, good! It's the old FUD that GPL takes away all your rights and your firstborn children and your dog runs away and everything. That's not the GPL, Ms/Mr AC. The GPL is a choice of license, not a surrender.
So how are you and Steve and Bill and Satya getting along these days fighting the software cancer?
"Although it's not settled law, contributing code to the kernel triggers the surrender of enormous amounts of software AND hardware patent rights to Linux and anyone else who wants to use it, thanks to the GPL poison-pill-patent-clause license."
Incorrect. The poison-pill clause only exists in GPLv3, while the kernel by necessity (due to the wide codebase) is still at GPLv2. Anyway, containerization provides a way to safely run proprietary, patented code in an open kernel without surrendering patent protections.
>since the Linux core of Android has essentially forked from Android some time ago
Google maintain a patch set for Linux that they have been gradually getting mainlined.. not really all that different from the kernel RHEL etc use that ship with vendor patches. Hardly a fork.
In several cases the OEMs have to customize it, e.g. adding back USB Mass Storage, Dual SIM, Bluetooth car kit profiles, and better power management. They also often fix bugs that Google ignore. Nexus is only released in one/two territories, i.e. Google only needs to do certification in those (FCC/CE/UL/etc). OEMs sell in many more markets and have to certify for each of those. And, every time you change the kernel, you have to recertify (both time consuming and expensive).
"And, every time you change the kernel, you have to recertify (both time consuming and expensive)."
Can you provide a link that proves that? Please keep in mind that a lot of the radio stuff in Android is in userland and not the kernel itself.
And I wonder how much telemetry it would be passing back to the Gobble mothership after installation - is this Google's Windows 10?
They monetize everything, Shirley they're not doing this out as a freebie to world+dog out of the goodness of their shriveled, black, advertising-bedecked hearts?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
