>> Взять, к примеру, задачу о 'light server partitioning': есть FreeBSD/Jail (технология,
>> которой много лет), есть Linux Containers (экспериментальная).
>> Они обе в общем-то довольно прилично работают, но в Линуксе вылезают странные
>> архитектурные проблемы, которых во FreeBSD почему-то нет: /dev в Jail'е работает
>> великолепно, в LXC отсутствует, как класс, ибо ядро не умеет вызывать
>> udev helper в пятнадцати виртуальных машинах. Нет, не то, чтобы это
> а зачем там udev? вы туда какие-то устройства подключаете?Да. Подключаю. Например, хочу в lxc-контейнере видеть подключенный FIPS-140 криптоключехранитель.
> и в lxc я могу вешать любые ip-адреса на интерфейс гостя без
> подпорок со стороны основной системы(как и могу запускать tcpdump, да и
> много чего ещё полезного делать).
1. В Jail'ах это тоже можно вполне себе делать, но при условии пуска vimage.
2. При чём тут tcpdump? Откройте в /etc/devfs.rules bpf в jail и хоть об'tcpdump'ьтесь.
>> СИЛЬНО мешало -- mknod никто не отменял -- но неприятно.
>> Во FreeBSD есть разделение файловых иерархий на базовую систему и пакеты =>
>> базовую систему можно смонтировать по nullfs в сотню jail'ов и атомарно
>> их патчить в случае проблем с безопасностью, просто перестроив мир в
>> базовой системе. В Линуксе так сделать по очевидным причинам не получится.
> и? mount -o bind чем не годится?
Тем, что во всех lxc'шках будет одинаковый набор программного обеспечения, что не всегда есть хорошо. Скажем, opal без хаков поддерживает _только_ unixODBC. virtuoso -- только iodbc.
Как на одной машине получить оба пакета, если операционная система -- Линукс, /usr смонтирован через -o bind, а unixODBC и iodbc конфликтуют?
>> И вот тут-то и вылезает overhead на системное администрирование: когда у вас
>> на сервере чуть больше, чем LAMP крутится, всё становится очень и
>> очень печально с Линуксом.
> как раз совсем наоборот. вы там про атомарный патчинг. в debian пакет
> обновить будет достаточно для той же задачи.
-o bind -- не вариант для Линукса, см. выше. Если без него -- пакет надо обновлять во всех lxc'шках. А их, скажем, триста.
>> В чём именно? В том, что в Asterisk'е бага, или в том,
>> что бажная версия попала по каналу security update?
>> В первом -- разработчики Asterisk'а, конечно.
>> Во втором -- Debian'щики. А кто? Владимир Путин, что ли? Дистростроители --
>> это что, роботы, тупо упаковывающие софт в пакеты, да?
> и? товарищи из proftpd закрыли багу в 1.2, переехав на 1.3.0-rc3.
> другое дело, что с астериском надо было бэкпортировать фикс.
Так виноват-то, в итоге, кто?-)
> не надо сказок. обычно это какое-то готовое решение, апдейты вы получаете от
> вендора.
> А tdm-мультиплексоры - это вообще законченные решения в коробке. софт так же
> апдейтится от вендора.
Угу. Скажите это в КБ "Кроникс", с их Tau PCI. В коробке, ёныть.
Да и время вендоров с готовыми решениями ушло в прошлое. Теперь разве что virtual appliances только можно...
Нет у меня электричества -- столько серверов питать!
> например: http://www.fastfom.com/sdh-multiplexer/37-sdh-multiplexer.html
SDH -- это не ВЕСЬ TDM мира.
>> А я имею такую возможность. У меня
>> есть USB-хабы с десятком однотипных USB-модемов. Вот если его включить в
>> машину с Линуксом... :))) Да ещё несколько раз "повтыкать-повытыкать"... :))) У
>> меня Debian v6 зависал "вхолодную", до reset'а. :)
> вы уж так и скажите: у нас тут десяток 3g-модемов и asterisk
> с chan_datacard.
Во-первых, с chan_dongle. Его давно переименовали.
Во-вторых, chan_dongle и TDM живут на разных Asterisk'ах в разных организациях.
В-третьих, падение Линукса это не отменяет. :)
