From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catonano Subject: Re: Customize GuixSD: Use Stock SSH Agent Everywhere! Date: Tue, 29 May 2018 16:35:38 +0200 Message-ID: References: <87h8mu1lv9.fsf@gnu.org> <87muwk2fok.fsf@gmail.com> <87h8mshvdz.fsf@elephly.net> <87lgc2r31y.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e6cc9a056d592525" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fNfiv-0006I0-A8 for guix-devel@gnu.org; Tue, 29 May 2018 10:35:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fNfiu-0002D4-1Q for guix-devel@gnu.org; Tue, 29 May 2018 10:35:41 -0400 Received: from mail-yb0-x235.google.com ([2607:f8b0:4002:c09::235]:45671) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fNfit-0002CY-Rs for guix-devel@gnu.org; Tue, 29 May 2018 10:35:39 -0400 Received: by mail-yb0-x235.google.com with SMTP id r13-v6so5134945ybm.12 for ; Tue, 29 May 2018 07:35:39 -0700 (PDT) In-Reply-To: <87lgc2r31y.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: Guix-devel --000000000000e6cc9a056d592525 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-05-29 15:42 GMT+02:00 Ricardo Wurmus : > > Hi Catonano, > > > In this regard, I'd lie to suggest this talk, I think it's relevant > > https://archive.fosdem.org/2017/schedule/event/legacy_docs/ > > > > It'd be very useful for Guile too and God knows for how many more GNU > > projects > > Could you please summarize the key points and how they apply to this > discussion? > Sure ! Thanks for asking ! =F0=9F=98=83 I think a good starting point is this picture https://files.mastodon.social/media_attachments/files/003/855/604/original/= b02a794729c184ad.png The key point of the talk is that the documentation usually illustrates the technical features of a project And the process of envisioning solutions for use cases is left to the reade= r Instead, the documentation should start from specific use cases. It should be an anthology of use cases As for Guile, for example, Thomas Dankaert recently posted a question on the guile user mailing list about how to use string as ports in calling external commands; he wanted the error port of an external command to be a string The manual deals with input output in several locations scattered all aroun= d Drawing a working solution for reading/writing is not exactly immediate A bunch of examples would be more funcional, at least for some kinds of readers/users And input output is only one kind of use cases Regarding Guix, having examples of use cases of using packages could be a good starting point So, finally, I think your idea of having a separate document providing a different angle to using Guix is a good one Other categories of use cases could be envisioned It could cover not only the usage of specific packages but also some GuixSD functionalities such as updating, setting up specific desktop environments, services, reconfiguring Those things are quite different from the common usage patterns of mainstream distros and some reading-phobic people could use some quick general examples to draw a general picture of Guix on their own Maybe the traditional manual could be a further resource for those who want to deepen their knowledge of Guix How much am I ready to contribute to such a document ? I don't know I chimed in because I found interesting that a similar idea to that illustrated in the talk came afloat here --000000000000e6cc9a056d592525 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-05-29 15:42 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>= :

Hi Catonano,

> In this regard, I'd lie to suggest this talk, I think it's rel= evant
> https://archive.fosdem.org/2017= /schedule/event/legacy_docs/
>
> It'd be very useful for Guile too and God knows for how many more = GNU
> projects

Could you please summarize the key points and how they apply to this=
discussion?


Sure ! Thanks for askin= g ! =F0=9F=98=83

I think a good starting point is this pi= cture
https://files.mastodon.social/med= ia_attachments/files/003/855/604/original/b02a794729c184ad.png

<= /div>
The key point of the talk is that the documentation usually illus= trates the technical features of a project

And the proces= s of envisioning solutions for use cases is left to the reader

Instead, the documentation should start from specific use cases. It s= hould be an anthology of use cases

As for Guile, for exam= ple, Thomas Dankaert recently posted a question on the guile user mailing l= ist about how to use string as ports in calling external commands; he wante= d the error port of an external command to be a string

Th= e manual deals with input output in several locations scattered all around<= br>
Drawing a working solution for reading/writing is not exa= ctly immediate

A bunch of examples would be more funciona= l, at least for some kinds of readers/users
=C2=A0
<= /div>And input output is only one kind of use cases

Regarding G= uix, having examples of use cases of using packages could be a good startin= g point

So, finally, I think your idea of having a separate do= cument providing a different angle to using Guix is a good one

Other= categories of use cases could be envisioned

It could cover not only= the usage of specific packages but also some=20 GuixSD functionalities such as updating, setting up specific desktop=20 environments, services, reconfiguring

Those things are quite different from the common usage patterns of mains= tream distros and some reading-phobic people could use some quick general e= xamples to draw a general picture of Guix on their own

Maybe the traditional manual could be a further resourc= e for those who want to deepen their knowledge of Guix

How much am I ready to contribute to such a document ?<= br>
I don't know

I chimed in because I found interesting that a simil= ar idea to that illustrated in the talk came afloat here
--000000000000e6cc9a056d592525--