11 ms·

I worked at Google up until 2017. In the last year or two of my time there I had many conversation with some people who worked for or were adjacent to the Fuchs

by cletus 4y ago

I worked at Google up until 2017. In the last year or two of my time there I had many conversation with some people who worked for or were adjacent to the Fuchsia team. It's hard to believe it's been 6 years. We're now talking billions (quite literally) of dollars later and all we've got to show for it is an OS for the Nest? The core of the technical leadership on Fuchsia were, I believe, Android refugees so they had a very Android-centric way of looking at the world. The two premises for Fuchsia seemed to be: 1. There is no way to remove devices drivers from the Linux kernel. That goal was seen as desirable in terms of improving reliability, how long devices were supported for and the time taken to roll out updates. Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers; and 2. The Android ecosystem itself needed a reboot. This one is harder to define but, for example, you had duplication of services between the all-but-dead AOSP and Play services. Remember these are statements of fact. These are my impression of the beliefs of Fuchsia technical leadership. Google had always had hopes that there would be a healthy ecosystem of phone manufacturers. For awhile there were but now? Now it's really just Samsung. Samsung and Google, much like the Wintel alliance of Microsoft and Intel years ago, was an unhappy marriage of convenience. Samsung had tried (and repeatedly failed) to make their own OS. And Google didn't like Samsung being the consumer face of Android. So the question I raised was: given that Samsung in an unhappy spouse in a loveless marriage of necessity, how are you going to convince Samsung to switch to Fuchsia? I still see no answer to that. Maybe something interesting and useful will come out of Fuchsia eventually. I for one am not holding my breath however. It screams of being the pet project of some very high level engineers.

ncann 4y ago
> It screams of being the pet project of some very high level engineers. This seems true of so many Google projects lately, big promises that don't deliver and get shelved in a few years.
- lumost 4y ago
  This is a Truism of big anything. Once people are high enough in an organization and we’ll connected enough… their projects are unassailable. I can guarantee you that somewhere in google is a team of 3 getting shut down for making 100MM a year with a boring tech focus. Meanwhile Fuscia continues unquestioned.
- cbozeman 4y ago
  This isn't a "lately" phenomenon. This has been the Standard Google Playbook for about the past 15 years.
- baobob 4y ago
  This comment and the parent got me thinking of the contrast between "privilege" and "merit" as useful ways to describe some of the difference between small company land and the likes of Google. How many product disasters could be attributed to the wrong people accidentally possessing or ageing into privilege? I wonder if Plus or Reader could be phrased in these terms
  - djbusby 4y ago
    I don't think one just ages into privilege. One early win to make some marks would certainly help and give privilege for next projects.
    - lumost 4y ago
      This is true, but there is a survivorship bias. Someone who sticks around gains credit from the work of those who left. Exponential growth in a core business means promotions for everyone. Someone who is considered "good" gets looped into key projects. After 4-5 years these become a self-fulfilling prophecy in some organizations, as "good" people get attached to the growth drivers.
- summerlight 4y ago
  Being a pet project of very senior engineer is not necessarily a bad thing. You know what? MapReduce, BigTable, Spanner, TensorFlow and tens of other important infrastructures were once Jeff Dean's toy projects. I don't think Google even can exist without them... Important thing is execution of the project, not its inception.
  - kortilla 4y ago
    Something changed though. Those projects are ancient
    - metadat 4y ago
      Jeff Dean is also a legend and not just a "senior engineer", more like google's version of John Carmack.
      - jpgvm 4y ago
        Phil Cutler is probably a better equivalent but yeah, definitely legend status either way.
        daydream 4y ago
        You mean Dave Cutler?
        jpgvm 4y ago
        Yes, brain fart. No idea how I subbed Dave for Phil but I guess that is what I get for typing while tired.
    - summerlight 4y ago
      You want some recency? Search for Pathways, which is a backbone for PaLM.
  - mike_hearn 4y ago
    Those projects all had a unique and very successful take on the problem they were solving, though. The problem with creating a new OS is getting people to write apps. It's not really justifiable if your new OS doesn't take a very different approach to how apps are written and yield much better results as a consequence. If you build a new OS and rely too heavily on emulated Linux apps, then what is your value proposition? You're effectively admitting defeat up front by saying there's no real reason to write a native app; that running Linux apps is good enough. With Fuschia this problem is especially apparent because it's not really obvious from reading the docs what its value prop really is, or how the UX of a native app differs from any other platform. Successful operating systems don't normally have this problem. You could argue that Linux was an exception, but there the value prop was being an open source PC UNIX and that price/compatibility point was enough. Other platforms though, like macOS or Android, needed to have a very clear offering up front to get developers to care, as well as a large library of first party apps.
kernal 4y ago
>given that Samsung in an unhappy spouse in a loveless marriage of necessity What makes you think Samsung is a "unhappy spouse"? They save billons by having Google develop Android and spoon feeding them security updates each month all for free. Samsung can leave this relationship any time the want and they've probably though about it. Then they saw what happened to Huawei and Samsung fell in love with Google all over again. Samsung doesn't want to be Huawei-d, but they will be if they ever leave Android and the Android ecosystem. >how are you going to convince Samsung to switch to Fuchsia? I still see no answer to that. Why wouldn't Samsung switch to Fuchsia? If Fuchsia really is the next generation of Android then it seems logical to hop on that train or be left behind and trying to maintain a sunset OS with limited, if any, support from Google.
dataflow 4y ago
> healthy ecosystem of phone manufacturers. For awhile there were but now? Now it's really just Samsung. Confused, aren't there a ton of phone manufacturers? Sony, OnePlus, Asus to name a few off the top of my head. In what sense are they all "unhealthy" except Samsung?
- syntheticnature 4y ago
  I don't have exact data to hand, but my recollection is that Samsung is the only Android phone manufacturer turning a profit on phones.
  - dataflow 4y ago
    I haven't looked up any others, but I just looked up OnePlus and saw this [1]: > For the first time in company history, OnePlus passed the $1 billion mark in revenue and became profitable. (2018) [1] https://www.androidauthority.com/oneplus-profitable-830348/ https://www.androidauthority.com/oneplus-profitable-830348/
  - smegger001 4y ago
    if that case the case why are they all still making android phones if it isn't profitable? My perhaps naive presumption is that they are in fact profitable but not a high margin market. If it was not a profitable venture they wouldn't make them
- ejj28 4y ago
  It's the market that's unhealthy. Samsung and Apple are really the only big players at this point - Sony has sub 1% market share, Asus likely even less. OnePlus is owned by OPPO and together they have about 9% market share. Samsung is the only brand that is actually able to compete with Apple.
  - dataflow 4y ago
    Still confused. So what would be healthy in your mind? The sheer number of manufacturers competing in the Android ecosystem seems like the definition of a healthy market for Android phones—in contrast with iOS where there's 1 player. Obviously you can't have 10 manufacturers each with 50% market share, so what sign of health are you looking for that deviates so strongly from the status quo?
yjftsjthsd-h 4y ago
I have never worked at Google, but some of this seems... odd from my perspective. > Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. This is absolutely true. However - and this makes no sense to me - Chromebooks apparently do upstream everything, even for ARM models. Any idea what went right there? > you had duplication of services between the all-but-dead AOSP and Play services. My understanding from the outside is that Google likes to pretend that AOSP is sufficient for antitrust reasons but really wants to control everything directly; you can't solve that by creating a new product unless the hope is that nobody cares that the "new" ecosystem doesn't get examined by the same standards. > Remember these are statements of fact. I'm assuming you meant to type "not" there? > Google had always had hopes that there would be a healthy ecosystem of phone manufacturers. For awhile there were but now? Now it's really just Samsung. Samsung is certainly the biggest, but it's hardly the only name in town; https://www.appbrain.com/stats/top-manufacturers https://www.appbrain.com/stats/top-manufacturers puts them at ~34% with the rest in the long tail.
- djbusby 4y ago
  One guess is that getting drivers upstream for Chromebook improves the possibility of external vendors making hardware. And Chromebook I seems to be supported for a long time.
  - raggi 4y ago
    The patches & drivers involved in most Chromebook peripherals are much closer to that of a PC in architecture than for the SoC's that go into phones. In this regard the patches are far less invasive, and thus more easy to match with upstream requirements.
- toast0 4y ago
  >> Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. > This is absolutely true. However - and this makes no sense to me - Chromebooks apparently do upstream everything, even for ARM models. Any idea what went right there? >> you had duplication of services between the all-but-dead AOSP and Play services. > My understanding from the outside is that Google likes to pretend that AOSP is sufficient for antitrust reasons but really wants to control everything directly; you can't solve that by creating a new product unless the hope is that nobody cares that the "new" ecosystem doesn't get examined by the same standards. This might be why Chromebooks upstream and Android doesn't. ChromeOS doesn't have the same market context as Android, so Google doesn't have to play the game of avoiding anti-trust. They can be deeply involved in defining the acceptable hardware and requiring things get pushed upstream or not used. Android hardware on the other hand is more chaotic, and Google doesn't want to get hit with the anti-trust stick, so they're not willing to do very much to disturb the ecosystem. So they're stuck with this patently absurd system where SoC makers deliver an android build with a custom kernel to device manufacturers, and the kernel never gets updated, but Android keeps requiring new kernel features for their userland updates, so nobody can get those anyway; and there's a new project to make updates feasible for longer every two to three years, but it never actually drives the marketplace forward, because it only addresses new phones, but will be abandoned in three years anyway. At least, that's what I can gather as an outsider.
chasil 4y ago
My question remains, would this money have been better spent in buying QNX? Could an open-source QNX accomplish all of Google's goals? Given that QNX cannot be killed, and the cost to Google in attempting to do so (or enacting major change for legacy customers) would be catastrophic... Why not buy a working microkernel? Are there other commercial microkernels that are more attractive? https://en.m.wikipedia.org/wiki/QNX https://en.m.wikipedia.org/wiki/QNX Maybe Samsung should buy it, and put themselves in the driver's seat on Android. (They did buy Joyent, and SmartOS seems fine.)
- busterarm 4y ago
  BlackBerry isn't selling it. It's the only active line of business that they really have anymore. QNX is in 215 million cars.
  - jpgvm 4y ago
    Just buy BB then?
    - chasil 4y ago
      Agreed.
    - xg15 4y ago
      "I just bought the airline. It seemed neater."
    - busterarm 4y ago
      It's too expensive for what they'd get out of the deal. Buying BB would cost them between 3B-4B$. They've made less than 10 $B acquisitions, with Motorola Mobility being the most expensive at 12B and was for patents. I think if Google acquired BB for the QNX business that they wouldn't give it adequate attention and would run it into the ground.
  - DoingIsLearning 4y ago
    Do you know what is there business model? As in do they charge per unit sold? Or have a flat license? Do you know what would be aprox costs per unit for a startup say for QNX Neutrino?
sorenjan 4y ago
Your statements about Samsung reminds me of Wear OS 3, that Google is said to have developed together with Samsung. Does anyone know how much of that is Wear OS, i.e. Android, and how much is Tizen from Samsung? Wear OS 3 seems to differ quite a bit from previous versions, it's been Samsung exclusive for a year, and it doesn't work together with the Wear OS companion app on Android.
- izacus 4y ago
  There is no "Tizen" inside WearOS 3. Samsung contributed their own UI skin on top of WearOS like they build their own UI skin on top of Android for phones.
- kernal 4y ago
  Samsung switched to WearOS because they realized their Tizen OS was a failure on smartwatches just as it was on smartphones. Growth was stagnating, their app ecosystem was dead and the development environment was a nightmares. So Samsung did what Samsung does best and saved face by convincing Google to say WearOS 3 was a collaboration between Google and Samsung. Samsung probably did contribute code, but there is no Tizen in WearOS nor were these OSs "merged" like some people claimed. Samsung abandoned Tizen because they saw the writing on the wall. They were spending millions developing an OS that wasn't growing for an app ecosystem that was dead.
- roneythomas6 4y ago
  With the Wear OS 3 the licensing terms have more flexible, I believe it is to get Samsung on board. OEM's bring their own companion app. OEM's also can skin the UI as long it follows Android Wear UX. OEMs also can release their own companion app on iOS. Samsung isn't supporting iOS at the moment, but Fossil and Montblanc are.
- MishaalRahman 4y ago
  >Does anyone know how much of that is Wear OS, i.e. Android, and how much is Tizen from Samsung? Nobody really knows, as Wear OS remains closed source.
dcow 4y ago
I thought the core Fuchsia leadership were Plan9 people, not Android refugees. Maybe things shuffled around?
- dm319 4y ago
  Is that right? I didn't understand the technical reasoning behind Fucshia, but I understand there was always some disappointment that Linux took off the way it did when it was more of copy of unix rather than an evolution. Having said that, the issue was more with gnu than the kernel AFAIK.
pjmlp 4y ago
Outside US, there still exists more than just Samsung. For example, even Nokia branded phones get more updates.
- ysnp 4y ago
  Specifically, what is meant by more updates? According to https://security.samsungmobile.com/workScope.smsb https://security.samsungmobile.com/workScope.smsb some of their entry J-line from 2018 has two OS upgrades and should be getting (poor) bi-annual security updates. On https://www.nokia.com/phones/en_int/security-updates https://www.nokia.com/phones/en_int/security-updates Nokia's C1 from 2019 received its last security update in May and no OS upgrades.
- veeti 4y ago
  That was the promise by Nokia (HMD). Unfortunately, the reality is something else: https://www.geeky-gadgets.com/nokia-9-pureview-will-not-get-android-12-01-12-2021/ https://www.geeky-gadgets.com/nokia-9-pureview-will-not-get-... Samsung is pretty good with security and even OS updates nowadays.
  - pjmlp 4y ago
    As Nokia owner I hardly have reason to complain versus the aging Samsung devices I still have lying around.
initplus 4y ago
Getting drivers upstreamed is a political/legal issue, not a technological one. If google wants android drivers to get upstreamed, they can do so by throwing their weight around. Google can add a clause to the bottom of the license of the next android release that the licensee agrees to consider kernel modules a derivative work, and voila Google would have a legal crowbar to get drivers source released to the public.
- mschuster91 4y ago
  In almost all cases the party who writes the drivers it's the SoC vendor which is either Samsung themselves for their own chipsets or for everyone else Qualcomm, Mediatek or one of the less popular upstarts (Allwinner, Rockchip). For everything used by Google and Samsung, both do open source the kernel modules. Almost everything by Mediatek leaks sooner or later somewhere. The problem IMHO isn't driver source code availability itself, rather their often shoddy quality and the fact that SoC vendors drop support for updates very fast.
  - dm319 4y ago
    It seems drastic to me to conceive of an entire new kernel and OS just to resolve this issue and keep a stable ABI.
    - mschuster91 4y ago
      The core problem is Linux' lack of a stable internal API for drivers by design, which was thought of as an incentive for SoC and other HW vendors to upstream their drivers so that they need not care about keeping them updated. What happened instead was that, at least in the embedded world where the customers are not the mass market directly that votes with their wallets but "suits" without much technical knowledge, SoC vendors came up with bundling a private fossilized fork of the Linux kernel, u-boot and a bunch of tooling and calling it a "BSP" (board support package).
      - dm319 4y ago
phh 4y ago
> 1. There is no way to remove devices drivers from the Linux kernel. That goal was seen as desirable in terms of improving reliability, how long devices were supported for and the time taken to roll out updates. Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers; and Android's Project Treble was already supposed to (partly) fix that, and it didn't. Partly because of OEMs sure. But, and most importantly, because Google removed the support for versioned RPC merely 3 years after its introduction (audio HAL 2.0 introduced in Android 8, got removed in Android 12, simply reverting the deletion commit is enough to "fix" it). What does this tell? This tells that Google themselves aren't structurally ready to support hardware for more than 3 years. Why would Fuchsia be any different? In all likelihood, they'll also deprecate versioned ABI every 6 months, and drop old support after 3 years, which will lead to the exact same state. At this stage, this is a managerial issue, not a technical one anymore. If Google wants to do this (upgrade devices independently from OEMs), they first need to stop obsoleting code every time someone gets a promotion, and they need to actually try what they make, not just do things that are theoretically perfect [1]. (to the best of my knowledge, there is exactly one Google team who managed that, which is androidx/jetpack/android-compat) > Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers; Chromebooks have most/all drivers upstreamed, and yet they never upgrade their kernels in production. [1] And I could go on how Project Treble is architecturally beautiful, but is missing few small points that would make it actually usable, which is what my opensource project does, but I feel my message is already too diluted
- ladyanita22 4y ago
  Do you think, if executed correctly, project Treble could have solved the issue with Android's poor support even when running on Linux?
aaaaaaaaata 4y ago
Is AOSP dead, or do your favorite manufacturers just not have a clue how FOSS is supposed to work, and/or have a toxic relationship with the Google Play Services?

by cletus 4y ago

ncann 4y ago

> It screams of being the pet project of some very high level engineers. This seems true of so many Google projects lately, big promises that don't deliver and get shelved in a few years.

lumost 4y ago
This is a Truism of big anything. Once people are high enough in an organization and we’ll connected enough… their projects are unassailable. I can guarantee you that somewhere in google is a team of 3 getting shut down for making 100MM a year with a boring tech focus. Meanwhile Fuscia continues unquestioned.
cbozeman 4y ago
This isn't a "lately" phenomenon. This has been the Standard Google Playbook for about the past 15 years.
baobob 4y ago
This comment and the parent got me thinking of the contrast between "privilege" and "merit" as useful ways to describe some of the difference between small company land and the likes of Google. How many product disasters could be attributed to the wrong people accidentally possessing or ageing into privilege? I wonder if Plus or Reader could be phrased in these terms
- djbusby 4y ago
  I don't think one just ages into privilege. One early win to make some marks would certainly help and give privilege for next projects.
  - lumost 4y ago
    This is true, but there is a survivorship bias. Someone who sticks around gains credit from the work of those who left. Exponential growth in a core business means promotions for everyone. Someone who is considered "good" gets looped into key projects. After 4-5 years these become a self-fulfilling prophecy in some organizations, as "good" people get attached to the growth drivers.
summerlight 4y ago
Being a pet project of very senior engineer is not necessarily a bad thing. You know what? MapReduce, BigTable, Spanner, TensorFlow and tens of other important infrastructures were once Jeff Dean's toy projects. I don't think Google even can exist without them... Important thing is execution of the project, not its inception.
- kortilla 4y ago
  Something changed though. Those projects are ancient
  - metadat 4y ago
    Jeff Dean is also a legend and not just a "senior engineer", more like google's version of John Carmack.
    - jpgvm 4y ago
      Phil Cutler is probably a better equivalent but yeah, definitely legend status either way.
      - daydream 4y ago
        You mean Dave Cutler?
        jpgvm 4y ago
        Yes, brain fart. No idea how I subbed Dave for Phil but I guess that is what I get for typing while tired.
  - summerlight 4y ago
    You want some recency? Search for Pathways, which is a backbone for PaLM.
- mike_hearn 4y ago
  Those projects all had a unique and very successful take on the problem they were solving, though. The problem with creating a new OS is getting people to write apps. It's not really justifiable if your new OS doesn't take a very different approach to how apps are written and yield much better results as a consequence. If you build a new OS and rely too heavily on emulated Linux apps, then what is your value proposition? You're effectively admitting defeat up front by saying there's no real reason to write a native app; that running Linux apps is good enough. With Fuschia this problem is especially apparent because it's not really obvious from reading the docs what its value prop really is, or how the UX of a native app differs from any other platform. Successful operating systems don't normally have this problem. You could argue that Linux was an exception, but there the value prop was being an open source PC UNIX and that price/compatibility point was enough. Other platforms though, like macOS or Android, needed to have a very clear offering up front to get developers to care, as well as a large library of first party apps.

kernal 4y ago

>given that Samsung in an unhappy spouse in a loveless marriage of necessity What makes you think Samsung is a "unhappy spouse"? They save billons by having Google develop Android and spoon feeding them security updates each month all for free. Samsung can leave this relationship any time the want and they've probably though about it. Then they saw what happened to Huawei and Samsung fell in love with Google all over again. Samsung doesn't want to be Huawei-d, but they will be if they ever leave Android and the Android ecosystem. >how are you going to convince Samsung to switch to Fuchsia? I still see no answer to that. Why wouldn't Samsung switch to Fuchsia? If Fuchsia really is the next generation of Android then it seems logical to hop on that train or be left behind and trying to maintain a sunset OS with limited, if any, support from Google.

dataflow 4y ago

> healthy ecosystem of phone manufacturers. For awhile there were but now? Now it's really just Samsung. Confused, aren't there a ton of phone manufacturers? Sony, OnePlus, Asus to name a few off the top of my head. In what sense are they all "unhealthy" except Samsung?

syntheticnature 4y ago
I don't have exact data to hand, but my recollection is that Samsung is the only Android phone manufacturer turning a profit on phones.
- dataflow 4y ago
  I haven't looked up any others, but I just looked up OnePlus and saw this [1]: > For the first time in company history, OnePlus passed the $1 billion mark in revenue and became profitable. (2018) [1] https://www.androidauthority.com/oneplus-profitable-830348/ https://www.androidauthority.com/oneplus-profitable-830348/
- smegger001 4y ago
  if that case the case why are they all still making android phones if it isn't profitable? My perhaps naive presumption is that they are in fact profitable but not a high margin market. If it was not a profitable venture they wouldn't make them
ejj28 4y ago
It's the market that's unhealthy. Samsung and Apple are really the only big players at this point - Sony has sub 1% market share, Asus likely even less. OnePlus is owned by OPPO and together they have about 9% market share. Samsung is the only brand that is actually able to compete with Apple.
- dataflow 4y ago
  Still confused. So what would be healthy in your mind? The sheer number of manufacturers competing in the Android ecosystem seems like the definition of a healthy market for Android phones—in contrast with iOS where there's 1 player. Obviously you can't have 10 manufacturers each with 50% market share, so what sign of health are you looking for that deviates so strongly from the status quo?

yjftsjthsd-h 4y ago

I have never worked at Google, but some of this seems... odd from my perspective. > Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. This is absolutely true. However - and this makes no sense to me - Chromebooks apparently do upstream everything, even for ARM models. Any idea what went right there? > you had duplication of services between the all-but-dead AOSP and Play services. My understanding from the outside is that Google likes to pretend that AOSP is sufficient for antitrust reasons but really wants to control everything directly; you can't solve that by creating a new product unless the hope is that nobody cares that the "new" ecosystem doesn't get examined by the same standards. > Remember these are statements of fact. I'm assuming you meant to type "not" there? > Google had always had hopes that there would be a healthy ecosystem of phone manufacturers. For awhile there were but now? Now it's really just Samsung. Samsung is certainly the biggest, but it's hardly the only name in town; https://www.appbrain.com/stats/top-manufacturers https://www.appbrain.com/stats/top-manufacturers puts them at ~34% with the rest in the long tail.

djbusby 4y ago
One guess is that getting drivers upstream for Chromebook improves the possibility of external vendors making hardware. And Chromebook I seems to be supported for a long time.
- raggi 4y ago
  The patches & drivers involved in most Chromebook peripherals are much closer to that of a PC in architecture than for the SoC's that go into phones. In this regard the patches are far less invasive, and thus more easy to match with upstream requirements.
toast0 4y ago
>> Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. > This is absolutely true. However - and this makes no sense to me - Chromebooks apparently do upstream everything, even for ARM models. Any idea what went right there? >> you had duplication of services between the all-but-dead AOSP and Play services. > My understanding from the outside is that Google likes to pretend that AOSP is sufficient for antitrust reasons but really wants to control everything directly; you can't solve that by creating a new product unless the hope is that nobody cares that the "new" ecosystem doesn't get examined by the same standards. This might be why Chromebooks upstream and Android doesn't. ChromeOS doesn't have the same market context as Android, so Google doesn't have to play the game of avoiding anti-trust. They can be deeply involved in defining the acceptable hardware and requiring things get pushed upstream or not used. Android hardware on the other hand is more chaotic, and Google doesn't want to get hit with the anti-trust stick, so they're not willing to do very much to disturb the ecosystem. So they're stuck with this patently absurd system where SoC makers deliver an android build with a custom kernel to device manufacturers, and the kernel never gets updated, but Android keeps requiring new kernel features for their userland updates, so nobody can get those anyway; and there's a new project to make updates feasible for longer every two to three years, but it never actually drives the marketplace forward, because it only addresses new phones, but will be abandoned in three years anyway. At least, that's what I can gather as an outsider.

chasil 4y ago

My question remains, would this money have been better spent in buying QNX? Could an open-source QNX accomplish all of Google's goals? Given that QNX cannot be killed, and the cost to Google in attempting to do so (or enacting major change for legacy customers) would be catastrophic... Why not buy a working microkernel? Are there other commercial microkernels that are more attractive? https://en.m.wikipedia.org/wiki/QNX https://en.m.wikipedia.org/wiki/QNX Maybe Samsung should buy it, and put themselves in the driver's seat on Android. (They did buy Joyent, and SmartOS seems fine.)

busterarm 4y ago
BlackBerry isn't selling it. It's the only active line of business that they really have anymore. QNX is in 215 million cars.
- jpgvm 4y ago
  Just buy BB then?
  - chasil 4y ago
    Agreed.
  - xg15 4y ago
    "I just bought the airline. It seemed neater."
  - busterarm 4y ago
    It's too expensive for what they'd get out of the deal. Buying BB would cost them between 3B-4B$. They've made less than 10 $B acquisitions, with Motorola Mobility being the most expensive at 12B and was for patents. I think if Google acquired BB for the QNX business that they wouldn't give it adequate attention and would run it into the ground.
- DoingIsLearning 4y ago
  Do you know what is there business model? As in do they charge per unit sold? Or have a flat license? Do you know what would be aprox costs per unit for a startup say for QNX Neutrino?

sorenjan 4y ago

Your statements about Samsung reminds me of Wear OS 3, that Google is said to have developed together with Samsung. Does anyone know how much of that is Wear OS, i.e. Android, and how much is Tizen from Samsung? Wear OS 3 seems to differ quite a bit from previous versions, it's been Samsung exclusive for a year, and it doesn't work together with the Wear OS companion app on Android.

izacus 4y ago
There is no "Tizen" inside WearOS 3. Samsung contributed their own UI skin on top of WearOS like they build their own UI skin on top of Android for phones.
kernal 4y ago
Samsung switched to WearOS because they realized their Tizen OS was a failure on smartwatches just as it was on smartphones. Growth was stagnating, their app ecosystem was dead and the development environment was a nightmares. So Samsung did what Samsung does best and saved face by convincing Google to say WearOS 3 was a collaboration between Google and Samsung. Samsung probably did contribute code, but there is no Tizen in WearOS nor were these OSs "merged" like some people claimed. Samsung abandoned Tizen because they saw the writing on the wall. They were spending millions developing an OS that wasn't growing for an app ecosystem that was dead.
roneythomas6 4y ago
With the Wear OS 3 the licensing terms have more flexible, I believe it is to get Samsung on board. OEM's bring their own companion app. OEM's also can skin the UI as long it follows Android Wear UX. OEMs also can release their own companion app on iOS. Samsung isn't supporting iOS at the moment, but Fossil and Montblanc are.
MishaalRahman 4y ago
>Does anyone know how much of that is Wear OS, i.e. Android, and how much is Tizen from Samsung? Nobody really knows, as Wear OS remains closed source.

dcow 4y ago

I thought the core Fuchsia leadership were Plan9 people, not Android refugees. Maybe things shuffled around?

dm319 4y ago
Is that right? I didn't understand the technical reasoning behind Fucshia, but I understand there was always some disappointment that Linux took off the way it did when it was more of copy of unix rather than an evolution. Having said that, the issue was more with gnu than the kernel AFAIK.

pjmlp 4y ago

Outside US, there still exists more than just Samsung. For example, even Nokia branded phones get more updates.

ysnp 4y ago
Specifically, what is meant by more updates? According to https://security.samsungmobile.com/workScope.smsb https://security.samsungmobile.com/workScope.smsb some of their entry J-line from 2018 has two OS upgrades and should be getting (poor) bi-annual security updates. On https://www.nokia.com/phones/en_int/security-updates https://www.nokia.com/phones/en_int/security-updates Nokia's C1 from 2019 received its last security update in May and no OS upgrades.
veeti 4y ago
That was the promise by Nokia (HMD). Unfortunately, the reality is something else: https://www.geeky-gadgets.com/nokia-9-pureview-will-not-get-android-12-01-12-2021/ https://www.geeky-gadgets.com/nokia-9-pureview-will-not-get-... Samsung is pretty good with security and even OS updates nowadays.
- pjmlp 4y ago
  As Nokia owner I hardly have reason to complain versus the aging Samsung devices I still have lying around.

initplus 4y ago

Getting drivers upstreamed is a political/legal issue, not a technological one. If google wants android drivers to get upstreamed, they can do so by throwing their weight around. Google can add a clause to the bottom of the license of the next android release that the licensee agrees to consider kernel modules a derivative work, and voila Google would have a legal crowbar to get drivers source released to the public.

mschuster91 4y ago
In almost all cases the party who writes the drivers it's the SoC vendor which is either Samsung themselves for their own chipsets or for everyone else Qualcomm, Mediatek or one of the less popular upstarts (Allwinner, Rockchip). For everything used by Google and Samsung, both do open source the kernel modules. Almost everything by Mediatek leaks sooner or later somewhere. The problem IMHO isn't driver source code availability itself, rather their often shoddy quality and the fact that SoC vendors drop support for updates very fast.
- dm319 4y ago
  It seems drastic to me to conceive of an entire new kernel and OS just to resolve this issue and keep a stable ABI.
  - mschuster91 4y ago
    The core problem is Linux' lack of a stable internal API for drivers by design, which was thought of as an incentive for SoC and other HW vendors to upstream their drivers so that they need not care about keeping them updated. What happened instead was that, at least in the embedded world where the customers are not the mass market directly that votes with their wallets but "suits" without much technical knowledge, SoC vendors came up with bundling a private fossilized fork of the Linux kernel, u-boot and a bunch of tooling and calling it a "BSP" (board support package).
    - dm319 4y ago

phh 4y ago

> 1. There is no way to remove devices drivers from the Linux kernel. That goal was seen as desirable in terms of improving reliability, how long devices were supported for and the time taken to roll out updates. Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers; and Android's Project Treble was already supposed to (partly) fix that, and it didn't. Partly because of OEMs sure. But, and most importantly, because Google removed the support for versioned RPC merely 3 years after its introduction (audio HAL 2.0 introduced in Android 8, got removed in Android 12, simply reverting the deletion commit is enough to "fix" it). What does this tell? This tells that Google themselves aren't structurally ready to support hardware for more than 3 years. Why would Fuchsia be any different? In all likelihood, they'll also deprecate versioned ABI every 6 months, and drop old support after 3 years, which will lead to the exact same state. At this stage, this is a managerial issue, not a technical one anymore. If Google wants to do this (upgrade devices independently from OEMs), they first need to stop obsoleting code every time someone gets a promotion, and they need to actually try what they make, not just do things that are theoretically perfect [1]. (to the best of my knowledge, there is exactly one Google team who managed that, which is androidx/jetpack/android-compat) > Upstreaming driver changes was something phone manufacturers just didn't do and didn't want to do. Linux has no stable ABI for device drivers; Chromebooks have most/all drivers upstreamed, and yet they never upgrade their kernels in production. [1] And I could go on how Project Treble is architecturally beautiful, but is missing few small points that would make it actually usable, which is what my opensource project does, but I feel my message is already too diluted

ladyanita22 4y ago
Do you think, if executed correctly, project Treble could have solved the issue with Android's poor support even when running on Linux?

aaaaaaaaata 4y ago

Is AOSP dead, or do your favorite manufacturers just not have a clue how FOSS is supposed to work, and/or have a toxic relationship with the Google Play Services?