12 ms·
I've heard the following opinion on the internet: "The sole reason Fucsia OS exist is so google can release GPL-free android sometime in the future" How do you
by altmind 8y ago
I've heard the following opinion on the internet: "The sole reason Fucsia OS exist is so google can release GPL-free android sometime in the future"
How do you feel, is there anything behind this claim?
- nwah1 8y agoThere's other reasons why fuchsia is arguably better, such as using a micro-kernel and being "capability-based." The license is liberal enough to allow relicensing it as GPL, if anyone cared to fork it.
- altmind 8y agoyes, I'll try to sum up the article as i understand: * better process isolation * stable hw/driver api (this is a huge mistake in linux, agreed) * less historical craziness(who likes fork()?) * more micro-kernel some of the things I personally cannot buy: * vulkan native. android is not vulkan-native, it provides both opengl es and vulkan, for your choice * flutter. why bundling and bringing opinions to the system becomes a benefit? it was a major problem with android that you have to interact with java if you want any native ui => I would prefer more ways/languages/bindings to interop with the UI * fidl ipc. cool, again, why bundling something with the os? * vDSO. why is even vdso on the slides - vdso is important, but it already with us for a decade. This article is great because its one of the first that breaks down Fuchsia on a tech level. But at the same time, its not an article that explains all the reasons the fuchsia is better that what google have now.
- microcolonel 8y ago> stable hw/driver api (this is a huge mistake in linux, agreed) Not to get into a flamewar over this, but there are real benefits to Linux's rolling driver ABI (the "API", however, is mostly stable, contrary to what you say). It encourages mainline collaboration, and greatly improves the quality and compactness of the drivers. On Windows (and to some extent macOS), you'll find whole classes of driver where each driver has its own proprietary internal implementation of something that should have been in the API and ABI, but is not (or just was not when the driver was written). Linux has great, up to date drivers for the vast majority of devices you'd want to use†, and all of the best ones are built (compactly!) right in to the kernel, so it is more or less moot at this point whether a stable ABI is a good thing (at worst, it didn't matter in the long run; at best, it made the system better). The level of integration and standardization in the Linux kernel is spectacular, and absolutely would not have been achieved if vendors were empowered to link ABI-compatible binary blobs into end user kernels. There is tremendous value in the fact that I can manage, consistently, every LED, every DVFS controller, every fan controller, every GPIO pin, etc. on each supported system in a consistent fashion. Left to their own devices, each vendor would use their pet interface (as seen with NVIDIA putting their foot down and demanding EGL surfaces be used with their driver on Wayland, despite the fact that no standard software supports it); NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no. † Outside of the Android ecosystem, which, through what could maybe be called poor stewardship on the part of Google, inexplicably refuses to develop against the mainline kernel, so is constantly fighting to maintain literally thousands of vendor-, OEM-, model-, SKU-, country-, and carrier-specific kernel trees for absolutely no recognizable benefit, and against the clearest and most consistent advice of the highest experts on the subject.
- snvzz 8y ago>NVIDIA insists that this is the way it's meant to be played, and I'm glad that the answer is a resounding no. I have some bad news for you. They got their way.
- ebg13 8y ago> It encourages mainline collaboration I feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates because of vendor neglect. > and greatly improves the quality Compared to what? > and compactness of the drivers Which no user has ever cared about. > up to date drivers for the vast majority of devices you'd want to use† I notice that you excepted billions of devices in order to make this claim. > inexplicably refuses to develop against the mainline kernel It's not inexplicable. It's easier and cheaper.
- jhasse 8y ago> Which no user has ever cared about. The user cares because it results in fewer bugs.
- yc12340 8y ago> feel like this is demonstrably a false promise by looking at the billions of mobile devices never getting any updates Third-party firmware like CyanogenMod exists only because in-kernel GPL parts can be ported to new OS versions. With Fuchisa there won't be anything like CyanogenMod anymore.
- nwah1 8y agoI don't understand why they didn't want to base it on the formally-verified, capability-based micro-kernel called seL4. Formal verification is the difficult but necessary next step for security-intensive applications. Also, any new kernel should only be written in a memory-safe language. Rust would be the best, since it is also safe from data races, outside of unsafe blocks.
- im_down_w_otp 8y agoWell... it's non-trivial to use seL4 correctly. It has all of the facilities to build something great and very little rails to ensure that you actually do. CAmkES, the component framework to help you do that, is... challenging in all the wrong ways. The proof evidence is very hard to extend meaningfully for new platforms, and you're limited to environments which have a sufficient MMU. We're starting with seL4 and building a whole Rust-based userland around it, and creating a whole pile of compile-time assurances along the way to make sure we're not inadvertently doing something dangerous or stupid with the rope seL4 gives you. It's worth it for us. However, it is a colossal pain in the ass. That said, in the coming months we're likely to open source some of our progress in making it easier and more reliable to work with, integrate with, and otherwise leverage seL4 for certain use cases.
- Scramblejams 8y agoDeets would be appreciated. Sounds interesting.
- thenewwazoo 8y agoI'm super interested in the work you're doing. I spent a couple of weekends building bindings and trampolines to get Rust binaries linked into Chibi/OS and FreeRTOS and it worked really well. I've always wanted to work with seL4, so I downloaded the source and started working through the tutorials and... oh dear. There ended my experiments trying to add Rust into the mix. So if there's any way I can subscribe or otherwise keep abreast of the work you're doing, I'd love to do that. As an aside, I wonder just how much async/await in Rust will obviate the need for small kernels in deeply embedded applications. If I can do blocking IO with my peripherals and use the async state machines to do "task" switching, well... who needs tasks and capabilities? It'd land somewhere on the "language OS" side of an embedded OS almost.
- atombender 8y agoFIDL is used extensively through the OS, and looks like it will be the primary means of communication between processes, not too different from macOS's XPC (which is used for a lot of services as well as very low-level stuff like talking to the T2 processor, apparently). Fuchsia being a microkernel, it makes sense to make this part of the OS. The alternative of inventing ad-hoc RPC mechanisms for each area of the system would be worse.
- suby 8y agoRegarding Fuschia only having an option for vulkan and not opengl, it doesn't seem like that would necessarily stop opengl software from working on fuchsia, right? There are opengl implementations on top of Vulkan like MoltenVK. I don't have a great understanding of this stuff, but assuming that this is true, I imagine that it has upsides like eliminating potential driver bugs which have plagued opengl in the past.
- earenndil 8y agoMoltenVK implements vulkan itself, on top of metal, and its counterpart, moltengl is closed-source. There do exist projects to implement opengl on top of vulkan, but I don't think any of them are mature yet.
- josephg 8y ago> * vulkan native. android is not vulkan-native, it provides both opengl es and vulkan, for your choice IMO vulkan-native is the right choice because opengl (or opengles, or anything else) can always be reimplemented on top of vulkan anyway. Layering opengl on top of vulkan means you're no longer at the mercy of hardware vendors to provide a bug-free opengl implementation. And if you're calling a userland opengl library running on top of vulkan, you can actually debug into graphics system and much more easily tune performance. (Debugging through into opengl calls is almost impossible when the opengl implementation is hardware-specific and part of the graphics driver itself).
- hornetblack 8y agoCase in point. Google's ANGLE library has a in-progress Vulkan back-end. (Used for WebGL in Chrome and Firefox). ANGLE does only provide OpenGL ES, but then so does Android. I wouldn't be surprised if an upcoming android version required Vulkan suppport and Android shipped with ANGLE for OpenGL. https://github.com/google/angle https://github.com/google/angle
- kllrnohj 8y agoIn reality this is entirely moot and comes down purely to driver development cost. Nothing in the OS is designed around the idea of being "vulkan native" or not. That's just not a system architecture thing at all. But what is a thing is whether or not the GPU driver bothers to have an OpenGL ES path or not. It's obviously simpler if the driver doesn't, but a quality driver implementation will also obviously always beat something like ANGLE in every way. So take a hypothetical Nvidia Shield 5 running Fuchsia in 5 years or whatever. If games are still dominantly in OpenGL ES, then you can bet your ass Nvidia will be shipping a first-class GLES driver and not use ANGLE-on-Vulkan.
- fouc 8y agoHow tied to the internet will it be? How many callbacks to google will it have? Will it rely on google DNS?
- hrdwdmrbl 8y agonot
- sagartewari01 8y ago> Will it rely on google DNS? You bet!
- HeWhoLurksLate 8y agoAs default, that makes a lot of sense. I guarantee there will be a lot of pushback from enterprises if they can't change the DNS servers to their own.
- j16sdiz 8y agoGoogle does not mix well with stable api. They love the shiny new stuffs and break things often.
- protomyth 8y agoThe copyright owner can alway relicense no matter what license they use initially. Unless you mean others, in which case what license do they use that allows relicensing?
- nwah1 8y agoThe MIT, BSD, and Apache licenses, which Fuchsia uses, have almost no restrictions aside from attribution. Anyone would be able to fork Fuchsia and re-license as GPL.
- paavoova 8y agoHow exactly does that work, what stops anyone from maintaining a 1:1 branch, the "fork", with upstream and claiming it's GPL?
- pram 8y agoYou can relicense MIT source to GPL. Nothing is stopping anyone from maintaining a relicensed fork like you described. The real question is, would anyone even use or contribute to that fork? (probably not)
- suby 8y agoIt kind of defeats the purpose of GPL too. You can't keep future changes to the codebase public and open source since anyone who wants to do so will just not use your fork, so why bother?
- wongarsu 8y agoOnce somebody contributes to the fork the fork contains code that can't be backported to the MIT licenced version. The hope would presumably be that the GPL version grows faster since the GPL version can merge any change to the MIT version but not the other way around. In practise it wouldn't work all that well unless you pay a development team to push the GPL version significantly ahead, but it's a possibility.
- Stratoscope 8y ago> capability-based For anyone wondering what that means, here's a good place to start: http://erights.org/elib/capability/overview.html http://erights.org/elib/capability/overview.html > Modern capability security theory comes mostly from the work of Norm Hardy, Charlie Landau, Bill Frantz and others... I worked with Norm and Bill at Tymshare in the '70s. Alas, Norm passed on last year, but I got to see Bill at his memorial. If you're in the Bay Area and into ham radio, you might run into Bill on the N6NFI repeater.
- admax88q 8y agoAnyone can fork. But with the way android works vendors will no longer have to release their kernels for their android versions. This is one of the main reasons projects like lineage can exist as you can build and modify a kernel for almost every device on the market.
- ocdtrekkie 8y agoRegardless of what you think of Google, the reality is Fuchsia and Android have little to nothing in common. While they would certainly rather have a permissive language from the bottom up, they certainly wouldn't have written a whole new OS with that as the primary goal. Android's platform design would arguably have been considered modern in 2007 or 2008, but it is 2019, and the cracks in Android's capabilities have been widening for a while. Sometimes people still think of Android as "newer" in the operating system space, but it's a decade old!
- altmind 8y agoNo arguing with that - yes, selinux/uid permissions were somewhat wonky. But google did the job and paid its price isolating the programs and it works right now. Can we consider the problem of android app isolation aldready solved?
- beatgammit 8y agoA decade isn't much for an operating system...
- ocdtrekkie 8y agoIt is when you start thinking about our approach to security in 2019, versus our approach to security in 2009. And sometimes the baseline assumptions about how software is written makes it exceedingly hard to, in flight, rebuild for our new understanding of what is needed for good security. Attempts to do so often entail more or less, tacking on a whole different environment, as Microsoft has attempted with UWP. To a certain degree, it'd be easier to just start over from scratch, as Google is attempting to do.
- pjmlp 8y agoMicrosoft is still at it, just from the other side, by merging Win32 and UWP containers.
- wongarsu 8y agoWe mainly changed our focus from protecting multiple users from each other to protecting multiple applications from each other. But Android always had the latter model. Apart from that I don't think a lot has changed from 2009 to 2019?
- microcolonel 8y agoThere are plenty of kernels they could've started with, so I'm willing to say that the motivations are probably at least somewhat technical.
- londons_explore 8y agoI'd say it's more likely someone had a hobby of making microkernels, and when they joined Google they managed to twist the arm of someone senior to assign a few people to their hobby full time.
- fluffycat 8y agoA few? There are more than a hundred contributors in https://fuchsia.googlesource.com https://fuchsia.googlesource.com
- paavoova 8y agoI think it's a valid concern, look at how many originally open-source Android APIs and frameworks Google has pushed out in favor of their proprietary one's. Similar concerns I've seen voiced is there being a inseparable integration with Google services, like how Google has pushed Gapps dependency onto Android, but now baked into the OS-level.
- draw_down 8y ago...or we could talk about the actual operating system, on the hacker forum for hackers where hackers talk about hacker stuff.
- est31 8y agoGoogle has been a Linux user since before it even existed [1], and has been almost exclusively a Linux shop since: Linux servers, Linux desktops (Chromebooks, Goobuntu, Whatever debian testing derived distro they are using now is called), Linux based phone OS. So I'd say for most of its business activities, Google is actually okay with the GPL, otherwise they'd have rewritten it a long time ago. Given the size of Google and how important Android is to them, I think they'd have prioritized Fuchsia OS far more if their bottom line were really affected. There is a point with drivers, as Fuchsia has better support for proprietary drivers than Linux and IIRC one of the Android modifications was to add HALs to the kernel to make proprietary drivers easier. But it's not a killer argument, after all they figured it out for Android. Their business intent with Fuchsia is definitely not clear so it's a honey pot for speculation. I don't know. Maybe they wanted to diversify their approaches and have something if the Android kernel fork gets more and more patches and eventually backporting becomes impossible and they need to maintain it on their own now. Maybe they just want to be upstream as it involves a great deal or power that you have. Maybe it's part of a deal with a hardware vendor who wants their driver to become proprietary in the future. [1]: https://web.archive.org/web/19971210065425/http://backrub.stanford.edu/backrub.html https://web.archive.org/web/19971210065425/http://backrub.st...
- altmind 8y agoAgree, android drivers/blobs were not much use in linux space => hence, the whole premise of android==linux, backporting features from android to linux was never an option. The ones who used rpi, or even cheap chinese android tables wo/ linux support can relate. Yes, google have nothing against GPL, but still GPL/agpl/lesser gpl are licenses that place specific limitations on a company modifying the original work. There are alternative licenses that do not.
- pjmlp 8y agoThey have been removing GPL parts from Android with each release, the only thing left is the kernel, which after Project Treble looks more like a pseudo-microkernel than traditional Linux.
- deleted 8y ago
- ucaetano 8y agoIt is irrelevant. Running Android apps is no longer tied to AOSP. Chromebooks run Android apps. There is an app ecosystem composed of Google Mobile Services and the Play store, today it runs on Android and on ChromeOS, and it seems that it will run on fuchsia too.
- doctorpangloss 8y agoIt’s not that important to them I think. It’s a great senior engineer retention project though.
- snvzz 8y ago>How do you feel, is there anything behind this claim? A glance at the design will tell you that no, there's nothing to that claim. Fuchsia's only competitor is Genode. Linux is basically obsoleted by its design.
- pjmlp 8y agoThe only GPL left on Android is the Linux kernel, everything else GPL related has been replaced.
- ernst_klim 8y ago>Stable drive interface, hardware manufacturers can independently maintain hardware drivers (hardware) For me this reason is enough to justify linux replacement. I think it's one of the main reasons for google to, they want to deal with vendors' blobs in a more stable and ease manner.
- lpu4o74p 8y agoThe point of being GPL free is you don't need to release source code. If you combine this with the other point of Fuchsia, hardcore security, the final combined result is that nobody can audit what Google is actually doing on "your" devices. And that's why.
- DannyB2 8y agoAssuming Google doesn't need to hide anything, being GPL free could be so that others (like device drivers) don't need to release source code.
- otabdeveloper1 8y agoEmbrace-extend-extinguish. Are people really dumb enough to fall for this trick over and over again? (Don't answer, that was a rhetorical question.)
- Jyaif 8y agoWhat exactly are they embracing by creating a new OS?
- jgimenez 8y agoThat's very much my feeling. Linux has a history behind and some design decisions made for a wide range of devices a long time ago. Google has the kind of money necessary to build an OS from scratch in order to power their devices (Android, Chromebook, Google Home), whilst other mortal beings have to put up with one of the existing choices.
- imtringued 8y agoSoC vendors who write the device drivers in the end probably couldn't care less. Why should they opensource their drivers for a new OS?