Group: Guix/Wishlist

From LibrePlanet
Jump to: navigation, search
(→‎Features: clarify small rootfs)
(Also add an "Other" section since guix has todos for instance)
Line 458: Line 458:
 
* Add a better way to deal with secrets or external files: Currently it's up to users to do the provisioning of secrets like VPN credential files. If they package it somehow they end up being in the store and being a security risk as any users could see them. Having to manually provision such files might work in some cases but it doesn't scale well as to do it right we'd need to make a provionning method that works for all the cases (all the different types of images, etc). A solution would be to add some extra option to guix to also include extra files or tarballs. This way the files would be added for all images types (docker, qcow2 system images, disk images, with guix system init, etc).
 
* Add a better way to deal with secrets or external files: Currently it's up to users to do the provisioning of secrets like VPN credential files. If they package it somehow they end up being in the store and being a security risk as any users could see them. Having to manually provision such files might work in some cases but it doesn't scale well as to do it right we'd need to make a provionning method that works for all the cases (all the different types of images, etc). A solution would be to add some extra option to guix to also include extra files or tarballs. This way the files would be added for all images types (docker, qcow2 system images, disk images, with guix system init, etc).
 
* Add generic ways to generate very small rootfs. For instance there is some support for initramfs already. Now that there is ppc64le support, if we can make images that fit into (128M?) of flash and that OpenBMC is packaged in Guix, it could probably completely support RYF computers like the Talos II. If we have a good enough abstraction like a target OS for instance, we could probably add the software we want in initramfs and/or in the BMC and configure them like a regular Guix system from the host computer. There is already support for managing VMs through a ganetti API in guix and there are also childhurds in Guix.
 
* Add generic ways to generate very small rootfs. For instance there is some support for initramfs already. Now that there is ppc64le support, if we can make images that fit into (128M?) of flash and that OpenBMC is packaged in Guix, it could probably completely support RYF computers like the Talos II. If we have a good enough abstraction like a target OS for instance, we could probably add the software we want in initramfs and/or in the BMC and configure them like a regular Guix system from the host computer. There is already support for managing VMs through a ganetti API in guix and there are also childhurds in Guix.
 +
 +
== Other ==
  
 
== TODO ==
 
== TODO ==

Revision as of 16:54, 11 September 2021

The below list contains software that users of GNU Guix would like to see packaged. If you are interested in contributing to Guix, please consider packaging something in this list while keeping in mind that some may have been listed because they are "difficult" or elusive. If the package you're interested in is already listed, feel free to either add a "(+1)" next to its name or increment the vote count, e.g. "(+1)" -> "(+2)", etc.

So Before adding a package to this list, please verify that it hasn't already been packaged.

In addition, Guix is a distribution that follows the Free System Distribution Guidelines (GNU FSDG) and as such not only it only has free software but these guidelines also have additional requirements (like for instance not steering users toward the installation of nonfree software, no Malware, etc).

So it would be a really good idea to point if the package is already packaged by either a Free GNU/Linux Distribution or a Free Non-GNU Distribution, or at least try to see if that software is fully free software and doesn't have any nonfree dependencies (like nonfree firmwares, libraries, other nonfree packages and so on) or if not indicate if it wasn't checked in order to prevent accidental inclusion of nonfree software in Guix (that could happen for instance if each party assumes that the other people checked while no one checked).

This page should be synced with Free software replacements recommended by the FSF.

Packages

Communication

Mail

Multimedia communication

Instant messaging client

Social networking

Matrix

Production

Editor

Graphics

Office

System

Backup

Booting

  • Support booting from pre-existing systemd-boot, i.e. "grub-install --no-nvram".

DEs & WMs

Fonts

Hardware

Input

Media Transfer Protocol

Shell

Tools

Wayland

X11

Programming

Version control

Programming languages

Clojure
Emacs
Guile
Haskell
Java
Perl
Python
Eiffel
Ada

Misc


Emulation

Live USB

Audio

Music

Video

Education

Feed Readers

Games

Network

Tor Browser

The Tor Browser has an issue that makes it incompatible with the Free System Distribution Guidelines (GNU FSDG): it is configured to use Mozilla the addons repository.

Several strategies are possible to get it in Guix and it might be possible to combine some of them together.

The Tor Browser project might find it very interesting to use Guix instead of Ubuntu for building the Tor Browser as Guix goes way beyond reproducible builds: It has extensive work that has been done to make Guix bootstrapable. Most other distributions only care about reproducible builds and so if the compilers binaries had a backdoor, software built with such compilers could then have a reproducible backdoor.

The issue is that the Tor Browser supports several operating systems (GNU/Linux, Android, Microsoft Windows, MacOS) and currently Guix only supports building software for GNU/Linux, GNU/Hurd and Microsoft Windows (this was contributed by someone wanting to build bitcoin with Guix precisely because extensive work has been made to make Guix bootstrapable).

Adding the ability to build applications for Android should probably be doable but I've no clue at all about MacOS.

In addition Guix already supports i686 and x86_64 for both Windows and GNU/Linux, and we might gain the ability to get the Tor browser for armhf, ARM 64bit (aarch64), powerpc, powerpc64le (the architecture used in the Talos II), riscV64.

And finally Guix pack also support several formats, like tarballs and Debian packages, and more can also be added as well. That would enable the tor-browser to be installed as a regular package. That could be handy with Tails for instance as last time I checked it was just a tarball being extracted.

In any case, it would really be a good idea to make the upstream Tor Browser project switch to Guix for their releases as we would avoid having to do any Q/A to verify that our version of the tor-browser looks exactly the same on the networks and that websites can't distinguish Guix users because it has been patched or built differently. And other FSDG distributions with less strict policies on bootstrapability could either build it though Guix or ship the tor-browser installer as it would then only ship software that is FSDG compliant.

We'd also need to make sure that users don't mess up trying versions that are not exactly the same as the released one (that might happens if the dependencies gets updated in Guix for instance). In any case we could then easily package the tor-browser installer in Guix too.

In addition it could push them to fix or accept fixes for the addon repository problem as Guix is probably not going to accept a tor-browser that is not FSDG compliant.

Now with the addon repository, several approaches could be taken:

  • It could be removed completely. The Tor Project advise against installing addons anyway as it could de-anonymize users. That's probably the best option here.
  • It could be moved to another list, for instance the one maintained the GNU project or one maintained by the Tor project.
  • It could also be fixed at Mozilla but I've no idea how easy it is, especially because we might need to check if the addons are really free software and can be built with free software, etc.

In any case it's probably not super important what option is chosen here as long as it's fixed.

References:

Self-hosting

Science

Translator

Features

  • Add more cross toolcains for more CPU architectures
    • armv4t looks like a good idea as many older ARM boards that boot with free software could then be supported. Debian still officially supports armv4t, so it might be possible to copy their settings and fixes.
    • Add an xtensa-elf target as it's probably already supported within packages for building the ath9k_htc firmware
    • Find if other firmwares from other architectures are being built
  • Add more cross toolchains for more OSes
    • It would be a good idea to be able to build binaries for Android, we already have a bit of Android components in Guix but they can only be used on GNU/Linux or other already officially supported toolchains or OS. It would be a good idea to add an Android / bionic target. We'd need to check how much bionic is linked to the kernel version being used on the Android device.
  • Add more Guix pack or guix system image formats
    • We could add Arch Linux packages to guix pack be able to be used on Parabola.
    • We could enable to ship multiple package in one Debian package (currently that works with the tarball format of guix pack but not with Debian packages)
    • Add a way to deploy Guix in a directory in a way compatible with LXC
  • LVM-Support (+5) Guix now has LVM support but it might not be fully complete. I for instance managed to boot a Guix SD system from an ext4 rootfs that is in a LVM partition that is in a LUKS encrypted partition with this guide and by following the official documentation.
  • Integrate better letsencrypt/certbot. Currently certbot works fine if you already have certificates: it can renew them and so on. But if you use webroot you need the web server to be started for certbot to create or update certificates, but nginx (which is the web server best supported by guixSD API) won't start without the certificates. People deploying services with Guix typically have to do workarounds because of this issue. A solution would be to add a --standalone option for certbot and once the certificate is obtained to trigger the switch to webroot and starting the web server with a hook like it's done when renewing certificates.
  • Add a better way to deal with secrets or external files: Currently it's up to users to do the provisioning of secrets like VPN credential files. If they package it somehow they end up being in the store and being a security risk as any users could see them. Having to manually provision such files might work in some cases but it doesn't scale well as to do it right we'd need to make a provionning method that works for all the cases (all the different types of images, etc). A solution would be to add some extra option to guix to also include extra files or tarballs. This way the files would be added for all images types (docker, qcow2 system images, disk images, with guix system init, etc).
  • Add generic ways to generate very small rootfs. For instance there is some support for initramfs already. Now that there is ppc64le support, if we can make images that fit into (128M?) of flash and that OpenBMC is packaged in Guix, it could probably completely support RYF computers like the Talos II. If we have a good enough abstraction like a target OS for instance, we could probably add the software we want in initramfs and/or in the BMC and configure them like a regular Guix system from the host computer. There is already support for managing VMs through a ganetti API in guix and there are also childhurds in Guix.

Other

TODO

  • When libreplanet.org is upgraded to a new version of MediaWiki, use interwiki links to link to the Free Software Directory for descriptions of wishlisted software.

This page was a featured resource in February 2019.


Retrieved from "https://libreplanet.org/wiki?title=Group:Guix/Wishlist&oldid=65424"