Re: Introducing Guix "Features"! (Was: Syntactic Diabetes)

[Edouard Klein]

Weighting in here, as small as my weight may be:

- re-using 'service' is IMHO a bad idea, it is a loaded term and the
  expectation of a new reader is that a service is a SysV-init service:
  it can be started, status-ed, stopped, restarted, and that's it. It
  maps to a daemon running in the background. Basically a shepherd
  service.

- The fact that systemd service maps in functionality to guix services
  should be a huge redflag that the name is not good. Systemd sucks for
  many reasons, and using confusing and incosistent language is one of
  them.

- I agree that 'features' is a worse name, way too generic.

- Descriptive linguistics would consider the broader and
  historical use of the term in the UNIX crowd from which guix users are
  drawn, instead of the in-group use, which, despite being admitedly
  well documented and rooted in the history of the project, is
  overloading a close-but-not-exactly-matching term.
  I can not emphasize enough how much those subtle unexpected problems
  make adopting guix very hard.
  I pushed through because I understand that the project is
  fundamentally sound and worthwhile, but for a few years I have
  made interns and colleague work with guix and saw their motivation die
  by a thousand cuts because of confusing stuff like this.
  Finding a better term would be a worthwhile endeavour, for ease of
  adoption.
  Maybe we should dedicate a session for it in the next guix days ?

- At os-declaration time, ALL guix services can be added, extended,
  modified, and removed. Discovering this and the difficult-to-write
  syntax that goes along with notably the extension, led me to the
  syntactic sugar we were initially discussing.

- At os-reconfiguration time, SOME guix services will do their thing

- At os-boot time, SOME guix services will do their thing

- At os-running time, SOME (the shepherd kind) guix services can be
  stopped, started, statused, doced, custom-actioned, and restared

- Understanding these behaviours may help use find an naming ontology
  that would foster understanding and adoption.



Note that I don't disagree that service is a good name in *isolation*, I
just want to emphasize, as Attila did, that ignoring beginner's
expecations (however obsolete they may seem to be) is detrimental to the
project's adoption.


Cheers,

Edouard.

Felix Lechner <felix.lechner@lease-up.com> writes:

> On Thu, Nov 30 2023, Attila Lendvai wrote:
>
>> the use of 'service' to describe two rather different abstractions: a
>> component of an OS vs. a deamon process run by shepherd.
>
> Indeed, the use of 'service' in much of Guix appears to be a grand
> misnomer. It probably occurred because the meaning expanded over time.
>
> It's like we are looking back in time at the Big Bang. Our "services"
> are the microwave echoes of Guix's initial, creative spark!
>
> Please consider a recent, helpful reply to help-guix. [1] Carlo
> mentioned the term "service" eleven times, but none of them referred to
> what I believe most readers of this message would call a service in
> other contexts. What's a newbie on help-guix to think?
>
> Should Guix services instead be called "features"?
>
> Those "features" are central to any operating system definition. Other
> choices like "provider" may not fully capture our collective uses
> throughout the code and the documentation. I am especially thinking
> about 'modify-features' and '%base-features'.
>
> Kind regards
> Felix
>
> [1] https://lists.gnu.org/archive/html/help-guix/2024-01/msg00213.html