[vomitcuddle]

Yeah, what raised a red flag when reading this project's description was that having a single kernel for all devices and no compatibility layer like libhybris is unfortunately an unrealistic goal in the world of ARM android devices.

An approach that is less likely to result in vaporware would be to maintain ports of Halium to older devices based on LineageOS kernels/drivers, with an optional Alpine Linux userspace.

Otherwise this project is little more than README.md Hacker News bait.

[ollieparanoid]

> A (nearly) mainline kernel running on the Nexus 7 https://lwn.net/Articles/680109/

If there are enough helping hands, we could do this as a community.

The bootstrap program, pmbootstrap, is a working base component that makes development much easier (alone the automatically set up cross-compiling with distcc, ccache, armhf and native chroot), so it is definitely more than a README.md.

Also the title says, that the project is "aiming" - which does not say it has reached any of its goals yet. But at some point it needs to be announced to the community, so I might as well do that now, at a point, where other hackers could join in and parallelize development.

[brady67ten]

The biggest issue in trying to have a long running constantly updating OS on a Android phone is the device drivers.

Instead of trying to reverse engineer and make open source drivers, I think you should try a more generic approach something like a rump kernel or some other generic layer for each Linux kernel version which can simulate the interface needed for the particular kernel driver. That way you don't have to keep porting or reverse engineering device drivers.

Your approach of trying to make an open source driver is a losing one, it requires a lot of work and you can't reasonably keep up with it.

[jlg23]

> Your approach of trying to make an open source driver is a losing one, it requires a lot of work and you can't reasonably keep up with it.

Not necessarily, the more diverse the devices you have drivers for, the more code you can reuse and finally the more devices you can "recycle".

Of course, the big if there is: Can you reach the critical mass of drivers without the project exhausting itself.

[brady67ten]

> Of course, the big if there is: Can you reach the critical mass of drivers without the project exhausting itself.

If that were the case, we wouldn't find ourselves in the current quagmire that we're in. Linux kernel already had a huge number of devices supporting it.

The truth is, there is nothing stopping device vendors from releasing a device driver for a specific version, maintaining it for an year or two and then abandoning it. The better approach would be to figure out a stable interface layer for kernel drivers so that you can simply plug and play the vendor supplied device driver.

[vomitcuddle]

Could you help me understand your reasoning behind not pairing up with or taking advantage of existing projects like Halium or LineageOS?

I'd love to run mainline Linux without any Android cruft on my old phones, but realise that this would take a lot of effort per each device. Each Android device is different, with its own kernel patches, proprietary modules and sometimes Android-specific userspace HALs. The Tegra in the Nexus 7 was designed to run non-Android Linux, there are native X11 drivers for that thing - that's not the case for devices like my current phone.

[ollieparanoid]

> Could you help me understand your reasoning behind not pairing up with or taking advantage of existing projects like Halium or LineageOS?

From the article:

> Of course I am not the only one, that came to this conclusion - especially in the last few weeks with the Halium project rising (greetings!). I am all-in for working together — sharing udev rules, merging Android kernels together, whatever makes sense!

> [...] postmarketOS does not fit the Halium model, as it avoids the Android build system entirely and does not run Android next to GNU/Linux.

> Thanks to Replicant, LineageOS, Halium. Together, we can make the vision of long-lasting, open source smartphone operating systems a reality!

So I see postmarketOS as part of the community. We have multiple projects, that want to provide a more open alternative to Android, on Android devices. This will only work out, if we work together and share, what we can.

postmarketOS differs from the other projects, that it tries to completely cut-off the Android parts. This will be harder for hardware compatibility, but then again, it does not depend on Google's upstream Android code (which does not get developed as a true community project, they only put out the source after they are done developing behind close curtains), and it uses less resources than running Android as second OS next to your regular GNU/Linux.

Regarding kernels and drivers, postmarketOS directly packages LineageOS kernels. Proprietary 3d acceleration will be avoided for now, some tests with "weston-smoke" and other demos showed, that it works fast enough without them. You won't be able to play 3d games, but that's not really in the scope of the project for now.

[ndesaulniers]

Isn't that solved by device tree w/ overlays? (I don't know much about ARMv7).

[djsumdog]

Very few mobile phone arm devices support device trees. Only Windows Mobile phones provided UEFI (with locked bootloaders). Most ARM devices just attach random shit to random pins and have totally non-upstreamable kernels.