147 ms·

It will be very interesting to watch how Fuchsia evolves over the next couple of years. Especially what Google has planned for it. It might be a small moonshot

It will be very interesting to watch how Fuchsia evolves over the next couple of years. Especially what Google has planned for it. It might be a small moonshot experiment to see if they can come with a sensible, modern OS. It might also be the designated successor for Android/Chrome OS, and the future of the Google ecosystem. Conceptually, Fuchsia is interesting. It's built on a microkernel (Zirkon) and a capabilities based system. Drivers are isolated elf binaries with a stable ABI, other normally privileged things like file systems are also isolated services. On one hand, I find it promising as a application platform, both for mobile devices and desktops: while Linux sandboxing capabilities are evolving (cgroups , namespaces, ...) , very little of the ecosystem is built around isolation as a primary concept, leading to all kinds of half-baked sandboxing and permission solutions: chroot, Flatpack, firejail, SELinux, (Docker, mentioned hesitantly since it's mainly for server environments)... All of which are somewhat tacked on an hard to use properly. So a clean sheet design might be the best viable (practical) path. On the other hand: * this throws away decades of work on Linux * many drivers will be closed source; open drivers are a major achievement of Linux * Linux is a very collaborative effort with many stakeholders, while Google is known for keeping a very firm grip on their projects Curios to hear other thoughts on this.

sascha_sl 7y ago
Read NAMESPACES(7) The Linux kernel itself has a unified sandboxing API, there are just a lot of clients using different parts of it. And that's pretty nice, being able to pick what you need when developing an OS conceptually just barely above the kernel. Cgroups is more of a resource constraining API, I wouldn't call it the exact same concern as sandboxing. http://man7.org/linux/man-pages/man7/namespaces.7.html http://man7.org/linux/man-pages/man7/namespaces.7.html
- the_duke 7y ago
  I mentioned namespaces. The point I was trying to make: while you can build sandboxing solutions based on Linux, the entire ecosystem has evolved without sandboxing as a first class concept, leading to numerous half-baked, half-adopted solutions that are all quite cumbersome from a user perspective. A new OS with sandboxing by default would probably produce a applicaton ecosystem that is more secure. Also, isolating many normally privileged facilities (like drivers, file systems, ...) is not something that is reasonable on Linux.
- amluto 7y ago
  I’ve read that, and I helped develop and troubleshoot it. It’s a rather complex solution to the problem that POSIX is not particularly amenable to sandboxing. A good capability-based design can be sandboxed with no fuss at all.
- heavenlyhash 7y ago
  If you read NAMESPACES(7) and thought to yourself "that's a unified API", we have radically different definitions of "unified".
abacadaba 7y ago
Would be kind of a shame naming-wise if the first sentient devices end up running Fuchsia instead of Android.
- blotter_paper 7y ago
  How do we know which devices are sentient? The first ones could have ran GM-NAA I/O for all I know.
  - abacadaba 7y ago
    Not how we'll know, how they'll know.
  - deleted 7y ago
    [deleted]
- the_duke 7y ago
  Well, the first sentient device will probably be some supercomputer, so it won't be either of those. ;)
  - pestaa 7y ago
    There is no rule that supercomputers cannot run on Android. Let's just hope a new digital consciousness will be able to first observe something other than the Play Store or it's going have a very dim view of us.
    - abacadaba 7y ago
      No rule that I know of that sentience necessarily requires a supercomputer, either. Coming from someone that thinks houseflies are most likely sentient at some level.
- Razengan 7y ago
  “i OS” also works, and they may process their thoughts in their own bodies instead of receiving them remotely.
sprash 7y ago
Fuchsia has no real game changing new technology to offer. To me it looks just like a safety backup plan for the case that the Linux kernel can not be used anymore. For a similar reason Valve is pushing for Linux support in Games just in case Microsoft pulls them out of their Business by only allowing their own Appstore. Google should have forked Inferno OS. The DIS VM looks a lot like Android/Dalvik VM, Limbo looks a lot like an early version of Go and per App namespaces would be a much better alternative to the current way Android sandboxes its Apps.
- gtirloni 7y ago
  How would they not be able to use Linux anymore? With it being GPL and everything?
  - mkr-hn 7y ago
    Imagine a scenario where Microsoft's moves into open source aren't genuine. They spend a decade or two working their way into the ecosystem using their ownership of GitHub to encourage Microsoft solutions. One day Google wakes up to find some key component has been replaced with something Microsoft controls, or at least primarily develops. No biggie. They'll just make their own. Until the next one. I'm hopeful EEE[1] is a thing of the past, but I can see why Google would hedge for the possibility of Linux and open source in general being pod peopled into an ecosystem it can't keep using. They're worried Microsoft will do to Linux what Google did to AOSP. Golang's dependence on importing stuff from GitHub is already a threat. [1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
    - dodobirdlord 7y ago
      > One day Google wakes up to find some key component has been replaced with something Microsoft controls, or at least primarily develops. Then Google just doesn't take that patch and forks the kernel. Google already has its gLinux team with their own Debian-based Linux distro, and Google has a successful history of leading OSS projects.
    - 7y ago
swsieber 7y ago
One other con for ya: * Google is very likely to kill privacy enabling features
- devoply 7y ago
  Yeah as a dev I am not touching this with a 5 foot pole. Google open source is not open source. It's a nasty tactic of pretending to be open source while not actually being open source as the speed of development is so fast that it's impossible to fork anything and then its laden with proprietary blobs where you have to "trust" Google which basically means tolerate them doing nefarious shit.
  - xparco 7y ago
    Stop with the conspiracy theories and your tinfoil hat
  - kgraves 7y ago
    > ...as a dev I am not touching this with a 5 foot pole. Google open source is not open source. I do not understand what this means, the code is open isn't it?[0] This sounds very over exaggerated and alarmist, just like Android and for example Chromium people have forked it and removed all the Google proprietary stuff from it[1], I am sure you and other privacy conscious developers in the future will do the same for Fuchsia. [0] https://fuchsia.dev/fuchsia-src/development/source_code https://fuchsia.dev/fuchsia-src/development/source_code [1] https://github.com/Eloston/ungoogled-chromium https://github.com/Eloston/ungoogled-chromium
    - meruru 7y ago
      Yes, it's open source. I wouldn't try to claim it isn't, like the parent is doing. However Google being behind it still makes me nervous, specially since this might end up replacing the copyleft Linux kernel and contributing to furthering the locking-down and tivoization of Android.
  - eikenberry 7y ago
    Chromium doesn't match with this description. It has a ton of forks and derivative works, both open source and commercial. https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browsers_based_on_Chromium https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browser...
Asooka 7y ago
I could see myself using Fuchsia IFF we get the GNU userland and full Posix (including all the optional parts that Linux currently implements) on top of it. Closed drivers are a concession that doesn't sound too bad as long as the userland is proper GNU. On the other hand, the mere existence of Fuchsia might lead to its best ideas being reimplemented in Linux itself, which would be a win as well.
- fithisux 7y ago
  Or we could wait for Hurd, and it is not a joke.
- ridiculous_fish 7y ago
  Fuchsia doesn't implement dot dot to traverse to the parent directory. POSIX doesn't seem likely.
- AnIdiotOnTheNet 7y ago
  > I could see myself using Fuchsia IFF we get the GNU userland and full Posix Then what the hell would be the point?
- breatheoften 7y ago
  Closed source drivers running in kernel address space ... realistically — by now we know that even open source drivers running in kernel space isn’t really that great an idea. MacOS/iOS are about to move the file system layer and any third party kernel extensions out of kernel space and into user space — it seems to me an inevitable necessity that the notion that “hardware interfaces need drivers in the kernel” is going to have to die ... the time has arrived where hardware components (other than cpu and memory) need to be viewed as user space programs that the kernel talks to when the kernel wants to...
- pjmlp 7y ago
  Then keep using a UNIX clone.
vbezhenar 7y ago
I thought that Android fully leverages SELinux? That's how it implemented permissions AFAIK.
- Someone1234 7y ago
  SELinux wasn't added until after Android 4.3. Android's Application Sandboxing primarily relies on Linux's user security model. Each app is assigned a UID and run in that "user's" context. To quote the official docs: > The sandbox is simple, auditable, and based on decades-old UNIX-style user separation of processes and file permissions. https://source.android.com/security/app-sandbox https://source.android.com/security/app-sandbox SELinux is an extra layer of security that really benefited system services, drivers, and other exploit vectors. All apps remain sandboxed via normal user security on Linux, and then SELinux sprinkled on top for further hardening: > Prior to Android 4.3, these sandboxes were defined by the creation of a unique Linux UID for each application at time of installation. Android 4.3 and later uses SELinux to further define the boundaries of the Android application sandbox. https://source.android.com/security/selinux https://source.android.com/security/selinux
  - vbezhenar 7y ago
    Well, Android 4.3 is very old OS. Sandboxing is one thing, permissions are another. You can't deny Internet usage for application with unix permissions, for example.
    - JetSpiegel 7y ago
      You can with iptables.
meruru 7y ago
I think if Google drops Linux for Fuchsia, there's a chance Microsoft picks up Android development. That would be incredible.
- flyinglizard 7y ago
  Android will still be Android, but running over a Fuchsia kernel instead of the Linux kernel.
  - joenathanone 7y ago
    Fuchsia is an OS not a kernel, the kernel running under Fuchsia is called Zircon.
    - deleted 7y ago
      [deleted]
  - meruru 7y ago
    Linux is the last GPL component of Android. Dropping it would enable Google to close up Android source whenever they want.
    - flyinglizard 7y ago
      That doesn't make sense to me at all - you can have a closed source system running on top of Linux, today.
      - ghostpepper 7y ago
        Isn't that exactly what Android is? edit: misread your comment
        codewiz 7y ago
        No, Android (or rather, AOSP), is fully open source. Most device makers fork AOSP and distribute binaries containing their modifications. These always come with source code for the GPL portions, and occasionally also the portions licensed under permissive licenses such as Apache and BSD. For instance, OnePlus and Sony publish these Android sources: https://github.com/OnePlusOSS https://github.com/OnePlusOSS https://github.com/sonyxperiadev?tab=repositories https://github.com/sonyxperiadev?tab=repositories
onlyrealcuzzo 7y ago
Is there any chance they're developing Fuchsia for use in their data centers? As like the Kernel/OS for Google's servers? They already use a custom version of Linux, right?
- bonzini 7y ago
  Never say never but it's unlikely. Microkernels are slower than a monolithic kernel like Linux, and speed is money for Google's data center software.
  - StillBored 7y ago
    Microkernels are slower than a monolithic kernel like Linux, Twenty years ago I might have agreed with the basic premise but argued the a properly designed system with a fast zero copy IPC mechanism was worth the small cost. OTOH, Linux has become massively bloated as it attempts to fit into every nook and cranny. Optimizations that work in one environment simply don't make sense in others. Beyond that computing hardware has changed in 20 years. These days having a bunch of cores is normal, along with scattering them everywhere to manage power/clock or dedicate them for IO is common. Further a very large number of the highest performing applications are utilizing some kind of kernel bypass. The "standardization" of DPDK despite its shortcomings has brought hundreds of applications out of dark and pointed out the folly of trying to fit everything into a posix view of the world.
  - pjmlp 7y ago
    Ah the typical microkernel FUD. UNIX clones, Linux and BSD variants are the surviving monolithic kernels. On embedded space, most high integrity OSes are microkernel based, Apple and Microsoft OSes are hybrid variants, and as shown at this year's WWDC in a couple of years Apple OSes will only allow for user space drivers. Even Android now uses a mixed model with userspace drivers (Treble compliant ones) and the standard Linux drivers (Treble legacy mode drivers).
    - bonzini 7y ago
      It's not FUD. Measure system call latency on Fuchsia and Linux for a simple read(), and you'll see Fuchsia is slower. It's the context switch that kills you, not the copies. Of course you could use FUSE on Linux and it would be just as slow.
ernst_klim 7y ago
The bad thing about fuchsia is how closed the development process is. There is no community around it, they don't advertise it, don't encourage broader use and adoption. The contribution process is quite centralized to. It feels like it's google project and they and only they would decide its direction. So no spontaneous order, it's their way or no way.
- mythz 7y ago
  Which is expected for their own funded project that's still under active development which they've explicitly decided against publicizing what its strategic purpose or intentions are for it. > It feels like it's google project and they and only they would decide its direction. So no spontaneous order, it's their way or no way. Of course they're going to have full discretion of this multi-year heavily resourced investment for which they've spent years developing and haven't officially released yet. You can re-asses the merits of the project after they've released it, as to whether it's something you want to use or contribute to or not. It's clear at this stage they're not developing Fuchsia with reliance on external OSS contributions.
  - ernst_klim 7y ago
    >Which is expected for their own funded project that's still under active development which they've explicitly decided against publicizing what its strategic purpose or intentions are for it. Sure, the OP's question was what's bad about it. That's bad. >You can re-asses the merits of the project after they've released it There would be no merits. It's an OS. Who would write the thousands of drivers and layers for various purposes. If there will be no community, there would be no decent OS. And no, google doesn't invest enough in it. It's either you hire a dev team of thousands people, as Microsoft does, or draw the community. Google did neither so far, and so Fuchsia has fewer drivers than Haiku. Most they want it to be a system working on a few selected phones, or maybe google doesn't even consider it seriously, and it's an initiative of a small group of enthusiasts within google.
    - mythz 7y ago
StillBored 7y ago
* many drivers will be closed source; open drivers are a major achievement of Linux This is only partially true, simply having the source code for a driver doesn't mean you can fix anything given that overwhelmingly the hardware documentation isn't open or the drivers are talking to closed source firmware/binary blobs running on the hardware itself. It makes it easier to fix trivial problems caused by the OS changing, but it doesn't help when a problem is discovered in the underlying hardware/firmware/etc. So, the open source doesn't help as much as you would like, given the original drivers are frequently written by the hardware provider itself, or some privileged contractor given the documentation under NDA. This has been a huge problem with the ARM soc's that are "supported" in the linux kernel. Frequently they don't actually work following any given update, and no one can fix them because if they have open documentation it frequently is missing large swaths of the actual registers and device theory of operation parts necessary to assure that any given peripheral works.
- codewiz 7y ago
  The source code of the Linux kernel portions is still a huge step in the right direction, even if it comes without detailed datasheets and and talks to proprietary firmware. It still lets you continue to evolve the internal kernel interfaces without having to worry about the driver's existing ABI. It still lets you fix most security holes, or remove anti-features that rely on interaction between the firmware and userspace. Fuchsia, by means of facilitating real proprietary drivers, will take us back to the Windows era, where the OS must support 2 or 3 different driver models in parallel just to continue supporting existing hardware after it has been abandoned by the vendor (which typically means 1 or 2 years after its launch).
  - pjmlp 7y ago
    Yeah, my 10 year old laptop, bought with Windows 7, is now running Windows 10 latest, without any driver issues. While my Asus netbook, bought with Linux on it, has lost the DX 11 GPU capabilities and video hardware acceleration thanks to AMD open source driver reboot. Ah, Asus still pushes updates to Windows drivers on that specific model. So much for the power of open drivers.

sascha_sl 7y ago

Read NAMESPACES(7) The Linux kernel itself has a unified sandboxing API, there are just a lot of clients using different parts of it. And that's pretty nice, being able to pick what you need when developing an OS conceptually just barely above the kernel. Cgroups is more of a resource constraining API, I wouldn't call it the exact same concern as sandboxing. http://man7.org/linux/man-pages/man7/namespaces.7.html http://man7.org/linux/man-pages/man7/namespaces.7.html

the_duke 7y ago
I mentioned namespaces. The point I was trying to make: while you can build sandboxing solutions based on Linux, the entire ecosystem has evolved without sandboxing as a first class concept, leading to numerous half-baked, half-adopted solutions that are all quite cumbersome from a user perspective. A new OS with sandboxing by default would probably produce a applicaton ecosystem that is more secure. Also, isolating many normally privileged facilities (like drivers, file systems, ...) is not something that is reasonable on Linux.
amluto 7y ago
I’ve read that, and I helped develop and troubleshoot it. It’s a rather complex solution to the problem that POSIX is not particularly amenable to sandboxing. A good capability-based design can be sandboxed with no fuss at all.
heavenlyhash 7y ago
If you read NAMESPACES(7) and thought to yourself "that's a unified API", we have radically different definitions of "unified".

abacadaba 7y ago

Would be kind of a shame naming-wise if the first sentient devices end up running Fuchsia instead of Android.

blotter_paper 7y ago
How do we know which devices are sentient? The first ones could have ran GM-NAA I/O for all I know.
- abacadaba 7y ago
  Not how we'll know, how they'll know.
- deleted 7y ago
  [deleted]
the_duke 7y ago
Well, the first sentient device will probably be some supercomputer, so it won't be either of those. ;)
- pestaa 7y ago
  There is no rule that supercomputers cannot run on Android. Let's just hope a new digital consciousness will be able to first observe something other than the Play Store or it's going have a very dim view of us.
  - abacadaba 7y ago
    No rule that I know of that sentience necessarily requires a supercomputer, either. Coming from someone that thinks houseflies are most likely sentient at some level.
Razengan 7y ago
“i OS” also works, and they may process their thoughts in their own bodies instead of receiving them remotely.

sprash 7y ago

Fuchsia has no real game changing new technology to offer. To me it looks just like a safety backup plan for the case that the Linux kernel can not be used anymore. For a similar reason Valve is pushing for Linux support in Games just in case Microsoft pulls them out of their Business by only allowing their own Appstore. Google should have forked Inferno OS. The DIS VM looks a lot like Android/Dalvik VM, Limbo looks a lot like an early version of Go and per App namespaces would be a much better alternative to the current way Android sandboxes its Apps.

gtirloni 7y ago
How would they not be able to use Linux anymore? With it being GPL and everything?
- mkr-hn 7y ago
  Imagine a scenario where Microsoft's moves into open source aren't genuine. They spend a decade or two working their way into the ecosystem using their ownership of GitHub to encourage Microsoft solutions. One day Google wakes up to find some key component has been replaced with something Microsoft controls, or at least primarily develops. No biggie. They'll just make their own. Until the next one. I'm hopeful EEE[1] is a thing of the past, but I can see why Google would hedge for the possibility of Linux and open source in general being pod peopled into an ecosystem it can't keep using. They're worried Microsoft will do to Linux what Google did to AOSP. Golang's dependence on importing stuff from GitHub is already a threat. [1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
  - dodobirdlord 7y ago
    > One day Google wakes up to find some key component has been replaced with something Microsoft controls, or at least primarily develops. Then Google just doesn't take that patch and forks the kernel. Google already has its gLinux team with their own Debian-based Linux distro, and Google has a successful history of leading OSS projects.
  - 7y ago

swsieber 7y ago

One other con for ya: * Google is very likely to kill privacy enabling features

devoply 7y ago
Yeah as a dev I am not touching this with a 5 foot pole. Google open source is not open source. It's a nasty tactic of pretending to be open source while not actually being open source as the speed of development is so fast that it's impossible to fork anything and then its laden with proprietary blobs where you have to "trust" Google which basically means tolerate them doing nefarious shit.
- xparco 7y ago
  Stop with the conspiracy theories and your tinfoil hat
- kgraves 7y ago
  > ...as a dev I am not touching this with a 5 foot pole. Google open source is not open source. I do not understand what this means, the code is open isn't it?[0] This sounds very over exaggerated and alarmist, just like Android and for example Chromium people have forked it and removed all the Google proprietary stuff from it[1], I am sure you and other privacy conscious developers in the future will do the same for Fuchsia. [0] https://fuchsia.dev/fuchsia-src/development/source_code https://fuchsia.dev/fuchsia-src/development/source_code [1] https://github.com/Eloston/ungoogled-chromium https://github.com/Eloston/ungoogled-chromium
  - meruru 7y ago
    Yes, it's open source. I wouldn't try to claim it isn't, like the parent is doing. However Google being behind it still makes me nervous, specially since this might end up replacing the copyleft Linux kernel and contributing to furthering the locking-down and tivoization of Android.
- eikenberry 7y ago
  Chromium doesn't match with this description. It has a ton of forks and derivative works, both open source and commercial. https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browsers_based_on_Chromium https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browser...

Asooka 7y ago

I could see myself using Fuchsia IFF we get the GNU userland and full Posix (including all the optional parts that Linux currently implements) on top of it. Closed drivers are a concession that doesn't sound too bad as long as the userland is proper GNU. On the other hand, the mere existence of Fuchsia might lead to its best ideas being reimplemented in Linux itself, which would be a win as well.

fithisux 7y ago
Or we could wait for Hurd, and it is not a joke.
ridiculous_fish 7y ago
Fuchsia doesn't implement dot dot to traverse to the parent directory. POSIX doesn't seem likely.
AnIdiotOnTheNet 7y ago
> I could see myself using Fuchsia IFF we get the GNU userland and full Posix Then what the hell would be the point?
breatheoften 7y ago
Closed source drivers running in kernel address space ... realistically — by now we know that even open source drivers running in kernel space isn’t really that great an idea. MacOS/iOS are about to move the file system layer and any third party kernel extensions out of kernel space and into user space — it seems to me an inevitable necessity that the notion that “hardware interfaces need drivers in the kernel” is going to have to die ... the time has arrived where hardware components (other than cpu and memory) need to be viewed as user space programs that the kernel talks to when the kernel wants to...
pjmlp 7y ago
Then keep using a UNIX clone.

vbezhenar 7y ago

I thought that Android fully leverages SELinux? That's how it implemented permissions AFAIK.

Someone1234 7y ago
SELinux wasn't added until after Android 4.3. Android's Application Sandboxing primarily relies on Linux's user security model. Each app is assigned a UID and run in that "user's" context. To quote the official docs: > The sandbox is simple, auditable, and based on decades-old UNIX-style user separation of processes and file permissions. https://source.android.com/security/app-sandbox https://source.android.com/security/app-sandbox SELinux is an extra layer of security that really benefited system services, drivers, and other exploit vectors. All apps remain sandboxed via normal user security on Linux, and then SELinux sprinkled on top for further hardening: > Prior to Android 4.3, these sandboxes were defined by the creation of a unique Linux UID for each application at time of installation. Android 4.3 and later uses SELinux to further define the boundaries of the Android application sandbox. https://source.android.com/security/selinux https://source.android.com/security/selinux
- vbezhenar 7y ago
  Well, Android 4.3 is very old OS. Sandboxing is one thing, permissions are another. You can't deny Internet usage for application with unix permissions, for example.
  - JetSpiegel 7y ago
    You can with iptables.

meruru 7y ago

I think if Google drops Linux for Fuchsia, there's a chance Microsoft picks up Android development. That would be incredible.

flyinglizard 7y ago
Android will still be Android, but running over a Fuchsia kernel instead of the Linux kernel.
- joenathanone 7y ago
  Fuchsia is an OS not a kernel, the kernel running under Fuchsia is called Zircon.
  - deleted 7y ago
    [deleted]
- meruru 7y ago
  Linux is the last GPL component of Android. Dropping it would enable Google to close up Android source whenever they want.
  - flyinglizard 7y ago
    That doesn't make sense to me at all - you can have a closed source system running on top of Linux, today.
    - ghostpepper 7y ago
      Isn't that exactly what Android is? edit: misread your comment
      - codewiz 7y ago
        No, Android (or rather, AOSP), is fully open source. Most device makers fork AOSP and distribute binaries containing their modifications. These always come with source code for the GPL portions, and occasionally also the portions licensed under permissive licenses such as Apache and BSD. For instance, OnePlus and Sony publish these Android sources: https://github.com/OnePlusOSS https://github.com/OnePlusOSS https://github.com/sonyxperiadev?tab=repositories https://github.com/sonyxperiadev?tab=repositories

onlyrealcuzzo 7y ago

Is there any chance they're developing Fuchsia for use in their data centers? As like the Kernel/OS for Google's servers? They already use a custom version of Linux, right?

bonzini 7y ago
Never say never but it's unlikely. Microkernels are slower than a monolithic kernel like Linux, and speed is money for Google's data center software.
- StillBored 7y ago
  Microkernels are slower than a monolithic kernel like Linux, Twenty years ago I might have agreed with the basic premise but argued the a properly designed system with a fast zero copy IPC mechanism was worth the small cost. OTOH, Linux has become massively bloated as it attempts to fit into every nook and cranny. Optimizations that work in one environment simply don't make sense in others. Beyond that computing hardware has changed in 20 years. These days having a bunch of cores is normal, along with scattering them everywhere to manage power/clock or dedicate them for IO is common. Further a very large number of the highest performing applications are utilizing some kind of kernel bypass. The "standardization" of DPDK despite its shortcomings has brought hundreds of applications out of dark and pointed out the folly of trying to fit everything into a posix view of the world.
- pjmlp 7y ago
  Ah the typical microkernel FUD. UNIX clones, Linux and BSD variants are the surviving monolithic kernels. On embedded space, most high integrity OSes are microkernel based, Apple and Microsoft OSes are hybrid variants, and as shown at this year's WWDC in a couple of years Apple OSes will only allow for user space drivers. Even Android now uses a mixed model with userspace drivers (Treble compliant ones) and the standard Linux drivers (Treble legacy mode drivers).
  - bonzini 7y ago
    It's not FUD. Measure system call latency on Fuchsia and Linux for a simple read(), and you'll see Fuchsia is slower. It's the context switch that kills you, not the copies. Of course you could use FUSE on Linux and it would be just as slow.

ernst_klim 7y ago

The bad thing about fuchsia is how closed the development process is. There is no community around it, they don't advertise it, don't encourage broader use and adoption. The contribution process is quite centralized to. It feels like it's google project and they and only they would decide its direction. So no spontaneous order, it's their way or no way.

mythz 7y ago
Which is expected for their own funded project that's still under active development which they've explicitly decided against publicizing what its strategic purpose or intentions are for it. > It feels like it's google project and they and only they would decide its direction. So no spontaneous order, it's their way or no way. Of course they're going to have full discretion of this multi-year heavily resourced investment for which they've spent years developing and haven't officially released yet. You can re-asses the merits of the project after they've released it, as to whether it's something you want to use or contribute to or not. It's clear at this stage they're not developing Fuchsia with reliance on external OSS contributions.
- ernst_klim 7y ago
  >Which is expected for their own funded project that's still under active development which they've explicitly decided against publicizing what its strategic purpose or intentions are for it. Sure, the OP's question was what's bad about it. That's bad. >You can re-asses the merits of the project after they've released it There would be no merits. It's an OS. Who would write the thousands of drivers and layers for various purposes. If there will be no community, there would be no decent OS. And no, google doesn't invest enough in it. It's either you hire a dev team of thousands people, as Microsoft does, or draw the community. Google did neither so far, and so Fuchsia has fewer drivers than Haiku. Most they want it to be a system working on a few selected phones, or maybe google doesn't even consider it seriously, and it's an initiative of a small group of enthusiasts within google.
  - mythz 7y ago

StillBored 7y ago

* many drivers will be closed source; open drivers are a major achievement of Linux This is only partially true, simply having the source code for a driver doesn't mean you can fix anything given that overwhelmingly the hardware documentation isn't open or the drivers are talking to closed source firmware/binary blobs running on the hardware itself. It makes it easier to fix trivial problems caused by the OS changing, but it doesn't help when a problem is discovered in the underlying hardware/firmware/etc. So, the open source doesn't help as much as you would like, given the original drivers are frequently written by the hardware provider itself, or some privileged contractor given the documentation under NDA. This has been a huge problem with the ARM soc's that are "supported" in the linux kernel. Frequently they don't actually work following any given update, and no one can fix them because if they have open documentation it frequently is missing large swaths of the actual registers and device theory of operation parts necessary to assure that any given peripheral works.

codewiz 7y ago
The source code of the Linux kernel portions is still a huge step in the right direction, even if it comes without detailed datasheets and and talks to proprietary firmware. It still lets you continue to evolve the internal kernel interfaces without having to worry about the driver's existing ABI. It still lets you fix most security holes, or remove anti-features that rely on interaction between the firmware and userspace. Fuchsia, by means of facilitating real proprietary drivers, will take us back to the Windows era, where the OS must support 2 or 3 different driver models in parallel just to continue supporting existing hardware after it has been abandoned by the vendor (which typically means 1 or 2 years after its launch).
- pjmlp 7y ago
  Yeah, my 10 year old laptop, bought with Windows 7, is now running Windows 10 latest, without any driver issues. While my Asus netbook, bought with Linux on it, has lost the DX 11 GPU capabilities and video hardware acceleration thanks to AMD open source driver reboot. Ah, Asus still pushes updates to Windows drivers on that specific model. So much for the power of open drivers.