TA0x0
Logical, rational, built from facts. The thought process used by a Harvard grad, MIT research scientist.
>Which is pretty indicative of why he was fired.
"They hated him because he told the truth."
Except it is, and I just proved it above.
>You might as well measure bumps on people's heads to predict whether they want anti-violence funding
Bumps on people's heads have nothing to do with violence. This is a non sequitur.
>you'll have about as much luck as you will chasing it after skin color
That makes no sense. The fact that the group is more violent is not open to interpretation, or "chasing", as I proved above.
>manifestations in African American culture that breeds violence" (what does that even mean?).
Almost, but in specific cases like above, it is not open to interpretation. It's a raw fact.
>Statistics is the science of interpreting discrete data points, looking for patterns and relations.
And organizing and presenting discrete data, without interpolation.
>The only thing that stands alone without interpretation in statistics is the input data itself, and that tells us nothing.
Wrong. Basic presentation without interpolation is a core pillar of statistics.
>I suspect that for the specific claim you've made, the evidence supports the claim, but I'd want to see whether they've controlled for conflating the definition of "crimes committed" with "charged with crimes" or "convicted of crimes" to be certain.
Even with controlling, African Americans are charged, commit, and are convicted of more crimes than Asian Americans.
>Or whether the statistics are using the Bayesian or frequentist approach (after all, the claim being made is "are more likely," and that always assumes a giant pile of unstated priors).
None of the above, just basic summary statistics.
>Even still, whether the statistical claim being made is fact is uninteresting. If one assumes it's fact, the interesting question is "What do you do with it?"
It's super interesting, considering what the OP asked.
>Nothing. It's not nearly enough info to form theory or policy.
It's more than enough info to form theory, and possibly policy.
>Which is why my original response to your original post was about interpretation, not fact.
And what I've stated above is fact, not interpretation. Back to square one.
>Interpretation is where things get interesting. Facts without interpretation are dead as rocks.
Wrong. Facts without interpretation are as alive as can be, and stand on their own.
There are some facts, like the one I listed above, that are not open to interpretation.
Any and every statistical study ever done on race and crime supports the FACT stated above. Per capita, it's an indisputable fact that they commit more violent crimes, raw numbers alone, no curve fitting or extrapolation.
>And if one runs with that fact alone and tries to build behaviors on it, one's likely to fall into a similar trap to the one the phrenologists fell into: assuming that a single fact is descriptive enough of the world to dictate theory or practice.
Which brings us back to my original statement. Are facts racist and sexist?
Some facts are not open to interpretation.
The less systems touches the better.
>I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error.
Who said this was bash? The script from all those years ago worked perfectly without race conditions.
>They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps.
Makes no difference, procfs works fine for this.
>Try unmounting proc and running ps or kill and see what happens.
You're effectively never unmounting procfs. Also, if you managed to, systemd would crash!
>If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill().
There's maybe 10 lines of code to ensure that logic. Again, middling sysadmin work.
>POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned.
POSIX does say something about this; read about signals. You stop the process before killing it, and ensure that the start time is the same for the stopped process before the kill. That completely eliminates the race condition, using basic POSIX signals.
>There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill.
That race condition is eliminated with the logic above. That eliminates the PID reuse race condition, even if it's very rare.
>reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal.
That functionality is where it belongs now, so instead of coding a logic every time you have to ensure PIDs, it's now handled for you.
>There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.
Correct, I don't want to hear it from someone who doesn't understand POSIX and basic/intermediate sysadmin work.
In certain cases I don't disagree, but systemd does not implement this feature correctly, so using functionality that's easily reviewable from decades past makes sense. If systemd could properly implement the feature, there would be no need for the scripting.
>It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs.
This is hilariously wrong. Lots of UNIX OSes don't even implement the ps suite of tools by using procfs.
Even then, there were no race conditions in this use case anyway.
>You would need to implement this in C for it to have a chance of being safe at all, and even then, you would need to rely on system-specific functionality because there is no portable way in POSIX to actually do this.
It's already implemented this way on plenty of UNIXen. ps and kill is the POSIX portable way to approach this, so you're wrong about that as well.
Almost everything you said above is incorrect, or misunderstanding basic UNIX.
Even then, yes, the functionality of using ps and kill together has existed for 20+ years. Those tools are already implemented, providing the functionality for decades.
In no universe is logind considered robust, and basic scripts from middling UNIX admins have provided this functionality for decades, untouched. Even the "janky" ones.
A mid-level admin in 1995 could have easily made a 100 line script to kill background processes from non-logged in users that were running over three hours (or whatever).
systemd brought nothing to this arena.