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/
signature.asc
Description: PGP signature
#+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.
