all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>
To: Attila Lendvai <attila@lendvai.name>
Cc: "Liliana Marie Prikler" <liliana.prikler@gmail.com>,
	"Edouard Klein" <edou@rdklein.fr>,
	guix-devel@gnu.org, "Ludovic Courtès" <ludo@gnu.org>,
	"Josselin Poiret" <dev@jpoiret.xyz>
Subject: Introducing Guix "Features"! (Was: Syntactic Diabetes)
Date: Thu, 01 Feb 2024 05:29:45 -0800	[thread overview]
Message-ID: <87frycl3cm.fsf@lease-up.com> (raw)
In-Reply-To: <4H69vnQJrUA5WrVPVfQknwCz2ymq8NFyOnp0cCuqZiUVpSAwp6QAhonzbnSpsuRZJcZUX4dmV-U-qhV7CXNH5UOaGV8IEaL2fY8qXmPnmns=@lendvai.name>

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


  parent reply	other threads:[~2024-02-01 15:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23  8:06 A friendlier API for operating-system declarations Edouard Klein
2023-03-23 18:48 ` Josselin Poiret
2023-03-23 20:23   ` Edouard Klein
2023-03-23 21:05 ` Liliana Marie Prikler
2023-04-13  9:42 ` Ludovic Courtès
2023-05-18 14:37   ` Edouard Klein
2023-11-24 21:43 ` Syntactic Diabetes (was Re: A friendlier API for operating-system declarations) Edouard Klein
2023-11-24 22:50   ` Liliana Marie Prikler
2023-11-25 20:14     ` Attila Lendvai
2023-11-26  5:36       ` Michal Atlas
2023-11-26 16:49       ` Edouard Klein
2023-11-26 18:32         ` Liliana Marie Prikler
2023-11-26 20:46           ` Edouard Klein
2023-11-27 21:09             ` Liliana Marie Prikler
2023-11-29 20:12               ` Attila Lendvai
2023-11-29 23:39                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-11-30 11:16                   ` Attila Lendvai
2023-12-01 18:18                     ` Michal Atlas
2024-02-01 13:29                     ` Felix Lechner via Development of GNU Guix and the GNU System distribution. [this message]
2024-02-01 19:43                       ` Introducing Guix "Features"! (Was: Syntactic Diabetes) Liliana Marie Prikler
2024-02-01 20:30                         ` Attila Lendvai
2024-02-01 20:46                           ` Liliana Marie Prikler
2024-02-02 20:11                             ` Attila Lendvai
2024-02-01 21:02                           ` Ricardo Wurmus
2024-02-02 19:36                             ` Attila Lendvai
2024-02-02 20:21                               ` Vagrant Cascadian
2024-02-02 21:25                                 ` Attila Lendvai
2024-02-02  0:03                       ` Introducing Guix "Features"! Carlo Zancanaro
2024-02-18 15:07                       ` Introducing Guix "Features"! (Was: Syntactic Diabetes) Edouard Klein
2023-12-09 10:12         ` Syntactic Diabetes (was Re: A friendlier API for operating-system declarations) Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87frycl3cm.fsf@lease-up.com \
    --to=guix-devel@gnu.org \
    --cc=attila@lendvai.name \
    --cc=dev@jpoiret.xyz \
    --cc=edou@rdklein.fr \
    --cc=felix.lechner@lease-up.com \
    --cc=liliana.prikler@gmail.com \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.