NetBSD: Интервью с разработчиком
На одной истории с OpenBSD и Вячеславом Воронцовым мы конечно же не остановились, на этот раз в гостях у нас ещё один яркий и интересный представитель сообщества BSD.
Рассказ пойдет о системе NetBSD, потому что у нас в гостях Алексей Чеусов — самый настоящий разработчик NetBSD.
Видео
Выкладываем как обычно везде где только можно, сам ролик:
На других платформах: Youtube, Rutube.
Интервью
Ниже вас ждет текстовая версия интервью с Алексеем в литературной обработке, это не дословный перевод всех реплик из видео.
По той простой причине, что мы «художественных ПТУ» не оканчивали и общаемся в жизни далеко не на литературном русском.
Как и в прошлый раз, ради большей эпичности, будем использовать наши ники в сети для выделения реплик:
Собственно и автора и гостя можно легко найти, вбив ник в любую поисковую систему.
Алексей Чеусов
Алексей — программист-математик с большим опытом, работающий с NetBSD с 2006 года, действующий ментейнер в нескольких крупных открытых проектах, отвечающий за большое количество пакетов в pkgsrc.
Контакты
Телеграм: @convs_prog
Github: https://github.com/~cheusov
Youtube: https://www.youtube.com/@convs_prog
Блог: https://dzen.ru/convs_prog
Если видели прошлые ролики, думаю догадываетесь что будет дальше:
я буду снова задавать дурацкие и обывательские вопросы, Алексей будет давать умные комментарии и ответы.
Мы кстати идём по самому центру Питера и помимо умного разговора о высоком, вы еще увидите офигительно красивую картинку (в ролике).
С погодой нам тоже сегодня сильно повезло, так что сейчас будет круто и красиво.
Занимаюсь программированием с детства, зарабатываю этим примерно с девяносто шестого (1996).
Люблю, знаете ли, железки поковырять.
Алексей на самом деле скромничает, потому что он фактически самый настоящий математик, учёный. Закончил профильный математический ВУЗ и собственно говоря по основной работе занимается математикой.
При этом является активным коммитером NetBSD, у него есть специальная почта в домене netbsd.org.
Еще Алексей активно выступает на конференциях с докладами как по математическим темам, так и по BSD-шным.
Короче, это весьма известный, опытный и интересный человек.
Когда мы делали ролик про OpenBSD, я там говорил «ваш шанс встретить живого пользователя OpenBSD на улице примерно равен шансу встретиться с космонавтом».
Так вот с NetBSD всё ещё круче, поскольку это еще более редкая система.
Ну да, я сам из Минска, из Беларуси. Родился, вырос там.
И в моём окружении, честно сказать, никто NetBSD не использует. OpenBSD встречается в наших кругах куда чаще.
Я в последнее время жил в Кутаиси и на одной тусовке местных экспатов встретил пользователя OpenBSD.
Это было очень неожиданно. Мы с ним тут же, за игрой в настольные игры поспорили, какая из BSD лучше.
мало того, что мы BSD-шники, так ещё и встретились в узком кругу экспатов в Грузии.
Почему NetBSD
Расскажи, почему именно NetBSD?
Как часто бывает, это случайность :)
Гостил у своих приятелей из Sam Solutions — компания в Минске, где до сих пор существует отдел UNIX-разработки. Хотя сейчас уже Linux-разработки, в основном.
Увидел у них болванки — FreeBSD, NetBSD, OpenBSD.
Начав с FreeBSD, которая у меня.. упала и развалилась. Причём неоднократно, так что с ней у меня не задалось.
После чего поставил NetBSD 2.02. Как сейчас помню, это был 2006 год. К тому моменту я уже был знаком с Линуксом много лет.
Так что NetBSD — моя вторая Unix-подобная система.
И с NetBSD как-то у меня пошло.
Пошло во-первых, по технической части.
Она мне понравилась, всё заработало, всё было очень просто и понятно. NetBSD какая-то такая.. стабильная оказалась.
Дальше пошло общение с людьми, с разработчиками:
Thomas Klausner, Christos Zoulas, Alistair Crooks, David Holland.
Все эти ведущие разработчики NetBSD, с которыми пересекался, с ними пошло нормальное общение.
И я как-то увлёкся этим делом.
Ну и «прилип» не только к технике, но и к этим всем людям, которые показались очень интересными.
NetBSD и демократия
Когда готовился к этому ролику и начал собирать материал, оказалось что сообщество NetBSD — гораздо более.. демократично устроено, нежели другие, более известные и популярные из BSD.
Например, каждый коммитер может выкладывать патчи для любого пакета.
Расскажи как вообще у вас сообщество устроено, в чём отличие от «кровавого диктата» Тео в OpenBSD?
Одна из причин, почему я не использую OpenBSD и считаю эту систему непригодной для жизни, это откровенный «фюризм».
OpenBSD это система одного человека, как он сказал, так и будет.
А в NetBSD всё устроено совсем по-другому.
Там есть Core Team, который принимает взвешенные решения по спорным вопросам. Cостоит, насколько помню из семи человек.
И в случае возникновения каких-то непримиримых споров, все решается коллегиально. Туда кстати входил в прошлом и Валерий Ушаков из Питера, ваш местный товарищ.
Состав Core Team меняется и соответственно меняются поколения разработчиков.
В общем, как-то так всё происходит, более плавно.
Никто не уходит обиженным, в отличие от других экосистем, где всё устроено несколько по-другому.
В NetBSD все сильно лучше в этом плане. Но тотальной «демократии» здесь совершенно точно нет, всё гораздо интереснее.
В FreeBSD на самом деле тоже есть Core Team, размером по-больше, человек 15. Но в любом случае там нет такого, что любой коммитер может отправлять патчи в любую часть системы или набора пакетов.
Про общие пакеты
Если мы проанализируем самых популярных ментейнеров пакетов в pkgsrc, увидим там почтовый адрес @pkgsrc-users:
Это отнюдь не означает, что пакет бесхозный.
Это означает, что человек создал пакет, добавил в базу, но не берёт на себя труд по сопровождению этого пакета, по его поддержке.
И любой человек, с оглядкой на сообщество, на этот список рассылки @pkgsrc-users, может сюда коммитить.
Все это приводит к тому, что откровенно бесхозных пакетов нет.
И получается, что пакеты движутся вперёд более активно, чем если бы один человек уснул или там, не знаю, нарожал детей, ушёл в запой а пакет стоит без движения, без апдейтов все это время.
На самом деле, «не ушёл и не нарожал детей», чаще всего просто времени не хватает на все это у людей.
Самая частая причина, что просто сильный завал по работе и все — ребят, извините, не тяну.
По крайней мере во FreeBSD это самая частая причина, по которой меняются ментейнеры.
Точно не «идейные разногласия».
История с тостером
Сейчас мы развеем наверное самую известную байку про NetBSD — насчёт её реальной кроссплатформенности.
Расскажи эту историю про NetBSD на тостере:
Yesterday at LinuxWorld 2005 I ran into Jake Appelbaum and he mentioned that upstairs in up the .org Pavilion there was a toaster that was powered by NetBSD (the first open source version BSD, a Unix-like operating system). John Mc and I went up there and found the candy apple red toaster that was being controlled by NetBSD, and it actually made toast.
Очень известная история, ставшая для обывателей визитной карточкой NetBSD.
Думаю эта байка повторяется каждое десятилетие. И по-моему это какая-то глупость, которую стоит перестать повторять.
Если подходить к вопросу объективно, то все операционки стремятся быть перенесёнными на всё что движется.
NetBSD естественно это тоже касается, но это не означает что она лидер в данной области.
лидером по портируемости является Linux и уже очень давно.
И если уж мы выбираем операционную систему, то на мой взгляд совершенно не по этой причине.
Я например выбрал NetBSD совершенно по другим причинам. Точно не потому, что она якобы такая переносимая.
Про поддерживаемые архитектуры
История с количеством поддерживаемых архитектур.
Насколько понимаю, всё не настолько глобально как кажется обывателю? Из огромной массы поддерживаемых архитектур только примерно половина — активные, остальные просто есть в списке.
В NetBSD есть три категории поддерживаемые систем:
- Tier I: Focus — support is part of NetBSD's strategy
- Tier II: Organic — evolving at its own pace
- Tier III: Life Support — severely incapacitated or broken
Tier I поддерживается активно, туда входит x86 ясное дело, ARM, MIPS.
Вторая категория — всякие устаревшие SPARC, ALPHA и PowerPC.
И третья категория, то что вероятнее всего отвалится, потому что некому поддерживать. Не потому что эти архитектуры не нужны, а просто потому что это некому поддерживать.
Что касается целесообразности поддержки всяких Sony PlayStation 2 и прочей экзотики, как-то в рассылке видел забавный аргумент, когда разработчики обсуждали, нужно ли им поддерживать старый хлам.
Один из разработчиков NetBSD выдвинул следующий аргумент:
нам не столько нужен этот условный Sony PlayStation 2.0, сколько факт, что на нем все тоже работает.
А если это не так, значит мы сделали что-то неправильно.
Так что поддержка большого количества архитектур, при условии работоспособности, однозначно доказывает, что с точки зрения дизайна операционной системы всё сделано верно.
И вот для этого портируемость очень важна и очень нужна.
NetBSD и драйвера
От себя добавлю, что в NetBSD очень интересный подход к поддержке железа. Фактически там нет концепции драйвера устройства, но есть «фреймворк» для их создания, внутренний.
И когда создается код для поддержки конечного устройства, он пишется так чтобы его можно было применять на разных архитектурах.
Ну да, это упрощает поддержку железа на разных архитектурах.
Но ооочень сильно усложняет саму разработку, потому что когда попытался что-то портировать из FreeBSD — концов просто не нашёл.
NetBSD и pkgsrc
Поскольку Алексей в основном занимается поддержкой пакетов, он — ментейнер очень большого их количества в pkgsrc, про пакетную базу может рассказать много чего интересного.
Давай начнём с достаточно известного факта:
пакетная база pkgsrc на самом деле кроссплатформенная и все пакеты собираются под кучей разных систем.
Расскажи как это все происходит.
NetBSD тут лишь одна из целевых платформ для сборки пакетов, с поддержкой разных архитектур.
А у самого проекта pkgsrc одна из главных целей — поддержка разных операционных систем.
Поэтому если создал пакет один раз, сборка потом работает и под Линуксом и под MacOS, и под Solaris и под Minix и так далее — под «всем что движется».
И это на самом деле работает, это ключевой момент.
Этим проект pkgsrc радикально отличается от всех остальных пакетных систем, знакомых юниксоидам.
pkgsrc без root
Ну и вторая фича pkgsrc, которая мне кажется очень важной:
Это так называемый unprivileged-режим, непривилегированный режим.
У меня есть много своих разработок, которые приходится тестировать на разных аппаратных архитектурах и разных операционных системах.
Тестирую я все это на большом количестве систем, куда у меня есть удаленный SSH-доступ, но без привилегий суперпользователя.
Для тестирования нужен какой-то набор софта на целевой машине, а поскольку нет прав суперпользователя — не могу установить все необходимое из родных для целевой системы пакетных систем.
Так что я устанавливаю все необходимое pkgsrc в домашний каталог, никого при этом не дёргая по поводу доступа.
Расскажи про свою рабочую систему, ведь на самом деле ты — очень редкий вид пользователя, поскольку у тебя NetBSD используется непосредственно на рабочей станции, в качестве основной ОС.
Что из софта используешь, как это вообще выглядит?
Emacs наверное какой-нибудь?
Ну я «админ локалхоста», но очень опытный.
А в целом, я — разработчик и больше занимаюсь программированием.
Ну как больше, я 100% времени занимаюсь программированием, а не администрирую что-либо.
Поэтому да, у меня NetBSD на десктопе, одна из систем.
В основном у меня там используется Emacs, urxvt — форк rxvt с поддержкой Unicode и довольно древний window-менеджер ctvm, который меня вполне устраивает.
для разработчика window-менеджер или так называемый «desktop environment» никак не улучшает производительность.
Поэтому хватает столь древнего window-менеджера, который недавно в NetBSD сделали устанавливаемым по-умолчанию, внеся его в базовую систему.
Пользуюсь им наверное с начала двухтысячных годов.
История с дедушкой Керниганом и awk
Насколько знаю, ты часто отправляешь патчи для разных открытых проектов, в том числе для awk. Из-за чего у тебя случилась интересная история с Брайаном Керниганом.
Когда про это услышал — очень сильно удивился.
Если вкратце, то я очень много в свое время писал на awk.
Напомню, awk — такой язык программирования, хотя и примитивный, но весьма могучий.
Ну и когда писал на нём очень активно, сталкивался с проблемами в реализации для NetBSD, что реализация не соответствует POSIX.
То тут, то там.
Или просто какой-то баг присутствует.
Я этих багов накопил штук 13, ну и зная что в NetBSD используется реализация Брайна Кернигана, написал непосредственно в upstream — самому Кернигану письмо:
дяденька, поправьте пожалуйста вот тут, поправьте вот там, тут у вас баг.
Ответ от него был довольно забавный, в стиле:
Мальчик, иди отсюда. Это не баги. Моя книга была написана до этого вашего POSIX, поэтому это не баги, это фичи!
Зато в NetBSD все эти замечания приняли и внесли исправления. В целом awk был очень сильно поправлен в NetBSD благодаря моим багрепортам.
Ребят, если кто не в курсе, я сюда вставлю ссылки, кто такой этот Брайан Керниган.
Это очень хороший и известный дядька, конечно же.
Я учился по его книгам. Но оказался в жизни немножко злобным, хотя это и неудивительно.
Собственно, это один из авторов языка Си, один из авторов UNIX.
Фактически исторический персонаж, по уровню события — как если бы вам ответил лично Билл Гейтс.
Проект mk-configure
У тебя есть ещё интересные проекты, например mk-configure.
Есть такой, да. Система сборки.
В своё время меня достал «autoshit» так называемый, или «autobloat», в миру autotools.
Достал тем, что крайне неудобен в использовании. Да и честно говоря, over-engineering там откровенный, между нами и девочками.
Я решил, что в принципе против кодогенерации в проектах подобного рода. Это там не к месту, как мне кажется.
Ну и решил, что вариация make из NetBSD — bmake вполне пригодна для того, чтобы реализовать аналогичный функционал.
Например проверку на существование в системе какой-то функции.
Сделаем запись на фоне этого замечательного места, на память.
Храм Воскресения Христова на крови́ (Спа́с на Крови́) — православный храм-памятник в Санкт-Петербурге, сооружённый на месте, где 1 марта 1881 года в результате покушения был смертельно ранен император Александр II (выражение на крови указывает на кровь царя).
Про autotools
Немного прерву Алексея, чтобы вы понимали контекст.
Autotools — самая глубокая, самая большая жопа, связанная со сборкой проектов со времён создания языка C.
Не преувеличивай, autotools появился чуть позже.
Ну хорошо, тогда с начала девяностых.
В общем это самая грязная, самая вонючая куча говна, с которой все бегут.
Если вы сделали сборку проекта на этой штуке — гореть вам в аду, что тут скажешь.
Вот этот человек (кивает на Алексея) настолько крут, что попытался создать заменяемый аналог autotools.
Ещё чуть-чуть добавлю для обывателей.
autotools нужен для того, чтобы сделать проект переносимым на разные платформы — на Solaris, AX, *BSD, на линукс и так далее.
Для того, чтобы сделать приложение на С или С++ портабельным, очень часто возникает необходимость проверки на то, есть ли в системе нужная системная функция и в случае если нет — подставить собственную реализацию.
mk-configure это проект, который это же реализует, но при этом гораздо проще и меньше по объёму чем autotools.
Построен на базе make из NetBSD (bmake), который сильно отличается от более известного GNU Make.
Про NetBSD make
Кстати bmake недавно добавили во FreeBSD и в DragonflyBSD.
Так что из NetBSD тоже время от времени что-то растаскивают по другим проектам.
В FreeBSD и так уже свой вариант make, это получается ещё один.
Если сравнивать make из NetBSD, OpenBSD и FreeBSD — тот, который был раньше, то честно говоря, вариации make из OpenBSD и FreeBSD вообще ни о чём.
Ими нельзя пользоваться.
Ну прямо совсем неинтересно. bmake значительно богаче по своим возможностям.
NetBSD и nvmm
А какие фишки именно NetBSD ты чаще всего используешь? Что из нового есть интересное?
Ну например в десятую версию добавили nvmm.
Это штуковина, которая позволяет запускать виртуальные машины без существенной потери производительности.
Гипервизор уровня ядра, вроде KVM в линуксе.
В десятке это наиболее значительная вещь, как мне кажется.
Садишься за FreeBSD и руки трясутся от того, что что-нибудь сейчас развалится. Файловая система полетит или что-нибудь выдаст Segmentation Fault. Садишься за какой-нибудь Solaris и думаешь:
Боже, какое убожество.
Хочешь сказать, у тебя и Солярис ещё остался?
Ну я по ssh к нему захожу и тестирую свои разработки на Solaris, в том числе. SSH-доступ у меня есть на десятку, на девятку и на одиннадцатую версию.
А это какой именно Solaris? Современный или что-то историческое?
Есть 10й и 11й на SPARC, это уже Oracle Solaris. Еще есть доступ к Illumos — вчерашний OpenSolaris.
Про старые UNIX
Поддержка портабельности это то что стараюсь делать и в своих личных проектах тоже.
Для меня слово Unix значит гораздо больше, чем слово Linux для некоторых.
Поэтому все что я делаю, переносимо вплоть до Соляриса, десятого точно.
До портирования на AIX ещё не дошел, есть SSH на такую систему, изучаю особенности системы.
Это очень специфичные системы, которые находятся в режиме глубокого сопровождения, если и выпускаются патчи, то только патчи безопасности.
А точно не развивается вообще?
Остатки разработки как HP-UX так и AIX перенесли в Индию. И сейчас все это находится в режиме сопровождения.
Ну это дорогущие коммерческие системы, коммерческие юниксы, что с ними будет дальше — не знаю.
NetBSD для новичков
Допустим, кто-то сейчас захочет использовать NetBSD — что ему делать?
Как во всю эту историю входить?
Ну для начала смириться, что NetBSD это не Linux.
Если вы привыкли в линуксе к чему-то, то вам придётся признать, что BSD — любая BSD и NetBSD в частности это не Linux.
Например, там нет вашего любимого systemd. Привыкайте к тому, что его там нет и не будет никогда.
NetBSD и rc-скрипты
В NetBSD в 2000м году придумали rc.d.
До этого был просто rc или rc.local, куда руками вписывался запуск необходимых демонов в нужном тебе порядке.
Так вот, в NetBSD сделали rc.d, который тогда же, примерно в начале двухтысячных годов перенесли в FreeBSD.
Так что фрибздшная система скриптов запуска взята изначально из NetBSD.
По-моему, используется там до сих пор.
Она намного проще, чем допустим система скриптов запуска в Линуксе и в Солярисе. И на мой взгляд намного приятнее.
Если бы был адептом Линукса, я бы туда rc.d втащил и был бы счастлив. На самом деле существуют дистрибутивы с таким rc, вроде Slackware Linux использует такую систему скриптов.
NetBSD и флешки
Ну от systemd честно говоря сам не в восторге, зато вам в NetBSD втащили DBus не так давно. Я его там точно видел.
Ну, меня он пока не беспокоит, честно говоря.
Ну а как USB-диски подключать? Или ты вручную монтируешь?
Я всю вручную монтирую, я старпёр, извините.
Ну в FreeBSD это всё живёт уже очень давно. Там, слава богу, от HAL (Hardware Abstraction Layer) избавились, оставили только DBus.
Честно сказать, флешками вообще практически не пользуюсь. При наличии интернета зачем таскать что-то на флешках?
Какие-то физические устройства и на них что-то записывают — я этого не очень понимаю.
То есть у меня проблемы такой нету.
Ну я как-то вот не сталкиваюсь с необходимостью что-то втыкать в свой компьютер, если честно.
Вот мы сейчас видео пишем, часть придётся перебрасывать как раз через флешки, потому что оно всё большое.
Алексей и языки программирования
Насколько понимаю, набор языков программирования, которые ты используешь — очень и очень большой.
Расскажи подрастающему поколению.
В разное время я писал на разном.
Начинал с Pascal. Если взять совсем с детства, то начинал с Focal, BASIC и машинных кодов.
Уже потом, в университете, писал на Паскале.
Первая работа на госконтору была на Turbo Pascal 7.0, от Borland.
Потом C, C++, всякие скрипты, awk, шелл-скрипты, Ruby, Java, Коtlin.
Самый няшный из перечисленного — Kotlin.
Спрашивал Алексея заранее насчёт Scala. Как-то так получилось, что Scala при всем этом он обошел стороной.
Про функциональное программирование
Все эти Haskell, они конечно применимы в узких нишах, но для реального использования это всё не годится.
Как-то так сложилось, что я сталкиваюсь с задачами, требовательными к производительности и не могу защищать диссертации по алгоритмам, изобретённым в шестидесятые, пытаясь «натянуть уже на ежа».
Я не буду делать функциональщину там, где мне давно известен императивный алгоритм.
Не буду это делать, поскольку меня просто уволят за такое, если если вдруг не справлюсь.
Kotlin и NetBSD
Кстати, а Kotlin и NetBSD у тебя получается сочетать? Работать с Kotlin непосредственно в NetBSD?
Для разработки на Kotlin использую Linux. Не потому что это невозможно в принципе, а потому что просто слишком сложно и долго компилировать среду разработки Intellij Idea для NetBSD.
А я это сделал! Есть сборка Intellij Idea, которая прям работает на NetBSD.
На момент написания текстовой версии, шла работа по сборке Kotlin на FreeBSD — будет в отдельной статье.
Надо мне это тоже сделать и запакетировать Kotlin наконец.
Алексей и Alt Linux
С линуксом я знаком намного дольше чем с NetBSD и являюсь давним пользователем Alt Linux тоже.
В него я тоже коммичу, на уровне пакетов.
Опыт, получается — глобальный.
Коль у тебя такой глобальный опыт в качестве коммитера, расскажи как вообще это происходит?
Потому что например у меня часто не получается договориться.
Есть много своих наработок, которые хочется людям выдать, но постоянно что-то мешает. Где-то это сложная регуляция, где-то просто людям пишешь, а они не отвечают.
Как у тебя коммуникация выстраивается?
Проект Heirloom
Расскажу одну интересную историю.
Есть один проект, называется Heirloom.
Это набор утилит, написанный компанией Caldera давным-давно, на рубеже веков.
И это один из проектов, который я пакетировал в pkgsrc.
Ну и пока я его пакетировал, естественно возникли вопросы к сборке.
Как уже было сказано, pkgsrc это система кроссплатформенная и собирается на всём.
И среди операционных систем, в которых я был заинтересован, была такая система как Interix.
Это такой древний предок WSL, подсистема Unix для Windows.
Такой был забавный юникс внутри винды, под названием Интерикс.
Автору прислал патчи и говорю:
Слушай, приложи вот эти штуки. Мне для Interix нужно, чтобы оно собиралось.
I don't support Windows. До свидания.
Так что взаимодействие бывает и таким, причем регулярно.
Еще часто сталкиваюсь с линуксоидами, которые не заинтересованы в поддержке чего-либо кроме Линукса.
Такие в последнее время встречаются, в целом этот процесс с патчами — долгий и болезненный.
Но если умеешь с буржуями общаться, если достаточно вежлив — всё получается, так или иначе.
Короче если выдаёте патч для известной системы, который исправляет важную проблему — его примут, с большой радостью и охотой.
Да, это занимает много времени.
Это может кому-то не нравится. Айтишники многие не очень-то любят общаться в принципе.
Поэтому взаимодействовать с людьми, если хочешь что-то добиться, нужно этому учиться. Иногда приходится блин и поуговаривать кого-то.
Еще про pkgsrc
Есть контора называется Joyent, которая взялась в своё время сделать поддержку pkgsrc для Illumos (форк OpenSolaris).
Представляете, под Solaris поддерживается pkgsrc на таком же высоком уровне как и для NetBSD.
В пакетах под Illumos компилируется чуть меньше, чем под NetBSD.
Когда-то проект DragonflyBSD был на на развилке в выборе пакетной системы, они отказались на тот момент (лет 10 тому назад) от системы портов из FreeBSD.
Они пришли в NetBSD и один чувак Jorg Sonnenberger из NetBSD Community в одиночку, примерно за год обеспечил поддержку pkgsrc на DragonflyBSD, причем на очень высоком уровне.
Под Dragonfly pkgsrc собирал больше пакетов, чем под NetBSD.
Так что комьюнити pkgsrc заинтересовано в портируемости всех своих пакетов на все возможные операционки.
человек, пишущий патчи, должен разбираться и в Solaris и в OpenBSD, и в линуксе и делать патч таким образом, чтобы ничего не сломать.
Это сложный процесс, но коммьюнити, которое бережно к этому относится уже сформировалось.
А количество пакетов, пакетная база — сколько примерно?
Точно не скажу, но их намного больше, чем в OpenBSD, хотя конечно меньше, чем в портах FreeBSD.
Что такое WIP
Есть в pkgsrc точка вхождения, называется WIP.
WIP — сокращение от «Work In Progress», т. е. «находится в разработке».
Куда может прийти любой человек.
Уметь коммитить для этого совершенно не обязательно. И в этом самом WIP есть один ключевой разработчик, которого я уже упомянул — австриец Thomas Klausner.
Приходите к нему, заводите аккаунт.
Тут можно поиграться, запакетировать все чего вам не хватает.
Попросите кого-нибудь из девелоперов, например меня ваш пакет проверить и закоммитить в основную ветку. Если он собирается, то все будет хорошо.
Такая тестовая площадка для всех.
Реальное использование NetBSD
Про коммерческое.. даже не коммерческое, а просто реальное использование NetBSD, какие-то проекты, компании — кто использует?
Не слежу за этим делом, мне важнее что эта система нравится лично мне и я её использую.
Но некоторое время назад, лет семь или восемь, случайно узнал, что в Витебский Белтелеком в Беларуси заехало какое-то новое сетевое оборудование.
У которого в руководстве было написано, что в качестве управляющей ОС используется NetBSD.
Реальное использование pkgsrc
А что касается pkgsrc, то уже упомянутая компания Joyent использует его как родную пакетную систему для Illumos, который они разворачивают у себя в облаке.
Так что pkgsrc имеет коммерческое использование, штатные разработчики Joyent довольно активно коммитят.
И они же предоставляют бинарные репозитории pkgsrc для MacOS и для NetBSD.
При этом, насколько понимаю в пакетах pkgsrc есть очень серьёзные штуки, как минимум у вас есть gcc и clang, со всей сложной обвязкой.
Честно говоря вообще не понимаю, зачем так много пакетных систем в мире UNIX.
Ведь запакетировав единожды, хотелось бы пользоваться этим везде — в линуксе, во всех BSD, в MacOS.
Вкладываться условно в Debian означает, что создав пакет для Debian, в OpenSuse его не будет. И в NetBSD его не будет.
Но раз создав пакет для pkgsrc, можно им пользоваться и в OpenBSD и в NetBSD и в линуксе — где угодно. При желании, разворачиваешь в домашний каталог и используешь.
На самом деле история с кроссплатформенными пакетами стара как мир.
Их пытались делать ещё во времена Unix Wars, когда только-только появлялся открытый софт.
И всё свелось в итоге не к технологиям, а к политике.
Потому что тот, кто контролирует пакеты — создаёт ценность для конечного продукта.
Это не вопрос технологии по большому счёту.
Ну не знаю. У меня нет проблем с тем, чтобы отслеживать работоспособность моих пакетов на разных ОС.
Сейчас это работает. То есть как бы цель достигнута и всё работает.
Ну а представь какой-нибудь QT так поддерживать?
Или Chromium тот же самый, там же чудовищная кодовая база!
Поддержка разных версий в pkgsrc
Ну в pkgsrc уже есть много разных пакетов QT, и четвёртый и пятый и шестой. Приходится жить.
Та же самая колбасня с питоном — их поддерживается несколько разных в pkgsrc, одновременно.
Версии 3.9.1, 3.9.2 и так далее.
И Ruby тоже поддерживается несколько разных версий.
Модули для Python собираются в pkgsrc для различных версий питона.
Ну, если кто pip не пользуется или если нужен петон специфичной версии, там 3.1, 3.9, 3.8.
Все это в пакетах, они множатся таким образом.
NetBSD и AI/ML
А кто-то работает с нейросетями, с ML из такого окружения? Из NetBSD?
Насколько Numpy работает под NetBSD не проверял, потому что не пользуюсь.
А почему Numpy? У Pandas же тоже много чего.
В Pandas ничего зависимого от операционной системы нет. А вот работает ли Numpy, где есть такие зависимости — вопрос.
Тут есть некоторые вопросы с переносимостью, больное место.
История про джуна и прод
Расскажи эту шутку про джуна, который тебя оторвал от свидания с девушкой.
Работаю давно, историй у меня забавных много.
Сижу с барышней в пятницу вечером. Ужинаем, с вином. Часов 10 вечера.
Лёша, Лёша, я у тебя баг нашёл!
Какую багу?
я уже починил и выставил в прод..
Честно говоря начинаю охреневать. Какой прод? Какой баг?
Пятница, 10 вечера, я сижу с вином и женщиной.
Начинаю задавать наводящие вопросы.
Нет.
Ты знаешь, что у меня тесты написаны?
Нет.
То есть ты не протестировал свой фикс?
Нет.
А ты знаешь, что у нас есть staging-сервера, на которых тестирование проходит перед выкатыванием в прод?
Нет, не не знаю.
А ты помнишь, что сегодня пятница, вечер?
В понедельник вернёмся на работу, починим.
Ну и в общем, такая вот весёлая история.
Нет, я его не убил. Но свои патчи он откатил.
Я вернулся в понедельник и спокойно разобрался, что он там нашёл.
В результате ошибка была у него и его решение ломало мои тесты. Он принял за баг то, что так и должно быть.
Никакой ошибки не было.
У меня всё было изначально верно, что и отражали тесты, написанные не «на отвали», а по-взрослому.
На большом объёме все было не раз протестировано.
Эпилог
Это было в сериале «Доктор Хаус», когда этот самый доктор Хаус выдал реплику про назначенного им сотрудника, что «он может облажаться в деталях, но я не может облажаться во всём».
С вами был Алексей Чусов, всем привет. Всей BSD-тусовке.
Следующий ролик будет обязательно про FreeBSD, наконец-то я это добью.
Всё господа, всем спасибо, всем пока и до новых встреч!
Выражаем благодарность за помощь с созданием ролика: