>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...

If you left click a result first to give it focus, and then right click->open in new tab you'll get the original, full size, image.

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.

http://orgmode.org/worg/org-tutorials/orgtutorial_dto.html

There are some mobile apps but I've never used them.

A heat wave would still put every AC into service.

edit: I thought I commented on this story topic before and found this from over two years ago

https://news.ycombinator.com/item?id=8523104

Which supported service is not already running in the USA and subject to NSLs? In what way is Nylas reducing your privacy?

>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.

    grep -E "^[a-z]{5,10}$" /usr/share/dict/words | shuf -n5 | tr '\n' ' '

Meanwhile three years ago the message read: "Drive for Linux isn’t ready just yet"

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?

Where did you get that impression?

https://github.com/libressl-portable/openbsd/commits/master shows an actively developed project