Google’s Fuchsia OS Confirmed to Have Android App Support via Android Runtime(9to5google.com)
9to5google.com
Google’s Fuchsia OS Confirmed to Have Android App Support via Android Runtime
https://9to5google.com/2019/01/02/android-runtime-app-support-fuchsia/?xyz
150 comments
That's a big if on whether apps work or not though. It's already a pretty big hassle to design/test for the permutations that exist (with or without Play services, testing on ChromeOS, etc) compared to iOS development.
Since very early versions of Android, APIs existed for determining the characteristics of the hardware/software environment: What sensors exist, input methods, etc. If your app works on tablets and phones and handles orientation changes correctly, it will probably work in a window on a Fuchsia OS device.
It's about as much of a hassle than developing desktop app and less of a hassle than developing web apps. Meaning: really not that much of a hassle unless you're deliberately shooting yourself in a foot by doing equivalent of "position: absolute;" everywhere.
Which, for some reason, some iOS developers really loved doing which cause endless headaches when adding support to yet another form factor of those devices and endless "fragmentation" complaints.
Which, for some reason, some iOS developers really loved doing which cause endless headaches when adding support to yet another form factor of those devices and endless "fragmentation" complaints.
Big difference is Android on ChromeOS is using the Linux kernel that is part of ChromeOS. Here Android will be on top of Zircon. Which is the fuchsia kernel.
Now gnu/linux on ChromeOS is using a completely different Linux kernel.
It was important Google did it this way so gnu/Linux would still work when they update ChromeOS to Fuchsia. Google already has Gnu/linux running on fuchsia with something called Machina.
Now gnu/linux on ChromeOS is using a completely different Linux kernel.
It was important Google did it this way so gnu/Linux would still work when they update ChromeOS to Fuchsia. Google already has Gnu/linux running on fuchsia with something called Machina.
It doesn't make sense to say GNU/Linux on Zircon. That would be GNU/zircon. Unless you mean syscall translation layer.
It does though, assuming that machina is doing virtualization for zircon. Or am I confused?
If I'm understanding correctly, this would work the same way that the GNU/Linux termina VM is booted when using crostini currently.
If I'm understanding correctly, this would work the same way that the GNU/Linux termina VM is booted when using crostini currently.
This makes perfect sense, it would be naive to think that Flutter would be the only way to write apps for Fuchsia. Having such a hard break in compatibility would only succeed is tanking the new platform for consumers.
fuchsia apps use a different runtime ie part of the runtime ie the rendering part is in flutter in plain sight
from the web demos I have seen of fuchsia running flutter its the same UX as android ..different apis that's all and way faster rending pipeline via flutter rendering engine
from the web demos I have seen of fuchsia running flutter its the same UX as android ..different apis that's all and way faster rending pipeline via flutter rendering engine
Actually Fuchsia is getting an UI abstraction layer for multiple UI engines, where Flutter is just yet another UI.
Guess what will happen afterwards.
Guess what will happen afterwards.
What will happen afterwards? Will it become the only UI?
Here is Scenic, the UI agnostic scene graphic composition engine.
https://fuchsia.googlesource.com/garnet/+/master/docs/ui/sce...
Here is fuchsia-ui, an UI prototype done in Rust, remains to be seen if it really only meant for the Ermine session shell.
https://fuchsia.googlesource.com/garnet/+/0a214f5721d723a7d0...
I bet Flutter will either be yet another UI framework and then the one with market adoption wins, or it will be rebooted somehow.
https://fuchsia.googlesource.com/garnet/+/master/docs/ui/sce...
Here is fuchsia-ui, an UI prototype done in Rust, remains to be seen if it really only meant for the Ermine session shell.
https://fuchsia.googlesource.com/garnet/+/0a214f5721d723a7d0...
I bet Flutter will either be yet another UI framework and then the one with market adoption wins, or it will be rebooted somehow.
[deleted]
Is there any indication on how important/significant Dart will be to Fuchsia? I really like Dart, I think it's a fantastic interpreted language, but it has very little momentum because javascript es6 is good enough. If Fuchsia makes Dart its darling (with flutter?) perhaps the tides can turn?
I guess if Google want Fuchsia / Flutter to really take off, they will have to port Flutter to Javascript. One may or may not like Dart as a language, but if it didn't get any ground in some many years since it exists, why would it all of a sudden.
> I guess if Google want Fuchsia / Flutter to really take off, they will have to port Flutter to Javascript.
just like that time when iOS was suddenly hot, but there were no apps for it, because programmers hated Objective-C and weren't willing to learn it. So Apple released a new SDK and toolchain that allowed them to write apps in C++ instead.
oh wait.
Okay, all snark aside. Come on, guys. Isn't the fact that high tech is always new and innovative considered to be a good thing? So why is there always so much pressure to insist that every new thing has to be exactly like all the old things?
Learning Dart is not difficult. I did it myself, without even trying. I just pretended I already knew it, by following examples I found online. After a couple of weeks, my pretend-knowing turned into real-knowing.
just like that time when iOS was suddenly hot, but there were no apps for it, because programmers hated Objective-C and weren't willing to learn it. So Apple released a new SDK and toolchain that allowed them to write apps in C++ instead.
oh wait.
Okay, all snark aside. Come on, guys. Isn't the fact that high tech is always new and innovative considered to be a good thing? So why is there always so much pressure to insist that every new thing has to be exactly like all the old things?
Learning Dart is not difficult. I did it myself, without even trying. I just pretended I already knew it, by following examples I found online. After a couple of weeks, my pretend-knowing turned into real-knowing.
Thing is, Objective-C was the official language on iOS, and yes they did release C++ support, it is called Objective-C++ and exists since NeXTSTEP days.
Dart is just a programming language trying to get its killer app, which was dropped by Chrome team and gets political answers from Android team.
Dart is just a programming language trying to get its killer app, which was dropped by Chrome team and gets political answers from Android team.
> Thing is, Objective-C was the official language on iOS, and yes they did release C++ support, it is called Objective-C++ and exists since NeXTSTEP days.
I am well aware, I have used Objective-C++ myself, but it's irrelevant. No, you cannot write iOS apps completely in C++. you still have to use Objective-C or Swift when dealing with UI components.
Further, Objective-C is not "just" a programming language, in this case. All of Apple's native frameworks are very strongly influenced by it. They allow you to do things that wouldn't be possible in other languages.
Obviously, it's possible to translate that experience to something else (see Swift), but it's an entirely different experience. Worse, in my opinion.
The same is true of Flutter and Dart. A lot of Flutter's architectural decisions are tied closely to the strengths (and weaknesses) of Dart. It would not make sense to switch to a different implementation language at this point.
I am well aware, I have used Objective-C++ myself, but it's irrelevant. No, you cannot write iOS apps completely in C++. you still have to use Objective-C or Swift when dealing with UI components.
Further, Objective-C is not "just" a programming language, in this case. All of Apple's native frameworks are very strongly influenced by it. They allow you to do things that wouldn't be possible in other languages.
Obviously, it's possible to translate that experience to something else (see Swift), but it's an entirely different experience. Worse, in my opinion.
The same is true of Flutter and Dart. A lot of Flutter's architectural decisions are tied closely to the strengths (and weaknesses) of Dart. It would not make sense to switch to a different implementation language at this point.
Which is why Fuchsia is getting an UI agnostic composition engine, where Flutter is just another possibility.
While there are experiments in a Rust based UI and now Android.
I bet just like Brillo original plans, Flutter is on its way out.
While there are experiments in a Rust based UI and now Android.
I bet just like Brillo original plans, Flutter is on its way out.
By UI agnostic composition engine do you mean like Wayland? So every app is supposed to paint itself?
Every app is supposed to paint itself on any UI toolkit.
So what makes UI agnostic composition engine different from other composition engines?
Your answer means just a yes or "your question is irrelevant"? If the latter what I meant is a difference between Wayland and X. Wayland is a dumb pipe. X is mostly used as a dumb pipe, but it offers primitives to do the painting on the server side. Linux or Wayland does not have UI toolkit, but i.e. GNOME has.
Your answer means just a yes or "your question is irrelevant"? If the latter what I meant is a difference between Wayland and X. Wayland is a dumb pipe. X is mostly used as a dumb pipe, but it offers primitives to do the painting on the server side. Linux or Wayland does not have UI toolkit, but i.e. GNOME has.
Scenic (https://fuchsia.googlesource.com/garnet/+/master/docs/ui/sce...) is similar to the UI compositor in Android, macOS, Windows.
No different than using the UI toolkit of choice, while the window manager takes care of window decorations, OS input events and what have you.
Just push the window contents into the scene graph using Fuchsia IPC.
No different than using the UI toolkit of choice, while the window manager takes care of window decorations, OS input events and what have you.
Just push the window contents into the scene graph using Fuchsia IPC.
> No, you cannot write iOS apps completely in C++.
that's false. At least Qt supports deploying to iOS and you don't have to write a single line of objc
that's false. At least Qt supports deploying to iOS and you don't have to write a single line of objc
I would rather think some of Flutter's current rise in popularity is because it's not JavaScript.
Dart can be compiled ahead of time.
Most apps/websites show some text and a few pictures, why is this a benefit?
Because Dart is also used for compiled Flutter apps, which are meant to compete with native apps written in Java, Kotlin, Objective-C, and Swift. This gives us the obvious advantage of not turning people's phones into space heaters, which would be the case if Flutter apps used an interpreted language.
And there is no such thing as a slow Java app? Or a slow Objective-C app? Just because it's compiled, doesn't mean it's better. Some websites turn your phone into a space heater because the developer is shit, not because the tech is bad (HN doesn't make my phone blow up...). Dart will suffer the same problem - shit developers - so developing all this tech mumbo-jumbo is pointless.
AMP, in my opinion, was a step in the right direction. AMP is google's way of saying "you're all shit at developing on the web, use this very restricted way of developing a website and watch how fast it will go".
That's what we need. Don't put developers closer to the computer by giving them compiled languages. Move them as far away from the computer as you can. Languages should be moving in the direction of requiring the developer to do as little as possible. I need to import a package to make HTTP requests in Dart; every fucking app makes HTTP calls these days, how outdated is that? HTTP requests are baked in to javascript, I don't even need to think about what I need to import, I can spend mental cycles on real shit.
AMP, in my opinion, was a step in the right direction. AMP is google's way of saying "you're all shit at developing on the web, use this very restricted way of developing a website and watch how fast it will go".
That's what we need. Don't put developers closer to the computer by giving them compiled languages. Move them as far away from the computer as you can. Languages should be moving in the direction of requiring the developer to do as little as possible. I need to import a package to make HTTP requests in Dart; every fucking app makes HTTP calls these days, how outdated is that? HTTP requests are baked in to javascript, I don't even need to think about what I need to import, I can spend mental cycles on real shit.
Generally speaking in the context of normal, non-game apps I’ve found it rather difficult to write Swift or Objective-C in such an inefficient manner that it keeps the CPU spinning and heats up your device. It’s possible for sure but also requires crazy levels of laziness, incompetence, lack of understanding, or some combination thereof.
This is a weird objection. Import statements have nothing to do with whether a language is interpreted or compiled. It's just a matter of which names the language designers decide should be imported automatically.
Haha, fair criticism, but don't miss the forest for trees. My point was about simplicity - I don't need to worry about this when making a website, but there's this new language and now I have to worry about this? It just feels like a step backwards.
I'm sure you're right about how it feels, but "feeling like a step backwards" is normal for learning a new language since there's a learning curve. It seems hard to say if it's actually worse? You didn't start out knowing what all the built-in JavaScript functions were, right?
If you know you want to use Dart's HttpRequest class, you can just type it and a good editor will add the import for you. But people don't start out knowing what to type.
If you know you want to use Dart's HttpRequest class, you can just type it and a good editor will add the import for you. But people don't start out knowing what to type.
> I need to import a package to make HTTP requests in Dart
That's actually not true; the functionality is included in both dart:io and dart:html. package:http is just a cross-platform wrapper.
That's actually not true; the functionality is included in both dart:io and dart:html. package:http is just a cross-platform wrapper.
It's moreso the fact that the underlying pieces improve in quality, goals, and speed.
If more apps are just text and a few pictures, why are they running a full copy of the blink and v8 engines and not just using what's required for the job?
If more apps are just text and a few pictures, why are they running a full copy of the blink and v8 engines and not just using what's required for the job?
Because what's "required" for the job is way too complex for the perceived payoff. That's why the JS/HTML is winning - the time investment to "do something" matches the outcome.
Does anyone else have a suspicion that Google is about to completely screw this up?
If they do I really hope the Surface Phone comes out or something. I don't want to be forced to iOS, but I wouldn't be too mad if I had it.
You can already experience non-Andorid Android in the form of a Pixel Slate.
Including the pixelbook and many other ChromeOS devices
Windows Phone used to be a thing. Quite a good base UI but a shortage of apps, because it couldn't run Android apps.
I still have a Windows Phone at home that can sideload Android apps. Was pretty awesome. Android apps seemed slow in comparison to UWP apps, but ran more or less as well as they ran on Androids.
It wasn't the lack of apps that held me from buying one, it was that they never advertised one or had enough Windows Phones available on my carrier with good battery life. I'm sure they had amazing battery life but they didn't advertise it well enough if they did.
I still use my Lumia 650 as 2nd phone.
It runs the apps I care about, and keeps getting OS updates, unlike my Android devices.
It runs the apps I care about, and keeps getting OS updates, unlike my Android devices.
What a weird stage we’re in currently. The continued effort by the parent company to maintain basic updates and patch security holes in a delivered product is a differentiating feature. We’re literally considering whether a company is going to ghost it’s cumstomers as an optional thing.
has a vision of a world where mobile OSes look like their messaging app portfolio
Prepare for 5 different Google OSes all of which support a slightly different featureset
Prepare for 5 different Google OSes all of which support a slightly different featureset
ChromeOS, Android, Fuchsia. You aren't far off. Hell Apple and Microsoft have less Operating Systems and it's their businesses (but that may just prove the point)
I wonder if Fuchsia will really become a consumer brand though. If I understood it right, the original motivation was a desire to get rid of the Linux/GNU heritage in Android.
If that is the case I could imagine that Fuchsia might not become a separate "product" for consumers at all - instead, Google could replace Android's implementation "under the hood" with it but still present it as just another Android version brand/UI wise.
If they managed to do the same with Chrome OS, the'd actually have archieved consolidation on a technical level without causing consumer confusion. (Well, more than there already is)
If that is the case I could imagine that Fuchsia might not become a separate "product" for consumers at all - instead, Google could replace Android's implementation "under the hood" with it but still present it as just another Android version brand/UI wise.
If they managed to do the same with Chrome OS, the'd actually have archieved consolidation on a technical level without causing consumer confusion. (Well, more than there already is)
Google still needs to replace literally millions of LoC in the Linux kernel from hardware vendors like Qualcomm before they can actually ship a real functional phone.
If they limit their hardware choices (like Apple) it is actually not -that- difficult.
Wasn't there a rumor that Google wants to build there own CPU?
Maybe Fuchsia uses a lobotomized Linux kernel, together with such firmware blobs, as a (likely sandboxed) monolithic multi-driver?
How hard is it to rewrite drivers? Or is the problem that companies do not write others write these drivers?
Pretty hard, not only is it nearly impossible to get documentation for some of the hardware, even if you get it it'll usually be under some kind of NDA which means you can publish the driver. Then there's all kinds of errata and hardware quirks that aren't going to be in the documentation (maybe in future updates to the documentation) it ends up a full time job for multiple people to maintain just a single driver for a few products.
> it'll usually be under some kind of NDA which means you can publish the driver.
Did you mean cannot publish?
Did you mean cannot publish?
Yep, missed that when reviewing the comment and it's now too late to edit.
No worries. Seemed like that's what you meant, but just wanted to clarify.
The code for the Fuchsia kernel is available. It doesn't seem derived from Linux.
It would be surprising if Fuchsia followed linux by not having a stable ABI for drivers. Setting up a stable interface would make it easier for Google to label that "not my problem."
Android has a stable ABI for drivers since Treble, which kind of forced Linux into a pseudo-microkernel architecture, allowing for user space drivers written in either Java or C++, communicating over the HIDL messages/shared mem.
Weren't they working on a sort of unified "hardware abstraction layer" for Android anyways? - Which would put all the vendor-specific code "below" the kernel and would allow them to reuse the same OS image on different devices.
In that case, the Fuchsia kernel could just be another "client" to that layer.
(just speculating here, no idea if that is in any way what they're planning)
In that case, the Fuchsia kernel could just be another "client" to that layer.
(just speculating here, no idea if that is in any way what they're planning)
Why would they? Since 8.0, Android is fully separate from Linux kernel through its so-called Treble layer (see https://android-developers.googleblog.com/2017/05/here-comes... ) and doesn't really need Linux or POSIX sematics for its functionality.
Since Treble's adoption was rather low, given that it was optional when updating from Android 7, one of the decisions on Android 9 was to make it even more independent with the introduction of Generic System Image.
https://android-developers.googleblog.com/2018/11/an-update-...
https://android-developers.googleblog.com/2018/11/an-update-...
What do you mean by low adoption? Every device launching with 8 has to support it.
About 12% worldwide adoption, about when Android 9 got released.
OEMs got around Treble certification by releasing mostly devices with Android 7 on them.
And given that OEMs were the ones supposed to push Treble updates not Google, even those that released devices with 8 weren't that active pushing them.
Which has finally made Google include some update requirements on the Play Services access.
OEMs got around Treble certification by releasing mostly devices with Android 7 on them.
And given that OEMs were the ones supposed to push Treble updates not Google, even those that released devices with 8 weren't that active pushing them.
Which has finally made Google include some update requirements on the Play Services access.
> get rid of the Linux/GNU heritage in Android
What GNU heritage? Android has only ever used the Linux kernel to get a leg up on hardware support in the early days. AFAIK there has never been any GNU userspace of any sort in anything Android related, much to the chagrin of the Linux community.
What GNU heritage? Android has only ever used the Linux kernel to get a leg up on hardware support in the early days. AFAIK there has never been any GNU userspace of any sort in anything Android related, much to the chagrin of the Linux community.
Many never read beyond the headlines.
The NDK is constrained in what it can do, as per security concerns.
There is termux as port of GNU on Android, but only applications that rely on plain ISO C, ISO C++ can be ported.
Syscalls support is hit and miss per devices, as it isn't part of official NDKs APIs.
The NDK is constrained in what it can do, as per security concerns.
There is termux as port of GNU on Android, but only applications that rely on plain ISO C, ISO C++ can be ported.
Syscalls support is hit and miss per devices, as it isn't part of official NDKs APIs.
I gathered (from the outside — no inside knowledge) it was two big things:
* A response to Java lawsuits
* Something to work on that is interesting
But you raise a good point — why let go of Linux? Seems like a risky case of rewrite-from-scratch.
What are the odds it works out? It's not a sure thing. And what would the benefits be?
* A response to Java lawsuits
* Something to work on that is interesting
But you raise a good point — why let go of Linux? Seems like a risky case of rewrite-from-scratch.
What are the odds it works out? It's not a sure thing. And what would the benefits be?
MIT license and microkernel design.
You're kidding right? Microsoft comes out with a new OS practically every other year.
https://en.wikipedia.org/wiki/List_of_Microsoft_operating_sy...
https://en.wikipedia.org/wiki/List_of_Microsoft_operating_sy...
Currently everything is based on Windows Core or has been discontinued.
Xbox One has moved to Windows 10/Core, was previously based on top of Windows 8. Windows Mobile has been discontinued, and even had migrated to a Windows NT kernel before it was discontinued. ( https://www.zdnet.com/article/microsofts-windows-phone-8-fin... )
Not sure the status of Windows CE from an official support perspective (their life-cycle page isn't working for it) but their documentation lists as disconnected as of 2014.
I also don't believe any of their experimental OS projects are still active. ( https://www.microsoft.com/en-us/research/group/operating-sys... )
At the end of all that, you can argue that there are two operating systems at Microsoft currently. Xbox One and Windows 10. The UI of the XBox is a sufficiently large enough gap in design/functionality that I would concede it to be a separate entity.
Edit: There was a concerted effort at MS to get on to a single OS around the Windows 8/Mobile days. This was also the death of CE and switch to Windows 8 between XBox 360 and XBox one. Granted the backlash of the tablet style interface of Windows 8 was not insignificant, but you see it's refinement in Windows 10 today.
I also don't believe any of their experimental OS projects are still active. ( https://www.microsoft.com/en-us/research/group/operating-sys... )
At the end of all that, you can argue that there are two operating systems at Microsoft currently. Xbox One and Windows 10. The UI of the XBox is a sufficiently large enough gap in design/functionality that I would concede it to be a separate entity.
Edit: There was a concerted effort at MS to get on to a single OS around the Windows 8/Mobile days. This was also the death of CE and switch to Windows 8 between XBox 360 and XBox one. Granted the backlash of the tablet style interface of Windows 8 was not insignificant, but you see it's refinement in Windows 10 today.
I think of it as Microsoft’s OSes differentiate by features aka marketing weasels. They’re essentially the same OS otherwise. MS markets this as backwards compatibility at times as well. I think that’s a good feature that Google doesn't appear to be making a priority.
Having said all of that, I’m sick of googles abandoning of products. I loved my 2013 Pixel 7. They essentially sell goods and services only to ignore them when it suits them.
Having said all of that, I’m sick of googles abandoning of products. I loved my 2013 Pixel 7. They essentially sell goods and services only to ignore them when it suits them.
Well, if you include Windows 95/98/NT/ME/2000/... But I think it's a valid point. Windows 10's main contribution is an attempt to provide auto-updating operating system to reduce version skew. I have a lot of hope that windows 10 actually does have a long lifespan. Crossing my fingers Android can do the same one day.
My understanding is that the point of Fuchsia is to be a base for a new version of ChromeOS that also obviates Android. I'd compare it to the move Microsoft made with Windows XP to merge the NT and 9x lineages. Fuchsia is NT, "ChromeOS on Fuchsia" is XP, and Android is 9x.
> ChromeOS, Android, Fuchsia. You aren't far off.
Add Android TV, which has some features and restrictions that differ from Android.
Add Android TV, which has some features and restrictions that differ from Android.
And then we get to play Google roulette: Which OS will be discontinued this year.
Android as a standalone product gets replaced by Chrome OS on phones, but it sticks around as a runtime inside that. Fuchsia isn't ready for prime time, but we'll add those later!
Google's phone lineup for 2022:
Google's phone lineup for 2022:
- Chrome with Android
- Chrome with Android One
- Chrome Android Pixel
- Fuchsia with Android
- Fuchsia Silver with Android
- Fuchsia Android Nexus
- Fuchsia Android Pixel
My real question isn't so much what Google itself will be shipping on their hardware, but what all the other phone manufacturers that are currently using Android, are going to be shipping on their phones in ten years.
Android.
Maybe a Microsoft Open Source platform that support Windows, Linux and Android Apps and an doesn't need Google Play Services?
I thought it was the other way around — Chrome OS was absorbed into Android.
My first thought is "Requires a paid google account to work between devices!".
Yes, though Google likely views it as a chance to do-over their mistakes with Android such as allowing OEM and carrier control of things like updates and customizations, building on top of copyleft code (which requires a lot of code to be open sourced they and their OEMs would rather not) and code they stole from Oracle (which has caused them years of legal nonsense), etc.
> code they stole from Oracle (which has caused them years of legal nonsense)
Oracle wasn't accusing Google of using "stolen" code in Android. They were claiming that Google's complete re-implementation of Oracle's Java APIs was a copyright violation.
The case itself will have long lasting impacts since it has established in US law that API interfaces themselves are a copyright/protected concept. That means that even complete clean room re-implementations or compatibility layers could be threatened.
The ruling is quite problematic, but there's nobody technically literate enough in congress or the courts to do anything to stop it.
Oracle wasn't accusing Google of using "stolen" code in Android. They were claiming that Google's complete re-implementation of Oracle's Java APIs was a copyright violation.
The case itself will have long lasting impacts since it has established in US law that API interfaces themselves are a copyright/protected concept. That means that even complete clean room re-implementations or compatibility layers could be threatened.
The ruling is quite problematic, but there's nobody technically literate enough in congress or the courts to do anything to stop it.
It's pretty off-topic to pick a fight about this here, the point that I've made, that their fight with Oracle could've best been avoided, stands reasonable regardless of your opinion on the details of the case.
I think Google legitimately believed nothing was wrong with their implementation of Java and that implementing a language with so many developers was a smart move.
Gosling stated otherwise on his interviews, and Rubin emails also prove they were trying to do something fishy.
As it stands, Android has pulled a J++ and is a pain for any Java library writer, that now is forced to either write two versions or keep using a common subset.
As it stands, Android has pulled a J++ and is a pain for any Java library writer, that now is forced to either write two versions or keep using a common subset.
>it has established in US law that API interfaces themselves are a copyright/protected concept
Only in the Federal Circuit, which adjudicates cases involving patent law. Copyright cases are typically decided by the other courts of appeal, and there is precedent in those courts (like Lotus v Borland) against the copyrightability of interfaces.
Only in the Federal Circuit, which adjudicates cases involving patent law. Copyright cases are typically decided by the other courts of appeal, and there is precedent in those courts (like Lotus v Borland) against the copyrightability of interfaces.
In what way?
This already happend before with Brillo.
It was going to be Android native userspace plus a subset of the Android frameworks redone in C++.
Then suddenly, due to customer feedback as the main official reason, it got rebooted as Android Things, supporting even writing userspace drivers in Java.
Then ChromeOS got to add Android support.
I guess it is kind of clear which group is winning the internal political wars.
It was going to be Android native userspace plus a subset of the Android frameworks redone in C++.
Then suddenly, due to customer feedback as the main official reason, it got rebooted as Android Things, supporting even writing userspace drivers in Java.
Then ChromeOS got to add Android support.
I guess it is kind of clear which group is winning the internal political wars.
Android is a pretty huge brand they invested a lot into. Makes sense, I guess (even though Android for me mostly means buggy and slow).
[deleted]
I don't know about screw it up, but I am wondering what is the upside in adopting this new OS in lieu of Android for all phone makers not named Apple?
Theoretically you could replace the AI layer (Topaz? IDR) with your own assistant (e.g., Samsung could integrate Bixby into the OS)
I should note that I have only glanced at what implementation details are public and it is entirely possible that this is not feasible
I should note that I have only glanced at what implementation details are public and it is entirely possible that this is not feasible
Google will just make it a requirement in order to provide the Play Store and other Google apps on your device. Then most will be forced to follow along.
I could see it being the straw that finally breaks the camel's back for Samsung, though. They have their own assistant, web browser... they could just choose to go it alone.
I could see it being the straw that finally breaks the camel's back for Samsung, though. They have their own assistant, web browser... they could just choose to go it alone.
This sounds like a cost to phone manufacturers, not a benefit.
At this point manufacturers don't have a lot of choices. To a reasonable approximation, the options are Android with google's blessing, android without play store, beg microsoft for windows mobile 10?, KaiOS, Tizen?, don't make phones.
About the only one that will sell the final product in the US is Android with Google's blessing.
About the only one that will sell the final product in the US is Android with Google's blessing.
Correct, Google has all the leverage to dictate what non-Apple smartphone manufacturers sell. Moving to Fuchsia would be expensive for everybody involved. Google is developing a new OS. Chip manufacturers will have to write new driver code. Cell manufacturers will have to integrate a new system. Everyone loses the work they put into the Android Open Source Project and their private branches of ASOP.
With all this cost, who's getting the upside? Google is clearly getting the lion's share.
With all this cost, who's getting the upside? Google is clearly getting the lion's share.
fuchs-ya
Man. I came here to post the same thing.
Google has been screwing up EVERYTHING lately. Every recent Google product launch that I can think of has been botched. They're REALLY checked out over there.
Serious question. What's the last major successful Google project that was built within Google and not acquired?
I can't think of one.
Google has been screwing up EVERYTHING lately. Every recent Google product launch that I can think of has been botched. They're REALLY checked out over there.
Serious question. What's the last major successful Google project that was built within Google and not acquired?
I can't think of one.
Google Photos
Edit: Also Google Home devices, especially the Mini
Edit: Also Google Home devices, especially the Mini
Ironically, I think Photos was a product of Vic Gundotra, which Google higher-ups gave the boot because he failed in social (as if anyone else would have succeeded in beating Facebook - he gave it a good shot anyway). Google wasn't even savvy enough about social to know to buy Instagram.
Others might at least have failed in a way that was less damaging to Google's reputation.
How do you define "major"? How do you define "product"?
If my "major" you mean "more than 100MM users", it's been a while, but then what was the last (new) product launch by any established company that has 100MM users? If you drop that to a smaller number, there are tons though.
If by product you mean "consumer product", again, perhaps a while, but I'd argue that there are tons in the business space. (ML, cloud, etc.)
If my "major" you mean "more than 100MM users", it's been a while, but then what was the last (new) product launch by any established company that has 100MM users? If you drop that to a smaller number, there are tons though.
If by product you mean "consumer product", again, perhaps a while, but I'd argue that there are tons in the business space. (ML, cloud, etc.)
GMail — still the anti-social network that I both rely on and ignore every day.
No friend discovery, funded by ads, people mostly ignore emails I send them, but everyone has it and depend on it being rock solid. It's like air.
No friend discovery, funded by ads, people mostly ignore emails I send them, but everyone has it and depend on it being rock solid. It's like air.
Whats to screw up? They haven't really promised anything, or announced Fuchsia in a consumer facing way. Some tech people seem hyped about Fuchsia but I still get the feeling its mostly an experiment that Google will roll back into Android or ChromeOS.
Android is what could get screwed up. ChromeOS could too, but it isn’t as important. Relevant hint: https://9to5google.com/2018/10/11/the-dirty-word-android-dea...
I'm really baffled by this question. Screw what up? Fuchsia is not a product; some people at Google are working on a project and it's gotten a bit of attention. I'm just confused as to the level of entitlement that would presume there is something here to "screw up".
You're being willfully naive if you think that Google wouldn't take an internal project, productize it, and then proceed to screw up said product.
This is literally the past 15 years of Google.
This is literally the past 15 years of Google.
> This is literally the past 15 years of Google.
Other than for Gmail/Chrome[OS]/Android/Photos/Youtube/Music/Maps, I totally agree.
Other than for Gmail/Chrome[OS]/Android/Photos/Youtube/Music/Maps, I totally agree.
I'm not sure what your point is though. Yes, Google could take an internal project, turn it in to a product, and then "proceed to screw up said product"...over the course of, what, 5, 10 years? What is the point of speculating about something so far off with no data? They could also turn it in to a product and then not "screw it up".
What am I being naive about? Do all of the wildly successful Google products not count here?
What am I being naive about? Do all of the wildly successful Google products not count here?
It's interesting how the trend in newer OSes seems to be towards client apps running in some sort of VM. Windows runs Linux. Some Chromebooks run both Linux and Android.
I wonder if we'll get to the point where hardly anything is a native app and the concept doesn't matter much anymore? The host OS just exists to run guest OSes.
I wonder if we'll get to the point where hardly anything is a native app and the concept doesn't matter much anymore? The host OS just exists to run guest OSes.
> I wonder if we'll get to the point where hardly anything is a native app and the concept doesn't matter much anymore?
You mean a web browser? We're there.
You mean a web browser? We're there.
I've been waiting for this more than 20 years :) http://lowendmac.com/1997/red-box-blue-box-yellow-box/ Now we are finally there.
ChromeOS and Android are Linux. Android compatibility comes from a container.
https://chromium.googlesource.com/chromiumos/platform2/+/mas...
https://chromium.googlesource.com/chromiumos/platform2/+/mas...
Having Linux kernel is pretty transparent for app developers.
They don't care which kernel powers Chrome processes, or ART.
On Android's case, Linux syscalls aren't even part of the official stable APIs.
https://developer.android.com/ndk/guides/stable_apis
They don't care which kernel powers Chrome processes, or ART.
On Android's case, Linux syscalls aren't even part of the official stable APIs.
https://developer.android.com/ndk/guides/stable_apis
But it does mean a Chrome OS device can run Linux software without a full-on Virtual Machine, since the underlying kernel is the same.
It also means that they can be ported to other OSes with zero dependencies on Linux.
OTOH, neither is the ARM ISA. Yet, once you try to bring a non-ARM Android device to the masses, you will soon discover the rule of Hyrum's Law.
I have plenty of apps running on my non-ARM Android devices.
As for Hyrum's Law, since Android 7, any misbehaved app that tries to use non-sanctioned NDK APIs gets killed by the OS.
As for Hyrum's Law, since Android 7, any misbehaved app that tries to use non-sanctioned NDK APIs gets killed by the OS.
Actually they are catching up with the language environments on mainframes.
Why not? The history of computing is about isolating applications, really. Why do we have Virtual Memory? Because it allows each process to have an independent address space. Why do we have preemptive multitasking? Because it allows each process to behave as though it is the only task running. Why is hardware virtualization so great? Namespacing and containers?
I think Casey Muratori did a good job outlining the case for removing the OS from the equation entirely in "The thirty-Million Line Problem" [0]. He describes a hardware architecture where standardized ABI and hardware virtualization replaces the OS and drivers, allowing each process to behave as if it was the only software on the computer, as it was in the olden days with platforms like the C64. The closest thing to an OS would be a hypervisor, which should be the kind of thing an enterprising young programmer could write in their spare time in a month.
[0] https://www.youtube.com/watch?v=kZRE7HIO3vk
I think Casey Muratori did a good job outlining the case for removing the OS from the equation entirely in "The thirty-Million Line Problem" [0]. He describes a hardware architecture where standardized ABI and hardware virtualization replaces the OS and drivers, allowing each process to behave as if it was the only software on the computer, as it was in the olden days with platforms like the C64. The closest thing to an OS would be a hypervisor, which should be the kind of thing an enterprising young programmer could write in their spare time in a month.
[0] https://www.youtube.com/watch?v=kZRE7HIO3vk
But isn't it also a problem? We not only want to do things contained within a program, we also went them to cooperate. Don't we also want accessibility? I think that middle ground is needed, but currently pendulum is inclined in other direction.
Personally, I look forward to QubesOS-feel [0] to be more mainstream and user-friendly - access to USB drives in secure VM, interoperable applications between various OSes and easy way to create a disposable disk/VM...
[0] https://www.qubes-os.org/
[0] https://www.qubes-os.org/
"I wonder if we'll get to the point where hardly anything is a native app and the concept doesn't matter much anymore? The host OS just exists to run guest OSes."
This already happens in server infrastructure where the host OS just exists to run the guest OSes(VMs) and now, lately, the host OS just exists to run guest containers.
This already happens in server infrastructure where the host OS just exists to run the guest OSes(VMs) and now, lately, the host OS just exists to run guest containers.
Linux on Windows, i.e. WSL (Windows Subsystem for Linux) is not a VM - it's a separate system compatibility layer, somewhat akin to what MS SQL Server does to abstract away to OS to also be able to run on Linux now.
The parent may very well have been referring to Linux on Windows, in the form of a Linux VM. They didn't mention WSL at all.
I think we've seen a proliferation of one concept, often disguised as many things: the container for a program.
A long time ago, the program was your whole OS, you'd boot into it. The computer is the container.
Then we introduced operating systems, allowing a safer container for bad programs. The program is the container.
One type of program became extremely popular because it enabled delivery of a program via the internet. The web app is the container.
In the web world, frameworks like React have become incredibly popular because they allow people to break up apps into smaller components that can be shared. The component is the container.
Of course, on the back end, similar needs have led to Docker/K8s. The container is the container.
Given that everything in our world is a container, you'd think we would have better tools for composing them. As a web developer, I should be able to embed other web apps and communicate with them like I do with my React components. And I'd also like to be able to boot directly into a web app, and embed native programs and virtual operating systems.
Even when it comes to basics: most operating systems other than Chrome still have yet to natively support the web as a peer of traditional programs.. Electron should't be necessary. Likewise, environments like Docker and VirtualBox should be baked in to the OS that we boot.
The point is, as an industry we need to collectively pull our heads out of our asses, and realize that we'd be much better off refactoring our magnificent existing containers, rather than attempting to invent new ones. (I'm looking at you, iOS/Android..)
A long time ago, the program was your whole OS, you'd boot into it. The computer is the container.
Then we introduced operating systems, allowing a safer container for bad programs. The program is the container.
One type of program became extremely popular because it enabled delivery of a program via the internet. The web app is the container.
In the web world, frameworks like React have become incredibly popular because they allow people to break up apps into smaller components that can be shared. The component is the container.
Of course, on the back end, similar needs have led to Docker/K8s. The container is the container.
Given that everything in our world is a container, you'd think we would have better tools for composing them. As a web developer, I should be able to embed other web apps and communicate with them like I do with my React components. And I'd also like to be able to boot directly into a web app, and embed native programs and virtual operating systems.
Even when it comes to basics: most operating systems other than Chrome still have yet to natively support the web as a peer of traditional programs.. Electron should't be necessary. Likewise, environments like Docker and VirtualBox should be baked in to the OS that we boot.
The point is, as an industry we need to collectively pull our heads out of our asses, and realize that we'd be much better off refactoring our magnificent existing containers, rather than attempting to invent new ones. (I'm looking at you, iOS/Android..)
>The host OS just exists to run guest OSes.
so a hypervisor?
so a hypervisor?
To be clear chromebooks ARE linux.
It's a technical detail. It may be quite a big detail, but it's covered by a huge elephant.
Back in 1991 IBM bet their operating system strategy on a project called “Workplace OS” which was supposed to be exactly that, although it didn’t include a VM:
https://en.m.wikipedia.org/wiki/Workplace_OS
“Above the PNS, the operating system personalities run in the form of user-space servers that execute DOS, OS/2, and UNIX—with further intentions to support Microsoft Windows, OS/400, AIX, Taligent, and MacOS personalities.”
It’s been called one of the most expensive failures in operating system development.
https://en.m.wikipedia.org/wiki/Workplace_OS
“Above the PNS, the operating system personalities run in the form of user-space servers that execute DOS, OS/2, and UNIX—with further intentions to support Microsoft Windows, OS/400, AIX, Taligent, and MacOS personalities.”
It’s been called one of the most expensive failures in operating system development.
This is not super surprising. Google OSes may come and go, but they will put the Android Runtime on all of them.
Its Microsoft all over again
microsoft in the 90's would relentlessly execute. Word and excel spring to mind, but really hundreds of little software shops woke up to discover their product was now a windows or office feature.
Think instagram eating snap, but for lots and lots of products.
Think instagram eating snap, but for lots and lots of products.
I get the feeling what started as a measure to keep staff has now turned into the perfect way to replace the Linux kernel for a lot of Google components.
My wondering out loud: is the Android Runtime in Fuschia supposed to be Google's Blue Box or Red Box? Classic or Carbon?
They were so close to having a .fart file extension
As long as their apps work, users won't care.