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