FSF High Priority Projects

Aury88

@flohack I already know-ish almost all of these things my doubt was about the "position" of this system.img/abstraction layer alt text (I though halium was covering the bottom red and blue areas in a "kernel-land"and UT was over it)
I already know UT needs (as any other SO) these blobs to run on "android device".
Replicant does not seems to use these services/daemons and so their os is always missing something in any device.

@kugiigi I only copy-pasted what they wrote on their website

I don't think they are purer that other distros on pinephone or librem5 and I suspect they also know that but avoid to talk about this.

flohack

@aury88 The old drawing still stands:

So basically Halium is only a device boot API that we developed to bring up the rootfs and init. As soon as everything is booted Halium is not needed anymore.
What most people confuse with libhybris: Thats the thing that talks to Android container and Ubuntu Touch. And thats also show in the drawing.

Fla

@kugiigi said in FSF High Priority Projects:

@aury88 So replicant is purer than even distros oon the Pinpehone/librem 5? Does it even work and daily driver ready on some devices? I thought it's similar to /e/ and Lineage OS.

The FSF quote talks about Firefox OS, no doubt it is several years old and the situation with PinePhone and Librem 5 is different.

Aury88

@flohack thank you! Now it is more clearer.
Now my only doubt is what is the scheme in an "open hardware" device like pinephone or librem5 and what closed source parts still have to be integrated in UT (preventing UT to be fully FSF compliant.)

PS: I don't find that very informative scheme in our doc...I think that could be usefull to understand what UT is and what is/must be touched by halium and the port process. why that is not in our documentation?

flohack

@aury88 Well in the Pinephone we do not need the Android container and libhybris parts. They are being replaced by native access or a small API so that our userland services can be used on both Android and Non-Android phones. But I am not sure FSF will not be confused if we offer ourselves as a "dual-stack" solution that runs sometimes on an open platform, sometimes not.

HengYeDev

@flohack The FSF doesn't like any sort of closed source anywhere in the project...they don't recommend Debian just because it has a non-free repo and documentation.

prog-amateur

I just would like to thank you all, as I have learned many things from this thread, especially the chart with the LXC container and UT.

My opinion is that FSF could add UT in the list with a star *(UT on Pinephone only) Because, if UT in the Pinephone complies with the FSF requirements, then it should be added into the list.

Keneda

@prog-amateur
Even pinephone is not full open source (hardware), so maybe FSF will not like this...

https://www.pine64.org/2020/01/24/setting-the-record-straight-pinephone-misconceptions/

"LTE modem is a black box"

dobey

If they won't even list Debian and Ubuntu on https://www.gnu.org/distros/free-distros.en.html I'm pretty sure we won't be seeing Ubuntu Touch listed either.

Given recent events and the dwindling relevance of the FSF over the last decade or more, I'd say we should just steer clear of anything involving the FSF, and if we want to get involved with a similar organization, to look at working with https://sfconservancy.org instead.

Keneda

@dobey
The purpose of FSF is to promote FULL libre software, so i understand why that doesn't include Ubuntu (desktop).

That's not a up to FSF to include companies that produce non full libre software, that's up to non full libre software to get rid of closed source software if they want to be included in FSF promoted software.

Now Ubuntu Touch is not Ubuntu desktop, so i assume the closed source software included in the first, is not necesserally present in the second.

PhoenixLandPirat

@keneda said in FSF High Priority Projects:

Now Ubuntu Touch is not Ubuntu desktop, so i assume the closed source software included in the first, is not necesserally present in the second.

The main point is drivers, and ubuntu touch cannot work 100% on many if on any mobile device, without closed source software.

Keneda

@phoenixlandpirat said in FSF High Priority Projects:

The main point is drivers

Technically, that's the android device linux kernel that contains those blobs, not uTouch, no?

If Pure OS can be FSF compliant (is it on librem 5?), maybe uTouch can be too (on Librem 5)?

flohack

@keneda no the kernel does not contain blobs, its the Android system image that we start in an lxc container.

Well you would need probably to go through a certification process with them, but they 100% find one important package that has the wrong license

As Rodney said, FSF is something that has no practical relevance for many users, they are pragmatic and want to get around with their workloads, and application cases. We also will not invest work ATM into getting rid of such blockers the FSF might find.

dobey

@keneda Ubuntu Touch still requires binary blobs to work, whether that's on Android devices, or ones that work on mainline. One of the core FSF complaints about Debian/Ubuntu is the use of linux-firmware which includes these redistributable firmware blobs which are necessary for the operation of certain hardware, and which the kernel loads into the hardware during initialization.

dobey

@keneda I guess that PureOS is "compliant" if they don't include the linux-firmware package by default, but the phone hardware itself wouldn't comply, because of the modem. AFAIK, the Bluetooth/WiFi support in Librem 5 is also a bit lacking because Purism want to only use BT/WiFi in their systems, which doesn't require binary firmware blob, which the newer Atheros chips that support newer Bluetooth and WiFi versions, do.