From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4Wk0EtBfRGFXuQAAgWs5BA (envelope-from ) for ; Fri, 17 Sep 2021 11:28:48 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id iKVqDdBfRGH8UgAA1q6Kng (envelope-from ) for ; Fri, 17 Sep 2021 09:28:48 +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 3271DF0B8 for ; Fri, 17 Sep 2021 11:28:47 +0200 (CEST) Received: from localhost ([::1]:52456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRAAo-0002Ve-Bj for larch@yhetil.org; Fri, 17 Sep 2021 05:28:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRAAX-0002VH-2H for guix-devel@gnu.org; Fri, 17 Sep 2021 05:28:29 -0400 Received: from h87-96-130-155.cust.a3fiber.se ([87.96.130.155]:54670 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 1mRAAS-0002yb-BR; Fri, 17 Sep 2021 05:28:28 -0400 From: Xinglu Chen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yoctocell.xyz; s=mail; t=1631870897; bh=7FOZAISY4RPl+2kmRwro9lKM9RAS7cTg6aXGn+dkCEI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=hJUrLRl8Nnlh+56qog6KJFA6OkOAxgn9zIX0yBjjhHqJGPpEniPV6QynOLyihWgv0 FOQhYKYWRdbxQNDnnXw+NYyywXpCmpXApPQxkUbuN0JtMt0YDjwYWsMKGz5Ht2KLdA i2tSnQTamRsXJGfcpaBVWbKyx2X4rza/Sd0GRcNU= To: Andrew Tropin , guix-devel@gnu.org Subject: Re: On the naming of System and Home services modules. In-Reply-To: <87zgscx2px.fsf@trop.in> References: <87zgsei5ta.fsf@trop.in> <87pmtarnrh.fsf@yoctocell.xyz> <87zgscx2px.fsf@trop.in> Date: Fri, 17 Sep 2021 11:28:13 +0200 Message-ID: <87h7ejpn4i.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.5, 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: , Cc: Sarah Morgensen 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=1631870927; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=72ymsIpYl77ZvmWLAAOzVbK9KXfIKsh52aieVr66+m8=; b=QV7IeRnyiNGV/FxRyVHdVGAnhatx6EIHWJqcwwysKoE6cfr13z0iXRPhshQu5s4LD1tywx ujcJdzp1ioDwk+1SkH3L+P+TjDou/+CTPF+V9IuMrkikZ4gWEr0Qip3mN5fhsjLRbeevVj 1+bNBiHScBnZ4Ri7Y6p5L/cykECa1PhJnj3oPQMRaILCRZBljZaDKGJhWOJiKzreVE3bWK cmOiT5wabS1DMw3TehgyNzpzr2/53bCFCZyzQEV2LphltlO5ViH3dkkgUwicV2uUtRjmts 96XeqqTcVDbRROph255y5Z/8URM90sPKl90Y9zlcrk0qtxerYHUc8xsL2Ij3rA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631870927; a=rsa-sha256; cv=none; b=KhFIf+bg3hyyU52n3K+JotjZeEFrWEiVwxJBsv2BJMwQVSLHdKml8dS2XlAUK5l3x4pTIb 5igFL9n/U92N6/pTycTM0H7pezjw7QpI3ggVeM+grDKtQQKw0UQ+znZs5No6D5jSPDBX+X e864Li3QKNjR5eMvlRQpS50RlSYzQPsLi71rTsSthVp/wCqRKUFu05UJdiA87fgeJ7cQau yHCT4aLp7gZwacw56+gNLRxJHq662ipoR4+K0Pl/T6vt+M4VLVutPH/KWi3enbBnbfagjJ yAO74qc5y0nOs5X2auw5WX5nitCbKoU2cjbI5Bqn3SR0TTgFZiCa+FqXowLTvw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=yoctocell.xyz header.s=mail header.b=hJUrLRl8; 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: -3.39 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=yoctocell.xyz header.s=mail header.b=hJUrLRl8; dmarc=fail reason="SPF not aligned (relaxed)" header.from=yoctocell.xyz (policy=none); 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: 3271DF0B8 X-Spam-Score: -3.39 X-Migadu-Scanner: scn0.migadu.com X-TUID: Wfq7yJLSUqZ3 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 simply= use >>>> (gnu services home), for the essential services, and other (gnu >>>> services =E2=80=A6) module, but that assumes some code can be shared b= etween >>>> 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.xyz%= 3E#%3C878s4l8kai.fsf@trop.in%3E >> >> Some services might be useful to have in both Guix System and Guix Home; >> 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, resist= ing macros probably won=E2=80=99t really help much. :-) >> I have thought about a =E2=80=98define-configuration=E2=80=99 macro that= 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, a= nd 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 t= hat would create >> a record and optionally, a >> record. Then =E2=80=98home-service?=E2=80=99 would= 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 ju= st 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 b= etween >> 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. There would then be a =E2=80=98NAME-service-type=E2=80=99 and a =E2=80=98home-NAME-service-type=E2=80=99. > 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-lin= ger%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 needi= ng 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. >> A while ago, someone on IRC mentioned that it would be nice to have >> Mcron in Guix System run Mcron jobs that were specified in Guix Home. >> The rationale is that Guix Home for a user will not activate---run >> user Shepherd, thus running Mcron---until that user logs in. This >> means that Bob=E2=80=99s Mcron jobs will only run when Bob is logged in.= The >> Mcron jobs in specified in Guix System will run regardless if the user >> that those jobs belong to logs in. But if Bob wants their Mcron jobs >> to run regardless if he logs in, he needs root access to be able to >> add jobs to his Guix System config and run =E2=80=98guix system reconfig= ure=E2=80=99. >> This does mean that the sysadmin has to add =E2=80=98mcron-service-type= =E2=80=99 to >> the =E2=80=98services=E2=80=99 field of the record, t= hough. >> > > Covered by linger idea mentioned above. The downside is it won't be > visible in root's herd cli, but it also fixable either by extending > shepherd or by using su to run herd from specific user. > >>> Utilitary functions like serialization helpers and so on can be >>> declared in a shared module and reused between System and Home >>> services. >>> >>> Recaping the section: All the necessarry code already reused, the >>> future home/system services are not expected to share much code, >>> different utilitary functions can be shared via (gnu services utils) >>> or (gnu services configuration) modules. >>> >>> *** Confusion >>> I already mentioned that I see a lot of confusion between System and >>> Shepherd services and I expect some confusion between home and system >>> services, it will be especially true if we place them in the same >>> namespace. >>> >>> People will be trying to use home services inside operating systems, >>> #+begin_src scheme >>> (operating-system >>> (services >>> (list (service home-mcron-service-type ...)))) >>> #+end_src >>> >>> and configuration record for system services inside home services. >>> #+begin_src scheme >>> (home-environment >>> ... (service home-mcron-service-type >>> (mcron-configuration ...))) >>> #+end_src >> >> With the above proposal, the user would use =E2=80=98home-mcron-configur= ation=E2=80=99 >> for home service, so I don=E2=80=99t think this should be a problem. An= d as >> Maxime mentioned, we could have a =E2=80=98validate=E2=80=99 field which= would give a >> friendly error message if the wrong configuration record was given. >> >>> ** Summary >>> Let's keep System and Home services separate for the sake of clarity, >>> reuse code via shared modules or just exports in (gnu services ...). >>> >>> * Putting Home Services to ~(gnu home services ...)~ >>> Another idea I saw is to move: >>> ~(gnu home-services)~ -> ~(gnu home services)~ >>> ~(gnu home-services gnupg)~ -> ~(gnu home services gnupg)~ >>> ... >>> >>> Sounds reasonable, I'll just mention the ideas behind ~home-services~ >>> name. >>> >>> System services have following naming conventions for the public API: >>> >>> in ~(gnu services CATEGORY)~ there are ~APP-service-type~, >>> ~APP-configuration~ and other related symbols. >>> >>> Not to be confused, I decided to prefix all service types and >>> configurations with ~home-~, so the exported symbols looks like: >>> ~home-APP-service-type~ and ~home-APP-configuration~. >>> >>> The same rule applies for module names: We do the same way as system >>> services do, but with ~home-~ prefix: ~(gnu services CATEGORY)~ for >>> system, ~(gnu home-services CATEGORY)~ for home. >>> >>> All namespaces containing ~system~ now becomes ~home~: ~(gnu system)~ a= nd >>> ~(gnu home)~ respectively. >>> >>> I find such approach to be consistent and doesn't see to much reasons >>> to change it. >>> >>> However, ~(gnu home services ...)~ also looks cool, but it would be a >>> little inconsistent with system services, which will have one level of >>> nestiness less: ~(gnu services)~. >>> >>> IMO, ~(gnu home services ...)~ would be a good choice if we use ~(gnu >>> system services)~ for system services. >> >> Yeah, having both (gnu system service) and (gnu home service) could make >> sense, but since we only have (gnu services), I don=E2=80=99t think it m= akes >> much sense. >> > > Just to clarify, by ..., I meant submodules, so it will be > (gnu system services version-control) and > (gnu home services version-control) for example. Sorry, I forgot to add ...; I meant (gnu system services ...) and (gnu home services ...). > For now it's just: > (gnu services version-control) and > (gnu home-services version-control), which I find okeish. I would prefer to just have everything verson-control-related in (gnu service version-control). Since everything is prefixed with =E2=80=98home-= =E2=80=99, it should make things clear that its used by Guix Home and not Guix System. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmFEX60VHHB1YmxpY0B5 b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5b9YP/3BAi8cA7o9lViab7yPu3EkkmUTV IliS5Z9m4kT05XMKoEJGkmR0UNymn37gbnfipmybCLve67B1FOZK4vtioHpfRr2r pSzOf7CVvOFEeBLAM/Z2AGrsiA2YBgHFE1o3hnUocMMDT8jQ43bOgus5D1tINoav QoKGnfw1/6gdLzHioYxizK6UEpb80cEPKCNx1LqqMBZQgZdwQgs7yFvEad+8Oi5R rTDkt9Sao/Q7EiX3SUomC8koyNkl480TWumom2FD43QnTx1Whz6oOK58Ob1yxi9e nhKry9DN6Xx7Dz6ULod0MBp0xXSPN4jb94sZgOGo54x4GrMIrAlX7fUTylupaTVL 84PygIN391KQXpmVsftP2Wqz3TF5L10TmwUV2xjCbW9/xsel8xvN3j4eBKzL/k/0 8XXzD4WdENiRVbxbk0ilPjNhgIT5v3hPEKuXs2EdNM8o7Ekg+aCsvaJ41EfRmZJq bbpmv7OyJo922VXx13Tfx8RoIqvr0tknV8DsvUTJwsW9gBraSs2vjbZgIDOSumnq Ud0svKeh4BwmOG3mSqC5o0cK9SsFzSKemhOe4YRJGNexkx+9XuRyDL6yDAcab5mY NAZjUO4fcvtKaDawx89d7IVSEuFQonyQITM7i1QfWBoEQKEqmBa1rCcKjWRoWxWq BYK89+KaQhOuxBUF =x0U9 -----END PGP SIGNATURE----- --=-=-=--