>How is any of that much different than machine-id, which is also subject to the user changing it, if they want to?

I think the typically scenario is that two companies merge and one company's serverpool is forced to change it's hostnames and IP-addresses. Any software like logging sinks that relies on these to identify systems will instantly have trouble.

In short, hostnames and IP-addresses are bad system identifiers because organizational changes can force them to be changed.
Hardware based fingerprinting is inflexible too, since NIC's and NVMe WWID's change if the hardware is replaced.

With a unique software defined identity like machine-id, a system like a web-server can change hostname/NIC/IP/etc or replace any piece of hardware without causing any breakages with the software analyzing its logs.

>Anyone, or process, can read it. Someone failed the confidentiality and 'do not expose' bits.

It is confidential the same way your NVMe WWID is confidential. If a program can read machine-id it can read the WWID of your NVMe or get the NIC MAC address, both can be used to fingerprint systems in a way that can survive even a total OS reinstallation.

What the machine-id man page says, is simply a reminder to programmers that such info should be considered confidential and that a cryptographic hash of machine-id should be used in most cases instead of using the more privacy sensitive machine-id directly.

The need for a unique system identifier is real, and for privacy reasons (and more flexible system management), it is much better to be a software defined key that can be deleted at will, rather than hardware based fingerprinting.

>Many applications have a reason to record an ID unique to their installation. Very few applications have reason to record an ID unique to the machine,

To quote the man page:
"Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm". So you can have the best of both worlds. And unlike hardware fingerprinting and MAC addresses, machine-id can be changed at will.

Having a unique identifier on a system can be really useful so eg. all generated logs can be tied to a single machine, even if it changes hostname/IP/MAC-address etc. And having it it done in software like machine-id does instead of hardware fingerprinting is much better regarding privacy.

Yes, it will be great when one day when most Linux non-system apps can run in a truly isolated container, but there is a long way to go before that is possible.

No, it is a real security problem; lingering processes have been used countless time to regain access to systems from the outside. Pre-systemd there wasn't even a good and reliable way to kill a (logouted) user's processes across servers (pkill was never a standard and it is unreliable since both broken and malicious programs can escape it).

Hyperbolic assertions about what LP might do are lame arguments. Besides timed logouts have been the order of the day for decades; I have never worked on a sensitive system that allowed the user to stay connected for weeks on end; it just too dangerous to allow that.
And don't forget that LP and the rest of the systemd developers really knows "user and session management" in Linux; they have practically invented and maintained all the core Linux software used for this like CK and logind.

Instead of abusing Unix signals like "nohup", lingering programs should just use PAM or similar to gain permission to run in their own scope; much better and much more granular security.

Lennart Poettering have been working strictly on open source Linux software ever since he graduated. He has at least +15 years developer experience on Linux. I have no idea why you think he has a MS Windows background. Did you just made it up?

He says that:
1: it should be an easy admin task to enable-disable users ability to run such tasks since they are a security risk (eg. a lingering ssh connection out through the firewall can be reversed so it can be used to connect back into the system).
2. As default, only programs that explicitly have permissions (from PAM etc) to linger after logout should be allowed to do so.

So he has no problems with lingering processes, he just thinks they should be secure and easy to admin. No sane modern OS would ever implement the current Linux scheme with unrestricted ability for users to run arbitrary programs after logout (and even after the account have been locked).

Yeah, I actually know the difference between those two programs, and old enough to have used both telnet and see ssh replace it as the default way for connecting to other machines.

People unable to cope with technological changes like the transition from telnet (rsh/rlogin/etc) to ssh, SysVinit to systemd, or the future, Xorg to Wayland, just eject themselves out of tech.

No I don't. I just accept technically superior solutions as the way forward, even if they means another way of working.

I have no sentimental feelings for old, close source, Unix systems made by money grabbing, Linux-hating companies. So I have no problems discarding ancient Unix ways of doing things if I find new ways that are better.

Finally, I actually study the new tech I embrace by reading the technical documentation. That is apparently a lost art among many modern Linux users.

It goes without saying, that if the close source vendors want to sell their stuff as supported on RHEL and E-Suse, and this is something they certainly will, they will make sure their stuff works with systemd.

Not familiar with "torque", but this doesn't seem like anything a single user will start from a terminal. It seems more like a fundamental system service, and therefore won't have any problems with "KillUserProcesses=yes".
Nor would any jobs it handed over to other machines be affected, unless it happens to "physically" login with username and password and run the instance under that user account. Highly unlikely IMHO.

X's network transparency have basically been broken for many years for anything complex. For simple uses of old legacy software it may still work for some. But really, I and many others are cheering for the day we can clean our systems for that insecure monster called X and start to use Wayland. Yeah, that will break peoples workflow too. But that is how progress works.

If you don't want me to answer your often rather unsavory personal attacks, then just stop talking to me. I don't remember starting to address you in the first place.

Then use different procedures for different machines. Not a problem in the real world where people often work with several incompatible OS's. Anyway, that problem will solve itself as the non-systemd Linux machines slowly are phased out.

Maybe you need a real mother that can love you unconditionally for what you are. You certainly seem like a bitter bileful person in desperate need for love.

A rather typical response from you. Please learn to argue if you want to be taken seriously.

Please be aware that we are talking about user .services, not system .services.
A users services are totally independent from other users services, and the system services.
Each user can control their own services with standard systemd tools like "systemctl start screen.service" and you can employ the whole suite of systemd features like socket activation, AmbientCapabilities, Cgroup resource management, etc. on such services.

I think the systemd developer group is the single most knowledgeably Linux developer group when it comes to multi-user Linux. The very existence of "systemd-logind" is a proof on how much better multi-user Linux work on systemd compared to any non-systemd distro. I mean, running Xorg rootless is only safe on systemd distros.

Just lock the session instead of logging out. That would be the typical thing to do with a workstation since it runs a DE of some sort.

I must say I have a hard time imagine CLI software being launched from a GUI and then detach from the terminal. But I don't think there is any problem with using "systemd-run" on the GUI; that will create a new scope and anything executed from that scope will remain in it. So even if the GUI is closed, the scope will remain with all the processes launched from it.
At worst they can just add the user to the "KillExcludeUsers=" in logind.conf to have the old behavior.

Oh yes, telnet was kicked off the default installation list along a lot of other inherently insecure Unix stuff like rsh and rlogin etc. Instead you got ssh. People whined about that too; suddenly they had to manually install a telnet client (lets just suppress the memories that some Linux distros came with a telnet-server as default).

ssh dramatically changed the whole workflow on both Linux and Unix, and a lot of people didn't like that. Same with packages and package management (how I don't miss hand patching and compiling). These days it is systemd that changes how Linux work, and I must say I much prefer how it does things as opposed to the old days of SysVinit.

The bottom line is that tech changes all the time, or else it becomes obsolete. That is just the price of progress. Cling to the old ways, and you and your skills become obsolete in the same way.