screen does work as before.... if you are that lazy, use your scripting skills and create a script with a name of one character in length to launch screen. i can't believe the trivial excuses that ooze their way out of the woodwork.
if tightening up of your system security seems slight or non-existent then fine i.e. i don't see anything wrong in defining what is allowed to remain running after you logout. Yes, its a little more work in the beginning but security is an ongoing process.
of course he gets it. most people get it but feel its too trivial to worry about. You seem to be saying that nothing has changed in the running of unix/linux since the year dot and you've never had to change a script at any time to allow for a change of process.
The rant is more like: "Why is systemd on my system? It's overly complex, works poorly [for server systems], it breaks backwards compatibility, uses binary log files (WTF!), etc."
Blame your distro maintainers that decided to use systemd or choose another one that doesn't use one. Ranting from a point of ignorance is a waste of time and ignorance is the start point of all anti-systemd rants. The ranters would spend their time better if they RTFM on systemd and learnt how to configure it.
All they have changed is a default config option, just change it back or
a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora)
b) there's a runtime switch to turn this off locally on the system (in logind.conf)
c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.
Probably quite a bit because no-one does any research on the issue before winding their neck out and making random ignorant statements especially as its just a configure change not a functional one. From the fedora thread on this issue..
"systemd 230 now finally flipped the switch and finally by default cleans everything up correctly when the user logs out. But we do so in a very conservative way actually: a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora) b) there's a runtime switch to turn this off locally on the system (in logind.conf) c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.
i would have thought as long as you are not locking the wheels under braking or burning tyres under acceleration, you'd lose about the same amount as you would just moving.
its more to do with xenophobia and borderline racism fueled by fear from idiots like Trump. This sort of paranoia is not the exclusive territory of the badly educated
if you follow that lkml, they are discussing a patch, read a little further in the thread. "This is on Debian testing, with sysvinit and a systemd-shim to
allow other parts to work." - i ignored the other 2 links as unverifiable anecdotes.
You might think its idiotic, i see it as being accurate. Every single way you read or inspect a file, it is done by using a tool whether it be 'cat' or 'grep' or journalctl. What you can do with journalctl and a few parameters, you'll need a lot of coding and testing to generate the same output via the "old" way. You can also pipe the text output from journalctl to any text parser you like.
no it isn't. you are moaning from a a point of ignorance. RTFM first.
whats your problem? learning new things a bit daunting?
screen does work as before.... if you are that lazy, use your scripting skills and create a script with a name of one character in length to launch screen. i can't believe the trivial excuses that ooze their way out of the woodwork.
You live in the Utopia of the coding world.
that's your problem, you stopped reading long ago to stay in your comfort zone.
RTFM before you jump
Welcome to the world of system admin and maintenance......
if tightening up of your system security seems slight or non-existent then fine i.e. i don't see anything wrong in defining what is allowed to remain running after you logout. Yes, its a little more work in the beginning but security is an ongoing process.
of course he gets it. most people get it but feel its too trivial to worry about. You seem to be saying that nothing has changed in the running of unix/linux since the year dot and you've never had to change a script at any time to allow for a change of process.
The rant is more like: "Why is systemd on my system? It's overly complex, works poorly [for server systems], it breaks backwards compatibility, uses binary log files (WTF!), etc."
Blame your distro maintainers that decided to use systemd or choose another one that doesn't use one. Ranting from a point of ignorance is a waste of time and ignorance is the start point of all anti-systemd rants. The ranters would spend their time better if they RTFM on systemd and learnt how to configure it.
RTFM on systemd configuration and you should be fine.
All they have changed is a default config option, just change it back or
a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora)
b) there's a runtime switch to turn this off locally on the system (in logind.conf)
c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.
Probably quite a bit because no-one does any research on the issue before winding their neck out and making random ignorant statements especially as its just a configure change not a functional one.
From the fedora thread on this issue.. "systemd 230 now finally flipped the switch and finally by default cleans everything up correctly when the user logs out. But we do so in a very conservative way actually:
a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora)
b) there's a runtime switch to turn this off locally on the system (in logind.conf)
c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.
https://wiki.archlinux.org/ind...
its all down to configuration so its up to you
i would have thought as long as you are not locking the wheels under braking or burning tyres under acceleration, you'd lose about the same amount as you would just moving.
its more to do with xenophobia and borderline racism fueled by fear from idiots like Trump. This sort of paranoia is not the exclusive territory of the badly educated
fortunately embryos that would have reproduced you, died within 5 minutes.
then you break out the wind turbine....
if you follow that lkml, they are discussing a patch, read a little further in the thread. "This is on Debian testing, with sysvinit and a systemd-shim to allow other parts to work." - i ignored the other 2 links as unverifiable anecdotes.
another load of anecdotal nonsense, he should have linked to a bug report
thats an unreliable anecdote, he can't find anyone else with the problem and seems like he's not even logged it as an error.
i think you need to get out more and see whats out in there beyond your scope of server use.
everybody who runs those types of systems needed it and thats why they all use it and contribute to it, not just Red Hat.
You might think its idiotic, i see it as being accurate. Every single way you read or inspect a file, it is done by using a tool whether it be 'cat' or 'grep' or journalctl. What you can do with journalctl and a few parameters, you'll need a lot of coding and testing to generate the same output via the "old" way. You can also pipe the text output from journalctl to any text parser you like.