![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Вторая часть: http://nuclight.livejournal.com/128712.html
Тут же помещаю свой комментарий для памяти, вдруг не пройдет модерацию у![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
nuclight
IMHO вся проблема с монолитной базовой системой надумана. Мне не мешают ни sendmail, ни bind в базовой системе, при нынешних-то объёмах дисков. Поэтому я изложу те проблемы, которые на мой взгляд более серьёзны.
1. Обновление на следующий релиз.
В пределах одного major release утилиты freebsd-update, portsnap и portmaster обеспечивают беспроблемное, технологичное поддержание системы и софта в актуальном состоянии (в том числе и jail нормально бинарно обновляются снаружи через "freebsd-update -b"). Но поддержка security ветки имеет неприятное свойство кончаться, и вот тут начинается кошмар. "freebsd-update upgrade" разве уже пригоден к применению? Единственный рабочий способ обновления - через make world. После чего применимость freebsd-update к получившейся системе уже под вопросом, а "freebsd-update IDS" ломается полностью. Отдельный вопрос - mergemaster, IMHO он слишком сложен, скажем я не представляю, как по нему тех. карту расписать. Но это всё цветочки. Самое страшное - это то, что обновление мира влечёт пересборку всех портов и никаких гарантий, что после пересборки всё будет работать как работало. У меня на домашней системе был случай, когда после работы portmaster появились дубликаты в /var/db/pkg, пришлось сносить весь /usr/local и строить заново по заранее сохраненному `portmaster --list-origins`.
Можно конечно не делать "make delete-old" после пересборки мира, но тогда не стоило и систему обновлять вообще.
2. Виртуализация
Не хватает развитых средств виртуализации. В jail нет лимитов на CPU, память и прочее, нет и нормальной инфраструктуры создания/удаления джейлов (в качестве примера хорошей инфраструктуры см. Solaris zones)
Меня также напрягает, что из VMWare ESX нельзя послать на FreeBSD guest сигнал выключиться. Не знаю почему, и можем ли мы что-то с этим сделать.
3. cvsup поломали
Наверное в связи с переходом на SVN теперь все исходники cvsup-ятся только целиком, в результате вывод "csup -L0" оказался замусорен.
src/etc/Makefile,v: Checksum mismatch -- will transfer entire file
src/sys/kern/vfs_mount.c,v: Checksum mismatch -- will transfer entire file
src/usr.bin/catman/catman.c,v: Checksum mismatch -- will transfer entire file
Тут же помещаю свой комментарий для памяти, вдруг не пройдет модерацию у
nuclight IMHO вся проблема с монолитной базовой системой надумана. Мне не мешают ни sendmail, ни bind в базовой системе, при нынешних-то объёмах дисков. Поэтому я изложу те проблемы, которые на мой взгляд более серьёзны.
1. Обновление на следующий релиз.
В пределах одного major release утилиты freebsd-update, portsnap и portmaster обеспечивают беспроблемное, технологичное поддержание системы и софта в актуальном состоянии (в том числе и jail нормально бинарно обновляются снаружи через "freebsd-update -b"). Но поддержка security ветки имеет неприятное свойство кончаться, и вот тут начинается кошмар. "freebsd-update upgrade" разве уже пригоден к применению? Единственный рабочий способ обновления - через make world. После чего применимость freebsd-update к получившейся системе уже под вопросом, а "freebsd-update IDS" ломается полностью. Отдельный вопрос - mergemaster, IMHO он слишком сложен, скажем я не представляю, как по нему тех. карту расписать. Но это всё цветочки. Самое страшное - это то, что обновление мира влечёт пересборку всех портов и никаких гарантий, что после пересборки всё будет работать как работало. У меня на домашней системе был случай, когда после работы portmaster появились дубликаты в /var/db/pkg, пришлось сносить весь /usr/local и строить заново по заранее сохраненному `portmaster --list-origins`.
Можно конечно не делать "make delete-old" после пересборки мира, но тогда не стоило и систему обновлять вообще.
2. Виртуализация
Не хватает развитых средств виртуализации. В jail нет лимитов на CPU, память и прочее, нет и нормальной инфраструктуры создания/удаления джейлов (в качестве примера хорошей инфраструктуры см. Solaris zones)
Меня также напрягает, что из VMWare ESX нельзя послать на FreeBSD guest сигнал выключиться. Не знаю почему, и можем ли мы что-то с этим сделать.
3. cvsup поломали
Наверное в связи с переходом на SVN теперь все исходники cvsup-ятся только целиком, в результате вывод "csup -L0" оказался замусорен.
src/etc/Makefile,v: Checksum mismatch -- will transfer entire file
src/sys/kern/vfs_mount.c,v: Checksum mismatch -- will transfer entire file
src/usr.bin/catman/catman.c,v: Checksum mismatch -- will transfer entire file