4 ms·

I think it’s a bit early to declare Linux’s market victory here. The obvious thing for Google to do is to use this in Android, and this will solve a number of

I think it’s a bit early to declare Linux’s market victory here. The obvious thing for Google to do is to use this in Android, and this will solve a number of big problems for them (specifically, binary-only drivers and a better security model). They might even have some success in the server or desktop spaces as well. I worry a bit that Linux will be the next Firefox.

cycloptic 6y ago
>binary-only drivers If by this you're referring to their promises of a stable driver ABI, I can't understand what problem this is supposed to solve compared to Linux. There are plenty of binary drivers already shipped on Linux. IOT device vendors don't care about a stable ABI because they just pin to their kernel version. Android device vendors don't care because either way they will stop updating their kernels after a number of years. Enterprise users don't care because they also pin to a kernel version and backport what fixes they want. It also does not seem to solve any problem for Google because they still have to make the same stability/support promises and deal with the same accumulation of legacy code either way. Yes, this is necessary to stop fragmentation but the problem is nothing really changes here compared to what they would do if they were going to take on the cost of backporting Linux kernel fixes. The only realistic cost saving for them I could see is if the greater stability came from reducing the total amount of hardware that is supported compared to Linux. Which makes sense for them but at the same time completely eliminates the possibility of them ever seriously touting this as a Linux replacement.
- quicklime 6y ago
  > Android device vendors don't care because either way they will stop updating their kernels after a number of years This one seems like a big problem to me. Maybe the handset manufacturer doesn’t care because they already made their profit, but this pushes the support burden onto app developers (including Google itself) who have to maintain support for these old Android devices that the manufacturers don’t care about. This seems like a real issue to me, is there something I’m missing?
  - cycloptic 6y ago
    I agree that is a real issue. By my point is that the proposed solution is now that Google itself is now going to have to maintain support for old Fuschia devices because the burden is now on them to maintain this stable ABI. How is this going to solve anything compared to just making a support promise about a particular Linux version? Nothing here seems like it would improve for the app developers.
    - tbodt 6y ago
      *Fuchsia
      - quicklime 6y ago
        It's ok, nobody can spell fuchsia: https://blog.xkcd.com/2010/05/03/color-survey-results/ https://blog.xkcd.com/2010/05/03/color-survey-results/ Back on topic though, I think it's just easier from an engineering perspective to maintain a stable ABI than it is to maintain a set of blessed kernel versions. An ABI is something that can be reasonably well-defined and has a clear scope, whereas if you just say that you support kernel versions X, Y and Z, then who knows what weird undocumented behavior you'll need to maintain.
  - m4rtink 6y ago
    There is an effort to upstream all the Android kernel patches to make Android device kernel updates simple: https://lwn.net/Articles/771974/ https://lwn.net/Articles/771974/ Also some vendors such as Sony have standardized kerbel versions across many devices & publish kernel major version updates for a range of devices (in Sonys case called the open device program).
- deleted 6y ago
  [deleted]

cycloptic 6y ago

>binary-only drivers If by this you're referring to their promises of a stable driver ABI, I can't understand what problem this is supposed to solve compared to Linux. There are plenty of binary drivers already shipped on Linux. IOT device vendors don't care about a stable ABI because they just pin to their kernel version. Android device vendors don't care because either way they will stop updating their kernels after a number of years. Enterprise users don't care because they also pin to a kernel version and backport what fixes they want. It also does not seem to solve any problem for Google because they still have to make the same stability/support promises and deal with the same accumulation of legacy code either way. Yes, this is necessary to stop fragmentation but the problem is nothing really changes here compared to what they would do if they were going to take on the cost of backporting Linux kernel fixes. The only realistic cost saving for them I could see is if the greater stability came from reducing the total amount of hardware that is supported compared to Linux. Which makes sense for them but at the same time completely eliminates the possibility of them ever seriously touting this as a Linux replacement.

quicklime 6y ago
> Android device vendors don't care because either way they will stop updating their kernels after a number of years This one seems like a big problem to me. Maybe the handset manufacturer doesn’t care because they already made their profit, but this pushes the support burden onto app developers (including Google itself) who have to maintain support for these old Android devices that the manufacturers don’t care about. This seems like a real issue to me, is there something I’m missing?
- cycloptic 6y ago
  I agree that is a real issue. By my point is that the proposed solution is now that Google itself is now going to have to maintain support for old Fuschia devices because the burden is now on them to maintain this stable ABI. How is this going to solve anything compared to just making a support promise about a particular Linux version? Nothing here seems like it would improve for the app developers.
  - tbodt 6y ago
    *Fuchsia
    - quicklime 6y ago
      It's ok, nobody can spell fuchsia: https://blog.xkcd.com/2010/05/03/color-survey-results/ https://blog.xkcd.com/2010/05/03/color-survey-results/ Back on topic though, I think it's just easier from an engineering perspective to maintain a stable ABI than it is to maintain a set of blessed kernel versions. An ABI is something that can be reasonably well-defined and has a clear scope, whereas if you just say that you support kernel versions X, Y and Z, then who knows what weird undocumented behavior you'll need to maintain.
- m4rtink 6y ago
  There is an effort to upstream all the Android kernel patches to make Android device kernel updates simple: https://lwn.net/Articles/771974/ https://lwn.net/Articles/771974/ Also some vendors such as Sony have standardized kerbel versions across many devices & publish kernel major version updates for a range of devices (in Sonys case called the open device program).
deleted 6y ago
[deleted]