Понятно, спасибо. Синтаксис, это все на любителя.

Про rust я не говорил. А взять тот же erlang, алгоритм чего вы хотите увидеть? Там и так все прекрасно с решением той задачи, которая описана в этом посте + равномерная загрузка всех ядер.

Если выбирать сейчас? На мой взгляд, ocaml, более практичный, ну не ленивый из коробки.

Берем erlang, haskell, ocaml + lwt и не паримся.

Хотел еще спросить. В списке кандидатов был ocaml?

Есть еще один плагин — github.com/tjarvstrand/edts

Понятно. Спасибо.

А для чего у вас остался erlang?

Вы erlang совсем выпилили?

Вот когда это будет доступно всем, тогда и поговорим.

Ну о том и разговор :)

Ну, так вы почитайте, какие мега костыли там предлагают.

Вы расскажите, каким образом устроено облако?

Каким образом приложение синхронизирует файлы? Есть докача?

Я говорю про веса, они вообще не работали на последней версии openvz 1 год назад. Имеем 40 виртуальных машин, все с разными весами, контейнер с самым маленьким приоритетом может загрузить весь cpu на хост ноде, когда он нужен остальным.

Так же, хочу извиниться, что влез в обсуждения, с такими комментариями, все же это не правильно.

Да хотя бы размещать файлы клиентов на lvm, а не в файле? Все ключивые фичи, которые вы указали, давно есть в xcp и проверено в xenserver. Так же, не знаю, поправили или нет, 1 виртуалка в openvz может полностью загрузить хост ноду.

Централизованное хранилище, это не заслуга PCS, так как он просто оперирует файлами, так что просто mount nfs://…

Так же, сама система виртуализации: нормальная vs расширенный чрут.

Вам openvz видимо нравится вот по этой причине:

Плотность контейнеров получилась больше, чем на OpenVZ и других платформах
Экономим ОЗУ и дисковое пространство

?

Если уж оверселить, с той же памятью, можно например взять — www.redhat.com/products/cloud-computing/virtualization/, если я ничего не путаю, в kvm из коробки можно оверселить память. И это на нормальном гипервизоре.

Можно понять, когда люди используют контейнеры для разработки, такое может быть удобно. Но когда начинают использовать для предоставления массовых услуг, как-то не понятно эта мотивация.

Много времени прошло с debian 4, и выбирая сейчас, отталкиваться от совсем старого опыта, как-то странно.

Если вы читали посты селектела, почему они отказались от снапшотов, там amarao рассказывал, какие есть проблемы. XCP очень плохо следит за зависимостями и связностью снапшотов, и из за этого возникают проблемы. Очень активно, это если постоянно восстаналиваться со снапшота и делать снапшот снапшота, очень часто и очень много. А так там есть cow.