Если вы хотите довести этот пример до возможности использования в реальной жизни — то настоятельно рекомендую прочитать вот эту статью: www.kegel.com/c10k.html
На счёт make install — cmake_install_prefix поможет, или вагрантовская виртуалка для опытов. Впрочем, тут каждый сам решает, делать ему make install, или не делать, а если делать — то где.
В ближайшее время из новых систем планируется только поддержка новой LTS убунты, которая в апреле выйдет. Основные силы разработчиков направлены на написание новых фич и починку багов. Если у нас получится собрать сборочные стенды с самыми разными популярными линуксами — то их поддержка может появиться, но вряд ли это будет раньше, чем через год, если вообще будет.
В целом же arch — достаточно красноглазый дистрибутив, вероятность появления сборки от поклонников арча далеко не нулевая.
Если быть ещё точнее, то вам нужен wordpress и вся инфраструктура для обработки запросов, балансировки нагрузки, хранения логов и мониторинги. С технической точки зрения именно контейнеры хорошо подходят для этой задачи, так что тут статья очень даже актуальна, но, в данном контексте, для разработчиков PaaS систем. А вам же уже нужны готовые решения, GAE, OpenShift, Heroku, Cocaine. Мне не раз приходилось рассказывать людям, что им не нужны виртуалки, и очень здорово, что вы сами поднимаете такие вопросы.
Чтобы сделать PKGBUILD для арча надо сначана изучить, как его делать, а потом сделать билд-ферму под него, чтобы регулярно тестировать сборку. Если у вас есть на это время — you are welcome! Опен сорс же так работает. Перед разработчиками Cocaine не стоит задачи охвата максимального количества разных дистрибутивов.
Их можно сколько угодно поднимать, а в клиентском фреймворке указывать список из агрегирующих нод. Между собой они ничего не шарят, так что пусть падают.
Скажу вам по секрету, kobolog — автор Cocaine :) А в рассылочку пишите, или ногами приходите, если будете проездом в Москве. Возможно, в этом году будут какие нибудь субботники с докладами про чудо-технологию в Питере.
Я же как раз и написал, «зачем». Чтобы не думать об инфраструктуре в каждом из приложений, а сделать её один раз. Вы попробуйте, всё не так страшно, переписывать всё с нуля не надо :) Ну или можно начинать новое писать под PaaS, а старое постепенно вывести из эксплуатации.
А откуда у вас такие знания про гугл и фб? Мне вот от сотрудников гугла доходили сведения, что у них очень даже PaaS под названием borg. А их новая система, про которую в интернете побольше ссылок есть, называется omega.
А потом навесить сверху балансировку нагрузки, управление пулом воркеров, сбор логов, вотчдоги, а в качестве отдельного бонуса — деплоймент свежей версии.
На самом деле, если надо запустить даже десяток приложений на паре десятков серверов — то всякие PaaS уже нанесут ощутимую пользу, уже даже за счёт унификации инфраструктуры. Если же приложения взаимодействуют друг с другом — то без какой-то платформы будет совсем печально.
Далеко не всегда изоляция на уровне контейнеров необходима, это от приложений зависит. Кому-то cgroups будет достаточно, а кому-то и на уровне разных процессов. Вы, наверное, сразу прикладываете подобные системы к продаже услуг хостинга частникам, да?
Контролировать, да. Попробуйте на трёшке бмв по снежку газ нажать в повороте — она начинает стараться вписаться в траекторию и делает эффект недостаточной поворачиваемости. Чем не контроль?
Судя по тому, как она там едет, я на 99% уверен, что занос включен в программу выступлений, слишком уж картинно. По моим субъективным ощущениям, не должно было её там занести без провокации, ну максимум — проехать мимо. Ехать в заносе — не самый эффективный способ прохождения поворота. К тому же, опять моё субъективное мнение, он там ехал с запасом. Сравните с заносами белой субары вот в этом ролике: www.youtube.com/watch?v=YiQ6FcyiPag (знаю, что грязно едет).
Кстати, в реальной жизни заносы почти всегда начинаются внезапно для человека. И если среагировать быстро — то рулить придётся на не слишком большой угол, кстати говоря.
Red Hat Enterprise Linux 6.5 enables customers to deploy application images in containers created using Docker in their environment of choice: physical, virtual, or cloud.
А что в этом сложного на заднем приводе то? Контролировать занос уже больше 15 лет назад научились, присутствует практически во всех современных автомобилях.
Вы забыли упомянуть, что фрезерный станок превращается в 3д принтер путём установки печатающей головки с хотэндом и немножко электроники. Правда по оси Z ход скорее всего будет меньше, чем у 3д среднего принтера с таким же размером рабочей области по XY.
Про то, что basic_string может быть сделан с рефкаунтерами и copy-on-write в стандарте написано, как и то, что это implementation specific. А в C++11 стандарте написано, что никаких copy-on-write больше нельзя. Вы же это хотели получить, да? В clang, если я не ошибаюсь, в строке никогда COW не было.
Ну а хак вы сделали отличный. Из-за него можно словить проблемы при компиляции, переконвертацию std::string в vstring implicitly (оно ведь умеет так, да?), ну и юзаете compiler-specific фичи, то есть какой нибудь clang идёт лесом уже.
Потестируйте std::string с --std=c++0x, высока вероятность, что будет работать не хуже, чем vstring. А раз используете специфичные для компилятора фичи — то и нечего на документацию языка или STL пенять. Разницу между string и __versa_string, очевидно, следует искать в документации GCC. Например, вот цитата:
That is not the case when reference counting is not used and indeed it will not be used (per the new C++11 Standard) in a new implementation of std::string which we are currently showcasing as <ext/vstring.h>
Как минимум пробовали в тестинге: Рамблер в своей почте, Байду для хранения аватарок, Docker для хранения образов систем, Undev.
В ближайшее время из новых систем планируется только поддержка новой LTS убунты, которая в апреле выйдет. Основные силы разработчиков направлены на написание новых фич и починку багов. Если у нас получится собрать сборочные стенды с самыми разными популярными линуксами — то их поддержка может появиться, но вряд ли это будет раньше, чем через год, если вообще будет.
В целом же arch — достаточно красноглазый дистрибутив, вероятность появления сборки от поклонников арча далеко не нулевая.
?
Чтобы сделать PKGBUILD для арча надо сначана изучить, как его делать, а потом сделать билд-ферму под него, чтобы регулярно тестировать сборку. Если у вас есть на это время — you are welcome! Опен сорс же так работает. Перед разработчиками Cocaine не стоит задачи охвата максимального количества разных дистрибутивов.
www.usenix.org/cluster-management-google
www.youtube.com/watch?v=WbE3wAJCm3I
А откуда у вас такие знания про гугл и фб? Мне вот от сотрудников гугла доходили сведения, что у них очень даже PaaS под названием borg. А их новая система, про которую в интернете побольше ссылок есть, называется omega.
На самом деле, если надо запустить даже десяток приложений на паре десятков серверов — то всякие PaaS уже нанесут ощутимую пользу, уже даже за счёт унификации инфраструктуры. Если же приложения взаимодействуют друг с другом — то без какой-то платформы будет совсем печально.
Судя по тому, как она там едет, я на 99% уверен, что занос включен в программу выступлений, слишком уж картинно. По моим субъективным ощущениям, не должно было её там занести без провокации, ну максимум — проехать мимо. Ехать в заносе — не самый эффективный способ прохождения поворота. К тому же, опять моё субъективное мнение, он там ехал с запасом. Сравните с заносами белой субары вот в этом ролике: www.youtube.com/watch?v=YiQ6FcyiPag (знаю, что грязно едет).
Кстати, в реальной жизни заносы почти всегда начинаются внезапно для человека. И если среагировать быстро — то рулить придётся на не слишком большой угол, кстати говоря.
Ну и докер не обязательно использовать, тогда особо без разницы, какое ядро.
Ну а хак вы сделали отличный. Из-за него можно словить проблемы при компиляции, переконвертацию std::string в vstring implicitly (оно ведь умеет так, да?), ну и юзаете compiler-specific фичи, то есть какой нибудь clang идёт лесом уже.
Потестируйте std::string с --std=c++0x, высока вероятность, что будет работать не хуже, чем vstring. А раз используете специфичные для компилятора фичи — то и нечего на документацию языка или STL пенять. Разницу между string и __versa_string, очевидно, следует искать в документации GCC. Например, вот цитата: