You, sir, are a complete and utter idiot. I thought that roman_mir calling the genocide on the Native Americans 'a win in the marketplace' was bad, but you are edging pretty damn close to that line.
Erm, no, I'm coming at this from the other way: because I now have a way to apply resource quotas to a group of processes, including putting them in their own scope that's no longer dependent on an interactive session, I don't mind that ending an interactive session kills all processes except those specifically exempted.
Then we will have to disagree, because I like being finally able to hedge off a part of my processes and manage their resources in ways that login sessions and process leaders don't provide.
Yes it is. It is up to the session leader to handle the session. If you're going literal on me, I'd ask you nicely to point out where in the standard it says otherwise.
And cgroups are an improvement because they finally have one overarching system to classify processes, with a unified interface, and resource control for the entire group. Isn't that self-evident?
It's really a bit more complicated than that; a session lasts until the session leader kills all other processe; but even so, just because something's always been done that way does not make it a bad idea to try and improve upon it. And yes, I consider the systemd solution of using cgroups to create another sessions scope an improvement.
Yes, apparenty because that single source is the only one willing to work on these kind of infrastructure problems. The rest of the entitled little manbabies just go "WAAAAH! WE DON'T LIKE THEIR SOLUTION!!!".
If for worse, what's so bad at changing it? The worst I can think of is someone not reading the documentation on an upgrade and being surprised by the change, but if you upgrade critical system components without even reading the docs, let alone running them on a test system first, well, you deserve what you get.
Well, it's obvious who is the idiot here: the one who can't read and see that Martin Pitt explicitly mentioned that use case as not being covered by the new default.
From that manpage:
Also, please note that all limit settings are set per login. They are not global, nor are they permanent; existing only for the duration of the session.
Gosh, seems that limts.conf by design does not do what you say it does. If you log out, to what session does your screen process belong now? Systemd has taken the choice that unless you mark it as explicitly running in its own scope, it goes away with your session, something completely within the design spec of limits.conf. Yes, if you don't read the documentation, this comes as a surprise. True, the prinicple of least surprise says that defaulting to this behaviour is a bit less than optimal. But it is a reasoned deviation from the defaults, even if you disagree with it.
A better approach would have been to have a group that had the ability to make processes run after logout. That would be a security improvement, since you could then determine which users had the rights to have persistent processes.
But that's exactly what systemd does! It gives you tools to run these processes in their own scope, so that their resources can be properly managed, and the admin knows that these processes are meant to hang around.
No, Gnome is just the most obvious offender. But the problem exists; notwithstanding how handy things like screen are, to the system (and by extension, to the admin), a long running detached process is indistinguishable from a program that did not cleanly exit. In order to make that distinction, manual intervention is necessary.
The systemd devs just decided to default to kill 'em all in absence of intervention, mostly because with systemd admins finally have the tools to properly separate these kinds of processes into their own resource managed partitions, using cgroups.
I can see the logic. I can see why the change in default behaviour might be a bit disconcerting, but the sheer amount of hateful bile being spewed is absolutely not warranted, and in fact drives the undecided into the systemd camp.
The old ways were not perfect, despite all attempts by script kiddies in their momma's basement who pretend to be admins on Slashdot to convince us otherwise.
the reality can be seen in those distros and operating systems that do not use SystemD and are not "creaking"
So tell me, just how do you keep track of a started service, to verify that it is indeed running and to shut it down cleanly? If you have any better solution than pidfiles, I'd love to hear it.
And yes, that is one of the things that systemd solves. I may not always agree with the default settings chosen, but systemd exists because there are good technical reasons for something like systemd to exist, and the systemd devs are apparently the only ones who don't stop at whining but actually code. So long as the haters do nothing but whine, you will have to put up with Pottering's insights and foibles.
The stated reason that margins are too thin for OEMs is nonsense. I own a Blackview phone, from a Hong Kong manufacturer, and it updates nicely, one update a month on average, with a full update from 5.1 to 6.0 last week. So if Blackview can do it on its none-too-expensive phones, what's the other manufacturer's excuse?
No, it's perfectly in line with libertarianism as it is actually practised: naked authoritarian abuse of power by the rich and bootlicking toadies praising it as high principle.
Nope, I did not. I pointed out specifically that the current safety model as it depends on active input is unsafe. That's common sense. You brought up the health risks.
So fuck off, you blind apologist. I don't talk to stupid people.
Irrelevant. You're moving the goalposts; I wasn't constraining myself to health risks only, I was making an observation that systems that depend on active input do not fail safe and are therefore fundamentally unsafe. You have not addressed that.
Simple observable fact shows that the death penalty is no deterrent. States like Malaysia have the death penalty for drugs smuggling; yet smugglers still get caught. Empircal evidence says you're just a bigot looking for an excuse for your revenge fantasies.
I was pointed at Father Spee through the '1632' fiction series (where the writers perpetuate the mistaken 'von Spee' name). After reading up on him I was quite impressed. An interesting person, and the 'Cautio Criminalis' is an interesting work, so I am glad to help another one find it;)
has been known to be completely ineffective as a means of getting information at the very least since the French tortured vigorously in Algeria about 50 years ago.
For decades now the single largest block of media is controlled by a reactionary billionaire, and any attempt by non-reactionaries to point out that this may not be healthy for political discourse is shouted down or outright not reported on.
But God forbid a market party tries to use its freedom to present the news and not be a flaming reactionary; it will be plastered all over the media as a scandal.
Fuck you, you fucking reactionary shits. You made your bed of biased media, now lie in it and STFU.
Slashdot Mirror
Let's see:
You, sir, are a complete and utter idiot. I thought that roman_mir calling the genocide on the Native Americans 'a win in the marketplace' was bad, but you are edging pretty damn close to that line.
Erm, no, I'm coming at this from the other way: because I now have a way to apply resource quotas to a group of processes, including putting them in their own scope that's no longer dependent on an interactive session, I don't mind that ending an interactive session kills all processes except those specifically exempted.
Then we will have to disagree, because I like being finally able to hedge off a part of my processes and manage their resources in ways that login sessions and process leaders don't provide.
Yes it is. It is up to the session leader to handle the session. If you're going literal on me, I'd ask you nicely to point out where in the standard it says otherwise.
And cgroups are an improvement because they finally have one overarching system to classify processes, with a unified interface, and resource control for the entire group. Isn't that self-evident?
It's really a bit more complicated than that; a session lasts until the session leader kills all other processe; but even so, just because something's always been done that way does not make it a bad idea to try and improve upon it. And yes, I consider the systemd solution of using cgroups to create another sessions scope an improvement.
Yes, apparenty because that single source is the only one willing to work on these kind of infrastructure problems. The rest of the entitled little manbabies just go "WAAAAH! WE DON'T LIKE THEIR SOLUTION!!!".
If for worse, what's so bad at changing it? The worst I can think of is someone not reading the documentation on an upgrade and being surprised by the change, but if you upgrade critical system components without even reading the docs, let alone running them on a test system first, well, you deserve what you get.
Well, it's obvious who is the idiot here: the one who can't read and see that Martin Pitt explicitly mentioned that use case as not being covered by the new default.
From that manpage: Also, please note that all limit settings are set per login. They are not global, nor are they permanent; existing only for the duration of the session.
Gosh, seems that limts.conf by design does not do what you say it does. If you log out, to what session does your screen process belong now? Systemd has taken the choice that unless you mark it as explicitly running in its own scope, it goes away with your session, something completely within the design spec of limits.conf. Yes, if you don't read the documentation, this comes as a surprise. True, the prinicple of least surprise says that defaulting to this behaviour is a bit less than optimal. But it is a reasoned deviation from the defaults, even if you disagree with it.
But that's exactly what systemd does! It gives you tools to run these processes in their own scope, so that their resources can be properly managed, and the admin knows that these processes are meant to hang around.
No, Gnome is just the most obvious offender. But the problem exists; notwithstanding how handy things like screen are, to the system (and by extension, to the admin), a long running detached process is indistinguishable from a program that did not cleanly exit. In order to make that distinction, manual intervention is necessary.
The systemd devs just decided to default to kill 'em all in absence of intervention, mostly because with systemd admins finally have the tools to properly separate these kinds of processes into their own resource managed partitions, using cgroups.
I can see the logic. I can see why the change in default behaviour might be a bit disconcerting, but the sheer amount of hateful bile being spewed is absolutely not warranted, and in fact drives the undecided into the systemd camp.
The old ways were not perfect, despite all attempts by script kiddies in their momma's basement who pretend to be admins on Slashdot to convince us otherwise.
So tell me, just how do you keep track of a started service, to verify that it is indeed running and to shut it down cleanly? If you have any better solution than pidfiles, I'd love to hear it.
And yes, that is one of the things that systemd solves. I may not always agree with the default settings chosen, but systemd exists because there are good technical reasons for something like systemd to exist, and the systemd devs are apparently the only ones who don't stop at whining but actually code. So long as the haters do nothing but whine, you will have to put up with Pottering's insights and foibles.
The stated reason that margins are too thin for OEMs is nonsense. I own a Blackview phone, from a Hong Kong manufacturer, and it updates nicely, one update a month on average, with a full update from 5.1 to 6.0 last week. So if Blackview can do it on its none-too-expensive phones, what's the other manufacturer's excuse?
As I said: bootlicking toadies.
No, it's perfectly in line with libertarianism as it is actually practised: naked authoritarian abuse of power by the rich and bootlicking toadies praising it as high principle.
Nope, I did not. I pointed out specifically that the current safety model as it depends on active input is unsafe. That's common sense. You brought up the health risks.
So fuck off, you blind apologist. I don't talk to stupid people.
Irrelevant. You're moving the goalposts; I wasn't constraining myself to health risks only, I was making an observation that systems that depend on active input do not fail safe and are therefore fundamentally unsafe. You have not addressed that.
It's billions of damage; something capable of causing that kind of damage is unsafe.
>blockquote>Zero deaths, projected zero health impacts due to exposure.
Several billions cleanup costs.
Really, apologists for the current nuclear industry are masters at goalpost moving.
Existing plants are build to require active input to maintain their safety. The question is not if things will go wrong, but when.
What Fukushima showed is that the current nuclear safety model is fundamentally unsafe.
Simple observable fact shows that the death penalty is no deterrent. States like Malaysia have the death penalty for drugs smuggling; yet smugglers still get caught. Empircal evidence says you're just a bigot looking for an excuse for your revenge fantasies.
I was pointed at Father Spee through the '1632' fiction series (where the writers perpetuate the mistaken 'von Spee' name). After reading up on him I was quite impressed. An interesting person, and the 'Cautio Criminalis' is an interesting work, so I am glad to help another one find it ;)
It has been known far longer than that
For decades now the single largest block of media is controlled by a reactionary billionaire, and any attempt by non-reactionaries to point out that this may not be healthy for political discourse is shouted down or outright not reported on.
But God forbid a market party tries to use its freedom to present the news and not be a flaming reactionary; it will be plastered all over the media as a scandal.
Fuck you, you fucking reactionary shits. You made your bed of biased media, now lie in it and STFU.
Sorry, I misread your post for sarcasm, implying that systemd did not log to syslog.