20 ms·

Fuchsia overview

287 points by farmerbb 6y ago

jpm_sd 6y ago
Sounds a bit like a modern, open approach to the problems that were solved by QNX. Excited to see how it evolves!
- Animats 6y ago
  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 https://cla.developers.google.com/about/google-individual
  - rstat1 6y ago
    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.
    - kick 6y ago
      '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.
      - joshuamorton 6y ago
        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.
      - smnrchrds 6y ago
        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.
        snazz 6y ago
        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.
        nradov 6y ago
        Yes if no one puts time into updating the default AOSP apps then they will stop being competitive. That seems like a tautology.
        kllrnohj 6y ago
        > 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.
        zozbot234 6y ago
        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.
  - 101404 6y ago
    So basically you'd work for free for one of the wealthiest companies. That's f'ed up.
    - cycloptic 6y ago
      It's not because you're also asking the same of them. If you're submitting code upstream, you're essentially asking the maintainers to perform code review and start maintaining your contributions, for free.
      - 101404 6y ago
        You're comment makes no sense.
        101404 6y ago
        *your
    - plerpin 6y ago
      Uh, that's how the BSD and Apache licenses work.
  - wmf 6y ago
    All permissively-licensed (MIT/BSD/Apache) code has that property. If you contribute to BSD anyone can create a proprietary derivative.
  - mbrukman 6y ago
    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 https://cla.developers.google.com/about/google-individual [2] https://www.apache.org/licenses/icla.pdf https://www.apache.org/licenses/icla.pdf [3] https://llvm.org/foundation/relicensing/ https://llvm.org/foundation/relicensing/
    - ColanR 6y ago
      >> 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.
      - mbrukman 6y ago
        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.
  - magicalist 6y ago
    > 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.
  - on_and_off 6y ago
    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.
- CyberDildonics 6y ago
  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.
matchbok 6y ago
Another Google project that will end up being abandoned. Flutter, Dart, messaging, etc. They need to just fix Android.
- clumsysmurf 6y ago
  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".
  - rob74 6y ago
    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.
  - bsder 6y ago
    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.
    - michaelmrose 6y ago
      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.
      - pjmlp 6y ago
        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.
gman83 6y ago
Sounds like Google's version of Darwin.
- plerpin 6y ago
  You mean Mach?
  - heavyset_go 6y ago
    Fuchsia is more than a kernel, and I wouldn't describe XNU as just being Mach.
  - Godel_unicode 6y ago
    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_architecture.svg https://en.m.wikipedia.org/wiki/File:Diagram_of_Mac_OS_X_arc...
adamnemecek 6y ago
Don't tell me what it's not tell me what it is.
- tpush 6y ago
  They do, you just need to actually click on the link to find out.
- NikolaeVarius 6y ago
  The literal first sentence
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
catern 6y ago
>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.
- ptomato 6y ago
  > 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.
  - snazz 6y ago
    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.
dang 6y ago
Please don't editorialize titles. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Lots of explanation here: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%22level%20playing%20field%22&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... (Submitted title was 'Fuchsia overview – “Fuchsia is not a science experiment”')
- deleted 6y ago
  [deleted]
- phreack 6y ago
  I'm sorry if this isn't the place to ask (and please let me know), but how should we correctly title something like a tweet, that has no obvious title?
  - dang 6y ago
    I'd use the text of the tweet or the most representative substring of it that will fit the 80 char limit.
tarkin2 6y ago
I have mixed feelings. This brings invitation to the operating system world. But it will track user behaviour from its core.
jccalhoun 6y ago
>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.
- qmarchi 6y ago
  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.
  - innagadadavida 6y ago
    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.
    - pjmlp 6y ago
      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.
  - jeffbee 6y ago
    They probably cut it down from the original “Play Home Hub All Access by Nest by Google”.
    - dragonwriter 6y ago
dzonga 6y ago
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.
- michaelmrose 6y ago
  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.
  - lsofzz 6y ago
    flatpak/snap applications can run on its own confined sanboxes
    - michaelmrose 6y ago
      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.
killjoywashere 6y ago
Has anyone tried installing this on a ThinkPad? Like an X201 or X230?
butterisgood 6y ago
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!
cletus 6y ago
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_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
- cageface 6y ago
dilandau 6y ago
Given Google's penchant for abruptly canceling platforms, I hope that implementors and vendors will be careful with this.
- cobookman 6y ago
  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.
loeg 6y ago
> 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.
- goodthenandnow 6y ago
  Yes. That is what we as users most need. Application sandboxing from first principles and the very bottom
sam1r 6y ago
What is the cheapest fuschsia supported hardware device?
- michaelmrose 6y ago
  Logically an emulator https://fuchsia.dev/fuchsia-src/getting_started#set_up_the_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/nuc/boards.html https://www.intel.com/content/www/us/en/products/boards-kits...
drtse4 6y ago
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)
stewbrew 6y ago
I still think its strange to create an OS that officially supports only 2-3 languages for development. Sounds rather 1980s to me.
- thethimble 6y ago
  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.
- TulliusCicero 6y ago
  2-3 languages? It has support for C, C++, Dart, Rust, and Go. And I think some level of support for Swift.
  - stewbrew 6y ago
    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.
    - abraham 6y ago
      Go is listed as a language https://fuchsia.dev/fuchsia-src/development#languages https://fuchsia.dev/fuchsia-src/development#languages
      - stewbrew 6y ago
        I see they pulled their language policy from a few months ago. Good.
- Jyaif 6y ago
  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"
- 6y ago
axegon_ 6y ago
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.
- nmcain 6y ago
  What fork are you referring to?
  - axegon_ 6y ago
    DahliaOS.
    - nmcain 6y ago
      Haha, I thought there was another fork going around. Don't worry, we are actively working on Pi4 support, Fuchsia dropped the 3 because they changed the graphics stack to one that used Vulkan, but the Pi4 has experimental Vulkan support.
tempodox 6y ago
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.
- SSLy 6y ago
  It's GOOG's GPL-less replacement for the Linux kernel, made so they can control the phones even more.
  - tempodox 6y ago
    Now I understand why much of the language in there looks more like foggy marketing hype than a comprehensible explanation.
    - SSLy 6y ago
      Besides, the page's CSS is (besides colours) very alike to their other properties. https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app https://cloud.google.com/kubernetes-engine/docs/tutorials/he... And, well "For details, see the Google Developers Site Policies."
  - oseityphelysiol 6y ago
    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?
    - SSLy 6y ago
      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.
- nmcain 6y ago
  fuchsia.dev?
jokoon 6y ago
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.
- oseityphelysiol 6y ago
  >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.
  - goodthenandnow 6y ago
    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...

Fuchsia overview

287 points by farmerbb 6y ago

jpm_sd 6y ago

Sounds a bit like a modern, open approach to the problems that were solved by QNX. Excited to see how it evolves!

Animats 6y ago
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 https://cla.developers.google.com/about/google-individual
- rstat1 6y ago
  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.
  - kick 6y ago
    '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.
    - joshuamorton 6y ago
      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.
    - smnrchrds 6y ago
      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.
      - snazz 6y ago
        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.
        nradov 6y ago
        Yes if no one puts time into updating the default AOSP apps then they will stop being competitive. That seems like a tautology.
        kllrnohj 6y ago
        > 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.
      - zozbot234 6y ago
        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.
- 101404 6y ago
  So basically you'd work for free for one of the wealthiest companies. That's f'ed up.
  - cycloptic 6y ago
    It's not because you're also asking the same of them. If you're submitting code upstream, you're essentially asking the maintainers to perform code review and start maintaining your contributions, for free.
    - 101404 6y ago
      You're comment makes no sense.
      - 101404 6y ago
        *your
  - plerpin 6y ago
    Uh, that's how the BSD and Apache licenses work.
- wmf 6y ago
  All permissively-licensed (MIT/BSD/Apache) code has that property. If you contribute to BSD anyone can create a proprietary derivative.
- mbrukman 6y ago
  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 https://cla.developers.google.com/about/google-individual [2] https://www.apache.org/licenses/icla.pdf https://www.apache.org/licenses/icla.pdf [3] https://llvm.org/foundation/relicensing/ https://llvm.org/foundation/relicensing/
  - ColanR 6y ago
    >> 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.
    - mbrukman 6y ago
      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.
- magicalist 6y ago
  > 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.
- on_and_off 6y ago
  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.
CyberDildonics 6y ago
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.

matchbok 6y ago

Another Google project that will end up being abandoned. Flutter, Dart, messaging, etc. They need to just fix Android.

clumsysmurf 6y ago
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".
- rob74 6y ago
  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.
- bsder 6y ago
  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.
  - michaelmrose 6y ago
    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.
    - pjmlp 6y ago
      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.

gman83 6y ago

Sounds like Google's version of Darwin.

plerpin 6y ago
You mean Mach?
- heavyset_go 6y ago
  Fuchsia is more than a kernel, and I wouldn't describe XNU as just being Mach.
- Godel_unicode 6y ago
  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_architecture.svg https://en.m.wikipedia.org/wiki/File:Diagram_of_Mac_OS_X_arc...

adamnemecek 6y ago

Don't tell me what it's not tell me what it is.

tpush 6y ago
They do, you just need to actually click on the link to find out.
NikolaeVarius 6y ago
The literal first sentence

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

catern 6y ago

>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.

ptomato 6y ago
> 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.
- snazz 6y ago
  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.

dang 6y ago

Please don't editorialize titles. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Lots of explanation here: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%22level%20playing%20field%22&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... (Submitted title was 'Fuchsia overview – “Fuchsia is not a science experiment”')

deleted 6y ago
[deleted]
phreack 6y ago
I'm sorry if this isn't the place to ask (and please let me know), but how should we correctly title something like a tweet, that has no obvious title?
- dang 6y ago
  I'd use the text of the tweet or the most representative substring of it that will fit the 80 char limit.

tarkin2 6y ago

I have mixed feelings. This brings invitation to the operating system world. But it will track user behaviour from its core.

jccalhoun 6y ago

>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.

qmarchi 6y ago
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.
- innagadadavida 6y ago
  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.
  - pjmlp 6y ago
    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.
- jeffbee 6y ago
  They probably cut it down from the original “Play Home Hub All Access by Nest by Google”.
  - dragonwriter 6y ago

dzonga 6y ago

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.

michaelmrose 6y ago
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.
- lsofzz 6y ago
  flatpak/snap applications can run on its own confined sanboxes
  - michaelmrose 6y ago
    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.

killjoywashere 6y ago

Has anyone tried installing this on a ThinkPad? Like an X201 or X230?

butterisgood 6y ago

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!

cletus 6y ago

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_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...

cageface 6y ago

dilandau 6y ago

Given Google's penchant for abruptly canceling platforms, I hope that implementors and vendors will be careful with this.

cobookman 6y ago
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.

loeg 6y ago

> 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.

goodthenandnow 6y ago
Yes. That is what we as users most need. Application sandboxing from first principles and the very bottom

sam1r 6y ago

What is the cheapest fuschsia supported hardware device?

michaelmrose 6y ago
Logically an emulator https://fuchsia.dev/fuchsia-src/getting_started#set_up_the_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/nuc/boards.html https://www.intel.com/content/www/us/en/products/boards-kits...

drtse4 6y ago

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)

stewbrew 6y ago

I still think its strange to create an OS that officially supports only 2-3 languages for development. Sounds rather 1980s to me.

thethimble 6y ago
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.
TulliusCicero 6y ago
2-3 languages? It has support for C, C++, Dart, Rust, and Go. And I think some level of support for Swift.
- stewbrew 6y ago
  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.
  - abraham 6y ago
    Go is listed as a language https://fuchsia.dev/fuchsia-src/development#languages https://fuchsia.dev/fuchsia-src/development#languages
    - stewbrew 6y ago
      I see they pulled their language policy from a few months ago. Good.
Jyaif 6y ago
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"
6y ago

axegon_ 6y ago

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.

nmcain 6y ago
What fork are you referring to?
- axegon_ 6y ago
  DahliaOS.
  - nmcain 6y ago
    Haha, I thought there was another fork going around. Don't worry, we are actively working on Pi4 support, Fuchsia dropped the 3 because they changed the graphics stack to one that used Vulkan, but the Pi4 has experimental Vulkan support.

tempodox 6y ago

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.

SSLy 6y ago
It's GOOG's GPL-less replacement for the Linux kernel, made so they can control the phones even more.
- tempodox 6y ago
  Now I understand why much of the language in there looks more like foggy marketing hype than a comprehensible explanation.
  - SSLy 6y ago
    Besides, the page's CSS is (besides colours) very alike to their other properties. https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app https://cloud.google.com/kubernetes-engine/docs/tutorials/he... And, well "For details, see the Google Developers Site Policies."
- oseityphelysiol 6y ago
  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?
  - SSLy 6y ago
    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.
nmcain 6y ago
fuchsia.dev?

jokoon 6y ago

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.

oseityphelysiol 6y ago
>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.
- goodthenandnow 6y ago
  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...