all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Chris Marusich <cmmarusich@gmail.com>
To: rendaw <7e9wc56emjakcm@s.rendaw.me>
Cc: help-guix@gnu.org
Subject: Re: Services and log management/monitoring
Date: Sat, 04 May 2019 01:24:14 -0700	[thread overview]
Message-ID: <87tvea4ogh.fsf@gmail.com> (raw)
In-Reply-To: <1a06849a-e399-47d9-e68a-e688fd72f435@s.rendaw.me> (rendaw's message of "Sat, 4 May 2019 17:01:45 +0900")

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

rendaw <7e9wc56emjakcm@s.rendaw.me> writes:

> I've written up something similar here:
> https://gitlab.com/rendaw/blog/blob/master/how_to_guix_for_those_who_dont.md

Nice!  Thank you for sharing it.

> I think it would be great to have this information in the
> documentation!

I agree, but I am not sure how to merge the important parts with the
documentation in a way that does not clutter it up and make it even more
confusing than it already is.

> I'd also elaborate on what actually happens in the end
> ("If every service just extends other services, what does the root
> service do?"), how stuff actually runs (since operating systems are
> processes and not data after all -> I think the answer is that the boot
> service, activation service, and shepherd service all run processes but
> that leads to a lot of other obvious questions: what's the difference
> between the boot and activation services - or what do each do and what
> makes them suitable for those tasks, what order are processes started in
> each of them, how does guix deal with existing files created by
> activation processes when reconfiguring the system, etc), what is a
> service vs a service type, and an explanation of the folding process and
> how it relates to a service type definition.

Yes, explaining this could make for a good manual section or blog post.

>> The manual section is helpful
>
> I strongly believe the manual section is not helpful to anyone who
> doesn't already know how Guix works.

It's true that we could do a better job of introducing services in the
manual.

> Reading the source code is a colossal hurdle for users

I think this statement is perhaps over-broad, since "reading the source"
can mean "reading an operating system configuration file," which is
definitely easier than understanding Guix's services.  That said, I
agree that users shouldn't have to grok fold-services just to understand
how to use services in their operating system configuration.  The manual
tries to explain services, but it just doesn't get the job done, and we
should improve it.

> I hope this doesn't come off too aggressive.

I don't think it does, and I appreciate hearing your opinion.  I
actually felt exactly the same way as you, when I was first learning
about services.  It was frustrating.  As I learned, I submitted patches
to change the documentation where it was unclear or incorrect.  But it
still isn't good enough.  I've been thinking about trying to rewrite
that section in a way that makes it easier to understand services for a
first-time reader, but I haven't yet done it.

If you have ideas about how to improve the documentation, please
consider submitting a patch.  Coding can be hard, but so can
documentation.  Every little improvement can help!

-- 
Chris

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

  reply	other threads:[~2019-05-04  8:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-14 18:12 Services and log management/monitoring rendaw
2019-04-17 21:20 ` Ludovic Courtès
2019-04-18 15:11   ` rendaw
2019-04-19 12:09     ` Ludovic Courtès
2019-04-19 15:47       ` rendaw
2019-05-04  7:01         ` Chris Marusich
2019-05-04  8:01           ` rendaw
2019-05-04  8:24             ` Chris Marusich [this message]
2019-05-04  8:32               ` rendaw

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=87tvea4ogh.fsf@gmail.com \
    --to=cmmarusich@gmail.com \
    --cc=7e9wc56emjakcm@s.rendaw.me \
    --cc=help-guix@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.