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

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

itsfoss.com

Post reply on HN
Print view View original

21–30 of 49 posts

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

#21

Post by monocasa »

ryukafalz wrote: post #17
kop316 wrote: post #15

Earlier quoted context omitted.

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?

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.

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

#22

Post by ryukafalz »

monocasa wrote: post #21
ryukafalz wrote: post #17

Earlier quoted context omitted.

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?

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.

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

#23

Post by ryukafalz »

monocasa wrote: post #20
ryukafalz wrote: post #18

Earlier quoted context omitted.

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.

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

#25

Post by monocasa »

ryukafalz wrote: post #23
monocasa wrote: post #20

Earlier quoted context omitted.

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.

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

#26

Post by BuildTheRobots »

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/

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

#27

Post by ryukafalz »

monocasa wrote: post #25
ryukafalz wrote: post #23

Earlier quoted context omitted.

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

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

#28

Post by doublerabbit »

doublerabbit wrote: post #8
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…

>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

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

#29

Post by mqus »

BuildTheRobots wrote: post #26

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.

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

#30

Post by monocasa »

ryukafalz wrote: post #27
monocasa wrote: post #25

Earlier quoted context omitted.

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

No, I'm not saying its a solution or a problem.

It's completely orthogonal.

Post reply on HN