[Replicant] Late report from FOSDEM 2020

dllud dllud at riseup.net
Sat Jul 4 12:06:23 UTC 2020


On the 1st and 2nd of February 2020, 4 Replicant contributors
(FilBerg, GNUtoo, GrimKriegor and dllud) attended FOSDEM
2020[1] in Brussels.

FOSDEM (Free and Open source Software Developers' European
Meeting) is an annual conference organized by volunteers, to enable
users and contributors to meet and promote the widespread use of free
and open source software. This helps communities take decisions and
also enables various communities and people to collaborate together.

Part of this comes from FOSDEM allowing projects to book rooms in
order to have meetings and presentations (dubbed as a BoF, Birds of a
Feather). Replicant contributors held such a BoF, and also gave a talk
at another room and wandered around the exhibition's rooms talking to
people at the stands of relevant projects.

As it is a conference, the FOSDEM also features talks by various
members and contributors of the free software and open source
communities which range across many different projects and areas.
Listening to the talks (which are often recorded as well) is a way
to get the latest news of what's happening in the free software
world.

This is a (late, sorry for that) report with the relevant information
that Replicant contributors leaned during the event, alongside with a
summary of the discussions that took place during the BoF.
This report is published both in the blog[2] and mailing list.
Comments are gladly welcomed on both mediums.

+----------------------+
| Before Replicant BoF |
+----------------------+

Technoethical:
--------------
Technoethical is a store that sells devices pre-installed with
official versions of Replicant and also Replicant merchandise. It is
featured at Replicant's website[3] and donates a percentage of its
sales to Replicant.
We went to the Technoethical stand to discuss the idea of only
requiring a percentage of the sales for bigger companies, which
wouldn't include Technoethical.
According to Tiberiu from Technoethical, Technoethical didn't agree to
formally give any percentages of the sales to Replicant, but they
instead do it voluntarily.

Wikidata:
---------
We had a discussion with someone involved in Wikidata about how to
describe hardware like smartphones in Wikidata.

For instance there is an entry for Replicant in Wikidata[4], and we
want to be able to more precisely express that a given software, like
Replicant 6.0 0004, or the Lima Linux driver, is compatible with a
given smartphone or GPU.

Right now this seems to be done through the Platform property [5].
Unfortunately, this property by itself cannot tell precisely which
version of Replicant is compatible with say the Galaxy Nexus
(GT-I9250). We were told to look into the qualifier to see if we can
find a way to express that.

After looking at it we found that it's possible to add a platform
qualifier for a given version, for instance to tell that Replicant 6.0
is compatible with the Galaxy SII (GT-I9100). However, after this, it
is not possible to add an extra layer of qualifiers to tell for
instance that the Galaxy SIII 4G (GT-I9305) is compatible with
Replicant 6.0 except for its modem.

The goal here is to be able to use Wikidata as a database for storing
information about hardware and software. This way we could reuse that
information easily in various tools and/or in MediaWiki after having
migrated to it. We already have a very rough tool to experiment with
that and print some information about Replicant versions and the
devices they support.

+---------------+
| Replicant BoF |
+---------------+
Like last year[6] we also had a Replicant BoF this year[7].

Organization:
-------------
This year we improved the organization of the Replicant BoF:
- Most of the people in the room seemed really engaged and interested
  in it, whereas last year we got the impressions that people were
  less engaged and interested.
- While things were more organized than last year we still need to
  improve on it. For instance we lacked a precise schedule for the
  BoF in order to properly cover all the topics we needed to.
  The consequence is that we usually try to rush at the end in order
  to cover some topics we didn't have covered yet.
- We also had the ability to remotely listen to the BoF through
  Mumble and participate through IRC.
  At the beginning we tried a setup that was too complex, with
  speakers, to enable remote participants to speak. This setup
  took too much time, so when enough people were in the room,
  we started without that and fell back on IRC for participation
  instead. As we were late to start, and were rushing to make the
  more complex setup work, we also forgot to record the meeting.
- Properly organizing a BoF is not that easy as we typically are short
  on time and also need to organize many other things in parallel such
  as the talks we give in other rooms.
- For next year, we need to decide on weather or not we could fund
  or reimburse travel costs for someone from the Replicant community,
  like Kurtis Hanna, that has a deep enough knowledge of what is
  going on in Replicant, to help us with the organization of the
  BoF.

Build system:
-------------
During the BoF, we did a quick presentation of the issues we were
having with the Android build system. More details on the issues are
available on the "Android’s build system is messier than your
distro’s" talk[8] that was presented at 36C3.

GeckoView:
----------
We also did a quick presentation of the freedom issues we were having
with WebView. As with the build system, more details are also
available in a presentation ("The Chromium mess meets Android") that was
held at 36C3[9].

We then got questions and ideas on how to solve that issue.

One of the ideas was to go for the lowest hanging fruit and implement
the easiest part of the WebView API with GeckoView, which should
suffice for some applications.

Once this is done we would still have the problem of making the
F-Droid applications use it: the application developers will probably
not include GeckoView in their applications as it would increase the
size of the package by around 20M (which is a lot).

But even if they do, it would still be an issue as each package using
WebView (and there are many) would have its own GeckoView, which would
probably increase RAM consumption.

There are kernel features like CONFIG_KSM which reduce the RAM usage
by finding duplicate regions and making the duplicated pages point to
the same region until the data is modified. However, this may not be a
proper solution, especially if the GeckoView builds shipped with each
app are not exactly the same. It may also increase CPU consumption as
CONFIG_KSM has to scan the RAM for duplicated pages.

Several solutions were proposed by Replicant contributors and people
attending the BoF:
- Make Replicant ship a GeckoView that is ABI compatible with WebView
  (even if not all of the WebView is implemented).
- Use F-Droid to build and distribute GeckoView.
- Develop software that would automatically recompile all the
  F-Droid applications that link against WebView to link against
  GeckoView instead, and automatically publish the result in a
  dedicated F-Droid repository.
- Applications could potentially be tagged with supporting or not
  supporting a given incomplete WebView implementation implemented
  through GeckoView.

Upstream:
---------
Replicant only wants to supports devices that reduce the amount of
harm for users freedom, privacy and security. For instance all devices
supported by Replicant 6.0 and onward have some form of modem
isolation.

However some people might still want to support devices that attack
users freedom, privacy, and security more than the ones already
supported by the current Replicant release. So we explained that
while such devices could not be supported by Replicant, the Replicant
project is open to collaboration with other projects like LineageOS
to add support for such devices.

This is relevant to Replicant because Replicant 9 uses a Linux kernel
that has very few patches on top of the upstream Linux.

So while Replicant 9 is not ready yet, when it will be, most of the
Replicant 9 code will probably be reused to support smartphones and
tablets that have good support in upstream Linux.
So, even if for smartphones with different modems, more work would be
needed to support the modem, there will probably be some people
interested in reusing the Replicant 9 code.

This means that we would need to work with other upstreams to find the
best ways to deal with it and share the maintenance of the code.
Unfortunately there weren't any contributors from other Android
distribution in the room.

Galaxy SIII (GT-I9300), Replicant 9 and LineageOS:
----------------------------------------------------
As ChronoMonochrome is also working on porting the Galaxy SIII to
LineageOS, we collaborated together when it was possible, as we were
both trying different approaches.

On Replicant 9 we were focusing more on the 2D graphics, and on
the modem, which doesn't work yet with LineageOS.

Once we have something usable on Replicant 9, it would also be very
interesting to find time to work on upstreaming the modem driver as
well:
- In several cases the kernel maintainers refused patches for drivers
  lacking free software userspace for using them. As Replicant has a
  free software implementation, it shouldn't be a problem.
- Similar modems are already supported by the Linux kernel, like the
  N900 modem, but the kernel interface is different from the one
  exposed by the kernel shipped by Samsung.
- As LineageOS functional requirements[10] to support a device are
  more strict than Replicant, if the Galaxy SIII modem driver is
  merged upstream, and LineageOs wants to use libsamsung-ipc[11] (and
  libsamsung-ril[12]) to use that driver, they would probably have
  some interest in helping to complete the libsamsung-ipc
  implementation as well.

F-Droid:
--------
We have already removed F-Droid from Replicant 6.0 after the 0003
version. This is due to the F-Droid repository not being compliant
with the Free System Distributions Guidelines, because of applications
like Yalp.

If there were no means for users to collaborate on workarounds, each
user would need to review by themselves each application they are
considering to install.

So we created the F-DroidAndApplications wiki page[13] to share the
work on reviewing F-Droid applications that meet or don't meet the
Free System Distributions Guidelines.

We started reviewing some applications. Unfortunately, even when the
source code should be fully free, we are not sure if the resulting
builds meet the guidelines, as we would need to make sure that it's
possible to compile the same application with a distribution that
meets the FSDG guidelines.

We need to look more into it and/or to write to the licensing team at
the FSF.

Documentation and migration to MediaWiki:
-----------------------------------------
We briefly talked about the rationale of migrating the wiki from
Redmine to MediaWiki. The main advantage is that it will avoid
duplication of information. For instance, the fact that the Galaxy
SIII has a MAX6673 chip is mentioned in many different wiki pages such
as:
- https://redmine.replicant.us/projects/replicant/wiki/GalaxyS3I9300
- https://redmine.replicant.us/projects/replicant/wiki/WifiAdapter
- https://redmine.replicant.us/projects/replicant/wiki/WiFi
- https://redmine.replicant.us/projects/replicant/wiki/UART

This happens because that chip is involved in many different things,
ranging from power management to managing the switch behind the USB
connector which enables to get access to the serial port.

It is therefore relevant to know about that chip in many different
contexts.

MediaWiki has ways to avoid the duplication of some information
through templates, and it's also possible to interface it with
Wikidata in various ways.

Someone mentioned that Sphinx handles such requirements. However, as
not everyone that contributes to the wiki knows how to program, and as
the contributions of such people are quite substantial (many edits,
creation of pages, etc), and that we do want to enable people not
knowing programming to edit the wiki, we will probably consider
switching to MediaWiki instead of tools like Sphinx.

Release schemes:
-----------------
Someone pointed out that upstream Android continuously gets security
updates. To keep up with that, we would need to do Replicant 9
releases very often.

While some people pointed issues with rebasing our work, it's probably
still achievable to do that, as porting our work forward from
Android 9 to the next Android versions is supposed to be easier.

Someone also pointed out that, for a given Android version, LineageOS
was backporting security fixes longer than the Android Open Source
Project (AOSP).

This information made us reconsider some design choices in Replicant:
once Replicant 9 has been released, the fact that LineageOS doesn't
have stable tags for releases becomes less relevant as we will need to
find ways to rebase and release often, in order to have the latest
security fixes.

Vulkan:
-------
Someone mentioned that the Vulkan graphics API will become mandatory
after Android 10. This would mean that the graphics stack we're
developing for Replicant 9 would no longer suffice.
Both Lima, the free software driver for the Mali GPU present on the
Galaxy SIII (GT-I9300), and llvmpipe, the software rasterizer planned to
be used as fallback on all other devices, only support OpenGL ES.

A possible workaround would be switching the fallback software
rasterizer from llvmpipe to SwiftShader, or using it just for apps
that need Vulkan support. We are actively making sure that SwiftShader
works on Replicant 9, therefore this should be doable without much
effort.

Note: someone suggested using a translation layer that runs Vulkan on
top of OpenGL ES, but that does not exist and probably never will.
Vulkan is a lower-level API than OpenGL[14], with finer-grained
control of the GPU memory and likes, making it really hard to
implement OpenGL on top of it.

A nice tip we got is to keep using a compositor (SurfaceFlinger) that
works with OpenGL ES. Current SurfaceFlinger still doesn't have Vulkan
support. Acceleration is still done through OpenGL ES or an hardware
composer. As such, compositor performance and compatibility won't be
an issue for the time being.

+-------------------------+
| After the Replicant BoF |
+-------------------------+

Replicant contact address:
--------------------------
We found that Fil Bergamo, who is part of the Replicant Steering
Committee, didn't receive emails from the Replicant contact address.

We need to setup a new email infrastructure in order to properly
address this issue. Currently the contact address is hosted at PaulK's
personal email server. Paul no longer has time to maintain it and thus
we must transition to a new server, hosted in a VM at the FSF servers,
that can be administered by several Replicant contributors, in order
to avoid a single point of failure.

Legal advice:
-------------
The FSFE is helping NLnet by giving legal advice to the people being
funded by NLnet to work on free software.

After the Replicant BoF, we met Lucas Lasota from the FSFE who
offered legal advice, probably through the ifrOSS institute, to the
people being funded by NLnet to work on Replicant (or the Replicant
project at large?).

The Replicant project is already getting legal advice through the FSF,
and the FSF also has a very big expertise on compliance with
certifications like the Free Software Distribution Guidelines, but the
FSFE legal team and/or ifrOSS legal team probably also have some very
interesting knowledge about European law.

For instance Till Jaeger who is/was involved in the ifrOSS institute
made a very interesting talk[15] years ago on what constituted
derivative work under the European laws and directives.

Necuno:
-------
After the the Replicant BoF, we discussed a bit with someone from
Necuno. They were supposed to make a device that could be used with
only free software. The hardware only had the following issues:
- On the I.MX6 System-On-a-Chip they chose, the firmware for the
  audio/video decoding offload is nonfree, but in many cases that can
  simply be ignored as that kind of thing is done by default on the
  main CPU.
- The I.MX6 DMA engine probably had a nonfree firmware but it was
  completely optional, as the Linux kernel knows how to use the
  builtin DMA engine ROM instead.

So the device would have been completely usable with fully free
software. They also stated in several places on their website that
it would have been possible to run fully free software on the device.

This was also made possible because the device wasn't a smartphone and
would not have any modem or WiFi chip.

But they are now are planning to add a WiFi chip, and to our
knowledge, all the WiFi chips made for smartphones and tablets
require a nonfree firmware.

While Replicant is not redistributing any nonfree software, it still
loads the modem firmware into the modem. In addition, all the
devices currently supported have many more freedom issues, from
forcing users to run nonfree software at boot, to having their
location tracked by the network, at all times, with a precision of
10 or 20 meters.

In the long run, for the WiFi firmwares, it would be a good idea
to have people working to get free WiFi firmwares and really solve
the issue for good, instead of finding workarounds that don't solve
the problem.

In the mean time, the workarounds still have the benefit of making
clear what is free software and what is not; this clear separation
enables us to claim at the same time that Replicant itself is fully
free software while the devices it currently supports do not respect
users freedom, and do run nonfree software as well.

Necunos also told us that they had some underlying issues because
their devices would be "dual use" devices. This is related to the fact
that they are also targeting some markets like the Finish defense or
secret services, but we didn't understood what it meant practically
speaking.

NLnet and the Android build system:
-----------------------------------
We discussed with Michiel from NLnet the issues we were having with
the Android build system. He pointed again to us that NixOS is working
on being able to build Android components.

At some point we would need to look more into it as we want to mix
Android and GNU/Linux components together. If we want Replicant to
scale and be able to support more devices, it would be a good idea
to be able to reuse some GNU/Linux userspace components that make
hardware work, like oFono, BlueZ, etc. This would also allow us to
share more work with GNU/Linux.

There are more details on the Replicant wiki about issues GNU/Linux
distributions are having for packaging Android components[16] like
adb, which depend on the Android build system and libc.

Maemo Leste:
------------
On the last day we also met someone from Maemo Leste. At first when
hearing of Maemo Leste, we feared that nonfree components from Maemo
would be reused, as Maemo had a lot of nonfree components. However,
according to the people we met, only the free software ones were
reused. Still, nonfree software not coming from Maemo, like the
nonfree WiFi firmwares or nonfree GPU drivers for some phones, were
still used.

We also saw Maemo Leste on a PinePhone. On this device, the graphics
stack was using the free software Lima driver and the graphics were
fast enough. We can't remember if Lima was stable enough for daily use
but it looks really promising at least, because the whole graphical
interface used it, and we saw no rendering artifacts while briefly
testing it.

GitLab:
-------
GitLab was first built upon a framework that did most of the work on
the server side, but at some point they switched to a framework that
does client-side rendering with JavaScript.

As we had an opportunity to talk with people from the GitLab team, we
asked them whether they would be open to accept patches that fix this.
They explained us that such would require to double the UI work for
everything, but that it might be possible to do server side rendering
with the same JavaScript that's used on the client. The issue is that
it cannot make requests from buttons like that, so in addition to the
page rendering that could happen through server-side JavaScript,
introspection could be used to rewrite the buttons.

Batteries report:
-----------------
In Paris (France), last year, batteries for phones compatible
with Replicant could easily be found in second hand shops, and
in a chain of shops specialized in replacement batteries.
But we got a more recent report that it was not the case in
similar shops in a smaller city.

+-------+
| Talks |
+-------+

Extending the lifetime of smartphones with Replicant:
-----------------------------------------------------
This talk was held at the Hardware Enablement devroom.

It quickly introduced Replicant and the smartphones ecosystem,
and then proceed to look at what affects smartphones' and tablets'
lifetime and how to increase it by making Replicant more sustainable.

There was also a small, satirical play in the middle this talk. Its
goal was to show how the current market trends in smartphone design
and construction severely impair those that look for privacy, software
freedom, and reduction of electronic waste.

Video and slides are available at the talk's page in FOSDEM's
website[17].

+-------+
| Extra |
+-------+

Fun:
----
Fil Bergamo started making a song[18] about Replicant.

Previous conferences:
---------------------
If you enjoyed reading this report, you may wish to take a look at the
reports from previous conferences that were (only) published on the
mailing list:
- 36C3[19]
- XDC 2019[20]

There's also a wiki page[21] that lists all talks about Replicant that
happened in several conferences throughout the years.

+------------+
| References |
+------------+
 [1] https://fosdem.org/2020/
 [2] https://blog.replicant.us/2020/07/late-report-from-fosdem-2020
 [3] https://www.replicant.us/supported-devices.php#stores
 [4] https://www.wikidata.org/wiki/Q7314062
 [5] https://www.wikidata.org/wiki/Property:P400
 [6] https://fosdem.org/2019/schedule/event/bof_replicant/
 [7] https://fosdem.org/2020/schedule/event/bof_replicant/
 [8]
https://redmine.replicant.us/projects/replicant/wiki/Presentations#Androids-build-system-is-messier-than-your-distros
 [9]
https://redmine.replicant.us/projects/replicant/wiki/Presentations#The-Chromium-mess-meets-Android
[10]
https://github.com/LineageOS/charter/blob/master/device-support-requirements.md
[11] https://redmine.replicant.us/projects/replicant/wiki/Libsamsung-ipc
[12] https://redmine.replicant.us/projects/replicant/wiki/Libsamsung-ril
[13]
https://redmine.replicant.us/projects/replicant/wiki/F-DroidAndApplications
[14] https://developer.nvidia.com/transitioning-opengl-vulkan
[15] http://faif.us/cast/2013/mar/26/0x39/
[16]
https://redmine.replicant.us/projects/replicant/wiki/Upstream#Tools-and-build-systems
[17] https://fosdem.org/2020/schedule/event/replicant
[18]
https://redmine.replicant.us/projects/replicant/wiki/Fun#Song-from-FOSDEM-2020
[19] https://lists.osuosl.org/pipermail/replicant/2020-January/002441.html
[20] https://lists.osuosl.org/pipermail/replicant/2019-October/002222.html
[21] https://redmine.replicant.us/projects/replicant/wiki/Presentations

---
GNUtoo and dllud

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20200704/3cb8719f/attachment-0001.asc>


More information about the Replicant mailing list