How to present Guix to a wider audience

How to present Guix to a wider audience

[Pierre Neidhardt]

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

Hi!

I've been asked multiple times to present this project I work on:
Guix! :)
And I found it quite difficult to explain the main perks of Guix to
people not well versed in computer science.

So I was wondering: do we have an article that introduces Guix for the
general public?  It could be quite useful I believe.

Cheers!

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

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

Re: How to present Guix to a wider audience

[zimoun]

Hi Pierre,


On Thu, 2 Jan 2020 at 11:04, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> So I was wondering: do we have an article that introduces Guix for the
> general public?  It could be quite useful I believe.

AFAIK, nothing dedicated.

Browse the folders doc/ and talks/ in
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/

Note that broken symbolic links are fixed in a patched sent here [1].

[1] https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00326.html


Well, it depends on what do you mean by "general public"?


To my knowledge -- and IMHO -- the talk by Chris at seagl-2018 is
didactic [2], the video by Carl Dong about Trusting Trust is really
well-explained [3], Julien wrote an article in French for JRES 2019
[4] and the associated video [5], an outdated article in French by
Ludo has the merit of existing [6].

Last but not least, all the videos [7] are a really good introduction
for(motivated) general public.

And I have tried to define concrete use-cases (based on "scientific"
workflows) in [1]; I would like to extend this as a Cookbook entry.
Whatever!


[2] https://media.marusich.info/everyday-use-of-gnu-guix-chris-marusich-seagl-2018.webm
[3] https://www.youtube.com/watch?v=I2iShmUTEl8
[4] https://conf-ng.jres.org/2019/document_revision_5343.html?download
[5] https://replay.jres.org/videos/watch/c77b3a44-b75f-4c10-9f39-8fb55ae096d7
[6] https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-194/Gestion-de-paquets-sure-et-flexible-avec-GNU-Guix
[7] https://guix.gnu.org/videos/


Not sure that helps! :-(

Cheers,
simon

ps:
Stay tuned! :-)
Should Konrad release a new version of the well-known MOOC [8]? ;-)

[8] https://www.fun-mooc.fr/courses/course-v1:inria+41016+session02/about

Re: How to present Guix to a wider audience

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> I've been asked multiple times to present this project I work on:
> Guix! :)
> And I found it quite difficult to explain the main perks of Guix to
> people not well versed in computer science.

Ideally, the web site should answer the question of what Guix is in a
way that the general public can understand and appreciate.

In my opinion, the website could do better.

-- 
Ricardo

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Ideally, the web site should answer the question of what Guix is in a
> way that the general public can understand and appreciate.
>
> In my opinion, the website could do better.

I couldn't agree more :/

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

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

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Hi Simon!

Thanks for the suggestions.  It's all good content, but I'm looking for
a presentation that you could give to _anyone_, more or less people who
know that

- Computers, smartphones, etc. are around us.
- They are used in research, banking, etc.
- They can be used to store our private data.
- They can be abused (e.g. maybe heard about Snowden).

Carl Dong's video is the closest to what I'm looking for.

I'd prefer a text format though.  Besides, if we don't want to exhaust
the patience of our users before pronouncing the word "Guix", I
think it's important to make it a very short read, say 5 minutes, or
some 1000 words.

(Carl Dong's video is 16 minute long, and Guix is only introduced at the
end.)

As Ricardo said, I believe such a general presentation would be very
welcome on Guix' front page.

Anyone interested in writing such a text?

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

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

Re: How to present Guix to a wider audience

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> As Ricardo said, I believe such a general presentation would be very
> welcome on Guix' front page.
>
> Anyone interested in writing such a text?

We discussed website changes extensively in the past.  Here’s a thread:

    https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00232.html

It also includes the suggestion to deemphasize the distro “Guix System”
and only keep text on the home page that applies to Guix itself.

In my last FOSDEM talk on the GWL I showed how Guix operates on
ever-growing “scenes”: packages, environments composed of multiple
packages, containers composed of environments, and even full-blown
systems.

Maybe there’s something in the old discussions that would still be
useful today for concrete change proposals.

--
Ricardo

Re: How to present Guix to a wider audience

[zimoun]

Hi Pierre,

On Wed, 8 Jan 2020 at 16:33, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> - Computers, smartphones, etc. are around us.
> - They are used in research, banking, etc.
> - They can be used to store our private data.
> - They can be abused (e.g. maybe heard about Snowden).
>
> Carl Dong's video is the closest to what I'm looking for.
>
> I'd prefer a text format though.  Besides, if we don't want to exhaust
> the patience of our users before pronouncing the word "Guix", I
> think it's important to make it a very short read, say 5 minutes, or
> some 1000 words.

Ahaha! Good luck! :-)

My experience: I explained to friends or family who fit your list above:
 + trusting trust: with 5 minutes, it is ok using the
yogourt=yogourt+milk analogy;
 + asymmetric cypher, cross-compilation, torrent, etc.: with 5 mins,
it is ~okish too
 - Guix: I have always failed; even with 15min.

Even failed with scientific colleagues who uses classical linux
distro. For example, I did an attempt here [1].

[1] https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00326.html


The issue is because each time my "audience" is too far from the
problems Guix fix. Other said, how do you explain why profiles,
manifests, roll-back, declarative stuff, etc. are so cool when the
"audience" only knows Word, Excel, Browser and some apps on
smartphones?

I do not want to be pessimistic but it is hard to introduce Guix for
general public.


> (Carl Dong's video is 16 minute long, and Guix is only introduced at the
> end.)
>
> As Ricardo said, I believe such a general presentation would be very
> welcome on Guix' front page.
>
> Anyone interested in writing such a text?

IMHO, a good start is to write down typical use cases/scenarii that
Guix solves. What do you think?


All the best,
simon

Re: How to present Guix to a wider audience

[wisdomlight--- via]

Below is my response to zimoun email.

Sent from ProtonMail Mobile

On Thu, Jan 9, 2020 at 12:35, zimoun <zimon.toutoune@gmail.com> wrote:

> Hi Sherab,
>
> First, you only sent the email to me. Was it your intention? If yes,
> your words should interest the list too. If no, please re-send your
> words to the list or can I use publicly them?
>
> On Wed, 8 Jan 2020 at 23:14, <wisdomlight@protonmail.com> wrote:
>
>> For what it’s worth, I presume I’m the person you are probably thinking about.
>> I am not a developer or any thing like that at all - but I do install my own Linux desktop distribution I can play a little with terminal and enjoy tweaking and finding out things about Linux. I can solve rudimentary issues by looking at the various forums.
>> I tried Guix a while back and did not get anywhere with it. The experience was abysmal- installation was infinitely slow and finally did not happen.
>
> Sad! :-(
> Now, with the binary shell installer, it should be easy. Please report
> on help-guix@gnu.org any of the issue you encounter.
>
> See the doc here [1] especially the note at the top, i.e., download
> [2] and run "bash guix-install.sh".
>
> [1] http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation
> [2] https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
>
>> As Simon said what needs to be clear is what is the benefits I as a user will receive from using guix. What makes it stand out then the other RedHat Debian based distributions??
>
> To help us to figure out or convince you that Guix is awesome, could
> you quickly describe why you were interested in Guix?
> How did you learn the existence of Guix?
> And why did you want to install it?
>
> All the best,
> simon

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Hi Sherab,

>> On Wed, 8 Jan 2020 at 23:14, <wisdomlight@protonmail.com> wrote:
>>
>>> For what it’s worth, I presume I’m the person you are probably thinking about.

Well, to be honest I was intending to write something reaching out to an
even broader audience, i.e. people who don't know how to install an OS.

Simon is asking good questions though:

>> To help us to figure out or convince you that Guix is awesome, could
>> you quickly describe why you were interested in Guix?
>> How did you learn the existence of Guix?
>> And why did you want to install it?

?

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

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

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

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!

-- 
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: 6730 bytes --]

#+TITLE: Why 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 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.

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

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

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

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.
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 it 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][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 easy 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 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://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.

Re: How to present Guix to a wider audience

[Jack Hill]

On Tue, 14 Jan 2020, Pierre Neidhardt wrote:

> 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!

On my initial reading, I think it's great, thank you! Unfortunately, I 
don't have any ideas for improvements right now, but I have been asked to 
talk about Guix at the library where I work in March, and perhaps that 
will bubble up other questions that people have.

This has helped me tremendously in thinking about how to frame Guix for 
non-hackers. Thank you.

Jack

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Thanks, glad you liked it!
I'd be happy to get feedback from your presentation!

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

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

Re: How to present Guix to a wider audience

[Jack Hill]

On Tue, 14 Jan 2020, Pierre Neidhardt wrote:

> Thanks, glad you liked it!
> I'd be happy to get feedback from your presentation!

It's not until March 26th (it's part of a series of lunchtime 
discussions), but I'm happy to write a summary and report back.

Best,
Jack

Re: How to present Guix to a wider audience

[Dimakakos Dimos]

> I just wrote a short draft which hopefully should explain in layman
> terms why Guix matters.

It's very nice, thanks for your work. I think I'll share it with friends to make
them get Guix a bit better.

Re: How to present Guix to a wider audience

[Vagrant Cascadian]

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

On 2020-01-14, Pierre Neidhardt wrote:
> I just wrote a short draft which hopefully should explain in layman
> terms why Guix matters.

Thanks, it's a nice read!


> * 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
...
> In practice this means that it's almost always impossible to /reproduce/ the
> exact same compiled application that is offered for download.

I object a bit to "almost always impossible" :P

There are a number of projects that have achieved reproducibility for a
majority of the distributed software, including small to large-sized
distributions. Even a few small projects that manage 100%
reproducibility.

How about "often difficult" instead?


> * Trust all the way
>
> To sum up, we need the following properties in order to be able to trust
> computer software:
...
> - 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.

I wonder if most people even undertsand the concept of a multi-user
system all that well? might be worth leaving out to keep the talking
points short...


> * Can everyone use Guix?
...
> More work needs to be done in terms of accessibility and easy 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.

"easy of use" -> "ease of use"


live well,
  vagrant

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

Re: How to present Guix to a wider audience

[Josh]

It is purist, and that's hard for a general audience.  To CS and math 
people, this is exactly the way to go.  The start is stronger.  Some of 
Ken Thompson's more worrying work should be included to convey our 
intuitive fear of this to the layperson. The second link may not be all 
that credible, but the story conveys what guix is meant to prevent, and fix.

http://wiki.c2.com/?TheKenThompsonHack

https://www.quora.com/What-is-a-coders-worst-nightmare/answer/Mick-Stute?srid=RBKZ&share=1

https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_backdoors

I think some of the buildup to the logical proof can be omitted, with 
just the assertion that with the elements of FLOSS, Reliability, and 
Trust are required and guix is designed to guarantee those would be 
sufficient for the audience.

Re: How to present Guix to a wider audience

[Arun Isaac]

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


> 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!

Reads well to me, but that could be because I already understand the
content of the essay. I don't know how practical it is, but if we can
get people who have never heard of Guix to read it, their opinion would
be of much value.

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

Minor typo: "theses" -> "these"

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

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Hi Vagrant!

Vagrant Cascadian <vagrant@reproducible-builds.org> writes:

> Thanks, it's a nice read!

Thanks!

> How about "often difficult" instead?

Agreed and applied.

>> - 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.
>
> I wonder if most people even undertsand the concept of a multi-user
> system all that well? might be worth leaving out to keep the talking
> points short...

True, it's less fashionable these days now that everyone has their
personal machine.  I'll comment it out.

>> * Can everyone use Guix?
> ...
>> More work needs to be done in terms of accessibility and easy 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.
>
> "easy of use" -> "ease of use"

Fixed.

Cheers!

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

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

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Hi Arun!

Arun Isaac <arunisaac@systemreboot.net> writes:

> Reads well to me, but that could be because I already understand the
> content of the essay. I don't know how practical it is, but if we can
> get people who have never heard of Guix to read it, their opinion would
> be of much value.

Indeed.  I've given it to a couple of friends who are not familiar with
Guix.  I'm still waiting for their feedback.

>> 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.
>
> Minor typo: "theses" -> "these"

Fixed, thanks!

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

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

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Josh <joshua.r.marshall.1991@gmail.com> writes:

> http://wiki.c2.com/?TheKenThompsonHack
>
> https://www.quora.com/What-is-a-coders-worst-nightmare/answer/Mick-Stute?srid=RBKZ&amp;share=1

It's a nice story, I may just include it as well in the references.

> https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_backdoors

I've already included this link.

> I think some of the buildup to the logical proof can be omitted, with 
> just the assertion that with the elements of FLOSS, Reliability, and 
> Trust are required and guix is designed to guarantee those would be 
> sufficient for the audience.

Could you be more specific as to which part can be omitted?

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

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

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Thank you all for the reviews and the kind feedback!

It seems that the draft was met with success for now.
So what about including it on Guix' website, maybe with a big link to it
on the front page?

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

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

Re: How to present Guix to a wider audience

[sirgazil]

Hi, Pierre


 ---- On Wed, 15 Jan 2020 03:59:00 -0500 Pierre Neidhardt <mail@ambrevar.xyz> wrote ----
 > Thank you all for the reviews and the kind feedback!
 > 
 > It seems that the draft was met with success for now.
 > So what about including it on Guix' website, maybe with a big link to it
 > on the front page?
 
I think the problem of "What is Guix?" should be solved before doing that (see https://lists.gnu.org/archive/html/help-guix/2020-01/msg00002.html).

Personally, I think GNU Guix and its related operating system should be presented separately.

I think that GNU Guix is not a software that needs to be explained to the average computer user. GNU Guix, in my opinion, is a software for system administrators and developers in any field, and it would be good to present it clearly to them in general and provide explanations for particular fields whenever necessary (that's what the section "GNU Guix in your field" in the home page was designed for).

Even though one of GNU Guix goals is to empower users, average users are more into installing and removing application, and that's about it. Ideally, not using a command-line interface directly but a graphical user interface (e.g. an app store).

The operating system, on the other hand, should be presented to average users, and it should be called simply GNU. With this I mean that the GNU project should use GNU Guix to generate downloadable installers of what they call the GNU Operating System in their home page and distribute these installers through the GNU.org website. The pages of GNU.org should be updated accordingly and focus on presenting the GNU operating system to the general public. This would include adding high-level information of the features GNU Guix brings with it (reproducibility, bootstrappability, etc.) which would differentiate GNU from other systems. For advanced uses of the system that require deeper understanding of GNU Guix, advanced users should be directed to the GNU Guix subdomain. The rest of the current Free Software Distributions (Trisquel, PureOS, Parabola, etc.) would still be listed in GNU.org as alternative distributions of the GNU Operating System. I know that RMS opposed to this idea a couple of years ago (https://lists.gnu.org/archive/html/gnu-system-discuss/2014-11/msg00002.html), but I think this should be done.

I think this separation could make it easier to outreach to potential users of both artifacts, the OS and the "software environment manager". Calling the OS just GNU would also help differentiate this system from what the general public call "linux". 


---
https://sirgazil.bitbucket.io/

Re: How to present Guix to a wider audience

[Todor Kondić]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, 15 January 2020 18:44, sirgazil <sirgazil@zoho.com> wrote:

> Hi, Pierre
>
> ---- On Wed, 15 Jan 2020 03:59:00 -0500 Pierre Neidhardt mail@ambrevar.xyz wrote ----
>
> > Thank you all for the reviews and the kind feedback!
>
> >
>
> > It seems that the draft was met with success for now.
>
> > So what about including it on Guix' website, maybe with a big link to it
>
> > on the front page?
>
> I think the problem of "What is Guix?" should be solved before doing that (seehttps://lists.gnu.org/archive/html/help-guix/2020-01/msg00002.html).
>
> Personally, I think GNU Guix and its related operating system should be presented separately.
>
> I think that GNU Guix is not a software that needs to be explained to the average computer user. GNU Guix, in my opinion, is a software for system administrators and developers in any field, and it would be good to present it clearly to them in general and provide explanations for particular fields whenever necessary (that's what the section "GNU Guix in your field" in the home page was designed for).
>
> Even though one of GNU Guix goals is to empower users, average users are more into installing and removing application, and that's about it. Ideally, not using a command-line interface directly but a graphical user interface (e.g. an app store).
>
> The operating system, on the other hand, should be presented to average users, and it should be called simply GNU. With this I mean that the GNU project should use GNU Guix to generate downloadable installers of what they call the GNU Operating System in their home page and distribute these installers through the GNU.org website. The pages of GNU.org should be updated accordingly and focus on presenting the GNU operating system to the general public. This would include adding high-level information of the features GNU Guix brings with it (reproducibility, bootstrappability, etc.) which would differentiate GNU from other systems. For advanced uses of the system that require deeper understanding of GNU Guix, advanced users should be directed to the GNU Guix subdomain. The rest of the current Free Software Distributions (Trisquel, PureOS, Parabola, etc.) would still be listed in GNU.org as alternative distributions of the GNU Operating System. I know that RMS opposed to this idea a couple of years ago (https://lists.gnu.org/archive/html/gnu-system-discuss/2014-11/msg00002.html), but I think this should be done.
>
> I think this separation could make it easier to outreach to potential users of both artifacts, the OS and the "software environment manager". Calling the OS just GNU would also help differentiate this system from what the general public call "linux".
>
>
>


I am sorry, but Guix should most definitively be presented to average *nix based users (the admins of their own/family workstations). It's like: "Look, now your grandmother, her cat and your dog can all install packages without knowing your sudo password!". This feature alone is highly appealing to some circles ;) .

As for more "advanced" users, from the experience I had when talking about Guix to the unconverted hackers, they struggle to accept why is it so much better than the already hyped technologies that Just Work, such as Chef/Puppet and other CI/CD for automating installations (*), Docker/Singularity on their own for building containers etc, especially because it is based on an 'exotic' language  as Scheme (exotic was the exact word that has been used in a certain conversation with an experienced professional developer). Disclaimer: I started using Guix because it was based on Guile.

Of course, different target groups should be, well, targeted with different aspects of Guix -- those that may appeal to them. And, there is more to Guix than just the pkg manager and the OS.

Also, to be fair, Guix is the first complex program of the GNU system I am aware of that started making waves in modern times, so on the presentation front some things have already been done well.


* I am not an expert on this, so I am not sure whether Guix can fit in the same workflow with the mentioned tools, or is in a parallel, or an orthogonal universe.

Re: How to present Guix to a wider audience

[wisdomlight]

Having worked with Guix for number of days with some issues - some of my own makings....
I cannot see how i can say to my grandmother install guix.
for the simplest reason that i found it very hard to find the software that i needed plus the software i needed if it was not on the guix store/farm was very difficult to understand how to install with chnnels etc.
So I am not sure about recommending Guix to beginners.


Sherab

Just like an experience in a dream
Everything I now enjoy
Will become a mere recollection
For what has past will not be seen again

Sent from ProtonMail, encrypted email based in Switzerland.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 19 January 2020 11:03, Todor Kondić <tk.code@protonmail.com> wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, 15 January 2020 18:44, sirgazil sirgazil@zoho.com wrote:
>
> > Hi, Pierre
> > ---- On Wed, 15 Jan 2020 03:59:00 -0500 Pierre Neidhardt mail@ambrevar.xyz wrote ----
> >
> > > Thank you all for the reviews and the kind feedback!
> >
> > >
> >
> > > It seems that the draft was met with success for now.
> >
> > > So what about including it on Guix' website, maybe with a big link to it
> >
> > > on the front page?
> >
> > I think the problem of "What is Guix?" should be solved before doing that (seehttps://lists.gnu.org/archive/html/help-guix/2020-01/msg00002.html).
> > Personally, I think GNU Guix and its related operating system should be presented separately.
> > I think that GNU Guix is not a software that needs to be explained to the average computer user. GNU Guix, in my opinion, is a software for system administrators and developers in any field, and it would be good to present it clearly to them in general and provide explanations for particular fields whenever necessary (that's what the section "GNU Guix in your field" in the home page was designed for).
> > Even though one of GNU Guix goals is to empower users, average users are more into installing and removing application, and that's about it. Ideally, not using a command-line interface directly but a graphical user interface (e.g. an app store).
> > The operating system, on the other hand, should be presented to average users, and it should be called simply GNU. With this I mean that the GNU project should use GNU Guix to generate downloadable installers of what they call the GNU Operating System in their home page and distribute these installers through the GNU.org website. The pages of GNU.org should be updated accordingly and focus on presenting the GNU operating system to the general public. This would include adding high-level information of the features GNU Guix brings with it (reproducibility, bootstrappability, etc.) which would differentiate GNU from other systems. For advanced uses of the system that require deeper understanding of GNU Guix, advanced users should be directed to the GNU Guix subdomain. The rest of the current Free Software Distributions (Trisquel, PureOS, Parabola, etc.) would still be listed in GNU.org as alternative distributions of the GNU Operating System. I know that RMS opposed to this idea a couple of years ago (https://lists.gnu.org/archive/html/gnu-system-discuss/2014-11/msg00002.html), but I think this should be done.
> > I think this separation could make it easier to outreach to potential users of both artifacts, the OS and the "software environment manager". Calling the OS just GNU would also help differentiate this system from what the general public call "linux".
>
> I am sorry, but Guix should most definitively be presented to averagenix based users (the admins of their own/family workstations). It's like: "Look, now your grandmother, her cat and your dog can all install packages without knowing your sudo password!". This feature alone is highly appealing to some circles ;) .
> As for more "advanced" users, from the experience I had when talking about Guix to the unconverted hackers, they struggle to accept why is it so much better than the already hyped technologies that Just Work, such as Chef/Puppet and other CI/CD for automating installations (), Docker/Singularity on their own for building containers etc, especially because it is based on an 'exotic' language as Scheme (exotic was the exact word that has been used in a certain conversation with an experienced professional developer). Disclaimer: I started using Guix because it was based on Guile.
>
> Of course, different target groups should be, well, targeted with different aspects of Guix -- those that may appeal to them. And, there is more to Guix than just the pkg manager and the OS.
>
> Also, to be fair, Guix is the first complex program of the GNU system I am aware of that started making waves in modern times, so on the presentation front some things have already been done well.
>
> -   I am not an expert on this, so I am not sure whether Guix can fit in the same workflow with the mentioned tools, or is in a parallel, or an orthogonal universe.

Re: How to present Guix to a wider audience

[ndre]

[-- 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 --]

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

[-- 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.

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

I've published the article on my website in the meantime:

https://ambrevar.xyz/guix-matters/index.html

Sherab, ndre, let me know if you want to be included in the "Special
thanks" section.

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

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

Re: How to present Guix to a wider audience

[Kelsang Sherab]

Hi Pierre

Thanks for the thought.

i'll leave it up to you.

Sherab

On 22/01/2020 17:35, Pierre Neidhardt wrote:
> I've published the article on my website in the meantime:
>
> https://ambrevar.xyz/guix-matters/index.html
>
> Sherab, ndre, let me know if you want to be included in the "Special
> thanks" section.
>

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Kelsang Sherab <wisdomlight@protonmail.com> writes:

I just added you there!

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

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

Re: How to present Guix to a wider audience

[Pierre Neidhardt]

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

Friendly ping!

What do you people think of posting this article on
https://guix.gnu.org?
Either as a blog post or as a dedicated page?

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

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

Re: How to present Guix to a wider audience

[Josh Marshall]

Not a bad idea.  There is still a need for general content for guix.  I'd
think it fits as a blog post.

On Tue, Feb 11, 2020, 02:46 Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> Friendly ping!
>
> What do you people think of posting this article on
> https://guix.gnu.org?
> Either as a blog post or as a dedicated page?
>
> --
> Pierre Neidhardt
> https://ambrevar.xyz/
>