Phusion Blog

.. no? Because many of the grsecurity+pax improvements apply to any kernel that runs on a CPU (it provides active protections against certain forms of kernel vulnerabilities caused by bugs). This includes illumos, thus the question is valid.

grsecurity is a set of patches for the GNU/Linux kernel. illumos is based on Solaris, so the entire argument about grsecurity is nonsense. illumos uses red zones to prevent buffer overflows, which grsecurity is attempting to address. grsecurity is a commercial product by the way. A single license costs $19,000 USD.

Enhanced auditing and process control which grsecurity provides have been part of Solaris, and therefore illumos, since Solaris 10, some even earlier. GNU/Linux is still playing catch-up, and as long as people like myself, Bryan Cantrill, Adam Leventhal and the rest of the former Sun kernel engineers live, it will be playing catch-up forever.

My impression about package management being a shit-show on other operating systems is that every single podcast or blog post I read about those operating systems is celebrating that "package management is easy now with pkg" -- while it's actually not IMO as good as certain GNU/Linux package managers.

In order for that opinion of yours to actually mean anything, the question is: how many packaging formats do you know to produce packages for? Only then will you be in a position where you would actually be competent to make such a statement, and where your opinion would actually make a…

Phusion co-founder here (creators of the Passenger app server); just wanted to chime in and say that this article resonated a lot with our experiences with VCs and our ventures in open source. Even down to the "lifestyle business" remark. Like OP, I'd encourage first-time founders to talk to VCs when starting out just to get an idea of how they perceive your business. Yes, even if you don't plan on raising. You may walk away learning a thing or two :-)

As for RethinkDB; we loved it, and even wrote an article about it a few weeks ago, outlining how it could be awesomely used with Rails 5 [1]. Having tried to bootstrap a company solely around an open source product ourselves as well[2], we can't help but share their pain here a bit. For instance, and I'm just going on what OP has shared about RethinkDBs business model, we tried to build our business solely on support contracts initially too. That didn't work out great for us.

And it kind of makes sense if you think about it: the support contract is available in case your software is failing during critical operations, yet your main efforts in product improvements are to minimize those chances. So you may have two conflicting interests, and I think you will find yourself having a hard time satisfying both. Through product improvements, you're basically minimizing the probability that such a support contract is needed. That might make it more enticing to only get the contract whenever you actually really need it, and that…

If you're using Rails 5 ActionCable and you're not on Passenger, I would recommend upgrading to this release as soon as possible. Phusion[0] and other Rails 5 users[1] found a slow client issue with its implementation that was not protected against by the default app server Puma.

We contacted the Rails team early on about this issue and worked closely with them to have this issue solved. Now that 5.0.1 is released we are at liberty to disclose details about this security issue.

I've written a blog post[2] on the problem, using OS X network shaping tools and a simple app to demonstrate it. Rails apps running on Passenger were never affected as Passenger implements response buffering for regular requests as well as websockets connections. Note that even popular reverse proxies like Nginx don't perform response buffering for websockets as far as I know, so this is something to be aware of if you're running on other frameworks than Rails as well.

[0] GH merge of patch: https://github.com/rails/rails/pull/26646

[1] GH related issue: https://github.com/rails/rails/issues/26409

[2] Blog post: https://blog.phusion.nl/2016/12/21/actioncable-under-stress-protecting-your-application-against-slow-clients-using-passenger/

That doesn't have anything to do with Poettering's quote.

PR_SET_CHILD_SUBREAPER moves the ownership of an orphaned process to whichever process was selected rather than the default PID1, and that only works for descendant of the subreaper.

The problem pointed by the quote is that normal software doesn't go around checking if it has zombie children and waiting on them, so in a container with random software S set as PID1 and creating subprocesses, zombies may accumulate until resources are exhausted[0].

PR_SET_CHILD_SUBREAPER is a way to cause that problem on a system with a proper init (or to test that your init works properly without needing to boot into it)

It's not a new observation: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

Previous HN discussion: https://news.ycombinator.com/item?id=8916785

[0] by default the limit is 32k processes after which the kernel will simply refuse to create new ones

I forgot to mention, the Phusion guys (who Mitchell mentions in the post and who create the excellent Passenger web server) have created some great assets for Vagrant and Docker:

https://github.com/phusion/baseimage-docker

https://github.com/phusion/passenger-docker (built on the baseimage above)

http://blog.phusion.nl/2013/11/08/docker-friendly-vagrant-boxes/

And regarding role-based containers, Phusion's Hong Lai says:

"Wait, I thought Docker is about running a single process in a container?

Absolutely not true. Docker runs fine with multiple processes in a container. In fact, there is no technical reason why you should limit yourself to one process - it only makes things harder for you and breaks all kinds of essential system functionality, e.g. syslog.

Baseimage-docker encourages multiple processes through the use of runit."

The part about inability to speed up authenticated page loads fails to take into consideration things like ESI.

If the majority of your page is still the same for logged-in users, but they see some pieces of content personalised for them, breaking them out into individually request-able components means you can let software like Varnish or a CDN rely on it's cache of the main page content, and make a very small (and ideally simple to process on the backend) request for the per-user content.

It took me some hunting to find it (no docs for v5 yet apparently) but if your stack already includes a caching layer (e.g. Varnish or a CDN) you may want to disable this extra cache using the config described here: http://blog.phusion.nl/2014/11/25/introducing-phusion-passenger-5-beta-1-codename-raptor/#mc_embed_signup