sply

But in fact, K8s provides more robustness than old good kinda monolith Pacemaker

Good analysis from Steven J. Vaughan-Nichols.

Bottom line: Even Accenture, the Microsoft partner, which suggested Munich return to Windows, doesn't consider Windows as the sole best option.

TL;DR On writes RocksDB is first, then PerconaFT, then WiredTiger.

Interesting results. Last months I saw the production use of MongoDB with RocksDB engine only once. Do you use engines other than WiredTiger (or mmapv1) and what were your reasons to do it?

Not sure. I personally know four projects using mLab and MongoDB Atlas. Maybe the poll just buried in other posts.

Related: https://www.quora.com/What-is-the-best-mongodb-hosting

Very thoughtful notes, thanks. Waiting for your full blog posts.

Have you examined emerging databases like Tarantool https://tarantool.org/, GunDB http://gundb.io, TiDB https://github.com/pingcap/tidb, ClickHouse https://clickhouse.yandex/ ?

It would be great to read some deep and independent analysis for them to.

> if your product sees meaningful adoption in the industry they launch their own service and take all your customers

Yes, very similar to Windows, Android etc, when owners of the platform learn which product goes well, and then make it themselves.

This can be seen as a kind of response to concerns about the survival of other open source databases raised after closing RethinkDB and its recent postmortem https://news.ycombinator.com/item?id=13421608

Just for history:

First post saved by archive.org: http://web.archive.org/web/20170114090437/http://rhelblog.re... Latest post: http://web.archive.org/web/20170117054512/http://rhelblog.re...

  $ wdiff -n -3 first latest
  
  ======================================================================
  [-Docker 0-Day Stopped Cold by-] SELinux
  ======================================================================
   SELinux {+Mitigates docker exec Vulnerability+}
  ======================================================================
   Fixed packages [-have been-] {+are being+} prepared and shipped for RHEL
  ======================================================================
   [-Centos.-] {+CentOS.+}
  ======================================================================
  
  
  
  [-Stopping 0-Days with-] SELinux
  ======================================================================
   SELinux {+Reduces Vulnerability+}
  ======================================================================
  
  
  [-How about a more visually enticing demo? Check out this animation:-]
  ======================================================================
   we were glad to see that our customers were [-safe-] {+safer+} if running containers with setenforce 1
  ======================================================================
   {+Even with SELinux in enforcement, select information could be leaked, so it is recommended that users patch to fully remediate the issue.+}
  {++}
  {+This post has been updated to better reflect SELinux’s impact on the Docker exec vulnerability and the changing threat landscape facing Linux containers.+}
  ======================================================================

I'm not sure that first post's version can be considered as recommendation to not upgrade. It just shows how RedHat people was happy to see that bug was prevented by another subsystem. Me, as a sysadmin, would be happy to to know that I'm not obligated to upgrade urgently everything I have. For most sysadmins it can be considered as a workaround, already engaged.

You as a Docker developer see the post as an attack on your project. But most of sysadmins and kernel developers see it as a nice example of the fruits of invisible long work - when well cared system with accurately configured security restrictions saves from some vulnerabilities.

Anyway, it not means underestimation of the Docker and you great job. Sorry you've got stressed by all this noise.

BTW, can you confirm than SELinux in enforcing mode really prevents exploiting of this runC vulnerability? Therefore, the argue on the post's correctness considers only RadHat's marketing war.

Because if the answer is "No", and there's some other way to bypass SELinux and exploit this bug, it raises more grave accusation of RedHad - false statement about the vulnerability workaround.

Thank you for clarification of your point. It really shows perfect example of the Red Hat marketing.

Can you please give a link to the announce from Red Hat or someone else urging their users that they don't need to upgrade? It would be the last thing closing the question.

No, you should use

  sudo sh -c "cat foobar.img > /dev/sdi"

or

  sudo -s "cat foobar.img > /dev/sdi"

See also discussion started from Ruby 2.4 announce few days earlier: https://news.ycombinator.com/item?id=13252225

There's "Ruby 3x3" plan to increase performance by 10x - https://blog.heroku.com/ruby-3-by-3

So when the plan will be realized, it would be these 2-10x slower than others.

Performance related:

  * Hash improvements via better locality for modern CPUs
  * #max and #min without temporary array
  * Speed up instance variable access

There's nice manual about data model correspondence between MongoDB and Couchbase