Progress on /e/, the de-Googled Android fork • Hacker News Board

Re: Progress on /e/, the de-Googled Android fork

#31

Post by ac29 » Mon, Mar 09, 2020, 7:56 PM UTC

CivBase wrote: post #6

> We are also announcing this week an “/e/ easy installer” that will make the flashing process much more easier, by pluging the smartphone to a PC and launching a dedicated application that will make most of the job. Why do phones require device-specific builds and ROM flashing just to install a different OS? Why isn't there a phone out there with a normal boot loader that allows me to install whatever OS I want like…

All Android phones that shipped with Android 9 or later can flash a generic system image (GSI): https://developer.android.com/topic/generic-system-image

Unlocked bootloaders aren't terribly common though outside of Google's devices.

Re: Progress on /e/, the de-Googled Android fork

#32

Post by _bxg1 » Mon, Mar 09, 2020, 8:11 PM UTC

> we replace with a software layout called microG that can still receive push notifications and have geolocation data for apps (using Mozilla geolocation service)

It's good that they set up microG for you; that's one of the hurdles with using Lineage this way.

I'm very curious about their Maps app. That was one of the very biggest problems when I tried to use Google-free Android a couple years ago. The open-source options at the time were bad. If they've made a decent alternative, that would truly be a game-changer.

One other random thought: the name "/e/" is terrible. Hard to search for, hard to meaningfully verbalize, hard to interpret.

Re: Progress on /e/, the de-Googled Android fork

#33

Post by nekopa » Mon, Mar 09, 2020, 8:11 PM UTC

doublerabbit wrote: post #28

doublerabbit wrote: post #8

Earlier quoted context omitted.

>Why do phones require device-specific builds and ROM flashing just to install a different OS? Capitalism. And reasons that Google/Apple want you locked to their operating system, their hardware. Prove me wrong.

Downvoted with no reasoning. Nice

Maybe because your comment didn't mention anything specific to prove wrong. Just saying Capitalism and Reasons doesn't mean anything.

Could I just say "Communism" and thereby prove you wrong?

Re: Progress on /e/, the de-Googled Android fork

#34

Post by doublerabbit » Mon, Mar 09, 2020, 8:34 PM UTC

nekopa wrote: post #33

doublerabbit wrote: post #28

Earlier quoted context omitted.

Downvoted with no reasoning. Nice

Maybe because your comment didn't mention anything specific to prove wrong. Just saying Capitalism and Reasons doesn't mean anything. Could I just say "Communism" and thereby prove you wrong?

> And reasons that Google/Apple want you locked to their operating system, their hardware.

Well, do they not? Locking you to their product, forcing you to use their product for their own gain.

Apple won't even let you repair your phone unless you go via their own dealers.

You could call communism, but there isn't any communism element to it. It's all capitalism to answer OP's question to "Why can't I install any operating system" because you can, there is nothing stopping you apart from the companies that control the product.

Re: Progress on /e/, the de-Googled Android fork

#35

Post by jshevek » Mon, Mar 09, 2020, 8:48 PM UTC

doublerabbit wrote: post #28

doublerabbit wrote: post #8

Earlier quoted context omitted.

>Why do phones require device-specific builds and ROM flashing just to install a different OS? Capitalism. And reasons that Google/Apple want you locked to their operating system, their hardware. Prove me wrong.

Downvoted with no reasoning. Nice

I downvoted your comment because it lacked substance, invited a flame war (whether or not it was intended), and ended with an idiom I associate with low quality discourse.

Re: Progress on /e/, the de-Googled Android fork

#36

Post by ggm » Mon, Mar 09, 2020, 9:26 PM UTC

Binary blobs dont have trackers and snoops? Phones have FPGA and need binary blobs. Certified RF segments for regulatory permitted operation in the mobile telephony world.

What about the TPM and keystore?

Re: Progress on /e/, the de-Googled Android fork

#37

Post by throwaway2048 » Mon, Mar 09, 2020, 10:06 PM UTC

monocasa wrote: post #9

CivBase wrote: post #6

> We are also announcing this week an “/e/ easy installer” that will make the flashing process much more easier, by pluging the smartphone to a PC and launching a dedicated application that will make most of the job. Why do phones require device-specific builds and ROM flashing just to install a different OS? Why isn't there a phone out there with a normal boot loader that allows me to install whatever OS I want like…

The problem's not the bootloader (pretty much all Android kernels use the same bootloader format), it's that the hardware introspectable by software, and the device tree passed in to make up for that isn't designed to be used by anybody other than the OEM in the first place. It's like the days of when Linux didnt support ACPI well, but now everything is behind ACPI tables instead of PCI config space.

acpi would be a blessing, the norm for ARM SoCs is absolutely no enumerablity whatsoever, just devices hanging off a random address in memory somewhere.

Re: Progress on /e/, the de-Googled Android fork

#38

Post by ldng » Mon, Mar 09, 2020, 10:21 PM UTC

monocasa wrote: post #30

ryukafalz wrote: post #27

Earlier quoted context omitted.

Given the set of design decisions Linux has made, and assuming the Linux driver development model isn't going to change to accommodate manufacturers that want to keep their source to themselves, the proprietary drivers are part of the issue here. (The other part is manufacturers not working with the Linux community on upstreaming their drivers, even when there are free drivers.) Yes, a stable interface is another pot…

No, I'm not saying its a solution or a problem. It's completely orthogonal.

The problem is those drivers are not maintained. And it just happen that those are proprietary. Is that what you're trying to say ?

Re: Progress on /e/, the de-Googled Android fork

#39

Post by pergadad » Mon, Mar 09, 2020, 10:47 PM UTC

_bxg1 wrote: post #32

> we replace with a software layout called microG that can still receive push notifications and have geolocation data for apps (using Mozilla geolocation service) It's good that they set up microG for you; that's one of the hurdles with using Lineage this way. I'm very curious about their Maps app. That was one of the very biggest problems when I tried to use Google-free Android a couple years ago. The open-source op…

Some osm apps have good navigation, but they don't have the same data, e.g. on traffic. 'Here' isn't bad. And in doubt there's always Google maps by browser.

Re: Progress on /e/, the de-Googled Android fork

#40

Post by _bxg1 » Mon, Mar 09, 2020, 10:50 PM UTC

pergadad wrote: post #39

_bxg1 wrote: post #32

> we replace with a software layout called microG that can still receive push notifications and have geolocation data for apps (using Mozilla geolocation service) It's good that they set up microG for you; that's one of the hurdles with using Lineage this way. I'm very curious about their Maps app. That was one of the very biggest problems when I tried to use Google-free Android a couple years ago. The open-source op…

Some osm apps have good navigation, but they don't have the same data, e.g. on traffic. 'Here' isn't bad. And in doubt there's always Google maps by browser.

OSMAnd was what I used, and it was horrendous. The actual data was okay (I didn't expect it to be on-par), but the user experience was just really bad. Barely usable.

Haven't heard of "Here". I did end up using Google Maps in the browser sometimes, although it felt like a compromise (and obviously didn't have a stellar user-experience itself).