Well l hope the coding is as pretty as the flower. Lightweight, secure and usable to the open source platform.
Very easy to take cuttings from!
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...
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?
OOP isn't about making things faster, it's about isolating functional blocks from each other. C++ will let you write bad code, but done properly it can produce robust, testable code that isn't much slower than raw C. If you think otherwise you're doing it wrong (and yes, I've seen an awful lot of programmers who claim to understand OOP who don't)
Let me fix that for you: "C++ will let you write code that looks completely innocent, but turns out to be a major security issue because the designers of C++ made some weird decisions in their early days".
The Problem with C++ is that it has grown far beyond the realms of human cognition. While it is possible to read C++ code, it's rather hard to read in real world projects. Only if you restrict yourself to a small subset of it, you might have a chance. The problem is, if you have a team, you may have non overlapping subsets of the language being used by individual members.
My guess is that Google is experiencing the same "brain drain" many companies have. They just cannot get/keep top notch people the way they used to. Adding to that, there's an emerging group of programmers who grew up with Windows from the time it kinda worked. Those people believe that it's economically possible to write a working operating system on C++, because they have seen Microsoft doing that. They never experienced how small and simple an operating system can be, if you base it on the UNIX philosophy. For them C/C++ is the "state of the art".
Because we all know that a big dose of OOP always makes things better and faster
OOP is only one of the things you can do with C++, you know.
The article doesn't mention OOP, so there's no reason to suppose that that's how C++ is being used.
... and, anyway, the point of OOP isn't to make things faster, it's to make it easier to understand them in the hope that those working on them will make fewer mistakes, and end up with something more reliable. I'm not suggesting that that's always the outcome, just that speed isn't everything.
"Google's brand new OS could replace Android" well... nope - pretty certain like 150% certain that Google have not spent 6 years building a developer community, getting more and more involved with the the development community and generally addressing the complaints of the users (admittedly - not all of them) - to then go back to the drawing board and start from scratch. It's only a few weeks ago that the Android development team did an AMA - none of these things are the signs of a project that is about to be superseded by an entirely new OS. A Google OS for tablets and Desktops running Windows, yup - that I can easily see happening.
It was meant to run everywhere (386, PPC, Alpha...) and support software written for many operating systems (WinAPI, OS/2, Posix, Mac). The problem with Microsoft was, that they never finished the things they were announcing.
In a way that seems to be a common theme with software written in "modern OOP"-languages like C++. Instead of focusing on small modular programs that do one thing right and only one thing, you end up with a hugely complex mess of binary APIs meant to do anything, but you replace them after a couple of years anyhow.
That presents a problem of its own. You're describing a process chain, and you know what they say about chains. Problem is, weak links aren't always obvious; problems can cascade and create non-obvious failures down the line when the failing process isn't really at fault. Trying to fix weak links is okay if you can access every single link, but Android is held hostage by stingy equipment manufacturers bent on protecting patents and trade secrets, meaning some of the links are impenetrable black boxes. Fixing broken chains with black boxes for links isn't always possible (because the black box could be the weak link but no replacement for it is available).
Hum... I see your point, but how long it would take for Google to show either Android developers the middle finger in both hands (unless the APIs, etc. are compatible). Or, how long it would take for Google to get people interested and then dropping the new OS as it dropped tools before?
Remember Orkut. And Wave. And several others that had some people involved on it then were killed when Google lost its interest.
How dare you say that Windows Phone flopped, I know someone who uses a Lumia 1020. She deliberately chose...Ah no wait I've just remembered it was given to her by her husband who had been given it at work. She is very happy with it and still uses....Ah no wait I've just remembered she got an iPhone instead......
" Will we be able to use our existing apps on the new OS, or will that require a major rewrite as well? Windows phone flopped because of poor app support, any OS lives and dies with its apps. "
I'd be very surprised if you couldn't. Remember that app developers are basically coding for the Dalvik VM, and the real machine level code is in Google's libraries and the infamous "binary blob". I doubt Google will ever set it loose in the real world if they can't port the Android userspace onto it (and the ChromeOS one, for good measure).
I don't see the problem, Google are already sorting the ability to only load as much of an app as need to view what you want. So if you have a link it just loads part of the app.
Add to that API's being sorted to work with either OS (As they are already doing with android apps on ChromeOS) and I don't see a problem.
If they came out with an OS that was more secure than Android, ran all the apps and had other added features plus fast updates I would buy it tomorrow.
About that Linux flame war - One consistent problem with Android is CPU core control. I have yet to see a governor determine accurately determine how many CPUs are needed and how fast they should be running. They need to know how many tasks may execute concurrently and whether or not intermittent loads are coming from a single operation (latency sensitive) or many operations (not sensitive). The hacks that try to make this work will make you cringe.
A new mobile OS that can control the CPU cores better could have at least 50% more battery life and 50% better performance for everyday tasks. A full-throttle benchmark would look the same, of course, but most uses are bursty.
Biting the hand that feeds IT © 1998–2019