From mboxrd@z Thu Jan 1 00:00:00 1970 From: ndre Subject: Re: How to present Guix to a wider audience Date: Tue, 21 Jan 2020 18:49:40 -0300 Message-ID: <20200121214940.GA7192@andel> References: <878smq41kg.fsf@ambrevar.xyz> <874kwyp9hi.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:49279) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iu1PK-0001J8-R8 for help-guix@gnu.org; Tue, 21 Jan 2020 16:50:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iu1PJ-0003Q5-2p for help-guix@gnu.org; Tue, 21 Jan 2020 16:49:58 -0500 Received: from mx1.riseup.net ([198.252.153.129]:45382) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iu1PI-0003NX-Kp for help-guix@gnu.org; Tue, 21 Jan 2020 16:49:57 -0500 Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 482MdZ5gPbzFcBG for ; Tue, 21 Jan 2020 13:49:54 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bell.riseup.net (Postfix) with ESMTPSA id 482MdX51c7zJpkX for ; Tue, 21 Jan 2020 13:49:52 -0800 (PST) Content-Disposition: inline In-Reply-To: <874kwyp9hi.fsf@ambrevar.xyz> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane-mx.org@gnu.org Sender: "Help-Guix" To: help-guix@gnu.org --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, ter 14 jan 2020 =E0s 12:23:37 (1579015417), mail@ambrevar.xyz enviou: > I just wrote a short draft which hopefully should explain in layman > terms why Guix matters. >=20 > I tried to keep short (< 1000 words) and to stick to non-technical vocabu= lary. >=20 > Let me know what you think! Nice work Pierre. I have only some small suggestions. Even though I've incr= eased 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 >=20 > Applications are /written/ in the form of /source code/, which is a serie= s of > instructions for the computer stored as text files. But the machine cann= ot 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, si= nce 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 usua= lly a subset of English language with a special syntax which purports to avoid am= biguity. But computers cannot understand these human languages, in fact they can only /understand/ machine language, which are series of operating instructions c= oded with numbers. So, in order to run an application on a computer, someone has to translate = it =66rom the programming language in which it was written to the target machi= ne language which the computer /understands/. This is the work of /compilers/, which are specialized software that automate the translation task. The resu= lt of their translation to machine language is called /compiled code/. The pro= gram 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 hi= gh 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 instru= ction on source code translates to several coded instructions on machine language. Thus, they are effectively /black boxes/." > * Open source is not enough >=20 > We might be tempted to think that free open source software gives us > transparency about what's in the application. While the compiled applica= tion we > download from the Internet is a black box, we could just compile the sour= ce code > ourselves and compare the result with the downloaded application, right? = If it's > identical, then we are good. >=20 > 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 differ= ent 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 s= ome modified version of it? >=20 > In practice this means that it's almost always impossible to /reproduce/ = the > exact same compiled application that is offered for download. >=20 Notice that it's enough that merely one 0 or 1 got flipped for the behavio= ur > of the application to change completely. In other words, if two applicat= ions > are not identical to the bit, everything can happen and all trust vanishe= s. >=20 > 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= =2E.. > The slightest difference in the compilation environment is susceptible to= flip a > bit. >=20 > This is called the /reproduciblity/ problem. >=20 > * Software is made with software >=20 > The compiler is also an application that must be compiled, by another com= piler, > from some source code. The same applies to this other compiler, and so o= n. It > seems to be a chicken and egg problem: can we ever trust any compiler the= n? >=20 > It is actually possible: if we go up the chain of compilers far enough, w= e reach a level where have a trivial "machine level" compiler that can build a sim= ple compiler from source. > This machine-readable file is small enough that it is no longer a black b= ox 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 buil= d a more > complex compiler, etc., until we get today's compilers. >=20 > This is called the /bootstrappability/ problem. >=20 ---> SNIP all the rest. --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQI5BAABCgAjFiEEIBdLYNLH+F+MBdSrYrJ+WmBEwoIFAl4nceoFgwPCZwAACgkQ YrJ+WmBEwoL8VA//Uwy9nrUMN65Q47vLdRDm/8J0YYxQoyO1HHmh2uFlyn7j4jQ+ OHqnfJ6fIpG7mHpyU1oTWeYy2hnHNGiOFQtc4JF2BUeJYaSlq64noDt4oPLQsmFa P+OvvUKWZTl0ButiNmB/d0aO3+ha4HssjqMMxRAorzwrRoe/JquAoGM3kFjdX2Ep 1+Z3I7A7iqHYNlJiIwiAMBnb9LEJ9TA2KpE+upc+1voxxdKWEdhmB8FM47ZHgVFj iY6mU5N5OtFMGKyBM9KZGYaTM0fSxf3o5wmI7inDS/D9Kzw1nC8ncSNqtR6lccOB DPqLVTyZ7oXwzeTQsmLJQk61Aw1DQ7jmEbDDOxECPQm7C/KzKgYB/6Awr728h2L0 wxAhX72lzUeqZ338Jih9XOqMgf1M7rDlDZJA4nvFX+PRWeSHYcHzQjgJlDoExnFx vtQ7lbEZKDlrdMkF7wVjcoOS0HmWpXXTxspf4QgeGhFnNygMdWTIOY4vI8rFy3js /Zhuz5UUVVHGEhCbWXlMpGIfgduOGrTNX/bfc3gmaxWweLeXtJKxvI6oilau9wGC qCOVFABaimCUdfhI1AEm3W3AuWo+vrTMYCkr/Y25LNxsrgwTO1rp+QtEMcru96d1 nYTnKc5nyPBRHgjhOf3V/yA5HIBhklHY1lB0jiNiZ9YsKRcpw8S3PzyTtUk= =XSHX -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0--