From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id cPCPMiQh0mW76wAA62LTzQ:P1 (envelope-from ) for ; Sun, 18 Feb 2024 16:24:20 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id cPCPMiQh0mW76wAA62LTzQ (envelope-from ) for ; Sun, 18 Feb 2024 16:24:20 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=rdklein.fr header.s=zoho header.b=edMA9l2w; 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"; dmarc=none; arc=pass ("zohomail.eu:s=zohoarc:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1708269860; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=vKuAwzp9gF9NXyezIMo4RJwgapo9dQHjqPIBdV5leAo=; b=Yr8GqDPTRLWiVuT/JU5uFG/vLaISRcAXXybIYgz0a6KHTAenJRsP4ZfktozdMZJjFHFUMr PHgAZ6hEArh8UlwL1QxbQlaPyFkGhXAR3XjMCIO99ZRoHE5Z2zE6vohc7JpZ8rFcRzI2WF lwRMet2B6LfDw5DxXPk3pe/6TGkaLFhpGNWaE6T9PRmu0HW/wyneMDgCwUGtVC66D6mswi hoRP6OraMiw7n4tbepOoo4O5NvC9pAdcBCVZ/EmSBNUbOpb29DWLEPvJdjqNGZ7LzXAs0L PznZuI6ng2dQs1xIvdPplG/7B2/MXZdxa/Sl795/5Xj+FNTK+pkS8KtdfCj+XQ== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=rdklein.fr header.s=zoho header.b=edMA9l2w; 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"; dmarc=none; arc=pass ("zohomail.eu:s=zohoarc:i=1") ARC-Seal: i=2; s=key1; d=yhetil.org; t=1708269860; a=rsa-sha256; cv=pass; b=iFKYS0iYafAMYUWDnRRo/B/Kk9k26HkqcMwuluVo/HCFxvjpvC4zEmqSrd5O9gDFh6dng/ qlY8R0gEw2Wr+YOt+ZK/gcbL6ptgTfrlT7sHQbFceb5hYkRrv+wYkXDEw3FdufwWsXDwxz EgTXPpYcvq3xCzlELCIK2GK3P76vLec+AV6KqG4CXSnCm05l3iEsctoX2R8ns+Qb5AEbGE C2kLTFicVG3Tv4Rvn7WtLtHAcP0+ENXpdFuZBK8+GX1SlGaOPXURNXFj/2QeZpEuN/TZmO DLt3hokv6Hw3cPq/R8q9jr2bndkT+ZXniwWE/7+qC+gqu2jWyqL8TQK8pVY/vQ== 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 A5F8D1AF3E for ; Sun, 18 Feb 2024 16:24:20 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rbj15-0003Dd-3L; Sun, 18 Feb 2024 10:23:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rbj13-0003DT-UR for guix-devel@gnu.org; Sun, 18 Feb 2024 10:23:41 -0500 Received: from sender-op-o9.zoho.eu ([136.143.169.9]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rbj11-0006Yd-Jm for guix-devel@gnu.org; Sun, 18 Feb 2024 10:23:41 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1708269815; cv=none; d=zohomail.eu; s=zohoarc; b=b/y53dO05rw5+UmucsyMmmLyeQhdJ+3VMNM9IN0HKmZd60gW4uQwV4QEK2Y6VZ9xEYpv45qogE9ZaQukZidDiPQzFxhyHUEOtlKUvaI13BkIo9GaondpPUGRY0DYmd2p6Xkc1BX6tVNMuSSnoG3cufVtxzlzNfWlfs5IpaqTuk8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1708269815; h=Content-Type:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=vKuAwzp9gF9NXyezIMo4RJwgapo9dQHjqPIBdV5leAo=; b=ZbWgwCF6g6FsAbbtRC6rudOnT80zDDQCSMZXcSXgYDf3ZBc+WDmiHg+LvkakQn9eoSj6XNDnCA5uF+khsnPLTggsrNHksMgLrE8XVUTTHNo/WQXrRN4lECFCqU2JWFpQkoiIys/tkV8j/vTP82YupUuMfm8YvnyxOlXAhWmoRmw= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=rdklein.fr; spf=pass smtp.mailfrom=edou@rdklein.fr; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1708269815; s=zoho; d=rdklein.fr; i=edou@rdklein.fr; h=References:From:From:To:To:Subject:Subject:Date:Date:In-reply-to:Message-ID:MIME-Version:Content-Type:Message-Id:Reply-To:Cc; bh=vKuAwzp9gF9NXyezIMo4RJwgapo9dQHjqPIBdV5leAo=; b=edMA9l2wHx0FMnVRUBZIpVuw66ntT7ZVsnk1WsiVHgR3579p3P30ihJ2O9K6pn+y xwcq6qtZX3PD5cY9UFpEHEaFzMRzeEahbhgg6QbOZrIm6w59rWdJZM1GjAkOtZrY84q +0R+cKGAbmCfASb25iFjkgWfpNW1ZSCBYM2WMPmvY5/yuJww2Ckuu8Ch41cak8DbRpA BG466xQp0C+vWpZ5QE5z+VQUA9UJyfQ0X9gFxoUjzprRSTxFts9Vmh0/B1StwkJvlSK uDTSqX0lpNpqp1ha3Y8pQAoDL309QwC97X7gghwX2SdgPohMTDx7CImrB4SLeFrQqd/ k6KbiXswZw== Received: from venerable (S0106f0f249e3cfa3.ek.shawcable.net [174.0.73.86]) by mx.zoho.eu with SMTPS id 1708269811860963.5562970211333; Sun, 18 Feb 2024 16:23:31 +0100 (CET) References: <87wn377rst.fsf@rdklein.fr> <877cm6reum.fsf@rdklein.fr> <52c2337b277721108e5e7cdd6ea32e37e3c20628.camel@gmail.com> <8734wsqwrh.fsf@rdklein.fr> <33976deaf13ce785edefa6ac1b3610054dd4a031.camel@gmail.com> <87v89op6f2.fsf@rdklein.fr> <87ttp4jfiy.fsf@lease-up.com> <4H69vnQJrUA5WrVPVfQknwCz2ymq8NFyOnp0cCuqZiUVpSAwp6QAhonzbnSpsuRZJcZUX4dmV-U-qhV7CXNH5UOaGV8IEaL2fY8qXmPnmns=@lendvai.name> <87frycl3cm.fsf@lease-up.com> User-agent: mu4e 1.8.9; emacs 28.2 From: Edouard Klein To: guix-devel@gnu.org Subject: Re: Introducing Guix "Features"! (Was: Syntactic Diabetes) Date: Sun, 18 Feb 2024 16:07:53 +0100 In-reply-to: <87frycl3cm.fsf@lease-up.com> Message-ID: <87jzn1lrti.fsf@rdklein.fr> MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.169.9; envelope-from=edou@rdklein.fr; helo=sender-op-o9.zoho.eu 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -8.52 X-Spam-Score: -8.52 X-Migadu-Queue-Id: A5F8D1AF3E X-TUID: 4Sy+UoCvlZQN Weighting in here, as small as my weight may be: - re-using 'service' is IMHO a bad idea, it is a loaded term and the expectation of a new reader is that a service is a SysV-init service: it can be started, status-ed, stopped, restarted, and that's it. It maps to a daemon running in the background. Basically a shepherd service. - The fact that systemd service maps in functionality to guix services should be a huge redflag that the name is not good. Systemd sucks for many reasons, and using confusing and incosistent language is one of them. - I agree that 'features' is a worse name, way too generic. - Descriptive linguistics would consider the broader and historical use of the term in the UNIX crowd from which guix users are drawn, instead of the in-group use, which, despite being admitedly well documented and rooted in the history of the project, is overloading a close-but-not-exactly-matching term. I can not emphasize enough how much those subtle unexpected problems make adopting guix very hard. I pushed through because I understand that the project is fundamentally sound and worthwhile, but for a few years I have made interns and colleague work with guix and saw their motivation die by a thousand cuts because of confusing stuff like this. Finding a better term would be a worthwhile endeavour, for ease of adoption. Maybe we should dedicate a session for it in the next guix days ? - At os-declaration time, ALL guix services can be added, extended, modified, and removed. Discovering this and the difficult-to-write syntax that goes along with notably the extension, led me to the syntactic sugar we were initially discussing. - At os-reconfiguration time, SOME guix services will do their thing - At os-boot time, SOME guix services will do their thing - At os-running time, SOME (the shepherd kind) guix services can be stopped, started, statused, doced, custom-actioned, and restared - Understanding these behaviours may help use find an naming ontology that would foster understanding and adoption. Note that I don't disagree that service is a good name in *isolation*, I just want to emphasize, as Attila did, that ignoring beginner's expecations (however obsolete they may seem to be) is detrimental to the project's adoption. Cheers, Edouard. Felix Lechner writes: > On Thu, Nov 30 2023, Attila Lendvai wrote: > >> the use of 'service' to describe two rather different abstractions: a >> component of an OS vs. a deamon process run by shepherd. > > Indeed, the use of 'service' in much of Guix appears to be a grand > misnomer. It probably occurred because the meaning expanded over time. > > It's like we are looking back in time at the Big Bang. Our "services" > are the microwave echoes of Guix's initial, creative spark! > > Please consider a recent, helpful reply to help-guix. [1] Carlo > mentioned the term "service" eleven times, but none of them referred to > what I believe most readers of this message would call a service in > other contexts. What's a newbie on help-guix to think? > > Should Guix services instead be called "features"? > > Those "features" are central to any operating system definition. Other > choices like "provider" may not fully capture our collective uses > throughout the code and the documentation. I am especially thinking > about 'modify-features' and '%base-features'. > > Kind regards > Felix > > [1] https://lists.gnu.org/archive/html/help-guix/2024-01/msg00213.html