3 hours ago by catern
>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers.
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.
2 hours ago by ptomato
> 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.
2 hours ago by cycloptic
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.
2 minutes ago by dontblink
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.
32 minutes ago by lain-dono
> 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.
2 hours ago by snazz
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.
2 hours ago by zozbot234
"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.
37 minutes ago by uluyol
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.
35 minutes ago by cameronbrown
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.
2 hours ago by CJefferson
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.
2 hours ago by est31
> 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.
2 hours ago by dang
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â')
2 hours ago by undefined
9 minutes ago by killjoywashere
Has anyone tried installing this on a ThinkPad? Like an X201 or X230?
17 minutes ago by dzonga
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.
3 hours ago by jpm_sd
Sounds a bit like a modern, open approach to the problems that were solved by QNX. Excited to see how it evolves!
3 hours ago by Animats
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
3 hours ago by mbrukman
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
3 hours ago by ColanR
>> 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.
2 hours ago by choppaface
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.
3 hours ago by wmf
All permissively-licensed (MIT/BSD/Apache) code has that property. If you contribute to BSD anyone can create a proprietary derivative.
3 hours ago by rstat1
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.
3 hours ago by kick
'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.
2 hours ago by magicalist
> 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.
3 hours ago by CyberDildonics
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.
an hour ago by jccalhoun
>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.
an hour ago by qmarchi
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.
2 minutes ago by innagadadavida
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.
an hour ago by skavi
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.
an hour ago by undefined
3 hours ago by gman83
Sounds like Google's version of Darwin.
3 hours ago by plerpin
You mean Mach?
2 hours ago by Godel_unicode
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...
3 hours ago by heavyset_go
Fuchsia is more than a kernel, and I wouldn't describe XNU as just being Mach.
3 hours ago by adamnemecek
Don't tell me what it's not tell me what it is.
3 hours ago by tpush
They do, you just need to actually click on the link to find out.
3 hours ago by NikolaeVarius
The literal first sentence
Daily Digest
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.