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.
Well. System users in systemd v258+ get a 'user-light' session if and only if they log in on a tty, if they log in via SSH they apparently get a 'user' session. I in no way understand this or how to manipulate this.
It turns out that I'm wrong about one detail of my work Fedora machine. It does open some sort of early session for me when it boots, but it's not from a crontab at-reboot entry and not from any 'User=' .service setting I can see. Loginctl says it's a 'manager-early' class with no seat associated.
All of this is rather charmingly opaque, and some of our users at work have low UIDs too (although none as low as 19, that was a Special Choice).
adb@cks I’ve only been doing Unix since 1987, and even then there was the convention mortal user accounts started at 100. There was the expectation a vendor service could have a hardcoded UID and installables owned by that, including setuid binaries, perhaps coming along in an upgrade after you had started using the system. And always the chance of software giving different treatment based on a numerical comparison of UID values. So congratulations on getting away with it for so long!
@adb Questionable decisions were made at the time, and not by me exactly¹.
¹ It was tradition in the group I joined that all system staff got extremely low UIDs, for reasons I don't know. I believe I got an unusually low UID even at the time, but possibly that was because it was a free UID. Then inertia carried it forward even when I had a couple of natural chances to change it (first due to NFS and later due to 'I'm going to dump|restore this filesystem and it has my old UID...').