[HN Gopher] The Google Nest Hub is first commercial Fuchsia device
___________________________________________________________________
The Google Nest Hub is first commercial Fuchsia device
Author : moh_maya
Score : 174 points
Date : 2021-05-25 18:39 UTC (4 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| refulgentis wrote:
| The comments on this article are disappointing.
|
| The first major open source kernel since Linux, and somewhat
| arguably OS X, has been released.
|
| I was looking forward to commentary on that, not blinkered
| commentary complaining this exists when Android/ChromeOS do
| already (the error there is Android is a window manager + runtime
| on top of a kernel, ChromeOS is a window manager) or how
| performance reviews should be run.
| CarelessExpert wrote:
| I disagree. The comments, here, give some real meta-insight
| into how Google is seen in the tech world: As an unreliable
| partner.
|
| Google has clearly and profoundly lost the confidence of the
| broader tech community.
|
| In particular, Google's history of starting and cancelling
| random projects helps explain why people are wondering _why_
| Google is releasing Fuschia: without some understanding of
| their motivations, it 's impossible to trust that it'll
| actually have any kind of extended lifespan.
|
| For all we know, Fuschia, Android, and ChromeOS are basically
| the OS equivalent of Hangouts, Meet, Allo, and Duo, in which
| case becoming in any way reliant on it is a huge mistake.
| refulgentis wrote:
| I probably won't reply past this, any thread on Google is a
| karma sink because it'd require Google users backing me up
| here but...the analogy completely breaks, immediately.
|
| Hangouts _is_ Meet and Allo, if it weren't for the constant
| migration notices leading to constant commentary no one would
| be the wiser, you log into Gmail and chat just like you did
| 10 years ago.
|
| Duo's a featured product, people go too far and think it's
| "yet another video chat app", but, they're forgetting Google
| has to offer both FaceTime _and_ Zoom, it has consumer and
| corporate customers, the corporate one doesn't need stickers
| and hats, the consumer one doesn't need meeting links that
| work in a browser.
| CarelessExpert wrote:
| > Hangouts _is_ Meet and Allo, if it weren't for the
| constant migration notices leading to constant commentary
| no one would be the wiser,
|
| So, let's say that's true (and bluntly, after the Hangouts
| EOL notice I just jumped ship entirely to Signal as,
| frankly, I couldn't be bothered to figure out what the heck
| Google was doing), and that Allo and Meet--which are
| marketed as two different products--are somehow seamlessly
| integrated with the rest of the Google ecosystem so that
| you didn't actually need to grok the differences.
|
| Assuming that was true, Google still _completely botched
| the communication_ , and believe it or not, marketing and
| communication are really damn important. Google could have
| the greatest technology ever, but they're _perceived_ as
| being unreliable, and both their words and their actions
| reinforce that perception.
|
| So, maybe in this specific example, the transition wasn't
| as traumatic is the flat out cancellation of Reader or
| Plus. But in the end, the communication was so muddled that
| it ultimately doesn't matter because to the rest of the
| world outside the Google bubble it just looks like yet
| another example of Google being Google.
| sdenton4 wrote:
| '...perceived as being unreliable...'
|
| AFAICT, the primary effect is that HN commentary on any
| google release has approximately zero SNR. Some back-room
| team could cure cancer and the HN thread would be 90%
| complaints about Reader. Compare/contrast the vast
| numbers of dead github projects, dead startups, and dead
| code generally. (Also, who the fsck calls the
| cancellation of plus traumatic?? That's comedy gold.)
|
| This is an open source release under the MIT license. You
| can use it, fork it, or ignore it...
| kemonocode wrote:
| At best, it'll be something others will be able to leverage and
| make forks out of, and thanks to its permissive license, they
| won't have that pesky requirement to make the source code of
| their fork available. At worst, it'll be yet another product
| abandoned in a couple years by Google because it failed to meet
| some ludicrous goals that are out of reach for 99% of the
| companies in the world anyway. Such is the way people see
| Google nowadays, and can you really blame us?
| yjftsjthsd-h wrote:
| > The first major open source kernel since Linux, and somewhat
| arguably OS X, has been released.
|
| Depending on your definitions, OpenSolaris and Redox would
| object. And it's open sourced in a way that's designed to
| support making proprietary products, so you'll forgive my not
| really celebrating.
| mabbo wrote:
| Many years ago, I interned at Google and a very wise mentor of
| mine explained Google to me in a way that has stuck with me.
|
| "Google discovered a hose that money poured out of. It's called
| 'online advertising'. All that we do now is find ways to make
| that hose go faster, and desperately search for another hose."
|
| Why does Google develop 3+ different OS's? In case one of them is
| a money hose. Why has Google created thousands of products, only
| to cancel most of them once people fell in love? Because they
| decided that they weren't money hoses.
| dougmwne wrote:
| This seems like a pretty flawed strategy to me. Lots of
| improbable products turned into multi-billion dollar companies.
| Tiny videos set to music, watching other people play video
| games, liking pictures of food, and so on. It seems to me that
| it's less about the product and more about the execution. There
| are lots of Google products that could have taken off if they
| had been iterated instead of abandoned. Take Apple as one
| example. They develop a product vision, then spend several
| versions refining the thing till it goes from a curiosity to a
| must have. Or look at Facebook with Oculus, they had a vision
| and released headset after headset, till they found a feature
| set that had the user engagement metrics they were looking for.
| They didn't just give up once the Gear VR proved to be a dead-
| end, which is exactly what Google did with their VR efforts and
| then cleanly missed the boat Oculus is on now with the Quest.
| zozbot234 wrote:
| How exactly does a random piece of IoT junk that looks like it
| could come from any single one of countless fly-by-night
| manufacturers in Shenzen (namely the "Nest Hub" that's now
| running some version of Fuchsia, per the OP) turn into a money-
| making firehose for Google? Just curious, because I'm having
| trouble seeing how this could make sense.
| mabbo wrote:
| The problem is that many good ideas only look good in
| hindsight.
|
| In 15 years, we'll either say "Fuchsia was a brilliant move,
| I'm so glad my home runs on that OS" or we'll say "Remember
| Fuchsia? lol".
|
| Here's what I mean. Acquisitions by Google in 2005:
| Reqwireless (mobile ads, merged with google analytics);
| Dodgeball (social networking, later Google Latitude); Akwan
| (Search tech); Skia (graphics library); Phatbits (Google
| Desktop); allPAY (???); bruNET (???); Android (cheap OS for
| mobile devices).
|
| In 2005, which of these were going to change the world?
| xnx wrote:
| Advertising/influence depends on two things: 1) Knowing what
| you're thinking (e.g. the search request you speak to your
| Nest Hub) 2) Presenting messages to you (e.g. displaying
| search results/suggestions/ads on the Nest Hub screen in your
| home)
| Jyaif wrote:
| Gee, how could the entry point to all the devices around you
| ever become a money making firehose?
| dragonwriter wrote:
| > All that we do now is find ways to make that hose go faster,
| and desperately search for another hose.
|
| There's one other thing Google does a lot of: try to foresee
| and actively forestall how someone else might cut-off or divert
| the flow to the existing hose. While both Chrome and Android
| evolved in directions that explored potential new hoses, they
| were clearly both initially directed at protecting the existing
| hose from being choked off or diverted by monopolies on the
| client side; Android was purchased and engineered to prevent
| Apple gaining the kind of dominance in mobile to do that,
| Chrome and Chrome OS against the desktop Windows monopoly and
| IE.
|
| Google+ was deployed against Facebook and abandoned once it was
| clear that Facebook's position, while making it something of a
| competitor for ad dollars, wasn't, even without a competitive
| Google alternative, an existential threat to Google's money
| hose.
| lern_too_spel wrote:
| This is the big one that people forget. Android itself isn't
| there to force tracking and marketing on users. It's there to
| prevent somebody else from controlling mobile devices and
| being a gatekeeper between Google's services and users. As
| long as nobody else can prevent Google from reaching users,
| Google doesn't care that people can run Android without
| Google services.
|
| In practice, poor development practices and incompetent
| product management has left some bits hard to change. The
| search provider used to be hardcoded with no way for the user
| to override it. That only changed when some early Android
| phones began shipping with Bing as the default. To this day,
| it is impossible to allow any non-system app store to update
| apps in the background. This hasn't changed only because
| Amazon, Samsung, and many other OEMs failed to get developer
| traction with their own app stores. Now that there are
| antitrust rumblings, Google has hinted they will finally fix
| this, but once again, this isn't a threat to the core Android
| strategy of removing gatekeepers.
| jolux wrote:
| > Android itself isn't there to force tracking and
| marketing on users. It's there to prevent somebody else
| from controlling mobile devices and being a gatekeeper
| between Google's services and users.
|
| It can be, and is, both.
| lern_too_spel wrote:
| If that were the case, it would require more data
| collection than competitors and force ads. Instead, you
| can trivially get your location on Android devices (even
| those sold by Google) without telling Google. You cannot
| on iOS. You can install apps on your Android device
| without telling Google. You can develop apps for your own
| device without telling Google. To do any of these things
| on iOS requires exploiting a vulnerability.
|
| Similarly, Google doesn't give itself a privileged
| separate settings for marketing data collection that
| ignore global settings. https://support.apple.com/en-
| us/HT202074
|
| If the point of Android were data collection and
| marketing, Google would abuse configurability of data
| collection at least as much as Apple does, but it does
| not, not even on devices that Google itself sells.
| fragileone wrote:
| Google Play Services is essential for most features a
| user would expect in a modern mobile phone. For running
| bank apps (SafetyNet), many maps apps or apps that
| include maps (eg Uber, Tinder - due to Google Maps API),
| push notifications, etc. It's absolutely used to lock-in
| users to the Google ecosystem and discourage them from
| degoogling.
| KorematsuFred wrote:
| > Google develop 3+ different OS's?
|
| It wont. From what I understand this new OS will replace others
| over time. Also it is way better than existing options.
| paxys wrote:
| That's a wild leap with zero evidence. Fuchsia runs on one
| unimportant production device and has basically zero usage.
| Saying it will replace all of Android and ChromeOS
| is...optimistic to say the least.
| tristanj wrote:
| Project 'Fuchsia': Google Is Quietly Working on a Successor
| to Android
| https://www.bloomberg.com/news/articles/2018-07-19/google-
| te...
|
| > _For more than two years, a small and stealthy group of
| engineers within Google has been working on software that
| they hope will eventually replace Android._
|
| https://news.ycombinator.com/item?id=19702968
|
| > _" And while Android is reaching EOL in the next 4-5
| years, most of this work will be carried on in Fuchsia OS,
| which is set to eventually replace Android"_
| nicetryguy wrote:
| > "And while Android is reaching EOL in the next 4-5
| years"
|
| I wouldn't bet on it. Sounds like IBM OS2 all over again.
| willtim wrote:
| Better than all existing options? I'm skeptical that a kernel
| written in C++ is likely to be better than e.g. a formally
| verified microkernel such as seL4. If they ever rewrite it in
| Rust, then it might be more interesting.
| chasil wrote:
| I am not a microkernel expert, but why is Zircon better than
| QNX as used in the final Blackberry handset?
|
| QNX appears to already be in every market where Fuchsia wants
| to go.
|
| Google could have bought Blackberry and used QNX in Android
| 5, rolling it up to Chromebooks. Why was this not the path
| they chose?
| echelon wrote:
| This would be another benefit of antitrust scrutiny for the
| tech giants.
|
| They're not _innovating_ at this point. They 're twiddling
| thumbs.
|
| If we broke up Apple, Google, Facebook, and Amazon, then they'd
| be forced to fight for survival.
|
| Struggle births innovation.
| ashtonkem wrote:
| Also, Google's internal politics are kind of broken. It's my
| understanding that a lot of the product launches and
| cancellations are a consequence of an internal culture that
| rewards launching new products, but not maintaining or
| improving them.
| CobrastanJorji wrote:
| I suspect that this is a consequence of the above problem.
| Something that's pretty successful and growing at a pretty
| good clip is not a giant spigot of money, and therefore it's
| effectively useless to Google. Maintaining it requires
| programmers that could be better put to searching for the
| next spigot.
| mlazos wrote:
| People say this all the time about every company. For many
| this is true, when seen from the narrow perspective of an
| individual. However for the only metric that people care
| about (stock price and profit) Google's system is incredibly
| successful. Higher ups will not dictate changes like this if
| the company is successful. Culture change at the macro level
| only happens when the company is spiraling at the macro
| level.
| ortusdux wrote:
| As I understand it, higher level promotions require a
| portfolio be compiled and submitted to an anonymous review
| board. A successful product launch is one of the most
| valuable additions to these packets.
|
| This has two logistical consequences: 1 - it's more valuable
| to launch a new product that it is to successfully
| maintain/grow a current one. 2 - the person running these new
| projects tends to get promoted away, leaving it rudderless.
|
| Google could change all this overnight by restructuring what
| these review boards prioritize.
| est31 wrote:
| If a solution is that simple, why hasn't it been done?
| Also, the head of Android has become the CEO, and Android
| is still not rudderless.
| s3r3nity wrote:
| Because the system works? Why fix what isn't broken?
| jolux wrote:
| It works for some things but they've kind of painted
| themselves into a corner with cloud services, many
| companies do not trust that GCP will not just disappear
| without a trace someday.
| danans wrote:
| > product launches and cancellations are a consequence of an
| internal culture that rewards launching new products, but not
| maintaining or improving them
|
| This is very stale information at this point. Product
| launches are now pretty heavily gated, and promotion criteria
| are far less based on launches than on overall impact,
| including but not limited to improving/maintaining products.
|
| (Googler but interpretation is my own)
| opheliate wrote:
| People always say this on HN, and while it's definitely a
| viable explanation for why Google so often cans projects that
| are well-loved, I'm finding it harder to believe the more I
| think about it. If all of us on the outside are so aware of
| this fact about Google's culture, surely _someone_ with sway
| has heard about it, and taken steps to fix it. I'm sure
| Google are well aware of the perception that they're always
| getting rid of products, and would like to fix that. So if
| the explanation was just that the culture doesn't reward
| maintaining existing projects, I'm sure we would have heard
| _something_ about a corporate incentive to maintain stuff.
| phkahler wrote:
| I hate the word, but if there's one thing google has it's
| analytics - data. They can tell if something is growing or
| dying. I'm guessing they could even tell youtube was
| growing before they bought it. But seeing an upward trend
| seems easier than seeing a flat line and deciding it can't
| be turned into an upward trend.
| CarelessExpert wrote:
| > So if the explanation was just that the culture doesn't
| reward maintaining existing projects, I'm sure we would
| have heard something about a corporate incentive to
| maintain stuff.
|
| So, two things:
|
| 1) Changing culture is _really hard_ , especially at a
| company the size of Google, and
|
| 2) Even if they could change the culture, it's possible
| they simply don't care or they believe the benefits
| outweigh the cost.
| refulgentis wrote:
| Neither OP or GP have it right - Fuchsia isn't a "3rd OS",
| it's a kernel, like Linux, except MIT. Maintenance is most
| certainly rewarded, at least in the 5 years I've been at
| Google
| mike_d wrote:
| Eh. If you've been at Google for 5 years then you should
| recognize Fuchsia as another one of the "retention
| projects" where you get paid to twiddle away at something
| cool in the corner and your only real deliverable is not
| going to work for Facebook or Apple.
|
| Sometimes they stumble upon something another PA needs, but
| often it just ends up as a patent or research paper.
| rejectedandsad wrote:
| Facebook or Apple? Not Amazon or Microsoft?
| refulgentis wrote:
| I can forthrightly say you're way, way, off the mark
| here. Another common anecdote in any Fuchsia article, one
| I myself believed at times, but not the case here.
|
| Edit: one of the many, many signs HN has deteriorated to
| a poor clone of subreddit combos is getting downvoted for
| knowing that this isn't a do-nothing project, which
| should be obvious to anyone reading: the whole point of
| the article is _it is launching on consumer hardware_.
| Sad stuff.
| Bud wrote:
| I'm interested: can you name even one more of the
| supposed "many, many signs"? The only one you elucidated
| doesn't really click; nor can I discern that HN is, by
| any stretch, a "poor clone" of anything about Reddit. HN
| has, in fact, many virtues that Reddit can't really
| touch, and it's basically just as old as Reddit, not that
| Reddit really invented anything that hadn't already
| existed for decades.
| refulgentis wrote:
| Look no further than you're being _upvoted_ for
| quintupling down on inanity completely divorced from the
| article that's we're supposed to be discussing, even with
| schoolyard inanity like "can you name even one thing
| backing up your thesis statement?"
| mike_d wrote:
| "Please don't post comments saying that HN is turning
| into Reddit. It's a semi-noob illusion, as old as the
| hills."
|
| https://news.ycombinator.com/newsguidelines.html
| ryandvm wrote:
| I find these playground rule recitations to be a rather
| lily-livered way of stifling discussion. This is a forum
| and we're here to discuss things. Lest you forget, the
| _users_ and their opinions are the most valuable part of
| Hacker News, so how about we dispense with the self-
| appointed hall monitoring? I really don't give a shit if
| there's a commandment about not comparing HN to Reddit.
| If the shoe fits...
| new_realist wrote:
| And if HN did turn into Reddit, how would we know, given
| that we're gagged?
| xvector wrote:
| Why would Google pay employees to not go to Apple?
| echelon wrote:
| The only competition for the giants are the other giants.
|
| Who can divert from Google's massive ad income funnel?
|
| Apple.
|
| Facebook.
|
| (Also maybe several foreign governments' antitrust
| cases.)
|
| An engineer on your payroll is an engineer not on the
| competition's payroll.
| astrange wrote:
| Because Google has infinite money, the execs just hire
| people so they can admire the zoo of smart people they've
| built. Why do they need Vint Cerf, Guido, and Rob Pike?
| Why are they on the MIDI board? Because there's no real
| reason not to.
| 1024core wrote:
| Guido hasn't been at Google since 2013
| therealrootuser wrote:
| I don't have an opinion either way on your position here,
| other than a fact check.
|
| Guido van Rossum (creator of Python) is a Distinguished
| Engineer at Microsoft. Before that, he worked at Dropbox.
| mike_d wrote:
| Before that, he was at Google. Failing to retain an
| employee doesn't invalidate that Google would rather they
| didn't leave.
|
| I get the quarterly check-ins from the "alumni
| recruiting" team, and can assume Guido does too.
| gjsman-1000 wrote:
| Actually, it is a 3rd OS named Fuchsia, which uses a custom
| kernel called Zircon which is MIT.
|
| "Zircon is the core platform that powers Fuchsia. Zircon is
| composed of a kernel (source in /zircon/kernel) as well as
| a small set of userspace services, drivers, and libraries
| (source in /zircon/system/) necessary for the system to
| boot, talk to hardware, load userspace processes and run
| them, etc. Fuchsia builds a much larger OS on top of this
| foundation."
|
| - Fuchsia Docs, https://fuchsia.dev/fuchsia-
| src/concepts/kernel
| BurningFrog wrote:
| This is also typical of mismanaged governments:
|
| Always building new infrastructure, and not maintaining the
| existing one.
| ranguna wrote:
| Isn't that most private companies ?
|
| Searching for sources of income ?
| mandelken wrote:
| No, most private companies are not monopolies (although many
| would not mind I guess).
|
| It seems online advertising has a strong network effect[1],
| where website owners use Google ads because that's where most
| advertisers are and advertisers use Google ads because it has
| most reach (and therefore tracking). This naturally creates a
| monopoly, just like with Facebook, twitter, LinkedIn, AirBnB,
| Uber etc.
|
| [1] https://en.wikipedia.org/wiki/Network_effect
| jillesvangurp wrote:
| I think it's telling that they are 'launching' this with a
| product that barely matters in their product portfolio. That
| indicates to me that they don't see this as an Android killer
| just yet. A bold move would have been to put this on the next
| Pixel. Clearly, that's not happening. If that was at all
| feasible, they would have waited for that and that would have
| been the grand launch. So, clearly it's nowhere near ready for
| such a launch.
|
| Their main issue with this is that OEMs like Samsung probably are
| not in any hurry whatsoever to jump on board and be even more
| dependent on Google. Without OEMs, app developers will drag their
| heels as well and Google is forced to maintain Android and not do
| a half-assed job of it. At this point Google has Android in cars,
| tvs, on phones, etc. Killing that would be suicidal; Google needs
| users interacting with their ads.
|
| If they botch the Fuchsia launch somehow, they'd have more OEMs
| taking things in their own hands and cutting loose from Google
| and forking Android (like Amazon and Huawei already did). They
| clearly are not ready to pull the plug on Fuchsia just yet but at
| this point it's a more than likely outcome. IMHO, they should
| just rip off the band-aid and move on. Most of what is wrong with
| Android is fixable.
| mamcx wrote:
| Contrast with Apple: M1 and pump! launched it the major selling
| laptop.
|
| That is how you know Apple _mean business_.
|
| And this is how you know fucsia/google will not.
| izacus wrote:
| Apple has been launching the "M1" piece by piece for years
| now. They started with Qualcomm/PowerVR cores and ended up
| with custom designs over years of iterative product launches.
|
| I have no idea why do you think M1 is such a green field
| effort when it obviously shares so much of it's design with A
| series SoCs you've been seeing in your favorite iDevice.
| rvz wrote:
| You do realise that Apple's M1 processor + OS porting was a
| 10 year goal to produce the results that you see before you?
|
| Several years ago [0], the same ones here were calling
| Fuchsia dead since 2016 - 2018 and theoretically today it
| should already have died. Today Google has surprised the
| skeptics here and just released Fuchsia 1.0 on a real device
| (earlier than expected) and now you're already calling it
| dead again?
|
| This whole thread sounds like a Linux meltdown club to me. In
| fact, Google is taking / controlling Fuchsia in the same
| direction as to what Apple has always done with iOS / macOS
| and its own silicon.
|
| Perhaps when this decade ends, you will be looking at this
| comment (and this one [1]) via a phone running Fuchsia.
|
| [0] https://news.ycombinator.com/item?id=17568335
|
| [1] https://news.ycombinator.com/item?id=22005286
| justapassenger wrote:
| Where else could've they launched it? It's not like Apple has
| tons of HW products that require M1.
|
| If Google would chose to launch Fuchsia as a base of next
| Android and force all OEMs on it, that would mean people
| managing release should be fired, as that's not how you stage
| major changes.
| mamcx wrote:
| > and force all OEMs ????
|
| This not make much sense, but if Google launched it in his
| own, then at least some OEMs could go along (supposing
| Fucsia is good, I don't know which could their selling
| point)
| Daishiman wrote:
| There's a gigantic difference in developer effort to make an
| appliance OS versus a full-featured mobile OS.
| jillesvangurp wrote:
| They are clearly having commitment issues for that.
| Daishiman wrote:
| I don't see it that way. Reinventing a mobile OS is a huge
| undertaking and it makes little sense to do it just as an
| experiment.
| remus wrote:
| > I think it's telling that they are 'launching' this with a
| product that barely matters in their product portfolio. That
| indicates to me that they don't see this as an Android killer
| just yet. A bold move would have been to put this on the next
| Pixel. Clearly, that's not happening. If that was at all
| feasible, they would have waited for that and that would have
| been the grand launch. So, clearly it's nowhere near ready for
| such a launch.
|
| That seems like a good thing to me. Personally I'm not very
| interested in an OS that's 'bold', I want an OS that's stable
| and well tested and releasing slowly on a limited set of
| devices seems a good way of doing that.
| dragonwriter wrote:
| > I think it's telling that they are 'launching' this with a
| product that barely matters in their product portfolio.
|
| It's certainly the best way to immediately get it a whole lot
| of real world use and feedback with basically zero sales
| effort, and its economical since it lets them transfer
| resources allocation from supporting a dead-end effort to a
| live one.
|
| > A bold move would have been to put this on the next Pixel.
|
| "Bold" is sexy, but not the same as smart long-term strategy in
| many cases.
| adrianmonk wrote:
| Another way of looking at it is that it probably takes a really
| long time to bring up an operating system to the point where it
| is production-ready.
|
| It would be easier to do if you can target one hardware
| platform that does not change so that you don't have to also
| shift gears. If you're building the Great Pyramid, you don't
| want to also move it to a new construction site when it's half-
| completed.
|
| Launching on hardware that was already released could mean they
| gave themselves that time. By the time they're finished (now),
| the hardware is old.
| summerlight wrote:
| > A bold move would have been to put this on the next Pixel.
|
| Which will delay the next Pixel at least several years while
| causing a unprecedented level of fragmentation in the Android
| ecosystem? BTW, I don't expect this kind of experimental
| projects can live without reaching any milestones. Replacing
| Android with Fuchsia is just not a feasible option at this
| moment.
| teddyh wrote:
| Linux was, AFAIK, the last GPL component of Android.
| remir wrote:
| I think this is great! Obviously Google has been working on
| porting Fuchsia to the Nest Hub for a while and I think they made
| the right call by deploying it to this kind of device first. They
| will get more users to test it in real life scenarios. At the
| same time, it's not a device that people use in mission critical
| situation, so if there's issues, it won't cause an uproar.
|
| I could see the rest of their portfolio migrating to Fuchsia OS
| eventually, including both Chrome OS and Android.
| CarelessExpert wrote:
| Who wants to start a betting pool for when they cancel the
| project now that it's officially released into the world? I'm
| going with 2025. Just enough time for it to build up some
| momentum before they pull the rug out from under the user base!
| watermelon0 wrote:
| If this can possibly replace Android, WearOS (or recently
| announced WearOS/Tizen mashup), and ChromeOS, it's quite
| possible that Fucshia is here to stay.
|
| Android apps and Chrome can easily run on a different OS, the
| only problem are device drivers, but I'm sure Google is in a
| position to persuade manufacturers to provide drivers for their
| OS.
| phkahler wrote:
| >> If this can possibly replace Android, WearOS (or recently
| announced WearOS/Tizen mashup), and ChromeOS, it's quite
| possible that Fucshia is here to stay.
|
| So they can cancel more products if they keep Fuchsia!
| dang wrote:
| Please don't repeat shallow-dismissal cliches and particularly
| not with added snark. You may not owe $BigCo better, but you
| owe this community better if you're participating in it.
|
| https://news.ycombinator.com/newsguidelines.html
| Eridrus wrote:
| Sure, define your terms & odds, I'll take your money.
| s3r3nity wrote:
| ChromeOS, Android, WearOS, Fuchsia, Fitbit OS...
|
| Doesn't that make 5? (Potentially dumb question, I know...)
| mikewarot wrote:
| Capability Based Security is a proven solution to computer
| security problems that arose in the Viet Nam conflict. Those
| problems keep cropping up here almost daily.
|
| The simple truth is that access control lists aren't up to the
| task of protecting systems with persistent internet connections
| and mobile code. A Windows or Linux machine can not ever be made
| secure.
|
| A microkernel, with the smallest possible attack surface, that
| never trusts driver code is the way forward. I don't care if the
| eventual winner is Fuchsia or Genode, all I want is momentum
| forward out of the morass that is the current Linux/Windows
| world.
|
| I look forward to trying out Fuchsia and Genode in the next few
| months, and porting a Forth interpreter to each.
| Eduard wrote:
| What does the "Viet Nam conflict" have to do with capability-
| based security?
| lugu wrote:
| I share your feeling, but I'd rather have a none isolated
| driver I can trust than an isolated one I cannot trust. My
| threat model includes fishy OEM doing borderline things.
|
| In driver development I often see abstraction violations or
| very loose abstractions: news hw capabilities can't be
| accounted for when designing framework abstractions.
|
| I have never done dev on windows, but I guess there is a reason
| why the form factor of things running windows is pretty
| limited. I don't see how you can have fixed interfaces in an
| ever evolving wold.
| merrvk wrote:
| It's a damn shame that you have to use flutter, that's all I'd
| say.
| malkia wrote:
| what should be used instead?
| NwpierratorR wrote:
| Android Runtime(ART) obviously.
| refulgentis wrote:
| You don't, any C++ will do, as well as Java, Swift, etc etc
| etc. Also, it's a kernel, not a whole window management system
| + APIs + look & feel like people are reading here
| The_rationalist wrote:
| Probably the biggest Google vaporware ever
| bogwog wrote:
| They got the vapor wave aesthetics with the name at least
| yjftsjthsd-h wrote:
| Vaporware with shipping units and published source code?
| gher-shyu3i wrote:
| Worth noting that golang was evaluated and then discarded for
| fuschia:
| https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d...
| hourislate wrote:
| Just another bot net from Google. How much personal information
| will these devices running this new OS capture/steal? No
| thanks....
| yjftsjthsd-h wrote:
| In all seriousness - how is that any different from ChromeOS or
| Android? It's not like the kernel is what determines privacy
| issues.
| logicslave wrote:
| Ahhaha... Google is basically just a large data collecting bot
| net
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| renewiltord wrote:
| Huh, genuinely thought this was a research kernel type situation.
| But they have a display manager and everything built in to it.
| Wonder why they're using a different kernel instead of using
| Linux.
| [deleted]
| tmccrary55 wrote:
| Google doesn't control Linux.
|
| I guess a microkernel is pretty cool though, the academic
| ideal.
| johannes1234321 wrote:
| Linux is GPL.
| wolverine876 wrote:
| I'm suprised to find people surprised at the development of a new
| OS. Linux is around 30 years old; Unix and C are around _50 years
| old_.
|
| Eventually the parameters of the world and of user needs shift
| far enough from the original design that it's less expensive to
| develop something new than to adapt the old thing. Sometimes it's
| impossible to adapt the old thing: for practical purposes, no
| amount of work will make C secure.
|
| EDIT: Apparently Fuschia uses C and C++, and uses them
| exclusively in the kernel (if I understand correctly), and Rust
| and Dart are permitted for some uses, if this document is up-to-
| date:
| https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/d...
|
| It's an impressive run, but the ground has shifted, slowly, under
| our feet, and now Unix/Linux are no longer a good fit. Let's not
| be conservative; let's do what our smarter predecessors did and
| embrace change.
|
| Fuschia is free and open source, per other comments in this
| thread. If that's true, let's be very thankful that the successor
| to Unix, if that's what Fuschia becomes, is FOSS. If Google put a
| proprietary OS on its phones, etc., even if they didn't charge
| for it, they'd have a lot of market power and they'd be competing
| with a 50 year old OS. It could be a terrible blow to FOSS.
| amelius wrote:
| > It's an impressive run, but the ground has shifted, slowly,
| under our feet, and now Unix/Linux are no longer a good fit.
|
| Unix is still a good fit for a kernel; e.g. it is used by
| Apple. The stuff built on top of the kernel (UI, etc.) can
| change, of course.
| rektide wrote:
| It's notable that this release has nearly ZERO attempt to market
| to or engage with 3rd party developers. It is solely for 1st
| party apps, solely under their control. Google picked a consumer
| device with extremely limited, contained functionality to target
| Fuchsia to.
|
| This is an extremely crazy twist for a device that is supposed to
| play a star, core role in the home, and a strong indicator to me
| of where we are in the War Against General Purpose Computing.
|
| There are definitely ways for 3rd parties to add to the
| experience, with the chatbot platform, but it's all expressed in
| Google's existing mold, via Actions with Google Assistant & other
| pre-baked systems of manipulation.
| stjo wrote:
| This makes no sense to me. Why is google building it? They want a
| more stable experience by using a microkernel and pushing
| everything to the userland? Maybe this will help with updates and
| vendors letting their devices rot? Or is it something to do with
| licensing?
| dragonwriter wrote:
| > Why is google building it?
|
| As the longer-payoff/higher-risk companion to Chrome OS as the
| longer-payoff/higher-risk companion to Android, in a nested
| generalization of the Poseidon-and-Polaris strategy discussed
| as a model (among other places) in Mary and Tom Poppendieck's
| _Implementing Lean Software Development_.
|
| It's kind of a go-to strategy for Google in important markets;
| when you are essentially made of more money than you can figure
| out ways to spend, internal diversification so that you
| literally don't make the choice between the immediately useful
| but maybe future-limited approach and the longer-time-to-
| payoff, higher-risk approach less tied to what is currently
| optimal makes a lot of sense.
| extrapickles wrote:
| Most OS's out there are unsuitable for making appliances, which
| this seems aimed at.
|
| Right now your choices are a Realtime OS or Linux. Realtime OS
| don't support making GUIs and Linux has a lot of foot-guns.
|
| Normally, updates to an appliance are one binary blob, this
| looks to support all of the various pieces having their own
| blob, and allow the OS to be updated independently from the
| application binaries, so security updates can happen without
| the appliance vendor needing to do anything.
| nyanpasu64 wrote:
| QNX is a microkernel RTOS which supported GUIs... but
| BlackBerry killed off support for using it on the desktop,
| and BlackBerry phones died out. IDK what else is using QNX
| technology now.
| kemonocode wrote:
| Cars [0], apparently.
|
| [0] https://blackberry.qnx.com/en/software-
| solutions/automotive/...
| jaywalk wrote:
| Ford uses QNX for SYNC 3, although they are abandoning it
| and switching to Android Automotive starting with the
| 2023 model year.
| handrous wrote:
| > Realtime OS don't support making GUIs
|
| My three favorite GUI operating systems, putting aside
| software support, are iOS, BeOS, and... Photon on QNX.
| kenhwang wrote:
| It's probably preferable than continuing to use the JVM-clone
| like it's an OS, while porting Linux to be the actual OS to run
| their JVM-clone OS.
| AshamedCaptain wrote:
| Who needs an excuse to keep a lot of very senior OS developers
| happy to be employees?
| jcranmer wrote:
| I can't speak as to their motivations specifically, but one of
| the things that I've noticed from poking around the kernel API
| is that the kernel APIs are much more coherently designed than
| the conventional kernels we have are.
|
| In particular, one of the key design goals appears to be a
| heavy use of a capabilities-enabled handle-based API, even for
| more conventional syscalls (e.g., mmap). One of the benefits of
| this approach is that it simplifies a lot more cross-process
| management stuff; you can inspect (or edit!) another process's
| memory maps, for example, with the same system call that a
| process would use to edit its own. It would also enable
| something like CreateRemoteThread; it would definitely be far
| easier to write a debugger for Fuchsia than it is for Linux.
| astrange wrote:
| Mach/Darwin/iOS has this and I suppose it's nice, but it does
| break down when you introduce POSIX compatibility, because
| you have to deal with the less expressive and insecure
| concepts like pids and file descriptors there.
| wallscratch wrote:
| Os noob here, what's less expressive / insecure about PIDs
| or file descriptors?
| jcranmer wrote:
| PIDs and file descriptors are effectively global tables
| indexed by integers that are reused. This means that you
| have inherent race conditions: you want to an operation
| on pid X, but in between the time you decided you want to
| do it and the time you actually did it, pid X died and a
| new pid X was created. This is even worse for PIDs, since
| there's basically nothing you can do to actually have any
| sort of locking to avoid race conditions.
| zozbot234 wrote:
| Linux has PID namespaces now, so it's not global. But
| yes, the race conditions you describe are real, and can
| only be addressed via new API's.
| Daishiman wrote:
| Because things have changed since the time Linux became
| ubiquitous.
|
| We have moved away from a world of shared libraries,
| filesystems, and UNIX users and permissions into a world of
| shared-nothing (no shared memory, no shared filesystem),
| capabilities, new and extremely aggressive attack vectors, and
| a need to compartmentalize and virtualize at more fundamental
| layers even if it comes at a performance penalty.
|
| You can't retrofit a microkernel-like abstraction on top of
| Linux. At the same time, a lot of the features you need for a
| shared multi-user system are basically cruft for modern mobile,
| single-user systems with little use for shared resources (not
| saying they're not shared; it's just that you can no longer
| trust apps installed in the user system so expecting apps to
| behave nicely is out of the window).
|
| The new wave of OSes embraces formal correctness when possible,
| JIT, garbage-collected application programming languages,
| tightly-enforced resource boundaries, deny-by-default security
| models, provably-safe system programming languages (Rust and
| whatever else will come), immutability and copy-on-write at the
| cost of filesystem space, and secure memory abstractions for
| more RAM.
|
| So why spend time supporting features that new OSes don't need,
| optimizing things that are no longer priority (HDD schedulers
| vs no-op SSD schedulers), when for once it _is_ actually easier
| to start over and fixing a lot of traditional pain points?
| zozbot234 wrote:
| > a lot of the features you need for a shared multi-user
| system are basically cruft
|
| That's just not true. A "single-user" system running multiple
| "apps" where each app is actually endowed with its own user-
| like privileges is just a shared multi-user system by another
| name. There's no reason not to reuse the existing
| infrastructure, if perhaps with some tweaks.
| wolpoli wrote:
| A large investment like this is likely a strategic move.
|
| Perhaps it is a corporate wide move to stop contributing to
| Linux. Or perhaps they plan on displacing Linux from the
| computing world.
| tomComb wrote:
| Good questions, and I don't know the answers, but it is kind of
| odd (particularly given the pace of change in other areas of
| computer tech) that the world's most popular operating system
| was designed so long ago, and it seems like there is so little
| going on in this area.
|
| Of course, Apple is hard at work on iOS, but we don't know what
| sort of under the cover innovations that might good.
|
| So. I'm glad to see something new.
| LordDragonfang wrote:
| >the world's most popular operating system was designed so
| long ago, and it seems like there is so little going on in
| this area.
|
| Are you talking about Linux, or Android specifically? Either
| way, I don't really agree that there's "little" going on
| there.
| yalogin wrote:
| This has been open knowledge for a few years now. I was fully
| expecting it to be cancelled before launch. In that sense am
| surprised it saw the light of day.
|
| However, I have never seen an explanation of why they need an OS
| written from scratch. The whole kernel and driver ecosystem,
| apps, development model, every single thing written from scratch.
| It took 6 years too for it to be productized. Why would anyone
| make that kind of an investment? It has to be extremely
| compelling. I would like to hear it from them
| na85 wrote:
| Linux wasn't invented at Google.
| summerlight wrote:
| It's worth noting that Nest is using (likely heavily customized)
| Linux, pretty hard to keep sync with the upstream due to its
| monolithic kernel architecture while doesn't get aggressive
| investments like Android. But lifespan expectation for those
| products is much longer (~10 yrs) than typical smartphones (3~5
| yrs) which leads to more maintenance headaches as Google
| accumulates their product portfolio, even compared to Android
|
| And... Even notorious Google couldn't completely pull their hands
| from Nest Secure although they decided to discontinue its
| production and sales. This is probably the problem they want to
| solve with Fuchsia. In this context, using Fuchsia is a pretty
| natural engineering decision. Fuchsia team can onboard its first
| customer while Nest team can outsource lots of its maintenance
| issues to a more appropriate team. I guess they already consider
| using Android before, but probably that's a no-go option since
| its support usually ends before 5 years.
|
| Of course, Android and Chrome OS have completely different needs
| and environments, so I don't expect them to converge to Fuchsia
| in any foreseeable future. More likely scenario would be a shared
| ecosystem based on Play Store which enables more future strategic
| movements.
| paxys wrote:
| Damn, are microkernels finally back?
| blendergeek wrote:
| Possibly unpopular opinion:
|
| This is a tragedy for Free Software. The Linux kernel (and
| specifically its GPL nature) is the best thing that has ever
| happened to Free Software drivers and embedded systems. The only
| reason that companies release open source drivers for their
| products is because they are legally required to in order
| integrate with the Linux kernel. Clearly Google wants to move
| away from this world.
|
| I will mourn the day that a non-copyleft kernel supplants Linux
| and our only reason for free software hardware support comes to
| and end.
| IshKebab wrote:
| I disagree. One of the things that stops people from actually
| _using_ Linux is that it is so hard to get devices working
| properly.
|
| I would be willing to accept some closed source drivers if it
| meant Linux actually worked reliably on most modern hardware
| (no it really doesn't).
| lamontcg wrote:
| Well if you hang Free Software's hopes entirely on the Linux
| kernel, or the Linux kernel doesn't mature to the point where
| it isn't the hall monitor for everyone's code quality, then
| that might be what happens.
|
| Darwin might be knocking. Evolve or die.
|
| (And its a bit weird that the Linux kernel is so centralized
| with a cabal lead mostly by one dude who yells at everyone on
| the planet about their shitty driver code quality. If you're at
| all Libertarian or libertarian, that should probably bug you a
| bit that Free Software picked that as the ideal model.)
| [deleted]
| est31 wrote:
| I think you give some valid concerns. I definitely understand
| you, but I want to give some counter arguments to where I'm
| seeing chances with Fuchsia in addition to the dangers that you
| rightfully point out.
|
| First, there are thriving non-copyleft driver projects, like
| mesa. No copyleft forces Intel to contribute to it. No copyleft
| forces AMD.
|
| Second, even in Linux, many drivers aren't maintained by their
| vendors, but third parties. I think that an upstream driver is
| generally easier to deal with for most parties, so most parties
| would prefer it. If fuchsia is indeed as modular as it promises
| to be, users can swap out those drivers, at least in custom
| ROMs. Android custom ROMs already copy over proprietary drivers
| from the native OS upon installation.
|
| Third, the GCC compiler has artificially restricted the ability
| to use it as a backend for third party languages, which led to
| many projects choosing LLVM instead. These projects now
| contribute to LLVM's success. Yes, some extensions to LLVM are
| proprietary. Still many companies contribute to LLVM directly.
|
| Fourth, legal action doesn't turn a company into a good
| citizen. They might release the source code in the end but they
| become extremely hostile to free software projects coming
| forward, because suddenly the legal department got involved.
| Those employees who share the cause can't freely talk on
| mailing lists any more because all mails to the project first
| require approval by a company lawyer. Etc. The released source
| code might be unusable anyways because it's done to a fork of
| an outdated version of the kernel.
| zozbot234 wrote:
| > First, there are thriving non-copyleft driver projects,
| like mesa. No copyleft forces Intel to contribute to it. No
| copyleft forces AMD.
|
| This is not entirely true. Mainline Linux has a longstanding
| policy of not including kernel-side graphics support in the
| officially-released tree unless it can be used with a totally
| Free userspace. So Mesa is, to some extent, piggybacking on
| incentives that have been established as part of the GPL'd
| Linux kernel.
| wolverine876 wrote:
| How is Fuschia licensed?
| therealrootuser wrote:
| It isn't GPL; I believe it is tri-licensed in BSD, MIT, and
| Apache 2.
| asciimike wrote:
| https://fuchsia.dev/fuchsia-
| src/contribute/governance/policy...
| blendergeek wrote:
| Fuschia is licensed under the BSD license as far as I can
| tell.
|
| This allows device vendors to use fuschia without releasing
| device specific software to the community resulting in
| further degraded software freedom.
| bogwog wrote:
| This is also why Android is such a security and privacy
| nightmare, with the terrible user experience (and environmental
| impact) of having to buy a new phone every 1-2 years.
|
| Because Android is not GPL.
|
| Google owns the software, so manufacturers really only make
| money from the device sales, and bundled spyware.
| jeroenhd wrote:
| You don't need a new Android phone every two years and you
| haven't needed to for a while now. The Android situation
| certainly isn't as good as the Apple situation, but it's not
| as bad as ten years ago.
|
| For most people, the only problem using a five year old phone
| today is the degraded battery. Almost all software is
| backwards compatible with the old operating systems and
| nobody simply outside IT cares about kernel updates.
| Journalists, human rights activists and American refugees
| like Snowden should fear kernel exploits, your average Joe is
| pretty unlikely to actually get infected. The massive
| segregation of Android devices is actually a good thing in
| this scenario, because you need to prepare your exploits for
| whole ranges of devices and several versions software
| versions, making "the Android botnet that ends all Android
| botnets" incredibly hard to build.
|
| The Android privacy nightmare is all Google being built
| around spying; the security nightmare is mostly due to brands
| like Samsung not releasing timely updates, not necessarily
| because Broadcom and Qualcom don't build patches.
|
| With medium to high end Samsung devices now reaching four
| years of Android security updates, the entire field is slowly
| becoming much better. The cheaper, low-end devices lag
| behind, but it figures that people who cannot afford a $300
| phone can't pay for software support and the profit margins
| become razor thin the cheaper the phone gets. Five years of
| software updates for a $90 phone just isn't realistic.
|
| This whole situation is why I lament Windows Phone's failure.
| Microsoft had the right idea, which carriers hated, that the
| operating system should be independent of the rest of the
| device. Carriers wanted to force their ugly branding
| everywhere and fought hard against MS, who themselves bumbled
| and failed spectacularly by breaking backwards compatibility
| with every major Windows Phone release, and the entire
| project was doomed to fail.
|
| Android could have been similar to Linux; a Google-supported
| core repository with vendor packages for drivers, updatable
| in the same way Debian is. Nobody outside the hacker
| community seems interested in this approach, but it could
| have been.
| JI00912 wrote:
| Are there any privacy aspects to this? Does Google track
| everything that is going on?
|
| Do you have control over your device or can Google release
| updates and do whatever they want with it?
| goodcjw2 wrote:
| Disclaimer: I used to work and knew a lot Fuchsia developers very
| well.
|
| No, Fuchsia is not a pet project. Instead, it's solving a very
| realistic problem: building a clean driver interface, while keep
| it open and gain hardware vendor support.
|
| Anyone have shipped a Linux-based embedded system (including
| Android smartphone) knows the pain: there are tons of ad hoc
| driver source files need to be manually merged/rebased against
| the Linux Kernel. Want to upgrade the Linux kernel from 4.x to
| 5.x? Good luck redoing lots of merges and rebasing. There are
| tons and tons of git branches floating around, crazy examples
| like: "Linux-4.11-some_soc_vendor-some_oem-random_device-
| random_project-rev-1.3". It soon becomes unmanaged and device
| manufactures just gave up on keeping up with OS upgrades.
|
| Overall, the monolithic natural of Linux Kernel and its strict
| licensing terms made it hard to get code upstreamed back or to
| write properly modularized driver extensions. Even when people
| managed to get it work, you end up something like AMD's GPU
| driver takes 10% of Linux kernel [1].
|
| The term of OS is heavily overloaded. But Fuchsia's goal is NOT
| to build other Android, but mainly to replace the Linux kernel.
|
| Is it worth it? Can Google pull it off? I don't know. But it
| probably worth a shot.
|
| [1]
| https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....
| xyzzy_plugh wrote:
| I half agree with you. It's not so much that Linux lacks a
| clean driver interface, it's really that OEMs write shitty
| software that doesn't belong upstream. Ideally vendors stop
| writing garbage drivers and distributing hacked up kernels with
| their "sample code" (but ends up in production) and opaque
| binary blobs.
|
| Android unified vendors but simultaneously made them even
| lazier. It's somewhat hard to get non-android code from vendors
| in the past 5+ years. Which makes me very sad.
|
| Will Fuchsia somehow convince vendors to produce better
| drivers? I don't see how Fuchsia makes this problem
| significantly easier. Shitty vendors will continue to be shitty
| vendors and take the easiest path to making money.
|
| In any case, the Kernel's super power is its community, not the
| software itself. The LKML is vast and full of knowledge, a
| strange intersection of open source, research and corporate
| exploits.
|
| I don't see Fuchsia replacing that anytime soon.
| londons_explore wrote:
| I think OP's point is it doesn't matter if the drivers are
| crappy, as long as they only use a fixed and we'll defined
| interface.
|
| If drivers all had a well defined interface, the exact same
| driver, binary or source, can be used across any OS version,
| and maybe even on other OS's with the right shims.
|
| Then you don't need driver manufacturers to all collaborate
| to update the OS.
| gosukiwi wrote:
| Will we see GNU/Fucshia someday maybe then? :P
| onlyrealcuzzo wrote:
| The Kernel is an MIT license, and the user space is BSD [1]
|
| > The Fuchsia kernel is released under the following MIT-
| style license: /zircon/kernel/LICENSE.
|
| > All Fuchsia user space components are released under a BSD-
| style license: /LICENSE or an Apache 2.0 license:
| https://fuchsia.googlesource.com/infra/+/main/LICENSE.
|
| > All code that is BSD-licensed has an additional IP grant:
| /PATENTS.
|
| [1] https://fuchsia.dev/fuchsia-
| src/contribute/governance/policy...
| zozbot234 wrote:
| > Overall, the monolithic natural of Linux Kernel and its
| strict licensing terms made it hard to get code upstreamed back
| or to write properly modularized driver extensions.
|
| The postmarketOS folks are doing it, starting from downstream
| OEM Linux kernels, and the patches are being accepted on LKML.
| It's a lot of work because so much ARM hardware is its own
| weird mixture of long-supported basic IP blocks and newer stuff
| with its own quirks, and ARM has nothing like the plug-and-play
| hardware enumeration of modern x86 systems. So untangling all
| of this just takes a lot of time and effort. But this has
| nothing to do with Linux per se; it's all about the ARM system
| architecture itself and the SoC-based industry that has sprung
| up around it.
|
| And no, running a microkernel-based system won't help at all,
| because any hardware that's part of the SoC can read or write
| arbitrary memory hence your driver can (perhaps unwittingly)
| subvert the very same security mechanisms you're supposedly
| relying on. Not to mention that some of these drivers handle,
| e.g. voltage regulators that will happily fry your hardware
| irreversibly if poked the wrong way. _All_ of this stuff is
| inherently part of the trusted base of your system, so you 're
| not going to do any better than what Linux already gives you.
| Steltek wrote:
| > the monolithic natural of Linux Kernel and its strict
| licensing terms made it hard to get code upstreamed
|
| > In 2018, we got the OS running natively on a Pixelbook. After
| that, the Fuchsia team stopped doing its work in the open and
| stripped all UI work out of the public repository.
|
| Linux (AFAIK) still doesn't require the typical CLA paperwork
| or copyright assignment. The "strict licensing terms" of the
| Linux kernel ensures that kernel stays open. If openness is a
| goal of Fuschia, the GPL would not be a problem here.
|
| If anything, Linux needs a harder license, like GPLv3 or
| similar, to maintain openness in a world of locked bootloaders
| and not-even-half-baked clone appliances with manufacturers who
| aren't interested in coughing up the kernel source.
| yjftsjthsd-h wrote:
| Okay, but having a stable interface doesn't fix vendors
| shipping bad code, it just decouples it so you can run terrible
| drivers on a less-terrible kernel. Better yet, Fuchsia removes
| any obligation for vendors to share code (by _both_ separating
| drivers from the OS and having the OS itself be permissively
| licensed), so third parties can 't even start from vendor code
| and try to improve things.
| dvfjsdhgfv wrote:
| > The term of OS is heavily overloaded. But Fuchsia's goal is
| NOT to build other Android, but mainly to replace the Linux
| kernel.
|
| To paraphrase a popular saying, "the driver interface
| apparently has an abstraction problem, so Google created
| Fuchsia - and now we have two problems."
| linuxftw wrote:
| It's a pet project. If you want to solve the kernel ABI
| problem, you can easily hard-fork and maintain that ABI
| indefinitely from any Linux kernel.
|
| And if that sounds like it's too hard, imagine how hard it is
| to maintain your own kernel, and all the associated user space
| you now have to reinvent.
|
| In fact, you don't even need to hard fork. You could have your
| own rolling tree with a stable "Android ABI" interface that
| vendors can write drivers against, optionally.
|
| In any case, no company in their right mind would use this
| project. Google has proven repeatedly they will enforce a
| monopoly on their platform one way or another.
| google234123 wrote:
| It accomplishes much more than just solving the kernel ABI
| problem.
| linuxftw wrote:
| It doesn't accomplish anything because nobody's going to
| use it.
| google234123 wrote:
| May the best software win.
|
| Anyway, if they succeed in integrating it into Android
| then that will be a lot of users :P
| matheusmoreira wrote:
| Why can't the vendors just contribute their drivers to the
| kernel? Why is it so hard? Looks like Intel is doing it and
| their products just work on Linux as a result. Why can't these
| shitty mobile hardware manufacturers do the same?
| delroth wrote:
| The sad answer is that they can't be bothered to meet the
| quality standards expected for upstream kernel code. Easier
| to just throw garbage in a tarball and ship privesc
| vulnerabilities to millions of users.
| 908B64B197 wrote:
| Driver supports costs money, vendors make money when they
| sell chips.
|
| They treat drivers and software as a cost-center, so the
| software quality is typically horrible. Can't be merged,
| won't be merged.
|
| Microsoft knew that, so they made sure to be ABI compatible
| so they could keep updating the OS.
| matheusmoreira wrote:
| > Microsoft knew that, so they made sure to be ABI
| compatible so they could keep updating the OS.
|
| I don't remember it that way. I remember buying
| motherboards and receiving CDs full of drivers for the many
| Windows versions. I remember having to scour the internet
| for drivers and finding a different one for each Windows
| version. I remember failing to find drivers for new
| versions of Windows because the manufacturer couldn't care
| less. I remember incredibly shitty manufacturer
| applications that took over one minute to display a window
| on the screen. I even managed to reverse engineer one of
| those into a free software user space driver.
| fmakunbound wrote:
| I feel this must explain why every Android device I've
| owned has felt janky in some way, while with an Apple phone
| it just seems to work.
| zozbot234 wrote:
| > Microsoft knew that, so they made sure to be ABI
| compatible so they could keep updating the OS.
|
| That's just not true. A lot of hardware support was
| stranded by OS version updates, especially pre-Vista and
| Win7. It's reached a point where Linux deals a lot better
| w/ some older hardware than any currently-supported Windows
| version.
| 908B64B197 wrote:
| Some of that is just getting rid of compatibility code
| for misbehaving drivers.
| fragileone wrote:
| Not just hardware but even older Windows applications run
| way better on WINE than on Windows 10. Microsoft doesn't
| care about reverse compatibility or long-term support for
| consumers.
| BugsJustFindMe wrote:
| A small handful of times over many decades when the
| driver model changed, not after every update.
| BugsJustFindMe wrote:
| > _Why can 't the vendors just contribute their drivers to
| the kernel?_
|
| What makes you think they want to? They want you to buy the
| next chip and the next and the next, not keep using the
| previous one with a new OS.
| matheusmoreira wrote:
| > What makes you think they want to?
|
| Do they not care about having a high quality product?
| BugsJustFindMe wrote:
| They do have a high quality product. And then you have to
| buy their next high quality product instead of continuing
| to use the old one. Their products are hardware, not
| drivers, and they get more money by selling more hardware
| rather than letting old hardware get updated.
| matheusmoreira wrote:
| Can't use the hardware without the drivers. If the driver
| is low quality proprietary code that can't be fixed or
| updated, they don't have a high quality product.
| BugsJustFindMe wrote:
| And yet here we all are with umpty billion Qualcomm SoCs
| floating around and nobody complaining about how
| Qualcomm's chips don't work well (except, of course, in
| comparison to Apple's).
|
| The hard reality that Linux kernel driver model stalwarts
| must face is that the only measure that matters to these
| companies is profit margin, and the economics just are
| not in favor of upstreaming their drivers. So knowing
| that, do we continue to yell into the night or do we
| implement a solution that doesn't leave umpty billion
| devices without kernel security updates?
| wott wrote:
| Nowadays, a lot of products go out of production and are
| replaced by the next model before they have time to
| settle and get a consumer reputation. It sometimes feels
| like they do only 1 production run per model and then
| bye-bye. So, quick and "good enough", "as good" or "not
| worse than others" is good enough :-/
| dogma1138 wrote:
| AMD already does and that creates a lot of friction both due
| to the bloat of the kernel the majority of which is now the
| AMD driver and the issue with code conventions and quality.
|
| Unless hardware vendors agree to support a generic driver for
| each device type which can be maintained by the Linux kernel
| team it's going to be a total nightmare and even then you
| need an easy model to extend the generic driver with a device
| specific one through an easy interface.
| IshKebab wrote:
| They might want to keep their driver source closed, and even
| if they don't upstreaming code into the kernel is simply a
| ton of extra work.
___________________________________________________________________
(page generated 2021-05-25 23:01 UTC)