Since the build page doesn’t provide much context, Fushsia has 3 different configurations bringup, core and workstation.
The workstation configuration is described as:
> workstation is a basis for a general purpose development environment, good for working on UI, media and many other high-level features. This is also the best environment for enthusiasts to play with and explore.
Having used several Google OSS projects I would NEVER consider using an OS from Google.
The documentation structure is often atrocious, the are always dozens of recognized but unresolved bugs, those bugs often remain for years, the documentation often is not updated to reflect the state of open bugs so code samples and tutorials are often broken, the bugs are resolved slowly, non-Google pull requests are often left to die on the vine[0], no road maps, the Google employees use an internal build system and the external packages are often broken, and these three words: "Not. A. Priority." If your bug is not an internal Google priority you are basically out of luck. Hope you like maintaining your own patches, for years.
I'm not saying that OSS projects from other large projects don't have similar problems, I'm saying that every Google project I've depended on has had all of these problems.
The idea of my OS being run like this? Absurd.
This just is a guess, but, I'd wager that most Google OSS developers just wanted a fancy corporate job and got stuck interfacing with the public on an OSS project. I don't think that most of them aspired to be OSS developers and it shouldn't be a requirement.
[0]: Just today a two year old bug that I've been watching was closed by merging a pull request that was first opened in early-2020, closed as stale in mid-2021, and re-submitted/merged this week.
People are saying Fuchsia is only usable on IoT devices, not much progress, etc.
However, not many new operating systems have a Chrome browser [0] on them and Fuchsia has this, not many people realise how huge this is let alone on a new from the ground up OS.
So I don't think Fuchsia will be going away, in fact I would say it is coming pretty fast.
Whether you like it or not, this tells me that they are targeting the desktop, laptops and chromebooks next.
Yes it has GUI. Flutter is the main/official way to build apps on it. The OS shell is also written in Flutter if I remember correctly. So far, the OS has been seen on or confirmed to release in near future on one Google Home device. Technically though, it seems to be designed for all kind of consumer devices ranging from phones to desktops.
IMO this is more or less an experiment which if successful, will end up merging/replacing Android and Chrome OS into a single OS. Android and Chrome runtimes can be ported to Fuschia and the underlying OS can be swapped on many devices. New devices can ship with Fuschia + an android compatibility layer. Developers would be able to ship native Fuschia or android apps. Would work on phones, IoT, Chromebooks and could be install-able on desktops.
This is all just speculation though and a lot of things need to go right for this to happen but I'd imagine this would be the ideal/desired outcome for its creators.
Is anyone providing unofficial builds of Fuchsia? I can see from the article the requirement is to build it yourself but I'm lazy/time poor and I'd really like to try runnning Fuchsia in an emulator.
I think the key thing to watch is what they will replace Qualcomm's firmware with; if at all. Apple made a move a few years ago to reduce their dependence on Qualcomm. From what I've heard, Apple is rolling out their internal replacement for their 5G modem from year or so.
Basically Android is OSS linux with a lot of proprietary drivers that are not under the control of Google. And a lot of those are provided by Qualcomm. What they provide is effectively an OS inside an OS. Linux is a somewhat hostile environment for proprietary drivers and it necessitates some technical steps to insulate against the 'viral' nature of the GPL.
Google likes their dependency on Qualcomm just about as much as Apple does. It would not surprise me if they eventually move to their own in house 5G stack and I bet that would be a proprietary fuchsia exclusive. Proprietary ensures you get your software from Google (or Qualcomm). And making it exclusive to Fuchsia ensures they have full control over the combined package.
Chinese manufacturers are also insulating against being dependent on Qualcomm. E.g. Huawei has their own 5G modem and is of course also in the base station market.
I bet that most of drivers will be proprietary. It seems the main motivation for Fuchsia: to allow windows-like model for drivers with stable driver API, because Linux-like model does not work well for hardware manufacturers.
If you have read beyond the title, I don't think this is what you think it is. (At least not yet anyway), since it is still not ready yet as a general purpose workstation.
It's more like building it, rather than using it here.
I think the idea of a proper production grade Fuschia workstation that you could use as a daily driver is still a few years away realistically.
However, I think when that happens a lot of interesting opportunities will I inevitably open up because it provides what I think is an extremely compelling story for a lot of people you might not initially anticipate. For example, from a security and just general maintainability point of view I would expect it to become the new obvious choice inside of organisations for those who aren’t still tied to Windows specific desktop applications.
I'm not sure people realize just how much money Google has thus far sunk into Fuchsia for (AFAICT) very little in return. It was in the billions... years ago.
I don't know if this is still the case but the mission was absolutely to replace Android. Many at Google believe Android to be unsalvageable on two fronts: drivers and the general ecosystem.
It has been pitched internally at various products and (AFAIK) only found traction thus far on Nest hubs. It was heavily pushed for Chromecast but I guess nothing came of that.
I'm not an OS expert by any means but I am unconvinced about the viability of a microkernel architecture beyond theory. Security is an often-cited issue with context switching between user and kernel space.
Project Treble is an effort to separate driver and Linux kernel. And later Android added mechanism to upgrade kernel from play service. I guess Google is resourceful enough to hedging on different approach to solve a similar problem.
However, the crux of the problem is the Android manufacturer. You can't solve a human and incentive problem with a technical solution. Project Treble makes manufacturer easier to support their device, but they still don't motivate to do it. Google needs a tighter control on what device manufacturer should release.
Android One is a good approach, only qualify certain devices to be include for meeting certain criteria. They could actually create a watermark on unsecured device for not updating Android version, just like chromium do it to website not using https. I think this is more effective than creating a new OS just to let the manufacturer being lazy.
> Many at Google believe Android to be unsalvageable on two fronts: drivers and the general ecosystem.
Could you elaborate? I'm simply curious why people would feel that way about Android. By the ecosystem, do you mean the fact that apps are primarily Java? That they're poorly made? What makes the drivers unsalvageable? Proprietary blobs interacting with the Linux kernel? Something else?
It seems like a new kernel would have minimal drivers, but maybe it would offer a better way of having proprietary drivers? Linux doesn't have a stable device driver ABI so maybe that is making it hard for Google to update Android without the phone manufacturer being involved in the updating?
I'm just curious what people see as the problems with Android that would require a new OS to fix. For example, if the problem is poorly made apps, that problem will follow you to a new OS if you let them publish for the new OS - and if you truly don't want them, you could remove them from the Play Store.
As an outsider, I'd like big corps to spend billions on research projects or technologies like this than social networks like Google Plus. I feel a lot more good can come out of these projects even if the projects themselves fail.
Generally speaking the hybrid microkernel is the architecture both macOS and Windows went width, where some drivers still run in ring 0, but have some level of isolation between the core OS stuff, and driver stuff.
For example, this allows Windows to restart a crashed GPU driver.
Windows (and I think macOS as well) also has a stable kernel ABI/API for drivers, a fact that's probably appreciated by the hardware vendors.
The bad name attached to microkernels I think stems from the debate between Tanenbaum and Linus in the 90s, where Tanenbaum's microkernel was sorely lacking in performance, mostly owning to the incredibly resource intensive context switches on the CPUs of the time.
However, on newer CPUs, this cost is much less significant as CPUs are better optimized for this, making it worthwhile to revisit this issue.
> unconvinced about the viability of a microkernel architecture beyond theory
QNX is an example of a real-world microkernel OS that Blackberry purchased for use in mobile phones. One could argue it had superior peformance to Linux, not because of throughput, but due to its real-time guarantees.
Most OS targeted to embedded space are microkernel based, while Windows and macOS have long been microkernel inspired with plenty of OS subsystems running on userspace.
UNIX FOSS clones abhor microkernels, and then run containers everywhere with a monolithic kernel stuck accessing the real hardware via a type 1 hypervisor.
It isn´t a theory for about several years already.
It has been pitched internally at various products and (AFAIK) only found traction thus far on Nest hubs.
Since my Nest Hub received the update to Fuchsia it's been generally more laggy and unresponsive. Occasionally it needs a power cycle. I wish there was a way to downgrade to whatever it had pre-Fuchsia :(
> with context switching between user and kernel space.
This is an issue only because today CPUs are optimized for legacy monolith kernels which rarely switch and not for microkernels.
Microkernels are very important because they allow to reduce privileged code size and move most things out of kernel. Legacy kernels like Linux or Windows are just an endless source of vulnerabilities, use legacy programming languages and have zero security. Linux doesn't even use static code analysis.
For example, in Linux a network card driver runs at kernel with maximum privileges. In a microkernel it would be a separate process without access to anything in the system (even to a file system) so exploiting it wouldn't give much to attacker.
Microkernels are also not very useful on hardware without IOMMU's or separate buses isolating external components (like most SoC hardware), because a rouge-acting driver can take over your system anyway, so it has to be part of your trusted base. You can make such drivers into separate kernel-side threads or tasks, as a matter of pure convenience, but implementing them in userspace adds no security value.
Some stats about the various ways of writing the project name (taken from these comments):
Fuchsia: 39
Fuschia: 19
Fushia: 1
Fuchia: 1
Other: ?
...so we can conclude that the UX of this codename is terrible. Maybe they should change it to something more easy to remember, e.g. Fuxia (Fucksya would probably also be easier to remember, but could be deemed too obscene)?
[+] [-] benjaminl|4 years ago|reply
The workstation configuration is described as:
> workstation is a basis for a general purpose development environment, good for working on UI, media and many other high-level features. This is also the best environment for enthusiasts to play with and explore.
From https://fuchsia.dev/fuchsia-src/development/build/fx#key-pro...
[+] [-] miiiiiike|4 years ago|reply
The documentation structure is often atrocious, the are always dozens of recognized but unresolved bugs, those bugs often remain for years, the documentation often is not updated to reflect the state of open bugs so code samples and tutorials are often broken, the bugs are resolved slowly, non-Google pull requests are often left to die on the vine[0], no road maps, the Google employees use an internal build system and the external packages are often broken, and these three words: "Not. A. Priority." If your bug is not an internal Google priority you are basically out of luck. Hope you like maintaining your own patches, for years.
I'm not saying that OSS projects from other large projects don't have similar problems, I'm saying that every Google project I've depended on has had all of these problems.
The idea of my OS being run like this? Absurd.
This just is a guess, but, I'd wager that most Google OSS developers just wanted a fancy corporate job and got stuck interfacing with the public on an OSS project. I don't think that most of them aspired to be OSS developers and it shouldn't be a requirement.
[0]: Just today a two year old bug that I've been watching was closed by merging a pull request that was first opened in early-2020, closed as stale in mid-2021, and re-submitted/merged this week.
[+] [-] cjbprime|4 years ago|reply
[+] [-] kgraves|4 years ago|reply
However, not many new operating systems have a Chrome browser [0] on them and Fuchsia has this, not many people realise how huge this is let alone on a new from the ground up OS.
So I don't think Fuchsia will be going away, in fact I would say it is coming pretty fast.
Whether you like it or not, this tells me that they are targeting the desktop, laptops and chromebooks next.
[0] https://youtube.com/watch?v=Rg9YgWXLfEo
[+] [-] sidcool|4 years ago|reply
[+] [-] Osiris|4 years ago|reply
There isn't much information about the capabilities of workstation. Is it a GUI OS? Can one run Flutter apps on it?
[+] [-] owaislone|4 years ago|reply
IMO this is more or less an experiment which if successful, will end up merging/replacing Android and Chrome OS into a single OS. Android and Chrome runtimes can be ported to Fuschia and the underlying OS can be swapped on many devices. New devices can ship with Fuschia + an android compatibility layer. Developers would be able to ship native Fuschia or android apps. Would work on phones, IoT, Chromebooks and could be install-able on desktops.
This is all just speculation though and a lot of things need to go right for this to happen but I'd imagine this would be the ideal/desired outcome for its creators.
[+] [-] p_l|4 years ago|reply
[+] [-] sequence7|4 years ago|reply
[+] [-] est31|4 years ago|reply
[+] [-] pabs3|4 years ago|reply
[+] [-] jillesvangurp|4 years ago|reply
Basically Android is OSS linux with a lot of proprietary drivers that are not under the control of Google. And a lot of those are provided by Qualcomm. What they provide is effectively an OS inside an OS. Linux is a somewhat hostile environment for proprietary drivers and it necessitates some technical steps to insulate against the 'viral' nature of the GPL.
Google likes their dependency on Qualcomm just about as much as Apple does. It would not surprise me if they eventually move to their own in house 5G stack and I bet that would be a proprietary fuchsia exclusive. Proprietary ensures you get your software from Google (or Qualcomm). And making it exclusive to Fuchsia ensures they have full control over the combined package.
Chinese manufacturers are also insulating against being dependent on Qualcomm. E.g. Huawei has their own 5G modem and is of course also in the base station market.
[+] [-] vbezhenar|4 years ago|reply
[+] [-] KSPAtlas|4 years ago|reply
[+] [-] krausejj|4 years ago|reply
[+] [-] childintime|4 years ago|reply
No need for the habitual google defamation exercise here.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] m6w6|4 years ago|reply
I can only guess that it's because of HW drivers?
[+] [-] nomercy400|4 years ago|reply
[+] [-] rvz|4 years ago|reply
It's more like building it, rather than using it here.
[+] [-] kwijibob|4 years ago|reply
Or is it basically just for Google employees working on Google devices?
[+] [-] mhoad|4 years ago|reply
However, I think when that happens a lot of interesting opportunities will I inevitably open up because it provides what I think is an extremely compelling story for a lot of people you might not initially anticipate. For example, from a security and just general maintainability point of view I would expect it to become the new obvious choice inside of organisations for those who aren’t still tied to Windows specific desktop applications.
[+] [-] cletus|4 years ago|reply
I don't know if this is still the case but the mission was absolutely to replace Android. Many at Google believe Android to be unsalvageable on two fronts: drivers and the general ecosystem.
It has been pitched internally at various products and (AFAIK) only found traction thus far on Nest hubs. It was heavily pushed for Chromecast but I guess nothing came of that.
I'm not an OS expert by any means but I am unconvinced about the viability of a microkernel architecture beyond theory. Security is an often-cited issue with context switching between user and kernel space.
[+] [-] dollop43|4 years ago|reply
However, the crux of the problem is the Android manufacturer. You can't solve a human and incentive problem with a technical solution. Project Treble makes manufacturer easier to support their device, but they still don't motivate to do it. Google needs a tighter control on what device manufacturer should release.
Android One is a good approach, only qualify certain devices to be include for meeting certain criteria. They could actually create a watermark on unsecured device for not updating Android version, just like chromium do it to website not using https. I think this is more effective than creating a new OS just to let the manufacturer being lazy.
[+] [-] mdasen|4 years ago|reply
Could you elaborate? I'm simply curious why people would feel that way about Android. By the ecosystem, do you mean the fact that apps are primarily Java? That they're poorly made? What makes the drivers unsalvageable? Proprietary blobs interacting with the Linux kernel? Something else?
It seems like a new kernel would have minimal drivers, but maybe it would offer a better way of having proprietary drivers? Linux doesn't have a stable device driver ABI so maybe that is making it hard for Google to update Android without the phone manufacturer being involved in the updating?
I'm just curious what people see as the problems with Android that would require a new OS to fix. For example, if the problem is poorly made apps, that problem will follow you to a new OS if you let them publish for the new OS - and if you truly don't want them, you could remove them from the Play Store.
[+] [-] owaislone|4 years ago|reply
[+] [-] torginus|4 years ago|reply
For example, this allows Windows to restart a crashed GPU driver.
Windows (and I think macOS as well) also has a stable kernel ABI/API for drivers, a fact that's probably appreciated by the hardware vendors.
The bad name attached to microkernels I think stems from the debate between Tanenbaum and Linus in the 90s, where Tanenbaum's microkernel was sorely lacking in performance, mostly owning to the incredibly resource intensive context switches on the CPUs of the time.
However, on newer CPUs, this cost is much less significant as CPUs are better optimized for this, making it worthwhile to revisit this issue.
[+] [-] grumpyprole|4 years ago|reply
QNX is an example of a real-world microkernel OS that Blackberry purchased for use in mobile phones. One could argue it had superior peformance to Linux, not because of throughput, but due to its real-time guarantees.
[+] [-] johncolanduoni|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
UNIX FOSS clones abhor microkernels, and then run containers everywhere with a monolithic kernel stuck accessing the real hardware via a type 1 hypervisor.
It isn´t a theory for about several years already.
[+] [-] jpkeisala|4 years ago|reply
Citation needed
[+] [-] pch00|4 years ago|reply
Since my Nest Hub received the update to Fuchsia it's been generally more laggy and unresponsive. Occasionally it needs a power cycle. I wish there was a way to downgrade to whatever it had pre-Fuchsia :(
[+] [-] codedokode|4 years ago|reply
This is an issue only because today CPUs are optimized for legacy monolith kernels which rarely switch and not for microkernels.
Microkernels are very important because they allow to reduce privileged code size and move most things out of kernel. Legacy kernels like Linux or Windows are just an endless source of vulnerabilities, use legacy programming languages and have zero security. Linux doesn't even use static code analysis.
For example, in Linux a network card driver runs at kernel with maximum privileges. In a microkernel it would be a separate process without access to anything in the system (even to a file system) so exploiting it wouldn't give much to attacker.
[+] [-] beagle3|4 years ago|reply
[+] [-] nine_k|4 years ago|reply
[+] [-] zozbot234|4 years ago|reply
[+] [-] rob74|4 years ago|reply
Fuchsia: 39
Fuschia: 19
Fushia: 1
Fuchia: 1
Other: ?
...so we can conclude that the UX of this codename is terrible. Maybe they should change it to something more easy to remember, e.g. Fuxia (Fucksya would probably also be easier to remember, but could be deemed too obscene)?
[+] [-] naoqj|4 years ago|reply
[+] [-] inops|4 years ago|reply
[+] [-] detritus|4 years ago|reply
[+] [-] catchclose8919|4 years ago|reply
[+] [-] davnn|4 years ago|reply
[+] [-] zoltar|4 years ago|reply
[+] [-] aynsof|4 years ago|reply
[+] [-] ggm|4 years ago|reply
[+] [-] lnxg33k1|4 years ago|reply
[+] [-] pch00|4 years ago|reply
[+] [-] orthoxerox|4 years ago|reply
[+] [-] Razengan|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]