Re: Introducing Guix "Features"!

[Carlo Zancanaro]

On Thu, Feb 01 2024, Felix Lechner via "Development of GNU Guix and the GNU 
System distribution." wrote:
> 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.

We can actually point to a specific moment when the meaning was
expanded. It was done in Guix 0.9.0:
https://guix.gnu.org/en/blog/2015/gnu-guix-090-released/

Here is a blog post introducing services back in 2015, which has a
heading "Services Beyond Daemons" which discusses the change to broaden
the term to encompass what Guix now calls a service:
https://guix.gnu.org/en/blog/2015/service-composition-in-guixsd/

There is also a talk that Ludovic gave at FOSDEM 2017 where he discusses
the ideas of Guix services (I can't remember the content of this, but it
seemed like it might be relevant):
https://archive.fosdem.org/2017/schedule/event/composingsystemservicesinguixsd/

This doesn't seem like accidental concept creep. This was an intentional
decision to use the word "service" to mean something specific.

I say this to note that any argument to change the term should first
understand why this decision was made (see: Chesterton's Fence).

Carlo

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

[Ricardo Wurmus]

> for an average unix user a service is a process that is running in the
> backgroud, doing stuff mostly without any user interaction. you can
> try to argue this away, but i'm afraid that this is the state of
> things.

I don’t think it’s a good idea to aim to satisfy some presumed “average
unix user”, because such a user would not be familiar with many concepts
introduced by Guix (e.g. “guix shell” or “guix system”).

The manual defines system services by referencing users’ expectations:

--8<---cut here---start->8---
11.18.1 Service Composition
---

Here we define a “service” as, broadly, something that extends the
functionality of the operating system.  Often a service is a process—a
“daemon”—started when the system boots: a secure shell server, a Web
server, the Guix build daemon, etc.  Sometimes a service is a daemon
whose execution can be triggered by another daemon—e.g., an FTP server
started by ‘inetd’ or a D-Bus service activated by ‘dbus-daemon’.
Occasionally, a service does not map to a daemon.  For instance, the
“account” service collects user accounts and makes sure they exist when
the system runs; the “udev” service collects device management rules and
makes them available to the eudev daemon; the ‘/etc’ service populates
the ‘/etc’ directory of the system.
--8<---cut here---end--->8---

Shepherd takes care of monitoring daemons and the like, but services
provided by the system (in the sense of system facilities) don’t have to
be daemons.

-- 
Ricardo

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

[Liliana Marie Prikler]

Am Donnerstag, dem 01.02.2024 um 20:30 + schrieb Attila Lendvai:
> 
> for an average unix user a service is a process that is running in
> the backgroud, doing stuff mostly without any user interaction. you
> can try to argue this away, but i'm afraid that this is the state of
> things.
Which is exactly what etc-service-type does.  It symlinks stuff to /etc
without user interaction.


Cheers

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

[Attila Lendvai]

> there for most of the time already. And if you think about it,
> symlinking stuff to /etc is a service.

i've arrived to guix after 3+ decades of programming, most of that in 
opensource environments, unix-like OS'es, and more than a decade using linux as 
my primary OS and lisp as my goto language.

it could be me, of course, but it took me months of tinkering until i 
understood the guix service vs shepherd service nomenclature. and i still need 
to focus when i'm dealing with foo-service-type and shepherd services at the 
same time.

this nomenclature was an obstacle to understanding, because the naming suggests 
something that was misleading me.

for an average unix user a service is a process that is running in the 
backgroud, doing stuff mostly without any user interaction. you can try to 
argue this away, but i'm afraid that this is the state of things.

and if you care whether your words (code) is communicating what you want to be 
understood by your audience, then you must consider their model of reality.

which reminds me of:

“Programs must be written for people to read, and only incidentally for 
machines to execute.”
— Abelson & Sussman, SICP, preface to the first edition

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“As a rule, whatever we don’t deal with in our lives, we pass on to our 
children. Our unfinished emotional business becomes theirs. As a therapist said 
to me, "Children swim in their parents’ unconscious like fish swim in the sea."”
— Gábor Máté (1944–), 'In the Realm of Hungry Ghosts' (2008)

[fr] Moment de convivialité Guix@Paris en février

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Ce jeudi 8 février 2024 à 19h, se tiendra la cinquième édition de Guix@Paris
ouverte au public.
Comme les fois précédentes, il sera possible de participer à distance
(*cf* ci-dessous).


## Programme

Il n'y a pas vraiment de programme… pour le moment ! À vous de proposer
des sujets en avance si vous voulez partager sur des sujets particuliers.
Le but est toujours que les utilisat·rice·eur·s de Guix
—ou futur·e·s utilisat·rice·eur·s !—, dans la région parisienne se
rencontrent et qu'ielles puissent discuter de Guix, Guile ou autres.

L'idée est surtout de passer un moment convivial en mettant des visages
sur des noms. Se rencontrer quoi ! 

Il n'y a pas d'expérience pré-requise et vous êtes tout·e·s les bienvenu·e·s.


## Logistique

Vous pouvez nous dire si vous comptez venir en répondant à ce message,
mais vous serez aussi les bienvenu·e·s au dernier moment ! 

Nous nous occupons des tables, des chaises, des prises électriques et
du vidéo-projecteur. Il y aura aussi de quoi boire et grignoter, mais
vous pouvez apporter ce qui vous ferait plaisir.


## Participation à distance

Sauf annonce contraire, il sera possible de participer à distance
*via* l'instance Jitsi Meet d'Easter-eggs :
.


## Accès

Nous serons accueilli·e·s dans les locaux de l'[April][1], elle même hébergée
par [Easter-eggs][2] :

```
Association April
44/46 rue de l'Ouest (cour intérieure)
Bâtiment 8
75014 Paris

Stations de Métro : Gaîté, Montparnasse, Pernety.

OpenStreetMap : .
```

[1]: https://april.org "April, promouvoir et défendre le logiciel libre"
[2]: https://easter-eggs.com/Presentation-d-Easter-eggs "Easter-eggs"


Au plaisir de vous y rencontrer !

-- 
Tanguy

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

[Liliana Marie Prikler]

Am Donnerstag, dem 01.02.2024 um 05:29 -0800 schrieb Felix Lechner:
> 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.
I'm pretty sure that "etc-service-type" was not something that expanded
the meaning of "service" over time, but rather something that had been
there for most of the time already.  And if you think about it,
symlinking stuff to /etc *is* a service.

> 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?
You might be experiencing an effect where repeating a word often enough
makes it appear meaningless, but not only is the reply helpful, it also
highlights the exact point you're criticizing: Typically, for stuff
like configuring clamav (which I think many would consider a service),
you'd have a dedicated clamav-service-type, which of course itself
extends more low-level services.  The mere fact that we haven't yet
gotten around to implement that doesn't mean that our terminology is
somehow off, it just means that there's something missing that
something is missing.

> 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'.
I think it's better to do descriptive linguistics over prescriptive
linguistics.  The use of `guix shell' prevails over `guix environment'
not because one of them uses a "more correct" term, but rather because
one of them provides a nicer interface that requires less typing (among
other benefits like reduced headaches, etc.)

As for the term features, that's a word that can mean literally
anything in between and around packages, services, etc.  Typically,
packages or services implement features, for instance evolution
implements "reading mail" and "writing mail", whereas (a) gdm(-service)
implements "logging into your account".  I personally don't think your
proposed relabeling would be worthwhile, especially if we have more
important features (like syntactic sugar) to discuss.

Cheers

Re: Core-updates coordination and plans

[Vivien Kraus]

Hello,

Le mercredi 31 janvier 2024 à 17:44 +0100, Josselin Poiret a écrit :
> Also, I see that most of the patches that were requested to be merged
> into c-u (like the big pages for jemalloc) actually got pushed, are
> there any other (well-tested) ones we can go for at the same time as
> the
> glibc rebuild?  I will stress that this is about *core* packages now,
> I feel that it's too late to introduce more complications and delay
> the
> update any longer.

Is it too late to ask if you could cherry-pick the commits that show up
in the d6462be6a8..b701a7018d range (from gnu: eudev: Update to 3.2.14.
to gnu: upower: Update to 1.90.2. inclusive)? We have them on gnome-
team, but maybe it would rather belong in core-updates.

What do you think?

Best regards,

Vivien

Re: GUIX days and FOSDEM 2024

[Pjotr Prins]

Guix days is happening with a large group! To keep track of things we
have a guix days channel on matrix:

https://matrix.to/#/#guix-days:matrix.org

Pj.

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

[Development of GNU Guix and the GNU System distribution.]

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