This is very interesting, because most docker break outs I see are exploits in the linux kernel, but this is one of the few in the containerization components themselves (first one I remember in runC).
Because the abstractions are good and the implementation gets better over time as with any other software. Obviously truly sensitive data should be handled on separate physical nodes (defense in depth).
(Note: obviously my opinion, not the actual rules)
I do think the rule should be based on the content of the release rather than the timing. If the software contains major new features every month that could be relevant to the HN audience I see no reason to remove the post, it's _new_ information being posted on Hacker _News_. (I haven't seen the referenced IDE update post so I don't have an opinion on it either way.)
Yeah, I think GitLab in particular is a really interesting product that competes in a crucial space for devs. In addition, they've committed and stuck with monthly releases, with new features/improvements, so that's why it's posted so much. I love the monthly releases though.
This "rails/ruby is slow" myth really needs to die. Sure, rails is too slow for certain very large companies at very large scales, and if you're in this position you already know it. However, rails is fast enough for 99.5% of usecases, gitlab included.
As to memory usage, I will concede it is often somewhat high with rails, but there are solutions, such as jemalloc that have helped me in the past.
I didn't say GitLab was fast (I haven't used it enough to know), but blaming its problems on ruby/rails when GitHub (which is pretty fast imo) is also written on rails is misleading at best.
Not true (at least in the US): weary (at least the adjective) is pronounced with a "we" at the beginning, while wary is pronounced with a "wear" at the beginning.
