> Fuchsia wants to be the best cross-device OS to date. To achieve this, Fuchsia uses a new tool known as ‘Ledger’ by the GitHub community. Ledger, once you’re signed into a Google Account on a Fuchsia device, will automatically save your place in all installed apps across all Fuchsia devices.
Please implement this with an open-standard API (WebDAV?) so that multi-device OS/app state can be synchronized to a self-hosted and hardened device.
> Behind the scenes, Ledger is currently powered by three cloud services. The first is of course the Firebase Realtime Database (acquired by Google in 2014), which specializes in keeping JSON data synchronized across multiple devices and smoothing over internet connection loss. This method also uses the tried and tested Google Cloud Storage, for basic file storage. There’s also work being done on a version based on Firebase Cloud Firestore.
Does Parse have a healthy OSS community as a Firebase substitute?
Well the code itself is open source, so that should simplify things quite a bit. As with Android though, maintaining a "de-googlified" build of Fuchsia is probably going to take significant community effort regardless.
That this centralized Ledger is something that will be deployed at scale (in true Google fashion, I expect avoiding it will require a fork, at once keeping the open source warm feelings around its brand alive and making it so only the obstinate will even try. But even default with opt-out would cover over 99% of users) confirms my new belief:
Every article about Facebook and privacy should have the word "privacy" replaced with "Mark Zuckerberg's unsettling, mildly robotic countenance and demeanor".
This article isn't very informative. For one thing "Andromeda" isn't Fuchsia, that was a proposed merger of Android & Chrome that was shelved in favor of Fuchsia. Kyle Bradshaw on 9to5Google has a pretty good series on Fuchsia that's much more insightful:
Andromeda was probably a bad misunderstanding/misrepresentation by the headline hungry press.
If we look at recent releases of Android, it has taken on the update scheme of ChromeOS by detaching the Android layer from the Linux kernel. Meaning that Google can push updates to the Android layer without having to deal with hardware suppliers and carriers dragging their feet.
While at the same time ChromeOS is getting the ability to run Android apps.
Thing is, if the ancient, unmaintained kernel that said Android layer is running atop is vulnerable, your pretty hosed. Securing higher up in the stack won't do you much good, nor will attempting to containerize proprietary drivers and hoping that that will ensure a secure experience.
Running modern kernels and upstreaming out of tree patches is the only reasonable way of supporting & securing these phones and tablets long term in a cost effective, until Google puts their foot down and says "No more custom BSPs", the horrible mess that is Android's security nightmare won't cease.
I don't see where they're getting this "next year" figure from. Fuchsia has been under development since 2016, there's no reason it couldn't go another year or two without seeing a consumer release.
Yes, if you just want to throw out guesses based on limited information then 2019 does seem at least plausible, but that's by no means certain.
While Google hasn't officially said what the purpose of Fuchsia is, I think they have said that Flutter is the tool for writing apps for Fuchsia. Currently, Flutter emits apps for iOS and Android while the work-in-progress builds of Fuchsia run on the Chromebook Pixel rather than phones. This leads me to believe the suggestion that Fuchsia will replace both Android and ChromeOS.
The Linux kernel was made for desktops/workstations/servers, no? I think this kernel was designed with the use case of mobile/tablet/PixelBook in mind.
The massive fragmentation and security problems caused by each device vendor creating a board support package based on an ancient version of whatever kernel they plan to run on the hardware they sell won't be resolved or seriously helped by Fuchsia.
Google isn't willing to address the root issues of upstreaming their device specific code and pushing updates often like Nokia has with their Android line and Microsoft did with the exact same vendors with Windows Phone. Until Google forces their licensees to upstream the BSP patches they create, nothing will change.
They could address it going forward by mandating a specific kernel version which will then receive long term support. Say something like 6 years. And then periodically update the required kernel version to another release which will receive the same 6 years of support.
In addition they could decouple the rest of the Android stack so it can upgraded and run on either of the currently supported kernel versions.
Umm..maybe I'm missing something but I don't recall reading about a lot of security breaches with Android, outside of some dumb users downloading very shady apps here and there.
Now, you wanna talk jokes, let's talk about the history of Microsoft's products, such as Windows. It is hard to keep a Windows machine going for over a year, no matter how careful you are.
I think, all things considered, that Google bakes excellent security into everything it does.
Kind of, given the way that they left the Treble updates to OEMs and only required compliance to Oreo devices, they arrived at IO 2018 with a mere 10% adoption of Oreo, mostly on Pixel devices.
Which was quite good the adoption being so bad, because they finally announced at IO that they will be requiring updates for certification after P's release.
It sure seems you've missed a lot regarding Chrome OS. OS running Android and Linux apps now.
Sure, Photoshop and Lightroom are both mobile versions, but I have a feeling that maybe WebAssembly will tempt Adobe and others to at least try to build their all's for the generation growing up with Chromebooks on school.
My Chromebook updates automatically about every 2 weeks or so, but last time I tried to install an Android app it still didn't work. And, yes, I do read tech news daily, get about 10 emails a day from sites like Techcrunch and so on, and am aware of these announcements. But it is only a very very small number of machines that these work on...not on Chrome OS itself....going against the original premise of Chrome OS which had me pretty excited about (was it) 7 or so years ago. Maybe I shouldn't have bought one so early??
34 comments
[ 3.4 ms ] story [ 87.4 ms ] threadPlease implement this with an open-standard API (WebDAV?) so that multi-device OS/app state can be synchronized to a self-hosted and hardened device.
I think that's it.
https://9to5google.com/2018/02/02/fuchsia-friday-the-ledger/
For some background.
It would be nice if people get interested in this and start coding before it's a done deal.
Does Parse have a healthy OSS community as a Firebase substitute?
https://blog.back4app.com/2016/06/15/firebase-parse/
That this centralized Ledger is something that will be deployed at scale (in true Google fashion, I expect avoiding it will require a fork, at once keeping the open source warm feelings around its brand alive and making it so only the obstinate will even try. But even default with opt-out would cover over 99% of users) confirms my new belief:
Every article about Facebook and privacy should have the word "privacy" replaced with "Mark Zuckerberg's unsettling, mildly robotic countenance and demeanor".
https://9to5google.com/guides/fuchsia-friday/
If we look at recent releases of Android, it has taken on the update scheme of ChromeOS by detaching the Android layer from the Linux kernel. Meaning that Google can push updates to the Android layer without having to deal with hardware suppliers and carriers dragging their feet.
While at the same time ChromeOS is getting the ability to run Android apps.
Running modern kernels and upstreaming out of tree patches is the only reasonable way of supporting & securing these phones and tablets long term in a cost effective, until Google puts their foot down and says "No more custom BSPs", the horrible mess that is Android's security nightmare won't cease.
https://www.usenix.org/system/files/conference/nsdi18/nsdi18...
Yes, if you just want to throw out guesses based on limited information then 2019 does seem at least plausible, but that's by no means certain.
Linux is already there, what insight would it bring to do the same thing again?
While Fuchsia is MIT/BSD/Apache licensed, is written in a mix of C++, Rust, Go and Dart, while using the best practices from micro-kernels.
Google isn't willing to address the root issues of upstreaming their device specific code and pushing updates often like Nokia has with their Android line and Microsoft did with the exact same vendors with Windows Phone. Until Google forces their licensees to upstream the BSP patches they create, nothing will change.
In addition they could decouple the rest of the Android stack so it can upgraded and run on either of the currently supported kernel versions.
Oh wait, already done.
Now, you wanna talk jokes, let's talk about the history of Microsoft's products, such as Windows. It is hard to keep a Windows machine going for over a year, no matter how careful you are.
I think, all things considered, that Google bakes excellent security into everything it does.
Which was quite good the adoption being so bad, because they finally announced at IO that they will be requiring updates for certification after P's release.
They announced at Google IO that they will finally start requiring updates as part of the store access certification.
How this will work out, remains to be seen.
Just kidding; we don't know the release date.
Until you can run real apps, how can it compete with PC clones and Macs?
I do appreciate my Chromebook a lot, but there isn't even a decent video player for it...I mean, it isn't a real OS despite all the hype.
Sure, Photoshop and Lightroom are both mobile versions, but I have a feeling that maybe WebAssembly will tempt Adobe and others to at least try to build their all's for the generation growing up with Chromebooks on school.