all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Thorsten Wilms <t_w_@freenet.de>
To: "guix-devel@gnu.org >> Guix-devel" <guix-devel@gnu.org>
Subject: Services, was: Re: XWayland, /tmp/.X11-unix
Date: Fri, 30 Mar 2018 18:25:48 +0200	[thread overview]
Message-ID: <95c03d9b-b530-4d16-ddb1-a04e2784ce1c@freenet.de> (raw)
In-Reply-To: <87po3m41w8.fsf@gmail.com>

On 30.03.2018 06:34, Chris Marusich wrote:
> I hope to eventually go back and improve the services
> documentation further in the manual, once I feel I have a strong enough
> grasp of how it all works.

A few thoughts then, that I hope will be of use:

Initially, I had a hard time understanding the talk about "extending", 
as the first snippets I looked at seemed rather like adding items to 
todo-lists. The 2nd paragraph on 
https://www.gnu.org/software/guix/manual/html_node/Service-Composition.html 
makes it clear.

So it appears to me that the core of this is that there are daemons and 
procedures that attain and control capabilities. Since there may be any 
number of things-to-do dependent on operating-system configuration, 
requiring access to those capabilities, a DAG is constructed and 
flattened to arrive at daemon configuration and executable procedures.

One aspect that makes reading the docs hard are the multiple meanings of 
"service" and the rather unspecific "service type", I think. Makes one 
think of Smurfs. In fairness: it seems hard to avoid ... maybe:
Could we try to reserve a naked "service" to refer to daemons and 
procedures with effects on the operating system? The things that go into 
operating-system/services are ... service-building-blocks, latent 
services, service-parts, proto-services ... OK; not terribly satisfying.

It is mentioned that service types are the nodes in the services DAG. 
Thus they could have been called service-nodes, which would have avoided 
confusion with those other *types* of services: ... printing s., desktop 
s., database s. ... .

Here I notice that I don't quite get how service-types wrapped in 
services in a list of services map to a DAG.


I see 2 main uses cases regarding the documentation:
A. Trying to understand the whole system.
B. Trying to accomplish a specific task and looking for just the 
required information.

The given descriptive nature of the documentation so far is alright for 
A. To serve B, you'd have to work along questions like:
- Is what I'm trying to accomplish within the scope of services? What 
are their capabilities and limitations? (A case like adding files to 
/etc might not come to everyone's mind.)
- What is the nature of what I'm tying to do, regarding time of 
execution, capabilities, dependencies and permissions? Here an overview 
of what service-type allows what?, when?, would shine.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

      reply	other threads:[~2018-03-30 16:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 19:57 XWayland, /tmp/.X11-unix Thorsten Wilms
2018-03-21 23:00 ` Ricardo Wurmus
2018-03-22 13:04   ` Thorsten Wilms
2018-03-25 14:34     ` Thorsten Wilms
2018-03-26  9:33       ` Marius Bakke
2018-03-26 10:45         ` Thorsten Wilms
2018-03-26 11:18           ` Marius Bakke
2018-03-26 12:44             ` Ludovic Courtès
2018-03-26 20:23             ` Thorsten Wilms
2018-03-29 15:18             ` Thorsten Wilms
2018-03-29 17:02               ` Marius Bakke
2018-03-29 19:57                 ` Thorsten Wilms
2018-03-29  6:18     ` Chris Marusich
2018-03-29 14:37       ` Thorsten Wilms
2018-03-30  4:34         ` Chris Marusich
2018-03-30 16:25           ` Thorsten Wilms [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=95c03d9b-b530-4d16-ddb1-a04e2784ce1c@freenet.de \
    --to=t_w_@freenet.de \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.