[HN Gopher] Fuchsia overview
___________________________________________________________________
Fuchsia overview
Author : farmerbb
Score : 108 points
Date : 2020-05-30 20:04 UTC (2 hours ago)
(HTM) web link (fuchsia.dev)
(TXT) w3m dump (fuchsia.dev)
| dang wrote:
| 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"')
| [deleted]
| adamnemecek wrote:
| Don't tell me what it's not tell me what it is.
| tpush wrote:
| They do, you just need to actually click on the link to find
| out.
| NikolaeVarius wrote:
| The literal first sentence
| jccalhoun wrote:
| >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 wrote:
| 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.
| skavi wrote:
| 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.
| [deleted]
| [deleted]
| tarkin2 wrote:
| I have mixed feelings. This brings invitation to the operating
| system world. But it will track user behaviour from its core.
| catern wrote:
| >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.
| ReactiveJelly wrote:
| 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.
| netdur wrote:
| 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.
| ptomato wrote:
| > 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 wrote:
| 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.
| zozbot234 wrote:
| "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.
| cycloptic wrote:
| 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.
| CJefferson wrote:
| 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.
| est31 wrote:
| > 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.
| damnyou wrote:
| 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.
| [deleted]
| matchbok wrote:
| Another Google project that will end up being abandoned. Flutter,
| Dart, messaging, etc.
|
| They need to just fix Android.
| diegoperini wrote:
| 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.
| plerpin wrote:
| Ah, the HN hivemind Markov chain is mired in another infinite
| cycle.
|
| https://hncynic.leod.org/
| mathgladiator wrote:
| This is just pure conjecture.
| mathgladiator wrote:
| 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.
| mathgladiator wrote:
| 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.
| mathgladiator wrote:
| That's great, my other three comments were generated from
| your comment. This is hilarious.
| myko wrote:
| Flutter is the UI framework of Fuchsia
| rvz wrote:
| 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.
| brmgb wrote:
| 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.
| jimbob45 wrote:
| 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.
| clumsysmurf wrote:
| 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".
| cryptoz wrote:
| 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)
| 101404 wrote:
| ...or Google+
|
| Oh, wait
| snazz wrote:
| Google+ was screwed out of the gate. It was invite-only,
| which did not work for Google+ or Wave nearly as well as it
| did for Gmail (logically). It also helps that Fuchsia is
| open-source and sees very active development.
| a3n wrote:
| > 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?
| cryptoz wrote:
| 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.
| 1123581321 wrote:
| 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.
| falcor84 wrote:
| Both Flutter and Dart had new preview releases just this month
| rstat1 wrote:
| I'd hardly consider projects (ie Flutter and Dart) that both
| had releases in the last week to be "abandoned".
| kgraves wrote:
| > Another Google project that will end up being abandoned.
|
| Do you have any sort of evidence for this statement or is this
| pure speculation?
| yjftsjthsd-h wrote:
| Google's track record is evidence, albeit not a guarantee.
| jpm_sd wrote:
| Sounds a bit like a modern, open approach to the problems that
| were solved by QNX. Excited to see how it evolves!
| CyberDildonics wrote:
| 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.
| Animats wrote:
| 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
| rstat1 wrote:
| 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 wrote:
| '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 wrote:
| 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 wrote:
| 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.
| zozbot234 wrote:
| 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.
| snazz wrote:
| 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.
| kllrnohj wrote:
| > 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.
| nradov wrote:
| Yes if no one puts time into updating the default AOSP
| apps then they will stop being competitive. That seems
| like a tautology.
| 101404 wrote:
| So basically you'd work for free for one of the wealthiest
| companies.
|
| That's f'ed up.
| cycloptic wrote:
| 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.
| plerpin wrote:
| Uh, that's how the BSD and Apache licenses work.
| magicalist wrote:
| > _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.
| wmf wrote:
| All permissively-licensed (MIT/BSD/Apache) code has that
| property. If you contribute to BSD anyone can create a
| proprietary derivative.
| on_and_off wrote:
| 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.
| mbrukman wrote:
| 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/
| ColanR wrote:
| >> 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 wrote:
| 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.
| ColanR wrote:
| That's a very fair point. Thanks for clarifying.
| joking wrote:
| 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.
| choppaface wrote:
| 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.
| mbrukman wrote:
| 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
| ColanR wrote:
| 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.
| mbrukman wrote:
| I've added a response to your earlier comment to clarify:
| https://news.ycombinator.com/item?id=23365469
| gman83 wrote:
| Sounds like Google's version of Darwin.
| plerpin wrote:
| You mean Mach?
| heavyset_go wrote:
| Fuchsia is more than a kernel, and I wouldn't describe XNU as
| just being Mach.
| Godel_unicode wrote:
| 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.
| ..
___________________________________________________________________
(page generated 2020-05-30 23:00 UTC)