А можете как-нибудь решить проблему с массовыми действиями?
По ошибке недавно в одну цепочку прилетело 30к писем, через веб-интерфейс их не удалить — 5 минут ждет, затем пишет, что письма удалены, а на самом деле они остаются.
По поводу фич Вы правы, подход, который разделяет управление дисковыми устройствами и виртуализацией, затрудняет реализацию таких вещей. Но если говорить о производительности, sparse-файл со своей ФС внутри явно проиграет проброшенному LV или блочному устройству.
Под простотой я имел в виду внутреннее устройство. OpenVZ лезет почти во все подсистемы ядра, и переносить в осн. ветку эти воздействия начали относительно недавно. А чем больше объем системы, тем больше в ней ошибок. На ядре 2.6.18, которое совсем не использовало LXC, иногда возникали очень печальные баги (вроде проседания сети в 1.5 раза) даже без запущенных контейнеров, просто после перезагрузки в OpenVZ-ядро. Сейчас, как я понимаю, должно стать лучше.
А XML это не минус, а плюс. Все равно при продаже VPS или облаков клиентам нужно писать им панель/биллинг, и тут перекидываться xml-ками с libvirt будет удобнее, чем текстом с vzctl.
При использовании KVM накладные расходы на сеть становятся заметно ниже при использовании vhost для сети. Я бы сказал, что это только расходы на поддержку сетевого моста и tap-устройства, то есть то же самое, что и в openvz при использовании veth.
Для диска OpenVZ сейчас предлагает использовать ploop, у которого накладные расходы сравнимы с дисковыми накладными расходами от xen/kvm+virtio, так как принцип работы тот же.
Пользовательский код выполняется что на kvm, что на openvz абсолютно одинаково без оверхеда (если не считать лишнего уровня косвенности при обращении к таблице страниц (но его почти убирает TLB) и возможных тонкостей с вытеснением нужной информации из кеша). Проблема остается только с системными вызовами, но тут у каждой из виртуализаций свои проблемы.
Но KVM проще и обеспечивает больший уровень изоляции.
>да, очевидно, что Роджерс совершил преступление, получив нелегальный доступ к базе, но не меньше виноват и сам сайт, который не был способен защитить свои данные
Очевидно, что убийца совершил преступление, заколов врага ножом, но не меньше виноват и сам враг, который сделан из мяса и так легко протыкается ножом.
Заголовок немного странный: чтобы объединять усилия, должны быть усилия с обоих сторон. А усилия есть только со стороны RedHat.
Видимо, RedHat не хочет заката бесплатного варианта своей ОС (о чем многие говорили несколько лет назад, когда разработчики ссорились, CentOS6 не выходил, а баги игнорировались), поэтому берет проект под свое крыло.
После «Отсортирован по ключу -> Да» должно быть «Требуются частые добавления/удаления», где «Да» ведёт на set/map, а «Нет» — на «Отсортированный vector или vector<pair<key, value>>»
Передавать параметр list по ссылке — плохой тон. Так как функция изменяет параметр, лучше было бы передать по указателю, чтобы в месте вызова было видно, что list изменится.
По ошибке недавно в одну цепочку прилетело 30к писем, через веб-интерфейс их не удалить — 5 минут ждет, затем пишет, что письма удалены, а на самом деле они остаются.
В начале обещали рассказать о теоремах о невыразительности, но не рассказали :(
Под простотой я имел в виду внутреннее устройство. OpenVZ лезет почти во все подсистемы ядра, и переносить в осн. ветку эти воздействия начали относительно недавно. А чем больше объем системы, тем больше в ней ошибок. На ядре 2.6.18, которое совсем не использовало LXC, иногда возникали очень печальные баги (вроде проседания сети в 1.5 раза) даже без запущенных контейнеров, просто после перезагрузки в OpenVZ-ядро. Сейчас, как я понимаю, должно стать лучше.
А XML это не минус, а плюс. Все равно при продаже VPS или облаков клиентам нужно писать им панель/биллинг, и тут перекидываться xml-ками с libvirt будет удобнее, чем текстом с vzctl.
Для диска OpenVZ сейчас предлагает использовать ploop, у которого накладные расходы сравнимы с дисковыми накладными расходами от xen/kvm+virtio, так как принцип работы тот же.
Пользовательский код выполняется что на kvm, что на openvz абсолютно одинаково без оверхеда (если не считать лишнего уровня косвенности при обращении к таблице страниц (но его почти убирает TLB) и возможных тонкостей с вытеснением нужной информации из кеша). Проблема остается только с системными вызовами, но тут у каждой из виртуализаций свои проблемы.
Но KVM проще и обеспечивает больший уровень изоляции.
Очевидно, что убийца совершил преступление, заколов врага ножом, но не меньше виноват и сам враг, который сделан из мяса и так легко протыкается ножом.
Видимо, RedHat не хочет заката бесплатного варианта своей ОС (о чем многие говорили несколько лет назад, когда разработчики ссорились, CentOS6 не выходил, а баги игнорировались), поэтому берет проект под свое крыло.
А разве то, что «надевили», не нужно собирать под CentOS?
Мог бы быть gcc-4.7, что очень полезно при разработке на c++11.
А можно кросплатформенно:
Но это изврат