Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
Записи с темой: стрекоза и муравей (список заголовков)
16:47 

Хроника свободного падения

"Первый звоночек" прозвенел еще на этапе установки DragonflyBSD - система отказалась грузиться с ACPI. В общем-то не особый криминал в случае ноутбука - кто его знает, что сумел понапихать производитель, но все же выводы сделать стоило. Впрочем, без acpi.ko система вполне резвенько загрузилась и установилась. Сырцы с деревом pkgsrc на вид встали тоже без проблем - cd /usr; make help; make src-create && make pkgsrc-create - сравните, что называется с процессом получения последней версии сырцов во FreeBSD (Создание sup-файла, ага) - вот только результат оказался м-мммм... инетересным. Полученная таким образом копия дерева относилась к ветке "development" и представляла собой "dayly snapshut" со всеми вытекающими.
Попытка задать CPUTYPE=p4 в make.conf (Значение бралось из ./defaults.make.conf) к успеху не привело - система наотрез отказалась воспринимать "p4", а все остальные значения "не подходят для х64" - нет, мне не трудно посмотреть man gcc и найти подходящее значение для CPUTYPE, н-но все же...
Далее, ядро отказалось собираться без включенного debug'а. Разобрать что ему, убогому, надо удалось попытки так с седьмой. Впрочем, результат вполне даже был - acpi заработал, а вот беспроводная сеть, mmc-картридер bluetooth и прочие радости "остались за кадром". Л-ладно. П-ппереживем, подумал я, приходя на работу.
Следующие грабли нашлись в самопоставленном же конторском proxy - по умолчанию bmake для извлечения исходников использует ftp, который м-ммм... на мой взгляд, не вполне адекватно работает с proxy. Пришлось едитить mk.conf и раскидывать переменные (HTTP|FTP)_PROXY_(AUTH). После замены ftp на fetch оно даже заработало, но сильно легче с того не стало. Не знаю, кто расставлял зависимости в Makefile'ах pkgsrc но с ориентацией у него явные не лады. Каким образом для ipython'а могут потребоваться zope, twisted, python 2.4 (В добавок к собственно, 2.6, ради которого все это и затевалось), gtk и QT (...!!!!) хоть убей, не понимаю. Единственный найденный мною "на коленке" способ все это конфигурять - ручное редактирование Makefile'а меня как-то... не вполне устраивает. Впрочем, в остальных пакетах ТАКИХ косяков вроде бы не было (Ага. 2/3 энторнетов поставились вместе с ipython'ом). Впрочем, вру - bison отказался работать с DBSD'шным sheduler'ом и, в общем-то, все.
Из крупных косяков - невозможность поставить ntfs-3g, ибо FUSE в DBSD отсутствует как класс. Окончательную точку в эксперименте поставил роняющий ядро модуль smbfs - что совсем уж "в никуда". Попытка завести его с kernel.GENERIC и modules.old к успеху так же не привела, и система была решительно послана в пешее эротическое.
"I'm back in USSR..." - в смысле, даешь FB8x64!

А самое во всем этом обидное - "на вид" HAMMER оказался даже пожалуй лучше, чем "по описаниям" - шустрый, стабильный (Во время экспериментов с acpi/smbfs система падала не раз и не два), с _реальной_ возможность работать со snapshut'ами в "живом" режиме (Revert to snapshut путем копирования его содержимого в нужное место... О май гад! :))... абыдна, вай!

@темы: Вендекапец!, Жизнь, стрекоза и муравей

16:29 

Итак, почему же именно...

... DragonflyBSD, что в ней такого интересного? На первый взгляд, ничего особенного - BSD она BSD и есть, а вот "унутре у нее неонка" :).
Про модель "легковесных нитей ядра" говорить не буду, ибо не разбираюсь. Об эмуляции системных вызовов с помощью модели портов-сообщений тоже промолчу. "На текущий момент" могу сказать, что по ощущениям на двух ядрах система шевелится чутка порезвее, нежели FreeBSD (Замерял на (кросс)компиляции ядра той же фрюхи).
Потенциальный перенос I/O в userland с распараллеливанием по нитям - штука куда более интересная, но все еще "перспективная", так что тоже в сторону, вместе с переписыванием VFS.
Несколько больший интерес представляют vkernel's - возможность "играться" с ядром системы, запущенным в userland'е без всяких перезагрузок и фатальных последствий в случае неудачи - но поскольку разработка-отладка-тестирование ядра ОС в сферу моих интересов не входит... :shuffle:

Так чего ради огород городить, спрашивается? Есть, есть чего! DragonflyBSD может похвастаться ну о-ооочень интересной файловой системой собственной разработки - HAMMER'ом. При всем обилии перспективных и не очень ;) файловых систем HAMMER вполне даже выделяется. В отличии от большинства своих "перспективных" собратьев HAMMER - потенциально кластерная ФС. В настоящее время от "кластерности" в ней (single-)master-multi-slave репликация (В том числе и сетевая, ага) и, в общем-то, все. Интересно, потенциально ОЧЕНЬ интересно - но для "букваря" не актуально от слова "совсем". А вот "живое" создание snapshut'ов с возможностью получить "живой" доступ к практически любой (Snapshut'ы постепенно удаляются через cron) "версии" ФС - просто фантастика, создание backup'ов путем зипования snapshut'ов - тоже оч-чень приятная вещь, возможность resize'ить ФС тоже не помешает, отсутствие лимитации по числу inode'ов (Ни разу не сталкивался, но сама возможность потенциально напрягала), практическое отсутствие ограничений по размеру (Как самой ФС, так и файлов) уже практически стандарт, мгновенное восстановление после сбоя (Snapsut'ы при каждом sync'е, помним?), CRC всего и вся - навскидку не хватает разве что поддержки ACL, но на букваре я это как-нибудь переживу.

Увы, не обойдется без ложки (Ведерка, если быть честным) дегтя - помимо стандартных BSD'шных косяков придется смириться с тем, что система "under active development" со всеми сопутствующими - то одно сломается, то другое недопочинится, но авось-небось-нихренась, переживем и эту беду.

@темы: Вендекапец!, стрекоза и муравей

Танец-с-саблями на граблях

главная