From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 34XvGkFPR2HqYwEAgWs5BA (envelope-from ) for ; Sun, 19 Sep 2021 16:54:57 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id kAUJFkFPR2HxWQAAB5/wlQ (envelope-from ) for ; Sun, 19 Sep 2021 14:54:57 +0000 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 6301815C25 for ; Sun, 19 Sep 2021 16:54:56 +0200 (CEST) Received: from localhost ([::1]:47744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRyDX-0001hs-ED for larch@yhetil.org; Sun, 19 Sep 2021 10:54:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58496) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRyDN-0001hi-4a for guix-devel@gnu.org; Sun, 19 Sep 2021 10:54:45 -0400 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:44180 helo=mail.yoctocell.xyz) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRyDK-0008En-2i for guix-devel@gnu.org; Sun, 19 Sep 2021 10:54:44 -0400 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yoctocell.xyz; s=mail; t=1632063274; bh=oDIDVrLO1Sg73soCiXhJXkIVp2Y+eok8BlxZu3rZIZU=; h=From:To:Subject:In-Reply-To:References:Date; b=ZeE2PRKeLwfUeqMGgVwQ3KQ8JIQVZVzboKIp46M14aYVfCnwSf1YZrLXQtTUxKple UM288txtXN9ubjYBMe5R0SYuaslPNYQzuzooxQfDt4i/JSYyCqSwwLhuiek33lAESg voSGAcWFhEoO6WDjA1xB7CeW0fLS+kYcaNXPOZS4= To: Andrew Tropin , guix-devel@gnu.org Subject: Re: On the naming of System and Home services modules. In-Reply-To: <87zgsb8mfo.fsf@trop.in> References: <87zgsei5ta.fsf@trop.in> <87pmtarnrh.fsf@yoctocell.xyz> <87zgscx2px.fsf@trop.in> <87h7ejpn4i.fsf@yoctocell.xyz> <87zgsb8mfo.fsf@trop.in> Date: Sun, 19 Sep 2021 16:54:31 +0200 Message-ID: <87zgs81uqg.fsf@yoctocell.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=87.96.130.155; envelope-from=public@yoctocell.xyz; helo=mail.yoctocell.xyz X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 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, FROM_SUSPICIOUS_NTLD=0.499, PDS_OTHER_BAD_TLD=1.999, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1632063296; 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=NSm6l02mgtzLtCM++AFWOG8wYJZMUO0jXU2rE2xPmeY=; b=aY3rVE6fTd3s7bWgJBOjJAHseAx8K95jYYI2KICH93L69YK4lSkYAsCpm2B9nbqQ+PhGS7 S/SVLqemXW1q0N7jYdnvnEVTRwj/kbVZY81kdQj65h54y3ls7TUDGplWzHTb4/gN0dLzdM LbJfddihsc7baTi1gQbz9fc6A1OiSyJpMOF2YYhTtf6loBLJ4wH8CaPSydLqiJ4SaFZdtY HQE2NTLMyTajzJy5LpXzx/TsKS6TUDQGrRcrdHEcneKOSvAwoDBEsrMaukFnxVEarKit0L oJXfEekiuWzXOdP7YfprhnLmII75UtgLpXuf0nRbioARqjfQkbF/nO1us3czrA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1632063296; a=rsa-sha256; cv=none; b=rNZbmV3z4vyOKdbOVp1yb21FKecC60rdGnijimRUDxKyvz8PNm48hMjs2mFiEGd5Fs5gM+ 3RdBMzoRcVsa+b2VHiLQATCI741njufGi21xIzSzY4s1zOb21eHn0481jbRsmQx3cLjZ4n 9r+doyKu/Q2IvHyOlehgHBJMR+96uofgtBd2OkzVzo36d0y2jcAcRUF0Y0eaCI0P54JwQK K8mFsE66REETE4AuS4odQ0Cp2q1sjf3fjYIfH80wXVb0G+rzaUDNiJNDPqPdvyYsl/vXME EoCk4Po3BBKb1d8328ID+IVXTGnRtfUxKBoVgTPYsiFbGh85zpsOSqmjD4ATRw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=yoctocell.xyz header.s=mail header.b=ZeE2PRKe; dmarc=pass (policy=none) header.from=yoctocell.xyz; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -5.19 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=yoctocell.xyz header.s=mail header.b=ZeE2PRKe; dmarc=pass (policy=none) header.from=yoctocell.xyz; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 6301815C25 X-Spam-Score: -5.19 X-Migadu-Scanner: scn0.migadu.com X-TUID: CL/8uJ0To2WU --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 17 2021, Andrew Tropin wrote: > On 2021-09-17 11:28, Xinglu Chen wrote: > >> On Thu, Sep 16 2021, Andrew Tropin wrote: >> >>>>> * Putting Home Services to ~(gnu services ...)~ >>>>> In the thread https://issues.guix.gnu.org/49419#18 Ludovic suggested: >>>>> >>>>>> Regarding module names: what about putting everything in the (gnu >>>>>> home =E2=80=A6) name space. For services, I wonder if we could simp= ly use >>>>>> (gnu services home), for the essential services, and other (gnu >>>>>> services =E2=80=A6) module, but that assumes some code can be shared= between >>>>>> System and Home. Thoughts? >>>>> >>>>> ** Shortcomings >>>>> While it's a nice idea, I see some shortcomings here: >>>>> >>>>> *** Code Reuse >>>>> Mcron, Shepherd and a few other fundamental pieces are reused between >>>>> Guix Home and Guix System, but it's easily done by exporting a few >>>>> symbols from related modules. >>>>> >>>>> Records even for the same services have slightly different fields and >>>>> because of macro nature can't be reused between Home and System >>>>> services. In more details I mentioned this problem here: >>>>> https://lists.sr.ht/~abcdw/rde-devel/%3C87y2cqifpx.fsf%40yoctocell.xy= z%3E#%3C878s4l8kai.fsf@trop.in%3E >>>> >>>> Some services might be useful to have in both Guix System and Guix Hom= e; >>>> for instance, Guix System currently has a service for configuring >>>> Syncthing, and I think it makes sense to also have one for Guix Home, >>>> this would mean that people not using Guix System (me :-)) could also >>>> have Guix manage Syncthing. With the current approach, we would have = to >>>> copy and paste quite a bit of code, and if the Syncthing service for >>>> Guix System changes, then the one for Guix Home might have to change as >>>> well. >>>> >>> >>> We can extract parts, which have to be in sync between home service and >>> system service and just use them in both. I don't see how placing home >>> service in the same module will decrease the amount of "copy-paste". >>> >>> If you talk about "shared" fields for configuration records, it's >>> probably true, but I don't see any good solution yet. I'm unhappy that >>> records are implemented with macros, because it complicates the >>> extensibility of the mechanism, wrapping them in more macros doesn't >>> make thing better IMO. >> >> Since we don=E2=80=99t have a way to avoid using macros for records, res= isting >> macros probably won=E2=80=99t really help much. :-) >> > > The fact that we already use them doesn't mean that we need to use more > macros, IMO it's a good idea to keep the amount of macros as small as > possible. > >>>> I have thought about a =E2=80=98define-configuration=E2=80=99 macro th= at would >>>> generate one configuration record for Guix system and optionally, >>>> one for Guix Home. For example >>>> >>>> (define-configuration syncthing-configuration >>>> ...) >>>> >>>> would work as it currently does, and >>>> >>>> (define-configuration syncthing-configuration >>>> ... >>>> (home-service? #t)) >>>> >>>> would generate a record and a >>>> record. >>>> >>>> There is the problem of and >>>> not having the same fields. To solve >>>> this, Each clause could have an =E2=80=98home-service?=E2=80=99 field,= and the code >>>> would look like >>>> >>>> (define-configuration syncthing-configuration >>>> (package >>>> (package syncthing) >>>> "Syncthing package to use.") >>>> (arguments >>>> (list-of-strings =E2=80=99()) >>>> "Command line arguments to pass to the Syncthing package.") >>>> (log-flags >>>> (integer 0) >>>> "Sum of logging flags.") >>>> (user >>>> (maybe-string 'disabled) >>>> "The user as which the Syncthing service is to be run." >>>> (home-service? #f)) ; not for Guix Home >>>> (group >>>> (string "users") >>>> "The group as which the Syncthing service is to be run." >>>> (home-service? #f)) ; likewise ^^ >>>> (home >>>> (maybe-string 'disabled) >>>> "Common configuration and data directory.") >>>> (home-service? #t)) >>>> >>>> This would mean that would have all the >>>> fields, but would have all but the =E2= =80=98user=E2=80=99 >>>> and =E2=80=98group=E2=80=99 fields. >>>> >>>> We could also have a =E2=80=98define-home-configuration=E2=80=99 macro= that would create >>>> a record and optionally, a >>>> record. Then =E2=80=98home-service?=E2=80=99 wou= ld be >>>> =E2=80=98system-service?=E2=80=99 instead. >>>> >>>> Maybe it=E2=80=99s too complicated and not worth it, but it=E2=80=99s = just an idea I >>>> have had. >>>> >>> >>> define-configuration is already a quite complicated macro, but maybe >>> something like that will work, still unhappy with tons of macros for >>> implementing records in scheme (: >>> >>>> >>>>> The intersection of home and system services should be very low, so >>>>> there is not much benifit here as well. >>>> >>>> Quite the opposite, I think it would be great if home and system >>>> services could integrate more with each other. >>> >>> The system and home services can't really integrate with each other at >>> least because of extension mechanism. >>> >>>> In NixOS, the NixOS modules and Home Manager modules feel like two >>>> very distinct things, and it=E2=80=99s not really easy to share things= between >>>> them. >>>> >>> >>> Yes, but with Guix System and Guix Home it's easier to keep them in sync >>> and share code between them because they are both a part of the same >>> repo. >>> >>> Going back to intersection: Yes, there are some services that are common >>> to Guix Home and System: mcron, shepherd and maybe a few more, but most >>> of the `guix system search .` is not relevant for user. >>> >>> Everything that can be implemented as a home service should implement >>> as a home service in most cases. >> >> Not really sure what you mean by this, but the above proposal would >> create a and a record. > > If something can be both home and system service we can prefer to > implement home service, because it can be used on both Guix System and > foreign distros. That could work, but a lot of problems/questions would also pop up; see some examples below. > Yes, I got your idea. > >>> There are two case, where you can bring an argument against it, but >>> I'll propose solutions upfront: >>> >>> - As admin I want to add a service in operating-system, but it's only >>> available as a home service. >>> >>> I think we can do something like that:=20=20 >>> >>> #+begin_src scheme >>> (operating-system >>> (services >>> (list (service guix-home >>> `(("USERNAME1" ,(generate-home-environment >>> with-needed-services))))))) >>> #+end_src >>> >>> - I want to start the home service on boot. >>> >>> Probably, something like linger systemd will be needed here for >>> Shepherd, still seems very possible to implement. >>> https://www.freedesktop.org/software/systemd/man/loginctl.html#enable-l= inger%20USER%E2%80%A6 >> >> That would be nice to have. >> >>> Yes, probably there are cases where we will need to have both system >>> and home services, but I expect this number to be very low and >>> everything else will fall in one category of services, this is what I >>> mean by small intersection. As an exercise try to name 10 services, >>> which doesn't belong to only one category. >> >> Well, there are quite a few that I can think of >> >> * The ones we have already mentioned: Mcron, Shepherd, and Syncthing. >> >> * Unattended-upgrade. >> >> * Rsync/state management. >> >> * guix-publish: As a normal user, I should be able to run a =E2=80=98guix >> publish=E2=80=99 service, to share substitutes with others, without ne= eding >> root access. >> >> * Mail related services: Getmail/Fetchmail/Isync can be used by a normal >> user for fetching their mail from some remote server. These programs >> can also be used by a server that hosts a Patchwork instance to track >> patches sent to a mailing list. I think this is what Christopher=E2= =80=99s >> Patchwork instance does. >> >> >> >> Dovecot/OpenSMTP/Exim can be used on a mail server, but they can also >> be used as a local IMAP server, which something like Gnus can connect >> to. >> >> I have also seen people use Postfix as a Sendmail/Msmtp replacement, >> and it would thus make sense to have a Guix Home service for it too. >> >> * Alsa: There is already an Alsa service for Guix System, but a user may >> also want like to configure their ~/.asoundrc file in order to not >> pollute the system configuration. >> >> * WeeChat can be used as an IRC client, and as a relay for other WeeChat >> clients to connect to. It would therefore make sense to have WeeChat >> running on a server (Guix System), and then connect to it through >> WeeChat as a regular user (Guix Home). >> >> * Shells: Each individual user will most likely configure their shell, >> but the sysadmin also might want the configure the system-wide shell >> and not just run with the default settings. >> >> There is also the problem of system service only working on Guix System, >> whereas home services will work on foreign distros as well. As someone >> who is on a foreign distro, I would like to configure things like Tor >> (and Privoxy), Transmission, Ipfs, Bitlbee, and a login manager and a >> desktop environment. But right now I have to be on Guix System to >> configure to these things. >> >> That=E2=80=99s just the ones I can think of; other people probably have = more >> things to add. >> > > I think most of this usecases are solvable by having only home services > and linger shepherd. > > For example an administrator can define a home-environment in > operating-system for weechat-relay user, which contains a WeeChat home > service, configured as a relay and setup it with `guix system > reconfigure`. Any other users can control their own home-environments > and configure and install their weechat clients with `guix home` That could work, then one would have to have lots of home environments if they had many services. Having a bunch of home environment would probably introduce quite a bit of overhead, compared to just running a service as another user. The configuration would also be quite a bit more complicated; instead of something like this: (operating-system (services (list (service dovecot-service-type ...) (service tor-service-type ...) (service weechat-service-type ...)))) It would look something like: =20=20 (operating-system (services (list (service guix-home `(("dovecot" ,(generate-home-environment ...)) ("tor" , (generate-home-environment ...)) ("weechat" ,(generate-home-environment ...))= ))))) And the user would also have to manually create the =E2=80=9Cdovecot=E2=80= =9D, =E2=80=9Ctor=E2=80=9D, and =E2=80=9Cweechat=E2=80=9D users and groups by extending the =E2=80=98ac= count-service-type=E2=80=99. These services would also start on boot regardless if there is any internet connection, because the Shepherd for the =E2=80=9Cdovecot=E2=80=9D= user isn=E2=80=99t aware of the networking =E2=80=98requirement=E2=80=99, which is only availa= ble for Guix System services. There is also the problem of what if the Dovecot service, which is a home service, has to extend something that is not a home service, e.g., =E2=80=98etc-service-type=E2=80=99 or =E2=80=98pam-root-service-type=E2=80= =99? =E2=80=98home-file-service-type=E2=80=99 can only create files in $HOME of the user, but a file might have to be put somewhere in /etc, which is out of reach of =E2=80=98home-file-service-= type=E2=80=99 for the =E2=80=9Cdovecot=E2=80=9D user. By having a bunch of home-services, something like =E2=80=98guix system extension-graph=E2=80=99 and =E2=80=98guix system shepherd-graph=E2=80=99 w= ould be a lot less useful, since a lot of things would be in home environments. It would make it harder for the user to visualize and understand how the system is built from all of these system services and home-service. If the Dovecot service became a home service, it would break backwards-compatiblity and break many peoples setups. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmFHTycVHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5Xn4QAJ1VZstqvyFIVl2wmUtTgDMrp2HC mUYmsxKMMXwxmgGdvKKfXXJxkBAB7+SuF71zcYjiFYYPTaywLbFwIBCpO04P9tEm eVmjFhLEu+3y+YTGJ7rTbZEVvj/YerBACd3rtPXcDb8OAhf5/BCKBDbSK73+/EfW 1wwMhJok2MGBfGeutBU+EosxX1p5wNHiMyyn3zi5imOO0hIIuL61i/a7MVDf+Mno HM7D/iYu8/+5kytggT0jATBUhhnY5z++KNJ0k4Zbaxz7Ea3dirJqAbDGk5CefsY0 Fcj5oKUOlP7QDMKUu1qaGntYyxOQtLrxc7gVJGScE/A/Lu0QukhtRYHYXnJMM3IG 55EGlh86OA1EO6iTakMIl1RmRrjxyplkEQBzmOj0Yn2QFHZr/UTWmrTB1mO9g383 tP54jcTz56Yw5tIl2Htyw6iE3u9MN/IxJZaiym66K79+io79J0edrq7Vb/8LFGD2 ivBMHpcWwXtyvHS7g7HYaccZ9djaXiAzkgmaRNRXfNDe+KxP/1NUxcoKDBqcSOUo O+l5pX+XXtT7SAzzJYBPo1hiVvd/RZNOf+kJcC7GLq+TKsm1J3nCp7kInPf+An2M 92qhzS5e7QbKz+opjBDdEc+CK3NLeh3CmRbNNyDZVz0jzkVJfhDjLee4G1GvrEKb URWhfkcNDpBG2hmC =0ukt -----END PGP SIGNATURE----- --=-=-=--