Re: How to present Guix to a wider audience

[Pierre Neidhardt <mail@ambrevar.xyz>]

[-- Attachment #1.1: Type: text/plain, Size: 2857 bytes --]

Hi ndre,

Thanks, those are  great suggestions!  Some comments below:

> "Applications are /written/ in programming languages, which are specialized human
> languages made up to give instructions to computers. As such, they are usually a
> subset of English language with a special syntax which purports to avoid ambiguity.
> But computers cannot understand these human languages, in fact they can only
> /understand/ machine language, which are series of operating instructions coded
> with numbers.
>
> So, in order to run an application on a computer, someone has to translate it
> from the programming language in which it was written to the target machine
> language which the computer /understands/. This is the work of /compilers/,
> which are specialized software that automate the translation task. The result
> of their translation to machine language is called /compiled code/. The program
> as expressed on a programming language is called /source code/."

Hmmm, maybe a bit too long in my opinion.  While this is educational, I
don't want to drown the fish either :)

The phrasing is good though and I've included half of it into the text.

> "Now while the source code is intelligible to humans and offers a pretty high
> level of transparency of its logic, compiled code is a virtualy unreadable
> sequence of numbers. In order to understand it, a human would have to decode
> the numbers to the appropriate instructions, do the binary arithmetic they
> represent and have intimate knowledge of the hardware. Moreover, one instruction
> on source code translates to several coded instructions on machine language.
> Thus, they are effectively /black boxes/."

Included.

>  compile the source code twice, chances are that you'll get slightly different
>  sequences of numbers. So how can you know that the compiled software you've
>  downloaded is in fact a proper translation of the source code instead of some
>  modified version of it?

Included.

>  Notice that it's enough that merely one 0 or 1 got flipped for the behaviour

Included.

>> It is actually possible: if we go up the chain of compilers far enough, we reach
>
>  a level where have a trivial "machine level" compiler that can build a simple
>  compiler from source.

Included.

>> This machine-readable file is small enough that it is no longer a black box and
>
>  can be inspected by humans and it is also the only piece of software which needs
>  the tedious decoding process done.  This simpler compiler can in turn build a more

I'm not sure this part adds much to the explanation.  I haven't included
it because I fear it sounds too complicated.

Thanks!
Updated version attached.

To the maintainers: what do you think of publishing this on guix.gnu.org?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: guix-why-matters.org --]
[-- Type: text/x-org, Size: 7352 bytes --]

#+TITLE: Why GNU Guix matters

Have you ever installed an application on a computer, a smartphone or your
favourite smart device?  Can you trust that it does its job instead of doing the
opposite of what it displays on screen or, worse, compromise your data and your
private life?

How can you know?  You might think "Let's use free and open source software!"
The bad news: it's far, very far from being enough.

This is a hard and yet very real problem that hits our everyday life constantly.
Consider this: the digital pictures of our loved ones, banking operations, the
(political?) news feed that we read, our contacts and the communication with our
friends and colleagues; all of it happens through applications.

How can we protect ourselves from deceit?  How can we guarantee trust in the
machines that we use?

First, we need to understand how applications are made.

* The assembly line of software

Applications are /written/ in the form of /source code/, which are specialized
human languages made up to give instructions to computers.  But the machine
cannot understand this source code directly: it must first be /compiled/ into
/machine code/, which are series of operating instructions coded with numbers.
The program responsible for translating source code into machine code is called
a /compiler/.  The resulting /compiled application/ can then be run by the user.

While the source code is intelligible to humans and offers a pretty high level
of transparency of its logic, compiled code is a virtually unreadable sequence of
numbers.  Moreover, one instruction on source code translates to several coded
instructions on machine language.  Thus, they are effectively /black boxes/.

* Open source is not enough

We might be tempted to think that free open source software gives us
transparency about what's in the application.  While the compiled application we
download from the Internet is a black box, we could just compile the source code
ourselves and compare the result with the downloaded application, right?  If it's
identical, then we are good.

So why is free, open source software not trustworthy then?  Because when you
compile the source code twice, chances are that you'll get slightly /different
black boxes/.

So how can you know that the compiled software you've downloaded is in fact a
proper translation of the source code instead of some modified version of it?

In practice this means that it's often difficult to /reproduce/ the
exact same compiled application that is offered for download.

Notice that it's enough that merely one 0 or 1 got flipped for the behaviour
of the application to change completely.  In other words, if two applications
are not identical to the bit, everything can happen and all trust vanishes.

This lack of reliability in the compilation of applications comes from the
"chaos" in the machine environment: slightly different software used for
compilation (e.g. different versions), different hardware, different date...
The slightest difference in the compilation environment is susceptible to flip a
bit.

This is called the /reproduciblity/ problem.

* Software is made with software

The compiler is also an application that must be compiled, by another compiler,
from some source code.  The same applies to this other compiler, and so on.  It
seems to be a chicken and egg problem: can we ever trust any compiler then?

It is actually possible: if we go up the chain of compilers far enough, we reach
a level where we have a trivial "machine level" compiler that can build a simple
compiler from source.
This machine-readable file is small enough that it is no longer a black box and
can be inspected by humans.  The simpler compiler can in turn build a more
complex compiler, etc., until we get today's compilers.

This is called the /bootstrappability/ problem.

* Trust all the way

To sum up, we need the following properties in order to be able to trust
computer software:

- Free and open source software.
- Reproducibility.
- Bootstrappability.

This is only useful if the entire software running on your machine obeys these
principles.  A single black box on your machine can wreck havoc.  In other
words, the entire /operating system/ itself must be free and open source
software, reproducible and bootstrappable.

This is precisely [[https://guix.gnu.org][GNU Guix]]' stated goal: Offer a strong guarantee of reliability and
trust.

- Reliability: It just works, and more importantly, it will always work.  No
  more unexpected, random behaviour; no more "software erosion."

- Trust: Work is in progress to fully /bootstrap/ the software assembly line,
  which means everything will soon be fully transparent..

What's even more interesting with Guix is the that this novel approach to
operating systems gives it great usability benefits:

- Unbreakable system and time travel: Have you ever updated a system only to
  restart it broken or less functional?  (Say there was a power cut during the
  upgrade.)  With Guix you keep a history of all previous /states/ of the
  system, even when you change the configuration manually.  If something breaks,
  you can always go back in time.  No more fear of updates or tinkering around
  with the settings!

# - Separate multi-user application collections: on a multi-user system, every
#   user can install their favourite applications independently.  Applications
#   don't "pollute" the other user sessions.

- Multiple versions: Sometimes you'll need an older version of a program (for
  instance to support an old format or a feature that's gone in a newer version).
  Guix allows to install multiple versions of the same program in parallel.

* Can everyone use Guix?

Guix is currently (January 2020) actively developed by a community of
programmers from all over the world.  It is stable and can be used in a number
of settings, from laptop and desktop computers to servers and scientific
computing.

More work needs to be done in terms of accessibility and ease of use so that the
less technically-minded among us can also enjoy Guix some day.  Then, hopefully,
we will find Guix preinstalled on computers, ready for everyone to use.

If you'd like to contribute in some way, feel free to [[https://guix.gnu.org/contact/][reach out to us!]]

* References

- https://guix.gnu.org: The home page of GNU Guix with blog articles, documentation,
  videos and more.

- https://nixos.org/: The other operating system that targets similar goals.
  Nix was an inspiration for Guix.

- https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_backdoors:
  Compilers can be malicious and create malicious compilers in turn.  This is
  commonly known as the "Thompson attack," as first mentioned in the speech
  "Reflections on Trusting Trust" by Ken Thompson.

- https://www.quora.com/What-is-a-coders-worst-nightmare/answer/Mick-Stute?srid=RBKZ&share=1:
  The story of an actual implementation of the "Thompson attack."

- https://reproducible-builds.org/: Technical information on reproducibility.

- https://bootstrappable.org/: Technical information on bootstrappability.

- https://www.gnu.org/software/mes/: GNU Mes is a project that aims at
  bootstrapping the main compilers until stage0.

- https://savannah.nongnu.org/projects/stage0: The "machine-level" compiler that
  both readable by machines and humans.