unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* On the naming of System and Home services modules.
@ 2021-09-15  8:47 Andrew Tropin
  2021-09-15 10:09 ` Maxime Devos
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Andrew Tropin @ 2021-09-15  8:47 UTC (permalink / raw)
  To: guix-devel; +Cc: Xinglu Chen

[-- Attachment #1: Type: text/plain, Size: 5639 bytes --]

This topic was raised a few times during development of Guix Home
project and also during the review of wip-guix-home branch.  I made a
separate thread to do an exhaustive discussion of it.

* Services and Confusion
It's an optional section, you can skip it, but I still find it somehow
related to the topic.

I want to re-raise the issue related to system services concept.  When
I started using Guix I found system services to be confusing,
originally I thought it's a way to declare services managed by init
system, but later I realised that only some of system services becomes
Shepherd services and many of them doesn't.  It's not a unique problem
I see this issue appear again and again in different Guix chats and
communities.

- System services :: just building blocks, nodes of DAG representing
a system, which after folding, results in a complete operating system
or other artifact.
- Shepherd services :: long-living processes/daemons managed by init
system or user-space Shepherd. It's what people used to refer as services.

It will be very hard and costly to rename system services to something
less confusing, but at least let's try to keep those concepts as
distinct as possible.  Probably originally system and Shepherd
services were closely related, but not now, so let's express it very
clearly in docs/chats/mailing lists.

Another player on this field is "home services", which is a similar to
system services, but used for describing a separate DAG, which after
folding, results in home environment (artifact containing user's
program configurations and profile with packages declared by user).

* 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 …) name space.  For services, I wonder if we could simply use
> (gnu services home), for the essential services, and other (gnu
> services …) 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.xyz%3E#%3C878s4l8kai.fsf@trop.in%3E

The intersection of home and system services should be very low, so
there is not much benifit here as well.

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

** 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)~ and
~(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.

* Conclusion
I'm quite satisfied with current state of naming, but probably I miss
some points and, also, maybe there are some other good or even better
naming schemes.  In case there is a better naming approach, we can
decide on using it, It would be not an easy change, but until
wip-guix-home branch is not merged, it still easier to do this than do
it later.

LMKWYT.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-15  8:47 On the naming of System and Home services modules Andrew Tropin
@ 2021-09-15 10:09 ` Maxime Devos
  2021-09-15 13:15   ` Andrew Tropin
  2021-09-15 13:06 ` Xinglu Chen
  2021-09-16  3:05 ` Ryan Prior
  2 siblings, 1 reply; 13+ messages in thread
From: Maxime Devos @ 2021-09-15 10:09 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel; +Cc: Xinglu Chen

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

Andrew Tropin schreef op wo 15-09-2021 om 11:47 [+0300]:
> *** 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

What do you think of adding some validation code to 'service-type'
and the "guix home" equivalent, e.g. a ‘validate’ field, which
could be used like

(define-module (...)
  #:autoload (gnu home??? mcron) (mcron-user-configuration?))

(define mcron-service-type
  (service-type (name 'mcron)
                ...
                (validate
                  (lambda (config)
                    (cond ((mcron-configuration? config) #t)
                          ((home-mcron-configuration? config)
                           ;; TODO: figure out a clear error message
                           (validation-error (G_ "A mcron configuration for the system was expected, but a configuration for the user was used")))
                          (#t #f))))))

and likewise for the "guix home" equivalent, such that if user configurations
are used in the system configuration, an error message is printed, indicating
the issue?  Maybe include the line and column number of the record as well.

Greetiings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-15  8:47 On the naming of System and Home services modules Andrew Tropin
  2021-09-15 10:09 ` Maxime Devos
@ 2021-09-15 13:06 ` Xinglu Chen
  2021-09-15 14:50   ` Katherine Cox-Buday
  2021-09-16  9:57   ` Andrew Tropin
  2021-09-16  3:05 ` Ryan Prior
  2 siblings, 2 replies; 13+ messages in thread
From: Xinglu Chen @ 2021-09-15 13:06 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel

[-- Attachment #1: Type: text/plain, Size: 9798 bytes --]

On Wed, Sep 15 2021, Andrew Tropin wrote:

> This topic was raised a few times during development of Guix Home
> project and also during the review of wip-guix-home branch.  I made a
> separate thread to do an exhaustive discussion of it.
>
> * Services and Confusion
> It's an optional section, you can skip it, but I still find it somehow
> related to the topic.
>
> I want to re-raise the issue related to system services concept.  When
> I started using Guix I found system services to be confusing,
> originally I thought it's a way to declare services managed by init
> system, but later I realised that only some of system services becomes
> Shepherd services and many of them doesn't.  It's not a unique problem
> I see this issue appear again and again in different Guix chats and
> communities.
>
> - System services :: just building blocks, nodes of DAG representing
> a system, which after folding, results in a complete operating system
> or other artifact.
> - Shepherd services :: long-living processes/daemons managed by init
> system or user-space Shepherd. It's what people used to refer as services.
>
> It will be very hard and costly to rename system services to something
> less confusing, but at least let's try to keep those concepts as
> distinct as possible.  Probably originally system and Shepherd
> services were closely related, but not now, so let's express it very
> clearly in docs/chats/mailing lists.
>
> Another player on this field is "home services", which is a similar to
> system services, but used for describing a separate DAG, which after
> folding, results in home environment (artifact containing user's
> program configurations and profile with packages declared by user).
>
> * 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 …) name space.  For services, I wonder if we could simply use
>> (gnu services home), for the essential services, and other (gnu
>> services …) 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.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.

I have thought about a ‘define-configuration’ 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 <syncthing-configuration> record and a
<home-syncthing-configuration> record.

There is the problem of <syncthing-configuration> and
<home-syncthing-configuration> not having the same fields.  To solve
this, Each clause could have an ‘home-service?’ field, and the code
would look like

  (define-configuration syncthing-configuration
    (package
     (package syncthing)
     "Syncthing package to use.")
    (arguments
     (list-of-strings ’())
     "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 <syncthing-configuration> would have all the
fields, but <home-syncthing-configuration> would have all but the ‘user’
and ‘group’ fields.

We could also have a ‘define-home-configuration’ macro that would create
a <home-NAME-configuration> record and optionally, a
<NAME-configuration> record.  Then ‘home-service?’ would be
‘system-service?’ instead.

Maybe it’s too complicated and not worth it, but it’s just an idea I
have had.

> 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.  In NixOS, the NixOS
modules and Home Manager modules feel like two very distinct things, and
it’s not really easy to share things between them.

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’s 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 ‘guix system reconfigure’.  This does mean that
the sysadmin has to add ‘mcron-service-type’ to the ‘services’ field of
the <operating-system> record, though.

> 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 ‘home-mcron-configuration’
for home service, so I don’t think this should be a problem.  And as
Maxime mentioned, we could have a ‘validate’ 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)~ and
> ~(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’t think it makes
much sense.

> * Conclusion
> I'm quite satisfied with current state of naming, but probably I miss
> some points and, also, maybe there are some other good or even better
> naming schemes.  In case there is a better naming approach, we can
> decide on using it, It would be not an easy change, but until
> wip-guix-home branch is not merged, it still easier to do this than do
> it later.
>
> LMKWYT.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-15 10:09 ` Maxime Devos
@ 2021-09-15 13:15   ` Andrew Tropin
  0 siblings, 0 replies; 13+ messages in thread
From: Andrew Tropin @ 2021-09-15 13:15 UTC (permalink / raw)
  To: Maxime Devos, guix-devel; +Cc: Xinglu Chen

[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

On 2021-09-15 12:09, Maxime Devos wrote:

> Andrew Tropin schreef op wo 15-09-2021 om 11:47 [+0300]:
>> *** 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
>
> What do you think of adding some validation code to 'service-type'
> and the "guix home" equivalent, e.g. a ‘validate’ field, which
> could be used like
>
> (define-module (...)
>   #:autoload (gnu home??? mcron) (mcron-user-configuration?))
>
> (define mcron-service-type
>   (service-type (name 'mcron)
>                 ...
>                 (validate
>                   (lambda (config)
>                     (cond ((mcron-configuration? config) #t)
>                           ((home-mcron-configuration? config)
>                            ;; TODO: figure out a clear error message
>                            (validation-error (G_ "A mcron configuration for the system was expected, but a configuration for the user was used")))
>                           (#t #f))))))
>
> and likewise for the "guix home" equivalent, such that if user configurations
> are used in the system configuration, an error message is printed, indicating
> the issue?  Maybe include the line and column number of the record as well.
>
> Greetiings,
> Maxime.

Hi Maxime,

Nice idea and viable solution, but here I was talking about the case,
when both home-mcron-service-type and mcron-service-type in the same
(gnu services mcron) namespace.  I expect much less confusion and it
probably won't be an issue, when they are in different modules (gnu
home-services mcron) and (gnu services mcron) for example.  If person
imports (gnu services SOMETHING) than they expect to get system services
for their operating-system, if they imports (gnu home-services
SOMETHING) they want to extend their home-environment. 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-15 13:06 ` Xinglu Chen
@ 2021-09-15 14:50   ` Katherine Cox-Buday
  2021-09-16 10:01     ` Andrew Tropin
  2021-09-16  9:57   ` Andrew Tropin
  1 sibling, 1 reply; 13+ messages in thread
From: Katherine Cox-Buday @ 2021-09-15 14:50 UTC (permalink / raw)
  To: Xinglu Chen; +Cc: guix-devel, Andrew Tropin

Xinglu Chen <public@yoctocell.xyz> writes:

> On Wed, Sep 15 2021, Andrew Tropin wrote:

>> 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.

I agree with this point. I have several Guix systems, and several
non-guix systems with Guix managing some services. In the past, I have
had to write my own Shepherd services for things already written as
system services.

>> 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.  In NixOS, the NixOS
> modules and Home Manager modules feel like two very distinct things, and
> it’s not really easy to share things between them.

I agree.

>> ** 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 ...).

[...]

>> 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’t think it makes
> much sense.

I haven't put in the energy to follow the rational behind the proposed
naming schemas, but I'd like to suggest this as well: =(gnu services
home)=. This namespace increases in specificity, and I think it would
easily follow that things in =(gnu services home)= might utilize things
in =(gnu services)=. Or I also like the idea of =home= and =system=
being sibling namespaces.

-- 
Katherine


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-15  8:47 On the naming of System and Home services modules Andrew Tropin
  2021-09-15 10:09 ` Maxime Devos
  2021-09-15 13:06 ` Xinglu Chen
@ 2021-09-16  3:05 ` Ryan Prior
  2021-09-16  8:50   ` Andrew Tropin
  2 siblings, 1 reply; 13+ messages in thread
From: Ryan Prior @ 2021-09-16  3:05 UTC (permalink / raw)
  To: Andrew Tropin; +Cc: guix-devel, Xinglu Chen

On Wednesday, September 15th, 2021 at 8:47 AM, Andrew Tropin
> People will be trying to use home services inside operating systems, and configuration record for system services inside home services.

I think it will be a dismal design failure if we cannot make this just work the way people would expect. Why should we accept that a service which can be run as your user (a "home" service) cannot be run as the system, or vice versa?

Perhaps there are some services that only make sense on the system (for example, I don't suppose a home service defining Linux kernel modules would be appropriate.) So for those corner cases perhaps we must allow marking home-only or system-only services, and make it an error to put one in the other's place. But isn't it the common case that a service declaration can be part of the home or the system, and this merely changes some details in how the thing is run and what fields are required for its configuration?

Ryan


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-16  3:05 ` Ryan Prior
@ 2021-09-16  8:50   ` Andrew Tropin
  2021-09-17 13:43     ` pinoaffe
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Tropin @ 2021-09-16  8:50 UTC (permalink / raw)
  To: Ryan Prior; +Cc: guix-devel, Xinglu Chen

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

On 2021-09-16 03:05, Ryan Prior wrote:

> On Wednesday, September 15th, 2021 at 8:47 AM, Andrew Tropin
>> People will be trying to use home services inside operating systems, and configuration record for system services inside home services.
>
> I think it will be a dismal design failure if we cannot make this just
> work the way people would expect. Why should we accept that a service
> which can be run as your user (a "home" service) cannot be run as the
> system, or vice versa?
>
> Perhaps there are some services that only make sense on the system
> (for example, I don't suppose a home service defining Linux kernel
> modules would be appropriate.) So for those corner cases perhaps we
> must allow marking home-only or system-only services, and make it an
> error to put one in the other's place. But isn't it the common case
> that a service declaration can be part of the home or the system, and
> this merely changes some details in how the thing is run and what
> fields are required for its configuration?
>
> Ryan

It's not technically possible with current service extension mechanism
to have a service, which can be used in both operating-system and
home-environment.  You can read more on possible improvements to
extension mechanism here:
https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

However, currently it's just impossible without a huge (and probably
backward incompatible) refactoring of service extension mechanism and
perhaps all the services.

Even if it would be possible, still don't see too much cases, where the
system service is wanted to be used as home service and vice versa.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-15 13:06 ` Xinglu Chen
  2021-09-15 14:50   ` Katherine Cox-Buday
@ 2021-09-16  9:57   ` Andrew Tropin
  2021-09-17  9:28     ` Xinglu Chen
  1 sibling, 1 reply; 13+ messages in thread
From: Andrew Tropin @ 2021-09-16  9:57 UTC (permalink / raw)
  To: Xinglu Chen, guix-devel

[-- Attachment #1: Type: text/plain, Size: 12971 bytes --]

On 2021-09-15 15:06, Xinglu Chen wrote:

> On Wed, Sep 15 2021, Andrew Tropin wrote:
>
>> This topic was raised a few times during development of Guix Home
>> project and also during the review of wip-guix-home branch.  I made a
>> separate thread to do an exhaustive discussion of it.
>>
>> * Services and Confusion
>> It's an optional section, you can skip it, but I still find it somehow
>> related to the topic.
>>
>> I want to re-raise the issue related to system services concept.  When
>> I started using Guix I found system services to be confusing,
>> originally I thought it's a way to declare services managed by init
>> system, but later I realised that only some of system services becomes
>> Shepherd services and many of them doesn't.  It's not a unique problem
>> I see this issue appear again and again in different Guix chats and
>> communities.
>>
>> - System services :: just building blocks, nodes of DAG representing
>> a system, which after folding, results in a complete operating system
>> or other artifact.
>> - Shepherd services :: long-living processes/daemons managed by init
>> system or user-space Shepherd. It's what people used to refer as services.
>>
>> It will be very hard and costly to rename system services to something
>> less confusing, but at least let's try to keep those concepts as
>> distinct as possible.  Probably originally system and Shepherd
>> services were closely related, but not now, so let's express it very
>> clearly in docs/chats/mailing lists.
>>
>> Another player on this field is "home services", which is a similar to
>> system services, but used for describing a separate DAG, which after
>> folding, results in home environment (artifact containing user's
>> program configurations and profile with packages declared by user).
>>
>> * 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 …) name space.  For services, I wonder if we could simply use
>>> (gnu services home), for the essential services, and other (gnu
>>> services …) 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.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.

> 
> I have thought about a ‘define-configuration’ 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 <syncthing-configuration> record and a
> <home-syncthing-configuration> record.
>
> There is the problem of <syncthing-configuration> and
> <home-syncthing-configuration> not having the same fields.  To solve
> this, Each clause could have an ‘home-service?’ field, and the code
> would look like
>
>   (define-configuration syncthing-configuration
>     (package
>      (package syncthing)
>      "Syncthing package to use.")
>     (arguments
>      (list-of-strings ’())
>      "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 <syncthing-configuration> would have all the
> fields, but <home-syncthing-configuration> would have all but the ‘user’
> and ‘group’ fields.
>
> We could also have a ‘define-home-configuration’ macro that would create
> a <home-NAME-configuration> record and optionally, a
> <NAME-configuration> record.  Then ‘home-service?’ would be
> ‘system-service?’ instead.
>
> Maybe it’s too complicated and not worth it, but it’s 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’s 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.

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:  

#+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-linger%20USER%E2%80%A6


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.

> 
> 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’s 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 ‘guix system reconfigure’.
> This does mean that the sysadmin has to add ‘mcron-service-type’ to
> the ‘services’ field of the <operating-system> record, though.
>

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 ‘home-mcron-configuration’
> for home service, so I don’t think this should be a problem.  And as
> Maxime mentioned, we could have a ‘validate’ 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)~ and
>> ~(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’t think it makes
> 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.

For now it's just:
(gnu services version-control) and
(gnu home-services version-control), which I find okeish.

>
>> * Conclusion
>> I'm quite satisfied with current state of naming, but probably I miss
>> some points and, also, maybe there are some other good or even better
>> naming schemes.  In case there is a better naming approach, we can
>> decide on using it, It would be not an easy change, but until
>> wip-guix-home branch is not merged, it still easier to do this than do
>> it later.
>>
>> LMKWYT.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-15 14:50   ` Katherine Cox-Buday
@ 2021-09-16 10:01     ` Andrew Tropin
  0 siblings, 0 replies; 13+ messages in thread
From: Andrew Tropin @ 2021-09-16 10:01 UTC (permalink / raw)
  To: Katherine Cox-Buday, Xinglu Chen; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]

On 2021-09-15 09:50, Katherine Cox-Buday wrote:

> Xinglu Chen <public@yoctocell.xyz> writes:
>
>> On Wed, Sep 15 2021, Andrew Tropin wrote:
>
>>> 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.
>
> I agree with this point. I have several Guix systems, and several
> non-guix systems with Guix managing some services. In the past, I have
> had to write my own Shepherd services for things already written as
> system services.
>

Shouldn't be a problem, if home service will be a prefered option.
More details on that in the reply to Xinglu, look for linger keyword. 

>
>>> 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.  In NixOS, the NixOS
>> modules and Home Manager modules feel like two very distinct things, and
>> it’s not really easy to share things between them.
>
> I agree.
>
>>> ** 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 ...).
>
> [...]
>
>>> 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’t think it makes
>> much sense.
>
> I haven't put in the energy to follow the rational behind the proposed
> naming schemas, but I'd like to suggest this as well: =(gnu services
> home)=. This namespace increases in specificity, and I think it would
> easily follow that things in =(gnu services home)= might utilize things
> in =(gnu services)=. Or I also like the idea of =home= and =system=
> being sibling namespaces.

Actually a good idea, thank you, I will consider it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-16  9:57   ` Andrew Tropin
@ 2021-09-17  9:28     ` Xinglu Chen
  2021-09-17 11:35       ` Andrew Tropin
  0 siblings, 1 reply; 13+ messages in thread
From: Xinglu Chen @ 2021-09-17  9:28 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel; +Cc: Sarah Morgensen

[-- Attachment #1: Type: text/plain, Size: 13918 bytes --]

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 …) name space.  For services, I wonder if we could simply use
>>>> (gnu services home), for the essential services, and other (gnu
>>>> services …) 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.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’t have a way to avoid using macros for records, resisting
macros probably won’t really help much.  :-)

>> I have thought about a ‘define-configuration’ 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 <syncthing-configuration> record and a
>> <home-syncthing-configuration> record.
>>
>> There is the problem of <syncthing-configuration> and
>> <home-syncthing-configuration> not having the same fields.  To solve
>> this, Each clause could have an ‘home-service?’ field, and the code
>> would look like
>>
>>   (define-configuration syncthing-configuration
>>     (package
>>      (package syncthing)
>>      "Syncthing package to use.")
>>     (arguments
>>      (list-of-strings ’())
>>      "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 <syncthing-configuration> would have all the
>> fields, but <home-syncthing-configuration> would have all but the ‘user’
>> and ‘group’ fields.
>>
>> We could also have a ‘define-home-configuration’ macro that would create
>> a <home-NAME-configuration> record and optionally, a
>> <NAME-configuration> record.  Then ‘home-service?’ would be
>> ‘system-service?’ instead.
>>
>> Maybe it’s too complicated and not worth it, but it’s 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’s 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 <NAME-configuration> and a <home-NAME-configuration> record.
There would then be a ‘NAME-service-type’ and a
‘home-NAME-service-type’.

> 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:  
>
> #+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-linger%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 ‘guix
  publish’ service, to share substitutes with others, without needing
  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’s
  Patchwork instance does.

    <https://patches.guix-patches.cbaines.net/project/guix-patches/list/>

  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’s 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’s 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 ‘guix system reconfigure’.
>> This does mean that the sysadmin has to add ‘mcron-service-type’ to
>> the ‘services’ field of the <operating-system> record, though.
>>
>
> 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 ‘home-mcron-configuration’
>> for home service, so I don’t think this should be a problem.  And as
>> Maxime mentioned, we could have a ‘validate’ 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)~ and
>>> ~(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’t think it makes
>> 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 ‘home-’, it
should make things clear that its used by Guix Home and not Guix System.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-17  9:28     ` Xinglu Chen
@ 2021-09-17 11:35       ` Andrew Tropin
  2021-09-19 14:54         ` Xinglu Chen
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Tropin @ 2021-09-17 11:35 UTC (permalink / raw)
  To: Xinglu Chen, guix-devel; +Cc: Sarah Morgensen

[-- Attachment #1: Type: text/plain, Size: 15240 bytes --]

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 …) name space.  For services, I wonder if we could simply use
>>>>> (gnu services home), for the essential services, and other (gnu
>>>>> services …) 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.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’t have a way to avoid using macros for records, resisting
> macros probably won’t 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 ‘define-configuration’ 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 <syncthing-configuration> record and a
>>> <home-syncthing-configuration> record.
>>>
>>> There is the problem of <syncthing-configuration> and
>>> <home-syncthing-configuration> not having the same fields.  To solve
>>> this, Each clause could have an ‘home-service?’ field, and the code
>>> would look like
>>>
>>>   (define-configuration syncthing-configuration
>>>     (package
>>>      (package syncthing)
>>>      "Syncthing package to use.")
>>>     (arguments
>>>      (list-of-strings ’())
>>>      "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 <syncthing-configuration> would have all the
>>> fields, but <home-syncthing-configuration> would have all but the ‘user’
>>> and ‘group’ fields.
>>>
>>> We could also have a ‘define-home-configuration’ macro that would create
>>> a <home-NAME-configuration> record and optionally, a
>>> <NAME-configuration> record.  Then ‘home-service?’ would be
>>> ‘system-service?’ instead.
>>>
>>> Maybe it’s too complicated and not worth it, but it’s 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’s 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 <NAME-configuration> and a <home-NAME-configuration> 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.

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:  
>>
>> #+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-linger%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 ‘guix
>   publish’ service, to share substitutes with others, without needing
>   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’s
>   Patchwork instance does.
>
>     <https://patches.guix-patches.cbaines.net/project/guix-patches/list/>
>
>   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’s 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`

I see the downside that such processes won't be visible in root's herd,
but as I already mentioned it doesn't seems to be a big problem and in
addition, it is most likely solvable.

>>> 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’s 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 ‘guix system reconfigure’.
>>> This does mean that the sysadmin has to add ‘mcron-service-type’ to
>>> the ‘services’ field of the <operating-system> record, though.
>>>
>>
>> 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 ‘home-mcron-configuration’
>>> for home service, so I don’t think this should be a problem.  And as
>>> Maxime mentioned, we could have a ‘validate’ 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)~ and
>>>> ~(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’t think it makes
>>> 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 ‘home-’, it
> should make things clear that its used by Guix Home and not Guix System.

Ok, got your opinion.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-16  8:50   ` Andrew Tropin
@ 2021-09-17 13:43     ` pinoaffe
  0 siblings, 0 replies; 13+ messages in thread
From: pinoaffe @ 2021-09-17 13:43 UTC (permalink / raw)
  To: Andrew Tropin; +Cc: guix-devel, Xinglu Chen


Andrew Tropin writes:
> Even if it would be possible, still don't see too much cases, where the
> system service is wanted to be used as home service and vice versa.

I think that a bunch of the current system services are basically "run
server <x> user <y>" or "run server <x> as its own user", those might
also be useful as home services (if I'm understanding the notion of home
services correctly).


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: On the naming of System and Home services modules.
  2021-09-17 11:35       ` Andrew Tropin
@ 2021-09-19 14:54         ` Xinglu Chen
  0 siblings, 0 replies; 13+ messages in thread
From: Xinglu Chen @ 2021-09-19 14:54 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel

[-- Attachment #1: Type: text/plain, Size: 12601 bytes --]

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 …) name space.  For services, I wonder if we could simply use
>>>>>> (gnu services home), for the essential services, and other (gnu
>>>>>> services …) 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.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’t have a way to avoid using macros for records, resisting
>> macros probably won’t 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 ‘define-configuration’ 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 <syncthing-configuration> record and a
>>>> <home-syncthing-configuration> record.
>>>>
>>>> There is the problem of <syncthing-configuration> and
>>>> <home-syncthing-configuration> not having the same fields.  To solve
>>>> this, Each clause could have an ‘home-service?’ field, and the code
>>>> would look like
>>>>
>>>>   (define-configuration syncthing-configuration
>>>>     (package
>>>>      (package syncthing)
>>>>      "Syncthing package to use.")
>>>>     (arguments
>>>>      (list-of-strings ’())
>>>>      "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 <syncthing-configuration> would have all the
>>>> fields, but <home-syncthing-configuration> would have all but the ‘user’
>>>> and ‘group’ fields.
>>>>
>>>> We could also have a ‘define-home-configuration’ macro that would create
>>>> a <home-NAME-configuration> record and optionally, a
>>>> <NAME-configuration> record.  Then ‘home-service?’ would be
>>>> ‘system-service?’ instead.
>>>>
>>>> Maybe it’s too complicated and not worth it, but it’s 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’s 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 <NAME-configuration> and a <home-NAME-configuration> 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:  
>>>
>>> #+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-linger%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 ‘guix
>>   publish’ service, to share substitutes with others, without needing
>>   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’s
>>   Patchwork instance does.
>>
>>     <https://patches.guix-patches.cbaines.net/project/guix-patches/list/>
>>
>>   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’s 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:

  
  (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 “dovecot”, “tor”,
and “weechat” users and groups by extending the ‘account-service-type’.

These services would also start on boot regardless if there is any
internet connection, because the Shepherd for the “dovecot” user isn’t
aware of the networking ‘requirement’, which is only available 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.,
‘etc-service-type’ or ‘pam-root-service-type’?  ‘home-file-service-type’
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 ‘home-file-service-type’
for the “dovecot” user.

By having a bunch of home-services, something like ‘guix system
extension-graph’ and ‘guix system shepherd-graph’ would 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.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-09-19 14:54 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-15  8:47 On the naming of System and Home services modules Andrew Tropin
2021-09-15 10:09 ` Maxime Devos
2021-09-15 13:15   ` Andrew Tropin
2021-09-15 13:06 ` Xinglu Chen
2021-09-15 14:50   ` Katherine Cox-Buday
2021-09-16 10:01     ` Andrew Tropin
2021-09-16  9:57   ` Andrew Tropin
2021-09-17  9:28     ` Xinglu Chen
2021-09-17 11:35       ` Andrew Tropin
2021-09-19 14:54         ` Xinglu Chen
2021-09-16  3:05 ` Ryan Prior
2021-09-16  8:50   ` Andrew Tropin
2021-09-17 13:43     ` pinoaffe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).