Live data from Hacker News

Daily driving a Linux phone, but why?

thefoggiest.dev

171–180 of 237 posts

Re: Daily driving a Linux phone, but why?

#171
post #49

Earlier quoted context omitted.

Firejail and apparmor have existed for years. If you don't use them maybe it's your fault? Also the very same npm backdoors have already hit android apps. What can sandboxing do if you backdoor a dependency of your banking app?

Sandboxing should be built in and by default, not DIY and glued on, like with apparmor and firejail. "Your car does not come with a seatbelt? Seatbelt parts are easy to order online and assembled on any car, it's your fault for not using one." > Also the very same npm backdoors have already hit android apps. What can sandboxing do if you backdoor a dependency of your banking app? The whole point of sandboxing is that…

It’s always felt strange that Linux desktops try to make sandboxing and permissions the responsibility of packaging standards. That strikes me as much more of a system level thing like audio or display output.

Re: Daily driving a Linux phone, but why?

#172

Earlier quoted context omitted.

It still makes zero sense to take the XDG/dbus/whatever stack and make it run on a phone, suboptimally, when AOSP is right there and has already solved all the thousands of integration issues you'll run into --- plus, it's already free software. NIH is the only rationale for the "Linux" phone thing and it's why it will be forever fringe. People working on "Linux" phones as anything more than a diversion (why not play…

> it's already free software I'd just like to interject here for a moment. The word Free Software has a specific meaning that AOSP does not meet. The only component of AOSF that is Free Software is the Kernel, due to GPL, and aside from low-level Android-specific modules such as binder there's no secret sauce in Android kernels; even the vendor modifications are mostly gutted out in favour of Project Treble and GKI.…

Which one of the four freedoms is not met by AOSP?

Don‘t Linux phones also rely on binary blobs?

Re: Daily driving a Linux phone, but why?

#173
post #56

Earlier quoted context omitted.

It still makes zero sense to take the XDG/dbus/whatever stack and make it run on a phone, suboptimally, when AOSP is right there and has already solved all the thousands of integration issues you'll run into --- plus, it's already free software. NIH is the only rationale for the "Linux" phone thing and it's why it will be forever fringe. People working on "Linux" phones as anything more than a diversion (why not play…

Try getting a patch into android vs getting a patch into a debian package and tell me how it's the same thing :D

GrapheneOS has contributed many past features to AOSP.

Does that count?

Re: Daily driving a Linux phone, but why?

#174

Earlier quoted context omitted.

It still makes zero sense to take the XDG/dbus/whatever stack and make it run on a phone, suboptimally, when AOSP is right there and has already solved all the thousands of integration issues you'll run into --- plus, it's already free software. NIH is the only rationale for the "Linux" phone thing and it's why it will be forever fringe. People working on "Linux" phones as anything more than a diversion (why not play…

It makes sense because it gives you complete control over your device, to a level even AOSP can't touch.

Even Linux phones rely on binary blobs.

Re: Daily driving a Linux phone, but why?

#175
post #130
post #112

Earlier quoted context omitted.

We‘re talking about AOSP Android here

It cannot be compiled as it is, so it's nothing that runs on any phone.

GrapheneOS is completely open source and based on AOSP. As is LineageOS. What‘s your point?

Re: Daily driving a Linux phone, but why?

#177

same here, i daily drive linux on my phone, ditched the prioprietary OSs long ago

How are you dealing with companies that force you to use an Android app? There are so many services in daily life where people just expect me to have an Android/iPhone device. Those things are increasingly difficult to achieve in a different way.

spoiler: i dont. i dont need to, simply. my bank can be accessed fully through the website, and that is how i use it. most services i have i use through email or some other form of interaction that does not require an app. i simply do not use these services, and thus i dont need to even have an app for them. if im lucky, it will work on waydroid, but i dont have a lot inside waydroid. so, yeah, it is easy for me as of now at least.

Re: Daily driving a Linux phone, but why?

#178
post #159
post #135

Earlier quoted context omitted.

It is unclear to me what alternative you are proposing, apart from bending to Google and Apple?

There is no alternative. Unless you pay by cash and have verified that all of the utilities and services you consume are not laundering your data then you’re just wasting your time by putting up with a horrible phone OS experience.

You are right to remind that other service providers such as banks or any online shop do routinely collect and sell an amount of personal data that should also concern us, but a phone in your pocket that is used for virtually everything and that's controlled by a third party raises more concern than just privacy of consumer data.

Re: Daily driving a Linux phone, but why?

#179

Earlier quoted context omitted.

> Is it still possible to initialize an Android phone without a Google account? Totally, get a Pixel phone and put GrapheneOS on it. You get state of the art hardware and the latest Android hardened for privacy and with optional Google services. That is, you can install and remove them anytime like any other app.

Do you have to install a whole new distro? I just managed to get past the signup screen, then deleted the "first use" app and disabled Google's apps.

Yes, you need to flash their image. They have a web installer from the browser and the process is relatively straightforward: https://grapheneos.org/install/web

Re: Daily driving a Linux phone, but why?

#180

Earlier quoted context omitted.

It may be in the future, but for now it is no different from Fedora Workstation in terms of security. Please correct me if I am wrong. AFAIK Silverblue has no additional sandboxing or any other improvements to security.

Pretty sure Fedora, being based on Red Hat, has the strongest SELinux policy in place by default, and SELinux is pretty much the best sandboxing option available other than actual virtualization.

Yes, but this was about Silverblue and how it implements some additional sandboxing, which it doesn't. SELinux is great, but maintaining it and creating configs is huge amount of work and where on AOSP, every process is strictly confined with SELinux, on Fedora, not so much. Not to mention the additional software the user installs. Not at all comparable to real Android or iOS sandboxing.
Post reply on HN