Re: How to present Guix to a wider audience

[ndre <nandre@riseup.net>]

[-- Attachment #1: Type: text/plain, Size: 5205 bytes --]

Hello,

ter 14 jan 2020 às 12:23:37 (1579015417), mail@ambrevar.xyz enviou:
> I just wrote a short draft which hopefully should explain in layman
> terms why Guix matters.
> 
> I tried to keep short (< 1000 words) and to stick to non-technical vocabulary.
> 
> Let me know what you think!

Nice work Pierre. I have only some small suggestions. Even though I've increased
the number of characters, I think the result is more friendly on the reader.


> #+TITLE: Why Guix matters

---> SNIP unmodified text.

> * The assembly line of software
> 
> Applications are /written/ in the form of /source code/, which is a series of
> instructions for the computer stored as text files.  But the machine cannot read
> theses files directly: it must first be /compiled/ into /machine code/.  The
> resulting /compiled application/ can then be run by the user.

I'd slightly change this introduction to present source code, machine code and
compilers in more familiar terms if we are targeting a broader audience, since
they might sound as tech jargon at first. Thus the above text could be
something like:

"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/."

> While source code access gives you a pretty high level of transparency and
> allows you to inspect what the program will do, compiled programs are a
> practically unreadable sequence of 1 and 0.  They are effectively /black boxes/.

And this one as follows:

"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/."


> * 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
 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?

> 
> In practice this means that it's almost always impossible 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 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 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

> complex compiler, etc., until we get today's compilers.
> 
> This is called the /bootstrappability/ problem.
> 

---> SNIP all the rest.

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