Google’s “Fuchsia” smartphone OS dumps Linux, has a wild new UI
arstechnica.com
arstechnica.com
Ultimately, what we want is not the app itself (the silo), but what the app enables (what's inside). I don't want to download a parking meter app, I just want to pay for parking. I don't want to download LiveNation's app. I just want to order concert tickets. The system should be able to generate an interface that allows me to do x,y,z depending on context, without having to manage credit cards, adresse and accounts.
Chatbots are here, personal assistant, too. You can use your messaging app to order stuff, find answers or send money to your friends. The writing is on the wall: single-purpose apps are not the future and chatbots and AI assistant potentially means less Google search and ad click.
So Google figured that re-purposing Android to fit this new paradigm would be an impossible task so they just said fuck it! Let's start from scratch with a solid base. Let's design a platform that will be everywhere, runs on everything, update silently like Chrome, and is made with AI in mind.
All of these use cases should be easily solved by a decent web UI running in a browser without the need for a native app?
I'm talking about Google's perspective here. I'm not saying this is where the entire industry should go.
It was interesting to see another company using 'Skills' to describe their AI addons. I see the same thing applying to mobile apps, essentially services that also describe a minimal UI but leave the communication, notification, and other components up to the underlying environment. Essentially a user agent that decides what I want to see, and then sorts through the proposals from the various skills and let's through only what it knows I will be interested in.
Advertising is a concern, but it will take the same level of breakthrough that text-based ads did. It will be completely obvious only once it has been accomplished.
The use cases mentioned above are both time and location sensitive making this "sorting" process easier for the agent.
Parking meters make sense when you are parked in front of them, and can justify taking up a large portion of your screen, turning the display on if it's out of your pocket, propose an actual transaction, etc.
Ticket sales might be notifying you when a desired event is coming up, such as a play or music act, and then offering to monitor the ticket prices or offer you the opportunity to buy through a loyalty program from one of your credit cards or phone carriers.
The important thing is that skills can expose spoken, UI-based, chat-based, location and driving state dependent interfaces.
Thinking of simply an application which runs on a screen, runs a service in the background or requires a complicated notification system which it primarily uses to capture as much of your attention as possible is quickly becoming outdated.
Games will still be apps, but not much else.
For example, a man could tell the AI assistant that he wants to send flowers to his wife at her office for her birthday. The florists in the area could simply connect their stores to Google's AI, so Fuchsia could then generate an interface with relevant selection of flowers.
The man then taps what he wants, confirm, and the system handles payment and shipping info. Done. The interface closes automatically and he can go on with his day.
No app to download, no credit card to enter, no new account to create.
The rest is just mockups at this point, I hope; for example, the control center is pretty rough: presumably the user knows their own location, and when they're looking at this screen, they probably don't care; the full date is hidden whereas most people forget today's date much more often than they forget their own location; there is no obvious way to do auto-brightness, the negative space is in all the wrong places; etc.
I wish to know if there are many people like me, and what's special in MD for those who actually love it.
[+] which hardware may never see the light of day, who knows? Certainly not me, a non-googler. And the people I know are engineers; perhaps upper management has other intentions. But that's what my friends are working on.
Another question is if the operating system is designed to be real-time, the applications also need to be real-time. If the applications are not real-time, you lose the real-timeness. Dart is garbage-collected. I suppose it is not real-time, yes?
Free software plays a huge role in this field of course, dating back to the Cygnus days.
2. Commercial license
3. They get to control commits (rather than waiting for linux devs)
Not sure if this is what you were referring to, but the article notes
"With Fuchsia, Google would not only be dumping the Linux kernel, but also the GPL: the OS is licensed under a mix of BSD 3 clause, MIT, and Apache 2.0. "
Google will have a "technically open source" version but OEM's will be required to buy the separately licensed google version to include things like the play store and gmail.
I don't think that's legal, but it's a pretty interesting idea. Instead of just mandating a license, the vendor and customer can each advocate a license, and then have a duel to determine which license to use. Of course, each side would have to find someone willing to risk death in a duel (and one of them would have to die, for it to be a real duel), just for the sake of their employer. Do you think it'd be better to have a duel with swords or pistols? I guess they could water it down and remove the death requirement, perhaps by having the combatants do fencing or wrestling or something like that.
The Fuchsia source is primarily BSD licensed (with some MIT bits like the Magenta kernel, and some third party code generally of the MIT/BSD/Apache2/Zlib varieties).
Drivers reside in userspace
Stable driver ABI
Reduced attack surface area
Control of their own kernel development
Also, what issues do you have with the scheduler?
For an example among many. Basically network data should magically appear in bulk, whereas in Linux it's almost one packet at a time.
As you move to 10G, thus start to eat a lot of cpu.
I don't disagree that there are many examples, but it's hard to solve them unless people give specifics.
Scheduling for Android devices
If Magenta is also an instance of LK then they can maintain each through a common source tree and the bootloader can initialize the device resources once without needing separate drivers for each distinct kernel.
Magenta was based on LK but it is definitely its own thing and is evolving in its own directions (64bit, SMP, userspace, etc). LK is generally MCU-targeted and can be very tiny (15-20K for a minimal system used for bootloader cores or tiny embedded things).
http://www.zdnet.com/article/310-microsoft-patents-used-in-a...
According to an analysis by NCAM
21% of Microsoft’s alleged Android portfolio scored as
commercial versus 79% as non-commercial. This means
that only one fifth of the portfolio was directly
commercially relevant, casting doubt the overall
viability of the Microsoft licensing packages on offer.
There are a surprising amount of abandoned and expired
patents already in this space. Much of the Android
platform may, in fact, be a 'Freedom to Operate' space
and already part of the public domain. There may well
be alternatives to the Microsoft licensing packages
that could be assembled from the rich vein of patents
that occupy the 'Freedom to Operate' space.
The question remains as to whether Microsoft actually owns proprietary rights
to the Android OS or is the company unfairly taxing device makers by exploiting
an uninformed belief in its supposed innovation?
http://www.m-cam.com/sites/www.m-cam.com/files/Patently%20Ob...
https://seekingalpha.com/article/3545506-microsoft-sacrifici...
If you have the resources to do it, I guess - why not do it? Especially for something like a phone/tablet OS.
Smaller surface area for various purposes from security to performance. Stable ABI for driver (I'm guessing) giving Google the ability to upgrade the core OS.
I unfortunately kept pronouncing it "fucks-yeah" in my mind and was wondering why on earth would google name it as such, until I discovered that it's actually "fyushya".
Since flutter is a cross platform UI framework.
And i can also image apps to be loaded directly from the web (ala like a browser).