Fuchsia overview(fuchsia.dev)
fuchsia.dev
Fuchsia overview
https://fuchsia.dev/fuchsia-src/concepts
232 comments
> For various reasons, but nothing fundamental.
"Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason.
Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to make their own high performance gpus.
"Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason.
Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to make their own high performance gpus.
I would not say that is a fundamental reason. They have been willing to do it when the proper incentives are there. The incentive to keeping it closed source is primarily part of a strategy to sabotage their competitors, which I hope is not a behavior that anyone here is complicit in. Please don't work for hardware companies that do this, there are plenty of companies out there that know how to spend their money in other ways.
>Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers?
Neither of those are good options because even in the second case, there are still vast swaths of code that upstream is not going to touch out of fear of breaking things, the end result being that you still get stuck with unfixable kernel and driver bugs.
>The open source community is not, for example, going to make their own high performance gpus.
The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.
>Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers?
Neither of those are good options because even in the second case, there are still vast swaths of code that upstream is not going to touch out of fear of breaking things, the end result being that you still get stuck with unfixable kernel and driver bugs.
>The open source community is not, for example, going to make their own high performance gpus.
The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.
This claim is wrong. It’s not about sabotaging competitors, it’s about being afraid that your competitors would steal your IP they gives you an advantage.
Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified.
If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different. But you can’t prevent somebody from reading even GPL code, being “inspired” by it, and writing something different enough that does the same thing with the same ideas. Like just look at the LLVM project were people look at what GCC code does every now and then for “inspiration”.
Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified.
If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different. But you can’t prevent somebody from reading even GPL code, being “inspired” by it, and writing something different enough that does the same thing with the same ideas. Like just look at the LLVM project were people look at what GCC code does every now and then for “inspiration”.
> Every Nvidia and Intel competitor (AMD) is probably already reverse engineering their binary drivers and binary libraries trying to steal their IP, so Intel and Nvidia’s fears are imo justified.
If NVIDIA or Intel could easily protect their open source code from being stolen from AMD, the story would be different.
Intel's GPU drivers are free software, they even contribute them themselves, same goes for AMD.
I think NVIDIA's different because they have the Apple mentality of them being the real innovators, (regardless of fact) and building their internal culture on secrecy, closeness even to other teams within the company etc. I think they consider it as part of their 'coolness factor', together with the CEO being on stage dressed like a rock star from the 80s.
The fact that they benefit from Linux massively and that having an open driver would win them massive goodwill is not directly measurable in terms of their balance sheet, at least in the short term, plus it would remove some of the secrecy.
Intel's GPU drivers are free software, they even contribute them themselves, same goes for AMD.
I think NVIDIA's different because they have the Apple mentality of them being the real innovators, (regardless of fact) and building their internal culture on secrecy, closeness even to other teams within the company etc. I think they consider it as part of their 'coolness factor', together with the CEO being on stage dressed like a rock star from the 80s.
The fact that they benefit from Linux massively and that having an open driver would win them massive goodwill is not directly measurable in terms of their balance sheet, at least in the short term, plus it would remove some of the secrecy.
They do so by using different teams, and their open source variants always lag behind what their closed source drivers are capable of doing across Windows, Apple and game consoles.
The drivers are decent enough nonetheless. I think having an open driver done by a different team and maybe a bit less optimized is still preferable to not having an official open driver at all.
I used to enjoy my OpenGL 4.1 driver on Radeon HD 6250, which was still short of OpenGL 4.4/DX 11 on Windows, but still quite ok I guess, all it does now with open source drivers is OpenGL 3.3.
So no that isn't decent enough, and I only keep it like this, because it is just a little travel laptop that I keep on using until it eventually dies.
So no that isn't decent enough, and I only keep it like this, because it is just a little travel laptop that I keep on using until it eventually dies.
Why even mention a fairly ancient GPU when AMD has really only gotten their act together fairly recently with amdgpu, but that supports Vulkan as I would expect.
I don't get this constant obsession with mentioning how 8 years ago this and this on Linux sucked. Yes, it did, things improved considerably since then.
If you're only willing to run Linux on ancient, underpowered hardware and then complain about the experience, be my guest, but I think you'd be better served by a Mac.
There's a whole class of people who run Linux on shitty little laptops and then compare the experience to their brand new iMac. I guess somewhere there's still the mentality that since one's not paying for Linux, it's not for my serious hardware, only second hand.
As much as I'd have liked for AMD to get their shit together sooner, I am glad they eventually did and are improving amdgpu at a decent speed.
I don't get this constant obsession with mentioning how 8 years ago this and this on Linux sucked. Yes, it did, things improved considerably since then.
If you're only willing to run Linux on ancient, underpowered hardware and then complain about the experience, be my guest, but I think you'd be better served by a Mac.
There's a whole class of people who run Linux on shitty little laptops and then compare the experience to their brand new iMac. I guess somewhere there's still the mentality that since one's not paying for Linux, it's not for my serious hardware, only second hand.
As much as I'd have liked for AMD to get their shit together sooner, I am glad they eventually did and are improving amdgpu at a decent speed.
That was just one example, I can provide more up to date ones as well.
Indeed, that is why this Linux laptop is the surviving one that still runs Linux on bare metal, everywhere else I just VMs, if at all.
Indeed, that is why this Linux laptop is the surviving one that still runs Linux on bare metal, everywhere else I just VMs, if at all.
Having worked for a GPU company, it's not even about stealing IP. It's about giving ammo to your competitors for suing you. If you publish the source code to your drivers then let's say Nvidia can read through them and find a few similarities in your hardware to something they have patented, and then sue you for IP infringement. They can't do this without some evidence that there might be a similarity, but weak evidence is enough. So they basically send you a set of 100 patents that they say you violate, and then it's your job to spend your legal resources to show how you don't violate those patents. It might be easy to show this for say 90 of those patents, but there can be a few which require considerable work, and if you're a small company you don't have the resources to fight off lawsuits all the time. So open sourcing your drivers opens you up to a lot of potential attacks, with very little upside. More specifically, it opens up the companies that buy GPU IP from you to attacks. Nvidia on the other hand has the resources to keep throwing accusations at you and see what sticks and force you to burn cash on legal resources.
That is an assumption. I think the simpler case is it's more work and exposes potential security vulnerabilities they don't care to patch or maintain. Function > all.
[deleted]
The incentive to keeping it closed source is primarily part of a strategy to sabotage their competitors, which I hope is not a behavior that anyone here is complicit in.
I can't figure out what you mean by "sabotage their competitors". The term sabotage indicates that they are performing actions to actively harm their competitors, how is that related to keeping your source, which cointains your IP, private?
The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.
It is nice to hear that they are welcome :p. Which they would even feel more so, if there were actual incentives being offered rather than trying to make their life artificial difficult.
I can't figure out what you mean by "sabotage their competitors". The term sabotage indicates that they are performing actions to actively harm their competitors, how is that related to keeping your source, which cointains your IP, private?
The open source community includes a lot of companies. The high-performance GPU companies are welcome to join this community any time they like.
It is nice to hear that they are welcome :p. Which they would even feel more so, if there were actual incentives being offered rather than trying to make their life artificial difficult.
> The open source community is not, for example, going to make their own high performance gpus.
I think we should lower the entry threshold first. The open source and free GPU project was the first thing that came to my mind when I saw http://llhd.io/. After all, one of the main problems with OpenHardware projects is the closed FPGA ecosystem.
I think we should lower the entry threshold first. The open source and free GPU project was the first thing that came to my mind when I saw http://llhd.io/. After all, one of the main problems with OpenHardware projects is the closed FPGA ecosystem.
It's pretty amazing how far the open source FPGA tooling has come in the last few years. I'd even go so far as to say some parts of the open source ecosystem have surpassed the commercial tools.
Still a long way to go of course, but I'm pretty positive about the direction things are heading.
Still a long way to go of course, but I'm pretty positive about the direction things are heading.
Plus, better isolation between driver code and other kernel code (which Fuchsia seems to bring; correct me if I'm wrong) would be good for everyone, since you can be relatively assured that running vendor-provided driver blobs is safe.
"Isolation" of driver code that can talk to on-SoC hardware is just not very meaningful. You can only have real driver isolation if it's enforced on the hardware side via some IOMMU mechanism (or by keeping the hardware isolated on the USB bus, etc.), otherwise you're just adding pointless overhead for no real benefit.
I didn't get it. Don't we want, for example, wifi driver not to be able to access and corrupt (due to some bug) GPU driver's memory?
It's desirable, but typically hardware devices have DMA-capable buses that can read / write to arbitrary physical memory. So a buggy or malicious WiFi driver may be able to use the WiFi DMA hardware to write into the GPU driver's memory, and no pure software mechanism can stop it from doing so.
IOMMUs solve this problem by giving hardware devices their own virtual address spaces.
IOMMUs solve this problem by giving hardware devices their own virtual address spaces.
> Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option
A phone in which the kernel never needs to be updated, like with the seL4 microkernel.
A phone in which the kernel never needs to be updated, like with the seL4 microkernel.
Most BIOS are also closed source. If I used a microkernel primitive enough not to require changes, I could live with not updating the kernel unless there is a security bug.
A third solution could be to require device manufacturers to share their source code with a trusted third party (such as google/certification authority). This third party will make sure that the driver does not include any harmful code and provide signed binaries. Binaries could also be updated for newer versions that way, even if the original manufacturer loses interest/goes bankrupt. If the IP gets stolen, the device manufacturer could sue this third party, therefore business people will also feel secure.
It is not ideal, but I could be able to live with this solution.
A third solution could be to require device manufacturers to share their source code with a trusted third party (such as google/certification authority). This third party will make sure that the driver does not include any harmful code and provide signed binaries. Binaries could also be updated for newer versions that way, even if the original manufacturer loses interest/goes bankrupt. If the IP gets stolen, the device manufacturer could sue this third party, therefore business people will also feel secure.
It is not ideal, but I could be able to live with this solution.
> The open source community is not, for example, going to make their own high performance gpus.
Of course it will.
Of course it will.
The first GPU came out twenty one years ago. Why on Earth do you think all of a sudden we're going to get something we've never gotten before?
The RISC-V community is already working on GPUs, some of them open:
https://github.com/felsabbagh3/Vortex https://news.ycombinator.com/item?id=22492902 https://libre-riscv.org/3d_gpu/
https://github.com/felsabbagh3/Vortex https://news.ycombinator.com/item?id=22492902 https://libre-riscv.org/3d_gpu/
Doesn’t look that good to me. The Vortex is not a GPU. They call it GPGPU, meant purely for running OpenCL kernels, doesn’t have a graphics pipeline at all, which is kinda important part of a GPU.
I am not so sure about that. GPU has been slowly moving away from having a fixed graphics pipline at all in the past a few years. See the recent Nanite technology from Unreal 5: http://c0de517e.blogspot.com/2020/05/some-thoughts-on-unreal...
They use compute shaders for triangles that cover 1 pixel as rasterization always does 2x2 due to derivative calculations etc so there is overhead. For larger triangles they do go trough the rasterization pipeline as usual because it is so much faster.
Another crucial thing is texture mapper. That thing is really fast and usable even in the compute pipeline. Image support is (was?) largely optional in OpenCL.
Also I remember the last time people talked about this. PS3 was not originally supposed to have a GPU at all because the Cell processor was so powerful. In the end they had to ram in an actual GPU. While the Cell was just fine for vertex processing it did choke terribly in rasterization due to lack of TMU and dedicated HW rasterizer.
EDIT: I also want to emphasize the difference of target markets. On AMD one can go to the Nanite path for some of the rasterization. One must remember that it is a non battery powered device.
Memory bandwidth is really power hungry. For mobile, the likely target market for the Vortex and similar, one really wants to do tile based rendering. Ideally the way IMG does it. Even though theoretical flops of modern mobile GPU’s is higher than some old discrete ones their memory bandwidths are way lower, so no running Crysis on modern mobile even though flops would indicate it would match a good discrete GPU back in the days.
Another crucial thing is texture mapper. That thing is really fast and usable even in the compute pipeline. Image support is (was?) largely optional in OpenCL.
Also I remember the last time people talked about this. PS3 was not originally supposed to have a GPU at all because the Cell processor was so powerful. In the end they had to ram in an actual GPU. While the Cell was just fine for vertex processing it did choke terribly in rasterization due to lack of TMU and dedicated HW rasterizer.
EDIT: I also want to emphasize the difference of target markets. On AMD one can go to the Nanite path for some of the rasterization. One must remember that it is a non battery powered device.
Memory bandwidth is really power hungry. For mobile, the likely target market for the Vortex and similar, one really wants to do tile based rendering. Ideally the way IMG does it. Even though theoretical flops of modern mobile GPU’s is higher than some old discrete ones their memory bandwidths are way lower, so no running Crysis on modern mobile even though flops would indicate it would match a good discrete GPU back in the days.
> The first GPU came out twenty one years ago. Why on Earth do you think all of a sudden we're going to get something we've never gotten before?
'21 years ago we got a new thing. Why on Earth do you think we're going to get something new ever again?'
'21 years ago we got a new thing. Why on Earth do you think we're going to get something new ever again?'
I think people are missing the sarcasm... at least I hope that's sarcasm.
It's not at all sarcasm. What's different now?
Wait, you really don't see the contradiction between your first and second sentences?
'21 years ago we got yet another new thing. What makes you think we'll ever get a new thing again?'
Seriously?
'21 years ago we got yet another new thing. What makes you think we'll ever get a new thing again?'
Seriously?
Expired patents
Sorry, walk me through this. There was a competitive field of GPUs. Somehow the companies were able to produce hardware. Are you saying that someone controlled the defining patents, and all of the competitors were forced to license from them?
Citation needed.
Citation needed.
Currently the GPU market consists of companies that have been working on GPUs for decades. Companies that are starting right now have failed to design GPUs. This includes very big players, like Intel, Apple and Huawei. This is likely because all the important ways to produce GPUs have been patented, and there's only so many ways to create an efficient GPU. Even if you try to create your own GPU by poaching engineers from existing GPU companies (like Apple tried), those engieers are only familiar with methods that were already patented and you have no way around this even if you have Apple's tremendous resources to throw at the problem. So the only way to create an open source GPU is to use patents that already expired. Such a GPU might be 15-20 years behind current technology, but that's still a GPU.
I really want to agree with you, and in principle, it would be far better for hardware manufacturers to upstream their drivers. In practice this hasn't happened and will never happen, because there's no incentive to support hardware no longer making money (a chip is only sold once, after all).
I think the mounting cost of e-waste is a far bigger deal. Think of the unimaginable amount of carbon impact from the millions of trashed Android phones out there. Do we really want to continue down this path, until there's billions of obsolete machines sitting in landfills (there probably already is)? Updatability can save devices for much longer, and now people are upgrading less often, there's a huge opportunity for impact there.
Disclosure: I work for Google, but not on the Android OS or Fuchsia.
I think the mounting cost of e-waste is a far bigger deal. Think of the unimaginable amount of carbon impact from the millions of trashed Android phones out there. Do we really want to continue down this path, until there's billions of obsolete machines sitting in landfills (there probably already is)? Updatability can save devices for much longer, and now people are upgrading less often, there's a huge opportunity for impact there.
Disclosure: I work for Google, but not on the Android OS or Fuchsia.
> Updatability can save devices for much longer
I'm skeptical of this. People buy new phones because they are faster, or because they did update and the new version of the OS is very slow on old hardware. People buy new hardware because they want new hardware.
Most non-tech people I know actively avoid updating their phones because it's annoying. They will ignore the notifications and choose older software over the inconvenience of updating and rebooting their phone.
I'm skeptical of this. People buy new phones because they are faster, or because they did update and the new version of the OS is very slow on old hardware. People buy new hardware because they want new hardware.
Most non-tech people I know actively avoid updating their phones because it's annoying. They will ignore the notifications and choose older software over the inconvenience of updating and rebooting their phone.
Hardware has its limits of course, but sometimes if you can’t upgrade your OS, you can’t install apps. You’ll be stuck with a screen saying “This application requires IOS X and higher”. When that frequently happens, you are forced to upgrade your phone, even if you’re content with the hardware.
Avoiding updates and ignoring notifications could stem from a different reasons. People may not want to take the time and maintain their phones. I consider myself a techy person, but I also put off updating my phone, taking good care of it, upgrading it. I also dread tidying up my room, getting a hair cut, shopping for clothes, eating healthy, sleeping well etc. It could be a personality trait.
Avoidance conserves energy :)
Avoiding updates and ignoring notifications could stem from a different reasons. People may not want to take the time and maintain their phones. I consider myself a techy person, but I also put off updating my phone, taking good care of it, upgrading it. I also dread tidying up my room, getting a hair cut, shopping for clothes, eating healthy, sleeping well etc. It could be a personality trait.
Avoidance conserves energy :)
Once upon a time, Linux had terrible support for laptop hardware. Remember ndiswrapper? That thing you used to get Windows wifi drivers working on Linux. Or how about when ATI (AMD) provided only the most buggy drivers. How about printers?
These days Linux has better hardware support (imo) than Windows. Solving it for laptops was about creating the right incentives for hardware manufacturers. It can happen for mobile too.
These days Linux has better hardware support (imo) than Windows. Solving it for laptops was about creating the right incentives for hardware manufacturers. It can happen for mobile too.
I wouldn't say Linux has better hardware support than Windows. When your hardware is properly recognized and supported by Linux than yeah, I do feel it operates much better, more stable and have more knobs. However, not all hardware works at all.
For example, as of now, the hardware sensors on my x590 board are not recognized.
LED control is not a thing, even on most old/established boards (you can argue if LEDs are nice or ugly, but if they are there I want to control them).
Even enterpriseish devices, like Lenovo's X1 laptops, that are CERTIFIED by both Red Hat and Ubuntu, have limited hardware support at best. Fingerprint scanners on 3 year old models are still not recognized, and there seems to be zero will from synaptic to ever support it. Sleep states were terrible for a long long time, finally fixed in a fashion that requires different firmware for optimal sleep performance on Windows or another one for Linux.
So no, my experience is that still hardware vendors are not giving me as a Linux user the support and value for the good money I pay for their products. Obviously they don't deliver the expected level of support any reasonable consumer would expect, and most probably won't deliver it in the future either, since they get away with it so easily.
For example, as of now, the hardware sensors on my x590 board are not recognized.
LED control is not a thing, even on most old/established boards (you can argue if LEDs are nice or ugly, but if they are there I want to control them).
Even enterpriseish devices, like Lenovo's X1 laptops, that are CERTIFIED by both Red Hat and Ubuntu, have limited hardware support at best. Fingerprint scanners on 3 year old models are still not recognized, and there seems to be zero will from synaptic to ever support it. Sleep states were terrible for a long long time, finally fixed in a fashion that requires different firmware for optimal sleep performance on Windows or another one for Linux.
So no, my experience is that still hardware vendors are not giving me as a Linux user the support and value for the good money I pay for their products. Obviously they don't deliver the expected level of support any reasonable consumer would expect, and most probably won't deliver it in the future either, since they get away with it so easily.
3 year old hardware is still very new by Linux standards. Especially wrt. hardware classes for which a unified support framework has yet to be provided, including RGB LED's and fingerprint scanners. The sleep performance thing is an interesting example, since the whole issue was caused by hardware OEM's deprecating the old ACPI "sleep" state and deciding that OS's should manage standby states entirely on their own - this too will require a lot of really hard work to be supported properly across zillions of devices.
> 3 year old hardware is still very new by Linux standards
I agree, and hence my claim - Linux have excellent support for the hardware it supports, but in general it is not lagging behind Windows in that dimension due to restricted access to required information.
I agree, and hence my claim - Linux have excellent support for the hardware it supports, but in general it is not lagging behind Windows in that dimension due to restricted access to required information.
I'm torn on the subject of a binary-stable driver interface. The idealist in me likes that it forces vendors to open source their driver code, but the pragmatist in me knows that some vendors (like a certain graphics card manufacturer in the desktop and server world) probably never will open source their drivers, and if they do, they may not be as high of quality as the proprietary version for other OSes. I wonder if there is some middle ground. Also, even with open source drivers, the lack of stability has downsides, such as requiring you to recompile all drivers whenever the kernel updates. Maybe where a subset of the ABI is stable, so it's possible to build driver binaries that work across kernel versions, but there is still some incentive for keeping drivers open source?
> any improvement that could be added to Fuschia could be added to Linux
This is not necessarily true. Some things certainly. But linux is constrained by keeping a backwards compatible user-space interface, and being mostly posix-compliant. For example, fuchsia doesn't have fork or exec (it has a single spawn function/syscall instead). Linux could add a new spawn syscall, but has to keep fork, clone, execv, etc. forever. And even if most new code moves to use the new syscall, the complexity around the old ones will be around forever.
> any improvement that could be added to Fuschia could be added to Linux
This is not necessarily true. Some things certainly. But linux is constrained by keeping a backwards compatible user-space interface, and being mostly posix-compliant. For example, fuchsia doesn't have fork or exec (it has a single spawn function/syscall instead). Linux could add a new spawn syscall, but has to keep fork, clone, execv, etc. forever. And even if most new code moves to use the new syscall, the complexity around the old ones will be around forever.
While I understand why you want open source drivers, the situation hasnt improved for 10 years, and this is one of the major reasons many phones end up not getting Android updates, which makes Google/Android look bad.
> the situation hasnt improved for 10 years
But it has.
* I remember having major issues with printer drivers on Linux 10 years ago. Nowadays thanks to IPP support I don't need any drivers any more. I had to help my dad with installing a windows driver while on my Linux laptop it just worked.
* My Laptop from 13 years ago didn't have free network drivers. I had to jump through hoops to install them. Now they are all free.
* AMD has started maintaining really good open source driver support for their GPUs
* Even for Android there is improvement, with e.g. free Mali drivers being built. It's slow and not enough, but improvement.
But it has.
* I remember having major issues with printer drivers on Linux 10 years ago. Nowadays thanks to IPP support I don't need any drivers any more. I had to help my dad with installing a windows driver while on my Linux laptop it just worked.
* My Laptop from 13 years ago didn't have free network drivers. I had to jump through hoops to install them. Now they are all free.
* AMD has started maintaining really good open source driver support for their GPUs
* Even for Android there is improvement, with e.g. free Mali drivers being built. It's slow and not enough, but improvement.
> the situation hasn't improved for 10 years
I believe its meant in context of Android.
I believe its meant in context of Android.
> AMD has started maintaining really good open source driver support for their GPUs
Still waiting for them to reach parity for my laptop GPU, it used to be OpenGL 4.1 with hardware video decoding, nowadays I just get OpenGL 3.3 with the open source driver, the antithesis of really good.
Still waiting for them to reach parity for my laptop GPU, it used to be OpenGL 4.1 with hardware video decoding, nowadays I just get OpenGL 3.3 with the open source driver, the antithesis of really good.
I believe the situation is a bit better now that there are LTS releases of the Linux kernel.
> any improvement that could be added to Fuschia could be added to Linux
Not easily. If Linux has gone down a path far enough, it may be hard to reverse, especially if it is of fundamental design. For example, the separation of kernel space and user space is different. I am not an operating system engineer, but I would bet that certain things would be hard to change --- deep structural decisions mentioned in the article, like:
- the kernel primitives are exposed to applications as object-capabilities
- applications can interact only with the objects to which they have been granted access explicitly
- applications interact with each other and the system using message passing
> use proven ideas
I would say in the realm of software there are still competing ideas, even if you narrow it to the subset of ideas that are good (secure, maintainable, fast, etc.). Linux chose some good ideas, but if you want to try out different ones, you may have to start from a clean slate.
Not easily. If Linux has gone down a path far enough, it may be hard to reverse, especially if it is of fundamental design. For example, the separation of kernel space and user space is different. I am not an operating system engineer, but I would bet that certain things would be hard to change --- deep structural decisions mentioned in the article, like:
- the kernel primitives are exposed to applications as object-capabilities
- applications can interact only with the objects to which they have been granted access explicitly
- applications interact with each other and the system using message passing
> use proven ideas
I would say in the realm of software there are still competing ideas, even if you narrow it to the subset of ideas that are good (secure, maintainable, fast, etc.). Linux chose some good ideas, but if you want to try out different ones, you may have to start from a clean slate.
There is also de fact that the concepts/model of Zircon's kernel API and Linux one are diferent and in some cases mutually incosistent if implemented in the same kernel
sorry but that's just naive idealism, my wife has android flagship, a Samsung s10, she will receive one more year of updates, then she will be on her own, my daughter has iPhone 6S, this old device will receive iOS 14 soon.
my wife do not care about updates, she will not hesitate a second to get iPhone once she knows her social media or pictures is not safe on her android device, this is the issue Android have and Fuchsia have to fix.
my wife do not care about updates, she will not hesitate a second to get iPhone once she knows her social media or pictures is not safe on her android device, this is the issue Android have and Fuchsia have to fix.
I'm pretty sure Qualcomm not giving a shit about supporting their SoC is why my Android watches were practically EOL'd within months.
Not sure how Fuchsia is supposed to solve this. If you can port those Qualcomm SoC drivers to the fixed Fuchsia interface, you could just as easily port them to the mainline Linux kernel and submit them upstream.
"Easily"? Some things can only be shipped as binary blobs. For example, you won't get open source audio drivers that support patent-encumbered codecs like Dolby Atmos.
Windows has a stable binary ABI which means that my drivers don't go stale when Microsoft pushes out a minor rev to the NT kernel. Windows does its updates and my peripherals [mostly] work just fine.
Windows has a stable binary ABI which means that my drivers don't go stale when Microsoft pushes out a minor rev to the NT kernel. Windows does its updates and my peripherals [mostly] work just fine.
Exactly. It is kind of funny how IT people look through their tech glass and think that the rest of the world (99.9999%) does the same. Nobody cares about software, everybody cares about user experience. Linux proved the point that having unstable driver interface has nothing to do with the success of the platform.
I think that if you consider success for the average user, Android has proved it, not the Linux kernel.
Note that it will only get one more major Android version, but Samsung provides 4 years of security updates, so she still has 3 more years before she's on her own.
Certainly not as good as Apple, but I believe that's the best you can find in Android land.
Certainly not as good as Apple, but I believe that's the best you can find in Android land.
I think your take on this is very wrong.
An open source driver written once will work for all future versions of Fuschia. Right? That reduces the effort for open source developers enormously.
Most security flaws come in above the driver level. Right? Being able to update the OS, despite the hardware manufacturer's laziness, is a huge boon for everyone.
Fuschia is open source. Drivers written for one Fuschia (say, the one Google controls) should work for another Fuschia (say, the one you and your friend forked.) Right? That's a huge win for you.
Whatever incentives you have imagined that hardware manufacturers have, time has proven those incentives don't work. It's far better to take as much control away from them as possible. They will do the minimum amount of work necessary (write new drivers). Then we can all exploit the hardware + driver + Fuschia system.
It has always, and will always, be possible to build propriety drivers. This is minimizing the blast radius of them never being updated, as much as possible.
For these reasons and more, we should all hope Fuschia is successful.
The Android developers who have tried to live on top of Linux are sick of the problems that Linux brings them. Fuschia is an open source direct response to those limitations. It's stunning to me that you would wish them to fail.
"then any improvement that could be added to Fuschia could be added to Linux". Explain to me why we still have BSD? Not all problems are solved by Linux. The sooner you accept that, the better off we will all be.
It's like you're wishing Clang would die, because we can always just improve GCC. That's demonstrably false. Just like saying everything good in Fuschia can be added to Linux. No, it can't.
"We don't need a new operating system whose only advantage is that it's easier to write proprietary drivers."
Wait, if it's easier to write propriety drivers, doesn't that lower the barrier to making low-cost phones? Well, Christ, sign me up. Do you have any idea how many billion people have a low-cost smart phone as their first computing device? If we lower the cost even more, that will broaden the reach even more.
Do you seriously not get that the other major phone OS is completely closed source? Maybe put a little faith in the people who have developed the most successful competing operating system that's open source?
An open source driver written once will work for all future versions of Fuschia. Right? That reduces the effort for open source developers enormously.
Most security flaws come in above the driver level. Right? Being able to update the OS, despite the hardware manufacturer's laziness, is a huge boon for everyone.
Fuschia is open source. Drivers written for one Fuschia (say, the one Google controls) should work for another Fuschia (say, the one you and your friend forked.) Right? That's a huge win for you.
Whatever incentives you have imagined that hardware manufacturers have, time has proven those incentives don't work. It's far better to take as much control away from them as possible. They will do the minimum amount of work necessary (write new drivers). Then we can all exploit the hardware + driver + Fuschia system.
It has always, and will always, be possible to build propriety drivers. This is minimizing the blast radius of them never being updated, as much as possible.
For these reasons and more, we should all hope Fuschia is successful.
The Android developers who have tried to live on top of Linux are sick of the problems that Linux brings them. Fuschia is an open source direct response to those limitations. It's stunning to me that you would wish them to fail.
"then any improvement that could be added to Fuschia could be added to Linux". Explain to me why we still have BSD? Not all problems are solved by Linux. The sooner you accept that, the better off we will all be.
It's like you're wishing Clang would die, because we can always just improve GCC. That's demonstrably false. Just like saying everything good in Fuschia can be added to Linux. No, it can't.
"We don't need a new operating system whose only advantage is that it's easier to write proprietary drivers."
Wait, if it's easier to write propriety drivers, doesn't that lower the barrier to making low-cost phones? Well, Christ, sign me up. Do you have any idea how many billion people have a low-cost smart phone as their first computing device? If we lower the cost even more, that will broaden the reach even more.
Do you seriously not get that the other major phone OS is completely closed source? Maybe put a little faith in the people who have developed the most successful competing operating system that's open source?
> An open source driver
Lost you already. Since Fuchsia uses a pushover license instead of a copyleft license, the vendors' drivers aren't going to be open source. Look how many companies today don't open-source their Linux drivers, and they're breaking the law by not doing so. It's going to be so much worse when there's "nothing" wrong with keeping them proprietary.
Lost you already. Since Fuchsia uses a pushover license instead of a copyleft license, the vendors' drivers aren't going to be open source. Look how many companies today don't open-source their Linux drivers, and they're breaking the law by not doing so. It's going to be so much worse when there's "nothing" wrong with keeping them proprietary.
> Since Fuchsia uses a pushover license instead of a copyleft license [emph. add.]
This is great term for it, thank you.
This is great term for it, thank you.
I can't claim credit for coming up with it: that honor goes to RMS and the FSF. See https://www.gnu.org/licenses/license-compatibility.html and https://www.gnu.org/licenses/license-recommendations.html#sm...
Huh; I've actually read both of those before and not noticed that, so still thanks for bringing it to my attention, although now I feel a bit bad about my own reading comprehension.
However hard it is to produce an open source driver, that's how hard it is. Sometimes the hardware vendors do it. Sometimes dedicated developers produce an open source, clean room driver.
So, when an open source driver exists, Fuschia will make it useful for a long time.
So, when an open source driver exists, Fuschia will make it useful for a long time.
With linux they are required to release some version of their driver even if its for an old kernel. Without any source it will be hard to produce a driver ever. Look at nvidia cards which still have shit drivers after how many years?
Further its entirely possible for a device to require signed drivers and their is even a security incentive to doing so. They don't have to ever let you have your own drivers for their hardware.
Further its entirely possible for a device to require signed drivers and their is even a security incentive to doing so. They don't have to ever let you have your own drivers for their hardware.
There exists hardware that you are screwed by. How is that Fuschia's fault? How is that anyone in the open source operating system world's fault? Given the fact that some hardware is completely impenetrable, why would someone wish harm upon Fuschia?
A multi billion dollar company doesn't need you to shield its efforts from criticism. You have somehow anthropomorphized an OS project and are treating it like a frail animal in need of your protection. It's composed of actual adults who presumably can read critical comments without coming to "harm".
Hardware running software that is either proprietary or based on permissively licensed software is everywhere. It's usually impractical or impossible to run your own software on such devices. There is no particular reason to trust Google any more than any other big company. Corporate persons judged by the moral standards one would apply to people are nearly always bad people even wherein most of the people therein are OK to good. Trusting them beyond their own self interest is nearly always a mistake.
Hardware running software that is either proprietary or based on permissively licensed software is everywhere. It's usually impractical or impossible to run your own software on such devices. There is no particular reason to trust Google any more than any other big company. Corporate persons judged by the moral standards one would apply to people are nearly always bad people even wherein most of the people therein are OK to good. Trusting them beyond their own self interest is nearly always a mistake.
No, I mean, you are blaming one project, Fuschia, for something no project can fix.
Therefore, your criticism is completely without merit, and should be ignored entirely.
1) Fuschia doesn't have a property. (It doesn't compel hardware vendors to provide open source drivers.)
2) No other operating system can possibly have that property either.
3) Therefore Fuschia should die, to help one of those other operating systems succeed.
Do you not see the flaw in this argument?
Therefore, your criticism is completely without merit, and should be ignored entirely.
1) Fuschia doesn't have a property. (It doesn't compel hardware vendors to provide open source drivers.)
2) No other operating system can possibly have that property either.
3) Therefore Fuschia should die, to help one of those other operating systems succeed.
Do you not see the flaw in this argument?
As the owners of the platform Google logically they COULD require all oems to ship open drivers as a condition of using the software. My criticism lays out legitimate concerns as a potential user to a potential user. I don't think it has to have an actionable solution by a third party to be valid. It merely has to connect with objective reality and have a well supported line of reasoning. If you are looking for an actionable item I suggest waiting and seeing how open the platform is and not investing development time or dollars in it if its even less so than android.
As an alternative I suggest you look at actual Linux devices even if they are objectively worse if they are more open.
As an alternative I suggest you look at actual Linux devices even if they are objectively worse if they are more open.
Fuchsia could have fixed it by being copyleft licensed. That doesn't preclude in any way having a stable interface for drivers.
Hardware vendors are under no obligation to use Fuschia. Therefore, you have still not compelled hardware vendors to provide open source drivers.
Linux has not compelled Nvidia to produce good OpenGL drivers.
No, really, walk me through this.
Linux has not compelled Nvidia to produce good OpenGL drivers.
No, really, walk me through this.
Nvidia actually DOES have good OpenGL drivers that are unfortunately proprietary. AMD GPU drivers have been getting progressively better to where they represent a valid alternative for gaming. Intel GPU drivers have long been good enough for general use.
I think the principal is that if Google had licensed Fuchsia in such a way as to require release of source code to kernel modules that companies would rightly fear being sued for violating the copyright of a mega corp like google in a way that GPL violators don't fear say the free software foundation.
I think the principal is that if Google had licensed Fuchsia in such a way as to require release of source code to kernel modules that companies would rightly fear being sued for violating the copyright of a mega corp like google in a way that GPL violators don't fear say the free software foundation.
> Nvidia actually DOES have good OpenGL drivers that are unfortunately proprietary.
I think this proves GP's point.
I think this proves GP's point.
As a developer of a Fuchsia fork, I couldn't agree more. Unfortunately, not all components are opensource ATM, (like the khadas VIM2 bootloader), but at least they are available.
Can you tell us more about the goals of your fork?
I'd love to see a list of the problems you have with Fuschia or how Fuschia is being managed. Maybe as a new top-level post on HN?
I'd love to see a list of the problems you have with Fuschia or how Fuschia is being managed. Maybe as a new top-level post on HN?
It's a negotiation, and the hardware vendors seem to be 100% happy stepping away from the table and letting old hardware suffer.
They have a lot more leverage than we FOSS supporters do.
They have a lot more leverage than we FOSS supporters do.
What this is really about is Qualcomm. They have inadequate competition and that allows them to abuse everybody else.
In a competitive market, open source drivers win. Look at the desktop market -- nearly everything is open source, and the biggest holdout is nVidia, because for a while there nobody was challenging them on performance. Now that AMD has competitive GPUs again, not only does that provide a competitive option with open source drivers, nVidia is now losing market share to them.
OEMs don't really like proprietary drivers. They're a pain. Whenever new driver versions come out, it becomes the OEM's problem to test and distribute them instead of having the Linux kernel team deal with that hassle. The open source drivers also generally have fewer bugs (because anybody can fix them), which leads to fewer support calls and more satisfied customers who make repeat purchases.
And customers naturally prefer hardware with longer hardware support, when it's available.
What we need is more competition for Qualcomm. Google could do that if they wanted to -- throw some money at making competing phone chips. Apple does it, why can't they? And then publish open source drivers and sell the chips to anybody.
We also have AMD as a dark horse now. The Ryzen 4000 series goes down to 10 watts -- it's so power efficient you could squeeze it into an Android tablet as-is (and then be a lot faster than most tablets), and it wouldn't take much on AMD's part to do something that could work in a phone. Android is an open source system with apps that run on the JVM, so the architectural difference shouldn't matter much.
Or we could get the antitrust authorities to stop letting Qualcomm buy every competitor that springs up, which they've been doing for years.
But you solve the competition problem and you get open source drivers. Along with all the other benefits of real competition.
In a competitive market, open source drivers win. Look at the desktop market -- nearly everything is open source, and the biggest holdout is nVidia, because for a while there nobody was challenging them on performance. Now that AMD has competitive GPUs again, not only does that provide a competitive option with open source drivers, nVidia is now losing market share to them.
OEMs don't really like proprietary drivers. They're a pain. Whenever new driver versions come out, it becomes the OEM's problem to test and distribute them instead of having the Linux kernel team deal with that hassle. The open source drivers also generally have fewer bugs (because anybody can fix them), which leads to fewer support calls and more satisfied customers who make repeat purchases.
And customers naturally prefer hardware with longer hardware support, when it's available.
What we need is more competition for Qualcomm. Google could do that if they wanted to -- throw some money at making competing phone chips. Apple does it, why can't they? And then publish open source drivers and sell the chips to anybody.
We also have AMD as a dark horse now. The Ryzen 4000 series goes down to 10 watts -- it's so power efficient you could squeeze it into an Android tablet as-is (and then be a lot faster than most tablets), and it wouldn't take much on AMD's part to do something that could work in a phone. Android is an open source system with apps that run on the JVM, so the architectural difference shouldn't matter much.
Or we could get the antitrust authorities to stop letting Qualcomm buy every competitor that springs up, which they've been doing for years.
But you solve the competition problem and you get open source drivers. Along with all the other benefits of real competition.
Qualcomm has plenty of competitors. Mediatek, Allwinner, Samsung, Broadcom etc. They all have the exact same issues wrt. driver support: they do the minimum work required to bring up their board with one heavily-patched kernel version, and that's it. Allwinner now has quite decent support from the mainline kernel, but only because of 3rd-party efforts. It's not just Qualcomm: these problems are shared by every embedded SoC to date, with very limited exceptions.
The existence of other ARM SoCs doesn't mean they're competitive enough at the high end for the advantage of open source drivers to be the determining factor.
Meanwhile the low end is more sensitive to price than quality, so competition there pushes things towards things cut costs rather than things that improve the experience, or even things that reduce long term costs at the expense of short term costs.
Meanwhile the low end is more sensitive to price than quality, so competition there pushes things towards things cut costs rather than things that improve the experience, or even things that reduce long term costs at the expense of short term costs.
> Android is an open source system with apps that run on the JVM, so the architectural difference shouldn't matter much.
Android apps run on ART, not the JVM (different bytecode, similar idea): https://en.wikipedia.org/wiki/Android_Runtime
Many apps have native code as well, and Intel put a lot of time and money into automatic binary translation some years ago to make such apps work on x86 Android: https://www.anandtech.com/show/5770/lava-xolo-x900-review-th...
AMD might be able to build on that, but it was probably specific to Intel's mobile CPUs of the time (which didn't really succeed), and I don't know what's happened since.
Android apps run on ART, not the JVM (different bytecode, similar idea): https://en.wikipedia.org/wiki/Android_Runtime
Many apps have native code as well, and Intel put a lot of time and money into automatic binary translation some years ago to make such apps work on x86 Android: https://www.anandtech.com/show/5770/lava-xolo-x900-review-th...
AMD might be able to build on that, but it was probably specific to Intel's mobile CPUs of the time (which didn't really succeed), and I don't know what's happened since.
I'm a strong FOSS proponent, most of my software is released under MIT, I use Linux daily and help others to use open source as much as I can.
And yet I find this idea total BS.
The reason I could even migrate to Linux when I was a teen was compatibility. It's because free softwares (VLC, Firefox, OOo...) were ported to Windows, a proprietary plateform, so that I could then feel at home later on Linux. And I made a definitive switch thanks to Ubuntu, because it made using most hardware easy, by accepting to use proprietary drivers when required.
Strong arming the industry into Libre never worked. The GPL is one of the least popular licences for this very reason. I, myself, never uses it.
Representing close source as evil doesn't work either.
It's like being vegetarian (which I am) and guilt triping people about meat. It's completly counter productive.
The result we got is that the year of Linux on the desktop never happened, because playing on Linux is hard, because the last cool gadget doesn't work, because you have to carefully chose your laptop to be sure it will work with it (E.G: my XPS 2-in-1 webcam doesn't work on Linux).
It also adds a lot of work to the kernel devs to try to keep up with the outter world, but they have a limited bandwith.
So Linux BT still sucks (even more than regular BT). Wifi is still not on part with the XP on other OS. Batter life is abysmal (I'm dual booting, and the difference is X2).
All for an ideal we never reached anyway.
Help and encouraging for FOSS makes a better world.
Being pushy about it hurts us.
And yet I find this idea total BS.
The reason I could even migrate to Linux when I was a teen was compatibility. It's because free softwares (VLC, Firefox, OOo...) were ported to Windows, a proprietary plateform, so that I could then feel at home later on Linux. And I made a definitive switch thanks to Ubuntu, because it made using most hardware easy, by accepting to use proprietary drivers when required.
Strong arming the industry into Libre never worked. The GPL is one of the least popular licences for this very reason. I, myself, never uses it.
Representing close source as evil doesn't work either.
It's like being vegetarian (which I am) and guilt triping people about meat. It's completly counter productive.
The result we got is that the year of Linux on the desktop never happened, because playing on Linux is hard, because the last cool gadget doesn't work, because you have to carefully chose your laptop to be sure it will work with it (E.G: my XPS 2-in-1 webcam doesn't work on Linux).
It also adds a lot of work to the kernel devs to try to keep up with the outter world, but they have a limited bandwith.
So Linux BT still sucks (even more than regular BT). Wifi is still not on part with the XP on other OS. Batter life is abysmal (I'm dual booting, and the difference is X2).
All for an ideal we never reached anyway.
Help and encouraging for FOSS makes a better world.
Being pushy about it hurts us.
I disagree. For starters, strong arming the industry has worked in a number of cases; this has been covered in a few other comment threads so I won't retread them too much here, but the state of free drivers on Linux is significantly better than it was just a few years ago.
More broadly though: what kind of world do you want to live in? A world where it's easy for companies to create new proprietary software, or a world where it's easy for the users to shape their computing experience?
Look around you, at the consumer devices you own. Can you name one that's: 1) aimed at consumers (i.e. not a dev board, Raspberry Pis and such don't count here) and 2) that you have most or all of the source code to?
Look, if your goal is just "make better software" in general, maybe permissive open source has been a success. But if your goal is to increase practical user freedom, it's been an abject failure. It's just helped companies to make proprietary software more cheaply. And sure, there's some interesting technology that comes out of that for developers, but in the vast majority of cases the users don't see the benefits! Surveillance capitalism marches on, bolstered by the free labor of the community.
This is why I've been so disheartened that parts of the community have turned so anti-copyleft recently. In a world of permissively licensed software, the incentives are stacked against free software for end users. In a world of GPL'd software, you can release your code as GPL too, or you can pay more to write it all yourself.
More broadly though: what kind of world do you want to live in? A world where it's easy for companies to create new proprietary software, or a world where it's easy for the users to shape their computing experience?
Look around you, at the consumer devices you own. Can you name one that's: 1) aimed at consumers (i.e. not a dev board, Raspberry Pis and such don't count here) and 2) that you have most or all of the source code to?
Look, if your goal is just "make better software" in general, maybe permissive open source has been a success. But if your goal is to increase practical user freedom, it's been an abject failure. It's just helped companies to make proprietary software more cheaply. And sure, there's some interesting technology that comes out of that for developers, but in the vast majority of cases the users don't see the benefits! Surveillance capitalism marches on, bolstered by the free labor of the community.
This is why I've been so disheartened that parts of the community have turned so anti-copyleft recently. In a world of permissively licensed software, the incentives are stacked against free software for end users. In a world of GPL'd software, you can release your code as GPL too, or you can pay more to write it all yourself.
> the state of free drivers on Linux is significantly better than it was just a few years ago.
Of course, but I think you can thank phones, the internet and the economy of scale for that. Not strong arming.
You will always find examples of times where something worked. But each one I can see 10 examples of companies that said "nope" during one of my mission.
> what kind of world do you want to live in? A world where it's easy for companies to create new proprietary software, or a world where it's easy for the users to shape their computing experience?
It's a false dichotomy. It's not us vs them.
There is no them. It's just all us.
> Surveillance capitalism marches on, bolstered by the free labor of the community.
That's a sociological problem, you won't solve that with software. Or licences.
For that you need to get into politics or business.
> This is why I've been so disheartened that parts of the community have turned so anti-copyleft recently.
I haven't see that at all. Open source has never been so popular. Creative common as well.
What I do see is a complexification of software, that requires more and more resources, which the FOSS world has a hard time to keep up with.
What I do see is a mass of people comming to software that don't care at all about those topics, but only about usability, which the FOSS world has a hard time to keep up with.
I'm glad VLC didn't decide that they couldn't read DVD, or OOo read .doc because there were proprietary formats, otherwise they wouldn't have been the popular softwares of today.
Today LibreOffice is replacing MS office in many administrations and schools. The alternative would have been Google doc.
You think making Linux more restrictive would have forced industrials to be more conciliant?
No, they would just have used more proprietary softwares. The entire stack if necessary, and we would never have had Linux on mobile. Instead, we would have had a black box.
The open source mouvement is not "free to everyone to use and modify, except the ones that don't contribute and profit from it".
That would be a very bitter point of reaction, not positive action.
Of course, but I think you can thank phones, the internet and the economy of scale for that. Not strong arming.
You will always find examples of times where something worked. But each one I can see 10 examples of companies that said "nope" during one of my mission.
> what kind of world do you want to live in? A world where it's easy for companies to create new proprietary software, or a world where it's easy for the users to shape their computing experience?
It's a false dichotomy. It's not us vs them.
There is no them. It's just all us.
> Surveillance capitalism marches on, bolstered by the free labor of the community.
That's a sociological problem, you won't solve that with software. Or licences.
For that you need to get into politics or business.
> This is why I've been so disheartened that parts of the community have turned so anti-copyleft recently.
I haven't see that at all. Open source has never been so popular. Creative common as well.
What I do see is a complexification of software, that requires more and more resources, which the FOSS world has a hard time to keep up with.
What I do see is a mass of people comming to software that don't care at all about those topics, but only about usability, which the FOSS world has a hard time to keep up with.
I'm glad VLC didn't decide that they couldn't read DVD, or OOo read .doc because there were proprietary formats, otherwise they wouldn't have been the popular softwares of today.
Today LibreOffice is replacing MS office in many administrations and schools. The alternative would have been Google doc.
You think making Linux more restrictive would have forced industrials to be more conciliant?
No, they would just have used more proprietary softwares. The entire stack if necessary, and we would never have had Linux on mobile. Instead, we would have had a black box.
The open source mouvement is not "free to everyone to use and modify, except the ones that don't contribute and profit from it".
That would be a very bitter point of reaction, not positive action.
>There is no them. It's just all us.
In many contexts I would agree, but not here. Say I buy a device, and people discover later that it has surveillance code in it. Why can I not just remove it myself? Who do I need to talk to? The developer of that proprietary code. That's "them."
>That's a sociological problem, you won't solve that with software. Or licences.
>For that you need to get into politics or business.
There are many different angles you can take to approach a problem. One of which is politics, sure: we could outlaw software that surveils its users without consent. That's one approach. But a technical approach is also valid: if all software were free, do you really think users would just accept big tech companies surveilling them? Don't you think we'd have people removing the tracking code, and telling their friends how to do the same?
And by the way, one of the things we see over and over again from the business world is that incentives matter. No, I don't think all companies would have freed their code if the GPL were prevalent, but if it's significantly easier to make their code free than it is to make it proprietary, certainly more of them would. Just look at the state of Linux drivers on x86: how many of them are free these days, and how many of them are proprietary? There are a few high-profile proprietary drivers, but by and large most of them are free. That's meaningful progress! How many of your drivers are free on Windows?
>I haven't see that at all. Open source has never been so popular. Creative common as well.
"Open source" has had a surge in popularity, sure, but its current popularity has more to do with corporate interests than an interest in user freedom - which, of course, was why the term was coined in the first place. As a percentage of that software, the use of copyleft licenses has declined in recent years.
>I'm glad VLC didn't decide that they couldn't read DVD, or OOo read .doc because there were proprietary formats, otherwise they wouldn't have been the popular softwares of today.
Of course supporting existing proprietary formats for the purposes of drawing users to free software is a good thing! I just don't think we should be contributing to the development of more proprietary software. VLC and LibreOffice are both extremely valuable free software projects. (And by the way, they're both copyleft - OpenOffice isn't, but most development has shifted to LibreOffice these days.)
>The open source mouvement is not "free to everyone to use and modify, except the ones that don't contribute and profit from it".
Of course not! Anyone is free to use and modify any free software, including copyleft software. But I think copyleft is a valuable tool to help us build a software commons.
In many contexts I would agree, but not here. Say I buy a device, and people discover later that it has surveillance code in it. Why can I not just remove it myself? Who do I need to talk to? The developer of that proprietary code. That's "them."
>That's a sociological problem, you won't solve that with software. Or licences.
>For that you need to get into politics or business.
There are many different angles you can take to approach a problem. One of which is politics, sure: we could outlaw software that surveils its users without consent. That's one approach. But a technical approach is also valid: if all software were free, do you really think users would just accept big tech companies surveilling them? Don't you think we'd have people removing the tracking code, and telling their friends how to do the same?
And by the way, one of the things we see over and over again from the business world is that incentives matter. No, I don't think all companies would have freed their code if the GPL were prevalent, but if it's significantly easier to make their code free than it is to make it proprietary, certainly more of them would. Just look at the state of Linux drivers on x86: how many of them are free these days, and how many of them are proprietary? There are a few high-profile proprietary drivers, but by and large most of them are free. That's meaningful progress! How many of your drivers are free on Windows?
>I haven't see that at all. Open source has never been so popular. Creative common as well.
"Open source" has had a surge in popularity, sure, but its current popularity has more to do with corporate interests than an interest in user freedom - which, of course, was why the term was coined in the first place. As a percentage of that software, the use of copyleft licenses has declined in recent years.
>I'm glad VLC didn't decide that they couldn't read DVD, or OOo read .doc because there were proprietary formats, otherwise they wouldn't have been the popular softwares of today.
Of course supporting existing proprietary formats for the purposes of drawing users to free software is a good thing! I just don't think we should be contributing to the development of more proprietary software. VLC and LibreOffice are both extremely valuable free software projects. (And by the way, they're both copyleft - OpenOffice isn't, but most development has shifted to LibreOffice these days.)
>The open source mouvement is not "free to everyone to use and modify, except the ones that don't contribute and profit from it".
Of course not! Anyone is free to use and modify any free software, including copyleft software. But I think copyleft is a valuable tool to help us build a software commons.
Everyone is having their go at this, blame younger generations for fighting GPL, while favouring other license models.
GPL is the only reason Linux still exits, not for long though, when even Linux Foundation has decided to go with something else for IoT, namely Zephyr, which is neither Linux based, nor under GPL license.
In about 20 years we will be back at shareware and public domain, enjoy what is left while it lasts.
It doesn't matter if Fucschia is a success, Android is already like this, since Project Treble, Linux drivers are "legacy" drivers on Android, all new drivers use a microkernel approach with Android IPC, basically how Fuschia drivers work.
GPL is the only reason Linux still exits, not for long though, when even Linux Foundation has decided to go with something else for IoT, namely Zephyr, which is neither Linux based, nor under GPL license.
In about 20 years we will be back at shareware and public domain, enjoy what is left while it lasts.
It doesn't matter if Fucschia is a success, Android is already like this, since Project Treble, Linux drivers are "legacy" drivers on Android, all new drivers use a microkernel approach with Android IPC, basically how Fuschia drivers work.
The Linux Foundation has a misleading name: it's essentially the Megacorporations Linux User Group. It wants whatever its member companies want. It does not really want to promote Linux or, say, enforce the GPL.
Indeed, and while I am mostly a user of commercial software, I appreciate the work that Stallman and FSF have placed on the GPL.
Whatever non-copyleft licenses allow for, it was already available via public domain and shareware like licenses.
Yes, GPL makes is very hard for certain kinds of business models like games or desktop software in general, however when people complain about its existence, most seem to blind to the fact that they only have Linux and GCC because of GPL, and clang wasn't around until 2007.
Had it not been for them, and most likely all commercial UNIXes would still be around.
Whatever non-copyleft licenses allow for, it was already available via public domain and shareware like licenses.
Yes, GPL makes is very hard for certain kinds of business models like games or desktop software in general, however when people complain about its existence, most seem to blind to the fact that they only have Linux and GCC because of GPL, and clang wasn't around until 2007.
Had it not been for them, and most likely all commercial UNIXes would still be around.
I agree with what you said, however what is even more adding to the confusion is that the Linux Foundation is Linus Torvalds' employer...
I left that out to avoid opening a can of worms, but yeah...
If I was Linus, I might also avoid raising a stink because the Linux foundation does a few things that need to be done, and the damage it is doing might be less bad than what happens after discrediting it.
If I was Linus, I might also avoid raising a stink because the Linux foundation does a few things that need to be done, and the damage it is doing might be less bad than what happens after discrediting it.
I guess that Linux will quickly get an "NDISwrapper" equivalent that can run Fuchsia binary blobs. We'll all be a little bit worse off as a result, but with mostly working peripherals.
> We already have a high quality kernel: Linux.
Linux is full of security bugs. It is ludicrous to suggest Linux is high quality. OpenBSD, maybe. Not Linux.
Linux is full of security bugs. It is ludicrous to suggest Linux is high quality. OpenBSD, maybe. Not Linux.
Citation needed :)
Seriously, all software has bugs, how do you judge the quality of an operating system that is not finished?
Seriously, all software has bugs, how do you judge the quality of an operating system that is not finished?
Does Google itself help?
https://events19.linuxfoundation.org/wp-content/uploads/2017...
https://outflux.net/slides/2019/lss/kspp.pdf
Slides from 2018 and 2019 talks.
https://events19.linuxfoundation.org/wp-content/uploads/2017...
https://outflux.net/slides/2019/lss/kspp.pdf
Slides from 2018 and 2019 talks.
The fact that Linux doesn't have a binary-compatible driver interface is a good thing: It means hardware vendors have a very strong incentive to get their drivers upstream into the kernel.
I think it is a horrible thing and a reason to deter hardware vendors from supporting Linux at all. Even with the best intentions and open source drivers, it adds maintenance burdons to the hardware manufacturers. And some hardware vendors cannot go open source at all, as they might have licensed other code to implement their drivers or have other valid concerns not to open up their drivers entirely, like for IP protection.
I think it is a horrible thing and a reason to deter hardware vendors from supporting Linux at all. Even with the best intentions and open source drivers, it adds maintenance burdons to the hardware manufacturers. And some hardware vendors cannot go open source at all, as they might have licensed other code to implement their drivers or have other valid concerns not to open up their drivers entirely, like for IP protection.
This has only happened on Linux for commodity hardware. But Nvidia and others (hpc interconnects, routers,...) usually ship their own proprietary drivers, or even Linux forks.
I would say this is one of their biggest advantage over Linux.
>> This would allow for a much more competitive, and higher quality, software, and hardware ecosystem on mobile platforms.
I have no idea why you think that. Any proof? How would you measure it?
>> It makes it possible to build proprietary drivers
End users do not care about opensource vs closed source, they care about the user experience. Based on your thesis, Linux would be the best operating system with the most market share out there because it features everything you say, yet it has a negligible share on desktop. Empirically proving your thesis being wrong.
>> This would allow for a much more competitive, and higher quality, software, and hardware ecosystem on mobile platforms.
I have no idea why you think that. Any proof? How would you measure it?
>> It makes it possible to build proprietary drivers
End users do not care about opensource vs closed source, they care about the user experience. Based on your thesis, Linux would be the best operating system with the most market share out there because it features everything you say, yet it has a negligible share on desktop. Empirically proving your thesis being wrong.
> It makes it possible to build proprietary drivers.
Even worse, Fuchsia aims to be BSD License, not GPL. Fuchsia is a complete disaster for hobby OS makers.
Even worse, Fuchsia aims to be BSD License, not GPL. Fuchsia is a complete disaster for hobby OS makers.
Apparently everyone is unhappy with GPL.
In a couple of years the same people will understand why it exists in first place.
I guess they are having fun running FreeBSD on their PS4s, thanks to Sony, hence why they aren't paying attention.
In a couple of years the same people will understand why it exists in first place.
I guess they are having fun running FreeBSD on their PS4s, thanks to Sony, hence why they aren't paying attention.
*Fuchsia
A big reason why Fuchsia exists is governance — Google wants to make a kernel that it controls. Linux cannot provide that advantage unless Google forks it.
> Fuchsia's goal is to power production devices and products used for business-critical applications. As such, Fuchsia is not a playground for experimental operating system concepts. Instead, the platform roadmap is driven by practical use cases arising from partner and product needs.
This is an interesting statement given how many relatively unpopular OS concepts it integrates. I am interested in seeing this succeed. I hope that Fuschia helps drive capability-based sandboxing of end-user software.
This is an interesting statement given how many relatively unpopular OS concepts it integrates. I am interested in seeing this succeed. I hope that Fuschia helps drive capability-based sandboxing of end-user software.
Yes. That is what we as users most need.
Application sandboxing from first principles and the very bottom
Application sandboxing from first principles and the very bottom
Sounds a bit like a modern, open approach to the problems that were solved by QNX. Excited to see how it evolves!
Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones.
Like they did to Android with Google Play Services.
[1] https://cla.developers.google.com/about/google-individual
Like they did to Android with Google Play Services.
[1] https://cla.developers.google.com/about/google-individual
Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a bit to open-source projects.
Disclaimer: I'm not a lawyer, this is not legal advice, etc.
I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change that.
The Google ICLA you cited [1] is basically the same as the ASF ICLA [2]; the gist is that you retain copyright of your contributions, you're not giving up your copyright — i.e., it's a copyright license, not a copyright assignment (as some other CLAs are).
And, naturally, anyone can fork it if they wish, or distribute proprietary, non-open-source versions of an Apache/BSD/MIT-licensed project, subject to appropriate attributions, if required, by the relevant licenses.
However, neither you (nor Google) can claim copyright over the entire project, because the copyrights are held by the relevant contributors. Changing the license for the entire project requires agreement from all copyright holders — for example, see what LLVM had to do when they chose to add a clause to their license [3].
[1] https://cla.developers.google.com/about/google-individual
[2] https://www.apache.org/licenses/icla.pdf
[3] https://llvm.org/foundation/relicensing/
Disclaimer: I'm not a lawyer, this is not legal advice, etc.
I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change that.
The Google ICLA you cited [1] is basically the same as the ASF ICLA [2]; the gist is that you retain copyright of your contributions, you're not giving up your copyright — i.e., it's a copyright license, not a copyright assignment (as some other CLAs are).
And, naturally, anyone can fork it if they wish, or distribute proprietary, non-open-source versions of an Apache/BSD/MIT-licensed project, subject to appropriate attributions, if required, by the relevant licenses.
However, neither you (nor Google) can claim copyright over the entire project, because the copyrights are held by the relevant contributors. Changing the license for the entire project requires agreement from all copyright holders — for example, see what LLVM had to do when they chose to add a clause to their license [3].
[1] https://cla.developers.google.com/about/google-individual
[2] https://www.apache.org/licenses/icla.pdf
[3] https://llvm.org/foundation/relicensing/
>> If you submit code, you grant a license to Google to use it in non-proprietary [sic, I assume] code.
> it's a copyright license, not a copyright assignment
>> So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones.
> you're welcome to fork it if you wish, or distribute proprietary, non-open-source versions of the code
It sounds like you're agreeing completely with everything the parent said.
> it's a copyright license, not a copyright assignment
>> So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones.
> you're welcome to fork it if you wish, or distribute proprietary, non-open-source versions of the code
It sounds like you're agreeing completely with everything the parent said.
Sorry for not making it more clear; I was responding to the statement:
> Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones.
The CLA does not change anything about the license, and does not prevent or make it possible (or easier) to make proprietary versions of the software (or your contributions) — all those conditions are in the license itself, the CLA does not override or amend any terms of the license.
In other words, you can make the same argument about any Apache, BSD, or MIT software, while the poster is claiming that it's the CLA that enables making future releases proprietary, which is why I pointed out that the Google CLA is the same as the ASF CLA.
If the argument is that Apache/BSD/MIT licenses are "not really open" because they allow incorporating them into proprietary software without releasing code, that's a different argument and is really a distinction between the "permissive" licenses like Apache/BSD/MIT and the "copyleft" licenses like GPL, but again, that has nothing to do with the CLA.
> Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones.
The CLA does not change anything about the license, and does not prevent or make it possible (or easier) to make proprietary versions of the software (or your contributions) — all those conditions are in the license itself, the CLA does not override or amend any terms of the license.
In other words, you can make the same argument about any Apache, BSD, or MIT software, while the poster is claiming that it's the CLA that enables making future releases proprietary, which is why I pointed out that the Google CLA is the same as the ASF CLA.
If the argument is that Apache/BSD/MIT licenses are "not really open" because they allow incorporating them into proprietary software without releasing code, that's a different argument and is really a distinction between the "permissive" licenses like Apache/BSD/MIT and the "copyleft" licenses like GPL, but again, that has nothing to do with the CLA.
That's a very fair point. Thanks for clarifying.
The thing is that anyone can make that fork and use the code on a proprietary system, not only google. The same that apple did with the mach kernel and any other one could have done.
dilandau(2)
> And, naturally, anyone can fork it if they wish, or distribute proprietary, non-open-source versions of an Apache/BSD/MIT-licensed project, subject to appropriate attributions, if required, by the relevant licenses.
so, basically you submit free labor for the use by for-profit corporations, but you dont get those same freedoms to do so on your own devices, got it
personally, i wouldnt mind so much if users of submitted code were payed "dividends" for ones labor when used in propriatary for-profit services/products, but seing as that is not the case, well, i cannot abide...
so, basically you submit free labor for the use by for-profit corporations, but you dont get those same freedoms to do so on your own devices, got it
personally, i wouldnt mind so much if users of submitted code were payed "dividends" for ones labor when used in propriatary for-profit services/products, but seing as that is not the case, well, i cannot abide...
The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler. What the CLA does not prohibit is proprietary use—- your lengthy answer. The OP makes the point that Google will find a way to use public contributions for Google’s own profit.
The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer” which is what has alienated so many people from Google. The problem I’ve repeatedly experienced in Google open source and as a Google Cloud customer (contract with Google FDEs on-site) is that Googlers just don’t listen. You can’t trample the customer with your own narrative no matter how correct and elegant it is. You can disagree, but you can’t deny the feelings of others. It just doesn’t work that way.
The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer” which is what has alienated so many people from Google. The problem I’ve repeatedly experienced in Google open source and as a Google Cloud customer (contract with Google FDEs on-site) is that Googlers just don’t listen. You can’t trample the customer with your own narrative no matter how correct and elegant it is. You can disagree, but you can’t deny the feelings of others. It just doesn’t work that way.
Disclaimer: I'm not a lawyer and this is not legal advice.
I've added a clarification separately, please take a look there first: https://news.ycombinator.com/item?id=23365469
> The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler.
I think we are using different definitions of "proprietary". I'm using it to mean "non-open-source" [1], and you're using it to mean "employed by a specific company" (or something else); can you please clarify what you mean or rephrase what you're trying to say?
> What the CLA does not prohibit is proprietary use—- your lengthy answer. The OP makes the point that Google will find a way to use public contributions for Google’s own profit.
That's not the purpose of a CLA; that's the purpose of a project's license. That was the point of my post. Anyone can take a project with an Apache/BSD/MIT license (whether or not the project has a CLA, it's orthogonal), make a proprietary product from it, distribute it, sell it, etc. and they would be just fine doing it, without also sharing any of the source.
To put it another way, a CLA cannot restrict proprietary or commercial use of a patch or contribution, if the underlying project license is Apache/BSD/MIT, because all those licenses already allow commercial use, incorporating software into proprietary / closed-source products, etc. Such a CLA would be incompatible with the project's license.
I've never seen an Apache/BSD/MIT project where the CLA (and only the CLA) prohibits commercial / proprietary / closed-source or any other use cases — if you have an example or two, could you please point them out? I'm very curious to see how this would work in practice, because this seems like a strong contradiction, so I would be interested to see how this plays out in practice.
[1] https://en.wikipedia.org/wiki/Proprietary_software
I've added a clarification separately, please take a look there first: https://news.ycombinator.com/item?id=23365469
> The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler.
I think we are using different definitions of "proprietary". I'm using it to mean "non-open-source" [1], and you're using it to mean "employed by a specific company" (or something else); can you please clarify what you mean or rephrase what you're trying to say?
> What the CLA does not prohibit is proprietary use—- your lengthy answer. The OP makes the point that Google will find a way to use public contributions for Google’s own profit.
That's not the purpose of a CLA; that's the purpose of a project's license. That was the point of my post. Anyone can take a project with an Apache/BSD/MIT license (whether or not the project has a CLA, it's orthogonal), make a proprietary product from it, distribute it, sell it, etc. and they would be just fine doing it, without also sharing any of the source.
To put it another way, a CLA cannot restrict proprietary or commercial use of a patch or contribution, if the underlying project license is Apache/BSD/MIT, because all those licenses already allow commercial use, incorporating software into proprietary / closed-source products, etc. Such a CLA would be incompatible with the project's license.
I've never seen an Apache/BSD/MIT project where the CLA (and only the CLA) prohibits commercial / proprietary / closed-source or any other use cases — if you have an example or two, could you please point them out? I'm very curious to see how this would work in practice, because this seems like a strong contradiction, so I would be interested to see how this plays out in practice.
[1] https://en.wikipedia.org/wiki/Proprietary_software
I think a nice example that could help clarify the situation is the CLA that Canonical uses; if I remember correctly they reserve to themselves the right to change the license of community contributions.
Looking at the Canonical CLA [1], you're right that it allows Canonical the right to relicense contributions under any other license:
> 2.3 Outbound License
> Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. [...]
However, please note that my original comment [2] was asking for a CLA which prevents usage in a proprietary setting, while the project is under a permissive license like Apache/BSD/MIT (emphasis added):
> I've never seen an Apache/BSD/MIT project where the CLA (and only the CLA) prohibits commercial / proprietary / closed-source or any other use cases — if you have an example or two, could you please point them out?
[1] https://ubuntu.com/legal/contributors/agreement
[2] https://news.ycombinator.com/item?id=23365535
> 2.3 Outbound License
> Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. [...]
However, please note that my original comment [2] was asking for a CLA which prevents usage in a proprietary setting, while the project is under a permissive license like Apache/BSD/MIT (emphasis added):
> I've never seen an Apache/BSD/MIT project where the CLA (and only the CLA) prohibits commercial / proprietary / closed-source or any other use cases — if you have an example or two, could you please point them out?
[1] https://ubuntu.com/legal/contributors/agreement
[2] https://news.ycombinator.com/item?id=23365535
It was not directly a reply to that case, it was meant to say that even if the license was GPL so that a proprietary fork was forbidden, a CLA could make it so that only the owner of the project is allowed to use your contributions as proprietary.
It was an example of a case where a CLA could have caused what was imputed by the original comment.
It was an example of a case where a CLA could have caused what was imputed by the original comment.
That's a fair point, thanks for the clarification.
I've responded to the CLA / licensing issues in a separate sibling comment (https://news.ycombinator.com/item?id=23365535); this comment is to respond to the rest of your post as it's a separate topic that's important in its own right.
> The OP makes the point that Google will find a way to use public contributions for Google’s own profit.
That's an opinion on motivations, not a statement of fact, so I am not agreeing or disagreeing with that. My comment was only about CLAs and open-source licensing, and what each of them enables you to do (or not) with someone else's source code, and how your contributions may be used by others after you submit them, not a statement or response to their opinion.
> The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer” which is what has alienated so many people from Google. The problem I’ve repeatedly experienced in Google open source and as a Google Cloud customer (contract with Google FDEs on-site) is that Googlers just don’t listen. You can’t trample the customer with your own narrative no matter how correct and elegant it is.
I'm sorry you've had negative experiences in the past, and I'm sorry to read that my response on the distinction between CLA & open-source licenses came across as not listening or talking past the customer — that was not the intent at all.
If you're open to it, I'm happy to chat with you separately (you can easily find me on Twitter or LinkedIn and send me a message) whether you want to discuss this topic, or your other experiences with Google open-source projects, or Google Cloud, and I can try to help, or just listen. If not, that's fine, no worries.
> You can disagree, but you can’t deny the feelings of others. It just doesn’t work that way.
I'm sorry that came across as not listening; my comment was only to clarify the notion of CLAs and how they relate to open-source licenses, without delving into business goals and future roadmaps (which I have no visibility into, nor control of, in this case).
Everyone is entitled to their opinions or feelings on how a company might or might not use open-source software or their motivations for open-sourcing (or not) of a project, and I'm not here to debate, explain or defend any company's decision in that regard. Again, my comment was limited to the scope of what a CLA brings to an open-source license of a project.
> The OP makes the point that Google will find a way to use public contributions for Google’s own profit.
That's an opinion on motivations, not a statement of fact, so I am not agreeing or disagreeing with that. My comment was only about CLAs and open-source licensing, and what each of them enables you to do (or not) with someone else's source code, and how your contributions may be used by others after you submit them, not a statement or response to their opinion.
> The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer” which is what has alienated so many people from Google. The problem I’ve repeatedly experienced in Google open source and as a Google Cloud customer (contract with Google FDEs on-site) is that Googlers just don’t listen. You can’t trample the customer with your own narrative no matter how correct and elegant it is.
I'm sorry you've had negative experiences in the past, and I'm sorry to read that my response on the distinction between CLA & open-source licenses came across as not listening or talking past the customer — that was not the intent at all.
If you're open to it, I'm happy to chat with you separately (you can easily find me on Twitter or LinkedIn and send me a message) whether you want to discuss this topic, or your other experiences with Google open-source projects, or Google Cloud, and I can try to help, or just listen. If not, that's fine, no worries.
> You can disagree, but you can’t deny the feelings of others. It just doesn’t work that way.
I'm sorry that came across as not listening; my comment was only to clarify the notion of CLAs and how they relate to open-source licenses, without delving into business goals and future roadmaps (which I have no visibility into, nor control of, in this case).
Everyone is entitled to their opinions or feelings on how a company might or might not use open-source software or their motivations for open-sourcing (or not) of a project, and I'm not here to debate, explain or defend any company's decision in that regard. Again, my comment was limited to the scope of what a CLA brings to an open-source license of a project.
They aren't disagreeing. Parse what they said, and notice nothing contradicts the post they're replying to.
That's what I didn't want to say explicitly in my other comment: they made a long-winded comment that appeared to express a negative statement about what the poster said, while technically agreeing. To me, it's a perfect example of a lawyer's yes-that-sounds-like-no.
Edit: glad I didn't say this in the other comment. Shouldn't have jumped to conclusions.
That's what I didn't want to say explicitly in my other comment: they made a long-winded comment that appeared to express a negative statement about what the poster said, while technically agreeing. To me, it's a perfect example of a lawyer's yes-that-sounds-like-no.
Edit: glad I didn't say this in the other comment. Shouldn't have jumped to conclusions.
I've added a response to your earlier comment to clarify: https://news.ycombinator.com/item?id=23365469
All permissively-licensed (MIT/BSD/Apache) code has that property. If you contribute to BSD anyone can create a proprietary derivative.
Google Play Services was never open. You can however still submit changes to the actual OS though.
People said the same thing about Android in its early days. It was wrong then, still wrong now, and will likely be just as wrong in the future.
People said the same thing about Android in its early days. It was wrong then, still wrong now, and will likely be just as wrong in the future.
'Animats didn't claim they were ever open.
His claim was more along the lines of: Google Play Services has over time subsumed more and more of core functionality, enough to stop the creation of clones.
Which is true.
His claim was more along the lines of: Google Play Services has over time subsumed more and more of core functionality, enough to stop the creation of clones.
Which is true.
That's not what he claimed. He claimed that
1. Code submitted by third parties to android 2. was moved into Google Play Services 3. And this was possible only due to the CLA.
This isn't true for a couple of reasons. 2 is unsubstantiated (it's possible this is true, but I don't think it is). Functionality certainly moved, but I don't think there's reason to believe that code was copied.
3 just isn't true. Android is Apache licensed, so code in android can be reused in proprietary code without a CLA. What you can't do is relicense Android without a CLA. Another user mentions that the Fuschia CLA doesn't allow relicensing anyway, but I'm not an expert and don't have knowledge of that.
1. Code submitted by third parties to android 2. was moved into Google Play Services 3. And this was possible only due to the CLA.
This isn't true for a couple of reasons. 2 is unsubstantiated (it's possible this is true, but I don't think it is). Functionality certainly moved, but I don't think there's reason to believe that code was copied.
3 just isn't true. Android is Apache licensed, so code in android can be reused in proprietary code without a CLA. What you can't do is relicense Android without a CLA. Another user mentions that the Fuschia CLA doesn't allow relicensing anyway, but I'm not an expert and don't have knowledge of that.
Once upon a time, Android had a mail client that was part of the open source components. There was also GMail app that was closed source. Then a couple of versions later, the open source email app was discontinued and its functionality was incorporated into GMail. And the same thing has happened to many more apps and functionalities.
The F-Droid store provides compelling alternatives to essentially all of the old AOSP apps. (LineageOS also maintains varieties of them.) The one component where there's been a real issue for FLOSS apps is support for centralized push notifications, and that's reliant on 3rd-party services so "open" is not a very meaningful characterization anyway.
Part of that has more to do with the fact that AOSP is not used nearly as much and updating the default AOSP apps is not a good use of time for Google. The AOSP browser was never [edit: not recently] competitive with Chrome and the AOSP mail app was never [edit: not recently] competitive with Gmail.
> The AOSP browser was never competitive with Chrome
That's really not true, and not how it worked. Chrome was very late to the mobile game (first released 2012, a year after Android 4.0 / ICS was released) and its first few attempts on Android sucked. It was incredibly slow & laggy when it first finally came to Android.
It's obviously not a good use of resources to make two webkit-based browsers both targeting the same market, but it was a complete swap out from one to the other over a relatively short time-frame. It's not like the mail vs. gmail situation where it was actually two "competing" apps for quite a long while.
That's really not true, and not how it worked. Chrome was very late to the mobile game (first released 2012, a year after Android 4.0 / ICS was released) and its first few attempts on Android sucked. It was incredibly slow & laggy when it first finally came to Android.
It's obviously not a good use of resources to make two webkit-based browsers both targeting the same market, but it was a complete swap out from one to the other over a relatively short time-frame. It's not like the mail vs. gmail situation where it was actually two "competing" apps for quite a long while.
Yes if no one puts time into updating the default AOSP apps then they will stop being competitive. That seems like a tautology.
> Not really open
Not many people still consider non-copyleft open source licenses not "open" (even the FSF disagrees on the need for copyleft to be considered libre) and MIT, BSD, and Apache 2.0 in particular are widely considered proper open source, so I think you just mean "Not really copyleft", which, sure.
Not many people still consider non-copyleft open source licenses not "open" (even the FSF disagrees on the need for copyleft to be considered libre) and MIT, BSD, and Apache 2.0 in particular are widely considered proper open source, so I think you just mean "Not really copyleft", which, sure.
agree on the issue but I don't think that Play Services is a great exemple.
It has always been closed source and can be replaced in any AOSP build. Google has no obligation to provide open sources apps and services on top of AOSP.
It has always been closed source and can be replaced in any AOSP build. Google has no obligation to provide open sources apps and services on top of AOSP.
So basically you'd work for free for one of the wealthiest companies.
That's f'ed up.
That's f'ed up.
Uh, that's how the BSD and Apache licenses work.
Lets hope. I think QNX programs were often made out of smaller processes. It would be interesting and cool if this is the case with Fuchia.
>Fuchsia's goal is to power production devices and products used for business-critical applications
People have guessed that Fuchsia is some successor to Android or unification of Chrome OS and Android. However, this statement makes me wonder if it is meant to run their backend hardware and not consumer products.
People have guessed that Fuchsia is some successor to Android or unification of Chrome OS and Android. However, this statement makes me wonder if it is meant to run their backend hardware and not consumer products.
There’s a fairly heavy emphasis on graphics and UI throughout Fuchsia’s stack, so I doubt it’s meant to just sit on a server.
Actually quite the opposite, Fuchsia already runs on production devices manufactured by Google. The (ridiculously long named) Google Nest Home Hub and Home Hub Max both can run Zircon and Fuchsia on device, although it's very much for development.
They probably cut it down from the original “Play Home Hub All Access by Nest by Google”.
The original sold-as product name was Google Home Hub, the announced rename was the shorter Nest Hub, though it seems to be fully Google Nest Hub (that's the title of the Google Store product page, though the page itself only ever used Nest Hub.)
I can't find anything from Google using both the “Nest” and “Home” bits as part of the same product name, though some third party sites seem to have mixed the old and new names that way.
I can't find anything from Google using both the “Nest” and “Home” bits as part of the same product name, though some third party sites seem to have mixed the old and new names that way.
Apart from the unfortunate sounding name, for this to be relevant on android phones or watches, it needs to simply work with the 2+ million apps out there. Just posix compatibility is insufficient - apps rely on Linux implementation behavior.
No one doing apps cares about POSIX on or Linux on Android, unless we are talking about people rooting their devices.
The official stable APIs are the Java/Kotlin frameworks, NDK native libraries, ISO C and ISO C++ standard libraries.
Exactly to cut down on misbehaviours of developers getting hold of unofficial Linux syscalls or non public .so, Google has started to use LinuxSE and seccomp to lock out such kind of apps.
So any Android application that only uses public APIs will have no trouble migrating to Fuchsia.
The official stable APIs are the Java/Kotlin frameworks, NDK native libraries, ISO C and ISO C++ standard libraries.
Exactly to cut down on misbehaviours of developers getting hold of unofficial Linux syscalls or non public .so, Google has started to use LinuxSE and seccomp to lock out such kind of apps.
So any Android application that only uses public APIs will have no trouble migrating to Fuchsia.
[deleted]
Sounds like Google's version of Darwin.
You mean Mach?
Please see the below diagram from Wikipedia explaining the difference between Mach and Darwin. I agree with OP that Fuschia is much closer to Darwin than Mach.
https://en.m.wikipedia.org/wiki/File:Diagram_of_Mac_OS_X_arc...
https://en.m.wikipedia.org/wiki/File:Diagram_of_Mac_OS_X_arc...
Fuchsia is more than a kernel, and I wouldn't describe XNU as just being Mach.
I really like Fuchsia design wise... it’s got a great build system and folks on IRC have been nothing but friendly and excellent! Travis and team are doing a great job!
I can't help but think that if microkernel architectures were such a good idea, that would explain why every popular OS is a microkernel architecture (oh wait...). Snark aside, this is a serious debate since the inception of Linux [1].
It's important to look at Fuchsia through the lens of what problems it solves in Android/Linux because that tells you a lot.
As we know, receiving updates in Android is, well, a clusterfark. There are two key problems:
1. Phone manufacturers need to write or update drivers essentially with each Android release; and
2. Those drivers are by nature of Linux being a monolithic kernel, written in kernel space. Kernel space code by third-parties is going to be inherently more unstable to your device than if they were written in user space.
So when Google talks about Fuchsia having a stable binary ABI for drivers, they're talking about solving both of these problems (at least as they see them).
So the question I've always had about the justifications for pouring billions of dollars into Fuchsia (I mean that quite literally) is: could this really not have been solved in Linux, even if it's just the limited context of Android?
I'm not a driver or Linux expert by any stretch of the imagination. I'm sure there are people here who are so this is my question to you: could you have created a system for ideally user space drivers with a stable ABI in Linux and avoided all the costs of completely reinventing that wheel?
My other question about Fuchsia is: does Google foresee themselves adopting the same vertically integrated solution that, say, Apple does? It's worth noting that Apple by not providing iOS to third parties is somewhat paradoxically immune to antitrust investigations (I mean really... how does that work?).
Evidence against Google adopting the Apple model is the fact that Fuchsia is open source, which is a curious decision. This seems to imply that Google either wants to maintain an Android-like ecosystem or they simply see it as their only viable option.
I don't know how anyone can expect that Samsung is going to move to Fuchsia. Samsung already chafes under the yoke of their Google dependence with Android. They've tried to get out from under it (ie Tizen) but luckily for Google, Samsung is terrible at software (at anyone with Samsung crapware on their Galaxy can attest; Bixby anyone?).
Maybe Google thinks the insurance of Fuchsia being open source is necessary for third-party adoption to have any chance but still, the only way I see Samsung going along with this is that there's absolutely no other alternative.
[1]: https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
It's important to look at Fuchsia through the lens of what problems it solves in Android/Linux because that tells you a lot.
As we know, receiving updates in Android is, well, a clusterfark. There are two key problems:
1. Phone manufacturers need to write or update drivers essentially with each Android release; and
2. Those drivers are by nature of Linux being a monolithic kernel, written in kernel space. Kernel space code by third-parties is going to be inherently more unstable to your device than if they were written in user space.
So when Google talks about Fuchsia having a stable binary ABI for drivers, they're talking about solving both of these problems (at least as they see them).
So the question I've always had about the justifications for pouring billions of dollars into Fuchsia (I mean that quite literally) is: could this really not have been solved in Linux, even if it's just the limited context of Android?
I'm not a driver or Linux expert by any stretch of the imagination. I'm sure there are people here who are so this is my question to you: could you have created a system for ideally user space drivers with a stable ABI in Linux and avoided all the costs of completely reinventing that wheel?
My other question about Fuchsia is: does Google foresee themselves adopting the same vertically integrated solution that, say, Apple does? It's worth noting that Apple by not providing iOS to third parties is somewhat paradoxically immune to antitrust investigations (I mean really... how does that work?).
Evidence against Google adopting the Apple model is the fact that Fuchsia is open source, which is a curious decision. This seems to imply that Google either wants to maintain an Android-like ecosystem or they simply see it as their only viable option.
I don't know how anyone can expect that Samsung is going to move to Fuchsia. Samsung already chafes under the yoke of their Google dependence with Android. They've tried to get out from under it (ie Tizen) but luckily for Google, Samsung is terrible at software (at anyone with Samsung crapware on their Galaxy can attest; Bixby anyone?).
Maybe Google thinks the insurance of Fuchsia being open source is necessary for third-party adoption to have any chance but still, the only way I see Samsung going along with this is that there's absolutely no other alternative.
[1]: https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
Android Linux also has it since Project Treble.
Linux drivers are considered legacy on Android, all new drivers should follow the Project Treble architecture, which is basically the genesis of how Fuchsia drivers work.
Every driver has their own process and uses Android IPC to talk with the kernel.
The stable ABI is Android HIDL, similar to Fuchsia FIDL, a protocol buffer based IPC for fast communication with the kernel, that also allows for passing references to hardware buffers across processes.
You can read all about it at AOSP web site.
Linux drivers are considered legacy on Android, all new drivers should follow the Project Treble architecture, which is basically the genesis of how Fuchsia drivers work.
Every driver has their own process and uses Android IPC to talk with the kernel.
The stable ABI is Android HIDL, similar to Fuchsia FIDL, a protocol buffer based IPC for fast communication with the kernel, that also allows for passing references to hardware buffers across processes.
You can read all about it at AOSP web site.
Samsung is getting better at software. OneUI gets very positive reviews. Many of the Samsung apps on my Note 10 are perfectly acceptable daily tools. Mail, gallery, notes etc are competitive now.
Operating systems have a lot of inertia. Linux is close to 30 years old. Performance characteristics, threat models and a lot of other things were different back then. New operating systems solving this issue will generally fail because of missing drivers and userland code, not because they are technologically worse.
Did you read the article?
One of the things it explicitly calls out is that Fuchsia is not a microkernel.
One of the things it explicitly calls out is that Fuchsia is not a microkernel.
It's been 4 years and it's still being developed? Apparently android v1/v2 was released about 1 year later after the first iPhone.
It doesn't seem so easy to make a new OS/kernel.
The linux kernel is not perfect, but at least it works well, it's mature, and developers know how to work on it.
It doesn't seem so easy to make a new OS/kernel.
The linux kernel is not perfect, but at least it works well, it's mature, and developers know how to work on it.
>It's been 4 years and it's still being developed? Apparently android v1/v2 was released about 1 year later after the first iPhone.
I'd say they learned a lot from Android, the use cases and problems arising from supporting such a giant project on so many different devices (and non cooperating vendors). So it's not a surprise they're taking their time. I imagine there must have been a long and in-depth analysis at Google of Android and other operating systems before Fuchsia came to be, considering the money they're going to spending on it.
AFAIK Android was a quick hack and the ecosystem, if you know anything about it, you know it's a mess.
I'd say they learned a lot from Android, the use cases and problems arising from supporting such a giant project on so many different devices (and non cooperating vendors). So it's not a surprise they're taking their time. I imagine there must have been a long and in-depth analysis at Google of Android and other operating systems before Fuchsia came to be, considering the money they're going to spending on it.
AFAIK Android was a quick hack and the ecosystem, if you know anything about it, you know it's a mess.
Yep.
It's not always that appears a new software that is very well thought out and designed. In general things are hacked together and made in somewhat a hurry and it ends up causing a lot of problems afterwards.
It's also not everyone, meaning companies in practice, that could aford time to analyse, design, test and iterate such a software like an operating system and all its needed subsystems for the modern needs...
It's not always that appears a new software that is very well thought out and designed. In general things are hacked together and made in somewhat a hurry and it ends up causing a lot of problems afterwards.
It's also not everyone, meaning companies in practice, that could aford time to analyse, design, test and iterate such a software like an operating system and all its needed subsystems for the modern needs...
Haven't checked Fuchsia in a while, very glad to see that they have extended the documentation.
Did they improve the initial steps to get up and running too?
(I remember it took hours to clone all the subprojects and most of the times something failed along the way, even worse than downloading the Android sources)
Did they improve the initial steps to get up and running too?
(I remember it took hours to clone all the subprojects and most of the times something failed along the way, even worse than downloading the Android sources)
everything in userspace == high security. programs, software won't clash like they do on *nix, windows due to isolation. same benefits of snaps | flatpaks. but now you've a microkernel which is 1. fast 2. easy to patch 3. stable ABI something Linux doesn't have.
In what way does software "clash" on *nix? The isolation provided by snaps and flatpaks is 99% about isolating devs from having to worry about deps and different platforms.
flatpak/snap applications can run on its own confined sanboxes
Which are complete and total garbage insofar as actual isolation. If you think you can run malware in a snap and not be pwned you are kidding yourself.
I've been eyeing Fuchsia for some time now and wanting to give it a spin but I've been holding back just to make sure it doesn't get abandoned(despite having a well maintained fork already). Real shame they pulled the plug on the raspberry pi support.
I was trying to find out from that site who's behind this and if that information is in there it must be really well hidden. Apart from other concerns, I'm not going to touch an OS from a group that doesn't clearly state who they are.
It's GOOG's GPL-less replacement for the Linux kernel, made so they can control the phones even more.
Now I understand why much of the language in there looks more like foggy marketing hype than a comprehensible explanation.
Besides, the page's CSS is (besides colours) very alike to their other properties. https://cloud.google.com/kubernetes-engine/docs/tutorials/he...
And, well "For details, see the Google Developers Site Policies."
And, well "For details, see the Google Developers Site Policies."
Do you actually believe a company such as Google would constrain themselves with GPL (which is pretty much _socialism_) on a product that will possibly bring hundreds of billions in revenue?
No, of course it's logical for them to ditch GPL at the earliest convenience.
And it's still logical of me to criticise the idea on principle.
And it's still logical of me to criticise the idea on principle.
fuchsia.dev?
Has anyone tried installing this on a ThinkPad? Like an X201 or X230?
What is the cheapest fuschsia supported hardware device?
Logically an emulator https://fuchsia.dev/fuchsia-src/getting_started#set_up_the_e...
Regarding supported platforms
"Fuchsia has good support for a few different hardware platforms including the Acer Switch 12, Intel NUC, and Google Pixelbook (not to be confused with the Chromebook Pixel). The install process is not currently compatible with ARM-based targets."
Looks like the 2 laptops can be had used/new for between 660-1k+ while the NUC can be purchased as a bare board with cpu for as little as 290
https://www.intel.com/content/www/us/en/products/boards-kits...
Regarding supported platforms
"Fuchsia has good support for a few different hardware platforms including the Acer Switch 12, Intel NUC, and Google Pixelbook (not to be confused with the Chromebook Pixel). The install process is not currently compatible with ARM-based targets."
Looks like the 2 laptops can be had used/new for between 660-1k+ while the NUC can be purchased as a bare board with cpu for as little as 290
https://www.intel.com/content/www/us/en/products/boards-kits...
I still think its strange to create an OS that officially supports only 2-3 languages for development. Sounds rather 1980s to me.
It would be strange to create such an OS, which is why that's not the case of Fuchsia:
"Fuchsia is designed to let developers bring their own runtime, which means a developer can use a variety of languages or runtimes without needing to change Fuchsia itself"
"Fuchsia is designed to let developers bring their own runtime, which means a developer can use a variety of languages or runtimes without needing to change Fuchsia itself"
Sounds very much like any Apple, Google, Microsoft, IBM, Oracle, Sony, Nintendo, pick your embedded OEM, ... to me.
UNIX has always been the snowflake, and even there, commercial UNIX SKDs are pretty much C, C++ and Fortran, followed by the usual POSIX scripting languages.
To create a good developer experience in OS SDK IDE and platform APIs, there are only so much one can support.
Unless we are doing UNIX ABIs and the best one can hope for are 70's C style bindings.
UNIX has always been the snowflake, and even there, commercial UNIX SKDs are pretty much C, C++ and Fortran, followed by the usual POSIX scripting languages.
To create a good developer experience in OS SDK IDE and platform APIs, there are only so much one can support.
Unless we are doing UNIX ABIs and the best one can hope for are 70's C style bindings.
To the extent that there's native C++ I'm sure it will be somewhat straightforward to get other languages supported later by users/developers.
2-3 languages? It has support for C, C++, Dart, Rust, and Go. And I think some level of support for Swift.
I wouldn't be so sure about Go. Anway, I found certain remarks somewhat irritating in this respect. I'm happy if it turns out I misunderstood something.
Go is listed as a language https://fuchsia.dev/fuchsia-src/development#languages
I see they pulled their language policy from a few months ago. Good.
Please don't editorialize titles. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html. Lots of explanation here: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
(Submitted title was 'Fuchsia overview – “Fuchsia is not a science experiment”')
(Submitted title was 'Fuchsia overview – “Fuchsia is not a science experiment”')
Given Google's penchant for abruptly canceling platforms, I hope that implementors and vendors will be careful with this.
to be fair, there's a large graveyard of OSs which failed to gain traction, especially on mobile.
I'd be surprised if any vendor adopts Fuchsia thinking it has anything better than a 10-20% chance of being mainstream.
Today we have Android and iOS as the dominant Mobile phone OSs. Don't forget about all the attempts to dethrone those two by: Symbian, WebOS, Windows phone, Blackberry, Tizen, Ubuntu Touch, kaios, firefox os, PureOS, LiteOS,...etc.
I'd be surprised if any vendor adopts Fuchsia thinking it has anything better than a 10-20% chance of being mainstream.
Today we have Android and iOS as the dominant Mobile phone OSs. Don't forget about all the attempts to dethrone those two by: Symbian, WebOS, Windows phone, Blackberry, Tizen, Ubuntu Touch, kaios, firefox os, PureOS, LiteOS,...etc.
adamnemecek(2)
Another Google project that will end up being abandoned. Flutter, Dart, messaging, etc.
They need to just fix Android.
They need to just fix Android.
Your resentment (if there is any) is understandable but you are using a cross platform application framework to predict what Google will do for an OS. Moreover, I believe Flutter isn't going anywhere anytime soon either.
I write about Flutter in our company blog every now and then. I can confirm, Flutter posts currently receive their all time high impression counts and time retention rates.
I write about Flutter in our company blog every now and then. I can confirm, Flutter posts currently receive their all time high impression counts and time retention rates.
I'd hardly consider projects (ie Flutter and Dart) that both had releases in the last week to be "abandoned".
Well Flutter is a first-class citizen in Fuchsia and will be able to run Flutter apps as soon as they release the OS. So I don't see this as a likely candidate for Google to abandon this.
Android apps compatibility 'appears' to be being supported via a mix of using Android's ART ported to Fuchsia and hardware assisted virtualisation of the Linux kernel, called 'Machina'.
The sort of transitioning Apple did between PowerPC -> x86 and now to ARM.
Android apps compatibility 'appears' to be being supported via a mix of using Android's ART ported to Fuchsia and hardware assisted virtualisation of the Linux kernel, called 'Machina'.
The sort of transitioning Apple did between PowerPC -> x86 and now to ARM.
Flutter/Dart aren't being abandoned. They're healthy.
Also Google needs to move away from the Java ecosystem thanks to Oracle v. Google. That means dumping Android, which was built on Java entirely. Creating a new OS based on their language would seem to be in their best interests.
Also Google needs to move away from the Java ecosystem thanks to Oracle v. Google. That means dumping Android, which was built on Java entirely. Creating a new OS based on their language would seem to be in their best interests.
Ah, the HN hivemind Markov chain is mired in another infinite cycle.
https://hncynic.leod.org/
https://hncynic.leod.org/
It's a pretty big idea because it's pretty neat, but why not simply run an algorithm to figure out where the "random" random sequence is?
Then figure out which random sequence is a good fit for what's happening, as opposed to just looking for it in a random chain.
Then figure out which random sequence is a good fit for what's happening, as opposed to just looking for it in a random chain.
For those of you who find the 'misconceptions' of the phrase 'Mobi', this makes me very glad you aren't just an old friend.
It really should be noted that this was published in 2005.
It really should be noted that this was published in 2005.
That's great, my other three comments were generated from your comment. This is hilarious.
Truth hurts.
This is just pure conjecture.
I have a strong feeling that Fuchsia will not be abandoned. I can't put my finger on it, but Google's approach and tone around Fuchsia feels really different from how they talked about / marketed Reader, or even Wave, or other things they shut down.
I'm an Android developer learning Flutter and Dart out of both curiosity and an gamble that it will likely be a faster-improving way to make cross-platform apps than other approaches (like Kotlin + Swift, or React Native, or the others)
I'm an Android developer learning Flutter and Dart out of both curiosity and an gamble that it will likely be a faster-improving way to make cross-platform apps than other approaches (like Kotlin + Swift, or React Native, or the others)
I agree Fuchsia should prevail. My reasoning is that, presuming it succeeds technically, it could only be killed politically if both Android and ChromeOS prevented Fuchsia from being used on first party devices. This seems unlikely.
Google projects that get killed are either retail products that gain insufficient traction (for Google) or expensive projects that stall for technical or logistical reasons.
Google projects that get killed are either retail products that gain insufficient traction (for Google) or expensive projects that stall for technical or logistical reasons.
Fuchsia is not a current revenue generator for Google. If they needed to cut headcount, fuchsia could see reduced headcount.
> I can't put my finger on it, but Google's approach and tone around Fuchsia feels really different from how they talked about / marketed Reader, or even Wave, or other things they shut down.
Different marketers?
Different marketers?
Maybe - but are the marketers even in charge of the open source decisions? It's possible I guess. But to name an example, the open source code and developer-focused nature of the work just makes it seem completely different to me.
It’s the feeling that Google will be able to use it to implement more Apple-like iron fist control over hardware vendors and tie-ins that makes it seem more permanent.
> Another Google project that will end up being abandoned
This one however will give Google full control of the devices it runs on (no more Linux kernel related obligations), so they have zero incentives to kill it, unless they write something else that does the same things. Google will rather abandon Android a few years after Fuchsia is launched.
This one however will give Google full control of the devices it runs on (no more Linux kernel related obligations), so they have zero incentives to kill it, unless they write something else that does the same things. Google will rather abandon Android a few years after Fuchsia is launched.
Both Flutter and Dart had new preview releases just this month
> Another Google project that will end up being abandoned.
Do you have any sort of evidence for this statement or is this pure speculation?
Do you have any sort of evidence for this statement or is this pure speculation?
Google's track record is evidence, albeit not a guarantee.
Flutter is the UI framework of Fuchsia
Maybe they will fix Android by replacing it with Fuchsia :P I think the problems with Android run so deep, it can't just be "fixed".
No idea why you're being downvoted... I also think that would be one of the most obvious areas where Google could eventually put Fuchsia to use - it would have several advantages: a new OS with a more modern architecture (getting rid of the GPL-licensed Linux kernel, which Google probably sees as an advantage); the possibility to update the kernel independently of the drivers; getting rid of Java and its legal liabilities which Oracle could exploit in the future etc.
Well, the touchstone is audio.
If Fuchsia manages to have audio performance like iOS, then they definitely rearchitected rather than just slapped lipstick on a different pig.
If Fuchsia manages to have audio performance like iOS, then they definitely rearchitected rather than just slapped lipstick on a different pig.
Do people actually have audio problems with android? People don't seem to even have a problem with all the bad quality audio devices they ought to have a problem with let alone the OS.
Musics do have, hence why Samsung had their own real time audio stack, which Google eventually adapted into Android.
There are several years of Google IO stuff going into this, until you finally reach the talk done together with a Samsung representative and a couple of DJs using the new demo app on stage to prove Android was finally ready for music professionals.
It is just a matter to go down the Google IO archive.
There are several years of Google IO stuff going into this, until you finally reach the talk done together with a Samsung representative and a couple of DJs using the new demo app on stage to prove Android was finally ready for music professionals.
It is just a matter to go down the Google IO archive.
Google makes a lot of its own infrastructure for its data centers. I would not be surprised if fuchsia was already in use there. It would make sense at least securitywise.
[deleted]
I have mixed feelings. This brings invitation to the operating system world. But it will track user behaviour from its core.
[deleted]
This is a massive step back for open source. The fact that Linux doesn't have a binary-compatible driver interface is a good thing: It means hardware vendors have a very strong incentive to get their drivers upstream into the kernel. And indeed, on servers and laptops and desktop machines, this has largely happened. But on mobile platforms, with Android, it has not happened. For various reasons, but nothing fundamental.
We would all benefit if Android hardware drivers were upstreamed. This would allow for a much more competitive, and higher quality, software and hardware ecosystem on mobile platforms.
But Fuschia is going in the exact opposite direction: It makes it possible to build proprietary drivers. It's for this reason that I hope Fuschia is not successful. We already have a high quality kernel: Linux. If Fuschia is "not a science experiment", but instead intended to use proven ideas, then any improvement that could be added to Fuschia could be added to Linux. We don't need a new operating system whose only advantage is that it's easier to write proprietary drivers.