Right now, if you want to order concert tickets or pay your parking meter, you need specific dedicated apps. The result of this is rows and rows of single-purpose apps "silos" on you phone, having to create an account and entering your credit card for each of them. I think some folks at Google got bored of that and wondered "what's next?".
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.
> 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.
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?
Absolutely. Progressive web apps are great for this, but like I mentioned, chatbots and AI assistants are emerging. That doesn't mean the web is dead, but if more and more people are using chatbots and assistants like Alexa to do stuff, that could be problematic for Google as less people will see ads and download apps.
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.
You explained it better than I did. "Skills" is really the key word, here.
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.
At first I had a lot of trouble making sense of the UI, but now I think it's pretty neat. It's essentially the final form of the Material Design idea, where each app is a Card like a physical deck of playing cards, and you get to arrange them by dragging them around, with the important and intentional limitation that they snap into one of a finite number of arrangements. How do you undo a splitscreen or tabbed layout, though?
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.
Honestly (and with no attack), material design seems like a nonsense to me. I tried to use demo sites and gmail, but I simply can't get it. It has no response in my mind, it doesn't catch my eye. The only thing it does brightly is disturbing my perception via after-click wave effect, idk how to call it properly.
I wish to know if there are many people like me, and what's special in MD for those who actually love it.
I know some of the folks working on this and a companion piece of hardware[+]. These people say it's all about embedded and real time. Linux hasn't been designed for that (and if you haven't used Linux for something deeply embedded: it's a real issue, and not a slur on Linux. Motorbike, car, truck, bicycle all fit different points in the transportation matrix).
[+] 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.
Interesting. I would like to know the comparisons between Fuchsia, and QNX which is also a real-time microkernel operating system that runs on cars and phones. It seems Fuchsia competes with QNX directly in that space.
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?
There's a bunch of them, but you'd never want to run hard realtime on a phone or tablet. Hard realtime gives you horrible performance, but excellent latency guarantees. One big thing they do in hard realtime systems is to disable the CPU cache, because caching prevents determinism. It's also essential for performance, but in a hard realtime system performance isn't important.
VxWorks, eCos, ITRON, RTEMS, RTX... There are a plethora of players emphasizing specific features. Outside realtime, various BSDs and then some RT Linux and even still wince.
Free software plays a huge role in this field of course, dating back to the Cygnus days.
1. Modularity makes it easier to update portions of the OS even when device manufacturers are uncooperative (e.g. broadcom / qualcomm failing to provide driver source code)
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.
Dual-licensing in that sense is far more common with GPL'd apps/libraries where the copyright holder offers a separate commercial license for the same code.
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).
Unless I'm mistaken dual licensing GPL'd code also requires holding the initial copyright. It also adds complications around outside contributions. With BSD they can accept contributions under that license and still license it themselves.
See all the standard microkernel arguments, which seem particularly apropos given the overall Android ecosystem. You ideally want the vendor provided device drivers sandboxed since they're often not that good.
Linux system internal are ugly, there is little progress on static driver verification, resource management heuristics are poorly tuned, and the kernel network stack is so bad, you can make a living selling your own user space version. Linux has a lot of very real problems.
Since that article was published, things have changed a little bit. At least for the filtering use case they talked about in the blog, XDP (https://www.iovisor.org/technology/xdp) has come about, which is an in-kernel mechanism by which to filter at wire speed.
I don't disagree that there are many examples, but it's hard to solve them unless people give specifics.
Not really a problem for mobile... For HPC there have been user mode and offload tweaks since forever. The fact that none of the hardware or task specific techniques can replace the traditional BSD sockets stack is because writing that in general is a ton of work... Work which G would have to do ^10 to replace Linux in an android context.
AFAIK, there's at least 3 kernels running on an Android device.
- LK (1) for the bootloader (the screen you see when launching fastboot, I believe)
- LK (2) for 'Trusty', the crypto engine
- Linux as the bootloader's payload.
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.
Most Android devices also run some OS on the baseband processor (on-die or separate), and often the Wifi, Codecs, Bluetooth, Power Management blocks, etc also run their own little OSes. It's getting a little crazy, how many distinct cores exist on these devices.
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).
The majority of those patents are low quality and prior art laden. They were used to shake down Android OEM's that didn't want to go to court. Barnes & Noble called them on their extortion games and both companies immediately settled with Barnes & Noble also setting up a joint venture. Microsoft knows their junk and doesn't want to actually prove they aren't. Any court case involving an Android OEM will automatically get legal aid from Google in invalidating any patents presented.
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.
>In sum, M-Cam's analysis suggests that Microsoft's claim to ownership of the Android OS may not be as strong as it has hitherto insisted it is and it asks:
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?
Linux was developed with personal computers and servers in mind. Not mobile phones. The world really needs a bottom up mobile first operating system IMO. iOS is the closest to this right now, but at the end of the day it's still just Darwin.
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".
I played with Flutter before, and it is such a nice way to build mobile apps. Its based on react, its like react native but it has its own rendering engine.
And i can also image apps to be loaded directly from the web (ala like a browser).
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.