Chris SiebenmannI am sure I will not regret upgrading my eccentric office desktop from Fedora 42 to Fedora 43 through a live dnf upgrade the day before a long weekend.
(Well, I have to do it sometime, I've sat on this far too long.)
This is my unsurprised face that I am now gluing one local program back together because the old version broke in the upgrade. I hope that this is not an omen that the old old version of this program that I run at home will also break in the upgrade, because that would annoy me deeply. (I like the old old version better than the old version.)
On the negative side, gluing the local program back together took a lot more work than I expected at the start. On the slightly more positive side, apparently the old version was quietly broken too and I just didn't notice. Yay for actually testing things.
(In theory I could have done some of my stuff with local CSS hacks but in practice I'm building from source anyway so I already have a chainsaw running.)
I impulsively updated my home Fedora desktop to Fedora 43 this evening and the old old version of the program (Liferea) broke, which makes me unhappy because I liked the old UI better than the current one. On the other hand the old (old) version was very old in the tooth by now and being up to date is probably good for me.
I am going to be hacking the new UI, though (which, as usual, is HTML + CSS under the hood).
WHAT THE HELL. My home Fedora desktop (now Fedora 43) is refusing to start a 'systemd --user' daemon/session/etc when I log in on the tty/vty console. SSH in and the 'systemd --user' stuff starts (and then the console session can find it). This breaks sound, among other unpleasant things. At work this works, and I can't see any obvious /etc/pam.d differences.
This is apparently happening because direct console tty logins are now 'user-light' sessions which don't trigger things. On my work desktop, I run something from cron as an @ reboot thing that triggers user service manager startup but at home I don't so I get screwed.
Ah. I believe this is ancient sins coming back to haunt me. Many decades ago my UID was set to '19', a decision that has in no way haunted my Unix machines ever since. Low UIDs are by default system users and in systemd v258+, system users deliberately get a 'user-light' session.
Haelwenn /элвэн/ 
@cks I guess you can carbon date unix users with that kind of stuff, mine's 203 (as the 4th member of the household at the time it was assigned).
And I hope I will not have to change it.
Also /etc/login.defs here has SYS_UID_MIN and SYS_UID_MAX, I think it should only be used by su(1) and login(1) but well config files getting reused is rather common.
And I hope I will not have to change it.
Also /etc/login.defs here has SYS_UID_MIN and SYS_UID_MAX, I think it should only be used by su(1) and login(1) but well config files getting reused is rather common.
@lanodan In theory SYS_UID_MIN/MAX are only for adduser, when you ask it to dynamically make a 'system' login and group. UIDs under SYS_UID_MIN are historically for statically assigned system logins (ie, hard-coded UIDs).
In practice, everyone wants to know 'system UID or user UID' and everyone uses login.defs as the best option they have.
mirabilos@mirabilos @cks Yeah I wouldn't take it as portable across unixes, in fact POSIX (where it would probably be out of scope anyway) is using the term "system user" to mean something like "user of the system".