Я Дмитрий Маракасов, разработчик свободного программного обеспечения. Я пишу в основном на C++ и Python, участвую в разработке FreeBSD, интересуюсь пакетными системами, переносимостью ПО, разработкой свободных игр, а также улучшением и продвижением экосистемы свободного ПО, железа и данных в общем и целом. Контрибучу во всё до чего дотянутся руки.

Неполный список важных проектов в которых я участвую или участвовал:

Примерно обо всём этом я и пишу в этом блоге.

Последние посты

История коммита: добавляем новую опцию в Doxygen

Я использую Doxygen для генерации документации для одной из своих библиотек, libSDL2pp. Однажды, просматривая оную документацию я наткнулся на интересный факт: мой email в сгенерированном HTML был изменён до неузнаваемости, очевидно в целях помешать спам-ботам собирать адреса. Меня такое поведение категорически не устраивало, а в Doxygen не было настройки чтобы его отключить, поэтому я решил её добавить. Вот так выглядит изменённый email: То же в HTML (отформатировано для читаемости): <a href="#" onclick="location.

Python 3.11 в портах FreeBSD

Месяц назад я добавил в порты FreeBSD Python 3.11 (alpha2). Это продолжение моей работы над поддержкой (пререлиза) Python 3.10, и, как и с предыдущей версией, целью является дать возможность заинтересованным поиграть с новой версией языка, мантейнерам проверить совместимость своих портов, а разработчикам - своего кода. Хочу рассказать про статус поддержки и про то как был портирован Python 3.10. Статус Python 3.10 Поддержка Python 3.10 пока далека от полноценной, так как эту версию языка пока не поддерживают многие критичные пакеты (в основном по причине устаревших версий в портах, но есть и случаи отсутствия поддержки в upstream).

Пакетопригодность: нежелательные флаги компилятора

Иногда возникает желание добавить в сборку по умолчанию несколько полезных флагов компиляции типа -Werror (чтобы гарантировано исправлять предупреждения компилятора) и -march=native (чтобы собирать более эффективные бинарники). На деле это сулит проблемы при создании пакетов.

Писать большие посты трудно

Работа над азбукой переносимости как-то подзаглохла, и причина тому скорее всего в попытке откусить слишком большой кусок, а именно написать сразу огромную статью, да ещё и на двух языках. Сейчас две такие статьи в черновиках, работы до публикации они требуют ещё много, и это демотивирует. Поэтому пробую сменить формат на небольшие посты. Это не помешает собрать их потом в книгу, а писать станет проще. Помимо этого, думаю над изменением названия. Всё-таки тема ближе к опакечиванию чем к переносимости (хотя это и связанные вещи).

Азбука переносимости: именование проектов

Удивительно, но можно насоздавать проблем для переносимости и пакетирования ПО проекта даже не написав ни строчки кода, а просто неудачно его назвав.

Выбирая название для проекта, убедитесь что оно однозначно, уникально и совместимо с распространёнными ограничениями на именование пакетов, иначе есть риск что пакет вашего ПО или устанавливаемые им файлы будут называться совсем не так как вы задумали (чтобы избежать конфликтов, соответствовать требованиям при создании пакетов, или просто потому что вас недопоняли). В результате пользователи столкнутся с трудностями при поиске, установке и использовании вашего ПО, а автоматизированные инструменты (например уведомители о новых релизах или уязвимостях) не будут работать. Вдобавок, такие изменения скорее всего будет различаться от репозитория к репозиторию, что усложнит миграцию между дистрибутивами, поломает переносимость зависимых скриптов и приложений и применимость документации.