From mboxrd@z Thu Jan 1 00:00:00 1970 From: rendaw <7e9wc56emjakcm@s.rendaw.me> Subject: Re: Services and log management/monitoring Date: Sat, 4 May 2019 17:01:45 +0900 Message-ID: <1a06849a-e399-47d9-e68a-e688fd72f435@s.rendaw.me> References: <67f09d8d-3ca6-90a0-6e72-c85ec9d1572f@s.rendaw.me> <87bm1472ha.fsf@gnu.org> <4428ea68-57fe-5459-0e26-529bc05d0b31@s.rendaw.me> <87imvaci2p.fsf@gnu.org> <8736lu66vd.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:36484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <7e9wc56emjakcm@s.rendaw.me>) id 1hMpcG-0006dT-Ki for help-guix@gnu.org; Sat, 04 May 2019 04:01:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <7e9wc56emjakcm@s.rendaw.me>) id 1hMpcF-0006iy-1c for help-guix@gnu.org; Sat, 04 May 2019 04:01:52 -0400 In-Reply-To: <8736lu66vd.fsf@gmail.com> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Chris Marusich Cc: help-guix@gnu.org On 5/4/19 4:01 PM, Chris Marusich wrote: > rendaw <7e9wc56emjakcm@s.rendaw.me> writes: > >> I'm fairly sure that's not what it means, but if extends isn't an >> inheritance relationship and it's not a dependency relationship I'm not >> sure what it is. > In this context, when we say that a service A extends a service B, my > understanding is that we mean that A changes (customizes) something > about B. It is definitely not inheritance. And because A changes > something about B, I don't think "A depends on B" is the best way to > think about it. > > For example, the guix-service-type extends the account-service-type. > The former provides the latter with a list of user and group accounts. > In this way, the guix-service-type tells the account-service-type what > users and groups the guix service needs in order to run. When you add a > service of the guix-service-type to your operating system declaration's > list of services (it's already there by default), the > account-service-type will know what users and groups are required by the > guix-service-type, and it will create them automatically. We say the > guix-service-type "extends" the account-service-type because the former > provides the latter with a list of users/groups to create. > > That is what we mean by "extension". Via this "extension" mechanism, it > is possible to make cross-cutting changes that affect many different > parts of the system, without making a bunch of changes to a bunch of > services. For example, if the tor-service-type also needs to create a > user account and group in order to do its job, it can simply extend the > activation-service-type, just like the guix-service-type did. And if > something about the way we create user accounts or groups needs to > change, we can change it for all users and groups just by modifying one > place: the account-service-type. > > You might be wondering: if the account-service-type is extended by user > and group accounts, how are other services extended? The answer is that > the type of object used depends on how the services are defined. The > services participating in the extension define their own contract, > within the confines of the general "extension mechanism" that Guix > provides. Many services document how they can be extended in the > manual, but some do not, and you might have to look at the source or > existing examples to figure it out, which is not so great. > > Note that if you dig into the code, you will find that the term > "extension" can also refer to a specific record type called > , described in the "Service Reference" section of the > manual, and defined in the gnu/services.scm file. If you want to learn > more about it, I suggest reading the manual and also the source code - > specifically the 'fold-services' procedure in gnu/services.scm, which is > where the actual extension mechanism is implemented. Wow, thanks for taking the time to write this up!  I believe that's a much clearer explanation - I actually figured it out by reading the source code extensively, but I thought this thread had been abandoned.  I've written up something similar here: https://gitlab.com/rendaw/blog/blob/master/how_to_guix_for_those_who_dont.md I think it would be great to have this information in the documentation!  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. > The manual section is helpful I strongly believe the manual section is not helpful to anyone who doesn't already know how Guix works.  The explanation of _everything_ related to services hinges on the word "extend" - and it's never defined!  It's a novel definition in this context, it's not a matter of ambiguity.  The definition of extends here is strongly tied to the folding procedure so both of those need to be in the documentation for a reader to gather an understanding of what's being discussed. Reading the source code is a colossal hurdle for users, and especially considering that this is a core service and the actual behavior is influenced by and influences hundreds of other pieces of code (unlike things like `(shell ...)` which get passed through to the end system interacting with relatively few other processes).  Knowing the big picture of how Guix works as a system, how components interact under the hood, etc. is critical because it lets you make an informed decision when you want to create a new service, it gives you hints on how to read arcane build errors, when the resulting system doesn't work it lets you know where things could be going wrong, and if you want to read more about a particular subject you know what topics/search terms/articles could be relevant. I hope this doesn't come off too aggressive.  I view myself as a user at this point and really want Guix to take off.  I spent the greater part of three weeks trying how to figure out how to get my new (fairly simple) Guix system running.  IMO if it takes most users (who want to do more than install X and then run ./x) three full-time weeks, breathing Guile, and source code diving to reach a usable point then Guix will never be able to achieve critical mass.