[Dev] libreboot-utils, moving forward.

[Denis 'GNUtoo' Carikli]

On Sat, 24 Dec 2022 11:55:34 -0500
bill-auger <bill-auger at peers.community> wrote:

> On Sun, 18 Dec 2022 01:42:14 +0100 Denis wrote:
> > Since that nonfree
> > software will not be removed anymore, we won't be able to use the
> > newer tarballs.
> > 
> > I'm already in discussion with other people to continue a libre
> > version of Libreboot. 
> 
> that could be a mksource PKGBUILD - parabola could provide a
> pre-cleaned source-ball; but those patches would be carried and
> maintained forever, so that solution is essentially soft-forking
> libreboot
Why not continuing to maintain our FSDG compliant version of Libreboot
instead?

I'm already in discussion with people to do exactly that. It might take
a bit of time since we're setting up infrastructure and so on (some
stuff is still missing, we need a space for releases for instance).

We'll announce it officially as soon as we can accept and review
contributions.

The (old) Libreboot code works already. And it enables cross
distribution collaboration too, so I don't see why we need to reinvent
the wheel here.

Leah's Libreboot won't do anymore the deblob work for us, and
distributions need deblobbed Coreboot tarballs. So instead of doing the
deblob inside the distribution, I think it makes more sense to do it in
an upstream project to have to do it only once.

This works well for projects like linux-libre, and the work on
distributions side is minimal.

For instance for u-boot I'm not going to go fix every FSDG compliant
distribution out there but I can provide something easy to reuse,
especially when most of the work is done already.

If recent coreboot deblobbed tarballs are needed, we could do something
similar than with u-boot-libre and add a script (in libreboot) that
deblobs each coreboot releases as well and we'd release the script, the
blob list and cleaned up tarballs.

This way this deblob code could also be reused by our FSDG compliant
Libreboot version and everyone will benefit without having to reinvent
the wheel for each distribution.

And if new files containing blobs need to be deleted, we could simply
add them to our version of libreboot, and do a release and just have
the distribution bump the package revisions.

This system is already in place for u-boot in Parabola, so we have a
real example that we can look at.

> > for some of the boards it supported before like the KGPE D16.
> 
> ok, now i am more convinced that the new libreboot direction is
> not well aligned with parabola 
We don't need to follow Leah's decisions, we can simply maintain our
own version of Libreboot. I'm in discussion with people to do exactly
that. So it's just a matter of time until we can announce things and
start accepting contributions.

> - AFAIK, the D8 and D16 are the
> only powerful servers which can boot the original no-blobs
> libreboot; and these are libreboot's only significant targets
> besides thinkpads - if such important targets are no longer
> supported, i would be inclined to put the entire project into
> maintenance-mode, rather than shifting the meaning of "libre" to
> accommodate the ever-worsening lost cause that is x86 - does
> libreboot support any other than x86? - maybe it's day has
> passed, and it is just not needed any more
We have plans to continue supporting all of these. We might need help
with testing though.

> put another way, it just seems that x86 precludes "moving
> forward" in a libre direction - to me, "moving forward" means
> looking away from x86 toward ARM, RISCV, and POWER9 - at least
> those arches are trending toward libre-friendly, rather than away
We need both: we need more people working towards ARM (32 and 64bit),
powerpc 64bit little endian and RISCV 64bit.

But we also need to continue supporting x86 computers at least until
the alternatives manage to be almost as usable as x86 computers.

Right now there is no drop-in replacement for the Libreboot
compatible Thinkpads. All the non-x86 laptops I've reviewed could still
be used by some users but there is usually some drawbacks that prevents
more general usage.

For instance:
- The novena is pretty close: it could have 4GiB of RAM, it has a SATA
  port and an mPCIe port, so users could add big storage and ath9k
  compatible WiFi cards. 3 versions were produced:
  - One was a single board computer (SBC)
  - One was a transportable computer with a battery, but without any
    integrated keyboard
  - The third one costed a fortune (maybe it was close to 5000$ at the
    time if I remember well) and the integrated keyboard is wireless
    (not great for security or privacy).
  And this laptop isn't produced anymore.

- The olimex TERES-I has only 2GiB of RAM, and the internal WiFi /
  Bluetooth don't work with free software. So you need to use ath9k_htc
  compatible cards that are big or have poor range and don't support
  5GHz. And ath9k compatible cards don't have these issues but they
  don't work on the TERES-I because there is no mPCIe port.
  The TERES-I also has no SATA so you end up having to use a 16GiB
  internal eMMC and a microSD card. It at least boot with free software
  and most of the hardware (beside WiFi/Bluetooth) works. The Pinebook
  is probably somewhat similar.

- The Pinebook PRO also boots with free software, and it has 4GiB of
  RAM. It also supports NVMe SSDs but this means that the firmware of
  these SSD probably have access to your RAM (through DMA) and can
  therefor take control of the whole system. If you don't use that
  you end up having to use microSD and the internal eMMC again.
  Though you could in theory use the MVNe port with an ath9k instead
  with an adapter, but I'm unsure if you can buy that adapter or if you
  need to make it yourself. The connector for the external display
  also doesn't work with free software, so you can't use that laptop to
  do presentations.

- The mnt reform is unusable right now as it requires nonfree software
  to boot. FSDG distribution won't ship that software and AFAIK nobody
  is working to reverse engineer it.

- There was also a project to create a powerPC (64bit little endian)
  netbook, but it will rely on an external GPU that requires nonfree
  software to work. And so far I know no external GPUs that work with
  free software (ATI/AMD and Nvidia GPUs all require nonfree software
  that is run by the Linux kernel: they have nonfree bytecode in the
  video BIOS that is picked up and run by the nouveau, radeon, or
  amdgpu drivers). So unless someone designs a display controller and
  manage to get it to people, that won't work for laptop usage.

In addition, many people also use the tor-browser without installing any
addons (the tor-browser points to an addon repository which also has
nonfree software), so this is lacking for ARM/PowerPC and RISCV on
GNU/Linux. Replicant (and probably LibreCMC and proteanos) require x86
computers to build them.

So we still need something that works for people in the meantime, so we
have to keep supporting x86 computers.

Using ARM/PowerPC 64bit little endian/RISCV 64bit computers for home
servers for instance is probably much more easy. So we could try to
work on that and get the software on pair with x86. If good WiFi cards
aren't available it's also possible to use a libreCMC compatible WiFi
access point in bridge mode to add WiFi access point to a server. Some
use cases (virtualization) might not be on pair with x86 yet (due to
software support, the lack of RAM, etc), but containers might work
though (if there is enough RAM).

For people that don't use the tor-browser, it might also be possible
to use some of these computers as desktop computers and see what use
cases are covered and what uses cases are not covered. There is a big
unknown until we try for real and report our success / failures.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20221225/68910ee8/attachment.sig>