>GitLab has memory leaks. These memory leaks manifest themselves in long-running processes, such as Unicorn workers. (The Unicorn master process is not known to leak memory, probably because it does not handle user requests.)
>To make these memory leaks manageable, GitLab comes with the unicorn-worker-killer gem. This gem monkey-patches the Unicorn workers to do a memory self-check after every 16 requests. If the memory of the Unicorn worker exceeds a pre-set limit then the worker process exits. *
I know this is a Rails issue, but I cannot believe this is still a problem. I remember when the RoR folks blamed the Rails memory leaks on Zed, and Mongrel, more than a decade ago. They were obviously incorrect. Did the community simply give up on fixing the problem?
I had the same issue. Didn't realize .us required your info to be published. My registrar upsold me their whois guard service, but it sat unredeemedable on my account while spammers harvested my info.
Thanks for highlighting this. For me, OpenBSD releases needed so few fixes that keeping the system up to date wrapped around, and become more of a hassle to deal with! I'd get an email and have to manually rebuild something. Watching yet another flood of compiler output started feeling like a huge waste of time, despite only happening once every month or two.
For personal use, on debian I set a cron job and forget it. This utility hits the sweet spot to get me running OpenBSD again.
Check out org-mode. Handles todos, scheduling tasks, timers, you can link directly to a file or an email (not a copy, but a link emacs follows into your mail reader, such as mu4e/gnus/wanderlust, for that specific email). It will auto generate an agenda from multiple todo files spread across your filesystem.
>We suggest that you include five words of 5-10 letters in size, chosen at random, with spaces, special characters, and/or numbers embedded into words.
>You need to be able to recall the passphrase that was used to encrypt the file.
Why bother writing security guidelines which are impossible for a human to follow?
edit: Try recalling any passphrases generated by the command below, and that's before the random sprinkling of punctuation.
Python 2 had an inherent flaw with character encoding. While passing data around, strings and bytes were treated as the same thing, until they weren't the same thing, at which point your software broke in horrible and unexpected ways.
Python 3 fixed it, along with some other less drastic changes. Despite a gradual and ever ongoing migration to python 3 by every major library (http://py3readiness.org/https://python3wos.appspot.com/), a lot of HN posters love to talk about how they'll never use python 3.
The secret is: no one cares. People still use java 1.4.2 and that hasn't impeded Java.
Python 3 was a large and backwards capability breaking change that required people to learn some minor new behaviors when writing code, but it has been and will continue to be the future.
They're dressed up versions of "correlation != causation". Low thought comments appealing to people with not-even stats 101 knowledge.
There is no such thing as a perfect study, and a generic version of the OPs comment could be copy and pasted on any study ever. Unless you study the entire population of the planet, you're going to miss subgroups. Unless you study the entire population of the planet, you're going to need some sort of selection criteria. Unless you have infinite funding and time, you're going to need to make trade offs and sacrifices in your experiment design.
A study will disclose these shortcomings for readers to balance the significance of results against.
Take this complaint from OP:
>* The sample size was tiny. (20 students)
What sample size would satisfy him? Why is 20 too small? 40? 80? 1037? Is he basing his opinion of a proper sample size on his gut? 20 just doesn't feel right?
>To make these memory leaks manageable, GitLab comes with the unicorn-worker-killer gem. This gem monkey-patches the Unicorn workers to do a memory self-check after every 16 requests. If the memory of the Unicorn worker exceeds a pre-set limit then the worker process exits. *
I know this is a Rails issue, but I cannot believe this is still a problem. I remember when the RoR folks blamed the Rails memory leaks on Zed, and Mongrel, more than a decade ago. They were obviously incorrect. Did the community simply give up on fixing the problem?
* https://docs.gitlab.com/ee/administration/operations/unicorn...