Некоторому моему софту ведь уже не мало лет

Что: acf047419cebf9be9e625dc0d6bbfd2c11123c4e

Когда: 2025-01-14 16:24:10+03:00

Темы: bass go memories nncp python redo

Некоторому моему софту ведь уже не мало лет

http://www.stargrave.org/Software.html
Как-то переходя по всяким ссылкам в Geminispace, обнаружил, что куча
народу использует (или, как минимум, играется) с NNCP. И BBS-ки какие-то
делают и чисто для sneakernet-а и какие-то автоматизированные службы
поверх него. Размеры примеров, описаний и документации чуть ли не больше
чем у меня написано для него. А ведь я про NNCP проект вообще не
вспоминаю и даже в его TODO давным давно не заглядывал.

Использую я его каждый день и косвенно: через него ходит почта между
моим мобильным компьютером и сервером, и напрямую вызывая nncp-file для
сброса данных на домашний сервер. Его offline/sneakernet возможности не
помню когда в последний раз использовал, хотя изначально только для
этого проект и создавался, не имея TCP-демонов никаких. БОльшую часть
его возможностей/команд не использую вообще и, скорее всего, даже не
смогу их уже хотя бы перечислить. Но приятно видеть что у кого-то он
зажигает желание и тему флоппинетов. А существует проект с 2016-2017-ых
годов ведь уже. Вот, правда тестами, он покрыт слабо. Вообще никак не
покрыт интеграционными. Что стыдоба конечно, но... seems to work not
only for me :-)

Если спросить о самом моём любимом проекте, который больше всего
нарадовать не может, то с ходу хочется сразу же сказать про goredo,
созданном в 2020. Но это, видимо, потому что меня redo система так
впечатлила и я яростно презираю любые проявления Makefile-ов. А goredo и
в рабочих и вне рабочих и чисто сисадминских делах применяется не то что
ежедневно, а ежечасно, как минимум. И он хорошо покрыт тестами и в него
я чаще всего заглядываю за эталонным шаблоном то одного, то другого. Не
один рабочий проект redo тоже использует: причём некоторые коллеги
используют первый попавшийся им redo (apenwarr/redo который) и ещё ни
разу не возникло проблем с "совместимостью" написанных целей.

GoVPN, с которого началась моя страничка свободны проектов, давно не
поддерживается и официально заброшен. Вообще мне нужен был WireGuard, но
его не существовало на тот момент. А потом кроме функций чисто VPN-а я
надобавлял и всяких censorship-resistant вещей, неотличимости от шума и
прочих свистоперделок just-for-fun. Судя по новостям, именно их многим
пользователям не хватает в VPN решениях. Но мне настолько обрыгла вся
эта тема, что просто перестала был даже любопытной. Если бы прямо сейчас
мне надо бы было обернуть WG во что-то похожее на другое или неотличимое
от шума, то я бы вновь поднял udpobfs проект. Причём я его написал,
опять же just-for-fun, за один день что ли и уже забыл всё ли там
приемлемо или просто зашибись хорошо работает. И заворачивал WG через
него. Точно помню что proof-of-concept у меня работал. Но потребностей
не возникает в таких решениях.

Хотя до GoVPN я, как минимум, не один год участвовал в Inquisitor
проекте (65fe816f376f6e899232d66889f9cfb9cfe0c808) -- собственно, моей
первой полноценной профессиональной деятельностью. Да, я начал
зарабатывать деньги на исключительно свободном ПО :-). Но с
исчезновением компании, да и потери интереса к проекту, он заглох, даже
официальный сайт уже протух.

Только написав про GoVPN, я вспомнил, что вообще-то моя профдеятельность
началась с создания крипто-маршрутизатора. Звучит громко, но по факту
был взят m0n0wall и я люто много модифицировал его PHP-based framework
для того, чтобы каждый порт маршрутизатора можно бы было использовать
для любых целей, а не прибитыми гвоздями WAN/LAN/DMZ. Плюс был добавлен
netflow сборщик и визуализатор его журналов, CARP, что-то касательно
IPsec. И ведь где-то это даже было выложено в открытом доступе, но уже
забыл и саму площадку. Первые свои деньги я не то что на свободном ПО,
но на FreeBSD получал! И продавался он очень хорошо, насколько мне
говорили. Потому что just-works и имел хороший набор фич.

Увидел упоминание ETConf проекта: мои первые шаги в Django и вообще
Python. Эта система конфигурирования серверов при покупке, где
аппаратные компоненты между собой были взаимосвязаны как-то хитро. Умел
выгружать XML-ки в online-магазины и ещё что-то умел. Вроде его
использовали где-то и даже после закрытия компании.

Совсем недавно мне сообщали что до сих пор ещё имеются пользователи
OpenSAN. А ведь мы его закончили что-то типа в 2011-2012-ом годах. В это
проекте я был уже типа team lead-ом и имел подчинённых. Это
OpenWRT/LuCI-based SAN система. Год мы писали в основном на Lua. По сути
то просто WebUI для конфигурирования штатных Linux-овых LVM2, mdadm,
iSCSI-related вещей и всего подобного. После ухода из компании интереса
этот проект мне не представляет. Сам я и руками могу управлять
хранилками. Ну и тогда мы ещё не трогали ZFS. А в том OpenSAN, который
использовал mdadm, был write-hole вообще-то.

Часть написанного мною софта не используется из-за перехода на ZFS.
Часть из-за того, что я перестал писать на Python. Быстрый шифратор
файлов gohpenc теперь проще заменить age-ем.

До сих пор используются и применяются активно PyGOST и GoGOST на работе,
так как ГОСТовой криптографии у нас на каждом шагу, а реализаций на этих
удобных языках нема. Созданы они были ещё в 2015-ом. Но вне работы я бы
их и не использовал.

Больше всего вопросов из всех проектов я получал по PyGOST-у. Так как у
нас, похоже, безопасность вовсю основана ещё и на сокрытии чётких
описаний форматов, инструкций и протоколов, поэтому это регулярный
геморрой. PyGOST даже в каких-то "научных" статьях/изданиях засветился.

Особых чувств к *GOST у меня нет -- ну просто реализованные алгоритмы,
самый большой набор, с хорошим покрытием тестовыми векторами. Без
сильной оглядки на производительность.

PyDERASN для меня являлся эталоном скорости и качества моей работы. Это
наверное самая тщательно протестированная программа, самая вылизанная из
мною написанных. Две недели с утра до вечера с 9 утра до 9 вечера,
отвлекаясь только на обед и туалет, писал всё это. И к концу был готов
не только сам рабочий код, но и документация и 100% покрытие тестами, а
также перевод наших двух огромных многолетних проектов с pyasn1 на
PyDERASN. Вот это именно подобную работу я считаю за 100% своего КПД.

Сейчас же он у меня такой, что хочется уйти из ИТ. Задавался ещё
вопросом таким: может быть написание ASN.1 кодека это в принципе то
задача, пускай и ёмкая, но не сложная и поэтому её просто как на
конвейере монотонно можно было выполнять? Не то чтобы там много раздолья
для архитектурных решений или чего-то подобного. Может быть поэтому и
нельзя мерить свой КПД относительно такой задачи? Ответа не знаю.
Возможно это я пытаюсь себя так успокоить. Но вот например
проектирование (без написания кода) KEKS (бывший YAC) формата
сериализации у меня заняло больше времени, хотя я бы не сказал что
филонил или ленился или у меня голова не была полностью сосредоточена на
задаче.

К сожалению, так как от Python я держусь как можно дальше, использую я
PyDERASN крайне редко, да и то в составе других утилит, типа
pretty-printing-а ASN.1 файлов. Да и желание держаться подальше от ASN.1
тоже держит этот проект от меня подальше. Написан в 2017-ом и
существенно, с момента своего двухнедельного написания, не
переделывался. Как и серьёзных багов там было найдено что-то типа
одного, да и тот, который бил по рукам только нас, а не тех кто
использовал бы библиотеку вместо pyasn1. Давно никаких изменений в него
не вносилось просто потому, что там нечего делать, всё закончено, фичи
не нужны.

GoCheese создан в 2019-ом, как злобный ответ всем Python-истам на тему
того, что у них ничерта не было работающего и достаточно простого
кэша/прокси для pip/PyPI пакетов. Проще было быстренько написать
подобное на Go. Кто-то мне писал что оно используется и не только в
нашей компании, делали bugreport-ы. У нас оно до сих пор применяется,
как и у меня дома, как минимум, при обновлении yt-dlp :-). Пока API PyPI
не меняется, то оно just-works, more than good enough. Совершенно ничего
сложного в проекте нет, но я до сих пор удивляюсь почему аналогичное, в
стократ большее кол-во Python-истов, не могло написать.

SGBlob движок написан аж пять лет назад. Прежде мой блог был банальным
родным Git WebUI интерфейсом к репозиторию в который я пишу.
Web-интерфейс SGBlob частенько даже я сам использую: чтобы смотреть
записи сгруппированные по заданным темам. Их ведь на данный момент уже
5650 (не считая приватной веточки, недоступной публике), и искать многие
вещи становится утомительным занятием. Блог у меня становится всё более
критичной для меня копилкой технических знаний/заметок, как и дневником
моей жизни, в котором практически всё происходящее отражается.

Не раз мне писали, что кто-то читает блог через его gemini:// версию,
которую я добавил just-for-fun, хотя Gemini протокол я прям не люблю.
Кто-то читает даже его gopher://.

go.cypherpunks.su/recfile библиотеку, как и recfile формат я полюбил в
2020-ом. И NNCP и goredo его в нескольких местах используют. Совместно с
linksexp утилитой, из него генерируется страница со всякими закладками:
http://www.stargrave.org/Links.html в разных форматах. Он же
используется и как формат хранения сообщений в моём самописном
Mattermost клиенте. Наверняка где-то и ещё его применю, но сам по себе
он не быстрый по скорости десериализации, хоть и простой. В goredo от
него избавился в пользу бинарного кодирования.

go.cypherpunks.su/tai64n появился в том же 2020-ом, ибо мне понравился
этот формат от DJB. Как и идея самого TAI, а не не-монотонного UTC.
TAI64 external формат за исключением вывода в журналах, по аналогии с
daemontools, применяется на работе в моих криптографических протоколах,
и в KEKS кодеке. И дальше будет только больше.

Про массу других проектов я вообще не вспоминаю, но на деле использую
чуть ли не каждый час. И в них почти не появляется изменений, так как
just works. paster регулярно на работе используется для обмена с
коллегами code snippet-ами или файлами (когда-то был у нас SSH/NFS
shared сервер, но после переездов исчез, а использовать JS-driven говно
-- пошли в жопу). linksexp запускается каждый раз при обновлении списка
RSS/Atom лент и ссылок, а это чуть ли не каждый день бывает. feeder
используется по несколько раз в день: через него я получаю и читаю все
RSS/Atom ленты. Ничего удобнее и гибче я не использовал. Все эти
Newsboat и подобное: забыл как неприятный сон. zeasypki используется для
управления всеми моими TLS сертификатами, которых у меня 330+. zdns-ом я
генерирую файлы с DNS-зонами, никаких ручных правок. galgen генерирует
альбом с "мясными" обложками: http://www.stargrave.org/images/meats/1.page.html
которые у меня собирались со времён института, а точнее появления
160Kbps ADSL Интернета. sgmon мониторит моит сайты и прочие службы,
сегодня вот громко показывая как, действительно, шатался web в рунете:
https://habr.com/ru/news/873606/. dmon-ом регулярно смотрю кто ест
трафик. dht-bootstrap у меня по умолчанию используется для DHT
bootstrap-а в моём BitTorrent клиенте btrtrc (никаких других клиентов, с
момента написания, не использую).

Ищу через glocate я не каждый день, но аккуратно всегда поддерживаю его
индекс в актуальном состоянии. glocate мне запомнился уймой потраченного
на него времени и не тривиальной для меня задачей дико ускорить поиск и
экономно хранить данные (adca349bb86d9ed357051d2452c1a4f9dff24f7c).
Тестов нет, но на практике не заметил косяков или проблем. И аналогов
подобному ZFS-integrated решению я не знаю, прям killer утилита. Нужна
мне не часто, но когда нужна, то нарадоваться не могу её функционалу.

Когда-то казавшейся дикой, идею использования HTTP/HTTPS-proxy/terminator
перед броузером я реализовал в кратчайшие сроки в 2021-ом. С тех пор все
броузеры (и RSS/Atom feeder) ходят в web через него:
    % l ~w/tofuproxy/state/certs W
    31475
почти 32 тысячи сайтов я посетил за это время и сохранено ~78k
сертификатов. Из крупных изменений помню добавление поддержки просмотра
WARC файлов. В основном это был либо ни черта не работающий Python софт,
либо что-то слишком крутое на Java, либо ещё и JS-supported. Думал что
задача не из простых, но вышло вполне рабоче, хотя я даже не каждый
месяц .warc какой-нибудь подключаю, скорее создаю на всякий пожарный.
Ну и tofuproxy у меня ещё и для просмотра Geminispace служит: туда я
только через него ходил, ибо иногда какие-то ссылки ведут. Плюс он ещё и
всякие современные форматы изображений позволяет показывать любому
броузеру. Это и точка аутентификации, TLS клиент с кучей наворотов,
DANE, HTTP sanitiser, показыватель картинок, gemini-клиент, блокировщик
всяких нехороших сайтов. Тот ещё комбайн. Которым очень доволен, ибо его
хоть и вижу каждый день, но не замечаю.

И в том же 2021-ом я написал и собственный web-сервер. Используя конечно
массу готового функционала из родных Go библиотек. С того дня, с момента
написания и переезда, я жалел только о том, сколько времени я тратил на
возню с lighttpd. Нет, он мне нравился, в отличии от nginx, к которому
прям отвращение сравнимое с systemd испытываю. Но надо было куда раньше
делать web-сервер под свои нужды/удобства/желания. Документация lighttpd
зачастую паршива -- информация только в их wiki.

И ведь уже меньше месяца остаётся как BASS проекту исполнится год.
Возможно лет десять я думал о том, чтобы автоматизировать и упростить
возню с пакетами на моей системе. И так уж вышло, что и на работе задача
по детерминированной сборке возникла, и для кросс-платформенной CI
системе нужны пакеты/софт -- и всё это внезапно для меня превратилось в
систему сборки и (простым) управлением пакетами. И я всё равно не ожидал
что реально огромную часть софта я на своей системе переведу в BASS
(бывший zwoki). И что это более чем отличным рабочим решением окажется,
да ещё и столь минималистичным по коду. Проекту ещё и нет года, но мой
компьютер, как и некоторые проекты на работе, уже немыслимы без него.
Однако я не пытался его пиарить и громко где-то рассказывать. Хотя по
сути у меня нет ни TODO для его кода, ни known bugs. Так сказать,
никакого community (в отличии от NNCP) в нём нет.

Ну и наконец я питаю большие надежды на KEKS кодек. Но о нём я нигде не
говорю громко, ибо пока очень неспешно к нему дописываются тесты. Сам по
себе он уже применяется на работе (в том месте, где даже не очень
протестированная реализация пока допустима). Но уже возникает чувство,
что надо бы с тестированием ускоряться и добить его. До сих пор
удивляет, но реально просто нет детерминированных streaming-friendly
кодеков. Точнее нет таких, где бы была приемлемая реализация. CBOR по
описанию очень похож на то что хотелось, но на деле с его реализациями
всё крайне паршиво. Поэтому проще было считать что нет никакого CBOR.

К чему-то у меня пропал интерес, но у других людей остаётся и
поддерживается. Что-то перестало использоваться по ненадобности и это
удручало. Что-то дико нравится, но не находит восторга у других. Что-то
внезапно быстро доходит до точки "больше тут нечего делать", всё
тип-топ. И заранее точно ни про что не мог бы сказать в какую
"категорию" та или иная программа попадут.

А ещё есть много кода написанного в ivi. Не знаю как там сейчас, но
вроде в последний раз знакомые мне говорили что серьёзные пласты там мои
так и остались работать по сей день. Вроде бы, как и сервер
аутентификации/авторизации, так и написанные на Go прокси-серверы
раздачи самого контента. Последние точно менялись существенно, но,
говорят, что основа всё равно осталась прежней. Хотя ведь уже больше
десяти лет прошло и компания во много раз выросла. Если софт не
переписали с нуля, хотя он точно должен был требовать изменений и
поддержки, то, видимо, неплохо архитектурно устроен/написан был. И это
речь только про то, что голой попой в Интернет торчит. А ведь ещё массу
всего я писал во внутренней Django-based админке, в которой суммарно
наверное под две сотни тысяч строк было.

А с исчезновением Сирийской Арабской Республики, канет в небытие и
проект в котором я плотно участвовал не один год и помогал там с
внедрением в 2019-ом. Как быстро летит время!

=> оставить комментарий

Сгенерирован: SGBlog 0.34.0