Readit NewsThe code has been updated and now you can change the pooped char on the fly with something like :
`echo "<WHATEVER UTF-8 CHAR>" | sudo tee /sys/module/pooper/parameters/char_utf8`
/etc/pooper file and module unload/reload are no more needed :)
People who call themselves doctors — e.g. neurologists — generally aren't hesitant to do this. But psychiatrists — and even moreso, therapists — generally are. And psychiatrists+therapists lead the conversation on mood disorders, since that's who everyone is talking to about their mood disorders.
IMHO it's just the hammer-and-nail thing. To a cardiologist, every medical problem is seen through a potentially cardiovascular lens; to an oncologist, every problem is a question of what type of cancer could cause it.
Psychiatrists are technically medical doctors, but they spend their entire careers (after a few short years of school) focusing on psych cases; where these patients' problems either are purely psychological (e.g. conditioned-response, traumatic-response, coping/defensive, attachment-related, etc.), or at best "we don't know" the degree to which they're psychological vs organic. (If we can recognize a problem as purely organic from the outset, that problem doesn't end up in the hands of a psychiatrist!) And either way, they usually see good results in clinical practice from treating the patient's mind, rather than addressing organic signs/symptoms directly. Even when they prescribe medication, they're measuring their success on a mental basis (using questionnaire-based instruments used to gauge mental changes) rather than observing changes in e.g. measurable behavioral signs. The problems they're faced with, and the successes they have via these models, reinforce in psychiatrists a mind-centered mental model / worldview for psychiatric disease. (A model which is "the right one" to use in many psychological diseases! But not for many others.)
And therapists aren't even medical doctors. They never learn much-at-all in school about potential organic causes of psychological (or medical) problems. They focus purely on this lens of "the mind", ignoring the lens of "the brain as an organ" entirely. This means that in clinical practice, when confronted with a problem that has both mental and organic aspects, a therapist will tend to ignore the organic aspects; and when confronted with a problem where the organic aspects are too large to ignore, the therapist will simply refer to a psychiatrist (or neurologist, maybe) — with no follow-up, and thereby, no way to end up learning what the patient's problem actually was and thereby evolving the neurological side of their understanding.
Your ideas about how psychiatry is practiced might have been correct in the 1950’s but they’re a world away from how it’s done in the 2020s.
Uh, can’t imagine too many people reading this are playing Origin-era EA games on a Pentium 4
I do want to pick on this specifically - people can and should be patching open source projects they depend on and deploying them to production (exactly as described in the article). Something being in the language vs in “user” code should be no barrier to improving it.
Back when it was just environment variables, I could pipe /proc/PID/environ to xargs and get basically the same state. Given that things like unix domain sockets may end up in $TMPDIR, I can be left unable to do certain things.
Also you can use nsenter(8) to run a command (or even a shell) under another process’s mount, pid, network, etc namespace.
When JIT code size (RubyVM::YJIT.runtime_stats[:code_region_size])
reaches this value, YJIT triggers "code GC" that frees all JIT
code and starts recompiling everything. Compiling code takes
some time, so scheduling code GC too frequently slows down your
application. Increasing --yjit-exec-mem-size may speed up your
application if RubyVM::YJIT.runtime_stats[:code_gc_count] is
not 0 or 1.
It just dumps all the JIT-compiled code? I'd expect to see some kind of heuristic or algorithm there... LFU or something.
The internals of a JIT are essentially black magic to me, and I know the people working on YJIT are super talented, so I am sure there is a good reason why they just dump everything instead of the least-frequently used stuff. Maybe the overhead of trying frecency outweighs the gains, maybe they just haven't implemented it yet, or maybe it's just a rarely-reached condition.
(I hope a YJIT team member sees this, I'm super curious now)
When the stub is hit the code that gets generated is somewhere _else_ in executable memory, not contiguous with the original bit of the method. Because these "lazy basic blocks" are actually quite small, the bookkeeping involved in "where is the code for this ruby method" would actually be an appreciable fraction of the code size itself. Plus you then have to do more bookkeeping to make sure the method you want to GC isn't referred to by the generated code in another method.
Since low memory usage is an important YJIT goal, I guess this tradeoff isn't worth it.
Maybe someone who knows this better will come along and correct me :)
OpenBSD's doas is 108 lines of C. sudo and doas are not equivalent in functionality, but it shows how simple things can really be.
https://github.com/openbsd/src/blob/master/distrib/special/d...
Still just a tidy 1072 lines in that folder though.
I spent 5 minutes staring at your file trying to understand how on earth it does the things in the man page, but of course it doesn’t.
> Look at his CV. Tiny (but impactful) features ///building on existing infrastructure which has already provably scaled to millions and likely has never seen beneath what is a rest api and a react front end///
Off the top of my head he wrote the socket monitoring infrastructure for Zendesk’s unicorn workers, for example.