Hi Leo, On Sat, 02 Jan 2021 00:16:45 +0100 Leo Prikler wrote: > > And it indeed is possible to add (uid 4711) in the literal and it > > will work > > just fine. > I'm aware you're joking, or at least I hope you are, What? It's perfectly reasonable for a distribution to have stable system user ids. That's what Debian supports, too: https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes >0-99: >Globally allocated by the Debian project, the same on every Debian system. These ids will appear in the passwd and group files of all Debian systems, new ids in this range being added automatically as the base-passwd package is updated. >Packages which need a single statically allocated uid or gid should use one of these; their maintainers should ask the base-passwd maintainer for ids. [...] >60000-64999: >Globally allocated by the Debian project, but only created on demand. The ids are allocated centrally and statically, but the actual accounts are only >created on users’ systems on demand. >[...] And so does FreeBSD, see https://www.freebsd.org/doc/en/books/porters-handbook/users-and-groups.html and https://github.com/freebsd/freebsd-ports/blob/master/UIDs for the actual registry. For that matter, IANA does this for ports and many other things. And so on. Stable defaults are *good*. Right now, the Guix service user user-account record specifies 99% of the /etc/passwd entry. I indeed propose to make it 100% for system users for Guix system services. >but I shouldn't have to point out why hardcoding ids into those literals is a >bad idea. You have to point that out to us--especially since Guix service user accounts of the account-service-type extension can only be instantiated once anyway.