The Google Nest Hub is first commercial Fuchsia device(arstechnica.com)
arstechnica.com
The Google Nest Hub is first commercial Fuchsia device
https://arstechnica.com/gadgets/2021/05/google-launches-its-third-major-operating-system-fuchsia/
243 comments
I half agree with you. It's not so much that Linux lacks a clean driver interface, it's really that OEMs write shitty software that doesn't belong upstream. Ideally vendors stop writing garbage drivers and distributing hacked up kernels with their "sample code" (but ends up in production) and opaque binary blobs.
Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad.
Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money.
In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits.
I don't see Fuchsia replacing that anytime soon.
Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad.
Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money.
In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits.
I don't see Fuchsia replacing that anytime soon.
I think OP's point is it doesn't matter if the drivers are crappy, as long as they only use a fixed and we'll defined interface.
If drivers all had a well defined interface, the exact same driver, binary or source, can be used across any OS version, and maybe even on other OS's with the right shims.
Then you don't need driver manufacturers to all collaborate to update the OS.
If drivers all had a well defined interface, the exact same driver, binary or source, can be used across any OS version, and maybe even on other OS's with the right shims.
Then you don't need driver manufacturers to all collaborate to update the OS.
The point is not to produce better drivers, rather a stable driver interface.
It is no accident that Project Treble drivers follow a similar mikrokernel approach to Fuchsia.
On Android, after Project Treble, classical GNU/Linux drivers are considered legacy mode drivers.
https://source.android.com/devices/architecture/hal
Fuchsia is the next step.
It is no accident that Project Treble drivers follow a similar mikrokernel approach to Fuchsia.
On Android, after Project Treble, classical GNU/Linux drivers are considered legacy mode drivers.
https://source.android.com/devices/architecture/hal
Fuchsia is the next step.
I wonder if a stable driver interface could also result in higher driver quality: if the same driver keeps working across many versions, even with relatively few users it could aggregate incremental improvements from various parties?
> the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed
> In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository.
Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here.
If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.
> In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository.
Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here.
If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.
Okay, but having a stable interface doesn't fix vendors shipping bad code, it just decouples it so you can run terrible drivers on a less-terrible kernel. Better yet, Fuchsia removes any obligation for vendors to share code (by both separating drivers from the OS and having the OS itself be permissively licensed), so third parties can't even start from vendor code and try to improve things.
Just like Project Treble,
Binderized HALs => HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.
Taken from https://source.android.com/devices/architecture/hal-types
Binderized HALs => HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.
Taken from https://source.android.com/devices/architecture/hal-types
These are two distinct problems. Rather, one is an improvement and another is a problem. The terrible drivers can then be isolated, pinpointed if you want, and the OS can move forward - if you don't use the AMD GPU or the HP printer no need to have it bloating your kernel, so I take this as the improvement (I was always fond of microkernels, so I'm advocating here). On the second problem, I fail seeing how the blame for vendors failing to update their drivers could fall on the OS. With this approach the failing is just much more evident, not any less damaging.
Why can't the vendors just contribute their drivers to the kernel? Why is it so hard? Looks like Intel is doing it and their products just work on Linux as a result. Why can't these shitty mobile hardware manufacturers do the same?
The sad answer is that they can't be bothered to meet the quality standards expected for upstream kernel code. Easier to just throw garbage in a tarball and ship privesc vulnerabilities to millions of users.
Driver supports costs money, vendors make money when they sell chips.
They treat drivers and software as a cost-center, so the software quality is typically horrible. Can't be merged, won't be merged.
Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
They treat drivers and software as a cost-center, so the software quality is typically horrible. Can't be merged, won't be merged.
Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
> Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
I don't remember it that way. I remember buying motherboards and receiving CDs full of drivers for the many Windows versions. I remember having to scour the internet for drivers and finding a different one for each Windows version. I remember failing to find drivers for new versions of Windows because the manufacturer couldn't care less. I remember incredibly shitty manufacturer applications that took over one minute to display a window on the screen. I even managed to reverse engineer one of those into a free software user space driver.
I don't remember it that way. I remember buying motherboards and receiving CDs full of drivers for the many Windows versions. I remember having to scour the internet for drivers and finding a different one for each Windows version. I remember failing to find drivers for new versions of Windows because the manufacturer couldn't care less. I remember incredibly shitty manufacturer applications that took over one minute to display a window on the screen. I even managed to reverse engineer one of those into a free software user space driver.
> I remember buying motherboards and receiving CDs full of drivers for the many Windows versions.
There haven't been "many" Windows versions in the entire existence of Windows. I bet you don't remember getting different drivers for every service pack or security update.
There haven't been "many" Windows versions in the entire existence of Windows. I bet you don't remember getting different drivers for every service pack or security update.
[deleted]
> Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.
That's just not true. A lot of hardware support was stranded by OS version updates, especially pre-Vista and Win7. It's reached a point where Linux deals a lot better w/ some older hardware than any currently-supported Windows version.
That's just not true. A lot of hardware support was stranded by OS version updates, especially pre-Vista and Win7. It's reached a point where Linux deals a lot better w/ some older hardware than any currently-supported Windows version.
A small handful of times over many decades when the driver model changed, not after every update.
There were a lot of drivers who will not work with new windows versions. Due for examples of changes in things expectedv in the inf file or the registry. Installing drivers in windows was a lot of pain.
Ok, but again when you talk about "new windows versions" you're talking about an event that happens very infrequently, and most drivers do continue to work for decades without needing to be updated across multiple major versions. Windows 7 drivers from 11 years ago generally speaking still work in Windows 10 today. Hell, even Vista drivers (14 years ago!) often still work. Contrast that with the Linux kernel where you have to recompile external drivers, what, every few weeks?
Some of that is just getting rid of compatibility code for misbehaving drivers.
Not just hardware but even older Windows applications run way better on WINE than on Windows 10. Microsoft doesn't care about reverse compatibility or long-term support for consumers.
you made my day, now i have to stop trolling and get a job. Do the same ;)
A couple of times since 1995, not every year.
I feel this must explain why every Android device I've owned has felt janky in some way, while with an Apple phone it just seems to work.
I second others: it is horrible, low quality code.
I spent lots of time looking at released drivers for things like wifi dongles and cheap Linux sticks/tablets, and there are all sorts of horrors. The wifi cards do not fully implement scanning or ad-hoc mode. Existing ioctls are ignored or implemented wrong. Sleep is used for thread synchronization. Android device drivers hardcode specific app names and apply fixups for them, presumably to prevent crashes.
Intel has much better code, at least in wireless drivers, but to be fair their jobs is easier, because most of the logic runs in the embedded processor, and you only get the binary blob for its code.
I spent lots of time looking at released drivers for things like wifi dongles and cheap Linux sticks/tablets, and there are all sorts of horrors. The wifi cards do not fully implement scanning or ad-hoc mode. Existing ioctls are ignored or implemented wrong. Sleep is used for thread synchronization. Android device drivers hardcode specific app names and apply fixups for them, presumably to prevent crashes.
Intel has much better code, at least in wireless drivers, but to be fair their jobs is easier, because most of the logic runs in the embedded processor, and you only get the binary blob for its code.
> Why can't the vendors just contribute their drivers to the kernel?
What makes you think they want to? They want you to buy the next chip and the next and the next, not keep using the previous one with a new OS.
What makes you think they want to? They want you to buy the next chip and the next and the next, not keep using the previous one with a new OS.
> What makes you think they want to?
Do they not care about having a high quality product?
Do they not care about having a high quality product?
They do have a high quality product. And then you have to buy their next high quality product instead of continuing to use the old one. Their products are hardware, not drivers, and they get more money by selling more hardware rather than letting old hardware get updated.
Can't use the hardware without the drivers. If the driver is low quality proprietary code that can't be fixed or updated, they don't have a high quality product.
And yet here we all are with umpty billion Qualcomm SoCs floating around and nobody complaining about how Qualcomm's chips don't work well (except, of course, in comparison to Apple's).
The hard reality that Linux kernel driver model stalwarts must face is that the only measure that matters to these companies is profit margin, and the economics just are not in favor of upstreaming their drivers. So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?
The hard reality that Linux kernel driver model stalwarts must face is that the only measure that matters to these companies is profit margin, and the economics just are not in favor of upstreaming their drivers. So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?
> So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?
Absolutely. Google has more than enough power and leverage to solve this problem. Why doesn't it require manufacturers to upstream their drivers instead of enabling their shitty industry practices? Literally just make it a requirement for Google Play services licensing or something. The phone manufacturers will be forced to require it from the chip manufacturers as well.
Google already does a lot of good work getting open source firmware into chromebooks. It should do even more. Use all that intellectual property for good for once.
Absolutely. Google has more than enough power and leverage to solve this problem. Why doesn't it require manufacturers to upstream their drivers instead of enabling their shitty industry practices? Literally just make it a requirement for Google Play services licensing or something. The phone manufacturers will be forced to require it from the chip manufacturers as well.
Google already does a lot of good work getting open source firmware into chromebooks. It should do even more. Use all that intellectual property for good for once.
> Google has more than enough power and leverage to solve this problem.
Yep. They are using their power and leverage to stabilize the kernel driver interface so that this just stops being a problem.
> Literally just make it a requirement for Google Play services licensing or something.
Google already has enough trouble keeping manufacturers on Google Play without giving them even more incentive to develop alternatives like microG.
https://wccftech.com/oppo-vivo-xiaomi-and-huawei-band-togeth...
https://wccftech.com/huawei-executive-says-the-company-wont-...
Android really needs the chip makers more than the chip makers need Android.
Yep. They are using their power and leverage to stabilize the kernel driver interface so that this just stops being a problem.
> Literally just make it a requirement for Google Play services licensing or something.
Google already has enough trouble keeping manufacturers on Google Play without giving them even more incentive to develop alternatives like microG.
https://wccftech.com/oppo-vivo-xiaomi-and-huawei-band-togeth...
https://wccftech.com/huawei-executive-says-the-company-wont-...
Android really needs the chip makers more than the chip makers need Android.
Nowadays, a lot of products go out of production and are replaced by the next model before they have time to settle and get a consumer reputation. It sometimes feels like they do only 1 production run per model and then bye-bye. So, quick and "good enough", "as good" or "not worse than others" is good enough :-/
> Do they not care about having a high quality product?
No.
They care about maximizing shareholder value. If shipping lots of hardware with barely functional drivers integrators need to beat up into shape makes the most profit, that's what they'll do.
If you spend $20K more on making the software work, then it pays off paying $1 less for a part with a crappy driver than buying one from a vendor who also provides great software for anything you intend to sell more than 20K units.
No.
They care about maximizing shareholder value. If shipping lots of hardware with barely functional drivers integrators need to beat up into shape makes the most profit, that's what they'll do.
If you spend $20K more on making the software work, then it pays off paying $1 less for a part with a crappy driver than buying one from a vendor who also provides great software for anything you intend to sell more than 20K units.
AMD already does and that creates a lot of friction both due to the bloat of the kernel the majority of which is now the AMD driver and the issue with code conventions and quality.
Unless hardware vendors agree to support a generic driver for each device type which can be maintained by the Linux kernel team it’s going to be a total nightmare and even then you need an easy model to extend the generic driver with a device specific one through an easy interface.
Unless hardware vendors agree to support a generic driver for each device type which can be maintained by the Linux kernel team it’s going to be a total nightmare and even then you need an easy model to extend the generic driver with a device specific one through an easy interface.
The AMD driver bloat is the register definitions. They have like 100+ MB of autogenerated register defines, some duplicated 8 times for each unit instance, for every chip generation and variant.
It's not real code, though it is ugly as heck and I have no idea why AMD can't do it a saber way.
It's not real code, though it is ugly as heck and I have no idea why AMD can't do it a saber way.
They might want to keep their driver source closed, and even if they don't upstreaming code into the kernel is simply a ton of extra work.
> Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions.
The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it.
And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.
The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it.
And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.
> strict licensing terms made it hard to get code upstreamed back
How come?
Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does.
Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.
How come?
Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does.
Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.
Will we see GNU/Fucshia someday maybe then? :P
The Kernel is an MIT license, and the user space is BSD [1]
> The Fuchsia kernel is released under the following MIT-style license: /zircon/kernel/LICENSE.
> All Fuchsia user space components are released under a BSD-style license: /LICENSE or an Apache 2.0 license: https://fuchsia.googlesource.com/infra/+/main/LICENSE.
> All code that is BSD-licensed has an additional IP grant: /PATENTS.
[1] https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
> The Fuchsia kernel is released under the following MIT-style license: /zircon/kernel/LICENSE.
> All Fuchsia user space components are released under a BSD-style license: /LICENSE or an Apache 2.0 license: https://fuchsia.googlesource.com/infra/+/main/LICENSE.
> All code that is BSD-licensed has an additional IP grant: /PATENTS.
[1] https://fuchsia.dev/fuchsia-src/contribute/governance/policy...
GNU/Fucsia would probably end up similar to GNU/Hurd in that case, or Apple's MkLinux.
I'm guessing that depends on how big the pile of Fuchsia-compatible device drivers grows and how badly people running open source OSes want to use that hardware.
Where there's a demand for a particular class of device, maybe someone will create a shim? Then the kernel folks can have a debate.
Currently though, I think Linux has a big head start.
Where there's a demand for a particular class of device, maybe someone will create a shim? Then the kernel folks can have a debate.
Currently though, I think Linux has a big head start.
"But Fuschia's goal is NOT to build another Android, but mainly to replace the Linux kernel."
"BPF will replace the Linux kernel" - Linux kernel developer
Funny that the B in BPF stands for Berkeley, as in "BSD".
I bet it will be renamed at some point.
"BPF will replace the Linux kernel" - Linux kernel developer
Funny that the B in BPF stands for Berkeley, as in "BSD".
I bet it will be renamed at some point.
"BPF will replace the Linux kernel" is a quote from Steven Rostedt.
> The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel.
To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."
To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."
It's a pet project. If you want to solve the kernel ABI problem, you can easily hard-fork and maintain that ABI indefinitely from any Linux kernel.
And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent.
In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally.
In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.
And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent.
In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally.
In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.
It accomplishes much more than just solving the kernel ABI problem.
It doesn't accomplish anything because nobody's going to use it.
May the best software win.
Anyway, if they succeed in integrating it into Android then that will be a lot of users :P
Anyway, if they succeed in integrating it into Android then that will be a lot of users :P
Seeing as how this is like the 5th or 6th year there has been some sort of press coverage about "Google's new OS" I'm not going to hold my breath.
Android already uses a similar model since Project Treble was introduced, with version 8 all drivers must use Android IPC instead of being Linux drivers.
Treble driver model is quite similar to Fuchsia, so it already happened, no need to prove anything.
Treble driver model is quite similar to Fuchsia, so it already happened, no need to prove anything.
I'm suprised to find people surprised at the development of a new OS. Linux is around 30 years old; Unix and C are around 50 years old.
Eventually the parameters of the world and of user needs shift far enough from the original design that it's less expensive to develop something new than to adapt the old thing. Sometimes it's impossible to adapt the old thing: for practical purposes, no amount of work will make C secure.
EDIT: Apparently Fuschia uses C and C++, and uses them exclusively in the kernel (if I understand correctly), and Rust and Dart are permitted for some uses, if this document is up-to-date: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d...
It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit. Let's not be conservative; let's do what our smarter predecessors did and embrace change.
Fuschia is free and open source, per other comments in this thread. If that's true, let's be very thankful that the successor to Unix, if that's what Fuschia becomes, is FOSS. If Google put a proprietary OS on its phones, etc., even if they didn't charge for it, they'd have a lot of market power and they'd be competing with a 50 year old OS. It could be a terrible blow to FOSS.
Eventually the parameters of the world and of user needs shift far enough from the original design that it's less expensive to develop something new than to adapt the old thing. Sometimes it's impossible to adapt the old thing: for practical purposes, no amount of work will make C secure.
EDIT: Apparently Fuschia uses C and C++, and uses them exclusively in the kernel (if I understand correctly), and Rust and Dart are permitted for some uses, if this document is up-to-date: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d...
It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit. Let's not be conservative; let's do what our smarter predecessors did and embrace change.
Fuschia is free and open source, per other comments in this thread. If that's true, let's be very thankful that the successor to Unix, if that's what Fuschia becomes, is FOSS. If Google put a proprietary OS on its phones, etc., even if they didn't charge for it, they'd have a lot of market power and they'd be competing with a 50 year old OS. It could be a terrible blow to FOSS.
> It's an impressive run, but the ground has shifted, slowly, under our feet, and now Unix/Linux are no longer a good fit.
Unix is still a good fit for a kernel; e.g. it is used by Apple. The stuff built on top of the kernel (UI, etc.) can change, of course.
Unix is still a good fit for a kernel; e.g. it is used by Apple. The stuff built on top of the kernel (UI, etc.) can change, of course.
Windows NT has far more advanced facilities for async I/O [1].
[1] https://stackoverflow.com/questions/5283032/i-o-completion-p...
[1] https://stackoverflow.com/questions/5283032/i-o-completion-p...
It did, then io_uring leapfrogged it, and now Windows is moving towards adding a ring-based IO submission system: https://windows-internals.com/i-o-rings-when-one-i-o-operati...
> Unix is still a good fit for a kernel; e.g. it is used by Apple.
The POSIX APIs are not a good basis for designing a kernel. There are plenty of areas where it's widely agreed that the APIs are fundamentally utter garbage: POSIX signals, filesystem ACLs, async I/O, select, IPC. Arguably even some of the more less garbage APIs (e.g., regular filesystem calls) are extremely detrimental towards writing good software--imagine if we had filesystem APIs based on semantics such as "atomic file write" or "append-only files" (that guaranteed that a reader would only see old or new versions, not partly-written versions) instead of what we have now, where people attempt to recreate those APIs in userspace.
The POSIX APIs are not a good basis for designing a kernel. There are plenty of areas where it's widely agreed that the APIs are fundamentally utter garbage: POSIX signals, filesystem ACLs, async I/O, select, IPC. Arguably even some of the more less garbage APIs (e.g., regular filesystem calls) are extremely detrimental towards writing good software--imagine if we had filesystem APIs based on semantics such as "atomic file write" or "append-only files" (that guaranteed that a reader would only see old or new versions, not partly-written versions) instead of what we have now, where people attempt to recreate those APIs in userspace.
UNIX as used in macOS isn't the classical UNIX kernel, and since the last 5 years Apple has been moving away from it.
Want the new networking APIs? They are exposed only to platform frameworks not POSIX.
Want the new networking APIs? They are exposed only to platform frameworks not POSIX.
Given that Fuchsia is not GPL licensed (making proprietary forks possible & likely) and apparently developed behind closed doors, not by a self sustained community like the Linux kernel its not very far from your worst case scenario, especially if Google starts force feeding it into Android like it did with many non GPL and proprietary licensed software over the years.
I wonder how much GPL actually protects against proprietary forks. Aren’t most of these driver vendors in China where Google would have little recourse if GPL is violated?
Well, at least it makes major vendors cooperate - for example a lot of modern Sony PlayStation hardware runs heavily modified FreeBSD, yet anything the project ever got back from Sony is IIRC some multiprocessing improvement patches.
Also the multitude of companies contributing together to the Linux kernel are often direct competitors. Yet due to the GPL all their contributions are available to everyone else - so even though you are technically helping your competition, they have to do the same thing for you.
With permissive license, you competition can take the code and run with it, never contributing anything back, kinda like how Sony did in the example above.
Also the multitude of companies contributing together to the Linux kernel are often direct competitors. Yet due to the GPL all their contributions are available to everyone else - so even though you are technically helping your competition, they have to do the same thing for you.
With permissive license, you competition can take the code and run with it, never contributing anything back, kinda like how Sony did in the example above.
It's worth noting that Nest is using (likely heavily customized) Linux, pretty hard to keep sync with the upstream due to its monolithic kernel architecture while doesn't get aggressive investments like Android. But lifespan expectation for those products is much longer (~10 yrs) than typical smartphones (3~5 yrs) which leads to more maintenance headaches as Google accumulates their product portfolio, even compared to Android
And... Even notorious Google couldn't completely pull their hands from Nest Secure although they decided to discontinue its production and sales. This is probably the problem they want to solve with Fuchsia. In this context, using Fuchsia is a pretty natural engineering decision. Fuchsia team can onboard its first customer while Nest team can outsource lots of its maintenance issues to a more appropriate team. I guess they already consider using Android before, but probably that's a no-go option since its support usually ends before 5 years.
Of course, Android and Chrome OS have completely different needs and environments, so I don't expect them to converge to Fuchsia in any foreseeable future. More likely scenario would be a shared ecosystem based on Play Store which enables more future strategic movements.
And... Even notorious Google couldn't completely pull their hands from Nest Secure although they decided to discontinue its production and sales. This is probably the problem they want to solve with Fuchsia. In this context, using Fuchsia is a pretty natural engineering decision. Fuchsia team can onboard its first customer while Nest team can outsource lots of its maintenance issues to a more appropriate team. I guess they already consider using Android before, but probably that's a no-go option since its support usually ends before 5 years.
Of course, Android and Chrome OS have completely different needs and environments, so I don't expect them to converge to Fuchsia in any foreseeable future. More likely scenario would be a shared ecosystem based on Play Store which enables more future strategic movements.
Capability Based Security is a proven solution to computer security problems that arose in the Viet Nam conflict. Those problems keep cropping up here almost daily.
The simple truth is that access control lists aren't up to the task of protecting systems with persistent internet connections and mobile code. A Windows or Linux machine can not ever be made secure.
A microkernel, with the smallest possible attack surface, that never trusts driver code is the way forward. I don't care if the eventual winner is Fuchsia or Genode, all I want is momentum forward out of the morass that is the current Linux/Windows world.
I look forward to trying out Fuchsia and Genode in the next few months, and porting a Forth interpreter to each.
The simple truth is that access control lists aren't up to the task of protecting systems with persistent internet connections and mobile code. A Windows or Linux machine can not ever be made secure.
A microkernel, with the smallest possible attack surface, that never trusts driver code is the way forward. I don't care if the eventual winner is Fuchsia or Genode, all I want is momentum forward out of the morass that is the current Linux/Windows world.
I look forward to trying out Fuchsia and Genode in the next few months, and porting a Forth interpreter to each.
What does the "Viet Nam conflict" have to do with capability-based security?
I suspect a combination of
1) the US military having extensively studied this problem already.
2) that they did it a very long time ago.
Due to possible enemy infiltration of our computer systems and spy networks, there were multiple levels of secret data that had to be coordinated to allow airstrikes (one level of secret information) to avoid enemy radar(a different level of secrets).
The location of enemy radar sites was very tightly held information, as knowing what we knew could reveal means and sources of information. The actual airstrikes would eventually be known by the destruction of enemy targets. It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand.
The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.
The location of enemy radar sites was very tightly held information, as knowing what we knew could reveal means and sources of information. The actual airstrikes would eventually be known by the destruction of enemy targets. It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand.
The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.
> It wasn't possible at the time to have a computer system which could allow the mixing of these levels of secrecy. This meant everything had to be done by hand.
> The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.
BTW, this stuff is not just for Air Force folks, either. Multi-level security is the most principled approach around to efficiently mitigate pervasive information-disclosure vulnerabilities like Spectre. The current approach to mitigation has us flushing speculation contexts down the drain even when sensitive info is provably not at stake, which is wildly inefficient compared to what's theoretically possible.
> The development of Multilevel Secure systems by the Air Force in the 1970s is a direct result of that experience.
BTW, this stuff is not just for Air Force folks, either. Multi-level security is the most principled approach around to efficiently mitigate pervasive information-disclosure vulnerabilities like Spectre. The current approach to mitigation has us flushing speculation contexts down the drain even when sensitive info is provably not at stake, which is wildly inefficient compared to what's theoretically possible.
I imagine it's a reference to https://blogs.tedneward.com/post/the-vietnam-of-computer-sci...
Interesting tangent, but no... not that.
I share your feeling, but I'd rather have a none isolated driver I can trust than an isolated one I cannot trust. My threat model includes fishy OEM doing borderline things.
In driver development I often see abstraction violations or very loose abstractions: news hw capabilities can't be accounted for when designing framework abstractions.
I have never done dev on windows, but I guess there is a reason why the form factor of things running windows is pretty limited. I don't see how you can have fixed interfaces in an ever evolving wold.
In driver development I often see abstraction violations or very loose abstractions: news hw capabilities can't be accounted for when designing framework abstractions.
I have never done dev on windows, but I guess there is a reason why the form factor of things running windows is pretty limited. I don't see how you can have fixed interfaces in an ever evolving wold.
> I'd rather have a none isolated driver I can trust
We all would, but that doesn't seem practical given the market dynamics explained elsewhere in this thread.
We all would, but that doesn't seem practical given the market dynamics explained elsewhere in this thread.
Many years ago, I interned at Google and a very wise mentor of mine explained Google to me in a way that has stuck with me.
"Google discovered a hose that money poured out of. It's called 'online advertising'. All that we do now is find ways to make that hose go faster, and desperately search for another hose."
Why does Google develop 3+ different OS's? In case one of them is a money hose. Why has Google created thousands of products, only to cancel most of them once people fell in love? Because they decided that they weren't money hoses.
"Google discovered a hose that money poured out of. It's called 'online advertising'. All that we do now is find ways to make that hose go faster, and desperately search for another hose."
Why does Google develop 3+ different OS's? In case one of them is a money hose. Why has Google created thousands of products, only to cancel most of them once people fell in love? Because they decided that they weren't money hoses.
> All that we do now is find ways to make that hose go faster, and desperately search for another hose.
There’s one other thing Google does a lot of: try to foresee and actively forestall how someone else might cut-off or divert the flow to the existing hose. While both Chrome and Android evolved in directions that explored potential new hoses, they were clearly both initially directed at protecting the existing hose from being choked off or diverted by monopolies on the client side; Android was purchased and engineered to prevent Apple gaining the kind of dominance in mobile to do that, Chrome and Chrome OS against the desktop Windows monopoly and IE.
Google+ was deployed against Facebook and abandoned once it was clear that Facebook’s position, while making it something of a competitor for ad dollars, wasn’t, even without a competitive Google alternative, an existential threat to Google’s money hose.
There’s one other thing Google does a lot of: try to foresee and actively forestall how someone else might cut-off or divert the flow to the existing hose. While both Chrome and Android evolved in directions that explored potential new hoses, they were clearly both initially directed at protecting the existing hose from being choked off or diverted by monopolies on the client side; Android was purchased and engineered to prevent Apple gaining the kind of dominance in mobile to do that, Chrome and Chrome OS against the desktop Windows monopoly and IE.
Google+ was deployed against Facebook and abandoned once it was clear that Facebook’s position, while making it something of a competitor for ad dollars, wasn’t, even without a competitive Google alternative, an existential threat to Google’s money hose.
This is the big one that people forget. Android itself isn't there to force tracking and marketing on users. It's there to prevent somebody else from controlling mobile devices and being a gatekeeper between Google's services and users. As long as nobody else can prevent Google from reaching users, Google doesn't care that people can run Android without Google services.
In practice, poor development practices and incompetent product management has left some bits hard to change. The search provider used to be hardcoded with no way for the user to override it. That only changed when some early Android phones began shipping with Bing as the default. To this day, it is impossible to allow any non-system app store to update apps in the background. This hasn't changed only because Amazon, Samsung, and many other OEMs failed to get developer traction with their own app stores. Now that there are antitrust rumblings, Google has hinted they will finally fix this, but once again, this isn't a threat to the core Android strategy of removing gatekeepers.
In practice, poor development practices and incompetent product management has left some bits hard to change. The search provider used to be hardcoded with no way for the user to override it. That only changed when some early Android phones began shipping with Bing as the default. To this day, it is impossible to allow any non-system app store to update apps in the background. This hasn't changed only because Amazon, Samsung, and many other OEMs failed to get developer traction with their own app stores. Now that there are antitrust rumblings, Google has hinted they will finally fix this, but once again, this isn't a threat to the core Android strategy of removing gatekeepers.
> Android itself isn't there to force tracking and marketing on users. It's there to prevent somebody else from controlling mobile devices and being a gatekeeper between Google's services and users.
It can be, and is, both.
It can be, and is, both.
If that were the case, it would require more data collection than competitors and force ads. Instead, you can trivially get your location on Android devices (even those sold by Google) without telling Google. You cannot on iOS. You can install apps on your Android device without telling Google. You can develop apps for your own device without telling Google. To do any of these things on iOS requires exploiting a vulnerability.
Similarly, Google doesn't give itself a privileged separate settings for marketing data collection that ignore global settings. https://support.apple.com/en-us/HT202074
If the point of Android were data collection and marketing, Google would abuse configurability of data collection at least as much as Apple does, but it does not, not even on devices that Google itself sells.
Similarly, Google doesn't give itself a privileged separate settings for marketing data collection that ignore global settings. https://support.apple.com/en-us/HT202074
If the point of Android were data collection and marketing, Google would abuse configurability of data collection at least as much as Apple does, but it does not, not even on devices that Google itself sells.
Google Play Services is essential for most features a user would expect in a modern mobile phone. For running bank apps (SafetyNet), many maps apps or apps that include maps (eg Uber, Tinder - due to Google Maps API), push notifications, etc. It's absolutely used to lock-in users to the Google ecosystem and discourage them from degoogling.
Those are services that can be provided by others on any Android device, including those sold by Google. The fact that others aren't providing those services doesn't mean Android itself is meant to lock in users (or to collect data / serve ads), only that others haven't found a reason to provide those services. Google also provides many of those services on other OSes it does not develop (e.g., Chrome push notifications and Widevine).
nit: Android was purchased before the iPhone was announced.
Yep, the reality is that it was more likely a defensive play against Microsoft. At the time (mid-2005) it seemed most likely that Windows Mobile would eventually take over, and Android's strategy was taken from the Windows Desktop playbook.
Google had to postpone Android phones once iPhone launched because Google realized how badly they'd misjudged smartphones, particularly on-screen keyboards & multi-touch (& thinking that their primary competitor was Microsoft and Nokia & not Apple). It's actually a testament to the leadership that they managed to recognize that Apple was the 800lb gorilla here so quickly (which clearly wasn't obvious to other competitors in the space).
https://venturebeat.com/2008/08/07/first-android-phones-push...
https://venturebeat.com/2008/08/07/first-android-phones-push...
> which clearly wasn't obvious to other competitors in the space
I had a family friend that was a tech writer in 2007 or so. He proudly mocked my interest in the first iPhone. Pulling me aside and showing me how his blackberry had a mini trackball and a mouse cursor and just how precise this all was.
It’s obviously funny now, but yea I remember a lot of the “smart money” was against the modern smartphone at the time.
I had a family friend that was a tech writer in 2007 or so. He proudly mocked my interest in the first iPhone. Pulling me aside and showing me how his blackberry had a mini trackball and a mouse cursor and just how precise this all was.
It’s obviously funny now, but yea I remember a lot of the “smart money” was against the modern smartphone at the time.
Also, Google's internal politics are kind of broken. It's my understanding that a lot of the product launches and cancellations are a consequence of an internal culture that rewards launching new products, but not maintaining or improving them.
As I understand it, higher level promotions require a portfolio be compiled and submitted to an anonymous review board. A successful product launch is one of the most valuable additions to these packets.
This has two logistical consequences: 1 - it's more valuable to launch a new product that it is to successfully maintain/grow a current one. 2 - the person running these new projects tends to get promoted away, leaving it rudderless.
Google could change all this overnight by restructuring what these review boards prioritize.
This has two logistical consequences: 1 - it's more valuable to launch a new product that it is to successfully maintain/grow a current one. 2 - the person running these new projects tends to get promoted away, leaving it rudderless.
Google could change all this overnight by restructuring what these review boards prioritize.
If a solution is that simple, why hasn't it been done? Also, the head of Android has become the CEO, and Android is still not rudderless.
Identifying a good change and actually implementing it in a massive organization are two wildly different things.
> product launches and cancellations are a consequence of an internal culture that rewards launching new products, but not maintaining or improving them
This is very stale information at this point. Product launches are now pretty heavily gated, and promotion criteria are far less based on launches than on overall impact, including but not limited to improving/maintaining products.
(Googler but interpretation is my own)
This is very stale information at this point. Product launches are now pretty heavily gated, and promotion criteria are far less based on launches than on overall impact, including but not limited to improving/maintaining products.
(Googler but interpretation is my own)
I think that depends where you are. There's a lot of lip-service being paid, but from what I've seen, it's mostly translated to talking about _landings_ rather than _launchings_, which isn't much of a change.
(Also a Googler.)
(Also a Googler.)
I think landings allows for a much broader scope of accomplishments. For example, if refactor an entire system for demonstrably better maintainability and efficiency, that's a landing, but not a launch.
I suspect that this is a consequence of the above problem. Something that's pretty successful and growing at a pretty good clip is not a giant spigot of money, and therefore it's effectively useless to Google. Maintaining it requires programmers that could be better put to searching for the next spigot.
People always say this on HN, and while it’s definitely a viable explanation for why Google so often cans projects that are well-loved, I’m finding it harder to believe the more I think about it. If all of us on the outside are so aware of this fact about Google’s culture, surely someone with sway has heard about it, and taken steps to fix it. I’m sure Google are well aware of the perception that they’re always getting rid of products, and would like to fix that. So if the explanation was just that the culture doesn’t reward maintaining existing projects, I’m sure we would have heard something about a corporate incentive to maintain stuff.
I hate the word, but if there's one thing google has it's analytics - data. They can tell if something is growing or dying. I'm guessing they could even tell youtube was growing before they bought it. But seeing an upward trend seems easier than seeing a flat line and deciding it can't be turned into an upward trend.
How about this explanation instead: Google doesn't actually have a habit of canceling projects that are well-loved?
If you don't believe it, try selecting 10 of their supposedly killed products at random. Had you honestly heard of them ever before? Do they look like something that would have had a significant user base? Hell, do they even look like they were actual products?
If you don't believe it, try selecting 10 of their supposedly killed products at random. Had you honestly heard of them ever before? Do they look like something that would have had a significant user base? Hell, do they even look like they were actual products?
> So if the explanation was just that the culture doesn’t reward maintaining existing projects, I’m sure we would have heard something about a corporate incentive to maintain stuff.
So, two things:
1) Changing culture is really hard, especially at a company the size of Google, and
2) Even if they could change the culture, it's possible they simply don't care or they believe the benefits outweigh the cost.
So, two things:
1) Changing culture is really hard, especially at a company the size of Google, and
2) Even if they could change the culture, it's possible they simply don't care or they believe the benefits outweigh the cost.
People say this all the time about every company. For many this is true, when seen from the narrow perspective of an individual. However for the only metric that people care about (stock price and profit) Google’s system is incredibly successful. Higher ups will not dictate changes like this if the company is successful. Culture change at the macro level only happens when the company is spiraling at the macro level.
This is also typical of mismanaged governments:
Always building new infrastructure, and not maintaining the existing one.
Always building new infrastructure, and not maintaining the existing one.
Neither OP or GP have it right - Fuchsia isn't a "3rd OS", it's a kernel, like Linux, except MIT. Maintenance is most certainly rewarded, at least in the 5 years I've been at Google
Actually, it is a 3rd OS named Fuchsia, which uses a custom kernel called Zircon which is MIT.
"Zircon is the core platform that powers Fuchsia. Zircon is composed of a kernel (source in /zircon/kernel) as well as a small set of userspace services, drivers, and libraries (source in /zircon/system/) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation."
- Fuchsia Docs, https://fuchsia.dev/fuchsia-src/concepts/kernel
"Zircon is the core platform that powers Fuchsia. Zircon is composed of a kernel (source in /zircon/kernel) as well as a small set of userspace services, drivers, and libraries (source in /zircon/system/) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation."
- Fuchsia Docs, https://fuchsia.dev/fuchsia-src/concepts/kernel
Eh. If you've been at Google for 5 years then you should recognize Fuchsia as another one of the "retention projects" where you get paid to twiddle away at something cool in the corner and your only real deliverable is not going to work for Facebook or Apple.
Sometimes they stumble upon something another PA needs, but often it just ends up as a patent or research paper.
Sometimes they stumble upon something another PA needs, but often it just ends up as a patent or research paper.
Why would Google pay employees to not go to Apple?
Because Google has infinite money, the execs just hire people so they can admire the zoo of smart people they've built. Why do they need Vint Cerf, Guido, and Rob Pike? Why are they on the MIDI board? Because there's no real reason not to.
I don't have an opinion either way on your position here, other than a fact check.
Guido van Rossum (creator of Python) is a Distinguished Engineer at Microsoft. Before that, he worked at Dropbox.
Guido van Rossum (creator of Python) is a Distinguished Engineer at Microsoft. Before that, he worked at Dropbox.
Before that, he was at Google. Failing to retain an employee doesn't invalidate that Google would rather they didn't leave.
I get the quarterly check-ins from the "alumni recruiting" team, and can assume Guido does too.
I get the quarterly check-ins from the "alumni recruiting" team, and can assume Guido does too.
Guido hasn't been at Google since 2013
The only competition for the giants are the other giants.
Who can divert from Google's massive ad income funnel?
Apple.
Facebook.
(Also maybe several foreign governments' antitrust cases.)
An engineer on your payroll is an engineer not on the competition's payroll.
Who can divert from Google's massive ad income funnel?
Apple.
Facebook.
(Also maybe several foreign governments' antitrust cases.)
An engineer on your payroll is an engineer not on the competition's payroll.
Facebook or Apple? Not Amazon or Microsoft?
refulgentis(2)
This seems like a pretty flawed strategy to me. Lots of improbable products turned into multi-billion dollar companies. Tiny videos set to music, watching other people play video games, liking pictures of food, and so on. It seems to me that it's less about the product and more about the execution. There are lots of Google products that could have taken off if they had been iterated instead of abandoned. Take Apple as one example. They develop a product vision, then spend several versions refining the thing till it goes from a curiosity to a must have. Or look at Facebook with Oculus, they had a vision and released headset after headset, till they found a feature set that had the user engagement metrics they were looking for. They didn't just give up once the Gear VR proved to be a dead-end, which is exactly what Google did with their VR efforts and then cleanly missed the boat Oculus is on now with the Quest.
Isn't that most private companies ?
Searching for sources of income ?
Searching for sources of income ?
No, most private companies are not monopolies (although many would not mind I guess).
It seems online advertising has a strong network effect[1], where website owners use Google ads because that's where most advertisers are and advertisers use Google ads because it has most reach (and therefore tracking). This naturally creates a monopoly, just like with Facebook, twitter, LinkedIn, AirBnB, Uber etc.
[1] https://en.wikipedia.org/wiki/Network_effect
It seems online advertising has a strong network effect[1], where website owners use Google ads because that's where most advertisers are and advertisers use Google ads because it has most reach (and therefore tracking). This naturally creates a monopoly, just like with Facebook, twitter, LinkedIn, AirBnB, Uber etc.
[1] https://en.wikipedia.org/wiki/Network_effect
How exactly does a random piece of IoT junk that looks like it could come from any single one of countless fly-by-night manufacturers in Shenzen (namely the "Nest Hub" that's now running some version of Fuchsia, per the OP) turn into a money-making firehose for Google? Just curious, because I'm having trouble seeing how this could make sense.
The problem is that many good ideas only look good in hindsight.
In 15 years, we'll either say "Fuchsia was a brilliant move, I'm so glad my home runs on that OS" or we'll say "Remember Fuchsia? lol".
Here's what I mean. Acquisitions by Google in 2005: Reqwireless (mobile ads, merged with google analytics); Dodgeball (social networking, later Google Latitude); Akwan (Search tech); Skia (graphics library); Phatbits (Google Desktop); allPAY (???); bruNET (???); Android (cheap OS for mobile devices).
In 2005, which of these were going to change the world?
In 15 years, we'll either say "Fuchsia was a brilliant move, I'm so glad my home runs on that OS" or we'll say "Remember Fuchsia? lol".
Here's what I mean. Acquisitions by Google in 2005: Reqwireless (mobile ads, merged with google analytics); Dodgeball (social networking, later Google Latitude); Akwan (Search tech); Skia (graphics library); Phatbits (Google Desktop); allPAY (???); bruNET (???); Android (cheap OS for mobile devices).
In 2005, which of these were going to change the world?
Advertising/influence depends on two things:
1) Knowing what you're thinking (e.g. the search request you speak to your Nest Hub)
2) Presenting messages to you (e.g. displaying search results/suggestions/ads on the Nest Hub screen in your home)
Gee, how could the entry point to all the devices around you ever become a money making firehose?
> Google develop 3+ different OS's?
It wont. From what I understand this new OS will replace others over time. Also it is way better than existing options.
It wont. From what I understand this new OS will replace others over time. Also it is way better than existing options.
I am not a microkernel expert, but why is Zircon better than QNX as used in the final Blackberry handset?
QNX appears to already be in every market where Fuchsia wants to go.
Google could have bought Blackberry and used QNX in Android 5, rolling it up to Chromebooks. Why was this not the path they chose?
QNX appears to already be in every market where Fuchsia wants to go.
Google could have bought Blackberry and used QNX in Android 5, rolling it up to Chromebooks. Why was this not the path they chose?
This seems like a good question, and I also hope someone with good knowledge/experience around this to give some good comparison.
I have given only very cursory look into QNX and Fuchsia/Zircon and it seems that one of the main difference is the capabilities-based architecture in Fuchsia. It's a big change in the API/conceptual model, but we'll have to see if that actually translates into a meaningful difference at the application level - e.g. whether it allows building new types of applications, or allows building meaningfully more secure/fast/reliable applications.
I have given only very cursory look into QNX and Fuchsia/Zircon and it seems that one of the main difference is the capabilities-based architecture in Fuchsia. It's a big change in the API/conceptual model, but we'll have to see if that actually translates into a meaningful difference at the application level - e.g. whether it allows building new types of applications, or allows building meaningfully more secure/fast/reliable applications.
That's a wild leap with zero evidence. Fuchsia runs on one unimportant production device and has basically zero usage. Saying it will replace all of Android and ChromeOS is...optimistic to say the least.
Project ‘Fuchsia’: Google Is Quietly Working on a Successor to Android
https://www.bloomberg.com/news/articles/2018-07-19/google-te...
> For more than two years, a small and stealthy group of engineers within Google has been working on software that they hope will eventually replace Android.
https://news.ycombinator.com/item?id=19702968
> "And while Android is reaching EOL in the next 4-5 years, most of this work will be carried on in Fuchsia OS, which is set to eventually replace Android"
> For more than two years, a small and stealthy group of engineers within Google has been working on software that they hope will eventually replace Android.
https://news.ycombinator.com/item?id=19702968
> "And while Android is reaching EOL in the next 4-5 years, most of this work will be carried on in Fuchsia OS, which is set to eventually replace Android"
> "And while Android is reaching EOL in the next 4-5 years"
I wouldn't bet on it. Sounds like IBM OS2 all over again.
I wouldn't bet on it. Sounds like IBM OS2 all over again.
Check the context. The person I replied to is claiming there's "zero evidence" Fuchsia will replace other Google OSs which is obviously wrong.
May be. We have not seen future. But that is not the point and a person who is claiming there is "zero evidence" is mistaking absence of evidence to evidence of absence. Arsetechnica has published several articles on this topic in past and are available to read on Wikiepedia page for the OS.
General information suggests this is one of those long term things if successful would be massively game changing.
General information suggests this is one of those long term things if successful would be massively game changing.
Better than all existing options? I'm skeptical that a kernel written in C++ is likely to be better than e.g. a formally verified microkernel such as seL4. If they ever rewrite it in Rust, then it might be more interesting.
Parts of it is already in Rust and formal verification could be done for this project as well. At that stage would you be ok with it?
If it improves the security of the device and means that Google will keep updating it, then that will be good. However, personally I have given up buying Google-branded devices. They only gave me security updates for my Pixel C for three years (2016-2019).
This would be another benefit of antitrust scrutiny for the tech giants.
They're not innovating at this point. They're twiddling thumbs.
If we broke up Apple, Google, Facebook, and Amazon, then they'd be forced to fight for survival.
Struggle births innovation.
They're not innovating at this point. They're twiddling thumbs.
If we broke up Apple, Google, Facebook, and Amazon, then they'd be forced to fight for survival.
Struggle births innovation.
I think this is great! Obviously Google has been working on porting Fuchsia to the Nest Hub for a while and I think they made the right call by deploying it to this kind of device first. They will get more users to test it in real life scenarios. At the same time, it's not a device that people use in mission critical situation, so if there's issues, it won't cause an uproar.
I could see the rest of their portfolio migrating to Fuchsia OS eventually, including both Chrome OS and Android.
I could see the rest of their portfolio migrating to Fuchsia OS eventually, including both Chrome OS and Android.
I hope that performance is improved. The experience of using the Google Home Hub UI is quite bad. It looks slick and modern until you touch it, and then it feels like a car nav system display from 10 years ago. The frame rate is in the single digits. All the modern swoopy animations are wasted because the device can barely manage to display two or three frames before the animation is over. And the touch latency is off the charts.
It's inexcusably bad. I mean, the hardware was purpose built for this software. They should have designed the software to meet the constraints of the hardware they knew they were shipping on. And it's plugged into the wall with a big form factor so performance should be better than phones where power consumption and heat dissipation are much more constraining.
It's inexcusably bad. I mean, the hardware was purpose built for this software. They should have designed the software to meet the constraints of the hardware they knew they were shipping on. And it's plugged into the wall with a big form factor so performance should be better than phones where power consumption and heat dissipation are much more constraining.
It would be really interesting if someone could benchmark the performance before and after the transition.
Possibly unpopular opinion:
This is a tragedy for Free Software. The Linux kernel (and specifically its GPL nature) is the best thing that has ever happened to Free Software drivers and embedded systems. The only reason that companies release open source drivers for their products is because they are legally required to in order integrate with the Linux kernel. Clearly Google wants to move away from this world.
I will mourn the day that a non-copyleft kernel supplants Linux and our only reason for free software hardware support comes to and end.
This is a tragedy for Free Software. The Linux kernel (and specifically its GPL nature) is the best thing that has ever happened to Free Software drivers and embedded systems. The only reason that companies release open source drivers for their products is because they are legally required to in order integrate with the Linux kernel. Clearly Google wants to move away from this world.
I will mourn the day that a non-copyleft kernel supplants Linux and our only reason for free software hardware support comes to and end.
I think you give some valid concerns. I definitely understand you, but I want to give some counter arguments to where I'm seeing chances with Fuchsia in addition to the dangers that you rightfully point out.
First, there are thriving non-copyleft driver projects, like mesa. No copyleft forces Intel to contribute to it. No copyleft forces AMD.
Second, even in Linux, many drivers aren't maintained by their vendors, but third parties. I think that an upstream driver is generally easier to deal with for most parties, so most parties would prefer it. If fuchsia is indeed as modular as it promises to be, users can swap out those drivers, at least in custom ROMs. Android custom ROMs already copy over proprietary drivers from the native OS upon installation.
Third, the GCC compiler has artificially restricted the ability to use it as a backend for third party languages, which led to many projects choosing LLVM instead. These projects now contribute to LLVM's success. Yes, some extensions to LLVM are proprietary. Still many companies contribute to LLVM directly.
Fourth, legal action doesn't turn a company into a good citizen. They might release the source code in the end but they become extremely hostile to free software projects coming forward, because suddenly the legal department got involved. Those employees who share the cause can't freely talk on mailing lists any more because all mails to the project first require approval by a company lawyer. Etc. The released source code might be unusable anyways because it's done to a fork of an outdated version of the kernel.
First, there are thriving non-copyleft driver projects, like mesa. No copyleft forces Intel to contribute to it. No copyleft forces AMD.
Second, even in Linux, many drivers aren't maintained by their vendors, but third parties. I think that an upstream driver is generally easier to deal with for most parties, so most parties would prefer it. If fuchsia is indeed as modular as it promises to be, users can swap out those drivers, at least in custom ROMs. Android custom ROMs already copy over proprietary drivers from the native OS upon installation.
Third, the GCC compiler has artificially restricted the ability to use it as a backend for third party languages, which led to many projects choosing LLVM instead. These projects now contribute to LLVM's success. Yes, some extensions to LLVM are proprietary. Still many companies contribute to LLVM directly.
Fourth, legal action doesn't turn a company into a good citizen. They might release the source code in the end but they become extremely hostile to free software projects coming forward, because suddenly the legal department got involved. Those employees who share the cause can't freely talk on mailing lists any more because all mails to the project first require approval by a company lawyer. Etc. The released source code might be unusable anyways because it's done to a fork of an outdated version of the kernel.
> First, there are thriving non-copyleft driver projects, like mesa. No copyleft forces Intel to contribute to it. No copyleft forces AMD.
This is not entirely true. Mainline Linux has a longstanding policy of not including kernel-side graphics support in the officially-released tree unless it can be used with a totally Free userspace. So Mesa is, to some extent, piggybacking on incentives that have been established as part of the GPL'd Linux kernel.
This is not entirely true. Mainline Linux has a longstanding policy of not including kernel-side graphics support in the officially-released tree unless it can be used with a totally Free userspace. So Mesa is, to some extent, piggybacking on incentives that have been established as part of the GPL'd Linux kernel.
Linux only happened because Microsoft didn't care to put much love on their POSIX subsystem for Windows NT, and BSD was busy fighting AT&T.
Looking at the pleothora of BSD/Apache/MIT OSes appearing for embeeded devices it is clear what the future of Linux will become, when the generation that gave birth to it is gone.
Looking at the pleothora of BSD/Apache/MIT OSes appearing for embeeded devices it is clear what the future of Linux will become, when the generation that gave birth to it is gone.
I disagree. One of the things that stops people from actually using Linux is that it is so hard to get devices working properly.
I would be willing to accept some closed source drivers if it meant Linux actually worked reliably on most modern hardware (no it really doesn't).
I would be willing to accept some closed source drivers if it meant Linux actually worked reliably on most modern hardware (no it really doesn't).
This is also why Android is such a security and privacy nightmare, with the terrible user experience (and environmental impact) of having to buy a new phone every 1-2 years.
Because Android is not GPL.
Google owns the software, so manufacturers really only make money from the device sales, and bundled spyware.
Because Android is not GPL.
Google owns the software, so manufacturers really only make money from the device sales, and bundled spyware.
You don't need a new Android phone every two years and you haven't needed to for a while now. The Android situation certainly isn't as good as the Apple situation, but it's not as bad as ten years ago.
For most people, the only problem using a five year old phone today is the degraded battery. Almost all software is backwards compatible with the old operating systems and nobody simply outside IT cares about kernel updates. Journalists, human rights activists and American refugees like Snowden should fear kernel exploits, your average Joe is pretty unlikely to actually get infected. The massive segregation of Android devices is actually a good thing in this scenario, because you need to prepare your exploits for whole ranges of devices and several versions software versions, making "the Android botnet that ends all Android botnets" incredibly hard to build.
The Android privacy nightmare is all Google being built around spying; the security nightmare is mostly due to brands like Samsung not releasing timely updates, not necessarily because Broadcom and Qualcom don't build patches.
With medium to high end Samsung devices now reaching four years of Android security updates, the entire field is slowly becoming much better. The cheaper, low-end devices lag behind, but it figures that people who cannot afford a $300 phone can't pay for software support and the profit margins become razor thin the cheaper the phone gets. Five years of software updates for a $90 phone just isn't realistic.
This whole situation is why I lament Windows Phone's failure. Microsoft had the right idea, which carriers hated, that the operating system should be independent of the rest of the device. Carriers wanted to force their ugly branding everywhere and fought hard against MS, who themselves bumbled and failed spectacularly by breaking backwards compatibility with every major Windows Phone release, and the entire project was doomed to fail.
Android could have been similar to Linux; a Google-supported core repository with vendor packages for drivers, updatable in the same way Debian is. Nobody outside the hacker community seems interested in this approach, but it could have been.
For most people, the only problem using a five year old phone today is the degraded battery. Almost all software is backwards compatible with the old operating systems and nobody simply outside IT cares about kernel updates. Journalists, human rights activists and American refugees like Snowden should fear kernel exploits, your average Joe is pretty unlikely to actually get infected. The massive segregation of Android devices is actually a good thing in this scenario, because you need to prepare your exploits for whole ranges of devices and several versions software versions, making "the Android botnet that ends all Android botnets" incredibly hard to build.
The Android privacy nightmare is all Google being built around spying; the security nightmare is mostly due to brands like Samsung not releasing timely updates, not necessarily because Broadcom and Qualcom don't build patches.
With medium to high end Samsung devices now reaching four years of Android security updates, the entire field is slowly becoming much better. The cheaper, low-end devices lag behind, but it figures that people who cannot afford a $300 phone can't pay for software support and the profit margins become razor thin the cheaper the phone gets. Five years of software updates for a $90 phone just isn't realistic.
This whole situation is why I lament Windows Phone's failure. Microsoft had the right idea, which carriers hated, that the operating system should be independent of the rest of the device. Carriers wanted to force their ugly branding everywhere and fought hard against MS, who themselves bumbled and failed spectacularly by breaking backwards compatibility with every major Windows Phone release, and the entire project was doomed to fail.
Android could have been similar to Linux; a Google-supported core repository with vendor packages for drivers, updatable in the same way Debian is. Nobody outside the hacker community seems interested in this approach, but it could have been.
How is Fuschia licensed?
Fuschia is licensed under the BSD license as far as I can tell.
This allows device vendors to use fuschia without releasing device specific software to the community resulting in further degraded software freedom.
This allows device vendors to use fuschia without releasing device specific software to the community resulting in further degraded software freedom.
It isn't GPL; I believe it is tri-licensed in BSD, MIT, and Apache 2.
Completely true.
Also, the reason so much hardware doesn't have drivers for Linux until after many years, when it has been reverse-engineered.
So, it is both an advantage, and a hindrance.
Also, the reason so much hardware doesn't have drivers for Linux until after many years, when it has been reverse-engineered.
So, it is both an advantage, and a hindrance.
[deleted]
Well if you hang Free Software's hopes entirely on the Linux kernel, or the Linux kernel doesn't mature to the point where it isn't the hall monitor for everyone's code quality, then that might be what happens.
Darwin might be knocking. Evolve or die.
(And its a bit weird that the Linux kernel is so centralized with a cabal lead mostly by one dude who yells at everyone on the planet about their shitty driver code quality. If you're at all Libertarian or libertarian, that should probably bug you a bit that Free Software picked that as the ideal model.)
Darwin might be knocking. Evolve or die.
(And its a bit weird that the Linux kernel is so centralized with a cabal lead mostly by one dude who yells at everyone on the planet about their shitty driver code quality. If you're at all Libertarian or libertarian, that should probably bug you a bit that Free Software picked that as the ideal model.)
The comments on this article are disappointing.
The first major open source kernel since Linux, and somewhat arguably OS X, has been released.
I was looking forward to commentary on that, not blinkered commentary complaining this exists when Android/ChromeOS do already (the error there is Android is a window manager + runtime on top of a kernel, ChromeOS is a window manager) or how performance reviews should be run.
The first major open source kernel since Linux, and somewhat arguably OS X, has been released.
I was looking forward to commentary on that, not blinkered commentary complaining this exists when Android/ChromeOS do already (the error there is Android is a window manager + runtime on top of a kernel, ChromeOS is a window manager) or how performance reviews should be run.
I disagree. The comments, here, give some real meta-insight into how Google is seen in the tech world: As an unreliable partner.
Google has clearly and profoundly lost the confidence of the broader tech community.
In particular, Google's history of starting and cancelling random projects helps explain why people are wondering why Google is releasing Fuschia: without some understanding of their motivations, it's impossible to trust that it'll actually have any kind of extended lifespan.
For all we know, Fuschia, Android, and ChromeOS are basically the OS equivalent of Hangouts, Meet, Allo, and Duo, in which case becoming in any way reliant on it is a huge mistake.
Google has clearly and profoundly lost the confidence of the broader tech community.
In particular, Google's history of starting and cancelling random projects helps explain why people are wondering why Google is releasing Fuschia: without some understanding of their motivations, it's impossible to trust that it'll actually have any kind of extended lifespan.
For all we know, Fuschia, Android, and ChromeOS are basically the OS equivalent of Hangouts, Meet, Allo, and Duo, in which case becoming in any way reliant on it is a huge mistake.
I probably won't reply past this, any thread on Google is a karma sink because it'd require Google users backing me up here but...the analogy completely breaks, immediately.
Hangouts _is_ Meet and Allo, if it weren't for the constant migration notices leading to constant commentary no one would be the wiser, you log into Gmail and chat just like you did 10 years ago.
Duo's a featured product, people go too far and think it's "yet another video chat app", but, they're forgetting Google has to offer both FaceTime _and_ Zoom, it has consumer and corporate customers, the corporate one doesn't need stickers and hats, the consumer one doesn't need meeting links that work in a browser.
Hangouts _is_ Meet and Allo, if it weren't for the constant migration notices leading to constant commentary no one would be the wiser, you log into Gmail and chat just like you did 10 years ago.
Duo's a featured product, people go too far and think it's "yet another video chat app", but, they're forgetting Google has to offer both FaceTime _and_ Zoom, it has consumer and corporate customers, the corporate one doesn't need stickers and hats, the consumer one doesn't need meeting links that work in a browser.
> Hangouts _is_ Meet and Allo, if it weren't for the constant migration notices leading to constant commentary no one would be the wiser,
So, let's say that's true (and bluntly, after the Hangouts EOL notice I just jumped ship entirely to Signal as, frankly, I couldn't be bothered to figure out what the heck Google was doing), and that Allo and Meet--which are marketed as two different products--are somehow seamlessly integrated with the rest of the Google ecosystem so that you didn't actually need to grok the differences.
Assuming that was true, Google still completely botched the communication, and believe it or not, marketing and communication are really damn important. Google could have the greatest technology ever, but they're perceived as being unreliable, and both their words and their actions reinforce that perception.
So, maybe in this specific example, the transition wasn't as traumatic is the flat out cancellation of Reader or Plus. But in the end, the communication was so muddled that it ultimately doesn't matter because to the rest of the world outside the Google bubble it just looks like yet another example of Google being Google.
So, let's say that's true (and bluntly, after the Hangouts EOL notice I just jumped ship entirely to Signal as, frankly, I couldn't be bothered to figure out what the heck Google was doing), and that Allo and Meet--which are marketed as two different products--are somehow seamlessly integrated with the rest of the Google ecosystem so that you didn't actually need to grok the differences.
Assuming that was true, Google still completely botched the communication, and believe it or not, marketing and communication are really damn important. Google could have the greatest technology ever, but they're perceived as being unreliable, and both their words and their actions reinforce that perception.
So, maybe in this specific example, the transition wasn't as traumatic is the flat out cancellation of Reader or Plus. But in the end, the communication was so muddled that it ultimately doesn't matter because to the rest of the world outside the Google bubble it just looks like yet another example of Google being Google.
'...perceived as being unreliable...'
AFAICT, the primary effect is that HN commentary on any google release has approximately zero SNR. Some back-room team could cure cancer and the HN thread would be 90% complaints about Reader. Compare/contrast the vast numbers of dead github projects, dead startups, and dead code generally. (Also, who the fsck calls the cancellation of plus traumatic?? That's comedy gold.)
This is an open source release under the MIT license. You can use it, fork it, or ignore it...
AFAICT, the primary effect is that HN commentary on any google release has approximately zero SNR. Some back-room team could cure cancer and the HN thread would be 90% complaints about Reader. Compare/contrast the vast numbers of dead github projects, dead startups, and dead code generally. (Also, who the fsck calls the cancellation of plus traumatic?? That's comedy gold.)
This is an open source release under the MIT license. You can use it, fork it, or ignore it...
At best, it'll be something others will be able to leverage and make forks out of, and thanks to its permissive license, they won't have that pesky requirement to make the source code of their fork available. At worst, it'll be yet another product abandoned in a couple years by Google because it failed to meet some ludicrous goals that are out of reach for 99% of the companies in the world anyway. Such is the way people see Google nowadays, and can you really blame us?
> The first major open source kernel since Linux, and somewhat arguably OS X, has been released.
Depending on your definitions, OpenSolaris and Redox would object. And it's open sourced in a way that's designed to support making proprietary products, so you'll forgive my not really celebrating.
Depending on your definitions, OpenSolaris and Redox would object. And it's open sourced in a way that's designed to support making proprietary products, so you'll forgive my not really celebrating.
This makes no sense to me. Why is google building it? They want a more stable experience by using a microkernel and pushing everything to the userland? Maybe this will help with updates and vendors letting their devices rot? Or is it something to do with licensing?
Because things have changed since the time Linux became ubiquitous.
We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing (no shared memory, no shared filesystem), capabilities, new and extremely aggressive attack vectors, and a need to compartmentalize and virtualize at more fundamental layers even if it comes at a performance penalty.
You can't retrofit a microkernel-like abstraction on top of Linux. At the same time, a lot of the features you need for a shared multi-user system are basically cruft for modern mobile, single-user systems with little use for shared resources (not saying they're not shared; it's just that you can no longer trust apps installed in the user system so expecting apps to behave nicely is out of the window).
The new wave of OSes embraces formal correctness when possible, JIT, garbage-collected application programming languages, tightly-enforced resource boundaries, deny-by-default security models, provably-safe system programming languages (Rust and whatever else will come), immutability and copy-on-write at the cost of filesystem space, and secure memory abstractions for more RAM.
So why spend time supporting features that new OSes don't need, optimizing things that are no longer priority (HDD schedulers vs no-op SSD schedulers), when for once it _is_ actually easier to start over and fixing a lot of traditional pain points?
We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing (no shared memory, no shared filesystem), capabilities, new and extremely aggressive attack vectors, and a need to compartmentalize and virtualize at more fundamental layers even if it comes at a performance penalty.
You can't retrofit a microkernel-like abstraction on top of Linux. At the same time, a lot of the features you need for a shared multi-user system are basically cruft for modern mobile, single-user systems with little use for shared resources (not saying they're not shared; it's just that you can no longer trust apps installed in the user system so expecting apps to behave nicely is out of the window).
The new wave of OSes embraces formal correctness when possible, JIT, garbage-collected application programming languages, tightly-enforced resource boundaries, deny-by-default security models, provably-safe system programming languages (Rust and whatever else will come), immutability and copy-on-write at the cost of filesystem space, and secure memory abstractions for more RAM.
So why spend time supporting features that new OSes don't need, optimizing things that are no longer priority (HDD schedulers vs no-op SSD schedulers), when for once it _is_ actually easier to start over and fixing a lot of traditional pain points?
> We have moved away from a world of shared libraries, filesystems, and UNIX users and permissions into a world of shared-nothing
This is absurd. Fuchsia has all of shared libraries, filesystems, users and permissions. Probably even more of those than Linux.
And while I am a fan of microkernels, I can hardly claim that have become more interesting as of lately. In fact, I would even claim they have become even less interesting, since people are now taking seriously for some reason all the side channel attacks that practically make hardware-enforced privilege separation useless.
This is absurd. Fuchsia has all of shared libraries, filesystems, users and permissions. Probably even more of those than Linux.
And while I am a fan of microkernels, I can hardly claim that have become more interesting as of lately. In fact, I would even claim they have become even less interesting, since people are now taking seriously for some reason all the side channel attacks that practically make hardware-enforced privilege separation useless.
> a lot of the features you need for a shared multi-user system are basically cruft
That's just not true. A "single-user" system running multiple "apps" where each app is actually endowed with its own user-like privileges is just a shared multi-user system by another name. There's no reason not to reuse the existing infrastructure, if perhaps with some tweaks.
That's just not true. A "single-user" system running multiple "apps" where each app is actually endowed with its own user-like privileges is just a shared multi-user system by another name. There's no reason not to reuse the existing infrastructure, if perhaps with some tweaks.
Too many tweaks to be worth it.
To this date we still find bugs in sudo, interactive shells, weird env var interactions from su and inheriting variables. The Unix permissions system is complicated yet insufficient for protecting systems. There are multiple, orthogonal machineries for isolation (jails, chroot, namespaces,SELinux thingies, setuid and sticky bits) and they all interact in horrendous ways that leave huge security gaps.
Just reconsidering their use cases and redoing al lot of that having learned the lessons of the past twenty years is a huge advance.
To this date we still find bugs in sudo, interactive shells, weird env var interactions from su and inheriting variables. The Unix permissions system is complicated yet insufficient for protecting systems. There are multiple, orthogonal machineries for isolation (jails, chroot, namespaces,SELinux thingies, setuid and sticky bits) and they all interact in horrendous ways that leave huge security gaps.
Just reconsidering their use cases and redoing al lot of that having learned the lessons of the past twenty years is a huge advance.
I can't speak as to their motivations specifically, but one of the things that I've noticed from poking around the kernel API is that the kernel APIs are much more coherently designed than the conventional kernels we have are.
In particular, one of the key design goals appears to be a heavy use of a capabilities-enabled handle-based API, even for more conventional syscalls (e.g., mmap). One of the benefits of this approach is that it simplifies a lot more cross-process management stuff; you can inspect (or edit!) another process's memory maps, for example, with the same system call that a process would use to edit its own. It would also enable something like CreateRemoteThread; it would definitely be far easier to write a debugger for Fuchsia than it is for Linux.
In particular, one of the key design goals appears to be a heavy use of a capabilities-enabled handle-based API, even for more conventional syscalls (e.g., mmap). One of the benefits of this approach is that it simplifies a lot more cross-process management stuff; you can inspect (or edit!) another process's memory maps, for example, with the same system call that a process would use to edit its own. It would also enable something like CreateRemoteThread; it would definitely be far easier to write a debugger for Fuchsia than it is for Linux.
Mach/Darwin/iOS has this and I suppose it's nice, but it does break down when you introduce POSIX compatibility, because you have to deal with the less expressive and insecure concepts like pids and file descriptors there.
Os noob here, what’s less expressive / insecure about PIDs or file descriptors?
PIDs and file descriptors are effectively global tables indexed by integers that are reused. This means that you have inherent race conditions: you want to an operation on pid X, but in between the time you decided you want to do it and the time you actually did it, pid X died and a new pid X was created. This is even worse for PIDs, since there's basically nothing you can do to actually have any sort of locking to avoid race conditions.
Linux has PID namespaces now, so it's not global. But yes, the race conditions you describe are real, and can only be addressed via new API's.
Most OS's out there are unsuitable for making appliances, which this seems aimed at.
Right now your choices are a Realtime OS or Linux. Realtime OS don't support making GUIs and Linux has a lot of foot-guns.
Normally, updates to an appliance are one binary blob, this looks to support all of the various pieces having their own blob, and allow the OS to be updated independently from the application binaries, so security updates can happen without the appliance vendor needing to do anything.
Right now your choices are a Realtime OS or Linux. Realtime OS don't support making GUIs and Linux has a lot of foot-guns.
Normally, updates to an appliance are one binary blob, this looks to support all of the various pieces having their own blob, and allow the OS to be updated independently from the application binaries, so security updates can happen without the appliance vendor needing to do anything.
> Realtime OS don't support making GUIs
My three favorite GUI operating systems, putting aside software support, are iOS, BeOS, and... Photon on QNX.
My three favorite GUI operating systems, putting aside software support, are iOS, BeOS, and... Photon on QNX.
QNX is a microkernel RTOS which supported GUIs... but BlackBerry killed off support for using it on the desktop, and BlackBerry phones died out. IDK what else is using QNX technology now.
Cars [0], apparently.
[0] https://blackberry.qnx.com/en/software-solutions/automotive/...
[0] https://blackberry.qnx.com/en/software-solutions/automotive/...
Ford uses QNX for SYNC 3, although they are abandoning it and switching to Android Automotive starting with the 2023 model year.
Good questions, and I don't know the answers, but it is kind of odd (particularly given the pace of change in other areas of computer tech) that the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area.
Of course, Apple is hard at work on iOS, but we don't know what sort of under the cover innovations that might good.
So. I'm glad to see something new.
Of course, Apple is hard at work on iOS, but we don't know what sort of under the cover innovations that might good.
So. I'm glad to see something new.
>the world's most popular operating system was designed so long ago, and it seems like there is so little going on in this area.
Are you talking about Linux, or Android specifically? Either way, I don't really agree that there's "little" going on there.
Are you talking about Linux, or Android specifically? Either way, I don't really agree that there's "little" going on there.
A large investment like this is likely a strategic move.
Perhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.
Perhaps it is a corporate wide move to stop contributing to Linux. Or perhaps they plan on displacing Linux from the computing world.
> Why is google building it?
As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development.
It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.
As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development.
It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.
It's probably preferable than continuing to use the JVM-clone like it's an OS, while porting Linux to be the actual OS to run their JVM-clone OS.
Who needs an excuse to keep a lot of very senior OS developers happy to be employees?
Linux was, AFAIK, the last GPL component of Android.
This is huge and exciting! One of the first open-source microkernels to get some serious commercial rollout, if I’m not missing anything. (I believe BlackBerry used a microkernel which was proprietary). Should be interesting!
Huh, genuinely thought this was a research kernel type situation. But they have a display manager and everything built in to it. Wonder why they're using a different kernel instead of using Linux.
It is in a sense something of a research kernel. The reason to not use Linux is that it’s 30 years old and crufted up with things like multiple users, processes running as the user that started them, and POSIX.
Linux also doesn’t have a stable kernel interface for drivers, which is probably a huge pain when dealing with supporting a device for many years. Either you don’t update the OS on the devices, or you have to modify all of your drivers every time you update the OS.
Linux also doesn’t have a stable kernel interface for drivers, which is probably a huge pain when dealing with supporting a device for many years. Either you don’t update the OS on the devices, or you have to modify all of your drivers every time you update the OS.
[deleted]
Linux is GPL.
Google doesn't control Linux.
I guess a microkernel is pretty cool though, the academic ideal.
I guess a microkernel is pretty cool though, the academic ideal.
Aside: Fuschia* is such an odd choice of name unless you are on a dual mission to not only make an MIT licensed Linux, but also to improve the ESL** world’s spelling and vocabulary.
*Fuchsia, sorry.
**German speakers will be fine.
*Fuchsia, sorry.
**German speakers will be fine.
Worth noting that golang was evaluated and then discarded for fuschia: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d...
Why is that worth noting, and not the fact that the network stack is still Go-based? (So to say it’s discarded is inaccurate.)
Because it was supposed to be a "systems language", yet it failed at that task. Furthermore, they want to move the network stack to an approved language over time:
> netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
> netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.
I don't think it's failed. It's true that it has been far more successful as a general purpose web backend language, but you still have most of the container ecosystem (Docker, containerd, runc, kubernetes) written in Go. Either way, I don't think Fuchsia's language policy is noteworthy in this context.
I understand that Fuchsia is currently targeted at IoT or consumer devices, but can it run "containerized apps" in server environments with its current design (compared to Linux namespaces)?
Maybe Kubernetes can be extended later to support Fuchsia nodes. It sounds really interesting to have a new target OS, with a different network and virtualization stacks.
Maybe Kubernetes can be extended later to support Fuchsia nodes. It sounds really interesting to have a new target OS, with a different network and virtualization stacks.
Considering all resources are accessed via scoped and capability-based handles, I suspect so. Not sure I want to see more kubernetes more places though... I'd rather just write software on a secure os in the first place.
ChromeOS, Android, WearOS, Fuchsia, Fitbit OS...
Doesn't that make 5? (Potentially dumb question, I know...)
Doesn't that make 5? (Potentially dumb question, I know...)
It's a damn shame that you have to use flutter, that's all I'd say.
You don't, any C++ will do, as well as Java, Swift, etc etc etc. Also, it's a kernel, not a whole window management system + APIs + look & feel like people are reading here
With this update, will the Nest Hub finally be able to tell time without an internet connection?
I returned mine as I had this happen to me, which completely invalidates its use as a clock.
I returned mine as I had this happen to me, which completely invalidates its use as a clock.
I'm curious, do you mean actually show the time, or be able to respond to a voice query? I know newer Pixels for example run local-assistant and can answer a decent percent of queries locally, including telling time. I assume older Nest Devices don't yet have the local capability of processing your voice query locally, other than the hotword.
Actually show the time. If the hub lacks an internet connection, the screen prompts you to get one and will no longer show time.
Well, if Fuschsia doesn't do too well initially, at least they picked a hardware device that will probably be as forgetful as the Verizon Hub from 2009.
https://youtu.be/1z1nsuQi40w
https://youtu.be/1z1nsuQi40w
Are there any privacy aspects to this? Does Google track everything that is going on?
Do you have control over your device or can Google release updates and do whatever they want with it?
Do you have control over your device or can Google release updates and do whatever they want with it?
Just another bot net from Google. How much personal information will these devices running this new OS capture/steal? No thanks....
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
In all seriousness - how is that any different from ChromeOS or Android? It's not like the kernel is what determines privacy issues.
Ahhaha... Google is basically just a large data collecting bot net
Probably the biggest Google vaporware ever
Vaporware with shipping units and published source code?
They got the vapor wave aesthetics with the name at least
it's literally shipping
Who wants to start a betting pool for when they cancel the project now that it's officially released into the world? I'm going with 2025. Just enough time for it to build up some momentum before they pull the rug out from under the user base!
Please don't repeat shallow-dismissal clichés and particularly not with added snark. You may not owe $BigCo better, but you owe this community better if you're participating in it.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
If this can possibly replace Android, WearOS (or recently announced WearOS/Tizen mashup), and ChromeOS, it’s quite possible that Fucshia is here to stay.
Android apps and Chrome can easily run on a different OS, the only problem are device drivers, but I’m sure Google is in a position to persuade manufacturers to provide drivers for their OS.
Android apps and Chrome can easily run on a different OS, the only problem are device drivers, but I’m sure Google is in a position to persuade manufacturers to provide drivers for their OS.
>> If this can possibly replace Android, WearOS (or recently announced WearOS/Tizen mashup), and ChromeOS, it’s quite possible that Fucshia is here to stay.
So they can cancel more products if they keep Fuchsia!
So they can cancel more products if they keep Fuchsia!
Does every new Windows update count as a “cancellation” to you?
>> Does every new Windows update count as a “cancellation” to you?
No, but replacing android or chrome OS with a new OS built from scratch should right?
No, but replacing android or chrome OS with a new OS built from scratch should right?
It wouldn’t be like that. Take a look at this https://en.m.wikipedia.org/wiki/Ship_of_Theseus
Sure, define your terms & odds, I'll take your money.
It's notable that this release has nearly ZERO attempt to market to or engage with 3rd party developers. It is solely for 1st party apps, solely under their control. Google picked a consumer device with extremely limited, contained functionality to target Fuchsia to.
This is an extremely crazy twist for a device that is supposed to play a star, core role in the home, and a strong indicator to me of where we are in the War Against General Purpose Computing.
There are definitely ways for 3rd parties to add to the experience, with the chatbot platform, but it's all expressed in Google's existing mold, via Actions with Google Assistant & other pre-baked systems of manipulation.
This is an extremely crazy twist for a device that is supposed to play a star, core role in the home, and a strong indicator to me of where we are in the War Against General Purpose Computing.
There are definitely ways for 3rd parties to add to the experience, with the chatbot platform, but it's all expressed in Google's existing mold, via Actions with Google Assistant & other pre-baked systems of manipulation.
It's a last-gen device. Why not interpret the lack of fanfare -- by design, a user won't even notice the swap -- as a soft launch?
The smart home space has always been a shit show, from the radios up. It's a separate bag of rats from launching a research OS on real hardware.
The smart home space has always been a shit show, from the radios up. It's a separate bag of rats from launching a research OS on real hardware.
I quite agree that this un-developable device issue is an IoT issue not really a Fuchsia issue. But it is also demonstrative a bit of some of the unique role Fuchsia has for us, what life after Android Things looks like.
This has been open knowledge for a few years now. I was fully expecting it to be cancelled before launch. In that sense am surprised it saw the light of day.
However, I have never seen an explanation of why they need an OS written from scratch. The whole kernel and driver ecosystem, apps, development model, every single thing written from scratch. It took 6 years too for it to be productized. Why would anyone make that kind of an investment? It has to be extremely compelling. I would like to hear it from them
However, I have never seen an explanation of why they need an OS written from scratch. The whole kernel and driver ecosystem, apps, development model, every single thing written from scratch. It took 6 years too for it to be productized. Why would anyone make that kind of an investment? It has to be extremely compelling. I would like to hear it from them
Linux wasn't invented at Google.
I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio. That indicates to me that they don't see this as an Android killer just yet. A bold move would have been to put this on the next Pixel. Clearly, that's not happening. If that was at all feasible, they would have waited for that and that would have been the grand launch. So, clearly it's nowhere near ready for such a launch.
Their main issue with this is that OEMs like Samsung probably are not in any hurry whatsoever to jump on board and be even more dependent on Google. Without OEMs, app developers will drag their heels as well and Google is forced to maintain Android and not do a half-assed job of it. At this point Google has Android in cars, tvs, on phones, etc. Killing that would be suicidal; Google needs users interacting with their ads.
If they botch the Fuchsia launch somehow, they'd have more OEMs taking things in their own hands and cutting loose from Google and forking Android (like Amazon and Huawei already did). They clearly are not ready to pull the plug on Fuchsia just yet but at this point it's a more than likely outcome. IMHO, they should just rip off the band-aid and move on. Most of what is wrong with Android is fixable.
Their main issue with this is that OEMs like Samsung probably are not in any hurry whatsoever to jump on board and be even more dependent on Google. Without OEMs, app developers will drag their heels as well and Google is forced to maintain Android and not do a half-assed job of it. At this point Google has Android in cars, tvs, on phones, etc. Killing that would be suicidal; Google needs users interacting with their ads.
If they botch the Fuchsia launch somehow, they'd have more OEMs taking things in their own hands and cutting loose from Google and forking Android (like Amazon and Huawei already did). They clearly are not ready to pull the plug on Fuchsia just yet but at this point it's a more than likely outcome. IMHO, they should just rip off the band-aid and move on. Most of what is wrong with Android is fixable.
> I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio.
It’s certainly the best way to immediately get it a whole lot of real world use and feedback with basically zero sales effort, and its economical since it lets them transfer resources allocation from supporting a dead-end effort to a live one.
> A bold move would have been to put this on the next Pixel.
“Bold” is sexy, but not the same as smart long-term strategy in many cases.
It’s certainly the best way to immediately get it a whole lot of real world use and feedback with basically zero sales effort, and its economical since it lets them transfer resources allocation from supporting a dead-end effort to a live one.
> A bold move would have been to put this on the next Pixel.
“Bold” is sexy, but not the same as smart long-term strategy in many cases.
> I think it's telling that they are 'launching' this with a product that barely matters in their product portfolio. That indicates to me that they don't see this as an Android killer just yet. A bold move would have been to put this on the next Pixel. Clearly, that's not happening. If that was at all feasible, they would have waited for that and that would have been the grand launch. So, clearly it's nowhere near ready for such a launch.
That seems like a good thing to me. Personally I'm not very interested in an OS that's 'bold', I want an OS that's stable and well tested and releasing slowly on a limited set of devices seems a good way of doing that.
That seems like a good thing to me. Personally I'm not very interested in an OS that's 'bold', I want an OS that's stable and well tested and releasing slowly on a limited set of devices seems a good way of doing that.
> A bold move would have been to put this on the next Pixel.
Which will delay the next Pixel at least several years while causing a unprecedented level of fragmentation in the Android ecosystem? BTW, I don't expect this kind of experimental projects can live without reaching any milestones. Replacing Android with Fuchsia is just not a feasible option at this moment.
Which will delay the next Pixel at least several years while causing a unprecedented level of fragmentation in the Android ecosystem? BTW, I don't expect this kind of experimental projects can live without reaching any milestones. Replacing Android with Fuchsia is just not a feasible option at this moment.
Another way of looking at it is that it probably takes a really long time to bring up an operating system to the point where it is production-ready.
It would be easier to do if you can target one hardware platform that does not change so that you don't have to also shift gears. If you're building the Great Pyramid, you don't want to also move it to a new construction site when it's half-completed.
Launching on hardware that was already released could mean they gave themselves that time. By the time they're finished (now), the hardware is old.
It would be easier to do if you can target one hardware platform that does not change so that you don't have to also shift gears. If you're building the Great Pyramid, you don't want to also move it to a new construction site when it's half-completed.
Launching on hardware that was already released could mean they gave themselves that time. By the time they're finished (now), the hardware is old.
There's a gigantic difference in developer effort to make an appliance OS versus a full-featured mobile OS.
They are clearly having commitment issues for that.
I don't see it that way. Reinventing a mobile OS is a huge undertaking and it makes little sense to do it just as an experiment.
Contrast with Apple: M1 and pump! launched it the major selling laptop.
That is how you know Apple mean business.
And this is how you know fucsia/google will not.
That is how you know Apple mean business.
And this is how you know fucsia/google will not.
You do realise that Apple's M1 processor + OS porting was a 10 year goal to produce the results that you see before you?
Several years ago [0], the same ones here were calling Fuchsia dead since 2016 - 2018 and theoretically today it should already have died. Today Google has surprised the skeptics here and just released Fuchsia 1.0 on a real device (earlier than expected) and now you're already calling it dead again?
This whole thread sounds like a Linux meltdown club to me. In fact, Google is taking / controlling Fuchsia in the same direction as to what Apple has always done with iOS / macOS and its own silicon.
Perhaps when this decade ends, you will be looking at this comment (and this one [1]) via a phone running Fuchsia.
[0] https://news.ycombinator.com/item?id=17568335
[1] https://news.ycombinator.com/item?id=22005286
Several years ago [0], the same ones here were calling Fuchsia dead since 2016 - 2018 and theoretically today it should already have died. Today Google has surprised the skeptics here and just released Fuchsia 1.0 on a real device (earlier than expected) and now you're already calling it dead again?
This whole thread sounds like a Linux meltdown club to me. In fact, Google is taking / controlling Fuchsia in the same direction as to what Apple has always done with iOS / macOS and its own silicon.
Perhaps when this decade ends, you will be looking at this comment (and this one [1]) via a phone running Fuchsia.
[0] https://news.ycombinator.com/item?id=17568335
[1] https://news.ycombinator.com/item?id=22005286
So? Of course this take time, but when Apple LAUNCH it, it do it with confidence.
> but when Apple LAUNCH it, it do it WitH cONfIdeNCE.
The answer I'm looking for is that during this 10 year effort Apple had already and always used their existing designed ARM chips in their iPhones and iDevices. Once they improved it over time and it surpassed their Intel counterparts, it was the time to target the Mac which is why you are hyping over the M1 performance.
In fact, macOS was already on ARM years ago. It's just that it would have ran slower and wasn't ready which is why they waited and here we are.
But this claim:
> And this is how you know fucsia/google will not.
How can you be so certain that the owner of the world's most used mobile operating system [0] and a very competitive desktop OS on the market [1] cannot or 'will not' launch Fuchsia with confidence (even when they just did)? Don't you think it's extremely too early to make such vacuous claims without ANY compelling evidence?
[0] https://www.statista.com/statistics/272698/global-market-sha...
[1] https://www.geekwire.com/2021/chromebooks-outsold-macs-world...
The answer I'm looking for is that during this 10 year effort Apple had already and always used their existing designed ARM chips in their iPhones and iDevices. Once they improved it over time and it surpassed their Intel counterparts, it was the time to target the Mac which is why you are hyping over the M1 performance.
In fact, macOS was already on ARM years ago. It's just that it would have ran slower and wasn't ready which is why they waited and here we are.
But this claim:
> And this is how you know fucsia/google will not.
How can you be so certain that the owner of the world's most used mobile operating system [0] and a very competitive desktop OS on the market [1] cannot or 'will not' launch Fuchsia with confidence (even when they just did)? Don't you think it's extremely too early to make such vacuous claims without ANY compelling evidence?
[0] https://www.statista.com/statistics/272698/global-market-sha...
[1] https://www.geekwire.com/2021/chromebooks-outsold-macs-world...
Apple apologist here, but uh, really the M1 isn't a first-gen product, it's more like a TENTH-gen product. It's a direct evolution from the A4 chip series, and apple only did the big sexy "we mean business" rebrand when, after a decade of R&D, they'd basically bred a mouse up to the size of a mammoth.
Apple quietly ramped it up year over year; at its initial release, it was just another "me too" phone ARM chip, but as they built it, after a few years they had their own chip design team and were no longer just popping in generic ARM Cortex designs. Then it quietly got 2, then 3x faster than the other phones on the market. Finally it reached full parity with common-market intel chips; apple made sure their "intel on arm" emulator was working well.
They still didn't release it! They waited a couple more years - until it was so fast that even emulated, it would be comparable with a brand new low-end intel machine, and then, finally, they branded it as the M1 and released it.
---
Google's strategy seems to be playing out really similarly. Put it out in the wild in some devices where they won't get flak for the usual teething problems. Work all of those out, and then, once it's pretty robust, make the big confident "sexy play" to deploy it on an android phone.
Apple quietly ramped it up year over year; at its initial release, it was just another "me too" phone ARM chip, but as they built it, after a few years they had their own chip design team and were no longer just popping in generic ARM Cortex designs. Then it quietly got 2, then 3x faster than the other phones on the market. Finally it reached full parity with common-market intel chips; apple made sure their "intel on arm" emulator was working well.
They still didn't release it! They waited a couple more years - until it was so fast that even emulated, it would be comparable with a brand new low-end intel machine, and then, finally, they branded it as the M1 and released it.
---
Google's strategy seems to be playing out really similarly. Put it out in the wild in some devices where they won't get flak for the usual teething problems. Work all of those out, and then, once it's pretty robust, make the big confident "sexy play" to deploy it on an android phone.
Apple has been launching the "M1" piece by piece for years now. They started with Qualcomm/PowerVR cores and ended up with custom designs over years of iterative product launches.
I have no idea why do you think M1 is such a green field effort when it obviously shares so much of it's design with A series SoCs you've been seeing in your favorite iDevice.
I have no idea why do you think M1 is such a green field effort when it obviously shares so much of it's design with A series SoCs you've been seeing in your favorite iDevice.
Where else could've they launched it? It's not like Apple has tons of HW products that require M1.
If Google would chose to launch Fuchsia as a base of next Android and force all OEMs on it, that would mean people managing release should be fired, as that's not how you stage major changes.
If Google would chose to launch Fuchsia as a base of next Android and force all OEMs on it, that would mean people managing release should be fired, as that's not how you stage major changes.
> and force all OEMs
????
This not make much sense, but if Google launched it in his own, then at least some OEMs could go along (supposing Fucsia is good, I don't know which could their selling point)
This not make much sense, but if Google launched it in his own, then at least some OEMs could go along (supposing Fucsia is good, I don't know which could their selling point)
No, Fuchsia is not a pet project. Instead, it's solving a very realistic problem: building a clean driver interface, while keep it open and gain hardware vendor support.
Anyone have shipped a Linux-based embedded system (including Android smartphone) knows the pain: there are tons of ad hoc driver source files need to be manually merged/rebased against the Linux Kernel. Want to upgrade the Linux kernel from 4.x to 5.x? Good luck redoing lots of merges and rebasing. There are tons and tons of git branches floating around, crazy examples like: "Linux-4.11-some_soc_vendor-some_oem-random_device-random_project-rev-1.3". It soon becomes unmanaged and device manufactures just gave up on keeping up with OS upgrades.
Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions. Even when people managed to get it work, you end up something like AMD's GPU driver takes 10% of Linux kernel [1].
The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel.
Is it worth it? Can Google pull it off? I don't know. But it probably worth a shot.
[1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....