Sergey Matveev [Sun, 23 Mar 2025 13:02:49 +0000 (16:02 +0300)]
Сходил на Only Fetish Fest: Black Metal Time
Всё же для меня человечество ещё не придумало в музыке ничего лучше чем
black metal. Много я куда ходил, но не сравнится оно с интересным и
добротным блэком.
В этот раз не было московских групп. Открывали мероприятие, прежде мне
не известные, Уводь из Удомли. Хороший такой блэк, всё по трушному. Уже
на этой группе понял, что не зря выбрался из дома. Не однообразный,
интересный. И, по сути, единственный кого точно можно к этому
направлению в музыке причислить, среди всех выступавших.
Продолжили Cage Of Creation из Суздаля. Два года назад в 91bf686031eb868a0d3b0f5dddcb2db9bf977c9d уже писал о них и ничего нового
не добавлю: интересное и мелодичное. Но к black сложно причислить, лишь
моментами.
Затем шла единственная группа мне известная из Новосибирска -- Olshanoe.
Я не продолжаю удивляться: огромный город, развитый, культурный, но
метал групп из него вообще прям нет, что мне и подтвердил экскурсовод
когда там был. Вокалист представлял группу ставя ударение на втором
слоге. Пожалуй больше всего она мне и понравилась. Очень атмосферная,
почти всё время и спокойная, хотя и элементы быстрого рубилова тоже
присутствовали. Плюс несколько раз вместо электрогитары наяривал их
вокалист на баяне. Более чем его звук сочетается с метал инструментами.
Заканчивали сие мероприятие Passéisme. Полная противоположность
умиротворяющему спокойствию Olshanoe. Сплошное сверхскоростное рубилово
похлеще чем в грайндкоре. С кучей риффов напоминающих русские народные.
Под них активный слэм и шёл. Такой, что буквально ботинки слетали с людей.
Между своими песнями они вставляют спокойные французские медляки
старенькие, под которые брутальные слэмоводы мигом образовывали пары и
вальсировали, заставляя ржать вокалиста.
Перед Passéisme ко мне подошёл какой-то человек и спросил кто для меня
является headliner-ом. Сам он пришёл на Passéisme. Olshanoe ему вообще
не понравилась. Сзади меня я слышал разговоры, что кто-то только ради
Cage Of Creation посетил. Этим мне black (и его смежные направления) и
нравится: он очень разнообразен. Ну и на вкус и цвет -- товарища нет. Я
то точно в восторге от Olshanoe, а на Passéisme, если не поколбаситься,
то не пошёл бы снова.
Прикупил дюжину дисков, футболочку. Only Fetish Fest это прям уже имя
нарицательное интереснейших сборных солянок из музыки, а не повторение
одного и того же раз за разом.
Я думаю, что Vim многих отпугивает тем по началу, что если его
запустить, то увидишь голое окно. И типа... и это всё? В отличии от
приборной панели шаттла как в GUI IDE всяких. Конечно же причина тут
одна: минимум ненужной и явно не запрашиваемой информации. В современных
Microsoft Office же даже делают снимки экрана, показывая чуть ли не с
полдюжины панелей с кнопочками, которые занимают почти четверть экрана
рабочего. Но под капотом Vim скрывается практически самый мощный
редактор текста, инструмент для работы с текстом, коим являются все наши
программы, письма, документация.
Вначале все познают базовые команды по передвижению по тексту и
редактированию. Я уже тебе на словах говорил, что это, как правило,
команда (yank, delete, change, follow, и т.д.), после которой идёт
motion (слово, СЛОВО, внутри слова, предложение, абзац, внутри кавычек,
внутри скобок, и т.д.). Перед этим может идти указание кол-ва повторов
команды. "Удали ка мне три слова с окружающими их знаками препинания".
Если суммарно команд в каком-нибудь Блокноте или IDE от силы 2-3 десятка
наверное наберётся, то в Vim их сотни.
Вместо нажатия "влево, влево, влево, удалить букву, ещё раз", ты будешь
стараться делать "перейди на начало предыдущего слова, удали до его
конца слог". И это нужно для того, чтобы можно было повторить действие,
нажатием точки. Если твоим действием было "удалить букву", то с этим
много не сделаешь полезных повторов, а "удали слово" -- уже будет
актуально для многих контекстов применения. Так начнёшь пользоваться
макросами: это буквально запись твоих действий. Например тебе надо из
конца предложения найти вторую фразу с конца, но которая в кавычках,
переместить её в начало предложения, сменить кавычки на скобочки, и
внутри все слова поменять с camelCase на kebab-case, плюс порядковый
номер в начале строки увеличить на единицу. Всё это будет сделано одним
макросом, в котором каждое высокоуровневое действие у меня точками
разделено в описании. Подобные вещи сплошь и рядом встречаются во время
рефакторинга того же.
Сколько буферов обмена в Windows? Я им конечно пользовался в последний
раз четверть века назад, но вроде бы больше одного у них не стало. В X11
(графическая система в UNIX-ах) их два. А в Vim их больше трёх десятков.
Найди мне среди строк начинающихся с описания вот такого вот класса,
заканчивающихся на docstring в конце класса, строки описываемые такой то
регуляркой, и примени к каждой строке макрос который мы только что
написали в предыдущем абзаце, но при этом оригинальные версии строк
добавляй ка в регистр "m". Всё это делается одной командой в командной
строке Vim. Зачем всё сохраняли в регистр m? Чтобы из него удобно
сформировать changelog для нашего log message коммита, чтобы потом не
выуживать вручную их git diff-а.
Нашли запоминающиеся места в нашем исходном коде, о которых не надо
забывать и быстро между ними перемещаться? В Vim есть метки, по которым
можно как в Wikipedia моментально перемещаться. Вернутся на последнее
изменение? Вернутся на последнее место с которого мы сделали jump из
другого файла? Всё это пара нажатий клавиш. Посмотреть список последних
сделанных высокоуровневых изменений и среди них выбрать вот то 20-е, где
я правил странный метод в другом проекте? Пожалуйста, пара команд.
Как угодно делать mapping клавиш и слов? Я не пишу "и т.д.", а пишу
"итд", который автоматом раскрывается. Тьма команд у меня тоже
сокращены, заалиасены. У каждого тьма сокращений и мини команд
накапливается. Например если мне надо "обернуть" какую-то переменную в
скобочки, то я парой нажатий оборачиваю слово в кавычки, а дальше ещё
парой нажатий меняю кавычки на скобочки. Звучит как двойная команда,
много нажатий, но это занимает доли секунды, ибо на рефлексах всё.
Кто-то может считать, что идеально когда минимальное количество нажатий
клавиш делается. Я убеждён что нет: более длинные последовательности
рефлекторно отработанные могут быть эффективнее. Плюс многие действия
могут быть менее эффективны для конкретного узкоспециализированного
здесь-и-сейчас случая, но зато их можно будет удобно применить в макросе
или хитрой команде командной строки Vim.
Про повтор действий/команд многие пишут, но многие умалчивают что в Vim
есть, очевидно, и отмена действий, но организованная в виде дерева
изменений. Такого вроде нет ни в одном редакторе. У всех история
изменений по которой можно туда-сюда перемещаться линейна.
Искать текст по всякому, подсвечивать, перемещаться по меткам, в том
числе среди множества файлов -- это всё банально. Vim умеет перемещаться
по тэгам. Тэги это по сути аналог индекса из СУБД. Это отдельные заранее
сгенерированные файлы. Хочешь прыгнуть на определение функи под
курсором, или по названию -- два нажатия клавиш. Название фунок
совпадают/похожи с названиями переменных или констант? Два нажатие и
тебе меню с выбором куда ты хочешь перейти. Это возможно единственное
что умеют IDE в отличии от тупых редакторов (Nano, Блокнот, и подобных).
Но более того: поддержка навигации по тэгам появилась не в Vim, а в Vi,
который был задолго до него (просто любопытный факт насколько старая эта
фича (вовсю в 1980х), которой так любят хвастаться современные IDE из
2020-х :-)). Причём я вот как-то себе делал Zettelkästen систему, где
проще простого было написать скрипт, который бы генерировал бы файл с
тэгами для моего формата заметок, чтобы я в Vim мог как в броузере
прыгать по заметкам как по ссылкам.
В Vim есть jump-list и quickfix-list. Это отдельные окошки в которых
зачастую выводят результат работы поиска типа grep или git grep. Или там
выводят список ошибок во время компиляции или linter-а. По которым можно
удобно перемещаться и прыгать. А можно одной командой выкинуть ошибки
связанные с PEP8. А второй командой для каждой ошибки linter-а во всём
проекте применить команду комментирующую проблемную строку или например
сразу исправляющую вызов os.exit на os_exit например. Выставить пометки
рядом со словами или строками о проблемах -- тоже пожалуйста.
Подключить LSP плагин для работы с LSP сервером и получить по сути весь
per-language функционал для рефакторинга и linting-а? Без проблем. Иметь
автодополнение методов или аргументов? Показывать сигнатуры функций во
время набора кода и сразу же lint-ить? Все эти свистоперделки и полезные
вещи (опять же, которыми любят хвастать IDE) включаются на раз два.
Конечно же в Vim есть возможность показывать множество окон и как угодно
тасовать/изменять их. Есть и табы, хотя лично я не вижу в них смысла,
особенно при использовании мультиплексора терминала. Хочется сохранить
полностью от и до всё размещение окон, табов, курсора, содержимого
регистров и jump/change-списков? Одной командной Vim может сохранить
файл с сессией и одной командной продолжить эту сессию. А можно
сохранить только расположение окон/файлов, для часто используемого
проекта.
Отредактировать кусок кода изолированно в отдельном буфере/окне? Без
проблем. Скрывать часть текста, чтобы глаза не мозолил? Скрывать
определённые символы (ну например URL при редактировании Markdown, чтобы
только название ссылки оставалось)? Выводить всплывающие окна рядом с
курсором или словами? Все есть из коробки.
Молчу про многие сотни опций и настроек. Даже такой мелочи как добавлять
ли пробел после объединения строк или нет? Оставлять ли отступ после
ввода перевода строки? Но я молчу про это, молчу ибо слишком много.
Мы вроде с тобой использовали не просто вставку из файла, а вставку
вывода команды -- это частое действие.
Возможность проверки орфографии? Из коробки, встроена. Ну только словари
подложить надо.
Vim может быть запущен в режиме сервера и из командной строки в него
можно посылать команды. Например ты в терминале видишь вывод Python
traceback-а и можешь послать команду на открытие уже запущенного Vim-а
заданного файла на данном месте с подсветкой проблемного слова. А можно
редактировать файлы по прозрачно запущенному SSH на удалённой машине. А
можно и прямо в Vim запустить терминал и в нём работать, прямо на месте
выуживая или редактируя вывод программ.
Открывать и искать файлы как в эффективном shell-е, не задалбывая Tab
для автодополнения? Всё можно. Но ты наверное ещё тут не в теме, так как
и в shell ещё не использовал эффективное перемещение по директориям и
поиск/выбор файлов. В Vim я себе делал fuzzy-matching файлов как в zsh,
всё возможно. А может быть для поиска или выбора файлов хочется
буквально использовать fzf (https://github.com/junegunn/fzf) -- легко.
Интегрироваться с tmux мультиплексором терминала и общаться с его
встроенными буферами обмена? Плагин на пару экранов кода, без проблем.
Автоматическое форматирование текста, перенос строк, соблюдение отступов
в многоуровневых списках? Всё из коробки, настраиваемое. Зависимое от
языка комментирование строк и снятие комментариев? Пара нажатий. Ведь не
везде же достаточно добавить "#" в начало строки, а надо обрамлять и с
начала и с конца "/*" какими-нибудь.
Запустить компилятор/сборку, отловить ошибки в выводе, заполнить ими
quickfix окно -- при должной настройке из пары команд это можно сделать
вызовом :make. Из коробки, всё заточено под дружелюбность к разработчику.
Иметь возможность навешивать hook-и и автоматически выполняемые команды
на разных действиях? Без проблем. Например когда у меня открывается
письмо (email), то у меня сразу из цитируемого содержимого вырезается
подпись человека и курсор сразу же перемещается после конца цитаты.
И я ещё даже не упомянул про чуть ли не самую важнейшую часть Vim: его
встроенный язык программирования. Конечно, обязательно многие про свои
Atom, PyCharm, VSC могут начать говорить что там тоже можно писать на
JS/whatever и добавлять/изменять функционал. А теперь покажите мне хоть
одного человека кто это бы делал на практике. На этом "а у нас так тоже
можно делать" можно закрывать. Если бы было РЕАЛЬНО удобно и легко это
делать, то делали бы. А вот в Vim его язык очень интегрирован с самим
редактором и на vimscript регулярно и постоянно пишутся какие-нибудь
плагины многими людьми под свои нужды.
Разбить длинную сигнатуру функи на много строчек с корректным indent,
соблюдением нетривиального формата Python "foo: [bar, baz]", с
добавлением всех нужных запятых в конце? Написал плагин. Добавить все
недостающие import-ы о которых нам сказал linter из quickfix окна,
основываясь на статистике их применений через банальный git grep вызов?
Написал плагин. Открывать файлы которые указаны как
путь/к/файлу:строка:столбец? Что часто выдаётся компиляторами. Написал
плагин. Добавить дополнительные интерактивные команды для навигации по
indent-ам в тексте, что часто нужно в Python коде? Написал плагин.
Подсвечивать не человековводимые Unicode символы, которые могут
представлять опасность? Написал плагин. Выравнивать удобно по всяким
вертикальным разделителям? Написал плагин. Находясь в произвольном месте
unittest метода Python, нажать пару клавиш, чтобы в буфере обмена
оказался полный python-path вида path/to/file:TestCaseName.test_method?
Снова плагин. Тоже самое делать для Си кода, чтобы в буфере обмена
оказывалась строчка пригодная для вставки в отладчик, чтобы он
останавливался на строке где курсор? Плагин. И почти все вышеназванные
плагины написаны что-то типа за десятки минут или пару часов. Это не
очередной долбанный framework с которым нужно хорошенько пострадать
чтобы от него добиться того, что ты хочешь, а это инструмент сделанный
программистами для программистов, чтобы делать новые инструменты и
программы :-)
Когда-то можно было услышать критику vimscript: мол он странно выглядит
и не удобен. Не спорю: даже перенос строк в нём выполнялся добавлением
слэша в начале строки. И нельзя было в конце списков/словарей оставлять
запятую. Эти времена в прошлом, так как уже не мало времени существует
vim9script, который уже полностью похож на современный и привычный нам
язык программирования. Почти все мои плагины были написаны ещё на старом
vimscript, но я всё полностью перевёл на vim9 -- он хорош.
А кроме самого языка, Vim может и запускать асинхронные задачи. Есть как
в Go и каналы для коммуникации между асинхронными процессами. Сделать
instant messenger внутри Vim? Да я десятки видел и пробовал, не проблема
уже 20 лет назад была.
Из коробки интеграции с Git нет, но есть замечательнейший плагин
fugitive, без которого многие из нас не представляют уже возможным
разрешение конфликтов. Не скажу что он супер-пупер выделяющийся, но он
сильно помогает при работе с Git. И, в отличии от IDE, не скрывает его
от пользователя, ограничивая его действия или скрывая важные
предупреждения и сообщения.
И из коробки в Vim есть инструмент для сравнения, создания, отображения
и вообще работы с diff-ами. Видел в блогах что не редко Emacs
пользователи используют именно vimdiff для визуализации и правки
diff-ов, а не свой родной Emacs. Может что-то уже и поменялось и у них
появились свои достойные решения.
Как минимум vi, есть на любом уважающем себя UNIX. Поэтому, зная хотя бы
vi ты сможешь эффективно править конфиги на серверах во время
администрирования. Работая в командной строке, в zsh, в bash, whatever,
ты всегда одним нажатием можешь вызвать vi/vim для редактирования
многострочной строки в вызванном редакторе. Работая в PostgreSQL, введя
\e в его psql клиенте, ты будешь редактировать SQL запрос в Vim. Я
наверное лет 20 в самом окне web-обозревателя уже ничего не редактировал
и одним нажатием у меня вызывался Vim чтобы отредактировать textarea,
которая вставится назад в web после выхода из редактора. Мало кто из
опытных пользователей набирает/отвечает на почту в окне почтового
клиента: для этого де-факто всё равно будет вызываться внешний редактор
(типа Vim или Emacs). *Любой* POSIX совместимый shell по стандарту
обязан иметь два режима редактирования командной строки: либо vi, либо
emacs. Других вариантов нет. Огромная часть интерактивных CLI программ
реализует свой интерфейс через libedit или GNU readline, оба из которых
имеют возможность использования vi режима. Это не полноценный vi(m)
редактор, но базовые команды там будут одинаковы. То есть, почти всё в
UNIX мире, на котором строятся все современные серьёзные решения, ЦОДы,
сети, backend-ы и HPC -- имеет только два режима работы с пользователем:
или vi или emacs. Другого не дано, ибо за ~35 лет никто не изобрёл
ничего хотя бы отдалённо лучшего.
Если что, то в Vim одна из самых лучших документаций что я встречал. С
введением безумно дружелюбным к пользователю, даже с графическими
объяснениями (чего не было в документации в моё время когда я начинал им
пользоваться).
Но начать стоит с получасового vimtutor (это прям команда в терминале),
после которого ты сможешь уже без проблем использовать редактор где бы
то ни было.
От меня есть важнейший (как я считаю) совет: не усердствовать с
визуальным режимом выделения текста ("v" команда), не злоупотреблять ею.
Для начала вообще забыть про её существование. Ибо я со стороны видел,
что именно из-за неё люди убивают почти все возможности редактора типа
повторение действия, создания макросов или выполнения команд в ":g".
Визуальное выделение это уже не высокоуровневое действие, а буквально
"выдели вот ровно вот именно такой длины строки/символы". Но тянуть к
нему будет, так как в Microsoft Windows программах стрелочки с зажатым
shift-ом используются крайне часто.
Ну и рекомендую сразу же включить режим показа относительной нумерации
строчек. 5ff1b3c8c76be6e7691defe34a7e18c4d753f4f2
Без этой фичи ещё будет проблематично совместно с кем-то работать, так
как сказать "на минус 19-ой строке забыл вот то то" можно моментально,
ибо на экране прям будет "19" число написано. А если бы были абсолютные
номера строчек, то они и трёхзначные бывают и просто устанешь
произносить их.
Есть большущий миф о том, что Vim нельзя использовать без массы
плагинов. Как человек с 20+ летним стажем работы в нём, знакомый с
другими опытными его пользователями с не меньшим стажем, однозначно
заявляю что это миф/бред/враньё. Чаще всего люди обвешиваются плагинами
только для того (иногда и сами того не понимая), чтобы из Vim сделать
другой редактор. Людям дают болид Формулы-1, а они сразу начинают
модифицировать его, чтобы сделать знакомый им Жигуль. Многие, включая
меня, проходили этот этап, когда 20-30 плагинов стояло. Но с годами об
этом только жалели, ибо многие из них только скрывают настоящую мощь
Vim, препятствуют гибкому использованию. Сейчас у меня 15 моих
собственных самописных плагинов: но они связаны или уже с выработанными
привычками или же для узкоспециализированных задач (особых языков,
форматов и прочего) -- тут я не вижу проблем в установке task-specific
помощников. Вот только для языков программирования есть LSP, поэтому
Python/Go/C/whatever-specific плагины вряд ли могут потребоваться, ибо
достаточно одного LSP клиента, ну и LSP-сервера для языка, который от
редактора уже никак не зависит.
Ещё можно найти много рекомендаций для новичков начинающихся с совета
установки менеджера плагинов. Это абсолютно устаревший и не имеющий
смысла совет, так как уже много лет назад в нём появилась встроенная
система пакетов, очень удобная.
Всё что я написал касательно Vim также наверняка полностью относится и к
Emacs -- второму из "профессиональных" редакторов. Хотя многие и не
считают Emacs редактором, а скорее чуть ли не операционной системой,
неким desktop environment.
Самое большое отличие между ними в том, что Emacs с самого начала был по
сути интерпретатором и окружением для работы с Lisp (свой диалект),
поверх которого как бы реализован редактор. Vim, в котором не сразу
появился vimscript, же это развитие Vi -- а Vi это просто редактор, без
какого либо встроенного языка программирования (VI VI VI -- editor of
the Beast :-)). Vim это редактор в который добавили возможность
программирования/расширения, а Emacs это наоборот штука для
программирования на Lisp, поверх которой, на которой сделали редактор.
Реализовать внутри Emacs-а почтовые и новостные клиенты, IM-ы и всякое
такое: это абсолютно штатное его использование.
Плюс главнейшая разность Emacs и Vi(m) как редакторов: в Vi используется
несколько переключаемых режимов работы (вставка, выделение, командный,
командная строка), тогда как в Emacs сплошные сочетания и комбинации
клавиш (Ctrl+то, Ctrl+сё). Физиологически за ними работается по разному.
И есть известный статистический факт: частота проблем с запястьями у
Emacs-еров существенно выше чем у пользователей другого редактора.
Коротко упомяну про shell-ы. Я видел как большинство новичков работают в
терминале. Собственно, как и все мы когда-то начинали. Постоянный cd
туда, cd сюда, ls и всякое подобное. Наверное возникает вопрос: и чем же
это удобнее чем тыкать мышкой в GUI проводнике или IDE? Ничем.
А удобнее это становится тогда, когда начинает использоваться эффективно :-)
Пока работа в режиме cd/cd/cd/ls/cd/cd/ls ничем не отличается от DOS, в
котором просто было мало ресурсов для чего-то более серьёзного.
Надо сразу понимать: есть shell который используется для исполнения
скриптов, а есть интерактивный shell, в котором ты, человек,
интерактивно с ним взаимодействуешь. Иногда эти две задачи может
выполнять один и тот же shell. Не редко два совершенно разных и
несовместимых. shell скрипты де-факто пишутся на POSIX shell, который
/bin/sh. Но например в FreeBSD по умолчанию для интерактивного
использования выставляется tcsh, который вообще не совместим с /bin/sh.
Многие писаются от FISH shell-а, который тоже никоим образом не
совместим с POSIX/bin/sh -- и это не страшно, ибо интерактивная работа и
скрипты это зачастую не пересекающиеся задачи.
Первое что узнают люди для хоть какой-то эффективной работы с
интерактивным shell-ом это автодополнение имён файлов и названий команд.
Никто не пишет "main.go", все напишут "ma" и нажмут TAB, который
дополнит имя файла (если нет коллизий) до "main.go". Это всё научились
делать shell-ы ещё в 1980-е, насколько знаю.
Второе что узнают: наличие истории команд. Хотя бы нажимать стрелочками
вверх/вниз. А затем узнают про Ctrl+r, в котором можно написать часть
команды и будет произведён поиск только по этой части. Например ты
помнишь что что-то вводил касательно "build". Ctrl+r, "bui" а дальше
тебе предлагают команду "go build", нажимаешь enter.
90% людей на этом и останавливается. Хотя это всё лишь только 5% от всех
возможностей современных интерактивных shell-ов. Что прискорбно и
удручает, видя как много времени теряется впустую на сплошную ручную
работу.
Исторически как бы существовало два больших семейства shell-ов: Bourne
shell и C shell (1978 появился). "sh" и "csh". POSIX shell это Bourne
shell. BASH это Bourne Again Shell (что читается как "born again", игра
слов). Не то чтобы Bourne shell чем-то был сильно удобнее и выделялся,
но просто так исторически сложилось, что именно он стал стандартом для
написания скриптов, так как появился первым.
https://en.wikipedia.org/wiki/Comparison_of_command_shells
Одним из самых продвинутых shell-ов (и для интерактивной работы и для
скриптоваяния) долгое время был Korn shell, появившийся аж в 1983.
Однако он был проприетарным (закрытым). Сейчас появились свободные
версии, но по сути после появления Z shell это уже не так актуально.
Хотя некоторые BSD системы используют ksh по умолчанию, который я очень
уважаю.
В tcsh (TENEX C shell) впервые появилась возможность дополнения имён
команд и файлов. В csh появилась впервые история команд,
дополнение/подстановка из истории, алиасы, стэк директорий посещённых,
~-нотация (~/ это домашняя директория например) которая сверх часто
используется. В tcsh это всё развилось ещё сильнее. Job control в csh
был почти с самого начала, тогда как в том же GNU Bash оно появилось
только в 1989.
Почти всё вышенаписанное перекочевало и в ksh, который был более менее
ещё и совместим с bourne shell синтаксисом, позволяя и удобно/привычно
скрипты писать и интерактивно работать. В нём появились ассоциативные
массивы как тип данных. Очень продвинутые возможности по подстановке и
перенаправлению всяких файлов. Иерархичные вложенные переменные.
Ссылочные переменные. И многое другое.
Сложно описать насколько более продвинут ksh/zsh/bash относительно POSIX
shell. Простейший пример: у тебя "foo | bar" команда в скрипте. Если у
тебя foo упадёт и вернёт плохой код возврата, то для POSIX/bin/sh кодом
возврата всей этой конструкции pipeline-а будет результат только bar.
Например bar это "grep". Если у тебя упал "foo", то с точки зрения
"grep" ему просто подали на вход пустоту, ничего ошибочного, всё
валидно, мы успешно выходим. Тогда как более продвинутые для
скриптования shell-ы имеют возможность "выкинуть" плохой код возврата
pipeline-а любой команды. Это делает скриптовании и куда безопаснее и
куда компактнее/короче без тьмы костылей.
Вот например табличка с сравнением некоторых возможностей разных
shell-ов, довольно старая уже, древняя можно сказать:
sh csh ksh bash tcsh zsh rc es
Job control N Y Y Y Y Y N N
Aliases N Y Y Y Y Y N N
Shell functions Y(1) N Y Y N Y Y Y
"Sensible" Input/Output redirection Y N Y Y N Y Y Y
Directory stack N Y Y Y Y Y F F
Command history N Y Y Y Y Y L L
Command line editing N N Y Y Y Y L L
Vi Command line editing N N Y Y Y(3) Y L L
Emacs Command line editing N N Y Y Y Y L L
Rebindable Command line editing N N N Y Y Y L L
User name look up N Y Y Y Y Y L L
Login/Logout watching N N N N Y Y F F
Filename completion N Y(1) Y Y Y Y L L
Username completion N Y(2) Y Y Y Y L L
Hostname completion N Y(2) Y Y Y Y L L
History completion N N N Y Y Y L L
Fully programmable Completion N N N N Y Y N N
Mh Mailbox completion N N N N(4) N(6) N(6) N N
Co Processes N N Y N N Y N N
Builtin artithmetic evaluation N Y Y Y Y Y N N
Can follow symbolic links invisibly N N Y Y Y Y N N
Periodic command execution N N N N Y Y N N
Custom Prompt (easily) N N Y Y Y Y Y Y
Sun Keyboard Hack N N N N N Y N N
Spelling Correction N N N N Y Y N N
Process Substitution N N N Y(2) N Y Y Y
Underlying Syntax sh csh sh sh csh sh rc rc
Freely Available N N N(5) Y Y Y Y Y
Checks Mailbox N Y Y Y Y Y F F
Tty Sanity Checking N N N N Y Y N N
Can cope with large argument lists Y N Y Y Y Y Y Y
Has non-interactive startup file N Y Y(7) Y(7) Y Y N N
Has non-login startup file N Y Y(7) Y Y Y N N
Can avoid user startup files N Y N Y N Y Y Y
Can specify startup file N N Y Y N N N N
Low level command redefinition N N N N N N N Y
Has anonymous functions N N N N N N Y Y
List Variables N Y Y N Y Y Y Y
Full signal trap handling Y N Y Y N Y Y Y
File no clobber ability N Y Y Y Y Y N F
Local variables N N Y Y N Y Y Y
Lexically scoped variables N N N N N N N Y
Exceptions N N N N N Y N Y
Не так часто делают просто переход cd, cd, cd. Или имеют алиасы для
директорий (например "cd ~pyg" у меня перейдёт в /home/stargrave/work/pygost),
или имеют стэк директорий и при перемещении добавляют директори в стэк,
позволяя одной командой (у меня это буквально одно нажатие клавиши)
перейти назад по стэку. "cd -" вернёт в предыдущее место.
tcsh (как и zsh) имел встроенный spellchecker и он мог исправлять
опечатки в командах или названиях файлов (но лично я не рекомендовал бы
такое, ибо у меня не раз случались губительные исправления).
Если пользователь набирает полностью снова целые слова или команды, то
скорее всего делает что-то не так и не эффективно. "!$" подставит
последний аргумент из последней команды -- эту штуку даже наши
технические писатели, которые сидят под Астрой и в Word, вовсю
используют. !:1 подставит первый аргумент из прошлой команды.
!!:gs/foo/bar выполнит заново предыдущую команду, но заменив в ней все
foo на bar.
Иногда ты точно не помнишь с чего начиналась команда, но помнишь что это
было связано с ffmpeg и blablabla фильмом. А тебе надо повторить команду
связанную с перекодированием видео. У себя я могу просто набрать "ffm
blabla", нажать кнопку "вверх" и у меня по сути будет выведен список
команд с поиском по ".*ffm.*blabla" регулярке без учёта регистра букв.
Набрав "s/2/r2s/auth/init" и нажав TAB у меня этот путь раскроется до
"src/rik2utils/rik2s/request_auther/__init__.py". Причём между слэшами
можно даже опускать написание букв вообще (зависит от наличия коллизий с
другими файлами/директорий, конечно же).
"**.mod" в ksh/zsh подставит все go.mod файлы проекта.
"**.php(.om[1]:h)" у тебя возьмёт все .php файлы рекурсивно из всех
поддиректорий, отсортирует по времени изменения и возьмёт самый свежий и
подставит директорию где он находится.
"**.{js,php,css}~(libs|temp|tmp|test)/*" подставит рекурсивно всей .js,
.php, .css файлы, но за исключением директорий libs, temp, tmp, test.
"!#$:t:r" -- подставит у *текущей* команды последний аргумент, но только
с отрезанной директорией из пути и без расширения. "**(#ia2)readme"
подставить все "readme" файлы где допустимо до двух опечаток в названии.
Ничто с подобным мощным раскрытием wildcard-ов и работой с историей не
сравнится по эффективности. Именно подобными вещами и мощны командные
интерпретаторы, чего невозможно сделать в графических приложениях.
GNU Bash по умолчанию во многих дистрибутивах GNU/Linux используется по
сути исключительно из-за политических причин. Многое мною написанное
выше в bash не работает и невозможно сделать. Да и для скриптования он
не сильно лучше голого POSIX shell. Самая частая проблема при
скриптовании shell-а это возня с пробелами. Например у тебя в переменной
foo есть имя файла с пробелами: foo="hello world.txt". И сделав cat $foo
ты получишь ошибку, так как $foo раскроется в два слова, которые станут
двумя аргументами, что означает что ты хочешь вывести файл hello и файл
world.txt. В zsh почти во всех случаях с этим нет проблем, за счёт чего
на нём на порядок проще писать скрипты, надёжнее их писать.
В zsh есть возможность иметь объединённую историю команд между разными
instance-ами, чего тоже нет в bash. Сидишь в двух разных окнах, и у тебя
у каждого запущенного bash будет своя история. Для многих именно эта
фича zsh является главной для перехода на него. Для меня главной фичей
являлось autopushd: когда у тебя каждый "cd" начинает работать как
"pushd" -- добавляет директорию автоматически в стэк. Дальше я бы
выделил инкрементальный поиск истории по шаблону. Дальше бы выделил
fuzzy раскрытие wildcard-ов в путях. И только потом уже наверное
вспомнил бы про shared history. http://strcat.de/zsh/
https://www.arp242.net/why-zsh.html
Но чаще всего про zsh упомянут его мега-гипер-убер-мощнейшую систему
дополнений и https://ohmyz.sh/
https://adam-drake-frontend-developer.medium.com/supercharge-your-terminal-with-oh-my-zsh-4fb102ca5005
https://old.reddit.com/r/zsh/comments/1iu8bz8/is_ohmyzsh_worth_it/
Да, в zsh сверх крутая-как-нигде гибкая система completion-а. Которую я
активно использую и написал свои completer-ы. Но рекомендовать oh-my-zsh,
как и все пользователи с опытом -- однозначно не могу. Типа да,
прикольно что на каждой позиции кучи команд ты можешь нажать tab и у
тебя разукрашенные свистопердящие менюшки показывающие опции команд,
дополняющие имена хостов на основе данных из ~/.ssh/known_hosts,
дополняющие пути до файлов на других хостах (прозрачно логинясь через
ssh на них), но это всё жутко тормозит на практике и не даёт заметного
profit. Время не сильно экономит. Часто только вредит тем, что не
показывает все возможные опции/аргумент для команд и пользователь будет
думать что их и нет. А также это скрывает много деталей которые бы нужно
было знать. Вот человек знает как подставить PID процесса через
автодополнение zsh-а, но этом без наличия свистопердящего zsh он вообще
не в курсе как вывести хотя бы список процессов ("ps" команда). Всех
кого я знаю -- отключают oh-my-zsh и полный спектр completer-ов со
временем, ибо оно не даёт profit-а. Я не к тому что система completion
не нужна, а к тому, что нужно включать только то что нужно, осознанно и
с пониманием дела.
Не редко слышал фразы о том, что zsh медленный. Это, опять же, с чистой
совестью заявляю, что произносят только некомпетентные и не понимающие
люди. В 100% случаях они говорят про обвешанный плагинами свистопердящий
oh-my-zsh. Сам по себе zsh гораздо компактнее, проще, меньше по размеру
и существенно более быстрый чем тот же bash. И не смотря на меньшее
кол-во кода, zsh при этом умеет в десятки раз больше всего.
Ещё рекомендую начать посматривать на https://github.com/tmux/tmux/
https://en.wikipedia.org/wiki/Tmux
Это такая штука, которая притворяется обычным терминалом для запущенных
под ним программ. Но при этом он позволяет иметь множество вкладок,
множество окон, жонглировать ими по всякому, всякие там менюшки и popup
окна делать для автоматизации, иметь scrollback буфер и путешествовать
по нему или редактировать, иметь буфер обмена в котором менюшкой можно
выбирать что хочется вставить (штатные же буферы обмена это стэк из
одного элемента как бы).
Хотя многие впервые знакомятся с мультиплексорами терминалов
исключительно для того, чтобы можно было на сервере их запустить и
спокойно отключиться от сети, а подключившись снова увидеть всё как там
было запущено в точно таком же виде. Штатно при отключении сети, SSH
грохнет все запущенные в сессии процессы.
Многое из вышеназванного умеют делать эмуляторы терминалов: scrollback
буфер, разбиение на окна и их жонглирование, множество вкладок. Но
эмуляторы запускаются только под GUI, а значит на сервере их не будет.
Плюс у каждого второго обязательно да будет какой-то незнакомый тебе
эмулятор, поэтому будет неудобно за чужим компьютером. С другой стороны,
конечно, и нечего делать за чужим :-). Но изучив tmux ты будешь в своей
тарелке на любой системе где он установлен (да и собрать его не
проблема, ибо зависимостей почти нет).
Плюс ты сможешь скриптовать своё рабочее окружение. Я то как-раз именно
поэтому начал пробовать tmux. Когда я работал с одним проектом, то хотел
чтобы мне сразу создалось несколько вкладок, сразу в нужной директории,
в других вкладках всякие просмотрщики журналов сразу были запущены, в
третьих сразу подготовленные строчки с командами запуска. Даже если и
какие-то GUI эмуляторы терминалов и позволяют себя как-то
автоматизировать, то я не встречал кто бы это реально использовал, плюс
это зависимость от чётко заданного конкретного GUI эмулятора терминалов
(тогда как tmux под голой консолью можно запустить без проблем).
Я активно использую его popup окна для следующего: хочу вставить путь до
файла, но даже с возможностями zsh не всегда быстро можно указать путь
до нужного (много коллизий в именах), поэтому парой клавиш у меня
появляется popup окно, где запускается bfind (breadth-first штука типа
find-а, https://github.com/tavianator/bfs), которая на лету в real-time
подаёт данные в "fzf" fuzzy matcher (https://github.com/junegunn/fzf) и
fuzzy поиском позволяет выбрать мне нужный файл частенько за доли
секунды. Выбрав, нажав enter, он подставится в основное рабочее окно, а
popup закроется. Никакого дополнительного места на экране не будет
отъедено во время поиска.
Ну и с коллегами все его используем для парного программирования или
администрирования. Настраиваем специальную SSH учётную запись, при
логине в которую автоматически форсированно будет запускаться tmux
клиент, подключённый к твоему tmux серверу, но в read-only режиме. И мы
видим рабочие экраны друг друга. Но под своим графическим терминалом, со
своими удобными нам шрифтами. Если бы это была передача графической
информации (как удалённый доступ к Windows рабочему столу), то на
мониторах с разными DPI это было бы неюзабельно, либо дико неудобно тому
кому придётся перевести свою рабочую сессию на HiDPI мониторе в "low"
DPI, плюс шрифты регулярно многим не нравятся (на вкус и цвет товарища
никогда нет). Плюс GUI требовал бы очень неплохое Интернет соединение,
тогда как tmux это реально просто просасывание видимой текстовой
информации -- мизер.
Кроме Emacs пользователей, у нас вроде все коллеги с кем мы работали и
работаем, даже когда не идёт речь про связь по сети или удалённого
доступа, используют tmux локально запускаемый. Собственно, прям
настраиваются эмуляторы терминалов так, что после их запуска там сразу
же оказывается tmux. Ничего не отжирающая штука, но добавляющая
офигенное кросс-платформенное удобство, можно сказать сетевую
прозрачность и по сути window manager в терминале. Но штука
опциональная -- она уже не настолько значимую роль играет в отличии от
shell и текстового редактора.
Sergey Matveev [Fri, 21 Mar 2025 08:18:29 +0000 (11:18 +0300)]
Popup-ы на сайтах и других местах
https://yurichev.com/nr/popups/
На все 100% солидарен с автором, со всем написанным. Помню как в
Футураме (20+ лет назад!) показывался их Интернет будущего, в котором им
приходилось отбиваться от назойливых popup окон, не дающих нигде проходу.
В "Очень страшном кино" или каком-то подобном фильме тоже показывали
монитор человека зашедшего в Интернет, где десятки всплывашек то тут, то
там. Недавно я много часов убил сидя в "современном" Интернете, в
обозревателе с включённым JS. Помню что два хостинга сразу же, мгновенно
отмёл, вычеркнул и забыл про них, даже не интересуясь что у них там по
поводу IPv6: просто потому, что после захода на главную они сразу же
суют в лицо какие-то выгодные предложения, которые я вынужден буду
закрыть, тыкнув на крестик. Сразу закрыл. Это полное неуважение к людям.
Автор пишет про то, что на сайте автобусного расписания, после закрытия
popup-а, сделал снимки экрана и сохранил их, дабы более не заходить. И я
аналогично тоже делал когда-то. Или текст сохранял. Но заходить на такое
в последствии -- не вариант.
Понравилось, что он даже дошёл до темы с IDE и редакторами, сказав что
не встречал спецов, которые бы сидели под IDE. И предполагает, что
связано с возможностью сосредоточиться в нормальных редакторах. Типа
может быть где-то и бывают крутые профи за Word или IDE, но только как
редкое исключение из правил.
Sergey Matveev [Fri, 21 Mar 2025 07:46:30 +0000 (10:46 +0300)]
Бойкот собрания IETF 127
https://boycott-ietf127.org/
Так как США являются очень опасной страной для въезда, то предлагают
бойкотировать данное собрание. Мол, даже будучи белым европейцем, всё
равно показывают примеры как их сажают, например если находят критику
президента в смартфонах.
Sergey Matveev [Thu, 20 Mar 2025 14:13:52 +0000 (17:13 +0300)]
Вроде переехал на другую /48 сеть
Сегодня (0b605fb62d37ba546eb3ad5340938cd8e379a088) писал, что всё ожидаю
нового VPS hoster, но вот он предоставил всё в рабочем видел. Уже
поменял адреса в DNS, но ещё ждать пока и glue record обновятся. Вроде
бы пока всё работает. И, в отличии от предыдущего hoster, никаких NDP
proxy не нужно использовать: через выделенную /125 сеть мне на отдельный
IP адрес трафик приходит для всей /48 сети, а дальше я уж сам занимаюсь
маршрутизацией через WireGuard туннель. Насколько более грамотное решение.
Но вот, правда, скорость у них как-то не очень. И на самой VPS с того же
mirror.yandex.ru не более 10MBps (в отличии от 45+ на прошлой) и через
WireGuard с ней как-то не шустро, но это уже мелочи.
Sergey Matveev [Thu, 20 Mar 2025 08:59:42 +0000 (11:59 +0300)]
Вторая версия schwabrak
Год назад (42b3d1b739b5f0cef40f349cdc7044a785dc604a) писал о том, что
schwabrak (bd94115b066472316ea03e85d611f732785f8b7c) более менее активно
использовался мною и немного коллегами. Сейчас в одном репозитории с
задачами надо было причесать и поприводить их в порядок. Переименование
задач или смена иерархии директорий приводит к довольно муторному и
аккуратному исправлению символических ссылок. Получать информацию,
фильтровать её, без использования вспомогательных скриптов -- ну так
себе по простоте дело. Да, информация есть, можно всё сделать, но это не
тривиальные запросы в shell-е, почти всегда скрипты.
Вспомнил одну презентацию, но которую не могу найти в блоге (или не
упоминал о ней), где показывалось как "просто и легко" можно работать с
Bluetooth или чем-то подобным в GNU/Linux. Мол, вот у вас есть sysfs,
где в ряде директорий вы можете узнать о существовании тех или иных
устройств. Сделав echo такого-то значения в такой sysfs файл, вы сможете
сделать то или иное действие. И там относительно простая задача
превращалась в дюжину команд на shell, со сплошными циклами и хаками.
Тогда как эта же задача под Windows решалась единственным API вызовом
функи с несколькими аргументами.
Или вот распространённый suckless подход к IM-ам: делать per-user
директории, внутри них FIFO файлы in/out и ещё метаинформационные. Можно
ли это скриптовать? Конечно, да. Но работать без кучи дополнительных
обвязок уже проблематично. А хотелось бы иметь нечто, с чем более менее
можно бы было и вообще без дополнительного софта работать. В противном
случае это уже будет именно решение под конкретный framework/toolset.
Вторая итерация schwabrak у меня, как мне кажется, стала более
дружелюбной к пользователю и машине. Но она уже потребует recutils
утилиты. Вместо директории tags/ с символическими ссылками на файлы
меток, вместо deps/ с ссылками на зависимые задачи, вместо единичных
файлов на каждое key-value значение, я решил всё это сложить в один
"meta" файл в recfile формате.
По идее я захотел вообще всё сложить в одну базу данных в recfile. Но
разделить её на множество .rec-ов точно нужно: тогда на каждую задачу
git log-ом можно будет смотреть историю только чётко заданной одной, не
иметь конфликтов с другими. Плюс поля about/result я так и оставил в
отдельных файлах, чтобы удобнее было с ними работать в редакторе (внутри
recfile каждая строчка должна была бы иметь "+ " префикс). И написано
несколько утилит, которые просто генерируют большой recfile с
about/result полями на выходе. И предполагается что дальше нужно
использовать recutils. В них и производить фильтрацию, выборку, создание
отчётов, без дополнительных не тривиальных (z)shell скриптов.
recutils наверняка есть в каждом дистрибутиве. А если и нет, то
собираются легко, без зависимостей. Но пока это всё выглядит куда
удобнее для работы.
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.
И похоже что видео игры барабанщиков я смотрел гораздо больше и чаще чем
гитаристов или целых концертов. Завораживают они все своим мастерством.