FSF High Priority Projects

Aury88

@fla I already wrote them for another reason (make microkernel an HPP) I was only waiting to understand what is the foundation and community will about all this (so also to gain some time between the two email)

but I fear UT is not listed in the HPP because, as said by Replicant:
" Many mobile operating systems are mostly free software (e.g. Android, Firefox OS, Ubuntu Touch, Tizen), as they use the Linux kernel, a free framework and ship with free base applications. However, the user-space hardware abstraction layers are for the most part proprietary (it varies from one device to another) and they also ship with proprietary loaded firmwares for various integrated circuits. Every piece of proprietary software running on the system is a risk for privacy/security as they can offer remote access back-doors and compromise the rest of the system."
And also
" None of these mostly-free systems have a clear policy to reject proprietary software and not advocate its use, except for Replicant. "

PS: are we using a user-space abstraction layer? I thought the abstraction layer was between the hardware and the kernel, so a kernel-space abstraction layer :man_shrugging_light_skin_tone:

kugiigi

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

flohack

@aury88 you need to learn more about Android:

While Google chose the Linux kernel and its GPLv2 license, they sonn figured out that it was taking a) much too long to get all drivers into mainline, especially since they did not want to wait until Linus and other kernel folk were happy with their ideas, and also b) hardware vendors argued that they dont want to publish their sources.
So they found a way that most "drivers" for hardware in the Android Linux kernel are just stubs, and the real driver work happens in a closed-source userland service/daemon.
This is when we talk about the Android container, the system.img, thats the thing that communicates with UT via libhybris.
every Android device has one, without it you do not have sensors, GPS, Bluetooth, camera. Not even screen output.
So its unavoidable to run those daemons. But, as much as possible, we run them in an lxc container and try to seal them off as best as we can.

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.