Live data from Hacker News

Google shifting to “upstream first” Linux kernel approach for Android features

phoronix.com

41–50 of 116 posts

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#41
post #38

Earlier quoted context omitted.

>vote with your wallet and don't complain how "most devices" don't give you feature you're not ready to pay for This isn't always possible or realistic. The cheapest Pixel phone is worth 2+ median monthly salaries in my location.

Premium features, premium price point.

Are you content that full ownership of the device is a "premium feature"?

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#42
post #38

Earlier quoted context omitted.

Premium features, premium price point.

Are you content that full ownership of the device is a "premium feature"?

Think of it the opposite way.

All other devices are subsidized to be just an advertising platform for their producer. Real prices of devices are those that you consider "premium".

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#43
post #37
post #27

Earlier quoted context omitted.

> Googles own devices not only allow you to unlock the bootloader, but to relock it with your own signing keys. And does it let you pass SafetyNet and run most of the apps. AFAIK it's not so re-lockable bootloader is useless.

I use a pixel phone with my own signing keys and I find it very useful. I can live without SafetyNet, whatever that is.

It basically allows you running most banking apps (and anything that is related to money).

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#44
post #38

Earlier quoted context omitted.

>vote with your wallet and don't complain how "most devices" don't give you feature you're not ready to pay for This isn't always possible or realistic. The cheapest Pixel phone is worth 2+ median monthly salaries in my location.

Premium features, premium price point.

So privacy is a premium feature now, that should only be available to developed societies? Okay.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#45
post #16

Earlier quoted context omitted.

> Most Android devices these days have bootloaders that cannot be unlocked [citation needed] I'm finding the majority of devices to be unlockable as long as you don't buy your device from a carrier. Carrier locked devices are not typically the norm but in the US. And if you truly cared about software freedom, you wouldn't be buying carrier locked devices in the first place. I really wish people would stop griping abo…

> And if you truly cared about software freedom, you wouldn't be buying carrier locked devices in the first place. This irks me. Not everyone has such choice about what to buy.

> Not everyone has such choice about what to buy.

There is always a choice. There are multiple devices at given price point.

Taking credit to buy a mobile is not a wise choice ever.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#47
post #22

Earlier quoted context omitted.

> Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset. Googles own devices not only allow you to unlock the bootloader, but to relock it with yo…

>vote with your wallet and don't complain how "most devices" don't give you feature you're not ready to pay for This isn't always possible or realistic. The cheapest Pixel phone is worth 2+ median monthly salaries in my location.

Most of Motorola's devices are unlockable, too. I run LinegeOS without Google tools on an $80 discount model from a few years ago.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#48
post #23

Earlier quoted context omitted.

> And if you truly cared about software freedom, you wouldn't be buying carrier locked devices in the first place. This irks me. Not everyone has such choice about what to buy.

> This irks me. Not everyone has such choice about what to buy. Not an excuse anymore. Motorola has universal devices that work on all carriers. Including the most difficult ones in the US, Verizon and AT&T. The unlocked Motorola devices are also often cheaper than getting a device through a carrier.

It has not been an excuse since 10+ years ago in the US.

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#49
post #6

I am afraid it does not matter any more, at least not for practical software freedom. Most Android devices these days have bootloaders that cannot be unlocked, preventing device owners from installing custom kernel images onto their devices. And even if you have a phone where that isn't true, Google's SafetyNet will prevent you from using many crucial applications, like your bank's Android app, on that handset. It's…

While this won't solve all problems with practical software freedom, it's still an important step into right direction, which will definitely help the free software ecosystem.

You can still buy phones with bootloader which can be unlocked, such as sony[1], but I agree that most doesn't have this option.

The fact that google's proprietary services are necessary for most proprietary applications to work doesn't mean that there isn't a value in a phone running kernel which is closer to an upstream. When you run a custom operating system based on linux kernel, you are less likely to run the proprietary google services anyway.

[1] https://developer.sony.com/develop/open-devices/get-started/...

Re: Google shifting to “upstream first” Linux kernel approach for Android features

#50
This seems like the natural lifecycle.

1. There are many features that we feel very valuable to our OS, so we will implement them and ship our OS without blocking on upstream approval and acceptance. 2. Maintaining these patches is expensive. We will try to upstream as much as possible. 3. Most of our patches have been upstreamed and most new kernel requirements are lower priority, we should prefer to upstream first to reduce the cost to migrate our OS from the original implementations to the upstreamed implementations.

At no point does it seem that the decision was "wrong". Obviously carrying a bunch of patches has downsides but at the earlier points in the OS lifecycle getting the features was probably much more valuable than the downsides were harmful.

Post reply on HN