> http://www.openbsd.pw/files/wiki_openbsd_ru/%D0%9F%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4%D1%8B/c2k10-henning.html
> http://undeadly.org/cgi?action=article&sid=20101115091138

Хеннинг Брауэр (henning@) был моим вдохновителем с тех пор как я начал использовать OpenBSD. В misc@ есть несколько человек к которым я прислушиваюсь. Сообщения Ника Холанда всегда очень поучительны и информативны и также я стараюсь читать Хеннинга. Его сообщения всегда "в точку", авторитетные и часто смешные. Когда вы встретитесь с henning@'ом и узнаете его получше, вы поймёте что он обладает отличным чувством юмора, на тот случай, если это не очевидно из misc@. Он старается брать от жизни всё, даже если что-то пропускает. У него есть шрамы и костыли чтобы доказать это. Ну, что не убивает тебя...

Читайте дальше чтобы узнать почему он является моим вдохновителем и какая связь может быть между пивом и демонами:

Хеннинг начал использовать OpenBSD с релиза 2.7; очень популярный релиз для многих разработчиков. Примерно в тоже самое время, только после 4 лет проведённых в качестве программиста, он создал свой собственный ISP. Некоторое время спустя сначала открытия своего дела, он был подвержен неприятной атаке на один из своих линукс серверов. После этого он попробовал другие BSD в поиске вариантов. Он повторил эту атаку на FreeBSD и OpenBSD, последняя справлялась с атакой гораздо лучше. Ему не понадобилось много времени, чтобы осознать что OpenBSD подходит для его нужд лучше.

Спустя два года, в 2002, он сделал свой первый коммит в качестве разработчика OpenBSD и более 90% его коммитов осели в src с тех пор. pf(4) был причиной его аккаунта. В то время ipf испытывал серьезные проблемы с производительностью, по крайней мере в его конфигурации, т.к. он наблюдал 100% загрузку центрального процессора. Потом появился pf, но он был менее стабилен, менее целостен и не имел хорошей документации. Он думает что является первым человеком который испытал pf в большой конфигурации и в результате этого он видел крахи спустя секунды после загрузки. После того как Даниель Хартмейер (dhartmei@) внёс исправление над которым он и henning@ работали вместе, henning@ рассказал в misc@ о своём успехе и получил ответ от Тео с приглашением на хакофон. После этого pf заработал намного стабильнее чем ipf и он наблюдал только 10% загрузку центрального процессора на том же компьютере на котором он наблюдал 100% использование центрального процессора до перехода на pf.

Когда я читаю обо всём том что henning@ сделал для OpenBSD, можно подумать что он родился вундеркиндом и по крайней мере один из его родителей был программистом, но это не так. На самом деле когда он начал хакать pf, он имел только базовые знания о Си. Он говорит что отсутствие хорошего знания Си имеет свои преимущества. Он говорит: "OpenBSD - это лучшее сообщество для изучения Си". Одно из его недавних выступлений был посвящён безопасному программированию OpenBSD way.

Ключ к включению в участие в OpenBSD заключается в том что надо найти что-нибудь что интересует вас и работать над этим до тех пор пока не удастся починить. Или по другому: найдите что-нибудь что вам очень нравится. Тео и другие не могут сказать над чем вам надо работать. Они знают в каких областях они могут помочь, также они знают какие аппаратные ресурсы могут помочь ускорить процесс разработки и на этом всё. Мы знаем как henning@ был вовлечён, но что движет им продолжать улучшать OpenBSD? Ему нравится тратить своё свободное время на вещи которые доставляют веселье. Звучит слишком просто, верно? Однако же, не все из этих вещей забавны.

Брет Ламберт (blambert@) говорит: "разработчикам нравится удалять калифорнийские сорняки 20 летней давности из ядра". Исправление проблем требует колоссального количества усилий и чувство успеха которое по обыкновению приходит после исправления является большой составляющей мотивации. Как бы то ни было, когда вы затерялись в коде 20 летней давности с неприятными проблемами, вскоре вы понимает что всё это невесело. Есть два типа боли и есть разница между ними. Перепроектирование намного сложнее и менее приятно нежели разработка чего-либо с чистого листа. Хорошим примером этого является перепроектирование pf(4) по сравнению с написанием bgpd(8), в оба henning@ был вовлечён.

Переработка pf началась в 2005 году на пароме в Канаде. Сначала было пару лет простой эволюционной разработки и несколько мучительных лет внутренних изменений pf. После мучений переработки pf стали возможными видимые (прим. с точки прикладной точки зрения, т.е. для пользователя) изменения. Наоборот, с bgpd всё было намного веселее, проще и менее мучительно чем перепроектирование pf. Однако, несмотря на боль переработки pf, он говорит, что это того стоило. Работа над демонами была для henning@'а облегчением боли. Конечно, bgpd также помог решить проблемы с которым он сталкивался на работе, но это была возможность отдохнуть от мучений с pf'ом.

Интересный факт связанный с созданием bgpd, то что он (henning@) думал написать нового демона, но это будет выше его сил. После нескольких бутылок пива совместно с Тео он сделал неосторожную вещь, сказал что он хочет переделать демона маршрутизации. Когда я услышал эту историю до меня дошло почему распитие [алкогольных] напитков занимает большую часть в процессе разработки OpenBSD. Да, пиво хорошо для разработки. Оно является причиной добавления новых демонов в OpenBSD в каждый новый релиз.

Хакофоны также являются уникальной особенностью OpenBSD и то каким особенным является сообщество разработчиков, по крайней мере применительно к henning@'у. Ежегодно он участвует в хакофонах, больших и малых. Можно часто услышать от него "Я здесь чтобы хакать и хурлить" (прим. развлечение заключающееся в распитии пива). А что остальные? Он говорит что они лучшая группа людей которые только есть вокруг и что он бы ездил на хакофоны только чтобы пообщаться с этими людьми даже если бы он не умел программировать. Это так здорово что они рядом.

Он продолжает: хакофоны очень важны, так как они позволяют понять общую картину и проработать детали. Это место где вы можете не бояться делать значительные изменения. Да, и это не как не связано с частотой нажатий на клавиши (прим. здесь автор даёт понять что иногда не всегда можно увидеть по частоте коммитов о том что идёт какая-то интенсивная работа). Хеннинг обычно много времени тратит на дизайн перед кодированием. Хорошим примером этого может быть то, как он разработал bgpd. Он использовал метод чёрного ящика, но у него был примерный дизайн в голове, вплоть до API. Перед тем как начать кодировать его, он написал буферный фреймворк который находится в его [демона] основе, сейчас фреймворк imsg используется многими [openbsd] демонами, также как и фреймворк логирования [bgpd/log.c]. Только после всего этого он написал движок обработки сессий который может взаимодействовать с другими BGP реализациями, но при этом ничего не маршрутизирует. Теперь, когда у него было что показать остальным, он отправил свои труды нескольким людям среди которых оказался Клаудио Джекер (claudio@) который принял подачу и к концу декабря того же года у них было нечто работающее. bgpd в конечном итоге был добавлен в релиз 3.5 OpenBSD благодаря пиву, боли и совместным усилиям henning@'а и claudio@.

Не то чтобы это был Рейк Флоетер (reyk@), на другом хакофоне также во время распития местного напитка известного среди разработчиков как Трад, henning@ вновь, шутя с остальными, сказал что им следует переписать ntpd следуя OpenBSD way. Он сказал что может сделать всё сетевое волшебство пока кто-нибудь другой сможет сотворить магию управления временем. Тут же родился мини проект. К сожалению, разработчика сведущего в управлении временем не оказалось в наличии долгое время и Хеннингу пришлось делать и то и другое. Хорошо что он был в режиме облегчения боли (прим. здесь автор имеет ввиду то что для человека было отрадой работа над чем-то новым, вместо переделки старого). В конце концов ему помогли другие разработчики помогли завершить ntpd демона и релиз 3.6 ознаменовался появлением ntpd. Другие NTP реализации были сложны, но ntpd Хеннинга был простым и маленьким.

Спросите почему он помог улучшить dhcpd (включая dhcp клиент и dhcrelay), он говорит что другие [dhcp демоны] перегружены [функциональностью] и не имеют штампа OpenBSD в виде техник разделения и аннулирования привилегий.

С лета 2002 года henning@ поработал над pf, bgpd, ntpd, zlib, dhcpd, mopd, httpd и многим чем ещё.

В виду того что henning@ приложил свои руки к разработке такого количества демонов, я решил спросить его о том какой совет по разработке программного обеспечения он может дать другим. "Когда делаете изменения, неплохо иметь общее представление о самом изменении и обдумать его". Он обычно разбивает большие сложные проблемы на несколько простых. Он говорит что лучше всего записать их и потом превратить в Сишный код. Однако, добавляет он, прежде чем записать надо сначала выдержать [идею] в голове перед превращением в код. Интересно что после того как всё сделано она [идея] забывается. Также если первоначальный дизайн плох, то выбросьте его и начните с чистого листа. Впрочем он подмечает что писать новый код, например bgpd, намного проще нежели изменять существующий код, но переделывание это не [новое] решение, за исключением если оно сделано в несколько малых этапов. Не стоит и говорить что у вас будут ошибки.

Вот что henning@ говорит, о том чем он занимался на c2k10:

====

 У меня не было много планов на c2k10.  Я хотел пройтись по нашей базе
 данных отчётах о проблемах, и поискать проблемные отчёты связанные с pf'ом
 и сетью, и исправить их большую часть.  Я решил pf'овские проблемы, но
 они были простецкими.

 На повестке дня была починка pflog.  Я рассчитывал что это займёт у меня
 2 или 3 дня и смогу вернуться к своей работе по реорганизации сетевых
 интерфейсов в красно-чёрное дерево - прохождение пакетом односвязного
 списка является дорогой операцией если в система имеет много интерфейсов.
 Я даже до этого не добрался, я даже не закончил с pflog.

 pflog немного странен в том смысле что мы передаём живой mbuf (прим. 256
 байтный буфер на которые разбивается обрабатываемые сетевые пакеты, то
 что mbuf называется живим по-видимому говорит о том что ядро работает не
 с копией буфера, а с единственным экземпляром) (на самом деле цепочку)
 внутрь, над описываемым пакетом в данный момент времени работает pf для
 передачи его bpf, а bpf в свою очередь передаёт её в прикладное
 пространство что в свою очередь означает что нам не желательно (я бы даже
 сказал "нельзя") изменять данный mbuf.  Перед переделкой NAT кода, у нас
 было всё в порядке.  Всякий раз когда меняется адрес, который мы пишем в
 mbuf практически сразу же, перед тем как передаём его в pflog.  Тем не
 менее, код pflog изменят живой mbuf.  Мне кажется это неприемлемым.  Один
 из многих недостатков непосредственной перезаписи адреса то, что мы
 должны отменить эту операцию позже когда окажется что мы отбросили пакет
 и нам надо "процитировать" часть его данных в ICMP ответе.  Всё это
 приводило к ошибкам и они находились у нас не раз.  Не говоря о том что
 это медленнее чем переписать его позже и единожды.

 С новым NATом мы можем делать такие действия как nat и rdr более одного
 раза.  Это делает менее осмысленным копирование заголовков обратно при
 каждом изменении [mbuf].  Более того, теперь когда действия nat-to и
 rdr-to теперь составляют неотъемлемую часть набора правил без отдельного
 этапа заранее, сама собой пропадает точка в который надо делать обратное
 копирование заголовков перед передачей их в pflog.

 То что происходит сейчас с pflog, и то над чем я работаю сейчас, так это
 то что мы передаём ему mbuf ПЕРЕД копированием.  Мы регистрируем mbuf с
 оригинальными адресами и номерами портов.  Починка этого может быть
 причиной позднего логирования, но это конфликтует с другим изменением
 которое мы хотим [реализовать]: когда мы попадаем в правило match log, мы
 хотим залогировать сразу же с адресами видимые pf'ом после применения
 правила.  Мы не можем сделать этого для pass правил, потому что последнее
 правило под которое подпадает пакет является действующим и мы не можем
 логировать в промежуточных pass правилах...  не можем изменить этого
 [поведения] без того чтобы ухойдакать те множество развёрнутых систем,
 поэтому мы не будем [этого делать].

 Итак моя идея: bpf выполняет копирование в любом случае.  Подключив
 переписывание [адреса] и копирование в него, и обработка копии в bpf у
 нас в кармане.  Первым шагом к этому был рефакторинг кода, снова.  То
 есть вытаскиваем настройку структуры pf_pdesc из [функций] pf_test и
 pf_test6.  Мы получаем это вне зависимости от изменений pflog, делая код
 более прозрачным и простым в обращении.  На самом деле, когда Райн
 инспектировал мой дифф, он подозвал меня к экрану, указывая на
 последующый код pf_test, и спросил можем ли мы объединить 4 копии [mbuf]
 в одну...  выходит что мы можем это сделать.  Это было ещё больнее чем я
 думал.  Поэтому дифф который я разослал остальным назывался pain.diff.

 Следующим был этап в bpf'е который всегда приносит проблемы.  Я сделал
 собственную функцию копирования и новую точку входа в bpf для pflog,
 чтобы мы могли ею воспользоваться.  Я расширил эту функцию возможность
 перезаписи.  Я получаю один mbuf во время подключения к области хранения
 bpf, после вызываю pf_setup_pdesc и pf_translate над ним.  Вообще это
 работает, но имеется баг (баги?) которые надо найти и раздавить.  Я не
 закончил.  Как только это будет сделано мы можем логировать pf'ом тотчас
 же на правиле match log, как описывалось ранее.

 После, мне надо вернуться к организации сетевых интерфейсов в
 красно-чёрное дерево...

 [Примечание Марка: henning@ закончил работу над pflog по "моментальному
 логированию" на j2k10 в Японии и добавил некоторые другие интересные
 штуки.]

====

Henning

Сейчас вы сидите и размышляете могли бы вы стать разработчиком OpenBSD или нет, мне хочется надеяться что henning@ станет вашим вдохновителем. Если вы думаете что никогда не станете разработчиком, но вы приверженный и благодарный пользователь, тогда есть другие пути чтобы помочь проекту OpenBSD помимо покупки футболок, постеров и компакт-дисков или передачи пожертвований. Я уверен что Джейсону Макинтайру (jmc@) можно помочь с подготовкой документации, Нику Холланду (nick@) можно помочь с www.openbsd.org и undeadly можно помочь с числом редакторов. Проект движется вперёд потому что люди, такие как henning@, jmc@, nick@ и многие другие которым не безразличен [проект] и они делают что могут чтобы сделать его лучше. Просто присоединяйтесь и измените что-то. Спасибо Хеннинг тебе за всё то что ты сделал и продолжаешь делать для сообщества OpenBSD. Мы очень благодарны тебе.