From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id gOKLB+K8rWKgXQEAbAwnHQ (envelope-from ) for ; Sat, 18 Jun 2022 13:54:10 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WGaFB+K8rWLaHAAA9RJhRA (envelope-from ) for ; Sat, 18 Jun 2022 13:54:10 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AC6D93B34E for ; Sat, 18 Jun 2022 13:54:09 +0200 (CEST) Received: from localhost ([::1]:60702 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2X1k-00045z-QA for larch@yhetil.org; Sat, 18 Jun 2022 07:54:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58544) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2X1Y-00045c-Fb for guix-devel@gnu.org; Sat, 18 Jun 2022 07:53:56 -0400 Received: from libre.brussels ([144.76.234.112]:55316) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o2X1V-0000kt-O5; Sat, 18 Jun 2022 07:53:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libre.brussels; s=mail; t=1655553224; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vEMy7FGTq0qNOcCVHK4vVuI3ohnIqQ/y1CUFDjOrE2o=; b=SE3Qsdt1ZZq5dTGsaLk34i5NyePdcLzcgRWFTydc5TEVC7sO1BwH5LegiPPpX9YCdmw4bb jILY8raJqgRRbbtxHgc2PTwiSf/jf58Rtmg4XyUDxQmyFf3VYfXkQZFoH9NLe8i/TN6jTz RtHfgC6OC2FjEIJATdBxLSB3iHMo250= MIME-Version: 1.0 Date: Sat, 18 Jun 2022 13:53:41 +0200 From: indieterminacy To: Brian Cully Cc: catonano@gmail.com, Blake Shaw , Ricardo Wurmus , Andrew Tropin , Josselin Poiret , GNU Guix maintainers , guix-devel@gnu.org Subject: Re: how to write services In-Reply-To: <87tu8krafm.fsf@ditto.jhoto.spork.org> References: <87a6as62r2.fsf@elephly.net> <87ilpfwmi0.fsf@jpoiret.xyz> <877d5j5vng.fsf@trop.in> <87a666663179c883aaa1797b62c3bcb0084d3ebb.camel@gmail.com> <87bkuuyqf9.fsf@elephly.net> <87tu8krafm.fsf@ditto.jhoto.spork.org> Message-ID: <1ad22337d0d03c6dc9e5abf03c4a0f9b@libre.brussels> X-Sender: indieterminacy@libre.brussels Organization: Icebreaker Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=144.76.234.112; envelope-from=indieterminacy@libre.brussels; helo=libre.brussels X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1655553249; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=vEMy7FGTq0qNOcCVHK4vVuI3ohnIqQ/y1CUFDjOrE2o=; b=cO0xatyLIVHtYP7aUDUyur0H38BzL/we9lBtzB8YBJxU94F5zeqSvow2DKugA2dOcMUGu/ G3wccRa+fu5g1NZDmGqxb/lYgGAlWOjSaqc+W4O0hoxKfTpfUPuMAZlABzhXGwNBxeWi1m znz1B0es4zZlKKnwLZLsVj7JB8wqKky0p2+NUChfHAZCPFm53FTcPhiNVYn+bXa4CnP1eD aOWV+qNdMmdiAzoua50M2IoRdGJhJzPMiZNVRGsOvqjKV36qxcUwWJtDHUYcvvFAdDM0Qu AhrbMRXkYXVu9TaSycQ2WfUL6Swve0uyZd22p1USc6TmZgYSupLFNHl6fhZ9YQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655553249; a=rsa-sha256; cv=none; b=FRbP+nUtAVuC/Cwp3dCcjmDcdUhYGviQ6xb83beAJ3OzLWi/ML1MvmA6+A84V/WvG5TtS1 /uf+MXyVgFecD7pGIWoBLVGZWe+yPI+En7Q7VwY527KLV7+xnEswYm8ajQDL+cZ7ipSh3G g5yiQP5Vc8VhQFEDoV7aIBsDLm+qhz8AmYKKVidMFS2WNKYB9R0D87LmGGssNJqqDVs0Wq /Jbho6c7EAaRr6yv8BmVSeB4dXKseZC2Y4FPNvdsizEPfMFO4DVRemMfT7LQi1PuU6sF/l SyWweR+qEA90ICVSXuVSJMrlgPwuAA5hbYZ+wRbSRueUWC2vt5KRlp/nqBLE8w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=SE3Qsdt1; dmarc=pass (policy=none) header.from=libre.brussels; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.99 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=SE3Qsdt1; dmarc=pass (policy=none) header.from=libre.brussels; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: AC6D93B34E X-Spam-Score: -3.99 X-Migadu-Scanner: scn1.migadu.com X-TUID: zk0tTUxtnNrm Hello Brian, On 16-06-2022 15:09, Brian Cully via "Development of GNU Guix and the GNU System distribution." wrote: > catonano@gmail.com writes: > >> I asked for indications about the process (what magic to use in the >> REPL) > > My experience with Guix, in general, is that the REPL isn't > particularly useful for any task beyond very simple testing (eg, what > are the contents of ‘%base-services’). It's a shame, but I suspect > it's like this because it's hard to make it more functional, and there > are more important problems to work on. Even though I would much > prefer to do almost all work with a REPL, I have not invested the > effort into figuring it out because I don't have the time or > expertise, currently. I can't fault anyone else for making similar > choices. > >> This should be covered in the cookbook > > I agree. The cookbook could use a lot of work. Guix's documentation > suffers in the middle ranges. There's a lot of very high level > overview, and all the low level bits are reasonably documented, but > there's very little on how to integrate them. > Personally, Im somebody who requires examples to hack off. As many as possible, to compare and contrast concepts and feed my imagination. I wish I could reach for any API to explore and extrapolate with the same ease as I do with a dictionary. Probably a cognitive failing from me getting into coding so late in life. As with many things, I rely on conversational models to wash over me, so MLs have been useful as filling gaps - though I have to be patient waiting for solutions and ideals to reveal themselves over time. The Guix mailing lists are hugely important to serve as the bridge between higher and lower level concepts. This method may not be optimal to or known by some hoping to users hoping to utilise Guix further however. Similarly, Im sure IRC/Matrix is useful, though I find the volume of the official (Matrix?) room to be like a firehose with its volume and too much to passively observe. > If we were building a house, it'd be like having instructions that > say: our house is made out of rooms. Then being given a bill of > materials for all the different types of nails, boards, etc that can > be used to build a house. There's no (or almost no) instructions for > how to use those parts to build the shepherd service room, or how to > connect the activation plumbing, etc. Unfortunately, those are the > instructions that are most important, I think. > I like the analogy. I feel that there is an information-governance issue in terms of competencies, knowledge and requirements not fully intersecting. Its not only because of the scale of the Guix community and as you mention the weaker middle layer but problems of time and perspective making it hard for specific solutions to find troubled users with minimal costs. In many respects its not only a problem of documenting and publishing - there needs to be something in place to help orchestrate connections in a way akin to pollination. Like the moribund efficacy of forums such as GitHub Issues, I do feel that the 'classic' model of SEO based search does not serve our individual or collective requirements. I have been nudged into considering RDF more proactively, it would be super if Guix related knowledge could be represented in a semantic form, as it could be that triples can serve to provide 'knowledge-corridors', which connect up aspects of the ecosystem in ways unintended by contributors. > I have been keeping notes on my process of learning Guix in the hopes > of starting something along these lines, but I'm not sure I'll ever > have the time to get around to it; and I'm not much of a writer, > besides. > You are a cogent and thoughtful writer so please write more and tell people when you make progress! My own research project, Icebreaker, has focused on trying to utilise GemText and augment it with minimal syntaxes to support domains such as knowledge-management and kanban boards. GemText's minimal syntax could allow you to write your thoughts down unimpeded and can be interpreted with ease. See Genenetwork's own approach to such concepts to see how such habits can build out over time: https://github.com/genenetwork/gn-gemtext-threads Midway through my NLNet grant (once a move past a hospice related issue), Ill be integrating two interpreters covering formats (GemText and Koutliner) and my own annotation system (Qiuy). https://git.sr.ht/~indieterminacy/1q20hqh_kq_parsing_gemtext https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean For me, this has put me in a situation whereby I can annotate anywhere and soon I shall have a graph of resources to inspect and extrapolate. To aid others comprehension and interoperability I shall be trying to map my opaque seeming annotation syntax into RDF, hopefully something positive can come from that phase. Additionally, based upon a decent demonstration on LMDB, I realised that my annotation system makes it more feasible to adapt documents into LDIF database-like-files (is that the correct terminology Maxime?) - potentially turning each document into an LDAP ready database. Should both things turn out to be actionable then Guix knowledge-management could become a question of the governance of chaining concepts to fit usecases. Fingers crossed. >> In fact Tryton modules are not python modules and there's a patch >> modifying how Tryton retrieves its modules in Guix >> >> Yet there's no service for Tryton > > This is the case for many packages. The good news(?) is that you can > create your services your operating system config, and if you can get > them working acceptably, send a patch. > >> I think the friction on how to write a service is not in the semantics >> involved >> >> It's more menial > > See above: there's no documentation for assembly. Everything I've > learned was from studying the source. > >> As I'm writing this, I noticed someone replied to my toot >> (here >> https://tines.spork.org/objects/a2ff7376-c9a2-4bbd-9307-a5374571edb4 ) >> >> as you can see, they also noticed a difference in the experience >> between creating home services and system services > > I wasn't following this thread at the time, and didn't know whether > you were talking about shepherd services or not. In terms of shepherd > services, yes, there's quite a difference (maybe it would be a good > idea to define a generic service type, akin to > ‘home-shepherd-service-type’ that only extends the > ‘shepherd-root-service-type’ with a shepherd service?). As I said > there, if you have questions, feel free to ask! I may not be able to > write the cookbook/how-to that I want to, but I can try to answer > questions and share what little knowledge I do have with a fellow > neophyte. > > However, for the types of services you'd add to the ‘services’ slot of > the home/operating-system config, I don't think there is much of a > difference; or maybe none at all. > >> Guix is being successful, these days but that's an exception in the >> free software world and more so in the GNU world > > I'm happy that Guix is growing, and more people are using it and > adding to it (I'm a recent adopter, too!). But I think it's still a > niche distribution, and it shows in things like the documentation, the > builds breaking, old or broken packages, etc. > > I want to be very clear on this point, though: I don't blame anyone > for this, and I don't mean to downplay anyone's work because of these > problems. Creating and maintaining a distribution, especially one as > different as Guix, is a tremendous amount of work, and it's frankly > incredible how well Guix does on such a small core crew. It's simply > impossible to have the same level of polish as a bigger, more > established distribution, with an order of magnitude (or more) > contributors. > >> I have a job now (and it has to do with Odoo), I also train in a gym, >> I >> like to spend the free time I have on the beach (as it's evident from >> my presence on the fediverse) so I don't know it's not like I have >> any >> slots to assign to attempt this > > We're, all of us, in a similar situation, and we're few in number > (relatively), with a lot of work to do. I think this explains the > state of Guix more than anything else. > > -bjc -- Jonathan McHugh indieterminacy@libre.brussels