vikrantrathore

I think the simple answer is philosophy of Kaizen(改善)- continuous improvement. I started working with postgresql when it was just postgres95. Recently found that my earliest question on postgresql-users was 13th October 1998, 20 years ago (https://postgrespro.com/list/id/3.0.2.32.19981013214318.0069...).

I still use PostgreSQL in my startup for almost all critical production workload. This in itself a testament to its improvements. I remember I starting with c libraries of msql and postgres95 and continued to work with them as they evolved into postgreSQL and a new kid on the block mysql. I liked postgreSQL due to its adherence to SQL. Since I like working with relational algebra. So even though MySQL was more popular in later years, I still used PostgreSQL more often, except for building qmail servers with mySQL backend.

Good work been using it as an alternative to Github and Bitbucket for over 3 years now. We have a small team with more then 52 private repository and works good so far. Besides this we replicate all the upstream opensource repository and keep it synchronized in our own instance. This is done very easily as Kallithea supports both git and mercurial. We do pull request review online and merge it offline and then push the changes to main repository. Our costs is $10/month for hosting with unlimited users, unlimited repository and small update maintenance whenever a new release comes in.

Being working mostly in python and mercurial we choose it and are using it in production for 1-1/2 years and it's been very good so far.

Agree with you coming back to the point when 5% Indian owns 80% of wealth why they aren't the target. Only targeting 20% wealth owned by over 80% common Indian won't bring any benefits.

Trix is better as it works with new web components standard, quill does not support shadowDom in chrome and doesn't follow current web components standard, check https://github.com/quilljs/quill/issues/904 for details. It will create issues when used in web components project.

thats the main issue they don't use LXC but want LXC kind of functionality and re-inventing the wheels with libcontainer. Indeed it would have been better to keep the docker core as small as possible and move LXC driver code as module. Indeed instead of using LXC userspace tools they might have focused on rebuilding the driver using lxc-go. This would have helped LXC project as well and docker team then can focus on incorporating production quality changes from LXC into Docker like unpriviledged containers.

This is really an issue abandoning a production quality LXC 1.0 code and re-writing it from scratch. This is NIH syndrome.

Actually I was thinking docker to re-use lxc-go to build the driver for LXC instead of using LXC userspace tools, this would have helped linux containers project as well. But I never intended they should re-write a new library from ground up.

My feeling was since LXC is already 1.0 and almost production ready, it would have been better to integrate its features in docker to make it production ready with one of the major enhancement of unpriviledged containers.

Now libcontainer as it is re-inventing the wheels, what's being done by LXC, will require a long path towards stability similar to LXC 1.0.

Moreover docker team should have spend more time building other drivers similar to LXC for OpenVZ or Solaris and BSD zones. Anyways I am not doing any code contribution so do not know the priority of the docker team. But this seem more sensible to me. Just my two cents.

I am using tinkerer http://www.tinkerer.me/, its very simple to change and manage and uses well known sphinx-doc with jinja templates. I like it a lot you can check my live site at http://www.vyomtech.com/, since it uses boilerplate html 5 template its very easy to customize.