Yes it does, because using systemd-run enables you to use resource management on the user run service. See https://www.freedesktop.org/so... for some options.

Also, it really is best practice to totally clean the user session at logout, only allowing explicitly permitted processes to continue to run.

Cross platform scripts have always been problematic. Sometimes they work, sometimes they get broken when things change. Solaris changed a lot with SMF etc, and Linux with systemd. That is just progress.

Most of the old close source Unix's have chosen not to evolve and are now firmly niche OS's working in a very narrow confinement (and loosing ground there too every year).
Linux runs everywhere, from tiny embedded to clusters and supercomputers, and therefore have other needs than classic Unix. It is just logical that Linux evolve with new features while many Unix's are standing still, and that therefore it will become harder and harder to run platform-independent scripts on them. While it may be inconvenient to some, it is what is saving Linux from ending up in the same, small dying niche as the close source Unix's.

In 10 years there will be even less Irix, AIX, Solaris etc., but Linux has a fighting chance still to be relevant in the future, exactly because it changes.

Yes I am seriously suggesting to edit scripts so they work with new tech.

But I don't care whether you edit your scripts or not. If you prefer prefer broken scripts to editing them, that is your problem, not mine.

Do you really think your made up, incoherent hyperbolic stories counts as technical arguments?

It is scary to think that you probably are old enough to shave yet behave like a retarded 10 year old. You mother must really have hated you since you ended up in such a sad state. I am sorry for you, I really am.

Just edit your scripts. You had to edit them too when ssh replaced rsh back in day. Or just set "KillUserProcesses" to "no" and live with the same old problems. Hardly a big deal.

I think it is rather a question of who first "stole" the nice short commands, leading to permanent hogging of the namespace. Who is really using ar these days.

Anyway, those "terse" commands and their "terse" switches are really hard to remember, especially when they only have the vaguest mnemonic resembles to what they perform. And "-t" can mean anything depending on what program it is used with.

The solution was to use proper mnemonic commands and have tab completion of everything, including switches, and always have "long option" switches so a simple "--*tab*" would reveal the options. This combined with using the command stack is highly efficient, not only when it comes to typing, but also when it comes to remember what stuff do.
Programs like git and systemd is designed around this concept. I like it.

I think we can safely assume here that do don't really have any experience with systemd-run, nor have actually read its man-page. So you must have psychic powers in order to know that it offers no benefits to you.

The way you run the programs may have changed, but not the functionality. Screen works just like expected when started by systemd-run once it is running. So no functionality is lost.

This isn't about running stuff in the background (though systemd-run can do that too), but about keeping processes alive after logout.

With systemd-run the programs get their own scope that you can manipulate with standard systemd tools and use many of the standard systemd resource management features like limiting IO etc. In short, you can trivially constrain your long running processes so they don't DoS the system, even if some process went rogue.
Another major benefit is the ability to safely purge the user session in a clean way, so that only explicitly allowed processes survive the logout.

Anyway, it is trivially easy for those who want it to revert to the old (rather hackish) way of doing things. man logind.conf will show you how.

Yes, that is exactly what we told the whining users back in the day when they fiercely resisted to stop using telnet, rlogin and similar old Unix crap.

But some people just have severe trouble adapting to new tech and new work flows and start to cling to old outdated procedures and programs.

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Just recall the command line from the stack. No need to type when eg. "Ctrl-r" works so well.

Really such changes occur all the time in tech; we no longer use telnet, rlogin, uucp and similar old and insecure stuff anymore either. It must be hard to work in tech when unable to learn new commands and new ways of doing things.

Why do you think there no solid reasons for this new default. It is something somebody told you, or are you just presenting what you imagine as facts?

That isn't a problem of course, even with the new systemd defaults. Just use systemd-run --user --scope screen and the process and all other processes started from screen will survive logout.

Oh, Hyperbolic twaddle instead of technical arguments. Hardly surprising.

Well established Unix conventions, like using unencrypted connections (Telnet, UUCP, rlogin etc) that sends password in clear text? Unix was chock full of insecure way of doing things and an unfortunately a lot of this have carried over to Linux with the end result that multi-user Linux security seems to rely on users being nice guys as a basic security measure.

With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally.

That is just silly. I suppose you would have fiercely resisted when Telnet was kicked out in favor of ssh too since it had new syntax.

Change is just part of tech. Get used to it.

There is no change in how systemd handles either processes or logins with this change except that it purges processes that aren't explicitly allowed to continue to run. This is conceptually very similar to how things always have worked, It is simply the way to explicitly tell the system a process is allowed to survive that have changed.

So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?

There are several benefits from the new way of doing things too, like being able to use some of systemd's extensive resource management options.