| 26 Dec 2021 |
 Winter (she/her) | * In reply to @m1cr0man:m1cr0man.com
It did up until recently, but then some other maintainer removed its fixed UID. I was not against it - for the reason hexa says but also you're not transporting certs between systems anyway and the UID will never change once randomly picked.
the UID will never change once randomly picked.
unless you’re wiping your rootdir on every boot (hi), which regenerates /etc/passwd, so then you’re at the mercy of JSON ordering
| 21:07:14 |
| Winter (she/her) | * In reply to @m1cr0man:m1cr0man.com
It did up until recently, but then some other maintainer removed its fixed UID. I was not against it - for the reason hexa says but also you're not transporting certs between systems anyway and the UID will never change once randomly picked.
the UID will never change once randomly picked.
unless you’re wiping your rootdir on every boot (hi), which regenerates /etc/passwd, so then you’re at the mercy of JSON ordering | 21:07:23 |
 m1cr0man | you can always set your own UID :) | 21:07:36 |
| m1cr0man | just set user.users.acme.uid = 123; | 21:07:48 |
 hexa | yeah, I'm reluctant to spend fixed uids on something if we don't have to 🙂 | 21:08:06 |
| m1cr0man | We also can't solve for every case, which is a lesson I've learned the hard way with this module | 21:08:29 |
| hexa | bingo | 21:08:47 |
| Winter (she/her) | In reply to @m1cr0man:m1cr0man.com
you can always set your own UID :) yeah of course | 21:10:14 |
| m1cr0man | My logic at this point is if it can be done easily, we don't need to reimplement it. This is a case like that. If someone was trying to override the user itself, that would be more complex (and why I added useRoot in the PR, lol) | 21:12:15 |
| m1cr0man | speaking of the PR | 21:12:17 |
| m1cr0man | finally rebased :D | 21:13:17 |
