zlacker

[return to "Why I left Pine64"]
1. neilv+Va[view] [source] 2022-08-17 12:27:04
>>todsac+(OP)
It's good to see Martijn Braam fought the good fight on things like the PinePhone Pro bootloader in eMMC, and I'm sorry to hear the situation became untenable.

After Pine64 went to all the trouble to make a series of branded early developer editions for various distros, and ongoing community goodwill outreaches, I didn't expect something like this to happen.

IMHO, any handheld hardware right now wanting to be open and sustainable Linux should probably start by making sure it's solid with PostmarketOS configured with a mainline kernel, as a good test. (PostmarketOS is a litmus test for purity, and has had a bunch of work to make bringing it up easier than the usual server/desktop purity test of Debian.) Working Phosh and Plasma userlands running atop PostmarketOS are good further tests. Supporting additional distros, userlands, and hacking is also important.

(Even if the hardware is something like the Purism Librem 5, which has invested heavily in lots of good distro work, if PostmarketOS with mainline kernel boots cleanly and runs solidly, that's a good sign.)

◧◩
2. Martij+ae[view] [source] 2022-08-17 12:45:20
>>neilv+Va
We've spend a lot of time optimizing the developer experience in postmarketOS by making easier tooling and writing more documentation, I'm glad it helps.

While Debian has more strict policies on software licensing etc the musl component of postmarketOS pretty much makes sure that no closed source software will ever run in userspace. The main difference is that postmarketOS does deal with firmware for hardware while Debian doesn't. Hopefully we someday get at a point where even the firmware for these devices isn't problematic anymore.

◧◩◪
3. _chu1+Qx[view] [source] 2022-08-17 14:19:35
>>Martij+ae
Why prevent closed source software from running in userspace? Even in Fedora Linux I find myself having to use closed source software a lot for daily tasks.
◧◩◪◨
4. jcul+7C[view] [source] 2022-08-17 14:38:06
>>_chu1+Qx
It's not intentional, just a side effect of using musl libc instead of glibc (GNU C library).

Some distros, such as alpine Linux, use musl libc as their system wide C library.

glibc is pretty much ubiquitous, so any closed source software will be compiled against glibc and will not work with musl c libraries.

That's not to say a vendor couldn't do a muslc build of a closed source software, just that it's pretty much unheard of.

I believe binary compatibility is a goal of musl, being able to run a glibc binary against a musl libc library, but I think that's a long way off.

So an alternative on a musl libc distro is to use something like flatpak that bundles glibc libraries in a sandbox / container.

The side effect the grandparent comment is referring to, is that you have a good idea all the software on your system is open source, other than what you are running in flatpak, as closed source binaries are unlikely to run on your musl system.

[go to top]