Каковы проблемы FreeBSD и пути их решения? [LJ]

Для начала, линки на оригинал.

Часть 1
Часть 2

А теперь сам текст, мало ли что снова с ЖЖ будет...

ЗЫ Комменты там тоже имеет смысл читать, но сюда их копипастить не буду.

Плюс на хабре тема, выделено сравнение с gentoo

ЗЫЫ ветка шетухина

Каковы проблемы FreeBSD и пути их решения? Часть 1: Рампочта.
Три недели назад Андрей Шетухин, руководитель отдела почты Rambler, сообщил о начале миграции своего почтового кластера (порядка 500 серверов) с FreeBSD на Linux (Debian/Ubuntu), поскольку FreeBSD перестала его устраивать. Дискуссия в комментах, которых уже более полутысячи, разгорелась нешуточная. В комментах также стало известно, что аналогичный переход планирует Яндекс на своем поисковом кластере, который в данный момент работает целиком на FreeBSD, а это примерно 25000-30000 серверов, и порядка 60% мощностей Яндекса. Такая потеря — это для FreeBSD уже серьезно. С такими тенденциями система, к радости ликующих подонков, станет таки умирать.

Очевидно, что подобные решения не принимаются на ровном месте, и существуют определенные причины, проблемы, которые мы, FreeBSD, можем начать исправлять, пока не стало слишком уж поздно. BSD-сообщество привыкло закрывать глаза на многие проблемы, считая их несущественными. Более так поступать нельзя — легко списать всё на тараканы в голове менеджмента и ничего не делать, вот только постоянное повторение такого образа действий приведет к тому, что лет через 5 работу BSD-администратора будет уже не найти (Вы такую перспективу себе хотите? Я лично — нет). Однако, с другой стороны, тот же Шетухин 3 месяца назад писал "Вывод простой: миграция на Linux нецелесообразна, так как затраты на нее не окупятся" о том, что разницы в производительности FreeBSD и Linux для их целей не выявлено. То бишь, следует отделить зерна от плевел и решать те проблемы, которые действительно есть.

Таким образом, имеется два утверждения (которые будут более подробно рассмотрены далее), причем оба истинные и друг другу не противоречат:

I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
II. У FreeBSD действительно есть серьезные проблемы, нам необходимо их решать, иначе нам каюк.

По второму вопросу — в следующем посте предполагается анализ, каковы еще проблемы FreeBSD и как их можно решить, с опросом мнения читателей. Но сначала — о том, почему держателям акций Рамблера стоит продавать их, пока курс еще хороший.

Часть I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).

Что выяснилось в процессе обсуждений как в комментах к посту, так и в других местах? Например, то, что проблемы и претензии Рампочты к FreeBSD были вызваны во многом их собственной спецификой. А именно, это закрытый отдел, и они не используют наработки остальной части Рамблера. В условиях больших систем нормально организовывать работу ведь следует как? Делается собственная сборка системы, часть машин выделяется под компиляцию (сборку пакетов), часть под тестирование. Этот процесс требуется всегда, какой бы там дистрибутив не стоял — даже с самым бинарным будет сделан свой локальный репозиторий, в котором собираются пакеты под задачи фирмы. И распространяются пакеты аналогично. Может быть видоизменен инсталлятор для автоматизации разливки на новые машины кластера, и т.д.

Но у них, в отделе почты, свой инсталлятор, они не пользуются, например, тем, что сделано у работающего в соседнем отделе Глеба Смирнова, коммитера FreeBSD. Из высказанных претензий складывается впечатление, что администраторам Рамблер-почты неизвестно ни про freebsd-update(8) — средство бинарного апгрейда базовой системы, имеющееся в ней уже 5 лет (обновляет в две простые команды, "скачать" и "поставить"). Ни про portmaster, написанная на чистом /bin/sh утилита обновления пакетов, альтернатива portupgrade — претензия к которому была, что он тянет за собой язык Ruby.

Аргументов было много, внятный перечень (я тут свёл воедино из нескольких разных комментов) был таким:

Ок. Давайте осилим тиндербокс. Давайте осилим бинарные обновления базовой системы и пакетов. Давайте подтянем версию FreeBSD к текущей. Давайте забьем на тупизну ipfw и убогость pf по сравнению с iptables. Давайте все собирать древним как говно мамонта компилятором. Давайте жить на ufs2. Давайте сделаем еще миллион прекрасных в своей глупости вещей, лишь бы не уходить с труъ-системы на негодный Линукс.

Все это прекрасно, но моим админам не платят за название операционки. Им платят за то, чтобы все работало. Сделать так, чтобы все работало на Линуксе, объективно проще, чем на FreeBSD. Пройдет еще 3-5 лет, и фря станет системой исключительно для маргиналов.

1. Убить такое понятие как монолитная base sysem, сделать набор пакетов для base system и для ports.
Компилировать и патчить мир в 2011 году — уебанство. Кроме того, куча вещеий из base system не нужны большинству юзеров. Значит, их и ставить не надо. Тот же bind, который не запускается на 99.5% серверов. Хрена он там делает в base system?

2. Отказаться от сборки пакетов как от основного способа установки ПО.
Пакеты должны ставиться из репозитория, и только. Нужно что-то свое — делайте набор ПО чтобы подключить локальный репозиторий на машине.

3. Сделать -STABLE репозиторий с пакетами, регулярно обновляемыми патчами.
Да, это напрягает — искать патч к X.Y.Z версии одного пакета только потому, что другой пакет хочет только ее.

4. Разработать систему автообновлений, позволяющую с минимумом головной боли содержать up-to-date систему. Ключевое слово: АВТОобновлений.

5. Самое важное: все это должно быть "из коробки", без доустановки и чтения инструкций.

Я ничего против портов не имею, это наоборот, очень удобно и классно. А вот к менеджеру пакетов претензии есть.

Серьезные ли это причины? Серьезные, хотя разбираться мы с ними будем позже. Но, однако в другом месте встречаем признание: "Собственно, все пертензии к деплойменту — невозможность в автомате с учетом всех требуемых зависимостей поднять версию системы и/или переустановить те пакеты, которые требуются. Это — прямое следствие использования pkg_*."

Решаема такая проблема с FreeBSD? В принципе, решаема, но требует скриптования. Вполне понятно и желание не заниматься рутинной работой, которую уже сделали другие. Другое дело, что максимально её сложить с себя можно только, если кто-то это будет делать на оплачиваемой основе. Вполне резонно следующее мнение: "Удивительно, что Rambler, ища стабильность и уверенность + иметь возможность своих админов отпускать вечерами домой к семье выбрали опять черти что, а не коммерческий RedHAT, где они получат любую консультацию почему у них что-то не работает. А ведь для такой конторы как Рамблер стабильность должна быть на первом плане, а они ищут халявки. позор."

Тут-то уже закрадываются подозрения, что не во FreeBSD дело — ведь, как резонно отмечали, даже конкретно Debian не уменьшит работу админов до нуля как по волшебству. Подозрения закрадываются в том, что текущие админы Рампочты попросту не в состоянии адекватно управляться с FreeBSD. Так ли это? slonik_v_domene пишет по этому поводу:

Из админов ушел ровно один человек, было это в конце весны 2009 года. Причины, по которым мы расстались очень просты и печальны: мы не смогли работать друг с другом. Тем не менее, расставание прошло без ругани и взаимных истерик. И несмотря ни на что, к этому человеку я испытываю уважение за профессионализм и умение твердо отстаивать свои принципы, даже ценой рабочего места.

Далее находится (в IRC) сам этот ровно один человек, это был ospf_ripe, и комментирует заявление "FreeBSD сложно майнтейнить" так:

Wed 22:46:44 <@citrin> nuclight: не очень понятно что там маинтейнить, а миграция будет очень сложно и трудозатратной (до прихода slonik-v-domene я работал в Рампочте и представляю что там есть внутри)
Wed 22:52:18 <@citrin> обсуждать не хочется и смысла не вижу. собственно я и ушел оттуда из за того, что с Шетухиным сложно вести конструктивный диалог. Он любит все решения принимать сам, ни с кем не советуясь и не аргументируя свою точку зрения.

Аналогичной точки зрения придерживаются и другие сотрудники Рамблера. В частности, известно, что оттуда в свое время уволился и Максим Дунин (mdounin). Сам slonik_v_domene от комментариев насчет него отказался, а Глеб Смирнов высказался по этому поводу так:

Tue 16:17:37 <@glebius> ну, если бы Максим был здесь, то я думаю слоник бы не начал этого манёвра
Tue 16:17:56 <@glebius> потому как начальству будет видно, что это просто перестановка мебели
Tue 16:18:11 <@glebius> а сейчас понимающего начальства нет, так что можно попереставлять

[UPDATE:glebius@ поправляет, что это был не mdounin, а maxim@freebsd.org]

По непроверенным слухам, slonik_v_domene работал ранее в компании СУП (которой принадлежит ЖЖ) и был оттуда уволен за примерно такие же действия — взять и устроить революцию работающей системы без оснований.

Прямых подтверждений тому у нас нет, зато косвенных — валом. Например, мной был задан вопрос, чего не хватает FreeBSD, как нам можно её улучшить. Ответом был приведенный выше перечень, что именно стоило бы сделать. Однако последовавшее за этим обсуждение показало странные вещи. Глава Рампочты никак не хочет признаваться, в какие же именно затраты рабочего времени администраторов (то есть в конечном счете финансовые затраты) выливается та или иная проблема FreeBSD. Например, еще более-менее понятно, чем плох BIND в базовой системе, хотя даже по этому вопросу конкретику с цифрами я почему-то получил от другого человека. А вот чем администратору мешает наличие в базовой системе какой-нибудь мелкой утилиты, скажем, make— уму непостижимо. Если она не используется — она вообще не требует внимания админа, лежит себе да лежит. Если её требует кто-то по зависимостям — она всё равно будет поставлена по зависимостям, что во фре, что в дебиане. Если всё ставить вручную — наоборот, требуется время админа на расстановку галок в инсталляторе (или его эквиваленте), никакого выигрыша...

Такой отказ в назывании конкретики говорит о том, что причины не технические. А тут еще выясняется что? Что из Рамблера по-тихому, 3 месяца назад, ушел Игорь Сысоев, автор известного web-сервера nginx. Итого, из Рамблера ушло уже трое. Между тем, внимания заслуживает еще такая цитата:

> что подходы рампочты к администрированию конкретно fbsd, мягко говоря, плохие.

Ну, плохие и плохие. Будет Линукс вместо FreeBSD, будут хорошие подходы. Что-то возразить по существу описанных с портами проблем есть?

Изменятся ли подходы от смены систем? Ни разу, "внезапная революция в мосгах, бывает ли такое". Подходы зависят от людей. Заблуждение о том, что есть "серебряная пуля", инструмент, с которым все проблемы сразу решатся, к сожалению, популярно... Вдругом треде в обсуждении slonik_v_domene также заявлял о том, что предпочтительны системы, с которыми справится и новичок. Он считает, что "первопричина — это не люди, а системы. А люди — следствие". В действительности же — именно люди, ключевым является именно персонал, а не инструменты. Нет смысла останавливаться на этом подробно и переубеждать того, кто до понимания положения "кадры решают всё" еще не дорос. Я просто процитирую по этому вопросу классика:

Выдающиеся проектировщики. Главная проблема совершенствования искусства программирования заключена, как всегда, в людях. [...] Выбор правильного метода проектирования определяет различия между плохим и хорошим концептуальным проектом, но не между хорошим и выдающимся. Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой.
И разница немалая — это как Сальери и Моцарт. Одно исследование за другим показывают, что лучшие проектировщики создают структуры, которые быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями. Различия между выдающимся и средним достигают порядка величины.
[...]
Как растить выдающихся проектировщиков? Место не позволяет обсуждать это пространно, но вот некоторые очевидные шаги:

• Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.
• Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.
• Разработать и осуществлять план служебного роста для каждого перспективного проектировщика, включающий тщательно продуманное обучение у передовых проектировщиков, периоды дополнительного формального обучения, краткосрочные курсы, перемежающиеся с самостоятельным проектированием и назначением на руководящие технические должности.
• Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.

(с) Фредерик П. Брукс. "Мифический человеко-месяц или как создатся программные системы".

В Рамблере же всё происходит с точностью до наоборот. Кроме того, Андрей Богородский прокомментировал, что штатная сетка рампочты привела его в тихий ступор — с точки зрения риск менеджемента два человека администраторов недостаточно даже для текущего саппорта, что уж говорить о развитии (чтобы от болезней/свадеб/отпусков не зависеть, по КЗОТу для обеспечения круглосуточной работы должно быть минимум 5 человек на клетку).

[UPDATE: Эта ситуация относилась к 2008 году. Как сообщает А. Шетухин, сейчас сисадминов хватает для покрытия всех суток.]

В довершение ко всему, глава Рампочты еще и относится наплевательски к сообществу и исповедует паразитизм, считая, что его должны носить на руках уже за сам факт использования системы. Этика между тем проста: ему дали систему забесплатно, он ничем разработчикам не обязан, но и не имеет права требовать от них ничего, а уж тем более вставать в позу и оскорблять кого-то. Вот если бы помог хоть чем-то (тот же Яндекс, скажем, помогал)... но он хамски требует. И, не получив, уходя, он предпочитает обосрать всех и вся. Может быть, и специалисты из Рамблера сбегают из-за такого отношения руководства?..

Как бы там ни было, потеря уже невелика. "С таким подходом через 3-5 лет Рамблером не будет пользоваться никто, кроме маргиналов". Прощай, Рамблер! А мы пойдем дальше разбираться со своими проблемами сами.

Каковы проблемы 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% юзеров).

<Jay> source-based linux distro невозможен, ибо у них нет базовой системы
<Jay> без отдельной БС оно превращается в кашу легким движением руки
<Kaltmann> возможен, если там сделают БС и будут её поддерживать именно как БС
<Jay> ну все дистры так и делают, только не говорят, что у них есть БС
<Kaltmann> Jay, но это проблема не только source-based, но и бинарных
<Kaltmann> Jay, ну, в смысле, чтобы был атомарный апгрейд БС
<Jay> ну да, иначе первый же апгрейд glibc разрушит цивилизацию
<Jay> так что, те, кто говорит, что в линуксе нет БС и это хорошо — врут :)
<Jay> в любом живом дистре она есть, только про нее юзеры не знают

Монолитная базовая система, которую оппоненты предлагают поделить на тысячу маленьких пакетов "как в Линуксе". То есть, по сути убрать такое разделение, как "база" и "пакеты". Единственное ли это решение? Нет, конечно. Обратимся ко всем другим ОС, кроме Linux, и обнаружим, что понятие базовой системы, а не только ядра, существует везде. Даже в Windows (отдельно компоненты системы, отдельно приложения).

Но как именно она в них сделана? Посмотрим, скажем, на Solaris. Там имеется несколько довольно крупных, но пакетов, из которых и состоит базовая система. В этом смысле солярка похожа на фрю — во фре при инсталляции тоже можно выбрать distributions. И, как и во фре, они крупные и по умолчанию ставятся не по отдельности, а наборами. Пакетный менеджер в солярке, правда, ужасающ, всё еще хуже чем во фре. Для полноты картины солярка была упомянута, всё, теперь о солярке можно забыть.

На самом деле, монолитность базы — достоинство. В начале года в Фидо _slw подробно — см. http://groups.google.com/group/fido7.ru.unix.bsd/msg/b2e9414abbbe17eb — расписал плюсы и минусы единой базовой системы и системы, разбитой на пакеты. Про минусы (не только базы, но и пакетов) уже много кто объяснял подробно, поэтому я их просто перечислю, чтоб были под рукой:

1. Для изменения состава базы систему можно только пересобрать с опциями src.conf, при этом никакой информации о составе и поддерживаемых фичах скомпилированной системы в бинарном виде не сохраняется, нельзя бинарно обновить любой кастомный вариант, даже просто собранный из сырцов с опциями по умолчанию -STABLE.
2. Жесткая зависимость имени файла пакета от фич, которые туда причем кодируются лишь иногда. Нет способа определить, с какими опциями собран пакет.
3. Жесткая привязка к имени файла в зависимостях пакетов, что означает и жесткую привязку к конкретной версии.
4. Собственно, из привязок к имени вытекает много других неудобств, например, дурацкие конфликты между вариантами одного и того же пакета, геморрой при обновлении кучи пакетов (обновление одного может повлечь за собой пересборку почти всей системы).
5. Нельзя модифицировать пакет без правки базы пакетов вручную, в том числе невозможность штатного обновления/замены пакетов.
6. Всё то же самое с базовой системой, плюс отсутствие связок между базовой системой и пакетами — например, пакеты (/usr/local) прямых зависимостей от базовой системы не имеют, как и от её конкретных фич из src.conf (так что легко сломать по неосторожности в кастомных конфигурациях).
7. Требующие более глубоких изменений, но и менее актуальные проблемы с ветками (как HEAD/STABLE, так и samba34/samba35) и devel-ветками, версиями и devel-вариантами (это которые хедеры/дебаг и т.п.), альтернативными репозиториями (и их приоритетом). То есть с тем, что требует более одного измерения, не только лишь category/progname.

Гораздо более интересно, однако, помнить о тех плюсах, которые предоставляет концепция базовой системы. Их мало, но они большие:

1. Release engineering. Система представляет собой не кучу софта, а действительно систему — все её компоненты находятся в согласованном состоянии. Версии ядра и утилит между собой при обновлении останутся согласованы между собой. Ситуация, когда из-за апдейта по частям что-то отваливается, например сам пакетный менеджер на середине процесса, невозможна. Кроме того, согласованность означает тестирование — базовая система поддерживается командой, которая следит за качеством. Nota Bene: Согласованность не сводится только лишь к преимуществу апдейтов, этот принцип универсален — любая система есть нечто большее, чем простая сумма её компонентов (впрочем, здесь слишком мало места, остается только отсылать к философии и системному анализу).
2. Сравнительная комплектность и унифицированность. После установки имеется набор софта, пригодный для определенного класса задач, при этом он будет доступен в каждой инсталляции FreeBSD — всегда можно ожидать наличия ssh, tcpdump и ряда других полезных утилит. На это можно опираться. Здесь невозможна ситуация, когда, приехав на объект, можно обнаружить, что предыдущий админ не установил что-то элементарное, поскольку при установке нет проблемы "что выбрать из сотни галочек", особенно для новичка. По целому ряду инструментов никогда заранее не знаешь, пригодятся ли, поэтому лучше их иметь на всякий случай. Я видел, например, инсталляцию Gentoo, где не было никакого почтового агента, и об ошибках в егоcrontab сообщения валились на мой релей сети, а не его машину.
3. При размытии границ между базовой системой и пакетами, кроме усложнения выбора, легко может возникать ситуация сложных и запутанных (для админа) зависимостей, которые притянут много лишнего (канонический пример — 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.
• 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 пакетов можно получить обобщением системы зависимости от опций сборки, для чего еще необходимо делать возможность сборки нескольких пакетов из одного порта (идея совместно с b_a_t); это глобальный knob типа WITHOUT_X11. Пример же проблемы devel-пакетов: когда glib имеет perl в R-deps, но сам этот скрипт на перле необходим только лишь для сборки зависимых от glib портов — а так perl прописан у glib в R-deps и требуется всегда.

Добавлю один коммент:
Поскольку мы уже в "яме", то надо использовать то имеющееся, что привлечет к нам больших и толстых потребителей. Нужно использовать те сферы, где мы имеем некие общепризнанные преимущества. Таковыми я вижу следующие.

1. Лицензия BSD, которая позволяет "клятым проприетарщикам" жить чуть более спокойно в юридическом плане. Прекрасно подходит производителям в сфере embedded-решений. Здесь нам важно уметь собирать базовую систему и порты без лицензий, требующих открытия кода. Крайне желательно оставаться еще и равнофункциональными при этом.

2. Инфраструктура ядра для сложных систем хранения (ZFS, HAST, GEOM). Надо занимать нишу NAS/SAN-решений, пока есть возможность. А она пока еще есть. Solaris и его клоны находятся в подвешенном состоянии. Реализация ZFS под Linux имеет проблемы с юридической чистотой. BTRFS пока еще тоже не вышла на уровень ZFS. У нас есть примерно год (максимум). Хорошо бы сейчас выкатить "коробочное" решение для создания отказоустойчивого iSCSI-сториджа (два компа с дисками в ZFS-ных рейдах, реплицируемых HAST'ом и отдаваемых наружу по iSCSI с автоматическим переключением ролей).

3. Инфраструктура ядра для сложных сетевых конфигураций (netgraph, carp, ipfw). Я все еще считаю, что ниша роутеров и железок для анализа трафика и управления им - наша. Потому что у нас есть простые и понятные средства для этого. Хорошо бы тут взять тот же pfSense и попробовать договориться с кем-то из производителей (Netgear, D-Link, etc) на выпуск серии железок с freebsd внутри.

Как видно, основная сфера, где надо окапываться - это embedded (NAS'ы и роутеры). Тут преимущества пересекаются больше других. Хотя тот же панасоник, например, выпускает телевизоры с freebsd.

Остальной рынок я пока вижу слабо. На роль сервера приложений мы пока не катим. И единственная возможность в эту нишу прийти - killer-application для STCP.
С другой стороны, FreeBSD - вторая рекомендуемая OS после Solaris для PostgreSQL. Учитывая, что доля PostgreSQL поднимается, а доля Solaris - снижается, можно бы приложить определенные усилия, чтобы стать первой рекомендуемой OS. Это касается, в том числе, и поддержки привычных средств разработки и отладки.

Но кроме этого надо сделать одну большую работу, без которой ниша FreeBSD схлопнется совсем быстро. Нужно стать поддерживаемой всеми популярными средствами (пара-)виртуализации. То есть, КРАЙНЕ НЕОБХОДИМЫ работающие актуальные утилиты и драйвера для "гладкой" работы в гостевом режиме в Citrix XenServer, VMWare vSphere (ESXi), Microsoft Hyper-V и т.д. Вот сюда бы я в первую очередь вложил средства FreeBSD Foundation и силы разработчиков. Без этого мы умрем очень быстро.

Про режим хоста для виртуализации я пока ничего сказать не могу. Этот рынок мы уже упустили и догонять его пока не стоит. Лучше предложить что-то актуальное и стройное чуть позже (благо уже есть некоторый задел). Пока достаточно довести jail'ы до сравнимого с OpenVZ состояния.

В целом, у нас еще есть время, но его уже достаточно мало. Надо принимать решения и начинать действовать прямо сейчас.