Dear GUIX-SD,

I am interested in this initiative because it is the GNU distribution
and also because there is the possibility to address some major
technical problems I have with current GNU / Linux distributions.

I have several questions, and I would appreciate it if you could attempt
to answer some of them.


* Integration with existing software distribution managers

Modern languages (I use this term loosely) have developed their own
cross-platform distribution mechanisms. It feels like a terrible waste
of effort for GNU / Linux distributions to repackage such artefacts
instead of relying on the well maintained industry standards.

For example, on the JVM, Maven Central is the central point for hosting
source code, binaries and documentations for individual libraries, with
GPG signatures, checksums and license information. Most commercial
organisations host their on mirror of Maven Central, giving them full
control over which artefacts are approved for use internally.

Developers of Java / Scala / etc use tools (maven, ivy, etc) to manage
downloading local filesystem caches of the exact artefacts that they
need (and their transitive dependencies).

However, distributions such as Debian and Redhat repackage all files and
make a complete mess of it. It would be far superior if the OS package
manager simply had a Maven backend that populated a system-wide local
filesystem maven repository. Then Java applications supported by guix
could follow a basic "java application" template, and there would be no
need for the OS package manager to track each individual transitive
dependency. Installation of Java applications would then be trivial.

I don't want to single out Java, because this is true of a large variety
of other languages: Haskell (cabal), Go (built-in), Python, Perl, etc.
One could even argue that Emacs ELPA falls into this category also, and
that a locally hosted MELPA would make sense for locked-down machines.

The result is that I tend to ignore any java, scala, haskell or go
application or library from apt, and use the preferred language-specific
package manager to install and manage that application. It would be
really nice if this was all integrated into guix such that I had one
package management interface for system wide installations.

How are you planning on handling these more modern languages that manage
their own dependencies?


* Docker image

Most GNU / Linux distributions have uploaded a base image of their OS to
hub.docker.com will you be creating and uploading a similar image? I'd
love to try one out.

I use docker to maintain a consistent build environment (across many
heterogenous devices) for many of my free software projects and it is
incredibly well suited to this task.

I strongly recommend docker as a way to build artefacts. With the
immergence of lightweight CI build tools such as
http://github.com/drone/drone/ it would be an incredible way to boost
your build farm! Indeed, you wouldn't need to ask for hardware donations
and could instead ask for docker worker donations (users open up an SSL
connection to their hardware and you use it from an orchestrated drone).
It also makes it a lot easier for users to test their packaging scripts
before submitting their changes to your central repository.


* Issue tracker / comm channels

I see that you are using debbugs, savannah and email mailing lists as
the main communication channels. This is a very traditional approach to
managing a free software community. Along with a large number of other
people, I have found that a single, integrated, web based approach is
far easier to engage with as a user, for example github (free as in
beer) or gitlab (free as in freedom, but less complete). The "pull
request" concept makes it exceptionally easy to make contributions, and
easy for admins to review and accept those proposed changes.

Will you be continuing to use debbugs, savannah and mailing lists going
forward or would you consider moving to a modern community management
system like gitlab?


* Custom / full install images

Debian and co use an antiquated concept of CD/DVD isos for
installations. The vast majority of modern users want to put either a
full or a custom (where they have selected all the packages)
installation image onto a USB. It is not always possible to use network
installation from a minimal image due to firewall rules or connectivity
issues.

Something I've wanted for a long time would be the ability to create an
installation image on a USB, and fill the remainder of the USB with a
VFAT partition. This is remarkably hard to achieve with gparted and a
fixed size installation image.