Каковы проблемы FreeBSD и пути их решения? Часть 2: анализ и опрос
Продолжение предыдущего поста, рекомендуется прочитать из него хотя бы введение.
...Таким образом, имеется два утверждения (подробно рассматриваемые далее), причем оба истинные и друг другу не противоречат (по второму вопросу - высказывайте в комментах ваши взгляды на то, каковы еще проблемы FreeBSD и как их можно решить.):
Часть I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
Часть II. У FreeBSD действительно есть серьезные проблемы, или мы их решаем, или нам каюк.
Для начала. Год назад на http://www.opennet.ru/openforum/vsluhforumID3/69204.html#76 было высказано такое мнение:
Лично я считаю, что в последнее время Linux как ядро переживает стагнацию - качественного развития как такового нет, есть только постоянно добавляемая поддержка нового оборудования. Основной фронт разработки переместился с ядра на разработку Gallium, различных велосипедных файловых систем, систем интеграции в ядро видеоподсистемы и системы виртуализации.
В то же время во FreeBSD концентрировались на разработке перспективных идей, вроде GEOM, NetGraph, да время от времени переписывали различные подсистемы с нуля, да дописывали недостающие функции правильным образом. В результате я уже вижу, как FreeBSD уже вот-вот догонит Linux по фичам за счёт хорошего задела в архитектурном плане. Единственное почему FreeBSD не сможет существенно потеснить Linux - это наплевательское отношение к пакетам, устаревшая система портов, меньший охват в поддержке оборудования. А так базовая система - конфетка, по многим показателям уже опережает Linux.
[...]
Я перечислил вроде бы мелкие проблемы, которые пользователям FreeBSD изнутри не видны, а вот снаружи видны очень хорошо. (Как известно, в чужом глазу соринку найдёшь, а у себя и бревна не заметишь.) Именно эти небольшие проблемы скорее всего и приводят по принципу Паретто к потере существенной части аудитории пользователей.
Добавим к выделенному жирным цитировавшееся ранее из поста про Рампочту (где по пунктам было) насчет ввести ветки портов, разбить базу на пакеты, отказаться от компиляции... Я уже вижу тысячи несогласных и готовых спорить BSD-шников. Ан нет, ребята: чтобы решить проблему, для начала следует признать её наличие. Но чтобы решить проблему, следует серьезно изменить ряд вещей во FreeBSD. А ваши споры и несогласие на что направлены? На то, чтобы оставить всё как есть и не изменяться.
Социальные (и психологические) проблемы FreeBSD.
К чему приводит наше поведение, которое неизменно всё то же долгие годы? К тому, что Линукс, всего десять лет назад совершенно не годившийся для продакшена, нас не просто обогнал, а начинает вытеснять. Если дело так пойдет и дальше, FreeBSD через 3-5 лет действительно вымрет - то есть займет такую же маргинальную нишу, как и NetBSD/OpenBSD. В настоящее время https://ssl.netcraft.com/ssl-sample-report//CMatch/oscnt_all еще пока показывает, что серверов под FreeBSD около 3% (у собратьев *BSD - сотые доли). Сейчас Яндекс собирается свой поисковый кластер переводить с FreeBSD на Linux - это более 30000 машин. Они еще колеблются, но если это произойдет, что будет потом? Такое может стать сигналом для всех остальных, и если мы ничего не предпримем, доля FreeBSD начнет резко падать.
"Ну и что", - скажешь ты, рядовой FreeBSD'шник, - "у меня фря стояла и будет стоять, какое лично мне дело до рыночной доли?". В том-то и дело, что очень даже большое - чем меньше доля, тем меньше производителей софта и железа её поддерживают, размер сообщества сокращается, что-то допиливать и портировать своими силами оно сможет всё меньше. За это время индустрия и потребности пользователей уходят вперед, возникают новые задачи, а система их решить не в состоянии. А когда система не в состоянии решить задачу, её выкидывают и заменяют на другую. В итоге становится почти невозможно найти работу, которая была бы связана с данной системой. Весёленькая перспектива? Вот и мне не нравится.
С чем всё это связано? Кроме технических факторов, есть еще социальный: Linux банально у всех на слуху. И вот, из сотни студентов, услышавших в общаге про линукс и попробовавших, десять вырастают в "где-то в чем-то", но хоть как-то пригодных администраторов. А сколько из них слышало про фрю? Хорошо, если один-два, а то ведь и вообще никто. Как так получается? Всё дело в том (и тут вы все со мной сейчас радостно согласитесь и возвопите "агаа!"), что нам (фре) не нужны безмозглые хомячки-убунтоиды. И бывалые фряшники ужасаются низкому качеству статей на http://www.lissyara.su и ругают его, хотя это сейчас единственный ресурс, выполняющий функции пропаганды "в общагах" (на безрыбье и он для FreeBSD сейчас весьма полезен). А нужны нам, дескать, грамотные, технически пользователи. Которые бы нам еще и патчи слали. Так ведь?
А вот фиг. Проблема в том, что грамотный пользователь не есть фанат. Посмотрим, что пишет технически грамотный пользователь:
Технические аргументы: объективно более высокая сложность поддержки, отсталость пакетного менеджера, отсутствие нормальных средств разработки, отладки и деплоймента. Отсутствие поддержки вендоров оборудования.
Что здесь видно (кроме разработки/отладки, про которые автора поправили)? Да то же самое, что и в исходной цитате с Opennet. А что такое "более высокая сложность поддержки" ? Это значит, что для тех же самых действий админу нужно затратить больше усилий, требуется больше времени. Мы так не считаем? Мы просто привыкли. А вот человеку со стороны хорошо заметно. У него другие потребности. А мы на эти потребности, потребности пользователей - плюем. Еще раз, грамотный пользователь не есть фанат. Фанат может себе позволить потратить несколько часов на пересборку мира, кому-то другому это будет, скорее всего, неприемлемо. При этом, разве эти проблемы невозможно исправить? Было бы желание. Даже враги FreeBSD признают, что нерешаемых технических проблем у нас нет:
- Проблема теперь в том, что в 2011-м никому не нужны ни чистота, ни строгость. Кастомерам нужны прозрачность и скорость реакции на их запросы. Если нет прозрачности и скорости, получается CentOS 6 (которая на днях таки вышла, слава России). Ну, или FreeBSD (Gentoo, Solaris, you name it)."
- слова правильные, непонятно где фря это нарушает и где провинилась.
- Не футболки надо продавать, а брендированные железяки, как Nexenta.
- но я твою мысль понял -- больше агресивного маркетинга? что проблемы не технически-архитектурного плана, а маркетингово-позиционного?
Тот же Андрей Богородский замечает утрату позиций FreeBSD в телекомах по тем же причинам не-технического характера:
причём, смею заметить, не по технологическим преимуществам, а исключительно по признаку наличия доступного саппорта - телеком укрупнился, окорпоративелся и стал чувствителен к контрактам на саппорт. Линукс таковые, - кривые, косые, липовые, - имел, а Фря... а кто это? зачем это?
А чтобы такие фирмы, оказывающие услуги суппорта, могли появиться, система опять же должна иметь уровень популярности не ниже некоторого определенного. И обеспечить его можем только мы, сообщество. Как? Да не отталкивать от себя грамотных пользователей, прежде всего. А еще точнее - определить, для кого всё-таки предназначена система. В архивах arch@ двухлетней давности я читал такой диалог:
> Personally I'd like to think that that we write an OS for users.
We write an OS for the people who can and will use an OS written by us.
О ком здесь говорит коммиттер? Фактически, по тому же принципу Парето, он говорит, что 80% пользователей системы суть фанаты, которые будут использовать OS written by us несмотря ни на что, и 20% забредших грамотных пользователей, которые могут использовать системы и сделают это по каким-то их специфическим задачам, которые в данный момент не могут быть удовлетворены другими ОС.
Я считаю, что наоборот, система может стать настолько лучше, чтобы доля фанатов, развивающих систему, составляла всего 20%, остальные же - были грамотные пользователи, использующие систему из-за объективных преимуществ. А если доля пользователей FreeBSD возрастет таким образом в 4-5 раз, то, при доле серверов не в 3%, а в 15% вполне реальна поддержка корпораций и прочие радости жизни.
"Какая еще нафиг ненужная поддержка корпораций, и зачем нам эти иждивенцы в количестве 80%, которые ничего не отдают системе патчами?", - спросит среднестатистический фревый фанат-контрибутор? А всё просто. Существуют задачи, и их очень много, которые не могут быть решены патчами одного человека. Нужны целые их коллективы. В конце концов, коммиттеры FreeBSD - тоже коллектив. В одиночку не получится сделать и разнообразные архитектурные изменения - такое всегда требует обсуждений в списках рассылки. Отвечать на подобное "patches are welcome" - просто повод ничего не сделать. Посмотрите на Linux. Туда "присылают патчи" те же корпорации, большие коллективы. У нас это тоже есть, но в гораздо меньших объемах. А мы плачемся, что тратим кучу усилий на портирование Файрфокса, Хрома и других. А ведь коллективы их разработчиков, которые не корпорации, могли бы портировать их для нас сами. Не тратя наших усилий. Разве не этого мы хотим, когда говорим "where are your patches?" ?.. Как этого добиться? Очень просто - повысить популярность системы (что особенно актуально в свете выживания, когда некоторые из них уже начали призывать писать непортируемый код). Всего лишь какое-то время работать на перспективу - да, просто для тех, кто пользуется и ничего не присылает в ответ. Через какое-то время это даст свой эффект, на сотню юзеров найдется и один разработчик, а потом нас начнут замечать уже просто из-за достаточной доли. И патчи потекут от тех, кто может.
Да, так не получится сделать сразу - на рисунке справа изображена так называемая кривая Гартнера (hype curve), и мы сейчас, по-видимому, находимся где-то на её вершине, за которой неминуемо последует спад. Наша задача - приложить сейчас такие усилия, работая на будущее, чтобы этот спад затем перешел в подъем, причем перешел уже в схему Performance S-curve, обеспечив уровень больший, чем есть сейчас.
Что нам мешает это сделать, и какие схожие примеры можно найти в новейшей истории? Десять лет назад в России начался стремительный спад числа членов сети Фидо. В истории о социальных причинах этого и комментариях к ней можно прочитать, что автор тех строк еще в 1998 году выступал против "реформаторов", требовавших, например, отмены ZMH, "священной коровы" тогдашней сети. Автор сетует, что тогда никто ему не объяснил, что это уже была всего лишь традиция, более не отражающая изменившихся технических требований. Как можно видеть по графикам, всего через 3 года после первых дебатов по этой теме случился резкий перелом, число узлов стремительно пошло вниз. Всё, сейчас сеть практически мертва.
У нас нет трех лет роста, лишь только после которого случится падение, но нет и (как мы убедились выше) ужасающего технического отставания, каковое сложилось у Фидо в момент перелома. Мы еще имеем шанс и можем не повторить их ошибок. В чем же они заключались? Если коротко, то социальные и психологические причины воспрепятствовали технической модернизации. Если были бы приняты нужные решения, то технические решения стали бы уже делом техники, пардон за каламбур. Посему я и веду речь прежде всего о социально-психологических причинах, к техническим перейдем позже.
Не помнящие ошибок прошлого обречены повторять его.
- Джордж СантаянаИтак, у населения Фидо наблюдались излишняя жесткость, упертость и консерватизм. Да, сейчас мне тут же начнут возражать перечнем тех плюсов, которые фре приносит консерватизм. Вот только есть разница между понятиями "консерватизм" и "здоровый консерватизм", "строгость" и "жесткость (негибкость)", "упертость" и "принципиальность". Действительно ли то, чем вы хотите возражать против дальнейшего, обусловлено актуальными причинами, или вы предпочитаете действовать так по привычке? Действительно ли возражение имеет технические обоснования, или это просто традиция? Как мы увидим дальше, вполне возможно делать изменения, не нарушающие строгости и т.п., но которые могут противоречить упертости. Как отличить одно от другого? Один критерий я уже приводил: когда возражения направлены на то, чтобы в итоге ничего не менять и не делать. Другой - это посмотреть, действительно ли ваши технические возражения применимы более, чем в небольшом числе случаев. Если окажется, что вы возражаете против нарушения привычки ("мне так удобно") или аргументируете сугубо частным случаем ("в -надцатом году мне это помогло") - поздравляю, Вы в плену привычек, которые приносят вред FreeBSD. Посмотрите шире, чем Ваш уютный мирок.
Психология подсказывает нам, что жесткость и лишний консерватизм проявляются (и вредят!) сразу в нескольких местах. В том же Фидо это выражалось не только в сопротивлении техническим новшествам, но и в драконовских правилах и произволе в некоторых других местах (подробнее см. по ссылкам выше). В результате многие люди уходили из Фидо даже после того, как их туда заагитировали, просто потому, что разочаровались - от них требовали больше, чем они получали (четко прослеживается аналогия с "where are your patches?", не правда ли?). В сообществе FreeBSD существуют аналогичные явления. Вспоминая пример со студентами в общагах, какой смысл пропагандировать FreeBSD, если приходящие грамотные люди тут же "получат по шапке" от сообщества? Зачем человеку тут быть и тем более присылать свои патчи, если его даже не хотят для начала просто выслушать?.. Не так давно я лично наблюдал случай: человек задал вопрос вполне внятно, в соответствии с "Как правильно задавать вопросы", привел всю нужную информацию, просто в небольшом несоответствии с тем, как вопросы было принято оформлять здесь (#freebsd@RusNet). Тут же получил "от ворот поворот" от одного из операторов, мол, я так оформленное даже читать не буду, соблюдай наши правила.
Ну и кому от этого стало лучше? Стало ли от этого лучше FreeBSD? Человек просто "проголосует ногами" и будет всем рассказывать про "неадекватное сообщество". Понятно, откуда такое требование изначально возникло - новички часто не в состоянии грамотно сформулировать вопрос. Однако необходима гибкость для оценки, когда этот формализм помогает, а когда вредит. Задумайтесь, а как бы в таком случае поступили члены core team? Они в списках рассылки вполне вежливо на всякие разные вопросы отвечают...
Собственно, а что вам (нам всем) мешает просто признать свои ошибки и измениться? Гордость (а точнее гордыня aka ЧСВ)? Что, типа, линуксовые тролли на форумах взвоют, ага, они с нами наконец-то соглашаются? Обиды? Дескать, мы щас начнем делать как у них там в линуксе и фря будет уже не та, потеряет отличия?.. Да ничего подобного! Тролли отличаются тем, что никакой реальной помощи от них нам не дождаться. Послушать их "предложения" и сделать точно так же, как в линуксе? Фигу, мы сохраним свою уникальность. Более того, иметь мужество признать свои ошибки и исправить их, своим собственным способом - более трудно и более почетно, чем красноглазо выкрикивать, плетясь в мэйнстриме. Кто надеется пройти только через победы - не дойдет. Нужно быть готовым пройти и через грязь, и через поражения, и через позор, но - дойти.
Технические проблемы FreeBSD и предложения по ним.
Итак, две основные проблемы FreeBSD, на которые указывает большинство внешних наблюдателей - это пакетный менеджер и базовая система. Две тесно связанные друг с другом проблемы. Конечно, у FreeBSD хватает и других технических проблем, например, с теми же файрволами, но о них - в другой раз. Сейчас сосредоточимся на самом важном, на том, что по принципу Парето, от 20% усилий решит 80% наших проблем (и, при соблюдении социальной части, даст 80% юзеров).
source-based linux distro невозможен, ибо у них нет базовой системы
без отдельной БС оно превращается в кашу легким движением руки
возможен, если там сделают БС и будут её поддерживать именно как БС
ну все дистры так и делают, только не говорят, что у них есть БС
Jay, но это проблема не только source-based, но и бинарных
Jay, ну, в смысле, чтобы был атомарный апгрейд БС
ну да, иначе первый же апгрейд glibc разрушит цивилизацию
так что, те, кто говорит, что в линуксе нет БС и это хорошо - врут :)
в любом живом дистре она есть, только про нее юзеры не знаютМонолитная базовая система, которую оппоненты предлагают поделить на тысячу маленьких пакетов "как в Линуксе". То есть, по сути убрать такое разделение, как "база" и "пакеты". Единственное ли это решение? Нет, конечно. Обратимся ко всем другим ОС, кроме Linux, и обнаружим, что понятие базовой системы, а не только ядра, существует везде. Даже в Windows (отдельно компоненты системы, отдельно приложения).
Но как именно она в них сделана? Посмотрим, скажем, на Solaris. Там имеется несколько довольно крупных, но пакетов, из которых и состоит базовая система. В этом смысле солярка похожа на фрю - во фре при инсталляции тоже можно выбрать distributions. И, как и во фре, они крупные и по умолчанию ставятся не по отдельности, а наборами. Пакетный менеджер в солярке, правда, ужасающ, всё еще хуже чем во фре. Для полноты картины солярка была упомянута, всё, теперь о солярке можно забыть.
На самом деле, монолитность базы - достоинство. В начале года в Фидо _slw подробно - см. http://groups.google.com/group/fido7.ru.unix.bsd/msg/b2e9414abbbe17eb - расписал плюсы и минусы единой базовой системы и системы, разбитой на пакеты. Про минусы (не только базы, но и пакетов) уже много кто объяснял подробно, поэтому я их просто перечислю, чтоб были под рукой:
Гораздо более интересно, однако, помнить о тех плюсах, которые предоставляет концепция базовой системы. Их мало, но они большие:
Итак, нам говорят, что концепция базовой системы не подразумевает полноценной работы с пакетами, и потому надо отказаться от базовой системы нафиг, разбив её всю целиком на пакеты. Что мы тут имеем? Два разных подхода, "база" vs "всё пакетами", которые вроде бы исключают друг друга, по крайней мере, в текущей реализации каждого. Постановка вопроса подразумевает, что какой-то один из подходов безусловно лучше, хотя разве такое возможно при наличии минусов у обоих?.. На самом же деле, нужен новый третий подход, отличающийся от предыдущих двух и гармонично объединяющий плюсы тех двух. И разработка такого подхода - весьма интересная и творческая инженерная (даже изобретательская) задача.
Собственно, *BSD-системы всегда отличались склонностью именно к таким решениям. Присмотреться к аналогам, учесть ошибки и выпустить пусть с опозданием, но нечто такое новое, что будет пригодно и не устареет еще длительный срок, не требуя кардинальных переделок уже через год. Так, например, в NetBSD в свое время попытались разделить базовую систему на пакеты. Естественно, эта идея заглохла, потому что ничего существенно нового и изменяющего подходы так, чтоб плюсы и старого учитывались, она не принесла.
Итак, попытаемся (все вместе) решить эту задачу. Есть основания полагать, что она не потребует переписывания всего с нуля, а позволит обойтись не столь уж большими усилиями. Тем более, что есть одно важное условие: проект FreeBSD весьма ограничен в ресурсах. Здесь имеется в виду время разработчиков и усилия других помогающих проекту. Это в Linux вкладывают миллиарды баксов, у нас такого нет.
Опции сборки. В Makefile'ах портов бывает можно видеть строки, подобные:
.if ${OSVERSION} < 700104 || ${OSVERSION} >= 900000
...что означает проверку на версию базовой системы. Далее, в ядре с некоторых пор активно внедряется макрос FEATURE(), информация из всех применений которого собирается и экспортируется через sysctl для приложений, желающих проверять доступность той или иной возможности. Естественным образом эту идею можно обобщить и на саму базовую систему, на её компоненты - проверку этих опций и записывать в пакеты. Точно так же можно вписывать в пакеты и их собственные опции сборки, вынеся их и версию из имени пакета.
В случае решения "малой кровью" - можно обойтись изменением формата имени и строчки @pkgdep в +CONTENTS на содержащую только имя, диапазон версий, и требуемые значения опций в зависимостях. В случае более серьезного решения, возможно, необходимо будет приделывать к pkg_* функции, аналогичные проверкам переменных в портах. То есть, например, прописывать зависимость не от пакета, а как в портах:
LIB_DEPENDS+= profiler.1:${PORTSDIR}/devel/google-perftools
С учетом пожеланий того, чтобы бинарные пакеты стали равноправны с портами - вполне возможно, что потребуется сделать и так. Я уже не говорю о таких само собой разумеющихся вещах, как возможность обновления/замены штатными утилитами, и т.д.
Гораздо более интересен вопрос существования базовой системы. Основной аргумент, чтобы разбить её на множество мелких пакетов - это "теперь отдельные компоненты можно будет легко обновлять" и "можно не ставить ненужное". Но что такое отдельные пакеты по своей сути? Это независимые друг от друга компоненты. То есть, чтобы разбить монолитную систему на отдельные независимые модули, нужно затратить усилия на изоляцию их друг от друга и затем постоянно тратить усилия на поддержание их независимости друг от друга. Однако для цели release engineering разработчики постоянно тратят усилия на согласование всех компонентов между собой. Две во многом противоположные задачи. Чтобы догнать обоих зайцев, нужно затратить усилий не в 2, а в более чем 2 раза больше. А ресурсов у FreeBSD, как мы помним, мало. Что делать?
Противоречие снимается, если провести границы между компонентами иначе. Здесь важно прежде всего административное деление - в чьей зоне ответственности находится тот или иной компонент, кто его vendor. В самом деле, зачем разработчикам FreeBSD огораживаться самим от себя? И в то же время, чем постоянно аргументируют сторонники разделения базы на пакеты? BIND, Sendmail, GCC. А ведь это всё - то, что производится не на @freebsd.org. Что самое здесь хорошее, так это то, что разработчики FreeBSD уже прилагают некоторые усилия к поддержанию границ между софтом различных вендоров (просто незаметные пользователю). Дополнительные затраты усилий - минимальны сравнительно с другими вариантами. И некоторые разработчики, например Doug Barton (майнтейнер BIND, который всё мечтает выкинуть его из системы), тоже считают, что между текущим состоянием базы и "всё пакетами" должен быть некий промежуточный вариант.
Сделаем du -hd 1 /usr/src/ и увидим, что вся система занимает порядка 500 Мб, а /usr/src/contrib - порядка 250 Мб, то есть около 50%. Сделаем то же самое с самим contrib-софтом и увидим, что около половины его занимает GCC и его утилиты (кстати, исходники ядра занимают примерно половину того, что не contrib, т.е. систему можно условно поделить на четыре примерно равные части).
То есть, уже вырисовываются некоторые наметки: оставить в единой монолитной базе только то, что делают коммиттеры @freebsd.org, и выделить несколько десятков пакетов. Здесь, правда, возникает проблема: это условие, как в математике, необходимо, но не достаточно. Такая база не сможет жить самостоятельно, в contrib лежат, в частности, библиотеки, используемые остальной системой.
Хорошо, изменим критерий, пусть он будет звучать как: базовая система есть то ПО, чей эффективный вендор есть *@*bsd.org (в сии трудные времена BSD-системам лучше объединяться и выживать вместе, да и всё равно обмен кодом всегда шел между братскими версиями более интенсивно). Здесь "эффективный" значит, например, что или вендор был, но давно сдох, и компонент поддерживается коммиттерами (как в случае traceroute), или компонент втащен в систему под другим именем и навряд ли будет обновляться из апстрима (как expat -> libbsdxml). Уже лучше, в системе останется "из коробки" жить, например, openssh, правда, всё равно возникает проблема еще с рядом пакетов, например, openssl (используемый средствами обновления и проверки целостности системы). Такая база даже пересобрать сама себя не сможет без компилятора, например. И опять же, сетевая ОС да без tcpdump?!.. Критерий вроде хорош, но к нему уже приходится придумывать исключения...
Тут вопрос в том, что традиционно база определялась иначе. В базе было всё, потому что делали под себя ("will use an OS written by us"). Это был набор софта, удобный определенной группе людей. Сейчас нам необходимо сделать систему для более широкого круга юзеров. И всё упрется в то, как именно в точности определить эту группу, нашу целевую аудиторию. Достаточно достоверно прямо сейчас можно сказать лишь про то, о чем часто бывают крики, то есть, что нашей целевой аудитории не нравится.
Вот, например, почта. Большинство наших пользователей уже сейчас либо сносят Sendmail и ставят себе другой MTA, либо оставляют настроенный из коробки Sendmail для достаточно узко очерченных целей. Каких? Зачем вообще в базе почтовик? Для двух целей:
1) Складировать поступающую почту periodic-скриптов и других cron-заданий в локальные mailbox'ы либо отправлять её на нужный адрес
2) Позволить отправить почту с машины любым другим системным скриптам (например send-pr) или пользователю.
С обеими задачами прекрасно справится разработанный в DragonflyBSD именно для этих конкретных целей маленький агент dma. Его можно втащить в базу, он удовлетворяет критерию "вендор *@*bsd.org", и выкинуть из неё Sendmail. Кому нужен полноценный MTA, легко поставит из пакетов что угодно. А чтобы не нарушать POLA для тех, кто привык, достаточно поставлять вместе с базовой системой пакеты и держать соответствующие галочки отмеченными по умолчанию.
Обратите внимание, что здесь основные принципы FreeBSD вовсе не будут нарушены, а даже будут подчеркнуты. Чистота, строгость, минимальность: лишнего в базе нет, нужен почтовик - ставьте на выбор, не ограничивают. Есть налаженный техпроцесс со старой системой - пожалста, вот вам галки по умолчанию. А как насчет GCC, кощунство? Как так, база не сможет пересобрать сама себя? На самом деле нет, уже сейчас make release требует для своей работы кроме базовой системы еще ряда портов. Так же и для возможности пересборки. Просто опять же, класть их на инсталляционный диск рядом. А с учетом грядущей перспективы перехода на Clang отделение компилятора от базы и возможность использования с ней любого из двух компиляторов на выбор - это хорошо.
Таким образом, критерий "что именно оставить в базе" должен определяться целевой аудиторией и задачей, которую предстоит уточнить. Допустим, это будет "способный к работе после установки сервер, на который должно быть можно поставить из сети пакеты". Такая задача потребует некий необходимый минимум, например, редактор (vi) необходим для настройки сети - тех же rc.conf, resolv.conf. Для настройки сети может потребоваться чтение манов - нужен $PAGER (more, который у нас less). Пакеты надо распаковать, значит нужны архиваторы, проверить чексуммы, то есть требуются утилиты для их сверки (кстати, пригодится и для еще нормально не реализованной задачи сверки целостности базы - freebsd-update пока обрабатывает мало случаев).
Что у нас еще есть из проблем тех пользователей, на которых стоит ориентироваться? Допустим, база "похудеет" на треть. Она станет проще в поддержке для Security officer и других коммиттеров и может развиваться несколько быстрее. Станет возможным удлинить релиз-цикл на один minor-релиз. Зачем это? Затем, что уже несколько major-веток складывается такая ситуация, что релизы выходят чаще, STABLE для наших консервативных пользователей стабилизируется только к версии X.2. Но как раз следом выходит версия (X+1).0 и далее релизы X.3, X.4 уже почти не развиваются как таковые. Версия X.4 становится последней, потом новых релизов больше нет. При этом какое-то время существуют сразу ДВЕ ветки STABLE, сейчас, например, 7.x и 8.x. В итоге многие пользователи мигрируют сразу через одну ветку (с 6.x на 8.x) - ну и для кого другая, спрашивается, делалась и поддерживалась?..
Стандартное возражение разработчиков - плавали с этим во времена 4.11, наелись, куча проблем была. Да елки-палки, что вас в крайности-то бросает? То .0 каждые 2 года, то 5 лет без нового major. Оба варианта плохие, есть золотая середина. К тому же не придется поддерживать сразу два STABLE, вот экономия ресурсов. Особенно если базу облегчить... В конце концов, та стабильность - одна из выгодных отличительных черт FreeBSD, один из принципов. Поступаться им ради скорости выпуска нового major - значит терять конкурентное преимущество. Почему бы не поискать другие способы решения тех проблем, для которых был задуман короткий релиз-цикл?.. Да-да, снова поискать гармоничное решение с плюсами, незачем копировать у Ubuntu и Firefox порочную тактику time-based релизов и гонки за версиями...
И напоминаю, огромное значение имеют и социальные причины. Технические изменения следует проводить в жизнь вместе с ними, одновременно. И если Вы с чем-то категорически, решительно не согласны - это признак того, что несогласие скорее всего не имеет под собой реальных весомых аргументов, а лишь эмоции. Мы не в том положении сейчас, чтобы тешить свое ЧСВ тогда, когда это ставит под угрозу будущее проекта. А сиюминутный рост в каких-то областях не означает, что всё хорошо в целом и будет так и дальше продолжаться. Еще раз, давайте думать, как нам измениться, а не чем обосновать "не надо ничего делать". А к "мы ничего не будем делать" относится, разумеется, и отмазка вида "patches are welcome". Организационные проблемы патчами не решаются, увы. Перечитайте выше подраздел социальных проблем.
На том пока всё на момент публикации. Высказывайте Ваши взгляды на проблемы и способы их решения в комментах, я буду дописывать их ниже. Потом из всего этого будут собраны рекомендации, с которыми пойдем в arch@freebsd.org пропихивать уже официально.
Nota Bene: В комментах принимаются только конструктивные предложения. Троллинг, холивары и т.п. вредное будет нещадно тереться. Срите в предыдущем посте.
---8<----8<--- линия отреза ---8<----8<---
...Таким образом, имеется два утверждения (подробно рассматриваемые далее), причем оба истинные и друг другу не противоречат (по второму вопросу - высказывайте в комментах ваши взгляды на то, каковы еще проблемы FreeBSD и как их можно решить.):
Часть I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
Часть II. У FreeBSD действительно есть серьезные проблемы, или мы их решаем, или нам каюк.
Для начала. Год назад на http://www.opennet.ru/openforum/vsluhforumID3/69204.html#76 было высказано такое мнение:
Лично я считаю, что в последнее время Linux как ядро переживает стагнацию - качественного развития как такового нет, есть только постоянно добавляемая поддержка нового оборудования. Основной фронт разработки переместился с ядра на разработку Gallium, различных велосипедных файловых систем, систем интеграции в ядро видеоподсистемы и системы виртуализации.
В то же время во FreeBSD концентрировались на разработке перспективных идей, вроде GEOM, NetGraph, да время от времени переписывали различные подсистемы с нуля, да дописывали недостающие функции правильным образом. В результате я уже вижу, как FreeBSD уже вот-вот догонит Linux по фичам за счёт хорошего задела в архитектурном плане. Единственное почему FreeBSD не сможет существенно потеснить Linux - это наплевательское отношение к пакетам, устаревшая система портов, меньший охват в поддержке оборудования. А так базовая система - конфетка, по многим показателям уже опережает Linux.
[...]
Я перечислил вроде бы мелкие проблемы, которые пользователям FreeBSD изнутри не видны, а вот снаружи видны очень хорошо. (Как известно, в чужом глазу соринку найдёшь, а у себя и бревна не заметишь.) Именно эти небольшие проблемы скорее всего и приводят по принципу Паретто к потере существенной части аудитории пользователей.
Добавим к выделенному жирным цитировавшееся ранее из поста про Рампочту (где по пунктам было) насчет ввести ветки портов, разбить базу на пакеты, отказаться от компиляции... Я уже вижу тысячи несогласных и готовых спорить BSD-шников. Ан нет, ребята: чтобы решить проблему, для начала следует признать её наличие. Но чтобы решить проблему, следует серьезно изменить ряд вещей во FreeBSD. А ваши споры и несогласие на что направлены? На то, чтобы оставить всё как есть и не изменяться.
Социальные (и психологические) проблемы FreeBSD.
К чему приводит наше поведение, которое неизменно всё то же долгие годы? К тому, что Линукс, всего десять лет назад совершенно не годившийся для продакшена, нас не просто обогнал, а начинает вытеснять. Если дело так пойдет и дальше, FreeBSD через 3-5 лет действительно вымрет - то есть займет такую же маргинальную нишу, как и NetBSD/OpenBSD. В настоящее время https://ssl.netcraft.com/ssl-sample-report//CMatch/oscnt_all еще пока показывает, что серверов под FreeBSD около 3% (у собратьев *BSD - сотые доли). Сейчас Яндекс собирается свой поисковый кластер переводить с FreeBSD на Linux - это более 30000 машин. Они еще колеблются, но если это произойдет, что будет потом? Такое может стать сигналом для всех остальных, и если мы ничего не предпримем, доля FreeBSD начнет резко падать.
"Ну и что", - скажешь ты, рядовой FreeBSD'шник, - "у меня фря стояла и будет стоять, какое лично мне дело до рыночной доли?". В том-то и дело, что очень даже большое - чем меньше доля, тем меньше производителей софта и железа её поддерживают, размер сообщества сокращается, что-то допиливать и портировать своими силами оно сможет всё меньше. За это время индустрия и потребности пользователей уходят вперед, возникают новые задачи, а система их решить не в состоянии. А когда система не в состоянии решить задачу, её выкидывают и заменяют на другую. В итоге становится почти невозможно найти работу, которая была бы связана с данной системой. Весёленькая перспектива? Вот и мне не нравится.
С чем всё это связано? Кроме технических факторов, есть еще социальный: Linux банально у всех на слуху. И вот, из сотни студентов, услышавших в общаге про линукс и попробовавших, десять вырастают в "где-то в чем-то", но хоть как-то пригодных администраторов. А сколько из них слышало про фрю? Хорошо, если один-два, а то ведь и вообще никто. Как так получается? Всё дело в том (и тут вы все со мной сейчас радостно согласитесь и возвопите "агаа!"), что нам (фре) не нужны безмозглые хомячки-убунтоиды. И бывалые фряшники ужасаются низкому качеству статей на http://www.lissyara.su и ругают его, хотя это сейчас единственный ресурс, выполняющий функции пропаганды "в общагах" (на безрыбье и он для FreeBSD сейчас весьма полезен). А нужны нам, дескать, грамотные, технически пользователи. Которые бы нам еще и патчи слали. Так ведь?
А вот фиг. Проблема в том, что грамотный пользователь не есть фанат. Посмотрим, что пишет технически грамотный пользователь:
Технические аргументы: объективно более высокая сложность поддержки, отсталость пакетного менеджера, отсутствие нормальных средств разработки, отладки и деплоймента. Отсутствие поддержки вендоров оборудования.
Что здесь видно (кроме разработки/отладки, про которые автора поправили)? Да то же самое, что и в исходной цитате с Opennet. А что такое "более высокая сложность поддержки" ? Это значит, что для тех же самых действий админу нужно затратить больше усилий, требуется больше времени. Мы так не считаем? Мы просто привыкли. А вот человеку со стороны хорошо заметно. У него другие потребности. А мы на эти потребности, потребности пользователей - плюем. Еще раз, грамотный пользователь не есть фанат. Фанат может себе позволить потратить несколько часов на пересборку мира, кому-то другому это будет, скорее всего, неприемлемо. При этом, разве эти проблемы невозможно исправить? Было бы желание. Даже враги FreeBSD признают, что нерешаемых технических проблем у нас нет:
- Проблема теперь в том, что в 2011-м никому не нужны ни чистота, ни строгость. Кастомерам нужны прозрачность и скорость реакции на их запросы. Если нет прозрачности и скорости, получается CentOS 6 (которая на днях таки вышла, слава России). Ну, или FreeBSD (Gentoo, Solaris, you name it)."
- слова правильные, непонятно где фря это нарушает и где провинилась.
- Не футболки надо продавать, а брендированные железяки, как Nexenta.
- но я твою мысль понял -- больше агресивного маркетинга? что проблемы не технически-архитектурного плана, а маркетингово-позиционного?
Тот же Андрей Богородский замечает утрату позиций FreeBSD в телекомах по тем же причинам не-технического характера:
причём, смею заметить, не по технологическим преимуществам, а исключительно по признаку наличия доступного саппорта - телеком укрупнился, окорпоративелся и стал чувствителен к контрактам на саппорт. Линукс таковые, - кривые, косые, липовые, - имел, а Фря... а кто это? зачем это?
А чтобы такие фирмы, оказывающие услуги суппорта, могли появиться, система опять же должна иметь уровень популярности не ниже некоторого определенного. И обеспечить его можем только мы, сообщество. Как? Да не отталкивать от себя грамотных пользователей, прежде всего. А еще точнее - определить, для кого всё-таки предназначена система. В архивах arch@ двухлетней давности я читал такой диалог:
> Personally I'd like to think that that we write an OS for users.
We write an OS for the people who can and will use an OS written by us.
О ком здесь говорит коммиттер? Фактически, по тому же принципу Парето, он говорит, что 80% пользователей системы суть фанаты, которые будут использовать OS written by us несмотря ни на что, и 20% забредших грамотных пользователей, которые могут использовать системы и сделают это по каким-то их специфическим задачам, которые в данный момент не могут быть удовлетворены другими ОС.
Я считаю, что наоборот, система может стать настолько лучше, чтобы доля фанатов, развивающих систему, составляла всего 20%, остальные же - были грамотные пользователи, использующие систему из-за объективных преимуществ. А если доля пользователей FreeBSD возрастет таким образом в 4-5 раз, то, при доле серверов не в 3%, а в 15% вполне реальна поддержка корпораций и прочие радости жизни.
"Какая еще нафиг ненужная поддержка корпораций, и зачем нам эти иждивенцы в количестве 80%, которые ничего не отдают системе патчами?", - спросит среднестатистический фревый фанат-контрибутор? А всё просто. Существуют задачи, и их очень много, которые не могут быть решены патчами одного человека. Нужны целые их коллективы. В конце концов, коммиттеры FreeBSD - тоже коллектив. В одиночку не получится сделать и разнообразные архитектурные изменения - такое всегда требует обсуждений в списках рассылки. Отвечать на подобное "patches are welcome" - просто повод ничего не сделать. Посмотрите на Linux. Туда "присылают патчи" те же корпорации, большие коллективы. У нас это тоже есть, но в гораздо меньших объемах. А мы плачемся, что тратим кучу усилий на портирование Файрфокса, Хрома и других. А ведь коллективы их разработчиков, которые не корпорации, могли бы портировать их для нас сами. Не тратя наших усилий. Разве не этого мы хотим, когда говорим "where are your patches?" ?.. Как этого добиться? Очень просто - повысить популярность системы (что особенно актуально в свете выживания, когда некоторые из них уже начали призывать писать непортируемый код). Всего лишь какое-то время работать на перспективу - да, просто для тех, кто пользуется и ничего не присылает в ответ. Через какое-то время это даст свой эффект, на сотню юзеров найдется и один разработчик, а потом нас начнут замечать уже просто из-за достаточной доли. И патчи потекут от тех, кто может.
Да, так не получится сделать сразу - на рисунке справа изображена так называемая кривая Гартнера (hype curve), и мы сейчас, по-видимому, находимся где-то на её вершине, за которой неминуемо последует спад. Наша задача - приложить сейчас такие усилия, работая на будущее, чтобы этот спад затем перешел в подъем, причем перешел уже в схему Performance S-curve, обеспечив уровень больший, чем есть сейчас.
Что нам мешает это сделать, и какие схожие примеры можно найти в новейшей истории? Десять лет назад в России начался стремительный спад числа членов сети Фидо. В истории о социальных причинах этого и комментариях к ней можно прочитать, что автор тех строк еще в 1998 году выступал против "реформаторов", требовавших, например, отмены ZMH, "священной коровы" тогдашней сети. Автор сетует, что тогда никто ему не объяснил, что это уже была всего лишь традиция, более не отражающая изменившихся технических требований. Как можно видеть по графикам, всего через 3 года после первых дебатов по этой теме случился резкий перелом, число узлов стремительно пошло вниз. Всё, сейчас сеть практически мертва.
У нас нет трех лет роста, лишь только после которого случится падение, но нет и (как мы убедились выше) ужасающего технического отставания, каковое сложилось у Фидо в момент перелома. Мы еще имеем шанс и можем не повторить их ошибок. В чем же они заключались? Если коротко, то социальные и психологические причины воспрепятствовали технической модернизации. Если были бы приняты нужные решения, то технические решения стали бы уже делом техники, пардон за каламбур. Посему я и веду речь прежде всего о социально-психологических причинах, к техническим перейдем позже.
Не помнящие ошибок прошлого обречены повторять его.
- Джордж СантаянаИтак, у населения Фидо наблюдались излишняя жесткость, упертость и консерватизм. Да, сейчас мне тут же начнут возражать перечнем тех плюсов, которые фре приносит консерватизм. Вот только есть разница между понятиями "консерватизм" и "здоровый консерватизм", "строгость" и "жесткость (негибкость)", "упертость" и "принципиальность". Действительно ли то, чем вы хотите возражать против дальнейшего, обусловлено актуальными причинами, или вы предпочитаете действовать так по привычке? Действительно ли возражение имеет технические обоснования, или это просто традиция? Как мы увидим дальше, вполне возможно делать изменения, не нарушающие строгости и т.п., но которые могут противоречить упертости. Как отличить одно от другого? Один критерий я уже приводил: когда возражения направлены на то, чтобы в итоге ничего не менять и не делать. Другой - это посмотреть, действительно ли ваши технические возражения применимы более, чем в небольшом числе случаев. Если окажется, что вы возражаете против нарушения привычки ("мне так удобно") или аргументируете сугубо частным случаем ("в -надцатом году мне это помогло") - поздравляю, Вы в плену привычек, которые приносят вред FreeBSD. Посмотрите шире, чем Ваш уютный мирок.
Психология подсказывает нам, что жесткость и лишний консерватизм проявляются (и вредят!) сразу в нескольких местах. В том же Фидо это выражалось не только в сопротивлении техническим новшествам, но и в драконовских правилах и произволе в некоторых других местах (подробнее см. по ссылкам выше). В результате многие люди уходили из Фидо даже после того, как их туда заагитировали, просто потому, что разочаровались - от них требовали больше, чем они получали (четко прослеживается аналогия с "where are your patches?", не правда ли?). В сообществе FreeBSD существуют аналогичные явления. Вспоминая пример со студентами в общагах, какой смысл пропагандировать FreeBSD, если приходящие грамотные люди тут же "получат по шапке" от сообщества? Зачем человеку тут быть и тем более присылать свои патчи, если его даже не хотят для начала просто выслушать?.. Не так давно я лично наблюдал случай: человек задал вопрос вполне внятно, в соответствии с "Как правильно задавать вопросы", привел всю нужную информацию, просто в небольшом несоответствии с тем, как вопросы было принято оформлять здесь (#freebsd@RusNet). Тут же получил "от ворот поворот" от одного из операторов, мол, я так оформленное даже читать не буду, соблюдай наши правила.
Ну и кому от этого стало лучше? Стало ли от этого лучше FreeBSD? Человек просто "проголосует ногами" и будет всем рассказывать про "неадекватное сообщество". Понятно, откуда такое требование изначально возникло - новички часто не в состоянии грамотно сформулировать вопрос. Однако необходима гибкость для оценки, когда этот формализм помогает, а когда вредит. Задумайтесь, а как бы в таком случае поступили члены core team? Они в списках рассылки вполне вежливо на всякие разные вопросы отвечают...
Собственно, а что вам (нам всем) мешает просто признать свои ошибки и измениться? Гордость (а точнее гордыня aka ЧСВ)? Что, типа, линуксовые тролли на форумах взвоют, ага, они с нами наконец-то соглашаются? Обиды? Дескать, мы щас начнем делать как у них там в линуксе и фря будет уже не та, потеряет отличия?.. Да ничего подобного! Тролли отличаются тем, что никакой реальной помощи от них нам не дождаться. Послушать их "предложения" и сделать точно так же, как в линуксе? Фигу, мы сохраним свою уникальность. Более того, иметь мужество признать свои ошибки и исправить их, своим собственным способом - более трудно и более почетно, чем красноглазо выкрикивать, плетясь в мэйнстриме. Кто надеется пройти только через победы - не дойдет. Нужно быть готовым пройти и через грязь, и через поражения, и через позор, но - дойти.
Технические проблемы FreeBSD и предложения по ним.
Итак, две основные проблемы FreeBSD, на которые указывает большинство внешних наблюдателей - это пакетный менеджер и базовая система. Две тесно связанные друг с другом проблемы. Конечно, у FreeBSD хватает и других технических проблем, например, с теми же файрволами, но о них - в другой раз. Сейчас сосредоточимся на самом важном, на том, что по принципу Парето, от 20% усилий решит 80% наших проблем (и, при соблюдении социальной части, даст 80% юзеров).
source-based linux distro невозможен, ибо у них нет базовой системы
без отдельной БС оно превращается в кашу легким движением руки
возможен, если там сделают БС и будут её поддерживать именно как БС
ну все дистры так и делают, только не говорят, что у них есть БС
Jay, но это проблема не только source-based, но и бинарных
Jay, ну, в смысле, чтобы был атомарный апгрейд БС
ну да, иначе первый же апгрейд glibc разрушит цивилизацию
так что, те, кто говорит, что в линуксе нет БС и это хорошо - врут :)
в любом живом дистре она есть, только про нее юзеры не знаютМонолитная базовая система, которую оппоненты предлагают поделить на тысячу маленьких пакетов "как в Линуксе". То есть, по сути убрать такое разделение, как "база" и "пакеты". Единственное ли это решение? Нет, конечно. Обратимся ко всем другим ОС, кроме Linux, и обнаружим, что понятие базовой системы, а не только ядра, существует везде. Даже в Windows (отдельно компоненты системы, отдельно приложения).
Но как именно она в них сделана? Посмотрим, скажем, на Solaris. Там имеется несколько довольно крупных, но пакетов, из которых и состоит базовая система. В этом смысле солярка похожа на фрю - во фре при инсталляции тоже можно выбрать distributions. И, как и во фре, они крупные и по умолчанию ставятся не по отдельности, а наборами. Пакетный менеджер в солярке, правда, ужасающ, всё еще хуже чем во фре. Для полноты картины солярка была упомянута, всё, теперь о солярке можно забыть.
На самом деле, монолитность базы - достоинство. В начале года в Фидо _slw подробно - см. http://groups.google.com/group/fido7.ru.unix.bsd/msg/b2e9414abbbe17eb - расписал плюсы и минусы единой базовой системы и системы, разбитой на пакеты. Про минусы (не только базы, но и пакетов) уже много кто объяснял подробно, поэтому я их просто перечислю, чтоб были под рукой:
- Для изменения состава базы систему можно только пересобрать с опциями src.conf, при этом никакой информации о составе и поддерживаемых фичах скомпилированной системы в бинарном виде не сохраняется, нельзя бинарно обновить любой кастомный вариант, даже просто собранный из сырцов с опциями по умолчанию -STABLE.
- Жесткая зависимость имени файла пакета от фич, которые туда причем кодируются лишь иногда. Нет способа определить, с какими опциями собран пакет.
- Жесткая привязка к имени файла в зависимостях пакетов, что означает и жесткую привязку к конкретной версии.
- Собственно, из привязок к имени вытекает много других неудобств, например, дурацкие конфликты между вариантами одного и того же пакета, геморрой при обновлении кучи пакетов (обновление одного может повлечь за собой пересборку почти всей системы).
- Нельзя модифицировать пакет без правки базы пакетов вручную, в том числе невозможность штатного обновления/замены пакетов.
- Всё то же самое с базовой системой, плюс отсутствие связок между базовой системой и пакетами - например, пакеты (/usr/local) прямых зависимостей от базовой системы не имеют, как и от её конкретных фич из src.conf (так что легко сломать по неосторожности в кастомных конфигурациях).
- Требующие более глубоких изменений, но и менее актуальные проблемы с ветками (как HEAD/STABLE, так и samba34/samba35) и devel-ветками, версиями и devel-вариантами (это которые хедеры/дебаг и т.п.), альтернативными репозиториями (и их приоритетом). То есть с тем, что требует более одного измерения, не только лишь category/progname.
Гораздо более интересно, однако, помнить о тех плюсах, которые предоставляет концепция базовой системы. Их мало, но они большие:
- Release engineering. Система представляет собой не кучу софта, а действительно систему - все её компоненты находятся в согласованном состоянии. Версии ядра и утилит между собой при обновлении останутся согласованы между собой. Ситуация, когда из-за апдейта по частям что-то отваливается, например сам пакетный менеджер на середине процесса, невозможна. Кроме того, согласованность означает тестирование - базовая система поддерживается командой, которая следит за качеством. Nota Bene: Согласованность не сводится только лишь к преимуществу апдейтов, этот принцип универсален - любая система есть нечто большее, чем простая сумма её компонентов (впрочем, здесь слишком мало места, остается только отсылать к философии и системному анализу).
- Сравнительная комплектность и унифицированность. После установки имеется набор софта, пригодный для определенного класса задач, при этом он будет доступен в каждой инсталляции FreeBSD - всегда можно ожидать наличия ssh, tcpdump и ряда других полезных утилит. На это можно опираться. Здесь невозможна ситуация, когда, приехав на объект, можно обнаружить, что предыдущий админ не установил что-то элементарное, поскольку при установке нет проблемы "что выбрать из сотни галочек", особенно для новичка. По целому ряду инструментов никогда заранее не знаешь, пригодятся ли, поэтому лучше их иметь на всякий случай. Я видел, например, инсталляцию Gentoo, где не было никакого почтового агента, и об ошибках в его crontab сообщения валились на мой релей сети, а не его машину.
- При размытии границ между базовой системой и пакетами, кроме усложнения выбора, легко может возникать ситуация сложных и запутанных (для админа) зависимостей, которые притянут много лишнего (канонический пример - ssh тянул за собой половину X11 по зависимостям в Debian).
Итак, нам говорят, что концепция базовой системы не подразумевает полноценной работы с пакетами, и потому надо отказаться от базовой системы нафиг, разбив её всю целиком на пакеты. Что мы тут имеем? Два разных подхода, "база" vs "всё пакетами", которые вроде бы исключают друг друга, по крайней мере, в текущей реализации каждого. Постановка вопроса подразумевает, что какой-то один из подходов безусловно лучше, хотя разве такое возможно при наличии минусов у обоих?.. На самом же деле, нужен новый третий подход, отличающийся от предыдущих двух и гармонично объединяющий плюсы тех двух. И разработка такого подхода - весьма интересная и творческая инженерная (даже изобретательская) задача.
Собственно, *BSD-системы всегда отличались склонностью именно к таким решениям. Присмотреться к аналогам, учесть ошибки и выпустить пусть с опозданием, но нечто такое новое, что будет пригодно и не устареет еще длительный срок, не требуя кардинальных переделок уже через год. Так, например, в NetBSD в свое время попытались разделить базовую систему на пакеты. Естественно, эта идея заглохла, потому что ничего существенно нового и изменяющего подходы так, чтоб плюсы и старого учитывались, она не принесла.
Итак, попытаемся (все вместе) решить эту задачу. Есть основания полагать, что она не потребует переписывания всего с нуля, а позволит обойтись не столь уж большими усилиями. Тем более, что есть одно важное условие: проект FreeBSD весьма ограничен в ресурсах. Здесь имеется в виду время разработчиков и усилия других помогающих проекту. Это в Linux вкладывают миллиарды баксов, у нас такого нет.
Опции сборки. В Makefile'ах портов бывает можно видеть строки, подобные:
.if ${OSVERSION} < 700104 || ${OSVERSION} >= 900000
...что означает проверку на версию базовой системы. Далее, в ядре с некоторых пор активно внедряется макрос FEATURE(), информация из всех применений которого собирается и экспортируется через sysctl для приложений, желающих проверять доступность той или иной возможности. Естественным образом эту идею можно обобщить и на саму базовую систему, на её компоненты - проверку этих опций и записывать в пакеты. Точно так же можно вписывать в пакеты и их собственные опции сборки, вынеся их и версию из имени пакета.
В случае решения "малой кровью" - можно обойтись изменением формата имени и строчки @pkgdep в +CONTENTS на содержащую только имя, диапазон версий, и требуемые значения опций в зависимостях. В случае более серьезного решения, возможно, необходимо будет приделывать к pkg_* функции, аналогичные проверкам переменных в портах. То есть, например, прописывать зависимость не от пакета, а как в портах:
LIB_DEPENDS+= profiler.1:${PORTSDIR}/devel/google-perftools
С учетом пожеланий того, чтобы бинарные пакеты стали равноправны с портами - вполне возможно, что потребуется сделать и так. Я уже не говорю о таких само собой разумеющихся вещах, как возможность обновления/замены штатными утилитами, и т.д.
Гораздо более интересен вопрос существования базовой системы. Основной аргумент, чтобы разбить её на множество мелких пакетов - это "теперь отдельные компоненты можно будет легко обновлять" и "можно не ставить ненужное". Но что такое отдельные пакеты по своей сути? Это независимые друг от друга компоненты. То есть, чтобы разбить монолитную систему на отдельные независимые модули, нужно затратить усилия на изоляцию их друг от друга и затем постоянно тратить усилия на поддержание их независимости друг от друга. Однако для цели release engineering разработчики постоянно тратят усилия на согласование всех компонентов между собой. Две во многом противоположные задачи. Чтобы догнать обоих зайцев, нужно затратить усилий не в 2, а в более чем 2 раза больше. А ресурсов у FreeBSD, как мы помним, мало. Что делать?
Противоречие снимается, если провести границы между компонентами иначе. Здесь важно прежде всего административное деление - в чьей зоне ответственности находится тот или иной компонент, кто его vendor. В самом деле, зачем разработчикам FreeBSD огораживаться самим от себя? И в то же время, чем постоянно аргументируют сторонники разделения базы на пакеты? BIND, Sendmail, GCC. А ведь это всё - то, что производится не на @freebsd.org. Что самое здесь хорошее, так это то, что разработчики FreeBSD уже прилагают некоторые усилия к поддержанию границ между софтом различных вендоров (просто незаметные пользователю). Дополнительные затраты усилий - минимальны сравнительно с другими вариантами. И некоторые разработчики, например Doug Barton (майнтейнер BIND, который всё мечтает выкинуть его из системы), тоже считают, что между текущим состоянием базы и "всё пакетами" должен быть некий промежуточный вариант.
Сделаем du -hd 1 /usr/src/ и увидим, что вся система занимает порядка 500 Мб, а /usr/src/contrib - порядка 250 Мб, то есть около 50%. Сделаем то же самое с самим contrib-софтом и увидим, что около половины его занимает GCC и его утилиты (кстати, исходники ядра занимают примерно половину того, что не contrib, т.е. систему можно условно поделить на четыре примерно равные части).
То есть, уже вырисовываются некоторые наметки: оставить в единой монолитной базе только то, что делают коммиттеры @freebsd.org, и выделить несколько десятков пакетов. Здесь, правда, возникает проблема: это условие, как в математике, необходимо, но не достаточно. Такая база не сможет жить самостоятельно, в contrib лежат, в частности, библиотеки, используемые остальной системой.
Хорошо, изменим критерий, пусть он будет звучать как: базовая система есть то ПО, чей эффективный вендор есть *@*bsd.org (в сии трудные времена BSD-системам лучше объединяться и выживать вместе, да и всё равно обмен кодом всегда шел между братскими версиями более интенсивно). Здесь "эффективный" значит, например, что или вендор был, но давно сдох, и компонент поддерживается коммиттерами (как в случае traceroute), или компонент втащен в систему под другим именем и навряд ли будет обновляться из апстрима (как expat -> libbsdxml). Уже лучше, в системе останется "из коробки" жить, например, openssh, правда, всё равно возникает проблема еще с рядом пакетов, например, openssl (используемый средствами обновления и проверки целостности системы). Такая база даже пересобрать сама себя не сможет без компилятора, например. И опять же, сетевая ОС да без tcpdump?!.. Критерий вроде хорош, но к нему уже приходится придумывать исключения...
Тут вопрос в том, что традиционно база определялась иначе. В базе было всё, потому что делали под себя ("will use an OS written by us"). Это был набор софта, удобный определенной группе людей. Сейчас нам необходимо сделать систему для более широкого круга юзеров. И всё упрется в то, как именно в точности определить эту группу, нашу целевую аудиторию. Достаточно достоверно прямо сейчас можно сказать лишь про то, о чем часто бывают крики, то есть, что нашей целевой аудитории не нравится.
Вот, например, почта. Большинство наших пользователей уже сейчас либо сносят Sendmail и ставят себе другой MTA, либо оставляют настроенный из коробки Sendmail для достаточно узко очерченных целей. Каких? Зачем вообще в базе почтовик? Для двух целей:
1) Складировать поступающую почту periodic-скриптов и других cron-заданий в локальные mailbox'ы либо отправлять её на нужный адрес
2) Позволить отправить почту с машины любым другим системным скриптам (например send-pr) или пользователю.
С обеими задачами прекрасно справится разработанный в DragonflyBSD именно для этих конкретных целей маленький агент dma. Его можно втащить в базу, он удовлетворяет критерию "вендор *@*bsd.org", и выкинуть из неё Sendmail. Кому нужен полноценный MTA, легко поставит из пакетов что угодно. А чтобы не нарушать POLA для тех, кто привык, достаточно поставлять вместе с базовой системой пакеты и держать соответствующие галочки отмеченными по умолчанию.
Обратите внимание, что здесь основные принципы FreeBSD вовсе не будут нарушены, а даже будут подчеркнуты. Чистота, строгость, минимальность: лишнего в базе нет, нужен почтовик - ставьте на выбор, не ограничивают. Есть налаженный техпроцесс со старой системой - пожалста, вот вам галки по умолчанию. А как насчет GCC, кощунство? Как так, база не сможет пересобрать сама себя? На самом деле нет, уже сейчас make release требует для своей работы кроме базовой системы еще ряда портов. Так же и для возможности пересборки. Просто опять же, класть их на инсталляционный диск рядом. А с учетом грядущей перспективы перехода на Clang отделение компилятора от базы и возможность использования с ней любого из двух компиляторов на выбор - это хорошо.
Таким образом, критерий "что именно оставить в базе" должен определяться целевой аудиторией и задачей, которую предстоит уточнить. Допустим, это будет "способный к работе после установки сервер, на который должно быть можно поставить из сети пакеты". Такая задача потребует некий необходимый минимум, например, редактор (vi) необходим для настройки сети - тех же rc.conf, resolv.conf. Для настройки сети может потребоваться чтение манов - нужен $PAGER (more, который у нас less). Пакеты надо распаковать, значит нужны архиваторы, проверить чексуммы, то есть требуются утилиты для их сверки (кстати, пригодится и для еще нормально не реализованной задачи сверки целостности базы - freebsd-update пока обрабатывает мало случаев).
Что у нас еще есть из проблем тех пользователей, на которых стоит ориентироваться? Допустим, база "похудеет" на треть. Она станет проще в поддержке для Security officer и других коммиттеров и может развиваться несколько быстрее. Станет возможным удлинить релиз-цикл на один minor-релиз. Зачем это? Затем, что уже несколько major-веток складывается такая ситуация, что релизы выходят чаще, STABLE для наших консервативных пользователей стабилизируется только к версии X.2. Но как раз следом выходит версия (X+1).0 и далее релизы X.3, X.4 уже почти не развиваются как таковые. Версия X.4 становится последней, потом новых релизов больше нет. При этом какое-то время существуют сразу ДВЕ ветки STABLE, сейчас, например, 7.x и 8.x. В итоге многие пользователи мигрируют сразу через одну ветку (с 6.x на 8.x) - ну и для кого другая, спрашивается, делалась и поддерживалась?..
Стандартное возражение разработчиков - плавали с этим во времена 4.11, наелись, куча проблем была. Да елки-палки, что вас в крайности-то бросает? То .0 каждые 2 года, то 5 лет без нового major. Оба варианта плохие, есть золотая середина. К тому же не придется поддерживать сразу два STABLE, вот экономия ресурсов. Особенно если базу облегчить... В конце концов, та стабильность - одна из выгодных отличительных черт FreeBSD, один из принципов. Поступаться им ради скорости выпуска нового major - значит терять конкурентное преимущество. Почему бы не поискать другие способы решения тех проблем, для которых был задуман короткий релиз-цикл?.. Да-да, снова поискать гармоничное решение с плюсами, незачем копировать у Ubuntu и Firefox порочную тактику time-based релизов и гонки за версиями...
И напоминаю, огромное значение имеют и социальные причины. Технические изменения следует проводить в жизнь вместе с ними, одновременно. И если Вы с чем-то категорически, решительно не согласны - это признак того, что несогласие скорее всего не имеет под собой реальных весомых аргументов, а лишь эмоции. Мы не в том положении сейчас, чтобы тешить свое ЧСВ тогда, когда это ставит под угрозу будущее проекта. А сиюминутный рост в каких-то областях не означает, что всё хорошо в целом и будет так и дальше продолжаться. Еще раз, давайте думать, как нам измениться, а не чем обосновать "не надо ничего делать". А к "мы ничего не будем делать" относится, разумеется, и отмазка вида "patches are welcome". Организационные проблемы патчами не решаются, увы. Перечитайте выше подраздел социальных проблем.
На том пока всё на момент публикации. Высказывайте Ваши взгляды на проблемы и способы их решения в комментах, я буду дописывать их ниже. Потом из всего этого будут собраны рекомендации, с которыми пойдем в arch@freebsd.org пропихивать уже официально.
Nota Bene: В комментах принимаются только конструктивные предложения. Троллинг, холивары и т.п. вредное будет нещадно тереться. Срите в предыдущем посте.
---8<----8<--- линия отреза ---8<----8<---
- Предложение о мета-пакетах как аналоге мета-портов от ra_ga Уже имеются в системе, например xorg-apps.
- slonik_v_domene указывает, что отдельные пакеты могут быть использованы для решения лицензионных проблем, типа BSD grep или GNU grep. Эту идею можно развить и далее, например, стоит пересмотреть лицензионный вопрос об использовании свежего GCC, если он будет вне состава базы.
- Собственно, социальную часть можно резюмировать так, что нам, сообществу, следует ориентироваться не только на себя, тех кто committed и involved в проект (см. на http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig объяснение), но и на определенный круг пользователей вне самого нашего сообщества. Да, не давать лезть в идеологию проекта, но учитывать их потребности. Ряд наших пользователей считает, что фря элитарна, и что не следует ничего менять и поднимать популярность, ибо "кухарка не может управлять государством", и тогда фря станет попсой (commodity OS). Сие мнение ошибочно и базируется сугубо на ЧСВ, вредящем в данном случае системе. Во-первых, элитарность определяется вовсе не процентом пользователей, во-вторых, кроме двух крайностей "3%" и "как Линукс с 90% нубами" есть куча промежуточных вариантов. Чем вам, скажем, 15% плохо? Это не попса, нам и не нужно кидаться в крайность массовости, достаточно просто определить тот круг достаточно грамотных пользователей, который за пределами текущего размера сообщества.
- Решение проблемы -devel и не-devel пакетов (здесь их линуксовое понимание, а не фряшные порты-devel, см. далее) можно получить обобщением системы зависимости от опций сборки, для чего еще необходимо делать возможность сборки нескольких пакетов из одного порта (идея совместно с b_a_t); это глобальный knob типа WITHOUT_X11. Пример же проблемы devel-пакетов: когда glib имеет perl в R-deps, но сам этот скрипт на перле необходим только лишь для сборки зависимых от glib портов - а так perl прописан у glib в R-deps и требуется всегда.