Sergey Matveev [Thu, 20 Mar 2025 07:22:37 +0000 (10:22 +0300)]
Всё в ожидании IPv6 сети
Больше недели я написал (f52906a5e4067b2bfc45c054c1cd222dae4d223a)
всяким VPS провайдерам вопрос по возможности предоставления /48 (или
хотя бы /56) сети, SMTP/PTR, SSH и всякого такого. Только один провайдер
у меня остался не спрошенным, но как-то я наверное даже и не буду
пытаться, ибо его собственная родная главная страница находится на
Cloudflare, что уж больно не серьёзно. Ответил удовлетворительно только
deephost.pw.
Я задал вопрос как именно будет предоставляться сеть: по нормальному
через маршрутизацию, как это делает Hurricane Electric или IPv4Market
тот же, или придётся костылять и поднимать NDP proxy. Они сказали, что
по идее NDP прокси, но попробуют сделать по уму, но нужна настройка с их
стороны. Вот уже прошла неделя с момента как я начал с ними общаться. За
это время мне смогли выделить /48 сеть, даже трафик маршрутизируется на
указанный мною IP адрес из отдельной /125 сети. Однако... исходящий
трафик теряется. Пока только в одну сторону есть работоспособность, что
смысла практического не имеет.
Ещё мне необычным показалось то, что vtnet0 интерфейс смотрит в их /32
сеть. Выходит, что все VPS-ки напрямую подключаются к их /32 сети. Как и
широковещательные ARP по полтысячи пакетов в секунду льются. А ещё,
когда я только завёл VPS-ку, то tcpdump показывал полное отсутствие IPv6
пакетов в сети. Как пообщались со мной, то сразу внезапно появился
мультивещательный NDP трафик. Такое впечатление, что IPv6 в принципе был
выключен полностью. А если так долго возятся с моим банальным запросом
на /48 сеть, услуга которая у них вообще на главной странице сайта
показана, то такое впечатление, что я чуть ли не первый клиент у них,
или в их ДЦ в Москве, который запросил IPv6. Грустно это всё.
Если с этим VPS ничего не получится, то я даже не знаю... похоже я
просто буду делить /64 сеть другой VPS на маленькие части и их через NDP
proxy раздавать. Бесит. Где-то в РФ (в вопросах телекоммуникаций) всё
делают state-of-art грамотно и без проблем, но просто так физическому
лицу никто, даже за хорошие деньги, не готов предоставлять услуги,
которые вообще как рекомендуемые (то есть штатные, что должно быть по
умолчанию) в RFC прописаны.
Ну или ещё глубже выяснять вопрос со своей IPv6 сетью и как её где по
BGP можно будет подключить. Само собой я обращусь в какую-нибудь
организацию, которая сделает за меня все юридические процедуры по
регистрации AS и сети. Тут я не особо вижу проблем -- только денег надо
будет заплатить. Но дальше то надо где-то подключиться и анонсировать
эту сеть.
Sergey Matveev [Wed, 19 Mar 2025 07:07:43 +0000 (10:07 +0300)]
Сходил снова на оркестр волынщиков и ирландские танцы
Вот настолько круто слушать и смотреть на City Pipes волынщиков, что уже
третий раз на них не раздумывая пошёл. Но уже в Москве, в большом КЗ
Измайлово. А так как за день до этого был день святого Патрика, до
вместе с шотландской тематикой была группа ирландских танцоров "Celtic Wind".
Когда-то папу уговорил через силу пойти за компанию на City Pipes. Ему
так понравилось, что вообще ни на что больше не ходил из концертов или
опер, кроме как на них. Тётю затащил в прошлом году и в этот раз она,
тоже не долго думая, захотела пойти. Слышны были разговоры других людей
выходящих с концерта "теперь то понял почему мне так нравятся волынки?".
Всё было на ура. Танцоры выступали как и просто отдельно без музыкантов,
только создавая оглушительный ритмичный топот, так и вместе с
барабанщиками City Pipes и вместе со всем их оркестром. Там не просто
параллельно шли танцы и игра на инструментах, а была и хореография между
всеми на сцене, плюс прям шоу (типа театральное). Отличный симбиоз!
В этот раз, в отличии от предыдущих, совсем не исполняли рок хиты.
Но было больше классики старой английской.
В общем, офигенные концерты они устраивают! Ну и симбиоз с танцорами
тоже отлично вышел!
Sergey Matveev [Tue, 18 Mar 2025 08:18:45 +0000 (11:18 +0300)]
AV1 не перестаёт радовать
С одной стороны, AV1, судя по всему, очень и очень сложный, ничего
эстетически красивого в нём нем, плюс вроде бы непонятки с патентами
(впрочем, как и с JPEG XL что ли?).
Но зато на практике без всяких GPU и ускорителей, чисто на CPU, он за
более чем вменяемое время (в отличии от VP9) способен с отличнейшим
качеством и битрейтом пожать видео. За ночь у меня два DVD
перекодировалось в таком же разрешении с -crf 24 и -preset 2 (почти
самый медленный режим), делая 500-600 мегабайтные файлы, в которых я
вообще на глаз даже при ближайшем рассмотрении не могу заметить разницы
с оригиналом (хотя это и так DVD, с относительно мыльной картинкой). А с
YouTube (когда он ещё пускал) я и 20+ Mbps 4K видео в real-time без
проблем проигрывал на нескольких ядрах.
VP8/VP9 или по качеству/bitrate не могут сравнится или по скорости
кодирования. Пока AV1 реально лучший на практике. Всякие H.2xx не хочу
рассматривать.
Sergey Matveev [Mon, 17 Mar 2025 08:14:10 +0000 (11:14 +0300)]
Посмотрел "Зеркало для героя"
https://ru.wikipedia.org/wiki/Зеркало_для_героя
Советский фильм 1987-го о том, как двое людей попадают на 40 лет назад
во времени и каждый день у них повторяется снова и снова. Как "День Сурка",
вот только получаемые ими увечья остаются. Начинается с того, как сын с
отцом поругался, прям конфликт поколений. Но затем он увидел жизнь
своего молодого отца, по другому на неё начал смотреть. Хороший фильм.
Sergey Matveev [Mon, 17 Mar 2025 08:10:47 +0000 (11:10 +0300)]
Посмотрел "Крупный план"
https://ru.wikipedia.org/wiki/Крупный_план_(фильм)
Иранский фильм от их известнейшего режиссёра. Основан на реальных
событиях и в нём снялись сами участники этих событий. Очень необычный.
Куча Тарантино-like крупных планов говорящих людей. Жуть как понравился!
Ну и плюс любо посмотреть как на быт и людей Ирина, так и на их суд.
Sergey Matveev [Sun, 16 Mar 2025 13:36:46 +0000 (16:36 +0300)]
Лабиринт Фотопии
https://ifhub.club/2025/03/15/photopia-as-a-tutorial.html
https://en.wikipedia.org/wiki/Photopia
Photopia очень часто рекомендуется как первая IF игра. И у меня она тоже
была первой, если не изменяет память. Но её реально сложно отнести к
настоящим IF играм, ибо почти никакой интерактивности (просто постоянно
ждёшь продолжения развития сюжета).
Sergey Matveev [Thu, 13 Mar 2025 09:19:39 +0000 (12:19 +0300)]
Хотят избавиться от .su
https://habr.com/ru/news/890452/
https://habr.com/ru/news/890606/
https://dxdt.ru/2024/10/10/14047/
https://ripn.su/news/razyasnenie-o-statuse-domena-su/
Ну блин, приехали. Только я перевёл свои домены с .ru на .su, так вот
новость о том, что хотят от него избавиться. pos.su→pos.ru
Sergey Matveev [Wed, 12 Mar 2025 18:35:55 +0000 (21:35 +0300)]
Прочитал "Последние дни" Типа Пауэрса
https://ru.wikipedia.org/wiki/Пауэрс,_Тим
https://fantlab.ru/work7487
Да, начал читать не первую книгу из "Трилогии сдвигов", но... понял что
это точно не моё. Слишком много непонятной мистики. Через силу дочитывал
только первый том, второй даже не собираюсь.
Sergey Matveev [Wed, 12 Mar 2025 18:15:39 +0000 (21:15 +0300)]
Прочитал "Королеву ангелов"
https://ru.wikipedia.org/wiki/Королева_ангелов_(роман)
Номинирован научно-фантастический роман был на множество премий.
И Грег Бир мне нравится как автор, уже знаком с его творчеством.
Интересное произведение, в котором как в "Криминальном чтиве"
несколько историй параллельно идут, а потом встречаются вместе.
Удивительно что это только в 1990 было написано, ибо уж очень
современно выглядят описания.
Sergey Matveev [Wed, 12 Mar 2025 17:29:50 +0000 (20:29 +0300)]
Поиск IPv6-capable хостинга
Не один час сегодня потратил на прочёсывание на разных сайтах информации
о хостерах всяких. На каждом дальше нужно индивидуально искать у них
информацию о том как (не)поддерживается IPv6. В десяток компаний написал
email с вопросами о PTR, ограничениях трафика и возможности /56 или /48
сетей. Не раз слышал рекомендацию спрашивать об этом, ибо на самом сайте
могут не написать.
Вообще хостеров с поддержкой /64 IPv6 прям не мало. И речь только про
тех, кто есть в РФ. Зарубежные не рассматриваю в принципе. Есть,
конечно, и много кто не поддерживает IPv6, но, похоже, их всё меньше и
меньше. Попадаются такие, кто выдаёт единичные IPv6 адреса и просят
деньги за каждый дополнительный адрес. Бежать надо от таких, бежать, ибо
это это вне всяких норм этики.
Не мало видел примеров настройки IPv6 сети с полноценной маршрутизацией
через fe80::1 link-local адреса. Лично я бы именно так и делал.
Но поиск тех, кто выдавал бы >/64 -- удручает. Среди всех найденных мною
компаний только, среди тех кому написал письма, только с одной завтра
попробую уже на практике что-то сделать, и есть ровно одна про запас,
кто явно говорит про предоставление /48 сети. Возможно кто-то ещё не
ответил из адресатов, но у других или нет IPv6 (хотя по их сайту, где не
мало информации о преимуществах протокола, сразу и не скажешь) или нет
больших сетей.
Ещё есть возможность с собственной AS и сетью прийти, но это пока не моя
весовая категория, так сказать.
Sergey Matveev [Wed, 12 Mar 2025 07:16:26 +0000 (10:16 +0300)]
Никому не порекомендую vpsville.ru
Ну что ж, вот и подходит конец моего использования сабжевого VPS
провайдера. Вчера аж два человека сообщили о недоступности SSH-а
по IPv6 до моего основного компьютера. В комментарии к
(3136e07d90bf973abaf9fda3bad7e343a58c0be6) и ещё один у меня многие
годы хостил jail с сайтом, до которого SSH доступ всегда был только
по IPv6.
tcpdump-ом выяснил, что трафик по TCP 22-му порту полностью резался в
обе стороны на VPS-ке с которой я получаю /48 сеть. Техподдержка только
посоветовала своего демона на другой порт повесить. Извините, а
исходящие SSH соединения, как им это поможет?
* Блокируется SSH трафик в обе стороны
* Нигде не было написано, но PTR запись можно назначить только для IPv4
адреса (25ce76407710dc00ab7e4cbda272f32a83f54300). Сегодня мне
написали, что можно назначить на IPv6 адрес внутри /64 сети, но где ж
вы раньше то были с этой информацией? Или на момент моих настроек даже
для /64 нельзя было прописать. В общем, поднять SMTP сервер для
отправки не выйдет
* Были серьёзные (db38f36c737212f4ec8e82a82acf96586b56ea3b) проблемы и с
входящей SMTP почтой, особенно от gmail.com. Меня уверяют, что они
ничего не режут, так что возможно тут беда в вышестоящих магистралях.
Но весь входящий SMTP трафик я в итоге заруливал через мою старую VPS
* Безграмотное решение для /48 сети. Вся эта сеть просто навешивалась
ими на виртуальный Ethernet интерфейс, а не маршрутизировалась через
какой-то адрес (f1dc900ba79ee0d1f87977c16bfbf61c574bbcdf). Из-за этого
пришлось использовать ndproxy, да ещё патчить, так как на Ethernet-е у
них не только я, но и куча других VPS-ок, которым тоже рассылаются NDP
запросы, на которые мне отвечать не надо
Что-то это какая-то жопа с нашими провайдерами. А точнее с IPv6 в них.
Он на магистралях есть везде -- бери не хочу. У всех моих знакомых, кто
владеет компаниями и закупает Интернет в фирму, на работе -- везде есть
IPv6 и вроде бы без проблем. Но простому физическому лицу это какая-то
жопа получить работающее решение. И, судя по всему, банально из-за
недостатка достаточно квалифицированных специалистов по сетям. Как будто
всех спецов крупные компании переманили к себе, а для SOHO провайдеров
никого не осталось.
Я то, кстати, неработоспособность SSH не замечал, так как у меня до моей
VPS-ки с почтовым сервером проложен WireGuard туннель, через который по
BGP маршрут меняется. Я до своих IPv6 сетей через туннель ходил, минуя
блокировки провайдеров.
Sergey Matveev [Wed, 12 Mar 2025 07:03:38 +0000 (10:03 +0300)]
SFTP-only учётная запись и медленность протокола
https://stackoverflow.com/questions/8849240/why-when-i-transfer-a-file-through-sftp-it-takes-longer-than-ftp
У меня давно есть учётная запись выделенная исключительно под SFTP. Но
раз я в последнее время в блоге про SSH пишу, то просто заметка как
сделать сабж: достаточно прописать в authorized_keys:
А если правильно рулить правами доступа и сделать анонимного
(3136e07d90bf973abaf9fda3bad7e343a58c0be6) SSH пользователя, прописать
аналог restrict,command=internal-sftp в sshd_config, то будет анонимный
read-only SFTP.
Но с ним (SFTP) есть серьёзная проблема производительности. По ссылке к
этой записи автор HPN-SSH патчей объясняет почему с ним всё так плохо.
По сути из-за того, что он самостоятельно делает TCP flow control. Он
также отмечает, что эти HPN патчи применяют:
Google, Yahoo, Apple, most ever large research data center, NASA,
NOAA, the government, the military, and most financial institutions.
Слышал где-то и про Яндекс. А я никогда не пробовал с ними. Да и не
охота: всё равно NFS буду использовать для чего-то серьёзного/крупного.
Sergey Matveev [Tue, 11 Mar 2025 11:36:52 +0000 (14:36 +0300)]
Анонимный SSH+Git
https://gameoftrees.org/code.html
https://gameoftrees.org/gotsh.1.html
https://git-scm.com/docs/git-shell
Как-то я заметил, что в Game Of Trees (реализация Git от OpenBSD
разработчиков) весь исходный код доступен через ssh://-протокол,
анонимно, без регистрации (и SMS), никаких https://. Особо я никогда
не задавался вопросом можно ли "анонимный" SSH предоставить как либо?
Но в их документации на всё это есть намёки. Для "анонимного"
пользователя достаточно выставить в sshd_config (OpenSSH):
Match User anongit
PasswordAuthentication yes
PermitEmptyPasswords yes
DisableForwarding yes
PermitTTY no
ну и убрать пароль у этого пользователя. В качестве shell-а выставить
git-shell, чтобы ограничить его возможности только работой с git-ом.
Создать git-shell-commands/no-interactive-login чтобы явно вообще
запретить интерактивную работу в git-shell.
Я не использую got, но в его gotd можно указать read-only права доступа.
А вот для обычного git-а git-shell-у ничего такого не указать. В
исходном коде git-shell можно закомментировать строчку в командой
разрешающей загрузку патчей, Но я пока решил задачу с read-only доступом
просто помещением anongit в группу git, для которой не даются права на
запись в репозитории.
И я убрал HTTP/HTTPS протокол для Git репозиториев у себя. Это не
связано с моим недавним (3342002daf11a729fc4591577a72b81d8cfda5df)
очередным постом про HTTPS, а просто так совпало по времени. Git и так
есть, OpenSSH и так есть: почему бы их и не использовать для случаев,
когда нужна криптографическая защита протокола? HTTPS излишен. Плюс
никакого PKI не надо, на который намекает TLS.
Sergey Matveev [Tue, 11 Mar 2025 10:29:50 +0000 (13:29 +0300)]
Попробовал всяких азиатских дошираков
Уже множество знакомых, при упоминании Ханой-Москва на Ярославском
шоссе, обязательно посоветуют попробовать их лапшу быстрого приготовления.
Недавно оказался там совсем рядом и попросил знакомого сводить и
посоветовать чего-нибудь эдакого. Похоже там сотни видов всякой лапши, но
почти нигде нет никаких английских подписей. Судя по всему, сложнее
всего найти не острые варианты. Взяли каких-то видов. Попробовал. Ну или
что-то не настолько сногсшибательное взяли, как это описывают другие,
либо я не в состоянии оценить. Вкусно, но не более. Восторга или чего-то
необычного не почувствовал. Хотя и не был прежде знаком с рисовыми
клёцками. Ну и от одной лапши всё-равно рот потом горел. Не нашёл
кардинальных отличий от Доширак/Роллтон. Но часть лапши вроде бы
корейская, не вьетнамская.
Sergey Matveev [Tue, 11 Mar 2025 08:14:49 +0000 (11:14 +0300)]
Firefox форсирует HTTPS использование
http://xahlee.info/w/Firefox_Forces_HTTPS.html
http://xahlee.info/w/why_no_https.html
Не только я недоволен форсированным криптобесием касательно HTTPS.
* you now get a error for sites not sponsored by big corps such as Let's Encrypt.
* this means, billions of small sites are now unreadable. You only get
to read big corp sites.
* forcing https, began by google, is a way to censor the masses and control info.
* in the beginning, google empire mildly suggested it, for so called security.
* then, mysteriously, at the same time some org spring up offering https for free.
* then it gets gradually worse. sites without https shows as insecure
warning sign. scare tactics.
* vast majority of sites are not shopping sites.
* also, vast majority, even coders, making a cert is too much hassle, even free.
* then u get the expire issue, which occurs very often.
* requiring cert, basically force sites to be centralized by a few giant
orgs. (and there is lots war n scam within cert orgs, there's
incident...)
* and, oddly, for so called security of non-credit card sites, they no
sanction self cert.
* and now, basically, firefox begin simply prevent reading of non ngo
sanctioned sites. that's basically billions of sites.
* firefox says it's experimental. of course, they r trying to see how
deep it can go, how coders receives it.
Letsencrypt is a tool of capture to make it easier to censor people by
revoking their access to CAs.
HTTPS and more specifically Let's Encrypt is a power play to control the
internet and prevent counter-culture from forming. By browsers using
scare tactics for enforcing https it puts the control of the internet
into a handful of CAs making you vulnerable to cancelling.
Sergey Matveev [Sun, 9 Mar 2025 17:54:21 +0000 (20:54 +0300)]
Услышал Чеботину
https://ru.wikipedia.org/wiki/Чеботина,_Люся
Были на даче, готовили шашлыки, в колонках был playlist со всякой
нашей современной попсой российской. На одной песне мне прям почти
физиологическое отвращение и неприязнь вызывало что я слышу. Пошёл
посмотреть на экран смартфона, чтобы понять кто это. Я не припомню
чтобы настолько мерзкой и неприятной, раздражающей манерой пения
кто-либо обладал. Хотя я за последние лет десять вроде бы совершенно
спокоен стал ко многому в музыке, даже рэп в целом не вызывает негатива.
Sergey Matveev [Fri, 7 Mar 2025 10:08:58 +0000 (13:08 +0300)]
Yondr на концерте Ghost
https://www.darkside.ru/news/171495/
Снова (6a30d3693577f42c01ed7e5bdf73328a5eb30dfa) новость о концерте, где
запрещены смартфоны. Люто поддерживаю подобное. Я совершенно не понимаю
людей, которые потратили деньги, припёрлись, но смотрят не на сцену с
действом, а в свои смартфоны, ещё и частенько вытягивая их на руках
загораживая обзор сзади стоящим. У меня только один вопрос возникает:
х*ли ты припёрся то вообще? Ты на концерте или где? Тебе надо просто
сделать check-in о том что ты побывал на нём, засветиться?
Вот и исполнители это отмечают: что вместо созерцания довольных рож они
видят только направленные на них плоские объективы смартфонов, что
ломает всю "магию", скрывает людей (которым ты играешь) и обратную связь
от них.
Sergey Matveev [Fri, 7 Mar 2025 08:48:41 +0000 (11:48 +0300)]
Альтернатива GPS
https://lenta.ru/news/2025/03/07/gps-alt/
https://ru.wikipedia.org/wiki/Чайка_(навигационная_система)
https://ru.wikipedia.org/wiki/РСДН-20
США беспокоится о том, что GPS-у то у них нет запасных альтернатив.
В d5354336306e39e53086e7f171b5dc5ad9347ea1 я узнал про "гиперболическое"
позиционирование. И что у нас, кроме ГЛОНАССа, до сих пор функционируют
и наземные системы. А вот космические системы (Парус, Сфера, Цикада,
Циклон) тоже выведены из оборота.
Sergey Matveev [Fri, 7 Mar 2025 08:35:19 +0000 (11:35 +0300)]
You can tune a file system, but you cannot tune a fish
https://man.freebsd.org/cgi/man.cgi?query=tunefs
https://unixhistory.livejournal.com/1808.html
Взято из man-а по tunefs.
.\" Take this out and a Unix Demon will dog your steps from now until
.\" the time_t's wrap around.
.sp
You can tune a file system, but you can't tune a fish.
Sergey Matveev [Fri, 7 Mar 2025 07:38:32 +0000 (10:38 +0300)]
Идеальный рабочий компьютер и домашний сервер
https://ounapuu.ee/posts/2025/03/07/perfect-home-server/
https://ounapuu.ee/posts/2023/10/25/the-optimization-treadmill/
https://www.apple.com/newsroom/2025/03/apple-unveils-new-mac-studio-the-most-powerful-mac-ever/
Свалились ссылки из одного блога о рассуждениях об идеальном домашнем
сервере. Плюс на днях посмотрел на новое железо от Apple.
Когда-то я тоже любил делать "подкроватный хостинг" на отживших своё
ноутбуках. Зачастую у них ломается "мобильность", но системный блок ещё
может продолжать жить. Какое-то время у меня работал GuruPlug: маленькая
коробочка размером с RPi втыкаемая напрямую в розетку, имеющая два
Ethernet-а и eSATA порт. Подобные решения я вообще не рассматриваю как
вариант, даже для маршрутизатора/шлюза и/или NAS.
Нужно, как минимум, 2 или более Ethernet порта. Или, если форм-фактор
позволяет, то несколько PCIe слотов. Собственно, в них можно сколько
надо вставить сетевых карт, это не дорого.
Нужна возможность подключения множества HDD, чтобы это было сразу же и
NAS-ом. Хотя в теории ничто же не мешает разделить NAS от сетевого
шлюза/моста, но зачем? И опять же это намёк на необходимость
использования PCIe для установки SAS/SATA HBA. Не всегда на материнской
плате будет достаточное количество портов.
В нём должен быть всё же более менее приемлемый по мощности процессор и
вменяемое количество оперативной памяти. Когда я был выходной Tor нодой,
хостил Freenet, I2P и всякое такое -- всё это вполне себе требовало
относительно не мало ресурсов. А раз там будет NAS, то это однозначно
ZFS файловая система, которой CPU/RAM не помешают. Одновременный scrub
моих зеркал из 16, 20 и 22 TB дисков отъедает ощутимую часть 6-ти
ядерного Xeon процессора.
Только серверное железо, не consumer grade -- за 25+ лет я убедился, что
надёжность и стабильность работы (без нежданчиков) это не пустой звук и
слова на бумаге, поэтому только серверные процессоры и материнские платы.
Почти всю жизнь в нашей семье были только AMD процессоры: i386 (возможно
i286 тоже), i486, K6-2, K6-3, Athlon -- потому что дешевле. С
приобретением ноутбука появился Intel. Не считая MIPS-ового netbook-а,
дальше у меня только Intel был. Судя по сторонним наблюдениям,
обсуждениям в рассылках: AMD не всегда полностью и до конца
поддерживается в современных ядрах, если речь про виртуализацию и прочие
штуки. Видел в новостях как яростно глючили и были чуть-ли не
работоспособны Ryzen первые, если ничего не путаю. Возможно и с Intel
такие же проблемы всегда были, но вот почему-то в памяти оседает чётко
только про AMD. Плюс Intel chipset-ы и сетевые карты это максимальный
шанс что оно без проблем будет работать не под Windows/Linux, в отличии
от чипсетов для AMD решений. Поэтому я слепо только Intel CPU и chipset
выбираю.
Совсем нет опыта с ARM процессорами. Не прочь бы это использовать и
попробовать, но серверные решения на ARM что я видел -- дорогие, дороже
amd64 based. Либо относительно слабые. Это правда означает низкое
энергопотребление, что тоже хотелось бы, но если оно не может вытягивать
resilver/scrub с полдюжины HDD, параллельно раздавать BitTorrent и всё в
таком духе -- то значит оно уже не выполняет возложенные на него задачи.
Ну и вопрос с совместимостью с ОС: будет ли на случайной ARM64-based
штуке работать FreeBSD из коробки?
Сейчас я уже не хотел бы отказывать от 10GbE сети. И чтобы была
возможность подключения нормальных кабелей (хотя бы DAC), то есть был бы
SFP, а не намертво встроенная витая пара. А это снова означает, как
правило, необходимость ещё свободного PCIe слота.
То есть, по сути мне то на самом деле нужно просто обычный сервер. Но!
Не rackmount, которые, как правило, сильно шумят. Плюс в пьедестал можно
обычные полноразмерные PCIe карты вставлять, в отличии от невысоких
rackmount-ов. Которые ещё и дороже за счёт крепкого корпуса будут, что
не критивно для пьедестальника. И большущие, а значит тихие,
вентиляторы. Вот и автор заметок тоже к этому же решению пришёл.
Решения из ноутбуков или дешёвых одноплатников -- нет, не рассматриваю.
Больше нервов и геморроя и ограничений будет, чем экономии хотя бы
просто на обычном desktop компьютере, куда вставили HDD и NIC
дополнительные.
А каким я вижу идеальный рабочий (мобильный!) компьютер? Да по сути мой
текущий Intel NUC всем устраивает. Ну точнее, да: я хотел бы чтобы там
было server grade железо, но такого или никто не предложит в компактном
форм-факторе или будет дорого (хотя и NUC-то отнюдь не дешёвая штука).
Тут уж без вариантов и надо смириться. Обязательно два M.2 NVMe (можно и
только SATA) порта должно быть (или свободный PCIe слот для этого),
чтобы иметь зеркало, а не единичный диск. Мой NUC этому удовлетворяет.
Было бы полезно иметь SATA кабель, для того чтобы произвольный диск во
время каких-нибудь rescue работ иметь, но для rescue бывает достаточно и
USB enclosure, не страшно. Два сетевых порта: мой NUC из коробки их
имеет, killer-feature. Плюс в свободном PCIe ещё и 10GbE карта
вставлена. DisplayPort вывод должен быть -- HDMI то ещё говно по
вероятности иметь проблемы. Помощнее процессор и памяти побольше
(минимум 64GB) -- это очень хочется на рабочей машине.
Но Intel отдала производство NUC-ов Asus, к которым у меня не такое
доверие к качеству, но с ходу я не могу вспомнить точно моменты где Asus
плохо бы себя показывать. Они делают, насколько помню, насколько
показалось, и ширпотреб и качественные server-grade решения -- широкий
спектр. Вижу что NUC похожего форм-фактора всё же продолжают делать,
хотя в рюкзаке оно уже не уместится, судя по фотографиям:
https://www.asus.com/displays-desktops/nucs/nuc-kits/nuc-13-extreme-kit/
Sergey Matveev [Thu, 6 Mar 2025 06:55:48 +0000 (09:55 +0300)]
Колоссальная коллекция CD-ROM игр типа Фаргуса
https://rutracker.org/forum/viewtopic.php?t=6560175
https://my.abandonware.ru/
Подборка на 3.5TiB образов дисков с играми от уже не существующих
компаний типа Фаргуса, Седьмого Волка и подобных. Фаргус -- это прям
моя молодость. Именно эти диски были на прилавках всех магазинов и в
основном только подобные и приобретались.
Sergey Matveev [Tue, 4 Mar 2025 09:50:26 +0000 (12:50 +0300)]
Tutorial по git-send-email
https://git-send-email.io/
https://git-am.io/
Там даже есть пометки относительно Proton Mail:
Protonmail does not support the open, industry-standard protocols
necessary for git send-email to work out-of-the-box.
Be advised that Protonmail is generally known to be a pretty bad
email host. They will munge up your outgoing emails and your patches
may fail to apply when received by the other end. Not to mention
their mistreatment of open source and false promises of security!
You should consider a different mail provider.
Sergey Matveev [Tue, 4 Mar 2025 05:40:18 +0000 (08:40 +0300)]
Кратчайшая история появления IP протокола
https://linkmeup.ru/podcasts/2761/
Понравилось:
[00:14:36.140 --> 00:14:38.520] Сегодня IPv6 поддерживается большинством крупнейших
[00:14:38.520 --> 00:14:41.080] интернет-компаний, хотя, конечно, есть и ретрограды,
[00:14:41.080 --> 00:14:42.780] которым милее работать через коктейли из костыли
[00:14:42.780 --> 00:14:45.400] и синей изоленты, образовавшиеся в результате эксперимента
[00:14:45.400 --> 00:14:49.160] 50-летней давности.
Sergey Matveev [Fri, 28 Feb 2025 14:03:46 +0000 (17:03 +0300)]
Ещё разные способы шифрования файлов. Kryptor, Saltpack
https://www.kryptor.co.uk/specification
https://samuellucas.com/2021/01/28/kryptor-v3.html
https://saltpack.org/
https://blog.cloudflare.com/hybrid-public-key-encryption/
https://datatracker.ietf.org/doc/rfc9180/
За последнее время я узнал о существовании всяких разных стандартов и
инструментов для всякого шифрования.
* Kryptor. Сравнивает себя с age и minisign. Хвалится поддержкой PSK,
аутентифицированного шифрования на публичных ключах, key commitment
(6529c5c19cb52f69f65fec3d17e718cc491d2c53), в противовес age. Есть не
prehashed версия подписи, в отличии от minisign. Квантовоустойчивость
только за счёт PSK. Неотличимость от шума.
* Saltpack. Основан на MessagePack кодировании.
* Описывает проблемы PGP: нет настоящего signcryption, выводит ещё не
аутентифицированные данные, нет анонимных получателей, много старого
legacy.
* Подписи поддерживает потоково, однако подписывает каждый мегабайт
отдельно, что я не очень одобряю (нагрузка на ключ). Не prehashed
версии нет. Использует SHA512, что не одобряю ибо медленно.
* В зашифрованных сообщениях есть repudiability, anonymity и сокрытие
получателей. Поддержка нескольких получателей, с защитой от того,
что кто-либо из них может изменить шифротекст (ведь ключ же есть у
группы людей уже). Всё заточено на дружелюбность к потоковой
обработке. И это тоже аутентифицированное шифрование на основе
публичных ключей, в противовес age.
Оба творения (хотя я больше присматривался к Saltpack) выглядят достойно
и хорошо с криптографической точки зрения. В моём текущем KEKS/CM, где
реализация на Go имеется, тоже сплошное дружелюбие к потоковой
обработке, не выдаются неаутентифицированные данные, есть key
commitment, есть не prehashed версия подписи, есть настоящие PQ
алгоритмы для шифрования, есть key ratcheting (serial external key
rekeying, как в других местах это ещё называют). И шифрование и подпись
(только для prehashed версии) распараллеливаются (что у меня и делается,
выдавая GiB/sec).
Но у меня нет аутентифицированного шифрования на основе публичных
ключей. Чем рано или поздно надо будет заняться. Но когда есть несколько
получателей, то это сильно всё усложняет, поэтому не спешу с этим. И
похоже, что реализация будет сильно похожа на Saltpack своей сутью,
чтобы быть дружелюбным к потоковой обработке.
Вообще, чем больше погружаешься в десятки всяких статей с IACR, то
офигеваешь от того же PGP (даже современного LibrePGP) и CMS, JOSE и
многим другим популярным вещам. Такое впечатление, что никто не
приглашает криптографов для разработки всего этого.
Sergey Matveev [Fri, 28 Feb 2025 13:59:41 +0000 (16:59 +0300)]
Слепой метод печати: стоит ли переучиваться?
https://habr.com/ru/articles/886758/comments/
Статью не дочитал, но осуждаю.
[...]
слепой метод печати. Освоить его сложнее, придется целенаправленно
его изучать
[...]
Категорически не согласен с этим утверждением, ибо я вот не учился.
Оно само со временем приходит. Если не приходит, то могу предположить,
что слишком мало времени проводится за набором текста. Соответственно и
доверия к дальнейшему тексту у меня нет. ~300 символов в минуту я делал
на ThinkPad. Но после подключения тактильной клавиатуры скорость сразу
же стала >400.
Sergey Matveev [Fri, 28 Feb 2025 08:02:02 +0000 (11:02 +0300)]
Chempat KEM combiner
https://datatracker.ietf.org/doc/draft-josefsson-chempat/
Вот есть множество вариантов как скомбинировать результат работы разных
KEM-ов (объединить полученный секрет от пост-квантового и традиционного
DH, грубо говоря). X-Wing (135afdcb923cd9463751d5766279c8426ee6ab00),
XYBERTLS, HPKE,
https://datatracker.ietf.org/doc/html/draft-ounsworth-cfrg-kem-combiners-05,
да и ещё всякие. По сути нужно просто захэшировать результат. По
хорошему ещё и учесть отосланный шифротекст, а ещё лучше и публичные
ключи участников, чтобы весь контекст учесть в результате. Плюс и
возможность бы задать сам контекст применения.
Кто-то не учитывает публичные ключи, но доказывает что это излишне, для
чётко заданных двух конкретных комбинируемых алгоритмов. Кто-то хэширует
в таком порядке, что не удобно делать потоково это всё. Кто-то полностью
суёт в хэш публичные ключи (как это я делал в KEKS/CM), которые в случае
Classic McEliece могут быть более мегабайта.
Но вот смотришь на предложение от DJB. Всё учитывает. Вместо полных
публичных ключей использует хэш от них, как и хэш от шифротекстов. Это
позволяет заранее захэшировать эти огромные значения. Публичный ключ
получателя наверняка будет один и тот же, если использовать для PGP/CMS
подобных применений. Шифротекст (эфемерные ключи) тоже зачастую можно
переиспользовать -- поэтому и хэш от него вычислить и переиспользовать.
То есть, получаем возможность дорогие вычисления сделать заранее и
переиспользовать (например если отправляем сообщение нескольким
получателям).
Ну вот почему именно DJB (и команда) предлагает такие простые, но
продуманные решения? Даже вот в таких мелочах.
Sergey Matveev [Thu, 27 Feb 2025 07:28:58 +0000 (10:28 +0300)]
Firefox с условиями использования
https://www.opennet.ru/opennews/art.shtml?num=62799
Я вот не понимаю людей, которые умудряются считать Mozilla какой-то
положительной компанией, а Firefox чем-то хорошим. По моему уже чуть ли
не лет десять, но как ни новость про Firefox, то жесть на жести в плане
ужаса со сбором данных, рекламой, слежкой. Забавно, но я те же самые
эпитеты из года в год к Firefox применяю: 84f4c26aab49c2b1665ab961e264b2f6d3e45b89 a3a49eccb47ca5b67ff9c52fca12c08121a130e1
Sergey Matveev [Wed, 26 Feb 2025 09:01:02 +0000 (12:01 +0300)]
Качество Debian документации, NTP
https://www.debian.org/doc/manuals/debian-handbook/sect.config-misc.en.html
https://docs.freebsd.org/en/books/handbook/network-servers/#network-ntp
Вчера видел как коллега устанавливал себе Debian современный. По
неаккуратности у него так вышло, что оставшаяся какая-то резервная
область с Windows установила этот самый Windows поверх его Ubuntu.
Но это я знаю со времён Windows 9x -- она без спросу перезатирает
всё стороннее.
Коллега задался вопросом как настроить NTP в нём. Быстрый поиск приводил
к systemd-timesyncd, но вот только по умолчанию эта штука не установлена.
Ok, уже даже мне стало интересно есть ли что-то в штатной документации
этого старейшего дистрибутива. Идём с сайта в "Debian Administrator's
Handbook", видим секцию "Time Synchronization".
Во-первых, мне кажется я впервые вижу, что рекомендуют вообще
использовать только ntpdate при загрузке для рабочих станций, мол,
достаточно, ибо они часто перезапускаются. По моему современные ПК у
большинства живут очень долго: ноутбуки постоянно спят и не
перезагружаются месяцами, а настольные ПК сотрудников тоже редко
выключаются, дабы удалённо на них заходить.
Во-вторых, нет никакой конкретики и примеров настройки. Есть упоминание
"ntp" пакета и в какой его конфиг смотреть. А теперь сравним с разделом
документации из FreeBSD, где и сам "ntp" стоит из коробки (хотя лично я
всегда везде chrony использую) и примеры конфигов приведены все, даже с
командами по перезапуску демона.
В-третьих, почему, будучи systemd ОС, Debian не упоминает даже
systemd-timesyncd? Это не Gentoo какая-нибудь, которая одновременно
несколько систем запуска. А timesyncd как-раз для чисто клиентских
устройств решение.
А ещё в этом Debian, в котором XFCE был выбран в качестве DE, есть
LibreOffice, но нет... ssh! Дистрибутив для секретарш, дожили. Хотя,
может оно и к лучшему -- наконец-то для них появился рабочий GNU/Linux? :-)
Sergey Matveev [Wed, 26 Feb 2025 08:00:44 +0000 (11:00 +0300)]
Снова Linux, снова Rust, очередной профессионал уходит оттуда
https://www.opennet.ru/opennews/art.shtml?num=62797
Дядька участвовавший в разработке "XFS, KVM, Trace events, SCSI и Slab
Allocator" ушёл из Linux сопровождающих. Такое ощущение, что как будто
из ядра уходит по мощному профи чуть ли не каждую неделю. И всё из-за
безумия с Rust-ом, а точнее переусложнением и так дико сложного ядра.
Всякие fetch.prune и fetch.all не одобряю чтобы были по умолчанию, ибо
человек должен решать как и что будет обновляться. Про всякую сортировку
ничего не могу сказать, ибо у меня нет проектов с большим количеством
веток. Заявление что column.ui clearly makes better у меня под вопросом,
ибо мне совершенно не нравится вывод в колонках.
Sergey Matveev [Tue, 25 Feb 2025 07:56:45 +0000 (10:56 +0300)]
Трафик сайта cURL
https://daniel.haxx.se/blog/2025/02/22/curl-website-traffic-feb-2025/
Около 2TB/день. Причём, преобладающая часть трафика это не скачивание
самого cURL, а их пачки CA сертификатов.
Sergey Matveev [Tue, 25 Feb 2025 07:42:51 +0000 (10:42 +0300)]
Муха и солёные огурцы
Увидел тут, что наша собака Муха, если ей дать солёного огурца, начинает
об него обтираться. Ну как любят собаки в тухлятинке поваляться. Вторая
собака, Таська, потом съедает этот огурец.
Sergey Matveev [Mon, 24 Feb 2025 18:02:32 +0000 (21:02 +0300)]
Алгоритмы ломают наше мышление
https://www.youtube.com/watch?v=QEJpZjg8GuA
Очень необычное для Technology Connections канала видео про
рекомендательные системы и их роль в нашей жизни. Автор предупреждает
об этом и советует переключиться на другие его творения, если идея не
нравится.
Понравилось там сравнение о том, что вот вы сидите в общепите и слышите
за соседним столиком разговор о чём-то вам интересном, то вы всё же не
встрянете в разговор, не подсядете за их столик, ибо это и невежливо и
вряд ли будет хотя бы нейтрально встречено. А вот соцсети это огромный
общепит, но в котором нормой является встревание в разговоры и, чаще
всего, совершенно не понимания их (прошлого) контекста. Что... сразу же
ведёт к срачам и негативным реакциям от всех сторон.
Половину ролика рассказывается про новостные ленты, которые на лету сами
генерируют что надо посмотреть человеку. Похоже, что у меня таких лент
даже в VK/Facebook вроде не было -- были только потоки информации на
которые я явно подписался. Единственный подобный источник это пара
новостных сайтов, с которыми фильтр критического мышления вывернут на
максимум. Ну и несколько новостных агрегаторов из мира ИТ, но в которых
не автоматизированные системы публикуют ссылки, а люди. И ещё из-за
плеча в общественном транспорте вижу в каких количествах абсолютно
бесполезной информации льют на мегабайтных/сек скоростях.
Автор ролика верно говорит, что если человек полностью отдаёт на откуп
генерирование мнения о том или ином вопросе/предмете машине, то он, как
минимум, полностью отказывается от ответственности за это мнение/решение.
Видимо, чем оно и подкупает людей. Масса хочет получить быстрый ответ
"хорошо или плохо?" (только два чётких цвета) на любой вопрос. И вроде
бы любому мыслящему человеку очевидно, что достаточно одной/двум
компаниям запрограммировать свои системы на отдачу нужного (им) ответа и
ты вот уже и запрограммировал массу людей так же считать и следовать за
этим мнением. Чего мы видим по геополитической обстановке в разных странах.
А ещё вспомнилось, не совсем уже по теме рекомендаций, но что куча людей
боится написать напрямую человеку сообщение. Некоторые мне даже это явно
говорили. Вот написать комментарий в публичном пространстве это как
нефиг делать. А вот адресовать комментарий или вопрос автору поста --
так какая-то мне неведомая преграда.
Причём у меня всё совершенно полностью от и до абсолютно на 100%
наоборот. Буквально вчера я пару писем отправил двум неизвестным мне
людям, имеющих опечатки и битые ссылки в своих статьях попавших мне
через Atom ленты. Я массу писем писал людям напрямую, но мне сложно
вспомнить когда бы я в последний раз писал комментарий. Наверное все
комментарии у меня были разве что только на Хабре (и то, потому что я
там статьи выкладываю), парочка на ЛОРе. Если у автора есть возможность
оставлять комментарии, но нет контактной информации как ему почту
отправить, то я вообще ничего не напишу.
Вот в целом мне совершенно не хочется обсуждать/комментировать что-то
публично, но переписка с человеком один-на-один у меня частенько
начинается как ответ на какую-то его запись в его блоге. Вообще
поддержку комментариев я в своём блоге делал что-то типа как ответ на
"слабо?" от одного человека, а не потому что лично я сам считаю это
полезным и нечто что лично я бы использовал.
Где-то в geminispace я даже видел фразу типа "хочется пообщаться с
автором, но у него нет комментариев в его gemlog". Совершенно мне не
ясно и не понятно это мышление. Причём сталкивался с таким не только у
молодёжи, но и у тех кто ощутимо старше меня.
Sergey Matveev [Mon, 24 Feb 2025 14:41:58 +0000 (17:41 +0300)]
Google ALTS
https://cloud.google.com/docs/security/encryption-in-transit/application-layer-transport-security
Вообще никогда не слышал прежде, но в Google свой собственный "TLS"
используется. Я был в курсе про IPsec на стыках из ЦОДов, но не более.
Вообще я скорее был бы удивлён если бы TLS использовался внутри. Судя по
описанию ALTS, то это протокол в котором Protocol Buffers вместо X.509
ASN.1 используются -- одобряю, разумно. У них многочисленные tradeoff-ы
явно отмечены, типа отсутствия PFS, сокрытия идентификаторов участников,
возможность KCI. Но я прекрасно понимаю, что для их внутреннего
использования и очень частого обновления сертификатов участников, всё
это разумные компромиссы. Они не поддерживают Ed25519 сертификаты в
Web/почте (только из-за них я ещё держал ECDSA сертификаты), но при
этом, внутри конечно же активно используют X25519.
Плюс моношифр в виде AES-GCM.
Sergey Matveev [Sun, 23 Feb 2025 07:18:56 +0000 (10:18 +0300)]
Отваливался активный USB удлинитель
В e83e818e20c039c6fc8a035154e3c732d98a9352 писал о том, что регулярно
отваливалось USB устройство. Но позже эмпирически было выяснено, что во
всём виноват активный удлинитель, вскоре вообще переставший работать.
Заменил на два соединённых 5м обычных кабеля. Не особо надеялся что
заработает, ибо везде же пишут про 3-5м максимальную дальностью. Но если
есть, как у инженеров, двухкратный запас прочности, то попытка не пытка.
GNSS приёмник заработал и вот уже почти неделю ни одного отвала. Демон
следящий за подключённостью устройства всё равно остаётся, но хоть тут
USB показывает себя приятно.
В блоге не писал, но USB хаб в, прошлом году приобретённом, мониторе
работал тоже паршиво -- время от времени отваливаясь со всеми
устройствами (клавиатура, мышь, звуковая карта).
Sergey Matveev [Sat, 22 Feb 2025 21:50:06 +0000 (00:50 +0300)]
Wayland вроде стал уметь WCG и HDR
https://www.opennet.ru/opennews/art.shtml?num=62737
В 826d90cc2ea12e59239d965728d9ec099e8d43c8 я писал о том, что
неожиданностью для меня стало отсутствие поддержки WCG/HDR и в
X.org и в Wayland. Ну про X.org ещё могу понять, но на дворе
2024-ый год, а модный современный так всеми популяризириуемый
Wayland всё это не мог. А тут новость, что в этом направлении
есть активное движение.
Sergey Matveev [Sat, 22 Feb 2025 11:50:02 +0000 (14:50 +0300)]
FreeBSD sysctl и дополнения для zsh
man sysctl имеет примеры для дополнения значений sysctl-а для zsh:
-N Show only variable names, not their values. This is particularly
useful with shells that offer programmable completion. To enable
completion of variable names in zsh(1) (ports/shells/zsh), use
the following code:
listsysctls () { set -A reply $(sysctl -AN ${1%.*}) }
compctl -K listsysctls sysctl
To enable completion of variable names in tcsh(1), use:
complete sysctl 'n/*/`sysctl -Na`/'
Эта ОС не перестаёт приятно удивлять и радовать такими мелочами и
дружелюбностью к пользователю.
Sergey Matveev [Fri, 21 Feb 2025 08:43:37 +0000 (11:43 +0300)]
Mantar -- Post Apocalyptic Depression
https://mantar.bandcamp.com/album/post-apocalyptic-depression
Клёвый у них вышел альбом! Прям чуть ли не эталонный по своему
фирменному звучанию и мотивчикам. Предыдущий, 2022-го года, прям...
скучный, совсем не запоминающийся, сразу забывается.
Sergey Matveev [Fri, 21 Feb 2025 08:26:01 +0000 (11:26 +0300)]
Matrix это творение Моссада?
https://web.archive.org/web/20201219014215/https://samba.noblogs.org/post/2018/08/27/matrix-org-a-federated-app-funded-by-a-mossad-company/
https://web.archive.org/web/20201104154843/https://github.com/matrix-org/matrix-doc/issues/979
https://0x19.org/posts/2023-06-09.php
Как тут пишут (но я не проверял, да и не хочу), Matrix с момента
создания годами спонсировался Amdocs компанией, которая засветилась
много раз на сборе (развед)данных для Израиля. Китай (и другие страны)
их вышибли отовсюду у себя из-за этого.
А что плохого в Matrix при этом? Лично я относительно спокойно отношусь
к творениям армий и спецслужб, ибо кому как не им необходимы безопасные
коммуникации? Но и надо держать ухо востро, ибо кому как не им и
разведкой заниматься. А в Matrix, являясь не федеративной службой
доставки сообщений, а службой по синхронизации состояний баз данных,
активно участвующие сервера обмениваются метаинформацией.
Автор статьи также пишет:
functionally centralized (I have a suspicion that the devs
intentionally made it as difficult as possible to self host in order
to scrape more metadata and to sell more SAAS solutions)
Вот тут полностью соглашусь с тем, что разработчики как-будто специально
всё усложнили, дабы ты не поднимал своего решения. Я не смог поднять
работающую связку из своего Matrix сервера, клиента и чтобы с федерацией
к matrix.org. Пробовал и Python версию и Go. Уже не помню детали, но при
каждой попытке то так, то сяк попробовать, но какой-то из компонентов
(клиент, сервер, федерация) не работал. И очень много я слышал
рекомендаций из серии "забейте поднимать свой Matrix сервер, просто
используйте matrix.org".
Sergey Matveev [Fri, 21 Feb 2025 08:07:59 +0000 (11:07 +0300)]
Минимализм ПО это максимализм UNIX
https://0x19.org/posts/2023-05-21.php
Верно замечает автор, что software minimalism это: to "reduce code
complexity", avoid "bloat", что "increases the maintainability", что, в
свою очередь, "decreases the total number of bugs". "Programmer
sacrifices cleverness for readability" -- что прямо противоположно
(3cd3d587c3909ae8da1f6bdde9ecaaf3bbcf87b9) Rust-у в моём понимании.
"Unused features are unaudited attack vectors"
"Any free UNIX that is not Linux is sufficiently minimal" -- похоже на
правду :-). "Any Linux without {systemd, freedesktop, pulseaudio, dbus,
wayland, GTK, KDE, anything GNU whatsoever} is sufficiently minimal".
Впрочем, в UNIX мире тоже полно так себе продуманных вещей, типа Make,
Autotools (хотя, возможно для своего времени оно стоило того), SysV
систем инициализации как пример.
Sergey Matveev [Fri, 21 Feb 2025 07:58:10 +0000 (10:58 +0300)]
Боязнь IPv6
https://techlog.jenslink.net/posts/ipv6-is-hard/
Как написал источник откуда я получил ссылку:
If it doesn't work it doesn't mean it's hard, fix it instead.
Полностью согласен с этим. IPv6 я считаю более простым и куда более
продуманным чем IPv4. Если не работает, то чини, исправляй, делай
грамотно, включай голову, забывай про подходы использованные в
obsolete legacy мире IPv4.
If you do IPv6 take it seriously. If you don't take it seriously,
don't do IPv6. That leaves to people thinking that IPv6 is hard and
can not be done.
Sergey Matveev [Thu, 20 Feb 2025 17:54:39 +0000 (20:54 +0300)]
Ink console
https://blog.zarfhome.com/2025/02/the-ink-console
https://inkconsole.com/
Наконец-то портативная консоль не для всяких этих ваших стрелялок и
бродилок, а для interactive fiction игрушек! Но если серьёзно, то без
клавиатуры... и без софта или ручки под рукой для рисования карт...
не уверен что будет хорошим user experience-ом. Впрочем, я тот ещё игрок :-)
Sergey Matveev [Thu, 20 Feb 2025 10:48:44 +0000 (13:48 +0300)]
zstd --patch-from
https://www.linux.org.ru/news/opensource/17890558
https://github.com/facebook/zstd/releases/tag/v1.5.7
Только что вышел новый zstd. Узнал о существовании --patch-from штуки,
которая и прежде был (но кто ж читает документацию!?). Попробовал --
действительно, делает прям патч, который можно применить относительно
уже существующих данных.
Я применяю bsdiff для обновления (bf0b7e0357b8bf41a874a85ab55f920a0fba7d59)
своих web-серверов, ведь у них нет явного конфига и любые изменения это
пересборка самого демона, который весит несколько мегабайт. Тогда как
bsdiff патчи занимают десятки килобайт (если не прыжок с мажорной Go
версии на мажорную произошёл). zstd делает патчи в разы большего
размера, но это всё равно сильно лучше чем передавать полностью все эти
бинарники. Думаю, что буду zstd использовать теперь для этих целей,
просто чтобы иметь меньший зоопарк инструментов. Впрочем, под FreeBSD
bsdiff идёт из коробки.
Попробовал и новую --max опцию. Памяти она жрёт уйму: для двух потоков
более 30GiB. Поэтому я не могу утилизировать все свои ядра на компьютере
(мало памяти). Ну и медленно оно конечно работает. Для больших файлов
вряд ли вариант -- уж очень долго.
Sergey Matveev [Thu, 20 Feb 2025 07:53:15 +0000 (10:53 +0300)]
Rust в Linux всё же будет
https://www.opennet.ru/opennews/art.shtml?num=62748
https://www.opennet.ru/opennews/art.shtml?num=62756
https://lore.kernel.org/all/2025021954-flaccid-pucker-f7d9@gregkh/
https://lore.kernel.org/lkml/Z7SwcnUzjZYfuJ4-@infradead.org/T/
Не то чтобы я сильно переживал и интересовался происходящему в Linux,
но, к сожалению, он, как Windows, окружает повсюду. И двое главных
решили что Rust однозначно будет в ядре.
Для меня Linux уже давно мёртв и не рассматривается, но теперь это ещё
одна причина не думать о нём. К Rust-у у меня резко негативное отношение.
Одна из причин: его авторы/разработчики плевать хотели на то, чтобы мы
могли его собрать из исходных кодов. Мол, бери бинарники которые мы дали
и не вякай. Возможно что-то за годы поменялось, но сторонний mrustc
проект на FreeBSD у меня не вышло собрать. Поэтому это по сути закрытое
ПО, ну или как минимум доступное только на GNU/Linux, под которым у меня
на работе всё же вышло собрать на Devuan большим количеством шагов,
которые не факт что удастся повторить, ибо то одни, то другие патчи на
сам Rust требовались, то одни, то другие пакеты из его Cargo. Судя по
всему, современные программисты на Rust это всякая молодёжь, которая
вообще не понимает как так может быть, что при сборке/установке софта
может не быть Интернета и что такого в том, чтобы использовать бинари? a109e79ace807e6d0caa8c682f9d507725a51356
Плюс он жутко сложный. А я убеждён, что одна из главным проблем в ИТ это
(безосновательная) сложность. Да, это наверное говорит о моей
некомпетентности и не высоком профессиональном уровне, но я за неделю не
смог зашифровать AES-ом файлик. Это когда я всё же решил углубиться в
этот язык для понимания что это такое и может быть он не так уж плох.
Взяв его документацию и под Devuan собранную версию (по NFS-у из FreeBSD
правил код, а по ssh-у запускал компилирование под GNU/Linux в виртуалке)
я так и не смог осилить: открытие файла, чтение в память, инициализация
AES с ключом, шифрование, запись в другой файл. Надо быть очень умным
для его использования. Может быть люди тем самым и любят этот язык? Он
сам по себе отсеивает некомпетентных и у них не будет шанса написать
какое-нибудь говно забагованное? В этом случае у нас действительно
тотальная нехватка квалифицированных специалистов. Но даже знакомые
коллеги, кто на Rust ради интереса реализовывали ASN.1 с CMS-ом, после
этого ничего на нём и не писали и не стремятся где-либо ещё попробовать
его применить.
Плюс он открыто поддерживал нацистов и террористов в 2022-ом, что крайне
негативное впечатление производит о людях руководящих его разработкой.
Да и другие решения (48f294ee80ca459983f1e403497f3d60ee35f37f) не
связанные напрямую с технологией как таковой тоже заставляли людей
отворачиваться.
Sergey Matveev [Thu, 20 Feb 2025 07:16:23 +0000 (10:16 +0300)]
CAP теорема на собеседовании
https://habr.com/ru/companies/ru_mts/articles/882656/
https://en.wikipedia.org/wiki/CAP_theorem
Очередная статья про ИТ собеседования, плохие вопросы и всё такое
прочее. Как в ней и сказано -- 1001-ая, тьма их.
Но в ней на картинке есть какой-то пример с: "как реализовать новостную
ленту со строгой консистентностью, высокой доступностью и гео
резервом?". И я вот не понял: типа высмеивают этот вопрос, мол типа он
сложный что ли? Я почти такой же вопрос задаю на собеседованиях: "какая
их современных существующих СУБД могут обеспечить и консистентность и
доступность и устойчивость к обрыву связи между ДЦ?". Уж извините, но
это простой вопрос и на него простейший ответ: никакая. Как сделать
ленту новостей заявленную? Никак! Ну если не вдаваться в особые режимы
работы типа переключения в read-only режим и всё такое прочее. В ivi
поэтому для разных задач (например работа с финансами/балансом
пользователя и показом ему истории просмотра) разные подходы и БД
использовались.
Может быть я не понял эту высмеивающую картинку, но я подобное спрашиваю
на собеседованиях на junior-ов. Нет, чётко мне пока ещё никто не
ответил "никак", но ход мыслей уже у двоих был очень близок к такому
умозаключению, про CAP-теорему слышали.
Между тем, недавно мы уволили студента-стажёра-практиканта. Вот вроде бы
и головастый, соображает, но производительность труда была просто никакой.
Всё что успел сделать за почти три месяца, так это написать тесты на
Python и Go для KEKS кодека. Но... в которым почти каждую строчку мне
всё равно пришлось править.
Недавно на собеседовании хотя бы один человек смог правильно ответить на
мой вечный вопрос "по какому протоколу работает Интернет?". Другой же
ответил "HTTP". Эх, ну вот почему так удручающе мало людей хоть как-то
интересуются сетями и совершенно не понимают что происходит когда они
ежедневно путешествуют по Паутине?
Возможно это нам HR/рынок/HH/хз подкидывают такие варианты стажёров, а
другие разбегаются по иным компаниям, крупным наверняка, но в моё время,
что я, что все мои знакомые ИТшники студенты, даже начав работать со
второго курса, но каждый день приезжали на работу, пускай и не на полный
рабочий день. А сейчас складывается впечатление, что у молодёжи сама
мысль о каждодневной работе просто невозможна. На последних курсах так у
нас наверное половина одногруппников и моих знакомых из других
институтов уже даже продвигались по служебной лестнице, были вполне себе
ценными кадрами. Но это и старшее поколение мне подтверждает: молодёжь
сейчас не хочет работать, не понимает как можно вкалывать хотя бы по 8ч
в день, нормально и полноценно. Я считаю, что слишком много у нас
сюсюкаются с молодёжью (говорю только про ИТ сферу).
Sergey Matveev [Tue, 18 Feb 2025 08:20:39 +0000 (11:20 +0300)]
Вывожу age из использования
В 4eed9f47294d277e84f8ba1451b1b4ced04a09de упоминал, что начал делать
аналог CMS EnvelopedData контейнера. Всё уже настолько устаканилось, что
бОльшую часть всего перешифровал в cm/encrypted контейнеры.
Изначально у меня вовсю использовались слова типа "pki" и сертификаты.
Выпилил любое упоминание PKI, решив назвать все эти криптографические
форматы "cm"-ом -- cryptographic messages. И коротко и не пересекается с
чем-то другим распространённым. Сертификаты заменил просто на публичные
ключи. У которых, как и в случае с PGP, могут быть подписи, не без этого.
ChaPoly шифрование распараллелил, аналогично как делал в реализации на
основе деревьев Меркла (f77b37849893c17724125acc62916d01521e363d). Всё
равно до сих пор не понимаю где затык, но утилизировать все ядра не
выходит -- 2.5+GiB/sec потолок, хотя он достигается на 3-4 потоках
шифрования уже, половина ядер остаются у меня не использованными.
Чтобы рандомизировать шифрование, на всякий пожарный, решил nonce для
ChaPoly делать не просто счётчиком, но подмешивать в него неизвестное
злоумышленнику значение, как это делается в TLS 1.3.
Причесал работу с HKDF-ом, ибо где-то его Extract шаг не нужен, где-то
нужен. В целом зоопарк стал более упрощённым. ChaPoly для DEM-а не
отличается теперь от ChaPoly применяемом в KEM-ах (для key wrapping).
Доработал утилиты cmkeytool, cmenctool, cmsigtool, cmhshtool для более
удобной интерактивной работы с человеком. Собственно, их и применяю уже
для своих нужд, радуясь огромной скорости работы без бутылочного
горлышка в виде одного ядра.
Обнаружил, что вообще нет ни BLAKE3 реализаций на Си, ни BLAKE2
распараллеленных. Ни ChaPoly распараллеленного не смог найти (возможно
оно только в составе более сложного софта). Такое впечатление, что
распараллеливание толком никому не нужно и все удовлетворяются
скоростями на одном ядре. Но ChaPoly у меня даже до GiB/sec не
дотягивает. Аппаратно ускоренный AES-OCB в GnuPG вроде тоже что-то около
GiB/sec был, как и BLAKE2b. Это конечно относительно не мало, но всё же
SSD диски во много раз быстрее, как и суммарная производительность всех
ядер процессора. Понимаю что parallel код сложнее устроен, но он же
стоит того. А вот нифига свободных и открытых реализаций не видно, кроме
как на Rust попадаются.
Добавил возможность шифровать приватные ключи тем же самым cm/encrypted
контейнером но с применением KEM-а на основе парольной фразы. И
прозрачно использовать такие ключи при дешифровании. Типа весь основной
функционал age повторил удобный.
А ещё в KEKS появился новый тип данных: MAGIC. 16-байтная строчка
начинающаяся с "KEKS". "K" является тэгом, не используемый прежде
codepoint. 12 байт произвольных данных можно засунуть в неё.
Предполагается, что MAGIC будет просто добавляться в начало файла, чтобы
хоть как-то намекать на используемый в нём тип данных. Ведь ни в ASN.1,
ни в JSON невозможно это легко и просто понять. В ASN.1 любят делать
контейнеры типа {"type": "SignedData", "data": ...}, но с этим не очень
удобно работать если хочется делать аналог json.Unmarshal -- оно всё
загрузит в память. А MAGIC можно потоково декодировать просто как один
единственный KEKS-атом, а дальше продолжить чтение из io.Reader.
И для удобства использования и в cm/signed и в cm/encrypted применяется
BLOB вне основной структуры. В случае с cm/signed:
MAGIC(cm/signed) || cm-signed-prehash || BLOB(detached-data) || cm-signed
и подписывается:
[detached-data] || /load || sig-tbs
всё это позволяет не делать потоковое декодирование данных, а частями
засовывать в io.Reader/hash.Hash и подобные. KEKS позволяет потоково
работать, как и сама Go реализация, но это не так удобно и просто как
сделать .Unmarshal. В случае с cm/encrypted:
MAGIC(cm/encrypted) || cm-encrypted || BLOB(encrypted-data)
А ещё обнаружил, что в http://libpqcrypto.org/command.html софте от DJB
вовсю используются не только stdout файловые дескрипторы. В моём
cmenctool я один из таких дополнительных "файлов" использовал для вывода
bind значения (сейчас его не стало). А в libpqcrypto они вообще
используются вовсю для передачи и приватных и публичных ключей. Чем
дальше, тем больше у меня появляется схожих идей и ещё больше одобрения
того как делается DJB софт.
Sergey Matveev [Mon, 17 Feb 2025 10:01:10 +0000 (13:01 +0300)]
Прочитал Real World Cryptography
https://www.manning.com/books/real-world-cryptography
Хорошая книжка по прикладной криптографии. Самое главное: она хотя бы
упоминает и показывает как в действительности криптография применяется,
без всех этих "RSA зашифровали сессионный ключ" которым полны другие
книги и люди совершенно теряются и не понимают где же "асимметричное
шифрование" в TLS/IPsec/SSH/Signal/whatever протоколах то?
Sergey Matveev [Mon, 17 Feb 2025 07:54:50 +0000 (10:54 +0300)]
Посмотрел "Сквозь снег"
https://ru.wikipedia.org/wiki/Сквозь_снег
В целом понравился фильм. Люблю когда постоянно совершенно новые "миры"
открываются по мере развития приключений главных героев. Каждый новый
вагон это непохожий на другие мир.
Вот только концовка, где выживают китаец и негр... неприятный осадок
оставляет.
Sergey Matveev [Mon, 17 Feb 2025 06:25:09 +0000 (09:25 +0300)]
Сходил на оперу Вагнера "Тристан и Изольда"
https://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B8%D1%81%D1%82%D0%B0%D0%BD_%D0%B8_%D0%98%D0%B7%D0%BE%D0%BB%D1%8C%D0%B4%D0%B0_(%D0%BE%D0%BF%D0%B5%D1%80%D0%B0)
С учётом того, что перед самой оперой ещё была небольшая лекция
рассказывающая об истории создания и о самом Вагнере, то в опере
провёл почти шесть часов. Очень всё понравилось. Вагнер -- мощь!
Почти никакого действия, минималистичные декорации и костюмы, лишь
постоянно играющая насыщенная музыка и отличное пение. Папа не стал
поклонником опер, поэтому ходил только с мамой. Но, не смотря на часы
проведённые в зале, ни капли не устали, не чувствовали измотанности.
Так как в напряжении постоянно держит, никакой скуки.
По сути мы прослушали все доступные Вагнеровские оперы в Москве.
Sergey Matveev [Fri, 14 Feb 2025 08:47:56 +0000 (11:47 +0300)]
OBS Studio грозит иском к Fedora из-за пакета
https://www.opennet.ru/opennews/art.shtml?num=62718
Когда я увидел как пакетируют мой NNCP в Debian, то, мягко говоря, тоже
офигел. Я поставляю tarball со всеми зависимостями -- нужен только Go
соответствующей версии, больше ничего. Но там форсированно убирают все
предоставленные зависимости, используют +- (!) схожие версии из пакетов
и в итоге всё собирается с отличающимися версиями библиотек. И типа в
Debian так принято и всё тут. Недовольство OBS я могу понять.
Sergey Matveev [Wed, 12 Feb 2025 17:39:56 +0000 (20:39 +0300)]
Несколько проектов перевёл на Go 1.24
https://go.dev/blog/go1.24
Он вышел только сегодня, но я как-раз возился с кодом, где есть и HKDF и
PBKDF2 и SHA3/SHAKE, которые теперь перекочевали из golang,org/x/crypto
в родную библиотеку. Плюс не draft версия ML-KEM для TLS появилась. А
обновлённые go vet анализаторы активно начинают приучать использовать
родные итераторы Go (про которые только читал, но не пробовал ради
обратной совместимости) и generic-based библиотеки типа slices.
Пока портировал свои правки для поддержки ГОСТ в TLS 1.3,
то много видел упоминаний о FIPS 140-3, что нервирует.
Оно нигде не мешает, но глаз мозолит.
Sergey Matveev [Wed, 12 Feb 2025 17:26:07 +0000 (20:26 +0300)]
Нашёл проблему с Ethernet кабелями
А то была (8bf72b323ea37b56beda8d15bf3f5008609dffa7) аномалия с разными
кабелями. Всё оказалось проще: это был вышедший из строя SFP модуль.
Недавно он вообще перестал поднимать link. Поменял SFP-ку и всё вновь
заработало, с любыми кабелями. Причём полностью исчезли ошибки передачи
(ну, как минимум, счётчики). То ли SFP другой компании не отдаёт эту
информацию, то ли это действительно был показатель изначально корявого
прошлого SFP. Но задержки (e542298de3baade166b3abf55636933620ff667d)
лучше не стали.
Sergey Matveev [Tue, 11 Feb 2025 19:04:27 +0000 (22:04 +0300)]
Прочитал "Кладбище домашних животных"
https://ru.wikipedia.org/wiki/Кладбище_домашних_животных_(роман)
Не один десяток рассказов Стивена Кинга я "прочитал" в сборниках
аудиокниг. Решил тут что-нибудь большее по размеру прочесть из его
творчества. Взял вот эту книгу, которую он считает самой страшной.
Ну что сказать? Круто, очень круто! Отлично пишет, отлично погружает в
чувства всех этих людей, отлично передаётся ужас и напряжение. Очень
доволен книгой, которую за несколько дней в транспорте проглотил.
В статье Wikipedia есть фраза:
Написанное напоминает страшилку в лавкрафтовском стиле.
Может это тоже одна из причин почему так понравилось?
Sergey Matveev [Tue, 11 Feb 2025 18:53:46 +0000 (21:53 +0300)]
Добавил Classic McEliece KEM
https://classic.mceliece.org/
К уже существующему черновому (4eed9f47294d277e84f8ba1451b1b4ced04a09de)
формату зашифрованных данных, где реализован SNTRUP4591761+Curve25519 в
качестве KEM (не считая шифрования по парольной фразе), добавил KEM с
Classic McEliece. Больного много про него в рассылках упоминают,
постоянно добавляя про консервативность алгоритма.
Почитал про него побольше и тоже он очень понравился. Алгоритм
существует типа более 40 лет уже, и никаких атак серьёзных. Он прошёл и
в финал NIST PQC конкурса и одобрен для применения как альтернатива
Kyber/ML-KEM. То есть, даже де-юре, в отличии от SNTRUP, годен к
использованию. Описание алгоритма не то чтобы мне сильно понятно, но
выглядит убедительно квантовоустойчиво и просто. Увидел, что и сам DJB
не раз презентовал этот алгоритм и рассказывал про него -- одобряет.
Его приватный ключ: ~14KiB. Публичный: 1MiB. Зато шифротекст менее 200
байт. Из-за такого публичного ключа его проблематично использовать как
аналог DH, но зато отлично пригодно для CMS/PGP-like задач где есть
долгоживущий публичный ключ. Как и для формата зашифрованных данных на
основе KEKS! Где-то видел, что Classic McEliece используют для
долговременных ключей, а параллельно SNTRUP для эфемерных, ради PFS.
Понравилось, что внутри себя он использует SHAKE256 хэш. Поэтому и HKDF
для него тоже на его основе, не BLAKE2b.
Sergey Matveev [Tue, 11 Feb 2025 06:44:06 +0000 (09:44 +0300)]
Возможность убийства зная настоящее имя
https://www.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/ps.1
В man ps в некоторых версиях UNIX есть фраза:
v5 ps manual (v5man.pdf page 94)
The process unique number (as in certain cults it is possible to
kill a process if you know its true name).
v7 usr/man/man1/ps.1
.TP
PID
The process ID of the process; as in certain cults it is possible to
kill a process if you know its true name.
Хотя у меня, первым делом, возникает воспоминание как одна девушка
уговорила посмотреть "Тетрадь смерти", чтобы обязательно на японском
(с субтитрами). По началу всё довольно интересно было, но потом тааак
всё высасывают из пальца, что даже при 4x промотке не смог досмотреть
всё до конца. И так и не понял зачем слышать мне оригинальную японскую
речь.
Sergey Matveev [Mon, 10 Feb 2025 12:52:19 +0000 (15:52 +0300)]
Телефонный спам перезванивает с того же номера
Когда-то я регулярно (раз в пару лет) менял номера телефонов. Потом я
догадался не отвечать на незнакомые мне номера и номер поэтому уже не
менял наверное самое долгое время. Я условился: если хотя бы два раза
позвонят с одного и того же номера, то подниму трубку.
Но на прошлой неделе мне так предложили квартиру. Сегодня вот тоже с
одного номера пара вызовов прошла, но я не брал трубку. Вижу по номеру
что это прям из того же самого пула что и предложение прорвавшееся было.
За 4-5 лет ровно один раз был звонок с одного и того же номера и он
реально был по делу, хотя я его и ожидал. Плюс несколько звонков на
которые я сразу поднимал трубки, так как что-то заказывал. То есть
мой (не я первый, конечно же) подход работал отлично, но и ему
пришёл конец.
Sergey Matveev [Sun, 9 Feb 2025 17:52:14 +0000 (20:52 +0300)]
Посмотрел "Круто сваренные"
https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D1%83%D1%82%D0%BE_%D1%81%D0%B2%D0%B0%D1%80%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5
Отличный боевичок! Говорят, что именно от Джуна Ву, режиссёра этого
фильма, взяты фишки типа стрельбы с двух рук, замедленной съёмки,
постоянных полётов во время мочилова и подобного. Вот умели же круто и
интересно снимать без тонны компьютерной графики! Местами кажется, что
есть отсылки на Матрицу, но всё совсем наоборот.
Sergey Matveev [Sun, 9 Feb 2025 10:43:21 +0000 (13:43 +0300)]
Мы уничтожаем софт
https://antirez.com/news/145
Быстро закрыл эту статью, ибо всё совершенно очевидное ведь написано,
каждому толковому программисту всё это видно. Но... ведь как-раз таки
преобладающему большинству то как-раз это не ясно. antirez -- очень
опытный и толковый разработчик.
We are destroying software by no longer taking complexity into
account when adding features or optimizing some dimension.
Одно из самых первых что предъявляю и оцениваю в софте. Поэтому и
вынужден писать всякие VoRS, KEKS и подобные штуки.
We are destroying software with complex build systems.
Абсолютно верно! Поэтому и был создан BASS с goredo, ведь это просто
безумие если посмотреть в сторону какого-нибудь CMake или Autotools.
We are destroying software with an absurd chain of dependencies,
making everything bloated and fragile.
Это одна из причин почему я больше не хочу прикасаться к Python
экосистеме, а также наслышан про сотни *тысяч* зависимостей у NodeJS
проектов. По моему это просто невозможно использовать.
We are destroying software telling new programmers: "Don't reinvent
the wheel!". But, reinventing the wheel is how you learn how things
work, and is the first step to make new, different wheels.
Раз за разом и сам начинаю вроде бы переизобретать колёса. Но что
поделать если мне нужна повозка, а мне предоставляют локомотив. Ну и да,
не поспорю, что на основе всего этого я очень много нового узнал о мире.
We are destroying software by no longer caring about backward APIs
compatibility.
Не знаю насколько это критично, но вроде масса примеров, действительно,
находится когда люди забивают на совместимость и ты вынужден или
использовать неподдерживаемую старую версию или возможно ещё более
дерьмовую в других отношениях новую.
We are destroying software pushing for rewrites of things that work.
Наверное да.
We are destroying software by jumping on every new language,
paradigm, and framework.
Согласен. Но и не стоит забывать посматривать на новые вещи, которые
бывают очень хороши. Десятилетия использующийся софт -- далеко не всегда
означает что он был всё это время хорош.
We are destroying software by always underestimating how hard it is
to work with existing complex libraries VS creating our stuff.
Ну... могу вспомнить/представить множество примеров с перекосом в одну и
в другую стороны.
We are destroying software by always thinking that the de-facto
standard for XYZ is better than what we can do, tailored
specifically for our use case.
Абсолютно верно!
We are destroying software claiming that code comments are useless.
Ничего не могу сказать. Есть плохой код и без комментариев. Есть и
плохой код с бесполезными комментариями. Есть хороший код и без
комментариев.
We are destroying software mistaking it for a purely engineering
discipline.
Наверное не понял это предложение.
We are destroying software by making systems that no longer scale
down: simple things should be simple to accomplish, in any system.
Верно.
We are destroying software trying to produce code as fast as
possible, not as well designed as possible.
Ну бывает нужно и уметь писать *прототип* as fast as possible. Но
проблемой будет если этот прототип будет конечным продуктом, это да.
We are destroying software, and what will be left will no longer
give us the joy of hacking.
Sergey Matveev [Sun, 9 Feb 2025 07:19:05 +0000 (10:19 +0300)]
Написание простой системы сериализации данных
https://rxi.github.io/a_simple_serialization_system.html
Человек показывает, как можно просто на Си написать и структуры и
массивы и разные типы данных, включая строки. По сути у меня прям всё
точно такое же, даже Си сериализация. Разница только в большем
количестве поддерживаемых данных и более сложном кодировании длины для
экономии места. В очередной раз, понимаю что я был на правильном пути.
Не в первый раз здесь предлагают string interning использовать
технологию, где строчки можно заменить ссылками на уже декодированные. В
Binc (3f218260ad4a9b16f7e56031ab8a32d2b810de28) формате такое же было и
в каком-то из более широкоиспользуемых (flat buffers, cap'n'proto?).
Пока я не готов к подобному, хотя обдумывал, было дело.
Sergey Matveev [Sat, 8 Feb 2025 09:25:32 +0000 (12:25 +0300)]
Кризис в продвижении Rust в Linux
https://www.opennet.ru/opennews/art.shtml?num=62685
https://www.linux.org.ru/news/kernel/17876385
Искренне злорадствую! И тому, что Rust не проникает. И тому, что в
очередной раз у них постоянные тёрки в ядре и люди официально уходят. И
Линус показывает своё лицемерие западное, мол он весь из себя только за
технические решения/дискуссии, но не раз не забывает напоминать о том,
что он фин, последователь своих предков нацистов. Мир Linux это уже
такая гнилая помойка...
Sergey Matveev [Sat, 8 Feb 2025 09:20:43 +0000 (12:20 +0300)]
Пассажира поезда оштрафовали на €150
https://habr.com/ru/news/880642/
Завидую подобным действиям во Франции! Ибо как же задолбали все эти суки
говорящие по сотовым в общественном транспорте. И ведь реально куча
включает ещё и громкоговоритель. На МЦК есть вагоны тишины, но некоторые
люди идут по поезду, садятся именно в них и начинают или смотреть
сериалы/передачи или трепаться через громкоговоритель. Раздражают
подобные невоспитанные и показушно никого в округе неуважающие похлеще
тех, кто занимает две стороны эскалаторов, или еле плетутся по ним
уткнувшись в свой смартфон. А ещё сколько детей маленьких играет в игры
с громкоговорителями, при этом их мамаши/папаши сидят рядом и им насрать
что слышно на полвагона.
Sergey Matveev [Thu, 6 Feb 2025 19:02:28 +0000 (22:02 +0300)]
Почему в GNSS нужно четыре спутника
https://en.wikipedia.org/wiki/Satellite_navigation
https://en.wikipedia.org/wiki/Hyperbolic_navigation
https://en.wikipedia.org/wiki/Hyperbolic_positioning
https://en.wikipedia.org/wiki/GPS#Hyperboloids
В 99.99% статьях что нахожу на просторах Паутины, пишут про нахождение
местоположения по спутникам (как в GPS например) по замерам времени. Тут
мне всё очевидно: скорость, время, расстояние. Берём три спутника и уже
получаем (триангуляция) местоположение. Тут всё понятно. Но ведь у нас
же нет синхронизированных и точных часов! Как быть? И везде пишут, что
вот как-раз четвёртный спутник типа тут может помочь. Ну я про себя и
полу-додумывал, что, мол, наверное мы за reference можем взять сигнал
хотя бы кого-нибудь, а дальше уже итеративно плясать от него и всё
большую точность предположений времени делать. Уверен что это не так, ну
или, как минимум, нет понимания что я понимаю хотя бы абстрактно.
Более того, в статье про GPS на Wikipedia так и написано что пример с
пересекающимися сферами не верен:
It is sometimes incorrectly said that the user location is at the
intersection of three spheres. While simpler to visualize, this is
the case only if the receiver has a clock synchronized with the
satellite clocks (i.e., the receiver measures true ranges to the
satellites rather than range differences).
Точнее верен когда у нас синхронизированы часы, что для меня полностью
понятно. И вот геометрическое объяснение с гиперболами уже мне дало
чувство того, что я точно понимаю почему именно четыре спутника надо.
Плюс, после этого понятно (когда мы поняли своё местоположение и точное
расстояние/задержку от спутника) почему и время можно точно получать
только после выяснения своего местоположения.
Впрочем... качество статей Wikipedia тоже печально известно.
Sergey Matveev [Thu, 6 Feb 2025 09:13:27 +0000 (12:13 +0300)]
Brave всё
Менее года назад я начал (e022335c957350b8e124f9668e55bda101ad4edb)
использовать Brave Search вместо DuckDuckGo (совсем обезумевшие своей
политикой и цензурой). И вот сегодня он начал говорить что давай ка
CAPTCHA решай и JS врубай.
И что же остаётся? Пока только рекомендованный в комментариях
мета-поисковик SearX, его публичные instance. Уже заметил что качество
выдачи у них отличается. А больше работающих поисковых систем я вообще
не нашёл. Либо JS, либо 403 "русским смерть", либо на запрос
"шифропанки" ничего не выдаёт, даже хотя бы страничек из Wikipedia.
Вообще я давно уже начал считать, что правильной идеей было иметь
каталог ресурсов (https://en.wikipedia.org/wiki/Web_directory). И я был
уверен, что монополия поисковиков, уничтожившая каталоги, перейдёт на
обязательный запуск их программ на наших компьютерах (JS) и альтернатив
не останется. Почти полностью уже так и произошло.
Sergey Matveev [Thu, 6 Feb 2025 08:10:02 +0000 (11:10 +0300)]
Приключение с link-ом на Cat8 кабеле
Для меня это звучит как чертовщина какая-то, но на недавно приобретённом
(8b07d4cdd34f2ee48aefb66f7a7921444c841dd4) Cat8 Ethernet кабеле после
перезапуска компьютера не поднимается link. Лампочка на NIC мигает один
раз и всё. ifconfig up/down на обеих сторонах не помогает.
Однако, если вместо Cat8 подключить старый Cat 4(/5?), то link
поднимается. После чего можно перетыкнуть Cat8 кабель и всё тоже
заработает.
Sergey Matveev [Wed, 5 Feb 2025 08:13:57 +0000 (11:13 +0300)]
Интереснейшая история о том, как человек познакомился с компьютерами
https://nzdr.ru/creation/prograf/vehi
https://nzdr.ru/creation/prograf/vehi/first
https://nzdr.ru/creation/prograf/vehi/second
С массой иллюстраций и фотографий. Я же слишком молодой, чтобы застать
многие из подобных вещей, хотя и знаю чуть ли не про каждый компьютер
вдоволь. Помню, что тоже очень хотел МК-52 микрокалькулятор.
Sergey Matveev [Tue, 4 Feb 2025 09:27:07 +0000 (12:27 +0300)]
Ещё не встречал чтобы USB не отваливался
Об этом не раз упоминал везде: ну не видел я устройств, которые бы не
отваливались от USB время от времени. Могут дни, неделю проработать и
ничего не будет, но рано или поздно отвал произойдёт. Ну или не встречал
в природе работающих добротно контроллеров или драйверов к ним.
GNSS приёмник (caebe45a7eadafe4d5f93734b1118514685c8dbd) представляется
системе как umodem устройство, COM-порт типа. Но раз в сутки исчезает с
шины. Благо, usbconfig reset помогает.
Sergey Matveev [Tue, 4 Feb 2025 07:35:02 +0000 (10:35 +0300)]
macOS создаёт битые .zip
https://askubuntu.com/questions/1025742/unzipping-large-file-bad-zipfile-offset-local-header-sig
https://stackoverflow.com/questions/27151176/zip-files-corrupt-over-4-gigabytes-no-warnings-or-errors-did-i-lose-my-data/59518097
https://sourceforge.net/p/sevenzip/bugs/2038/
Ну конечно же, кто как ни Apple будет делать софт, который создаёт
well-known .zip архивы, но не валидные и никем не открываемые.
Причём даже и не большого размера и с десятком файлов внутри.
Sergey Matveev [Sun, 2 Feb 2025 14:08:39 +0000 (17:08 +0300)]
Нужная ли PTR запись для исходящего почтового сервера?
https://old.reddit.com/r/sysadmin/comments/k93d8r/ptr_record_is_it_required_nowadays/
Узнал тут, что даже без PTR записи некоторые большие почтовые провайдеры
могут принять почту. Для меня это стало большой новостью, ибо уж кто кто,
но "большие" только больше и больше закручивают гайки в почтовой
экосистеме. Но, возможно, приём и без PTR/rDNS записи возможно им больше
полезен будет для статистики спаморассылателей. Серверам же помельче без
этой проверки будет туго, ибо (попыток отправки) спама реально много. Да
и вообще я впервые услышал что кого то, кто поднял свой почтовик, куда
то почта могла ходить без PTR.
На Reddit нашёлся разговор, где тоже упоминают о том, что типа Google и
Microsoft перестали проверять rDNS. Но я не нашёл подтверждений оного.
Возможно оно участвует только в оценке спам/не-спам. В любом случае, это
только несколько провайдеров из тысячи, которые rDNS требуют.
Вероятность того, что сервер без PTR-а окажется легитимным -- крайне
низкая, поэтому отключать эту проверку у себя не буду, ибо от спама помогает.
Sergey Matveev [Sun, 2 Feb 2025 10:30:47 +0000 (13:30 +0300)]
Готовлю Merkle-tree-based хэширование в signed-data
Во время написания (4eed9f47294d277e84f8ba1451b1b4ced04a09de)
enveloped-data контейнера на основе KEKS, я задумался о
производительности скорости подписывания данных. chacha20-poly1305 у
меня выдаёт почти ГиБ/сек, а вот скорость подписывания больших данных
зависит от скорости хэша, где BLAKE2b всё равно будет медленнее ChaPoly.
Распараллелить ChaPoly, раз я бью на независимые блоки по 64КиБ, можно
без проблем. А вот хэш уже нет. Но кто ж помешает добавить опциональный
режим хэширования в виде деревьев Меркле? Я такое уже делал в NNCP, но
там это было нужно для возможности "дохэширования" данных, а
распараллеливание я не делал.
Пока все наработки в отдельной ветке, в master ещё не попали, но
2+ГиБ/сек я могу и на SHA2-512 достичь на своём компьютере. Но я не
один день бился над тем, чтобы попытаться утилизировать все процессоры.
Видимо, мне не хватает базовых знаний по структурам/алгоритмам. Задачи я
раздаю через каналы заранее запущенным горутинам считающие хэш.
Результаты собираю из другого канала. Делая чтение из stdin в буфер, а
дальше его запись в io.Pipe+io.ReadFull, у меня не однократное
копирование присутствует. Если размер блока Меркле дерева 128КиБ, то я
легко достигаю 2+ГиБ/сек пропускной способности. Если же 8КиБ, как
изначально хотел, то с трудом поднимаюсь выше 1.1. На данный момент я
дошёл профилированием и оптимизациями до того, что я по сути упираюсь в
производительность каналов Go. А точнее в частые использования mutex.
Пробовал использовать попадающиеся под руку lock-free реализации каналов
пригодных для моей задачи -- 10-20% прироста есть, но не более. Добавил
возможность хэшировать из mmap-нутого файла, избавляясь от чтений из
stdin и записей в hash.Hash -- это тоже дало только ~10%
производительности. Я в итоге не мог утилизировать все ядра процессора
для BLAKE2b. Коллега предложил решение в виде круговых буферов с
lock-free взаимодействием с ним, но это прям сильно неканонично с точки
зрения Go будет, который гласит "Don't communicate by sharing memory;
share memory by communicating".
Как освобожусь от более насущных задач, то снова вернусь к задаче.
Возможно уже ничего не будут менять, ибо 2-2.5ГиБ/сек
хэширования/подписи + шифрование (которое тоже надо распараллелить) на
остающихся свободных ядрах на моём компьютере это тоже очень не плохо.
Стрибога, очень не быстрой реализации без ассемблерных вставок, это
позволит очень хорошо распараллелить. Но ещё и на Си это же всё стоит
реализовать параллельно.
Sergey Matveev [Sat, 1 Feb 2025 18:19:38 +0000 (21:19 +0300)]
Heartbeat сигнал на принтере
На работе есть принтер, на боку которого равномерно мигающая лампочка.
А рядом просто нарисовано сердечко. Мол, heartbeat сигнал так показывают.
Причём его период как-будто совпадает с нашим человеческим.
Sergey Matveev [Sat, 1 Feb 2025 18:10:58 +0000 (21:10 +0300)]
Критикуют L4S эксперимент Comcast-а
https://habr.com/ru/news/877886/
https://lists.bufferbloat.net/pipermail/bloat/2025-February/018191.html
В рассылке bufferbloat очень недовольны фактом попыток использования L4S
AQM-а, который требует модификации всех участников передачи данных.
Sergey Matveev [Sat, 1 Feb 2025 17:58:47 +0000 (20:58 +0300)]
Приобрёл Cat8 Ethernet кабель
https://ru.genuinemodules.com/c8b-sftp-blk-10m
Пока в магазине брал 10м USB удлинитель для GNSS приёмника, то не смог
устоять и перед коробкой с Cat8 Ethernet-ом. Я даже не знал, что есть
что-то выше Cat7. А у этого плетёная оболочка, вместо пластика
скользкого -- прям приятен на ощупь и совсем не жёсткий, как некоторые
еле гнущиеся Cat7. Соединил им свой компьютер с сервером 10GbE. И нет,
это не повлияло на задержки (e542298de3baade166b3abf55636933620ff667d),
как и на кол-во ошибок. Может стало и получше, но ни в какое сравнение с
twinax-ом, который стоил даже чуть дешевле.
Sergey Matveev [Fri, 31 Jan 2025 07:49:44 +0000 (10:49 +0300)]
Online документация должна быть offline
https://rldane.space/online-documentation-should-be-offline.html
Полностью согласен с автором: online документация для программы это
просто недопустимо. Если документация имеется хотя бы Git-репозитории,
то я его клонирую и могу ещё закрыть глаза на отсутствие доки в более
удобных форматах (чем исходники документации). Но когда дока это только
wiki страницы какие-нибудь или размашистый статический сайт, то я почти
наверняка вообще не буду рассматривать возможность использования
программы. 1-2 HTML странички, которые я могу скачать wget-ом ещё тоже
терпимо.
Смотрю как два других моих компьютера относительно него синхронизируются:
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* www.stargrave.org 1 6 377 18 +272us[ +320us] +/- 345us
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* www.stargrave.org 1 6 357 48 +87us[ +138us] +/- 365us
то есть доли мс, вместо нескольких десятков мс. Но в настройках chronyd
пришлось добавить offset 0.04, ибо приёмник по банальному USB1 отдаёт
время отличающееся на 40мс от того что я с NTP получаю.
Рабочий компьютер, подключённый через VPN к домашнему серверу (для того,
чтобы IPv6 трафик шёл через него напрямую), показывает на порядок лучше
показатели чем наш NTP сервер в LAN:
Sergey Matveev [Wed, 29 Jan 2025 19:48:59 +0000 (22:48 +0300)]
Приобрёл GNSS приёмник для использования с сервером времени
Простой USB-шный, но поддерживающий и ГЛОНАСС и китайскую с европейской
(не считая GPS) навигацию. Не предоставляет PPS, но и без него,
насколько вижу, стабильность выше. Пока без точных цифр, ибо проверяю на
своём рабочем компьютере, а не центральном сервере с которым все
синхронизируются. gpsd завёлся моментально, chronyd соединился с ним
тоже с ходу.
Sergey Matveev [Wed, 29 Jan 2025 19:27:00 +0000 (22:27 +0300)]
DTrace помогает на работе
https://www.brendangregg.com/blog/2011-02-11/dtrace-pid-provider-arguments.html
https://www.brendangregg.com/blog/2011-02-14/dtrace-pid-provider-return.html
Есть задача по трассировке всех вызовов функций в Си программе.
DTrace-овский "pid" провайдер добавляет пробы при входе и выходе из
функции, даже которая была static.
Будет выводить факты вызовов всех функций с префиксом mylib в имени.
И аргументы функций доступны через arg0, arg1, .... Без изменения
программы можно чуть ли не полностью трасировать всё что в ней
происходит. Хотя мне и пришлось добавить свои пробы дополнительные,
которые где-то в середине функций имеются. Можно и Си-шные структуры
тоже разбирать прямо внутри DTrace.
Sergey Matveev [Fri, 24 Jan 2025 12:12:34 +0000 (15:12 +0300)]
Как палятся нацистские мошенники
Знакомых пытались развести в IM-е на телефонный разговор с (якобы)
представителями ФСБ, чтобы выяснить не спонсирует ли человек ВСУ.
Был приложен подписанный документ, штампы, подписи, типа всё серьёзно.
Вот только использование "в Украине" моментально выдаёт написавшего, что
он явно не местный. Как в шпионских фильмах сущие мелочи выдают людей.
Sergey Matveev [Mon, 20 Jan 2025 18:08:29 +0000 (21:08 +0300)]
Git trailers
https://alchemists.io/articles/git_trailers
Не замечал прежде в Git-е такую штуку как --trailer,
которые ещё можно и парсить git interpret-trailers командой.
Sergey Matveev [Mon, 20 Jan 2025 09:56:40 +0000 (12:56 +0300)]
Session IM: раунд 2
https://getsession.org/blog/a-response-to-recent-claims-about-sessions-security-architecture
https://soatok.blog/2025/01/20/session-round-2/
Оказывается, Session ответил на ранее (c48fd6b9485a4ea70a8287d1985dfcb9d9219a4c)
опубликованную критику из протокола.
Они не согласны с тем, что используется 128-бит энтропии для
генерирования Ed25519. Почему? Потому что к их 128-бит дополняются ещё
128-бит нулями и это пропускается через SHA512. Я даже не знаю как это
прокомментировать. "Сколько бит энтропии потребляется при выработке
ключа?" -- всё так же 128-бит, от этого никак не отвертеться. Для чего
они используют 128-бит? Чтобы это уместилось в парольную фразу.
Дальнейшая критика критики сводится к тому, что "вы не правильно поняли
наш код". Может быть это намёк на то, что ваш код настолько непонятно
написан?
Sergey Matveev [Mon, 20 Jan 2025 08:18:12 +0000 (11:18 +0300)]
IXP с нуля: peering LAN
https://blog.apnic.net/2025/01/20/ixp-from-scratch-part-3-the-peering-lan/
https://datatracker.ietf.org/doc/html/rfc7947
https://datatracker.ietf.org/doc/html/rfc7948
https://datatracker.ietf.org/doc/html/rfc5963
Интересное чтиво о том, как настоящие, пусть и не большие, Internet
exchange provider устроены.
Sergey Matveev [Mon, 20 Jan 2025 08:11:23 +0000 (11:11 +0300)]
Различный экстремальный вокал
https://world-playground-deceit.net/blog/2025/01/most-memorable-extreme-music-screaming.html
Большая подборка музыки с запоминающимся (по мнению автора)
экстремальным вокалом. К сожалению я лишь с несколькими группами из
этого списка знаком, но у которых, действительно, вокал выделяется.
Sergey Matveev [Sat, 18 Jan 2025 19:23:21 +0000 (22:23 +0300)]
DJB о скором изобретении на практике работающих квантовых компьютеров
http://blog.cr.yp.to/20250118-flight.html
DJB рассматривает всякие аргументы против PQC и то, что люди с ним
носятся. Говорит, что, учитывая как упорно финансируются АНБ, нанимающие
передовых специалистов в этих областях, они (атакующие) находятся на годы
впереди остальных, кто придумывает PQC. И типа всякие прорывные штуки
происходят внезапно и за короткое время. Мы можем только надеяться, что
квантовые компьютеры (способные выполнять алгоритм Шора и имеющие
практически достаточное кол-во кубит) не появятся, только верить.
Sergey Matveev [Sat, 18 Jan 2025 19:19:33 +0000 (22:19 +0300)]
Короткоживущие сертификаты Let's Encrypt -- ещё большая централизация
https://dxdt.ru/2025/01/17/14811/
Верно автор заметил, что их новые сертификаты это ещё большая власть и
централизация вообще всего web-а. И ведь юридически красиво сделано:
неугодные (с точки зрения США и прочих террористов) ресурсы можно даже и
не отзывать, а просто перестать обслуживать и выпускать для них новые
сертификаты. Отзыва нет -- ничего не нарушено, а никто не гарантировал
постоянное обслуживание.
Sergey Matveev [Sat, 18 Jan 2025 19:16:17 +0000 (22:16 +0300)]
Посмотрел "Чёрная кошка, белый кот"
https://ru.wikipedia.org/wiki/Чёрная_кошка,_белый_кот
Очень забавная комедия. Очень понравилось как всё снято, какие декорации
и костюмы необычные (для нас) использованы. Кадры, где хрюшка поедает
автомобиль, показанные типа просто так: запоминаются. Да и вообще
животных в фильме много, что тоже приятно.
Sergey Matveev [Sat, 18 Jan 2025 14:53:48 +0000 (17:53 +0300)]
Начинаю делать enveloped-data аналог
http://www.keks.cypherpunks.su/enveloped_002ddata.html
http://www.keks.cypherpunks.su/signed_002ddata.html
Не смотря на то, что KEKS ещё так себе покрыт тестами, особенно его
"PKI" часть, но приспичило меня всё же продумать формат для шифрования
на его основе.
Аналог подписанных данных (SignedData CMS, PKCS#7) у меня уже имеется.
Аналог X.509 сертификатов тоже. Главным отличием является то, что
сертификаты сами по себе являются signed-data документом. Нет разделения
на совершенно отдельный формат сертификата и совершенно отдельный формат
произвольно подписанных данных.
Это позволяет иметь несколько подписей над TBS-ом сертификата. Например
"выпустить" его как-бы несколькими CA, несколько якорей доверия иметь.
Совершенно нет уверенности что это может пригодиться и вообще здравая
идея, но возможность есть (никто же не мешает именно для сертификатов
сделать ограничение на кол-во подписей?).
Имя сертификата, его subject, это просто map со строчками. Map убирает
автоматом необходимость проверки дубляжа в записях. С ним удобнее
работать. Плюс позволяет всё же чуть более сложные чем ровно-одна-строчка
значения задавать, хоть какая-то простая структура.
Validity аналог вынесен за пределы TBS-а. Всё что CA-specific выносится
в аналог signerInfo подписи конкретной. Поэтому у меня в sigs, в tbs,
exp(iration) поле является тем самым validity. Это также позволяет
обновлять сертификат без смены его TBS-а, без затрагивания тела, в
котором, как минимум, могут идти только ключи и имя. Просто
добавить/обновить подпись от CA.
KeyUsage это ku поле, являющееся map-ом с NIL-значениями, что делает его
фактически set-ом строчек (ключей).
Сертификат может переносить несколько ключей. Но предполагается, что это
только и исключительно для случаев, когда надо их всегда для какой-то
задачи переносить вместе. Например в NNCP всегда вместе идут ключи DH,
ключи подписи, ключи для Noise-а. ku должен при этом содержать "nncp"
какой-нибудь в качестве контекста применения.
У каждого ключа есть идентификатор в виде UUIDv4. Рекомендуется его
генерировать детерминировано из хэша от структуры публичного ключа. Это
как-бы аналог subjectPublicKeyIdentifier.
Никаких серийных номеров. Никакой идентификации сертификата по
issuerAndSerialNumber. Даже в X.509 PKI это почти никогда не
требовалось, раз имелся SKID/AKID. Но всё же сам сертификат как-то надо
идентифицировать, а также иметь возможность переподписать, но чтобы
подпись была другой. Для этого в в подписе есть "cid" поле (certificate
identifier), тоже являющееся UUID-ом и контролируемое CA. Рекомендуется
использоваться UUIDv7 для него. Вот и идентификатор, и возможность его
обновить чтобы подпись поменялась, и ещё и дружелюбный к сортировке.
sid (signer identifier) в подписе является id публичного ключа
подписавшего сертификат. Аналог AKID.
Формат сертификатов у меня давно не менялся и им вроде все мы
удовлетворены. Используются сертификаты с ГОСТ Р 34.10 ключами (я
"стандартизовал" только 256A и 512C варианты, которые на скрученных
кривых Эдвардса).
Но для себя, в качестве proof-of-concept сделал и Ed25519-BLAKE2b
вариант. Обнаруживал (1be5aab3dae457709202ac4f0288b7953fe2fa93), что
правила валидации Ed25519 разнятся. Я просто сослался на zCach-овский
ZIP-0215. Долго не мог решиться: всё же использовать EdDSA/Ed25519 как
он описан в RFC всяких или же выпилить SHA2 из него и использовать
что-то более минималистичное и быстрое. SHA3, SHAKE? Skein мне так
нравящийся? BLAKE2b? Остановился на BLAKE2b. SHA3/SHAKE сами по себе
очень медленные в софте -- неприятно, но я считаю их лучше использовать
чем SHA2, особенно когда нужна NIST-approved совместимость. Skein всем
хорош. Как и BLAKE2. Я просто не смог найти хороших доводов/аргументов в
пользу того или иного. BLAKE2 всё же побыстрее будет. BLAKE3 например
уже, как по мне, слишком небольшой запас прочности имеет, из-за чего я
не хотел бы его для очень ответственных (для хэша) задач применять. В
итоге остановился на BLAKE2 и убедился что его заслуженно любят другие
криптографы. Но это добавляет немного геморроя: если в Ed25519
реализации сильно зашит SHA2 хэш, то придётся помучиться.
Правила формирования подписи в signed-data по сути идентичны SignedData
CMS. Не потому что они мне нравились, а просто потому что это вполне
себе адекватный и разумный несложный подход. Так же как и возможность не
переносить подписываемые данные внутри signed-data контейнера. Структура
подписи позволяет добавлять как и произвольные данные не защищаемые
подписью (например cer-loc поле в котором можно список URL-ов перенести,
которые чисто для информации), так и защищаемые.
А также есть prehashing режим, когда мы заранее указываем алгоритмы
хэширования и подписываем уже значение хэша в структуре. Но для
сертификатов этот режим не разрешён, что удовлетворяет EdDSA и его
предупреждениям о недостатках prehash режима подписи.
Хотел надолго отложить вопрос с продумыванием аналога для enveloped-data
контейнера. Ибо это всё сильно сложнее уже. Но что-то вот напрягает меня
(эстетически, так сказать) тот факт, что age не поддерживает
пост-квантовую криптографию, хотя его автор достаточно хорошо в ней
шарит и вообще реализовал crypto/mlkem и поддержку Kyber в Go TLS. А вот
GnuPG поддерживает всю эту тему.
И решил форсировать процесс продумывания enveloped-data и написать для
себя готовый инструмент на замену age. Меня тоже достаёт что это, в
очередной раз, как будто проявление NIH-синдрома. Но мне в age ещё и не
нравился его "128-бит ключ" (4adf9b82dc1c86d787ca0a56f0d37b924877277c).
Ну и то, что он не чешется касательно PQ.
К формату файлов age у меня нет претензий никаких, но раз уж я занялся
KEKS-ом и его реализации довольно компактны, то это будет конечно же
KEKS структуры. Я смотрел на OpenPGP, многое помню про EnvelopedData
CMS, ещё раз посмотрел на age, HPKE. И кроме того, что вполне себе пока
удовлетворён предложенным enveloped-data форматом, но и начал писать Go
реализацию утилиты для замены age.
И сегодня я начал использовать KEM/DEM терминологию. DEM -- data
encapsulation mechanism, мне действительно больше нравится чем
"encrypted", ибо encrypted ничего не говорит об аутентификации или
проверки целостности данных. Типа слишком низкоуровневое слово. А DEM и
короткое и уже известное в криптографических кругах. Так же как и KEM
(key encapsulation mechanism), который не намекает на детали
"инкапсуляции" ключа, ни на какие DH или прочее.
Данные шифруются CEK (content encryption/encapsulation key) -- термин из
EnvelopedData CMS. А дальше CEK "передаётся" одному или более
получателям. В age они названы получателями. Я же просто обозвал KEM-ами.
Ибо при использовании шифрования на пароле -- как бы никакого получателя
нет. Но при этом scrypt/bcrypt/Argon2/whatever может сформировать KEM.
Алгоритм шифрования данных (DEM) независим от используемых KEM.
Пока я реализовал только ChaCha20-Poly1305 шифрование. Бьём на кусочки,
каждый шифруем/аутентифицируем, в nonce не забываем сигнализировать о
последнем кусочке шифротекста, чтобы его нельзя было обрезать. Но не
забывал про возню (6529c5c19cb52f69f65fec3d17e718cc491d2c53) с key
commitment-ом. Для ряда KEM-ов, которые явно согласовывают/инкапсулируют
ключи, как и в age, отсутствие key commitment не несёт проблем. age не
даёт возможности использовать не ChaCha20-Poly1305, в отличии от моего
формата. И в теории может появится какой-нибудь KEM, которому бы key
commitment не помешал бы. Почитав всяких статей, решил добавить
простейший key commitment пригодный для ChaCha20-Poly1305: добавляю
128-бит нулей перед шифруемыми данными, которые я должен проверить после
расшифрования. Это overhead, но я считаю терпимым, плюс тривиальная
реализация.
Для шифрования на пароле я добавил balloon-blake2b KEM. scrypt из age я
считаю удовлетворительным для хороших парольных фраз, но не спроста же
начали Argon2 конкурс, чтобы иметь что-то более серьёзное. Argon2 меня
более чем удовлетворял бы, но мне он не нравится тем фактом, что это не
алгоритм используемый поверх произвольного хэша. Например у нас доверяют
Стрибогу, а Argon2 это Argon2. Я поклонник Balloon алгоритма, который
просто описывает какие действия надо над произвольным хэшом сделать,
дабы получить усиление пароля. Он появился позже Argon2, но его научные
статьи говорят о том, что всё равно в Argon2 нашлось что-то там не
ладное, а Balloon закрывает все проблемы. Нашей страны это не касается,
но в США (0ddca657ed629fa8458a471d7655d3bd63c6facc) Balloon вообще
NIST-ом рекомендован. В качестве хэша предлагается BLAKE2b, чтобы уж
везде по минимуму зоопарк хэшей был в проекте.
Для шифрования по публичному ключу добавил sntrup4591761-x25519-blake2b.
Собственно, чистый/голый Curve25519 не буду использовать, а только
гибридную версию с пост-квантовым алгоритмом. Почему не ML-KEM или
Kyber? Потому что, следя за рассылками по криптографии, читая DJB, у
меня мало доверия к NIST-у. Я думаю что ML-KEM достаточно безопасен, да,
но, как и в случае с SHA3 и AES, они выбрали алгоритм далеко не с самым
хорошим запасом прочности. А вот к алгоритмам от DJB (+компания) у меня
ни йоты претензий. К тому же, по факту, Streamlined NTRU Prime 761 у
меня используется уже не один год по много раз в ведь из-за OpenSSH. В
нём нет RSA, ECDSA, AES, но есть SNTRUP.
Почему sntrup4591761, а не sntrup761? Только по причине того, что я
нашёл одну реализацию (sntrup4591761) на Go. Разница между ними только в
чуть более компактном кодировании данных (экономия в десятки байт, на
фоне более чем килобайта), последний чуть компактнее. Во всём остальном
они полностью идентичны.
Как объединить результат работы SNTRUP и X25519? Вообще в PDF-ке SNTRUP
намекается на допустимость просто хэширования их секретов. OpenSSH так и
делает, как и TLS. Но даже мне очевидно, что не помешало бы, на всякий
пожарный, захэшировать бы и публичные ключи участников хотя бы. DJB в
рассылке это тоже рекомендует, дабы не заниматься доказыванием что и без
этого всё нормально. ML-KEM, кстати, в отличии от Kyber, отличается
отсутствием хэширования дополнительных данных, чем он мне тоже не
понравился. X-Wing (135afdcb923cd9463751d5766279c8426ee6ab00) тоже
делает хэширование ключей. Учитывая производительность современных
Kyber/X25519, а также килобайтные размеры PQ-ключей, стоимость
хэширования становится отнюдь не нулевой, но я бы не экономил на этом.
CEK ключ шифруется выработанным из KEM-а KEK-ом (key encryption key).
В моих случаях это, опять же, ChaCha20-Poly1305, с добавленным padding,
просто чтобы не думалось.
Принципиально это всё не отличается от того, что происходит в age. Но он
из file-key отдельно вырабатывает CEK и ключ для расчёта MAC-а над всем
заголовком. Пока я не увидел хороших аргументов зачем это надо. Да и я
бы и не хотел делал список KEM-ов immutable.
Откладывал я тему с enveloped-data по причине того, что его же грамотно
нужно бы ещё и совмещать с signed-data. То бишь иметь возможность делать
не просто encrypt и sign, а (55c0fea0eaa0b13b63e85c1a21afee4ed02f8ad9),
так называемый, signcrypt. Чего ни age, ни CMS, ни S/MIME, ни куча
других форматов не делают вовсе.
Пока достаточно хорошим решением вижу создание, так называемого,
binding-а в структуре enveloped-data, являющегося UUID-ом. И при
создании вложенного signed-data предполагается указывание
envelope-binding внутри подписываемой структуры. Таким образом мы явно
связываем подписываемый документ с конкретным будущим envelope. Плюс
binding участвует в вычислениях всех KEM-ов, явно привязывая их к
конкретной посылке.
Сам шифротекст можно вложить и в enveloped-data. И я решил сделать это
поле чисто BLOB-ом, размер кусочка которого будет специфичен для каждого
DEM-а. Для chacha20poly1305 с 64KiB кусочками это будет 64KiB+32 байта.
Однако мои текущие реализации библиотек не вернут мне управление, пока
полностью от и до не прочитают весь KEKS файл. А я хочу у себя
перешифровать age-файлы на много гигабайт. Никто же не мешает эти данные
предоставить отдельно (detached), независимо от структуры, как это можно
в EnvelopedData CMS и age? Поэтому ciphertext поле у меня опционально. И
мои текущие реализации KEKS библиотек просто декодируют KEKS структуру,
а дальше можно будет продолжать обрабатывать данные после неё из
io.Reader/файла.
На ГОСТовых алгоритмах ещё не делал спецификации, но с CMS на их основе
я много работал и не помню чтобы там были не вписывающиеся, во всё мной
придуманное, особенности.
Sergey Matveev [Fri, 17 Jan 2025 10:44:24 +0000 (13:44 +0300)]
XWingLabel
https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/
Есть такой алгоритм X-Wing, описывающий как использовать гибридный KEM.
А назван он так не просто так, ибо в 5.3 секции:
Sergey Matveev [Fri, 17 Jan 2025 10:31:25 +0000 (13:31 +0300)]
Eliminate the state! призыв в SPHICS
https://sphincs.cr.yp.to/eliminate.jpg
https://sphincs.cr.yp.to/
В алгоритме подписи SPHINCS прям разъясняется что же это за "state"
такой и что речь не про государства.
Sergey Matveev [Fri, 17 Jan 2025 07:38:16 +0000 (10:38 +0300)]
Что нужно для получения "современного" терминала
https://jvns.ca/blog/2025/01/11/getting-a-modern-terminal-setup/
Человек пишет о том, что такое в его понимании "modern terminal".
Ему важно, чтобы работали Ctrl+стрелочки. Судя по тексту, проблема в
macOS, в которой нет GNU Readline к которому он привык. В моём случае
проблемы с libedit vs readline vs whatever решились тривиально: просто
использую vi режим редактирования везде.
Не понимаю зачем 24-бит цвета. Но это на вкус и цвет, а так то ничего
против hicolour поддержки не имею.
Но в остальном у меня полностью удовлетворяет всем требованиям этого
человека. Ну и кроме "automatic terminal fixing" -- по мне так не ясно
как компьютер, со всеми этими Unicode и шрифтами, может понять что
что-то пошло не так.
Автор критикует oh-my-zsh. Солидарен с ним во всём. Я никогда его не
рекомендовал бы.
Sergey Matveev [Thu, 16 Jan 2025 18:44:10 +0000 (21:44 +0300)]
Умер Дэвид Линч
https://lenta.ru/news/2025/01/16/umer-rezhisser-i-stsenarist-devid-linch/
https://ru.wikipedia.org/wiki/%D0%94%D1%8D%D0%B2%D0%B8%D0%B4_%D0%9B%D0%B8%D0%BD%D1%87
Запоминающимся режиссёром он был! Есть друг, который водил на первом
свидании девушку на "Маллхолланд драйв" -- в последствии стали супругами.
Его "Внутренняя империя" -- самый взрывающий мозг фильм из всех что видел.
Помню, что понравился и впечатлился "Головой-ластиком". Но все эти фильмы
не из тех, что хотелось бы пересматривать: ибо очередной взрыв головы.
Впрочем, он любит очень привлекательных женщин снимать ("Маллхолланд
драйв" например), на что можно переключиться с попыток понять сюжет.
"Синий бархат", "Шоссе в никуда" тоже помню что понравились.
Но вот "Твин Пикс" не любил, ибо это какая-то never ending story. Не
люблю такое. Это один из последних сериалов который смотрел, после чего
зарёкся тратить на них время.
Sergey Matveev [Thu, 16 Jan 2025 12:11:09 +0000 (15:11 +0300)]
Барабанщики и VK Видео обошёл YouTube
https://habr.com/ru/companies/sportmaster_lab/articles/874130/
https://lenta.ru/news/2025/01/16/vk-video-oboshel-youtube-po-chislu-ezhednevnyh-polzovateley/
Читая статью на Хабре про путь барабанщика, где есть несколько ссылок на
видео в VK Видео, посмотрел их с этого хостинга. Отметил необычность
ввода ссылок не на YouTube для yt-dlp. И сразу же появляется новость о
том, что он обошёл по числу пользователей YouTube.
И похоже что видео игры барабанщиков я смотрел гораздо больше и чаще чем
гитаристов или целых концертов. Завораживают они все своим мастерством.
Sergey Matveev [Wed, 15 Jan 2025 18:33:20 +0000 (21:33 +0300)]
FreeBSD для самых маленьких
https://linkmeup.ru/podcasts/2734/
Вышел тут подкаст с рассказом про FreeBSD. Что любопытного для себя
услышал?
Почему Netflix использует для своих 400/800Gbps серверов раздачи видео
именно её, а не GNU/Linux-ы? Да потому что проще поправить её код, в том
месте где бутылочное горлышко, из-за простоты и даже академичности кода,
чем копошиться в ядре Linux.
Снова упомянули, что в Яндексе полно FreeBSD машин, никуда они не
пропадают, что и видно по тому, что они продолжают коммитить в ядро.
PostgreSQL собирается для FreeBSD даже раньше официального релиза и
именно FreeBSD у них используется как лакмусовая бумажка для нахождения
странностей и проблем: типа если что-то пошло при тестах не так, то это
уж наверняка проблема в самой СУБД, нежели чем в ОС, чего про GNU/Linux
нельзя сказать.
Jail-ы в FreeBSD приятны и хороши. Кто-то ставит Docker как пример того,
что есть в GNU/Linux, но только надо не забывать, что jail-ы появились
уже с 2000-го года.
ZFS, как известно, появился в Solaris. Потом портировали в FreeBSD.
GNU/Linux тоже захотел такое и начал пилить свой ZFS-on-Linux, где
паршивое качество кода, баги и всё плохо. Но много дополнительных фич,
да (вот правда зачем они, если это всё криво работает? только линуксоид
сможет понять наверное). Собрались умные дядьки и решили объединиться в
OpenZFS, где львиная доля ZFS общая для всех, а дальше только, так
сказать, разные API интеграции в ядра ОС. И только с вхождением
BSD-шников в OpenZFS, баги начали правится, всё начало стабилизироваться
и работать. Ну и сама FreeBSD тоже стала использовать уже OpenZFS.
Sergey Matveev [Wed, 15 Jan 2025 09:49:29 +0000 (12:49 +0300)]
Криптография в Session IM
https://soatok.blog/2025/01/14/dont-use-session-signal-fork/
https://getsession.org/session-protocol-explained
Про свой первый взгляд на Session я уже писал в 089bf4d15b98749dc24ee1bb149c53e080e86837. Но на протокол и криптографию
не смотрел. А тут, оказывается, эти ребята вообще решили выпилить и PFS
и deniability свойства. По мне, для IM-а, так этого с лихвой достаточно
чтобы не рассматривать это решение и дальше, ибо ужас.
Но, судя по предоставленным кускам кода в статье, при генерировании Ed25519 ключей, они используют всего 128-бит энтропию, вместо ~256 бит.
То есть понижая безопасность 25519 до уровня пригодного для brute force
(причём, видимо, даже сейчас на практике).
Думаете, так обосраться было мало? Session постарался. Подписи в
сообщениях проверяются напротив публичного ключа, приложенного к этим же
самым сообщениям. То бишь, они просто по сути проверяют их целостность.
Даже протокол Telegram уже кажется куда более безопасным чем это.
Но они пошли дальше: в качестве симметричного ключа в сообщениях
используется публичный ключ корреспондента. Это фиаско хуже некуда.
В общем, Session это просто лютейшее говно к которому ни в коем случае
нельзя прикасаться. Даже Tox, с его проблемой KCI во время рукопожатия,
просто непробиваем по сравнению с этим.
Sergey Matveev [Wed, 15 Jan 2025 09:35:38 +0000 (12:35 +0300)]
Декодируя 802.11ah
https://destevez.net/2025/01/decoding-ieee-802-11ah/
Автор декодировал сабжевый трафик от "baby monitoring system" (не знаю
как это у нас называется) через SDR. Самое интересное для меня было в
конце, где трафик был зашифрован CCMP (WPA2), но с одним и тем же
вектором инициализации! В CCMP/CCM шифрование происходит в режиме
счётчика, для которого повторение IV фатально. То есть безопасность
такой передачи вообще никакая.
Именно поэтому я вообще не доверяю никоим образом WiFi шифрованию. Есть
места где там можно легко облажаться или же просто через задницу всё
реализовать, что неоднократно демонстрировали на практике всякие
китайские решения. Причём одинаковый IV то ещё можно в tcpdump увидеть,
но плохое качество PRNG уже не тривиально выяснить. Даже если вся
криптография происходит через программный стэк внутри встроенных в WiFi
Linux-ов, то доверия к качеству их разработчиков нет аналогично.
Поэтому, зачастую, нужен VPN поверх подобных беспроводных решений.
Sergey Matveev [Tue, 14 Jan 2025 13:24:10 +0000 (16:24 +0300)]
Некоторому моему софту ведь уже не мало лет
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-ом. Как быстро летит время!
Sergey Matveev [Mon, 13 Jan 2025 15:12:22 +0000 (18:12 +0300)]
Сходил на Carmina Burana Карла Орфа
https://ru.wikipedia.org/wiki/Carmina_Burana_(%D0%9E%D1%80%D1%84)
в консерватории им.Чайковского. Удивили две вещи. Как оказалось, я
совсем забыл, но я полностью прослушивал это произведение (не только его
"O, Fortuna" известную всем) и почти всё было сильно знакомо. Плюс
забыл, что вообще-то там вообще весёлые и заводные части имеются, не
только мрачняк типа Фортуны. Ожидал мрачного: получил лёгенькое такое
даже полу-попсовое произведение. Очень понравилось, но повторно уже
наверное только за компанию сходил бы. В отличии от Реквиема
(ec33ecd37983d8ad4ffeae49bf2408a0ce8ef62d), поднимавшего волосы на всех
частях тела и вгонявшего в такой мрак. На выступлении был ещё и очень
заводной дирижёр, который чуть ли не в пляс готов был пуститься.
Sergey Matveev [Mon, 13 Jan 2025 15:09:39 +0000 (18:09 +0300)]
Погуляли в центре новогодней Москвы
Как и в прошлые года, всюду всё наряжено, гуляния и куча народу. На
Красной Площади много ларьков оформлены по тематике советских фильмов
типа Операции Ы, Джентльменов Удачи и подобных известных, плюс места с
воссозданные оттуда сценами где можно пофотографироваться. Все очень
одобрили умения дизайнеров. Ну и погода была хороша: без ветра, не
жарко, но и не холодно.