3 ms·

"are involved with Kubernetes, etc. None of that stuff probably is even close to working on Fuchsia and I don't think server side is a priority with that." act

by stdcli 8y ago

"are involved with Kubernetes, etc. None of that stuff probably is even close to working on Fuchsia and I don't think server side is a priority with that." actually the networking stack in Fuschia, or more particularly zircon the kernel it is optimized around, is written in Go. Kubernetes is written in go, which is essentially a system for implicitly defining scaled linux boxes on a giant network, and now in the most recent release is allowing for declarative architectures as well, much like how user space services for graphics drivers in Zircon will enable more declarative and optimized use of expensive resources as well (in this case, modular hardware architecture for mobile operating systems, which is what Fuschia was originally envisioned for.) I'm also pretty sure Google also has experience with mobile operating systems (android), and Fuschia is literally a response of now over a decade of trying to interface android on POSIX in conjunction with multiple chains of monopolized and closed source hardware architectures, being intimately familiar with the evolution of trends in the mobile hardware architectural space, and trying to rewrite a kernel to optimize for that. "Fuschia will need to play nice...Part of that is supporting linux based stuff; which especially on Chrome..." Chrome had to have an entire team dedicated to resandboxing their tabs to mitigate for spectre and meltdown, which are both results from the unquestioned but growing obscurity due to unquestioned implementations between hardware and Linux integration, which is something that Fuschia attempts to take a step back from, and by doing so simultaneously make it easier for open source development on hardware architectures while optimizing for them. Still, total site isolation is still an advanced option in chrome that results in a 10% degradation in memory performance so people don't turn it on, if they even know to check for it/what that means (most people don't).

jillesvangurp 8y ago
Crucially kubernetes uses docker, which uses a lot of low level linux and posix stuff. Kind of an issue if that stuff isn't there. Kernel virtualization on fuchsia could of course become a thing (like it is on Windows and OSX) but so far I've not seen much on that topic. WASM on chromium might become a way out as well of course. But the bottom line is: Empty room. beautiful OS with an empty app store is kind of a non starter in the current market. Windows Phone found that out the hard way. Also, several other mobile operating systems that did not quite make it or continue to struggle. Sailfish, WebOS, Firefox Mobile, Ubuntu Mobile, etc. Even ChromeOS struggled until they added android support and Crostini.
- pjmlp 8y ago
  ART will run on top of Fuchsia, it is already being ported, you can check the merge commits. As we always need to remember Linux fans, the fact that Android uses a Linux kernel is irrelevant to userspace.
  - jillesvangurp 8y ago
    I have no idea what ART is but I doubt it addresses all concerns I listed above. On Android, there are plenty of native libraries and apps these days as well. I'm pretty sure these don't work as is without a compatibility layer that essentially replicates a lot of linux/posix stuff, which Fuchsia does not implement. In any case, it wouldn't be the first time that Google walks away after putting lots of development in something. In general, I think they are closer to merging Android and Chrome OS than they are to replacing either with Fuchsia (not to mention convincing OEMs like Samsung to actually use it).
    - pjmlp 8y ago
      ART is the Android RunTime, basically the large majority of Android's userspace. Those native libraries are forbidden to use Linux specific features, only these APIs are sancioned. https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Since Android 7, Google has been claping down NDK users that try to used anything that isn't part of that list. Since Android 8, APKs are only allowed to reach for their own internal filesystem and use SAF for anything else. Something that will be further enforced on Android Q, so no luck trying to peek into /dev, /share and similar.
- return_0e 8y ago
  As for virtualization, Fuchsia already has its own KVM equivalent called Machina which so far can run Debian on top of Zircon and with several compatibility changes for supporting the ART runtime in Zircon already merged in, it should be also possible to run Android apps with this. But perhaps the reason Fuchsia won't struggle unlike the other OSes you mention, is that it is possible that it will be compatible to run all the Android apps in the play store from day one, thanks to Machina; allowing a smoother transition, a process similar to what Apple did with the PowerPC to X86 switch but in Google's case, its for a completely different OS.

by stdcli 8y ago

jillesvangurp 8y ago

Crucially kubernetes uses docker, which uses a lot of low level linux and posix stuff. Kind of an issue if that stuff isn't there. Kernel virtualization on fuchsia could of course become a thing (like it is on Windows and OSX) but so far I've not seen much on that topic. WASM on chromium might become a way out as well of course. But the bottom line is: Empty room. beautiful OS with an empty app store is kind of a non starter in the current market. Windows Phone found that out the hard way. Also, several other mobile operating systems that did not quite make it or continue to struggle. Sailfish, WebOS, Firefox Mobile, Ubuntu Mobile, etc. Even ChromeOS struggled until they added android support and Crostini.

pjmlp 8y ago
ART will run on top of Fuchsia, it is already being ported, you can check the merge commits. As we always need to remember Linux fans, the fact that Android uses a Linux kernel is irrelevant to userspace.
- jillesvangurp 8y ago
  I have no idea what ART is but I doubt it addresses all concerns I listed above. On Android, there are plenty of native libraries and apps these days as well. I'm pretty sure these don't work as is without a compatibility layer that essentially replicates a lot of linux/posix stuff, which Fuchsia does not implement. In any case, it wouldn't be the first time that Google walks away after putting lots of development in something. In general, I think they are closer to merging Android and Chrome OS than they are to replacing either with Fuchsia (not to mention convincing OEMs like Samsung to actually use it).
  - pjmlp 8y ago
    ART is the Android RunTime, basically the large majority of Android's userspace. Those native libraries are forbidden to use Linux specific features, only these APIs are sancioned. https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Since Android 7, Google has been claping down NDK users that try to used anything that isn't part of that list. Since Android 8, APKs are only allowed to reach for their own internal filesystem and use SAF for anything else. Something that will be further enforced on Android Q, so no luck trying to peek into /dev, /share and similar.
return_0e 8y ago
As for virtualization, Fuchsia already has its own KVM equivalent called Machina which so far can run Debian on top of Zircon and with several compatibility changes for supporting the ART runtime in Zircon already merged in, it should be also possible to run Android apps with this. But perhaps the reason Fuchsia won't struggle unlike the other OSes you mention, is that it is possible that it will be compatible to run all the Android apps in the play store from day one, thanks to Machina; allowing a smoother transition, a process similar to what Apple did with the PowerPC to X86 switch but in Google's case, its for a completely different OS.