[Replicant] Replicant funds usage, Handshake donation, and nlnet funding.

Wed Jan 16 00:57:00 UTC 2019

On Tue, 15 Jan 2019 20:12:38 +0000
Nick <replicant at njw.me.uk> wrote:

> Hi GNUtoo,
Hi,

> I'm just a daily user of Replicant, not a developer, but figured it 
> would be good to join in the discussion nonetheless. Weigh my words 
> appropriately ;)
Everyone is welcome in the discussion.

> Quoth Denis 'GNUtoo' Carikli: 
> > The general consensus was that we could use the fund mainly to fix
> > some pressing issues and to lower the amount of work required to
> > maintain Replicant.  
> 
> I agree that lowering the amount of work to maintain replicant, to 
> the point that you can easily and quickly apply security patches, is 
> vital. After all, Replicant is great for software freedom, but 
> modern phones are a very efficient attack vector, and a free phone 
> which is insecure can be used to take away even more important 
> freedoms.
The main goal here is rather to make sure that the Replicant project
doesn't die due to the lack of developers and time.

For instance if we use the funds to fund work that we cannot maintain
anymore years after, because we don't have that amount of funding
anymore, and lack lack time to maintain it, then it would be a bad
strategic decision that could be dangerous for the Replicant project.

That said we also seriously need to find a way to lower the attack
surface and get the latest security fixes.

> > Pressing issues:
> > ----------------
> > Replicant has some urgent bugs to fix, for instance:
> > - We have several freedom issues to fix (for instance the build
> > depends on Debian which is not compliant with the Free Software
> > Distribution Guidelines(FSDG))
> > - Some SIM cards are not recognized
> > - Under some conditions, the call audio is garbled.
> > - Adding support for devices that can still easily be found new or
> >   second hand. The devices currently supported by Replicant already
> >   cannot be found in local second hand shop (in Paris, France)
> > anymore, but can still be found online.  
> 
> These all sound very reasonable to me. With the exception of the 
> Debian dependency for building - so long as it only depends on the
> 'main' repository I really don't see the problem.
Replicant is listed in the "Free Non-GNU Distributions" on the GNU
website, theses distributions have to follow the Free System
Distribution Guidelines (FSDG)[1].

This means that we don't want to depend on a distribution that don't
follow theses guidelines for building Replicant. This is a bug that we
seriously need to fix.

However if we port Replicant to a more recent Android version, that may
be fixed automatically.

> > Longer term tasks:
> > ------------------
> > The most important tasks we could want to fund would be the ones
> > that lower the amount of work required to maintain Replicant. For
> > instance:
> > - Finishing libsamsung-ipc and samsung-ril, and upstreaming them in
> >   LineageOS.  
> 
> Would this mean other (more modern) phones could be much more easily 
> ported to Replicant?
Yes, it would help a bit for that, though however adding support for
more recent Samsung phones or tablets is already easy if they already
use an Exynos Processor/system on a chip. We have some evaluations of
devices in the wiki here:
https://redmine.replicant.us/projects/replicant/wiki/TargetsEvaluation

Here it's more a maintenance issue: Completing samsung-ril and
libsamsung-ipc rather means that other Android or GNU/Linux
distributions could start using free software to talk to the modem for
some Samsung smartphones and tablets and start contributing to it.

This would probably result in having less bugs with such components,
and in having other distributions adding support for more devices and 
more recent Android versions after they are released.

This should lower the amount of work when porting Replicant to newer
Android versions.

> > - Making Replicant work with upstream kernels.  
> 
> Would this task reduce the maintenance burden significantly? If not, 
> my opinion is that this is not an important enough problem to spend 
> the resources on.
There is some rationale here:
https://redmine.replicant.us/projects/replicant/wiki/Upstream

As for the maintenance:
- Older smartphones and tablets that have enough RAM to run newer
  Android versions could continue to be supported by Replicant even if
  LineageOS stops supporting them as we would just have to update the
  kernel version and the hardware abstraction layers that works with the
  upstream kernel. This would apply to many of the smartphones and
  tablets capable of using a mainline kernel.
- We could very easily add support for devices already supported by a
  mainline kernel. For instance many tablets using an AllWinner
  processor/system on a chip seem good candidates as some of them have
  a free software bootloader and are already well supported by free
  software.

This also has strong security benefits. Not using mainline kernel means
that we are stuck with old kernels that are based on hardware vendors
fork of Linux. The code in Linux forks is also not always very clean
and did not have the same level of code review and scrutiny than the
upstream code.

Given the very good upstream status of some of the smartphones already
supported by Replicant such as the Galaxy SIII (I9300), and the amount
of work required to rebase all the changes on top of more recent kernel
version, it makes sense to go the other way around and instead make
Replicant work with stock upstream kernels.

Adding support for devices like the Goldelico GTA04 and the Necuno
Mobile will be way easier if we adapt Replicant to use kernels that are
as close as possible to upstream Linux.

We will probably still need some patches on top because of some Android
requirements, but the idea is to keep it as minimal as possible to be
able to easily rebase such changes each time that a new kernel version
comes out, in order to make porting Replicant to newer Android versions
way faster and way easier.

If at the end, we manage to upstream most of the Replicant code base up
to the point where upstream takes care of adding support for newer
Android version, it would be really great.

> Another possible task could be adding free software graphics 
> acceleration drivers, if there are any candidates that could use it.  
> I know there have been various efforts to create drivers for some 
> chips used for ARM stuff, but I don't know if they're relevant to 
> any phones Replicant could target.
This is definitely relevant but we also want to keep being able to
support devices that will probably never have free software 3D
acceleration.

I think that we should do both if we find the time and/or funding,
however having a more complete OpenGL implementation that would work in
all cases is probably more important if we can't work do both.

We could probably use Etnaviv to accelerate some operation such as
video resizing, color conversion (for the camera application) and so on.

> But if so, that would be cool - 
> the latency of my screen responding to stuff is the thing that most 
> annoys me about my S3 running Replicant (really this shows how great 
> Replicant is) - I'm sure it would feel much snappier with hardware 
> acceleration.
I've no idea about the status of the Lima and Panfrost drivers. Are
they usable enough to do very basic things like color conversion and
image resizing?

> > Volunteers:
> > -----------
> > So far, most of Replicant contributions were done by volunteers.
> > So the Replicant project could also not want to fund work that
> > people want to as Volunteers but but instead fund important work
> > that no one want to do.  
> 
> I may be mistaken, but it looks from the outside like there aren't 
> many volunteers to the project in general. Therefore I don't think 
> it makes sense to ensure any paid work is "unsexy", frankly all work 
> is much needed as far as I can see.
Yes work is definitely needed. I just wanted to keep that option in the
discussion as some people might have interesting ideas, and also not
orient too much the discussion in the directions that I have in mind.

References:
-----------
[1]https://www.gnu.org/distros/free-system-distribution-guidelines.html

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20190116/c7b0a76d/attachment.asc>