[Replicant] Replicant status and report of the 37C3 and FOSDEM 2024 conferences
dllud
dllud at riseup.net
Fri Mar 1 18:43:59 UTC 2024
Replicant current status:
=========================
The last Replicant release is still based on Android 6.0.
In the previous years, a lot of work was done to make the Galaxy SIII
(GT-I9300) usable with an upstream kernel, both on graphics and on the
modem.
While working on this report we also found that the removal of 3G
networks was more a serious problem than we originally understood.
As we understand from [the Wikipedia article on
2G](https://en.wikipedia.org/wiki/2G#Past_2G_networks), GSM networks
are also being removed in Europe as well (where most Replicant users
probably reside). If somehow we understood it wrong please
contact us on the Replicant mailing list as this has big implications
for Replicant.
This means that none of the currently supported devices will continue
to work on non-community networks in most areas of the world.
About a year ago, the current Replicant maintainer talked with
someone that knows well European regulations and that person told him
that there was no chance to stop 3G from being removed (for instance
through legal activism) due to the low number of users still using
3G. Since we didn't ask about GSM at the time, we have no idea if that
can be blocked or not or how much effort that requires.
In any case it means that the only way forward for Replicant is to
make sure it (also) supports devices that work on 4G networks.
Furthermore such devices should also have VoLTE (Voice over 4G
networks) ; otherwise, although they would be able to get Internet over
4G networks, they could not to make regular calls or send SMS.
Unfortunately even the Galaxy SIII 4G (GT-I9305) which is a Galaxy
SIII (GT-I9300) with a different modem doesn't support VoLTE. So we
cannot reuse most of the Replicant work we did.
Even if in some areas of the world (like some European countries), the
devices currently supported will continue to work for very few years,
and there was a big amount of work done to make these devices
usable with more recent Android versions, a lot more work is needed to
make that work usable daily (making power management work, debugging
complex issues, etc).
The majority of recent devices (like newer Samsung smartphones) have
too many freedom issues, making them unsuitable for Replicant.
Remains the PinePhone:
- The hardware already works under GNU/Linux.
- The battery life (in hours) is now almost good enough. Furthermore,
it is possible to buy an additional keyboard that has a builtin
battery to extend it more.
- There is an Android distribution (GloDroid) that supports the
PinePhone. It has some usability issues that need to be fixed: modem
disappearing on some models, no cellular data, no modem isolation,
etc.
The PinePhone Pro and Librem 5 could also be supported but they are
not high priority right now due to incomplete power management
(PinePhone Pro) and high cost (Librem 5).
In light of this, the current Replicant maintainer applied for funding
through NLnet (again) to fix some of the PinePhone's issues and
support it in Replicant. This application was accepted but he ended up
being sidetracked by another project instead of working on that.
He got involved in what became GNU Boot and planned to have the
project in good state by the end of the last summer, in the hope
the work could be reused to ship a bootloader for the PinePhone
in the next Replicant version.
See the [GNU Boot 0.1 RC3
announcement](https://www.gnu.org/software/gnuboot/web/news/gnuboot-december-2023.html)
and the [NLnet funding
application](https://git.replicant.us/contrib/GNUtoo/documentation/documents/tree/NLnet/porting_replicant_to_android9)
for more details.
Unfortunately the work on GNU Boot took way longer than anticipated,
being unfinished yet. Because of that the work on the PinePhone didn't
even start.
In addition to that, the main Replicant maintainer was also demotivated
(he did a lot of work that turned out not to be that useful) and he
thought that the project was poorly managed by him. He was trying
to understand what went wrong and how to fix it. Going to the 37C3
to find help was part of the fixing plan.
Identified issues:
==================
Discussions between GNUtoo, dllud (both Replicant contributors) and
several people we met during the 37C3 or on the train going to it
converged to the same points and together we identified several
issues:
Replicant has not enough people:
--------------------------------
- A diversity of profiles helps solving issues and not be stuck. It
also helps keeping the motivation as different people are good in
different areas and thus people can more easily work on what they
are good at and like to work on.
- We cannot expect a single person to take care of the community,
help new contributors, handle project management, keep
relationships with other communities, keep track of what work is
getting done elsewhere to improve collaboration, manage the
infrastructure (servers) and modernize it a bit, and at the
same time work on the code towards new releases. So far the
current maintainer has been switching from a set of tasks to
another but that didn't really work out.
It's too difficult to contribute to Replicant:
----------------------------------------------
- It requires computers that are not commonly available among
people: to build Replicant you need a lot of free space (200+
GiB), a fast internet connection to download more than 50
GiB, 32 GiB of RAM or more (for recent Android versions),
and sometimes run specific versions of distributions.
- It requires specific hardware like a Galaxy SIII (GT-I9300).
People can't help with commonly available emulators or single
board computers.
- There is extensive documentation but it's scattered around.
Documentation is also lacking for the tasks that are the most
important for Replicant (porting Replicant to newer Android
versions). Though we can also have people helping new contributors
again to compensate for documentation issues.
- We have a list of tasks and required skills for them
but we lack information about the importance of the tasks. We also
need to organize a bit how to assign tasks to people according to
their skills and will. We were also advised to break the important
tasks in more details.
Plan forwards:
==============
Very short terms plans:
-----------------------
- Write this report: As we were not always discussing with the same
people at the conference this should help us share information
between ourselves and also with all the people that helped
Replicant at the conference, to better organize the next steps.
- Setup a Replicant meeting online at a fixed time, on IRC/Big blue
button/Jitsi/Mumble. If new people come we would do a short
introduction and people would present themselves (especially what
they are interested in).
- Re-run the call for the Community Manager. We will run almost the
same call as before so the work will be less than last time. We
will be looking for a candidate that can do a subset of the tasks
in the call. As we were told multiple times that "Community
Manager" was not describing the job well, we are also looking for
a better term but so far no one found one that would feel right.
- Amend the NLnet proposal to include GNU Boot work as well to
solve our dilemma.
Medium term plans:
------------------
- Find a way to get a build server. A KGPE-D16 would be a good
idea. The FSF can probably buy it and host it for us.
- Work on the PinePhone (and on GNU Boot as well).
Long term plans:
----------------
While discussing with NLnet we were also told that it might be useful
to collaborate more with DivestOS as part of our goals are
similar. So we will need to evaluate again if there is enough
proximity in our code to collaborate.
In the past people from DivestOS were really helpful as they found
nonfree software inside Replicant and reported it to us.
Apart from that we don't have long term plans yet. Once we have a
Replicant release that supports the PinePhone, we will need to decide
where to go next.
For instance we could support more devices, reduce the amount of work
for adding support for newer Android versions, reduce the differences
between GNU/Linux and Android, or simply keep Replicant up to date by
supporting more recent Android versions with minimal work.
Right now we also didn't spend much of the Replicant money and beside
paying for a "Community Manager" we don't have precise plans yet.
We have about $200 000 and so far we relied on funding from NLnet to
bring Replicant back on track as it was easier not to mess up this
way.
Money goes away fast and spending it all in the wrong direction would
prevent Replicant from using it to become more sustainable. Very few
projects have an opportunity to use money to grow or achieve more.
Instead most of the ones that want to grow and become (bigger)
non-profits are stuck in a chicken and egg issue as they need more
money (that they don't have) to achieve more, which in turn leads
to a greater need for donations.
As such, getting the project back on track before even starting to
evaluate how to use the money to do big changes to the project seems
a good idea, as many projects were destroyed after getting too
much money and failing to properly use it.
Other advices for medium/long term:
-----------------------------------
- One person also told us that businesses have interesting
methodologies like "tracer bullets" in Agile methodology, or
"Business model canvas" or some emotional approaches to tasks that
might be worth looking at as they can work for non-commercial
projects as well and can be adapted to a wide variety of cases.
- One of the people we talked to insisted on the importance of
finding a good team and finding ways to divide tasks between
people. For that person it was also important to find people that
could work well together and that agreed on the same goal (to
avoid infightings).
- We could also delegate more sysadmin work to the FSF: It would
require less time from our side without compromising on freedom and
with minimal extra work for the FSF sysadmins if we don't require
custom things.
- We were also warned that delegating tasks among ourselves still
require time to organize. According to that person, in many cases
if a person delegates a task, only 50% of the time is saved.
Other area of work:
===================
Android SDK:
------------
The main advantage of Replicant over other GNU/Linux distributions
certified by the FSF is that it can run Android applications, but that
is only relevant if there are 100% free software Android applications.
Somewhat recently we found out that it was no longer possible to know
if Android applications shipped by F-Droid are really free, as F-Droid
now uses the nonfree Google SDK to build the applications. As such we
don't know if they build with another SDK on FSF certified GNU/Linux
distributions. We want to help fix that to make sure the solution
really suits our needs.
If there were fully free drop-in replacement SDKs that also build on
a 100% free distributions, that issue could be fixed for both F-Droid
and Replicant. F-Droid may have further requirements as they probably
have higher security demands than Replicant. For instance, they
probably won't like to depend on the (free software) binaries shipped
in the SDK source code that are used to build it, and would rather
build everything from source.
In the times of Replicant 4.2 (based on Android 4.2) Replicant
produced its own SDK. After that several GNU/Linux distributions
(Debian and some Debian derivatives) started shipping a fully free SDK
for Android 6.0 so Replicant stopped producing newer SDKs.
Nowadays Debian and PureOS still package an Android 6.0 SDK but don't
support more recent versions of Android. They also don't support the
NDK that supports languages like C. F-Droid probably used these SDKs
for a while, specially because they are completely built from source
from well known distribution(s), but many Android applications don't
build anymore with these old SDKs.
After that, free SDKs for various Android versions started being
released at https://android-rebuilds.beuc.net, but the main author of
this work at some point moved on.
After that several people tried to continue that work somehow and
published source code that can build SDKs but none published the SDK
binaries.
In the GNU 40 conference in Switzerland, the current Replicant
maintainer met the person behind SDK rebuilds (beuc.net) and also
someone interested in giving resources (like server space) to build an
SDK.
In the 37C3 we met additional people:
- Starfish, that wrote potentially 100% free Android applications and
that also publishes source code to build a free Android SDK. His
applications build with this free SDK.
Starfish doesn't publish binaries in order to avoid dealing with
license compliance in case something is wrong in the SDK binaries.
Replicant is happy to do that.
Starfish can also accept contributions and bug reports for
supporting FSF certified GNU/Linux distributions and for removing
nonfree software from the SDK if any if found.
As a bonus we also reviewed the applications that Starfish wrote
so if the SDK works on 100% free distributions we'll also have 100%
free applications to promote to people without any freedom caveats.
- Another person (wizzard) jumped in to automatize the builds, making
them run unattended on each new release.
So thanks to all these people everything is now in motion to get the
SDK problem fixed once for good and in a better way than before: one
that makes sure people can actually build Android applications with
100% free software.
Conferences:
============
At the 37C3 we managed to understand Replicant issues and a way
forward probably because we started discussing the project issues in
advance, which allowed just enough understanding to be able to ask for
help. If we didn't do that we probably would not have managed to get
help that is that useful.
37C3 talks and interesting people:
----------------------------------
While we (GNUtoo, dllud, and the people that helped us) did a lot at
the congress (and even too much since we missed our own lightning
talk due to too much cognitive load) at the end we managed to
achieve the most important goal: finding a path forward for Replicant.
Alongside our main goal of putting the project back on track, we
found time to host a variety of talks and events:
- We had an [official Replicant
assembly](https://events.ccc.de/congress/2023/hub/en/assembly/replicant/)
where people could meet us.
- We did [a presentation named Smartphones freedom status in
2023](https://events.ccc.de/congress/2023/hub/en/event/smartphones-freedom-status-in-2023/)
which looked at smartphone hardware and operating systems available
in 2023. It wasn't recorded. The slides are available as
[PDF](https://ftp2.osuosl.org/pub/replicant/conferences/37c3/Smartphones_freedom_status_2023.pdf)
and [source
code](https://git.replicant.us/contrib/GNUtoo/documentation/presentations/tree/37c3/Smartphones_freedom_status_2023?id=628319ae80491328b85958159e4511156fe20bc9).
At the end of the presentation, after the questions, we also got
some feedback:
- We were told that there are more applications for GNU/Linux that
work on smartphones than what we assumed. They are referenced in
https://linuxphoneapps.org and they also list applications
available in [PureOS
landing](https://linuxphoneapps.org/packaged-in/pureos-landing/)
(a rolling release version of PureOS) and
[Guix](https://linuxphoneapps.org/packaged-in/gnuguix/). Still
they probably have less applications available than on F-Droid but
things are progressing in the right direction.
- We also did a talk [presenting the Replicant as part of the Critical
Decentralization
Cluster](https://events.ccc.de/congress/2023/hub/en/event/cdc-critical-decentralization-cluster-cluster-reco/).
Unfortunately it wasn't recorded due to a technical issue, but we
[re-did it again the day after on a longer
format](https://events.ccc.de/congress/2023/hub/en/event/introduction-to-replicant/).
The slides [source
code](https://git.replicant.us/contrib/GNUtoo/documentation/presentations/tree/37c3/Replicant_introduction?id=628319ae80491328b85958159e4511156fe20bc9)
and
[PDF](https://ftp2.osuosl.org/pub/replicant/conferences/37c3/Replicant_introduction.pdf)
are available.
- We did a [presentation on the status of
Replicant](https://events.ccc.de/congress/2023/hub/en/event/replicant-struggle-past-and-present-successes-and-/).
It wasn't recorded so if you want to know what was said, [the slides
are
available](https://git.replicant.us/contrib/GNUtoo/documentation/presentations/tree/37c3/Replicant_struggle/presentation.pdf?id=628319ae80491328b85958159e4511156fe20bc9),
but you also need to read the
[presentation.txt](https://git.replicant.us/contrib/GNUtoo/documentation/presentations/tree/37c3/Replicant_struggle/presentation.txt?id=628319ae80491328b85958159e4511156fe20bc9)
to understand it.
- As a follow up to the presentation on the status of Replicant, we
also had [a meetup on the last
day](https://events.ccc.de/congress/2023/hub/en/event/replicant-meetup/)
where we had discussions with the people attending the talk.
- We met someone repurposing smartphones who told us that on some
Samsung smartphones/tablets, erasing the PARAM partition (with
dd if=/dev/zero) sometimes removes restrictions that prevent
the phone from booting custom distributions.
- Among those helping us, there was someone interested in using
Replicant for education. The most problematic issue found is
that the current requirements to work on Replicant are too
much for students. Supporting single board computers or emulators
would be a first step to help here. In general this would help
finding new contributors.
OFFDEM / FOSDEM 2024:
---------------------
The main maintainer of Replicant had already planned to go to an event
of [OFFDEM](https://oxygen.offdem.net/pub/offdem-ourstory) (an
alternative conference to FOSDEM) on Friday night, and also to FOSDEM
2024 on Saturday and Sunday. Train tickets were already bought before
Replicant took the decision to go to the 37C3, so he kept the plan.
As expected it was not as useful as the 37C3 for Replicant (it was way
more useful for GNU Boot) but still some interesting things happened:
- He met Hans-Christoph Steiner from F-Droid and explained the status
on having a fully free Android SDK. He detailed our work to provide
binaries by setting up an automated build system that reuses
[the maintained scripts to build the
SDK](https://codeberg.org/Starfish/SDK-Rebuilds)
and that runs on a FSF certified distribution (Trisquel) to make
this solution also work for Replicant.
- He was introduced to people working on CalyxOS by Michiel from
NLnet.
Before that he thought that CalyxOS was deeply problematic because
even if on paper CalyxOS had the same freedoms as LineageOS, its
security system removed users control of the devices (users don't
have root, etc) and didn't have access to their data.
But in reality CalyxOS [uses
SeedVault](https://calyxinstitute.org/projects/seedvault-encrypted-backup-for-android),
a backup application that enables users to backup their data and
restore it on any other distribution that may not have the same
security model. SeedVault is also used by most Android distributions.
It is therefore a good idea to see how it can be integrated into
Replicant, as it seems to be made with user's empowerment in mind. It
can backup data (encrypted) to an USB key, so users don't need a
server or external services.
In addition he was told by a CalyxOS contributor that it is
relatively simple for users to build CalyxOS with their own keys,
and so be in full control of the device.
He was also told that newer Android versions don't need [F-Droid
privileged extension](https://gitlab.com/fdroid/privileged-extension)
anymore due to the inclusion of an API for stores inside recent
Android versions (thanks to some European regulations).
- He met someone who is working on understanding the European
regulations that aim to standardize digital identity
papers and the way to store it. He already met that person at the
37C3 but this time there was more understanding and more time to
discuss the issue more in depth. The regulation has requirements for
smartphones so it will most likely affect smartphones distributions
that use free software drivers (like Replicant, various GNU/Linux
distributions, etc.). If done wrong, it would prevent free
software users from storing their identity papers in their
smartphones with free software (for instance because it could be
stored "securely" in areas of the phone inaccessible to users and
free software). One of the issue is that this person looks for help
to understand the technical parts, and also for some associations to
help in the fight to modify the laws to fit free software. Since
Replicant has very little time to look at this now, he referred her
to the Osmocom project that already analyzes somewhat similar
designs like eSIM.
- He also met with Tiberiu from Technoethical, a shop that sells FSF
certified hardware and Replicant compatible smartphones (that aren't
certified by the FSF due to nonfree bootloaders and other
issues). Technoethical will be negatively affected by Replicant's
decision to drop support for the current Samsung phones in future
versions, as PinePhone will become the major focus.
- The main maintainer of Replicant also met with Paul
Kocialkowski. Before that meeting he thought that on GNU/Linux the
[eg25-manager program](https://gitlab.com/mobian1/eg25-manager) for
the PinePhone only did simple things like setting up udev rules and
had simple hacks to make the modem work fine. He thought that
all stability issues were to be handled by Modem Manager.
However the EC 25 Manager may also be monitoring the modem
and restarting it when it crashes. This could explain modem
stability issues with Android/GloDroid on PinePhones with 3GiB of
RAM. The fix may be to port/reimplement that feature to make this
model usable.
More information about the Replicant
mailing list