Progress on /e/, the de-Googled Android fork | Hacker News Reader

, the de-Googled Android fork

itsfoss.com

108 pointsindidea48 comments

> 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 I can on a PC?

I have a perfectly good phone, but I know I'm going to have to buy a new one eventually just because the manufacturer will stop supporting the hardware. Meanwhile, I have decades-old PCs that are running just fine.

Privacy is important. Removing Google from the picture is great. But I don't see this, LineageOS, or anything else taking off until we have a more accessible solution for installing mobile operating systems. An application that streamlines the flashing process is nice, but I don't think that's enough.

>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?

> 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.

Capitalism + IP Protectionist policy would be more apt a description. But this isn't any more or less capitalism than say Capitalism + Social welfare programs are Marxism or Socialism.

Personally, I'm hoping that some states grow a pair and actually pass meaningful right to repair legislation, then a lot of things will tumble. There are plenty of Libertarian and Capitalist supporters who do not like the corporatist status quo. That doesn't mean that Capitalism itself is the issue.

If it weren't for IP protections, there would be more interoperability most likely, or better service/support. Sharing communication breaks, and offering run-alike chip and interface replacements would be less of an issue. Not to mention, it's Corporatist IP protections that keep out competitive upstarts.

Also, Apple happens to make most of their devices in a Communist country, so how does that stand?

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.

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.

> 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 I can on a PC?

A few reasons:

1. Proprietary drivers are the norm for mobile devices, whereas (with a few exceptions) this is not the case for desktops/laptops.

2. Even when the drivers are free, standard practice among device manufacturers seems to be forking the kernel for each device and working off that fork. These things don’t and can’t run on mainline Linux/Android.

See the Librem 5 and PinePhone for what are probably the only two devices attempting to fix the above problems. And even if you fixed those:

3. ARM devices typically don’t have the same device enumeration capabilities as x86 PCs, meaning you need a separate device tree for each one. I believe there are also efforts underway to improve this situation, but that’s where we are at the moment.

Proprietary drivers are very much the norm on windows and mac.

That’s true, I was mostly looking at this from a Linux-centric point of view. You won’t be running Windows or macOS on your phone.

What I'm getting at is that propreitary drivers has no bearing on the matter when 90+% of PCs are running propreitary drivers.

It does on Linux, where there's no stable ABI for drivers to use, right? Yes, that's a design decision on Linux's part, but it's one that seems to be working out just fine for PCs.

But that's less than 10% of the market. The rest doesn't have those problems either, despite having almost entirely proprietary drivers. Therefore it's not the propreitary drivers that are the issue.

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 potential solution. It's unlikely to happen[0], but it would solve the issue.

(Quite honestly, though, I'm glad we don't have to deal with manufacturers pulling stuff like this in the Linux world: https://twitter.com/Foone/status/1172237142485078016)

[0] https://www.kernel.org/doc/Documentation/process/stable-api-...

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 ?

The market is smart phones, where the market share for a linux kernel (android) is much higher.

The separate device tree (#3) is not as big an issue as the first ones. If you are making a Linux kernel for an ARM device, you will have to make a device tree, and it should not change once written.

That’s true, it’s less of an issue than the others, but it’s still a per-device difference that the kernel needs to know about before you bring the system online. If you’re trying to make an installer that’ll run on any ARM device like those on x86, that’s a problem - how does the installation image know what device tree to use?

If I remember when I did it for the Novena, you had to include that specific dtb file for the install. That does make it a pain, as you are correct, the installation image is board/chip specific

The device tree is part of the solution, not part of the problem. The reason PCs are able to handle this is that the really gnarly stuff (pincfg, gpios, I2C, SPI, random power management), is handled by per board tables in ACPI, and device tree handles the same niche.

The problem is that the device trees are half assed since they run against a hacked up kernel, not that they exist in the first place.

Ah, interesting. I think I have some reading to do; there clearly are multiplatform images out there now (Debian for example https://wiki.debian.org/DebianKernel/ARMMP) so my understanding of the situation was somewhat mistaken.

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.

> 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.

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).

> the name "/e/" is terrible. Hard to search for, hard to meaningfully verbalize, hard to interpret.

I think I read somewhere that this is a deliberately-obscure temporary codename pre-proper-branding, during initial unstable development.

That said, they've used it a lot in their branding, so I'm not sure...

Update: From their FAQ page[0]:

> Why this weird, inconvenient /e/ name?

> ...

> It’s the current project codename, we will probably introduce a new and more convenient name for our mobile ROM in few months.

https://e.foundation/get-support/#faq

As other user replied and to extend it, /e/ is a rebranded LineageOS with microG integrated plus some small commits.

Also, it uses a Nextcloud fork which isn't even open source as a replacement for Google cloud service, and same as another reply, why trust /e/ over Google?

As that it's mostly stolen work in some sorts(Earn money with OSS devs effort? Seriously what a disgrace.), instead, please support LineageOS for microG[1]

[1] https://lineage.microg.org/

Last time I checked all phones with lineageos support were made by Google, China or were like 5 years old. For this reason I never got it.

> the/e/ name will be abandonned for something else quite soon.

Good to know; a word that's more easily duckduckgoable may help with branding.

Wanted to comment on the name too.. slash-e-slash???

Obviously a reference to 4chan's ecchi board

It's a very funny and perhaps unfortunate from the perspective of 4chan users.

> duckduckgoable

Not a thing.

Duckable might be better?

Direct link (since it's not easy to find in the article):

https://e.foundation/

An ungoogled mobile operating system: fantastic!

> ensure that you have an /e/ account (for /e/ online services such as mail, drive, calendar…). You can register for a free /e/ acount here

right - and I should trust E over Google why?

https://doc.e.foundation/devices/

According to the article you can selfhost... But I don't know if thats possible right now.

Um... so how are they making money if we are not the product?

itsfoss

I guess I read about another similar story posted on HN several months ago? Or its the same company?

Maybe you're thinking about Volla Phone.

https://www.kickstarter.com/projects/volla/volla-phone-desig...

Are these de-Googlification changes going to be upstreamed into LineageOS?

Is this forked from LineageOS or directly from AOSP?

It's forked from LineageOS.

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?

Reply on news.ycombinator.com