5 ms·

So, if I buy a device that runs Fuchsia (say, this Nest Hub), is enough of Fuchsia FOSS that I can run my own copy of it with e.g. a different UI and without Go

So, if I buy a device that runs Fuchsia (say, this Nest Hub), is enough of Fuchsia FOSS that I can run my own copy of it with e.g. a different UI and without Google services? This is true of Android devices by necessity as the kernel is GPL (bootloader locking aside); is it true of Fuchsia devices? As for bootloader locking, Google releases some Android devices with unlockable bootloaders. Can we expect the same of Fuchsia devices?

hibbelig 5y ago
Are unlockable bootloaders bootloaders that cannot be locked, or bootloaders that can be unlocked? Not a native speaker. Hm. I think it is about bootloaders that can be unlocked.
- tmerc 5y ago
  In this case, unlockable means it can be unlocked. As a native American English speaker, I have not seen unlockable used as "cannot be locked", but both definitions are in the Oxford dictionary. If I understand correctly, a locked bootloader prevents you from installing a different OS or rooting a device you might "own".
- techrat 5y ago
  "Unlockable" == "The option exists for the user to unlock the bootloader if they wish to do so." Even as a native speaker, it can get awkward explaining 'unlockable bootloaders' because the impliction is that they're first locked if they can be later unlocked... when there are also locked bootloaders that CANNOT be unlocked. It's better to just assume 'unlockable' means 'not restricted.'
surajrmal 5y ago
While the platform may be open source, the product may not be. We have products which are completely open source, but the one being used for the Nest Hub is not. This is similar to the idea where you may use Linux for the bottom half of an OS, but the top half may be something else entirety. Different products may make different decisions, but a common core is used amongst all products.
kerneis 5y ago
There are several parts to your question, let me try and answer each of them as I understand them. Fuchsia is built with a minimal core (sometimes called a microkernel) and many user-space services interacting with each other over an IPC protocol (called FIDL). The open-source part of Fuchsia, available on fuchsia.dev, is a standalone system which you can build and run on supported architectures. It contains all the services required to start a user interface, interact with the network, etc. Currently, the main supported hardware architecture for people wanting to build their own version of Fuchsia is the Intel NUC: https://fuchsia.dev/fuchsia-src/development/hardware/intel_nuc https://fuchsia.dev/fuchsia-src/development/hardware/intel_n.... For a retail devices, such as the Nest Hub, vendors can build a custom system with additional or different services from what is found in the open-source release. Thanks to stability of the FIDL interfaces, those closed-source services do not prevent the core system from being updated. For more information on services and packages, you can read https://fuchsia.dev/fuchsia-src/concepts/software_model https://fuchsia.dev/fuchsia-src/concepts/software_model and the pages linked from it. Some of those services are drivers; others may be in charge of communicating with Google Services or customizing the UI; and not all of them are necessarily open-source. So if you wanted to build your own version of Fuchsia for a Nest Hub, you'd need to replace the closed-source components. As far as the Nest Hub is concerned, I'm not sure what the exact status is. I believe a significant part of the drivers have been developed in the open (which is how 9to5google was able to guess in the past that we would be targeting this platform), but take this with a grain of salt, I didn't work on drivers. The part that interacts with Google Services is closed source. I'm not sure this is much different from the situation with Android: not all drivers or UI used on Android devices are open source, are they? Finally, as you note, the bootloader can be locked on retail devices, preventing you from reflashing the system with your own build unless it is signed by an authorized key (mostly for security reasons, as far as I understand it). This is a product decision that is not related to Fuchsia itself, it depends on each manufacturer. I don't think it has ever been supported to reflash a Nest Hub, and the migration to Fuchsia shouldn't change that.
- ryukafalz 5y ago
  Thanks, this is useful information. > For a retail devices, such as the Nest Hub, vendors can build a custom system with additional or different services from what is found in the open-source release. Thanks to stability of the FIDL interfaces, those closed-source services do not prevent the core system from being updated. This is helpful so long as the interface does not change; do you anticipate ever having to change it or do you think it's pretty final at this point? Regarding drivers, it's interesting that they're userspace services interacting with the rest of the system via IPC. Are there any sort of security guarantees to protect against malicious services? (Obviously a proprietary driver could do its job incorrectly, but if they can't otherwise mess with other parts of the system that's helpful.) EDIT: I suspect that as it's a capability-based system, there is a decent amount of isolation between drivers and the rest of the system, but I just want to be sure. > I'm not sure this is much different from the situation with Android: not all drivers or UI used on Android devices are open source, are they? Regarding Android drivers: my understanding is they sometimes do have proprietary userspace components. Any kernel-side components are necessarily FOSS however, as they are derivative of the Linux kernel and therefore GPL. (This doesn't mean that they're always easy to use though, as manufacturers seldom upstream them and the Linux kernel is a huge project.) On the Android UI, you're correct; most often the UI on an Android phone is not FOSS. I suspect this is because, as that part of Android is permissively licensed, the device vendors don't have to release it. So they don't. I've had mixed feelings with Fuchsia from a licensing perspective for that reason. On one hand, having a stable interface might make it easier to deal with proprietary drivers, provided that interface is locked in amber and never changes. On the other hand, Fuchsia's permissive licensing makes it more likely that manufacturers will make all their drivers proprietary, because they clearly do whenever they can. (At least the ARM vendors do; the x86 vendors seem to be a lot more open to working in public.)
swiley 5y ago
It's not really true for Android either because the graphics drivers are mostly userspace and end up coupled with a lot of the vendor provided stuff. Fuchsia has no GPL so it's unlikely any of the driver source will be available to you.
- deleted 5y ago
  [deleted]
- kerneis 5y ago
  > Fuchsia has no GPL so it's unlikely any of the driver source will be available to you. The open-source repository already contains over 50 directories named `drivers`: https://cs.opensource.google/search?q=f:drivers%2F$&sq=&ss=fuchsia%2Ffuchsia https://cs.opensource.google/search?q=f:drivers%2F$&sq=&ss=f...
  - swiley 5y ago
    The BSDs have lots of drivers too, but it's rare you see them coming to an embedded board first (and rarer you see BSPs published for them from vendors.)
  - fabrice_d 5y ago
    Yes, but it's very unlikely that chipset vendors like QC or MTK will provide the source to their drivers. Why would they? On the other hand, if the driver interfaces are stable, it should be possible to implement a GPL kernel that can use these drivers.

hibbelig 5y ago

Are unlockable bootloaders bootloaders that cannot be locked, or bootloaders that can be unlocked? Not a native speaker. Hm. I think it is about bootloaders that can be unlocked.

tmerc 5y ago
In this case, unlockable means it can be unlocked. As a native American English speaker, I have not seen unlockable used as "cannot be locked", but both definitions are in the Oxford dictionary. If I understand correctly, a locked bootloader prevents you from installing a different OS or rooting a device you might "own".
techrat 5y ago
"Unlockable" == "The option exists for the user to unlock the bootloader if they wish to do so." Even as a native speaker, it can get awkward explaining 'unlockable bootloaders' because the impliction is that they're first locked if they can be later unlocked... when there are also locked bootloaders that CANNOT be unlocked. It's better to just assume 'unlockable' means 'not restricted.'

surajrmal 5y ago

While the platform may be open source, the product may not be. We have products which are completely open source, but the one being used for the Nest Hub is not. This is similar to the idea where you may use Linux for the bottom half of an OS, but the top half may be something else entirety. Different products may make different decisions, but a common core is used amongst all products.

kerneis 5y ago

There are several parts to your question, let me try and answer each of them as I understand them. Fuchsia is built with a minimal core (sometimes called a microkernel) and many user-space services interacting with each other over an IPC protocol (called FIDL). The open-source part of Fuchsia, available on fuchsia.dev, is a standalone system which you can build and run on supported architectures. It contains all the services required to start a user interface, interact with the network, etc. Currently, the main supported hardware architecture for people wanting to build their own version of Fuchsia is the Intel NUC: https://fuchsia.dev/fuchsia-src/development/hardware/intel_nuc https://fuchsia.dev/fuchsia-src/development/hardware/intel_n.... For a retail devices, such as the Nest Hub, vendors can build a custom system with additional or different services from what is found in the open-source release. Thanks to stability of the FIDL interfaces, those closed-source services do not prevent the core system from being updated. For more information on services and packages, you can read https://fuchsia.dev/fuchsia-src/concepts/software_model https://fuchsia.dev/fuchsia-src/concepts/software_model and the pages linked from it. Some of those services are drivers; others may be in charge of communicating with Google Services or customizing the UI; and not all of them are necessarily open-source. So if you wanted to build your own version of Fuchsia for a Nest Hub, you'd need to replace the closed-source components. As far as the Nest Hub is concerned, I'm not sure what the exact status is. I believe a significant part of the drivers have been developed in the open (which is how 9to5google was able to guess in the past that we would be targeting this platform), but take this with a grain of salt, I didn't work on drivers. The part that interacts with Google Services is closed source. I'm not sure this is much different from the situation with Android: not all drivers or UI used on Android devices are open source, are they? Finally, as you note, the bootloader can be locked on retail devices, preventing you from reflashing the system with your own build unless it is signed by an authorized key (mostly for security reasons, as far as I understand it). This is a product decision that is not related to Fuchsia itself, it depends on each manufacturer. I don't think it has ever been supported to reflash a Nest Hub, and the migration to Fuchsia shouldn't change that.

ryukafalz 5y ago
Thanks, this is useful information. > For a retail devices, such as the Nest Hub, vendors can build a custom system with additional or different services from what is found in the open-source release. Thanks to stability of the FIDL interfaces, those closed-source services do not prevent the core system from being updated. This is helpful so long as the interface does not change; do you anticipate ever having to change it or do you think it's pretty final at this point? Regarding drivers, it's interesting that they're userspace services interacting with the rest of the system via IPC. Are there any sort of security guarantees to protect against malicious services? (Obviously a proprietary driver could do its job incorrectly, but if they can't otherwise mess with other parts of the system that's helpful.) EDIT: I suspect that as it's a capability-based system, there is a decent amount of isolation between drivers and the rest of the system, but I just want to be sure. > I'm not sure this is much different from the situation with Android: not all drivers or UI used on Android devices are open source, are they? Regarding Android drivers: my understanding is they sometimes do have proprietary userspace components. Any kernel-side components are necessarily FOSS however, as they are derivative of the Linux kernel and therefore GPL. (This doesn't mean that they're always easy to use though, as manufacturers seldom upstream them and the Linux kernel is a huge project.) On the Android UI, you're correct; most often the UI on an Android phone is not FOSS. I suspect this is because, as that part of Android is permissively licensed, the device vendors don't have to release it. So they don't. I've had mixed feelings with Fuchsia from a licensing perspective for that reason. On one hand, having a stable interface might make it easier to deal with proprietary drivers, provided that interface is locked in amber and never changes. On the other hand, Fuchsia's permissive licensing makes it more likely that manufacturers will make all their drivers proprietary, because they clearly do whenever they can. (At least the ARM vendors do; the x86 vendors seem to be a lot more open to working in public.)

swiley 5y ago

It's not really true for Android either because the graphics drivers are mostly userspace and end up coupled with a lot of the vendor provided stuff. Fuchsia has no GPL so it's unlikely any of the driver source will be available to you.

deleted 5y ago
[deleted]
kerneis 5y ago
> Fuchsia has no GPL so it's unlikely any of the driver source will be available to you. The open-source repository already contains over 50 directories named `drivers`: https://cs.opensource.google/search?q=f:drivers%2F$&sq=&ss=fuchsia%2Ffuchsia https://cs.opensource.google/search?q=f:drivers%2F$&sq=&ss=f...
- swiley 5y ago
  The BSDs have lots of drivers too, but it's rare you see them coming to an embedded board first (and rarer you see BSPs published for them from vendors.)
- fabrice_d 5y ago
  Yes, but it's very unlikely that chipset vendors like QC or MTK will provide the source to their drivers. Why would they? On the other hand, if the driver interfaces are stable, it should be possible to implement a GPL kernel that can use these drivers.