Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

phoronix.com

Post reply on HN
Print view View original

91–100 of 116 posts

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

#91

Post by techrat »

seniorivn wrote: post #56
techrat wrote: post #34

Earlier quoted context omitted.

Code gets shared between projects all the time. Nothing in there specifically says that Fuchsia will replace Android. In case you had problems comprehending it the first time, ChromeOS and Android were not * merged.* The rumor has been around since 2015. https://www.theverge.com/2015/10/29/9639950/google-combining... Running ones' apps on another OS is not merging the two. The ChromeOS/Android merger claims are still…

that's how rumors work, what rumormongers considered merging of the two OSes, were in fact attempts to make chrome os able to run Android apps, and that's exactly what happend.

In other words, rumors are started because people imagined cross-code commits to be something more than it really was.

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

#92

Post by SXX »

NikolaeVarius wrote: post #57
SXX wrote: 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 have a unlocked booloader and I bypass SafeyNet just fine.

For now. Once SafetyNet start to require hardware attestation you won't be able to bypass it with Magisk.

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

#93

Post by BrightGlow »

jjulius wrote: post #90
BrightGlow wrote: post #85

Earlier quoted context omitted.

Which vendors are those? I could try to name some, but they might not necessarily be the ones you would come up with.

Allow me to rephrase. You say that such complaints are just noise to Google because they have already acted on these complaints (ie, Pixel bootloaders are unlocked). On that, I think you and I agree re: pointless complaining. I'm asking, why not continue to complain in an effort to push vendors with locked bootloaders to unlock them? Specific vendors are irrelevant, I'm just curious if you do/don't think people shoul…

I don't know what you mean specific vendors are irrelevant, if you're not complaining to anyone in particular, then it's just talking into the void.

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

#94

Post by pjmlp »

p_j_w wrote: post #88
pjmlp wrote: post #30

Earlier quoted context omitted.

Maybe some Gerrit commits will help, https://android-review.googlesource.com/q/fuchsia Also in case you missed, Android apps now run on ChromeOS.

>Maybe some Gerrit commits will help These commits don't show that they're replacing Linux with Fuchsia, they show that they haven't killed Fuchsia.

Indeed,

"RFC-0082: Runnning unmodified Linux programs on Fuchsia"

https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

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

#95

Post by pjmlp »

techrat wrote: post #34
pjmlp wrote: post #30

Earlier quoted context omitted.

Maybe some Gerrit commits will help, https://android-review.googlesource.com/q/fuchsia Also in case you missed, Android apps now run on ChromeOS.

Code gets shared between projects all the time. Nothing in there specifically says that Fuchsia will replace Android. In case you had problems comprehending it the first time, ChromeOS and Android were not * merged.* The rumor has been around since 2015. https://www.theverge.com/2015/10/29/9639950/google-combining... Running ones' apps on another OS is not merging the two. The ChromeOS/Android merger claims are still…

Believe what makes you happy.

"RFC-0082: Runnning unmodified Linux programs on Fuchsia"

https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

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

#96

Post by pjmlp »

fouric wrote: post #87
pjmlp wrote: post #33

Earlier quoted context omitted.

On this kind of devices the security chain of trust needs to take into consideration the same kind of users that fill their Internet Explorer with random toolbars from website popups. Not the user with a CS degree that knows what they are doing.

"Of all tyrannies, a tyranny sincerely exercised for the good of its victims may be the most oppressive." - C.S. Lewis Freedom to do what you want with the device you purchased is a right that is not to be infringed upon, especially not for the reason "the users might hurt themselves". Setting up a technically nontrivial flow to unlock the bootloader (e.g. connect the device to a machine with an SSH client, approve S…

As it is a right for a manufactures to sell their devices configured as whatever they feel like.

The consumer has the right to buy from companies that sell products that actually fit their purposes, like I don't know, a computer, instead of trying to replace the firmware in a toaster.

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

#97

Post by DCKing »

c0l0 wrote: 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…

> I am afraid it does not matter any more, at least not for practical software freedom.

The reason Google appears to be doing this is not software freedom, but enabling longer software updates. Google themselves cannot provide anything remotely competitive to iOS updates if Qualcomm or other SoC vendors effectively keep their proprietary Android builds hostage. Getting stuff mainlined and unshackling Android kernels from vendor shenanigans is a very, very important step. The Google Pixel 6 is the first time in a long while an Android phone excites me, just by virtue of Google's credible 5 years of update promise.

To your point: practical software freedom has been very, very hard on Android from the start. Smartphones are complex devices, and the custom kernels they run have barely been successfully reproduced anywhere else. You can find a small handful of old devices that you can get up and running in a somewhat acceptable state, but you have to restrict yourself to hard to use old stuff to get anything workable at all.

While more software freedom is not really a goal of this project, this does potentially have side effects of more software freedom down the line. Similarly, Google's Project Treble has not delivered everything people wanted, but does allow people to run say (a buggy version of) Ubuntu Touch on a fair number of Android phones [0]. In the Android ecosystem, you have to count your blessings. (And hey, it's not iOS or Windows Phone either!)

[0]: https://forum.xda-developers.com/t/gsi-arm64-a-ab-ubuntu-tou...

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

#98

Post by wizzwizz4 »

the8472 wrote: post #69
wizzwizz4 wrote: post #68

Earlier quoted context omitted.

Okay, so the app's running. Except the app is remote-controlled by a malicious “display driver” that waits for the user to do all this authentication set-up, transfers the money away, “are you sure”s it, then prevents the user from seeing any of the on-phone scam warnings until it's too late to reverse the transaction.

Display driver is part of the kernel, which is part of the trust chain.

Substitute “display driver” for a draw over other apps, “tap this dot” game, then.

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

#99

Post by techrat »

pjmlp wrote: post #95
techrat wrote: post #34

Earlier quoted context omitted.

Code gets shared between projects all the time. Nothing in there specifically says that Fuchsia will replace Android. In case you had problems comprehending it the first time, ChromeOS and Android were not * merged.* The rumor has been around since 2015. https://www.theverge.com/2015/10/29/9639950/google-combining... Running ones' apps on another OS is not merging the two. The ChromeOS/Android merger claims are still…

Believe what makes you happy. "RFC-0082: Runnning unmodified Linux programs on Fuchsia" https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

Again, nothing there specifically puts weight into the argument that "Fuchsia is replacing Android."

And also, Fuchsia's license is more permissive than Android's.

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

#100

Post by jjulius »

BrightGlow wrote: post #93
jjulius wrote: post #90

Earlier quoted context omitted.

Allow me to rephrase. You say that such complaints are just noise to Google because they have already acted on these complaints (ie, Pixel bootloaders are unlocked). On that, I think you and I agree re: pointless complaining. I'm asking, why not continue to complain in an effort to push vendors with locked bootloaders to unlock them? Specific vendors are irrelevant, I'm just curious if you do/don't think people shoul…

I don't know what you mean specific vendors are irrelevant, if you're not complaining to anyone in particular, then it's just talking into the void.

You've simultaneously demonstrated a misunderstanding of my comment, and - correct me if I'm wrong - answered my question.

My comment is not about specific vendors and their actions. My comment is only about wondering when, in your mind, is a valid time for people to complain; a philosophical question. That's why the question is broad - is it OK for people to complain about vendors who have yet to take action?

Your comment just now suggests that, yes, contrary to your post complaining about complainers, you likely think it's fine to complain to/about vendors who haven't taken action you'd like to see taken.

Post reply on HN