Live data from Hacker News

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

phoronix.com

101–110 of 116 posts

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

#101

Earlier quoted context omitted.

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 c…

I'm not concerned with what's valid or fine or not, this is just if you want a chance to get your problem solved or if you want to waste your own time on a complaint that is to the wrong people. These out-of-context complaints/rants happen so often online that twitter even has a meme for it: https://en.wiktionary.org/wiki/sir,_this_is_an_Arby's

Edit: Your logic in the last paragraph doesn't follow to me, as I was responding to a specific complaint. So that's another reason I can't really give an answer to the question.

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

#102
post #60

Earlier quoted context omitted.

Obligatory reminder of the state surveillance and censorship baked into Xiaomi products: https://news.ycombinator.com/item?id=28616683

If you can swap the device OS with something more trustworthy, does any of that matter or is there evidence that the hardware itself is untrustworthy?

It is not only about hardware. Lineageos re-uses binaries from the original image. The modem still runs original binaries. The bootloader is also original. Plenty of space to hide backdoors, possibly disguised as bugs.

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

#103
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 wish I could upvote you more. There's nothing about "freedom" in this post, it's all about developer's convenience. It's easier to keep local changes and push them later if the upstream is not changing much. If your upstream is a moving target, doing anything but upstream-first is only making it worse for yourself in the long run. Nothing to add regarding bootloader locking and safetynet on top. I don't want multip…

Instead of replacing your phone, have you thought about replacing your bank? Is there any competition that does not force this bullshit onto it's customers?

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

#104
post #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 th…

Sony? Who promise only 2 years of security updates on their 1300€ phones, which turns out to be only 1.5 years after their usual delay to HW availability, and for most of their better phones they never provide any open source support? Nope...

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

#105
post #7

I hope they can get SoC vendors onboard. Broken & old BSPs are really tiring, as is waiting for the small user community to slowly upstream all that work. It can take years for the support for a new SoC to mature in upstream Linux. The companies building products upon these SoCs are kinda between rock and hard place, and I think this shows for the user as well (you get old kernel with little to no security updates? i…

The SoC vendors are doing this on purpose, in order to increase sales. Planned obsolescence. They will not change that without significant pressure.

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

#106
post #99
post #95

Earlier quoted context omitted.

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.

That is exactly the problem. Fuchsia's license is more free only for developers in the short term, as lacks provisions to force developers to keep it free, in the end this will significantly reduce users' freedom. If Linux never had copyleft, it would never have had this success.

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

#107
post #69

Earlier quoted context omitted.

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.

That's a standard feature and not related to unlocking the bootloader. Handling that properly wrt. sensitive apps has to be done anyway.

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

#108

Earlier quoted context omitted.

Still, what's the point in telling someone "to vote with their wallet" instead of complaining? Why not both? Where, if not on HN, should we voice our opinion that tech is going down some path we aren't excited about? Avoiding Google/FB/Amazon/Microsoft or whatever your megacorp of choice is is becoming increasingly hard, and it absolutely deserves being talked about. As do any other things in which our choices and fr…

The general problem I have (personally) with these type of complaints is that there is no real way for any of these companies to act on it further. In the case of Google, they already have acted on it. It's just noise to them at this point. If you believe something else is being snuffed out, it would help to mention what it is so people can help you. Because making that statement without context doesn't really stand…

Google could definitely act on it further by leveraging their agreements with vendors who ship the proprietary Google components of most Android devices. That risks those vendors reimplementing the proprietary components from scratch though, which would fragment the Android ecosystem further.

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

#109
post #102

Earlier quoted context omitted.

If you can swap the device OS with something more trustworthy, does any of that matter or is there evidence that the hardware itself is untrustworthy?

It is not only about hardware. Lineageos re-uses binaries from the original image. The modem still runs original binaries. The bootloader is also original. Plenty of space to hide backdoors, possibly disguised as bugs.

Oh, I knew the modem issue but not that they were reusing binaries. Thanks.

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

#110
post #99
post #95

Earlier quoted context omitted.

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.

Lets put it this way, GCC is already kicked out of Android NDK, just like it has been from Apple platforms, and the Linux kernel is the last GPL piece standing on Android.

Meanwhile, Fuchsia is actually slowly testing the waters in production.

https://techlog360.com/fuchsia-os-on-first-generation-nest-h...

It is no accident that Project Treble follows a similar architecture to Fuchsia drivers.

Fuchsia's license being more permissive than Android is exactly the end goal.

It might not come tomorrow, but it will come.

Post reply on HN