Посмотрел "Полуночную жару"

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D1%83%D0%BD%D0%BE%D1%87%D0%BD%D0%B0%D1%8F_%D0%B6%D0%B0%D1%80%D0%B0_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_1967)
Отличный фильм! Но я оказывается уже слушал радиоспектакль по книге по
которой снят этот фильм. Так что о сюжете уже в курсе.

Ускорение запуска bash

https://work.lisk.in/2020/11/20/even-faster-bash-startup.html
Не только я обеспокоен задержками при запуске базовых простых вещей,
типа калькулятора. Помню что тоже мерил и zsh и vim время запуска всяких
штук, оптимизируя.

Каганов заценил современный русский хип-хоп

http://lleo.me/dnevnik/2020/11/22_1
Моргенштерн, Элджей, Макс Корж, Егор Крид:
* это всё попса, а не хип-хоп
* раскрутка искусственным шумом
* петь не умеют, слова... без комментариев

Фишки современных эмуляторов терминала

https://www.youtube.com/watch?v=9DgQqDnYNyQ
* Unicode/UTF-8. Ими в видео показывают как отображают прям иконки
  директорий например. Ну тут вопрос шрифтов только, по моему. Выглядит
  интересно, но по сути даже в примере видео я ориентируюсь по цвету --
  ну никто же не будет вглядываться в иконку
* Лигатуры -- тоже вопрос шрифтов. Кому-то нужны/нравятся
* SGR ANSI коды. Ну вот это точно может ощутимо помогать визуально.
  st поддерживает конечно же
* Поддержка мыши -- а вот это абсолютное зло! Готов крушить и громить
  когда я не могу выделить кусок текста, ибо какая-то сраная программа
  перехватываешь мышь. Нафиг мне терминал если я не могу выделить в нём
  что-то или вставить? st кстати поддерживает проброс мышки
* OSC коды -- общение с буфером обмена, выставлением title-ов окон. Да,
  это must-have. st конечно же держит. Для lynx даже писал патч чтобы он
  выставлял название окна/сайта. В vim это тоже нужно выставлять чтобы и
  в tmux показывалось нормальное название tab-а
* bracketed paste mode -- если этого нет, то терминал просто неюзабелен.
  Но меня удивляет как мало людей знает про эту штуку, насилуя себя
  какой-нибудь ручной работой с set paste в Vim
* 24-бит цвет. Боюсь что подобное я даже отключаю, например в Vim. Ибо
  мне нужны хорошие сочные яркие цвета. default цветовые схемы на 24-бит
  -- блёклые. st поддерживает
* поддержка отображения bitmap графики (Sixel). Вот это st не держит, да
  и вообще не много кто. Под вопросом насколько это удобно, но что-то не
  слышал чтобы люди особо это использовали. Ну и тут много разных
  несовместимых реализаций и плохая совместимость с другим софтом. Но
  даже в видео у человека ооооочень медленно отображаются картинки, что
  для меня точно было бы не юзабельно

Как минимум не сказали про то как мышкой, разными кликами, можно
выделять слова или предложения. А ещё всякий XIM ввод (хотя я этим
никогда не пользовался). А ещё некоторые позволяют производить какие-то
действия над выделенным текстом.

Снова Туктамышева крута

https://www.championat.com/figureskating/article-4195009-figurnoe-katanie-gran-pri-2020-2021-proizvolnaja-programma-zhenschiny-muzhchiny-onlajn-transljacija-21-nojabrja-2020.html
Оказывается уже как два года (9b57fe2c57650546ae8b55de278cda720a92d6f4)
я если и вижу упоминание Туктамышевой, то обязательно зайду в новость
посмотреть на фотографии с ней. Посмотрел на других в этой статье: ну
посмотрел и посмотрел. А вот Туктамышевой налюбоваться не могу.

Посмотрел "Не/смотря ни на что"

https://ru.wikipedia.org/wiki/%D0%9D%D0%B5/%D1%81%D0%BC%D0%BE%D1%82%D1%80%D1%8F_%D0%BD%D0%B8_%D0%BD%D0%B0_%D1%87%D1%82%D0%BE
Местами ускорял просмотр, ближе к концу, но фильм понравился. Хотя в
целом я и не одобряю главного героя что он на такой важной работе врал и
не говорил о слепоте. Ну да, смог достичь и даже в таком состоянии
успехов, но ведь это же и заслуга кто ему помогал. Это же просто тупо
опасно для жизни и своей и окружающих. Как и героиня с ребёнком тоже
сказала ему в лицо что доверила своего ребёнка тому, кто точно не мог бы
за ним приглядывать. Да, если бы он говорил о своём состоянии, то работы
ему не видать. Только если бы он не представлял опасности для себя и
окружающих (а покалечив себя, работодателю придётся несладко), то я бы
промолчал, мол ложь во благо.

Снова доработки goredo, redo-stamp и хэширование

Вчера обнаружил что при REDO_NO_HASH на самом деле не работает
redo-stamp поведение. Ничего не падает, но цель остаётся изменённой,
даже если stamp остаётся прежним.

Сам по себе redo-stamp у меня был некрасивым хаком: если во время
определения OOD (out-of-date) цели мы понимаем что она со штампом, то в
конце, если она требует пересборки, запускаем выполнение этой цели,
прямо внутри OOD функции, рекурсивно вызываемой. Это мешало
распараллеливанию -- одна проблема. По сути я делал изменение порядка
выполнения целей и зависящие штампа (а это так или иначе связанные с
redo-always целями), выполняя их раньше, а дальше, благодаря хэшам (на
штампам!), остальные считали что цель не изменилась.

Отключение хэшей приводит к тому, что цели всё равно, не смотря на штамп
пересобираются, ведь ctime то поменялся. А алгоритм понимания OOD цели
взят из redo-c и предельно прост: прочитать .dep, пройтись по каждой
записи в нём, если она имеет .dep, то рекурсивно вызвать OOD на неё.
Просто "сверху вниз" идём и смотрим не устарел ли кто. С отключением
хэшей приходится из-за штампов *заранее* понимать является ли цель
-always или -stamp, а также добавлять состояние о том что в *текущей*
сборке штамп не изменился. Это в итоге у меня заработало, есть коммит,
но это сущий ад уродства и хака, когда мы не просто спускаемся, а
заранее читаем и узнаём про зависимость. Плюс я ещё не добавлял
распараллеливание выполнения out-of-order always/stamped целей (так как,
скорее всего, такие цели на практике будут лёгкими (определение
переменных окружения, версии какой-нибудь), то это не создаёт проблем.
Но в общем случае оно страшно.

Если что-то всё слишком усложняется и добавляется хак то тут, то там
(например просасывание текущего stamp чтобы понять, в момент вызова
redo-stamp, остался ли он прежним), то что-то делается не так. Моя не
работающая версия с redo-stamp по сути делала только одно, давая нужное
и ожидаемое на самом деле поведение (поэтому я был уверен что оно
работало) -- меняла порядок выполнения целей, а дальше хэши делали
нужное поведение.

А не хотелось бы пользователю прописать redo-stamp в каждой цели? В
идеале хотелось бы, поэтому redo-stamp выглядит полнейшим уродством.
Теперь я яростно против него, видя как он на самом деле всё усложняет.
А что говорит apenwarr?
https://redo.readthedocs.io/en/latest/FAQImpl/#why-not-always-use-checksum-based-dependencies-instead-of-timestamps

Могут быть проблемы с пустыми файлами. Так как их хэши всегда остаются
прежними и цель будет считаться всегда свежей. Это единственный аргумент
который я принимаю... в общем случае, если бы не тот факт, что и redo-c
и apenwarr/do и apenwarr/redo и goredo при отсутствии stdout выхлопа не
создают файл, а отсутствие файла является признаком всегда протухшей
цели. На практике из-за этого нет никаких проблем и с желанием делать
пустые файлы, которые не устаревают (например создание какого-нибудь .rc
в котором реально нет никаких команд, выставляющих флаги), и с желанием
делать псевдо-цели "агрегаты". Если есть желание не делать выхлоп, но
всё равно иметь stamp -- ну так сделать запись в файл какого-нибудь хэша
от нужных данных, а файл не использовать. "Родное" хэширование
(go)redo(-c) из-за малого объёма данных будет супер лёгким. Поэтому на
практике это не проблема, повторюсь. Но она требует полноценной
поддержки и работы с stdout захватом и $3 файлом, чего некоторые
реализации не делают, считая захват stdout вредом. Ну вот и получается:
если забить на оригинальное предложение DJB с stdout/$3 -- имеем кучу
проблем и негибкостей, например при постоянной проверке хэшей. Сами
дураки что отказались -- сами же себе создали проблем. Те кто создают
пустые файлы при отсутствии stdout (я уверен что автор redo-c плохо
подумал, влив чей-то глупый pull request в последних коммитах) -- сами
же себе создали невозможность создания агрегатов и постоянно протухающих
целей. Короче, DJB всё предложил как никогда правильно и корректно!

Что ещё apenwarr говорит на тему "почему бы не всегда делать хэши?"

* It makes it hard to force things to rebuild -- просто touch-ем
  действительно не выйдет. Но есть redo (не -ifchange, который по
  умолчанию делает force)
* Targets that are just used for aggregation -- это снова пустые файлы.
  С ними нет проблем, так как они будут отсутствовать
* Calculating checksums for every output file adds time to the build --
  учитывая скорость современных быстрых хэшей (BLAKE2/3, Skein), даже
  просто на современных файловых системах всегда все данные хэшируются
  (ZFS). В теории оно конечно добавляется время, так как оно в любом
  случае что-то делает/занимает на CPU, но так ли это увеличивает время,
  чтобы жертвовать простотой софта и удобством пользователя не заставляя
  его писать каждый раз и думать где нужен redo-stamp? Сколько времени
  будет сэкономлено потому что он не поставил redo-stamp, а выполнение
  какой-нибудь сверх лёгкой цели типа "echo ${GO:-go}" займёт ГОРАЗДО
  больше времени, так как нужно запустить дочерний sh процесс. Я убеждён
  что на практике это совсем не аргумент. Ну и речь же не про абсолютно
  всегда проверку хэша, а если, например, только ctime поменялся --
  поэтому если на диске будет лежать гигабайтный tarball, который просто
  лежит, то хэшироваться он не будет при проверке OOD
* Building stuff unnecessarily and then stamping it is much slower than
  just not building it in the first place, so for almost every use of
  redo-stamp -- не понял к чему, ведь как-раз stamp-ы наоборот позволяют
  не собирать unnecessarily. Или это к тому, что проще собрать "echo
  ${GO:-go}" чем проверять хэш? Возможно только если процесс хэширования
  очень медленный, что не правда на практике
* To steal a line from the Zen of Python: explicit is better than
  implicit. Making people think about when they're using the stamp
  feature. -- Нет уж, снова не согласен и автор противоречит себе.
  Почему же ifcreate/ifchange implicitly ставятся? А как же Zen?
  Потому что это точно удобно будет всем, оно уменьшает нагрузку на
  пользователя, помогает ему (а инструмент должен помогать!). Checksum-ы
  и желание делать redo-stamp абсолютно всегда, если создаётся $3 --
  абсолютно нормально и адекватно
* djb's (as yet unreleased) version of redo doesn't implement checksums
  а вот это не правда, ибо я сам помню что речь про checksum-ы я видел в
  его статьях. Там речь вообще только про них и была, никаких
  ctime/mtime/whatever

Как с самого начала мне не нравились ВСЕ аргументы apenwarr, так сейчас
и подавно. Сейчас на практике я вижу НАСКОЛЬКО это всё усложняет и
уродует. Проблем с aggregation targets и пустыми файлами нет, если не
забивать на stdout и не создавать пустые файлы когда пользователь это
явно не попросил (touch $3). Мне кажется, apenwarr/redo просто борется с
тем, что в Python это всё медленно, хоть сами хэши и на C, но
просасывать данные нужно через Python.

Поэтому я решил выпилить возможность отключения хэшей и выпилил всё
уродство с redo-stamp. Сама команда и даже запись в .dep остались, но
ни на что не влияют. Однако порядок выполнения целей теперь хаотичен,
как и был и как и должен был быть. И проблема в том, что определение OOD
целей, множества целей, может происходить задолго до того как
always цель выполнится. Если поставить маленький уровень параллелизма,
неспешно рассматривая OOD каждой задачи и выполняя их, то всё неплохо. В
противном случае, всё работает, но много целей будут выполнятся потому
что OOD решил что они протухли, ибо always цель ещё не выполнилась. В
общем, проблема (чтобы всё красиво работало: например видя изменение
пути к AR команде, только .a пересобрался, а другие даже не пытались бы)
только с порядком выполнения зависимостей. И проблема и вся эта головная
боль только и только при наличии redo-always зависимостей, что даже
чисто теоретически говорит что раз always, значит протухший всегда,
значит все кто от тебя зависят -- тоже автоматом протухшие, всё честно.
И если следовать принципу apenwarr -- уже лучше пересобрать, чем что-то
недособрать, то можно и вообще ничего не делать.

Но я решил всё же хоть как-то но побороть и оптимизировать это всё.
Сначала я нахожу все always зависимости, попутно полностью собирая
информацию о том как кто на кого влияет. В любом случае. .dep файлы мы и
так читаем, поэтому тут overhead на ОС/диск не увеличиваются, ну кроме
как на чтение из кэша. Затем явно параллельно выполняю их. То есть
форсирую выполнение always раньше всего остального. А дальше я собираю
параллельно все цели которые зависят от каждого always. Затем выполняю
тех кто зависят от них. И продолжаю пока не будет ни одной задачи
протухшей. Звучит как ресурсоёмко, как плохо распараллеливаемо, как то,
что мы идём в обратном направлении по дереву зависимостей (а так и
есть), но на практике все case-ы которые я могу придумать, при
использовании always -- очень быстро должны сходится на нет (у меня во
всех проектах так и есть), если always не изменился. А дальше
запускаются штатные сборки, если, конечно же, они всё же OOD.

Пришлось добавить много кода. Но он касается чисто определения порядка
выполнения целей, без уродств. Если always целей нет, то всё работает
чисто по старинке, максимально просто и тупо как в redo-c. Даже не
смотря на "много" кода -- кол-во добавленных строчек чуть-чуть стало
больше чем я выпилил stamp-specific кода! При этом весь новый код
сосредоточен только в ifchange алгоритме/работе, не затрагивая
OOD/runScript функции.

Доработки goredo

http://www.goredo.cypherpunks.ru/
Jobserver, аналогичный своей сутью на GNU Make-овый, я добавил в goredo
под конец. Ну и конечно же после этого обнаружил что при кол-ве задач 1
оно бывает виснет. --debug показывает что возникает где-то deadlock. Без
ограничения кол-ва задач всё работает. Потратил много часов, но проблема
оказалась в двух строчках defer-ов, помененных местами: было ожидание
завершение задач, но которые не могли продолжить работу, так как мы свой
job-токен ещё не отдали.

Плюс оптимизации производительности определения свежести цели и redo-dot
утилита, которая сгенерирует DOT зависимостей. На практике, в моём
проекте из-за большого количества взаимосвязей она не знаю для чего
могла бы пригодится, но, опять же, сделать так легко, а надо же догнать
и перегнать альтернативные реализации.

Boost индукционной плиты

Тётя мне показала что можно одним нажатием на кнопку "boost" ощутимо
добавить мощности нагрева индукционной плиты. Она и так значительно
быстрее вскипятит воду чем электрический чайник, а с boost-ом вообще
чудеса. Кнопку видел, но даже не задумывался что это и для чего, хотя
она и говорит сама за себя.

I redo redo

http://git.cypherpunks.ru/cgit.cgi/goredo.git/tree/README
Психанул и написал свою redo реализацию на Go!

Python apenwarr/redo всем хорош, но Python зависимость не очень приятна.
Плюс при большом уровне параллелизма у него иногда что-то сбоит и он
падает. Не критично, ибо всё равно потом всё недособранное можно
пересобрать (это ж не Make, где с чистого листа только безопасно будет),
но не приятно.

redo-c не имеет redo-stamp команды. С ней просто приятнее и удобнее
жить. Плюс он не уважает umask, ибо просто используется mkstemp(). И
мозолят глаза его .dep. файлы в каждой директории.

Решил было просто переписать его на Go. И в основу он полностью и лёг.
Но на Go так приятно и легко пишется, что я по сути почти все фичи
apenwarr/redo реализации засунул. Ровно один день чтобы написать рабочую
(текущие проекты полностью мочь без проблем *пере*собирать) redo
реализацию. Тестами ничего не покрыто, но у себя всё что в голову
приходило и на нетривиальном проекте с default/redo-stamp разнообразием
оно отрабатывает идеально. Сейчас я даже Python реализацию удалил из
путей.

Что добавил, чего не было в redo-c:

* всегда захватывать stdout. Как и в apenwarr/redo, явно проверяется не
  записал ли пользователь И в stdout И в $3. Я не раз по неосторожности
  так делал и это сильно помогало
* явно проверять что собранный файл не изменился пользователем, вне
  контекста сборки redo, опять же, как это делает apenwarr/redo -- это
  очень удобно, ибо позволяет временно вносить правки и смотреть что
  получится, но файлы не будут перезатёрты
* исполняемые файлы запускаются как есть, содержащие shebang --
  запускаются с ним. Ну а оставшиеся с /bin/sh -e (или -x в дополнении)
* redo -x покажет trace (sh -x) только для текущих указанных целей, а не
  всех -- оказалось это очень удобно (но можно через env выставить и
  показ вообще всего для всех)
* уважение umask
* redo-stamp, redo-whichdo (мне не надо, но сделать легко)
* в .dep файле сохраняется и UUID сборки, по которому можно понять а
  была ли цель уже собрана, ведь от неё могут зависеть многие, а на ней
  стоит redo-always или redo-stamp какой-нибудь. Позволяет избежать
  возможных повторных ненужных сборок. В apenwarr/redo тоже хранится
  информация о конкретной сборки, поэтому в нём тоже избежали эту
  проблему
* lock-и и зависимости для каждой цели у меня аналогично в отдельных
  файлах, но все они собраны в .redo поддиректории (каждой директории
  проекта), что просто разгружает глаз. Там же хранятся и .log файлы

А теперь отличия от навороченного apenwarr/redo:

* apenwarr/redo проверяет размеры, mtime и ещё несколько параметров
  файла для определения его свежести. Насколько понимаю, ctime он не
  использует потому что он меняется с изменением link count-а. Я
  использовал подход redo-c: проверка ctime, если не совпал, то проверка
  хэша файла. Проверка хэша убирает false positive срабатывание. Если
  хочется иметь "вечную" цель, то, как и redo-c, как и apenwarr/redo,
  отсутствие файла воспринимают как тухлость. Последние правки в redo-c
  не удаляют файл, если stdout был пуст -- это ломает подобный подход. Я
  поэтому делал revert коммита. Ибо это добавляет гибкости и отсутствие
  проблем из-за хэширования пустоты. В итоге имеем и гибкость и false
  positive защиту хэшом. Если покажется кому-то медленным, то добавил
  возможность отключения хэширования (как apenwarr/redo будет). Для хэша
  использую BLAKE2b
* я явно делаю sync для созданных целей и файлов зависимостей, а также
  директорий после переименования файлов. Можно отключить. apenwarr/redo
  не делает sync ни для целей, ни для SQLite3 БД, явно отключая
  синхронность
* распараллеливание работы делается через jobserver-like протокол, но с
  возможностью infinite работ. У меня на C проекте это позволяет сверх
  быстро собрать его
* у меня разукрашенный вывод, с удобными indent-ами, возможностью показа
  когда цель завершена и сколько это заняло времени, возможностью
  показа PID-ов. stderr задач можно тоже показывать с PID-ом самого
  shell-скрипта выполняющегося. У меня сверх verbose debug вывод, весь
  из себя разукрашенный, показывающий все принимаемые решения и шаги
* stderr каждой цели можно сохранить на диск автоматом, но в нём каждая
  строка будет ещё и с TAI64N timestamp-ом, совместимым с tai64nlocal
  утилитой. redo-log команда позволит просмотреть его
* состояние хранится в .dep файлах которые являются recfile-ами
  (8249370437018ad186c7946f22242731fba52035, d47bdefa40f41b81435565029c035f62614fe0da)
  Особо надобности в этом нет, oneline формат redo-c не проблематичен,
  но так красивее, мне кажется
* в процессе работы создаются временные файлы, которые при убийстве
  процесса не подчищаются. Сделал отдельную redo-cleanup команду для их
  подчистки и возможности вообще удаления .redo отовсюду, для начала с
  чистого листа
* apenwarr/redo даже в FAQ говорит что скорее всего начнёт создавать
  .redo поддиректории в каждой директории, ибо не понятно как выяснять
  что является верхним уровнем проекта. Я сделал подход redo-c: вплоть
  до корня ФС он будет искать .do файлы. Но, с возможностью ограничения
  "сверху" через REDO_TOP_DIR переменную или наличию .redo/top файла.
  И оптимизация и безопасность если проект и подпроект используют redo,
  но должны быть независимы друг от друга. Насколько понимаю,
  apenwarr/redo тут будет иметь проблемы

Наконец, goredo имеет "gore" корень, что не может меня, любителя
goregrind, не радовать. Это один исполняемый файл, на который нужно
создать символические ссылки. Точнее запустить с -symlinks опцией, чтобы
он это сделал сам.

goredo в итоге работает и собирает проект даже на глаз ОЩУТИМО быстрее.
Всё же, как ни крути, но Python это Python и быстро запуститься
программа на нём не может. Чтобы просто перезапустить rebuild, который
пройдёт по целям делающим redo-stamp, apenwarr/redo нужно время заметное
на глаз, тогда как goredo отрабатывает вмиг. В общем, пока для меня это
идеальная redo реализация!

Смотрел ли я ещё на какие-нибудь?

* Haskell реализация поддерживает только redo-ifchange. Да, это основное
  и главное, но нет, хочется большего
* Есть 2-3 реализации на shell (не считая работающего apenwarr/do, но не
  делающего rebuild), но либо они требуют либо GNU утилит, либо вообще
  bash (идёт сразу в жопу)
* redux на Go я даже пробовал запускать. Он создавал какое-то дичайшее
  количество (многие мегабайты) JSON файлов, но .do вроде запускал.
  Только с безумно низкой скоростью это всё работало и я даже через
  десятки секунд (минуты?) не дождался конца и нажал Ctrl-C. Просто
  неюзабельно
* C++ не смотрел, ибо нафиг этот язык, тем более для выполнения redo задачи
* Отпадают не совместимые с redo(-ifchange) реализации

И только с написанием goredo я наконец-то понял надобность в
redo-ifcreate! Например есть цель "foo", но нет "foo.do", а есть
"default.do" (где-нибудь). Если в зависимости будет прописано только
"foo" и "default.do", то появление "foo.do" не заставить цель протухнуть!
Поэтому пути поиска default.do файлов автоматически прописываются в
зависимости, как-будто был вызван redo-ifcreate. Очень красиво, на мой
взгляд. Как пользователь, я redo-ifcreate так и не знаю где вызвать, но
внутри без него вижу что нельзя. Ведь и зависимость от .do файла явно
никто не прописывает -- оно автоматически.

Много людей подписались на рассылку LEAPSECS

https://pairlist6.pair.net/pipermail/leapsecs/2020-November/007275.html
Именно сегодня. После статьи из 273d4d5a49d90e55fbd5a173cf587fe09f8b03e7.
И я ведь тоже после неё подписался, интересно же!

Самая популярная покупка с первой зарплаты

https://lenta.ru/news/2020/11/19/pervazarp/
Одежда, гаджет, отдых, развлечения или отдали родителям. Ну меня за пару
месяцев зарплата ушла на Beyerdynamic наушники. Модель которую с тех пор
только и использую, ни на что не променяв.

Самая популярная песня всех времён

https://lenta.ru/news/2020/11/18/shazamtrack/
https://www.youtube.com/watch?v=q0hyYWKXF0Q
https://www.youtube.com/watch?v=fiore9Z5iUg
https://www.youtube.com/watch?v=PBZfCmlRIVs
https://www.youtube.com/watch?v=SsYXnH9lzCY
... по мнению Shazam. Ни одного исполнителя не знаю, ни одной песни не
слышал. Заценил. Я даже не могу сказать что "это не моё", ибо мне
реально жутко не нравится всё услышанное. Как минимум, отсутствие
голосов. Просто противно и неприятно их слушать. В них нет ни изюминки,
ни красоты, ни души. Мне например очень не нравится манера исполнения и
голос (тембр?) Bon Jovi, Nickelback особенно -- но у них выделяющиеся и
запоминающиеся, просто на любителя. А тут... просто какие-то сонные
подростки бубнящие в микрофон. Да и музыка... настолько уныла, скучна и
просто никакая, что наверное это причина почему в моём предыдущем посте
Земля даже стала медленнее вращаться!

С одним трэком "Let Her Go" я всё же знаком только потому что Within
Temptation на одном из bonus альбомов исполнили на него кавер:
https://www.youtube.com/watch?v=xJrEvz6nbv8 -- но даже он у них является
самым унылым. А вот кавер на Imagine Dragons "Radioactive"
(678bb3bee703cc2fc2d2a427b970c9b1a4ffb08a), так меня бесящий в оригинале
(но! вокалист всё же петь умеет, есть изюминка!), у Within Temptation
отличен: https://www.youtube.com/watch?v=hKDxvVom64c

Пойду снова слушать AC/DC новый альбом!

А Земля то вращается медленнее сейчас

https://fanf.dreamwidth.org/133823.html
И возможно ещё несколько лет leap second не появится.

Отправка <...> сообщений в IM-ах

https://rachelbythebay.com/w/2020/11/18/signal/
В Signal, как тут пишут, нельзя отправить сообщения в которых есть
что-то похожее на HTML тэги. Ну офигеть, а люди ещё умудряются говорить
что IM-ы это удобно, когда даже выхлоп ifconfig нельзя отправить.

pygopherd выпилили из Debian потому что не поддерживает Py3

https://lists.debian.org/debian-user/2020/11/msg00319.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937449
Хотя там всё же можно оставить было пакет если количество пользователей
большое. Как же мне много чего в Debian не нравится стало, и тут вот
очередные решения основанные на популярности.

cut vs awk

https://www.datagubbe.se/cutvawk/
Увидел в статье клёвый хак с tr -s " ". Его мне очень недоставало в tr!
awk я считаю лет 30 назад должен был перестать использоваться уже. Есть
Perl, полностью с потрохами легко заполняющий его нишу. Но awk я, к
сожалению, продолжал иногда использовать для print XX вещей. С tr хаком
уж точно перестану.

Интервью с Ангусом Янгом -- он тоже был впечатлён Хендриксом

https://www.darkside.ru/news/126147/
Почти все гитаристы упоминают что Хендрикс был крутейшим богом гитары.
Согласен с этим. Но также запомнилось что от Ангуса я не слышал про
Джимми упоминаний. Не то чтобы я много интервью с ним читал и слышал, но
вот не попадалось. А оказалось что Хендрикс то его впечатлил ещё как!
Purple Haze -- то самое!

А ещё Ангус оказывается совершенно в отказе от любого алкоголя! Не знал
про этот факт. Здорово! И я тоже вообще ничего алкогольного
принципиально не употребляю.

Забавно, а интервьювер впервые поцеловался под Thunderstruck AC/DC. Меня
немного удивляет, ибо как можно отвлекаться даже на такую штуку, когда
такая композиция играет!

Использую GNU Stow и для штатной его задачи

В f25380e9842d68f2f9ecce0d530db90903eeb66b коллега поднял тему по
иерархии директорий и устройству/установке пакетов. При этом упомянул
GNU Stow. С того момента всё не выходил он у меня из головы, ведь я его
уже использую для dotfiles (94dad30d714080ca9eb403277a4c923b54bc20c3),
но не использую для штатной цели! А ведь у меня в домашней директории
было много программ установлено (mutt, git, ffmpeg и десяток других),
которые я не хочу глобально в систему ставить. Каждая программа стоит
просто в $HOME префиксе и я в .zshenv добавлял PATH/MANPATH/INFOPATH для
неё. Только сегодня дошло что нафига я этим занимался, ибо Stow как-раз
для этого! Засунул все программы в $HOME/local/stow и он сделал нужные
symlink-и и про .zshenv я могу забыть теперь. Очень удобная штука!

Причём, кроме GNU grep и GNU sed (ну и recutils), без которых можно
прожить и я их использую только из-за производительности, я активно
использую и очень рекомендую GNU parallel и GNU Stow -- оба которых
написаны на Perl. Можно сказать, среди всего GNU софта я только на Perl
написанный считаю must-have-ным :-)

pkg-config нравится

https://people.freedesktop.org/~dbn/pkg-config-guide.html
В целом я считаю что freedesktop.org делает в основном плохое, но
pkg-config мне нравится. Только сегодня дошли руки причесать
генерирование корректного .pc файла, который позволяет парой вызовов
получить реально все CFLAGS/LDFLAGS/LDLIBS нужные для сборки. Requires
справляется с тем, что указав зависимости, он и их CFLAGS подставит все.
А у себя в проекте прям определяю какие зависимости определились через
pkgconf, добавляя их в итоговый requires, а какие нет, добавляя их
*FLAGS/LDLIBS уже к соответствующим секциям. К сожалению, проблема на
практике в том, что не все библиотеки предоставляют .pc файлы. Но,
благо, их легко делать. Но даже suckless проекты его вовсю используют и
поэтому их сборка не вызывает проблем и, тем более, какого-нибудь ада в
виде autotools.

Посмотрел "Вторую жизнь Уве"

https://ru.wikipedia.org/wiki/%D0%92%D1%82%D0%BE%D1%80%D0%B0%D1%8F_%D0%B6%D0%B8%D0%B7%D0%BD%D1%8C_%D0%A3%D0%B2%D0%B5_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Очень понравился фильм! В целом он конечно грустный и печальный, но
забавные моменты ещё какие есть. Заканчивается, я считаю, на хорошей
ноте, мол главный герой много кому оказался полезен. Но в жизни я думаю
таких не много найдётся.

Вообще у меня в блоге как фильм ни упоминается, то он мне понравился. На
самом деле я смотрю их в разы больше, но они настолько не стоят отзыва
(если это не редкостная гадость), что просто об этом умалчиваю, стыдясь
что взялся такое смотреть.

Blockchain and trust статья Шнайера. Голосование на blockchain

https://www.schneier.com/blog/archives/2019/02/blockchain_and_.html
https://www.schneier.com/blog/archives/2020/11/on-blockchain-voting.html
Удивительно, но я почему-то не читал эту статью раньше у него. Люто
нравится, так как в ней повторены аналогичные мои point-ы почему
BitCoin/blockchain бесполезны:

    [...]

    Blockchain technology is often centralized. Bitcoin might
    theoretically be based on distributed trust, but in practice, that’s
    just not true. [...] With bitcoin, there are only a few miners of
    consequence. There’s one company that provides most of the mining
    hardware. There are only a few dominant exchanges. To the extent
    that most people interact with bitcoin, it is through these
    centralized systems.

    [...]

    Do you need a public blockchain? The answer is almost certainly no.
    A blockchain probably doesn’t solve the security problems you think
    it solves.

    [...]

    Honestly, cryptocurrencies are useless. They’re only used by
    speculators looking for quick riches, people who don’t like
    government-backed currencies, and criminals who want a black-market
    way to exchange money.

А вообще там сплошная тема про доверие и то что доверие нельзя заменить
алгоритмами и протоколами. А вышел на эту статью я через "On blockchain
voting", где тоже сказано что для голосования использование blockchain
вообще тупейшая идея.

Честно говоря я переживал что Шнайер не высказывался о blockchain-ах и
даже наоборот где-то по началу говорил что идея неплохая. Я вот такой
упёртый и считаю Bitcoin/blockchain -- сущим глупым hype-ом, не несущим
никакой практической пользы (ну, кроме продавцов электроэнергии, железа
и спекулянтов, конечно же), а Шнайер, мол, нет и может быть я всё же не
прав? Нет уж, оказалось что всё ok, мы с ним сходимся во мнении.
Столлман про Bitcoin плохо говорил потому что там нет анонимности, что
очевидно.

Apple firewall не поможет от программ от Apple

https://thenextweb.com/plugged/2020/11/16/apple-apps-on-big-sur-bypass-firewalls-vpns-analysis-macos/
В общем, это и не firewall оказалось, ибо прозрачен для софта от Apple.

Преимущества "Linux" перед Windows: длины имён файлов

https://github.com/nbeaver/why-linux-is-better
Только начал бегло смотреть по диагонали и вижу раздел с максимальной
длиной пути в Windows: 260 символов, а в "Linux" например 4096 (байт?).
И типа в Windows много проблем из-за этого. Насчёт полного пути не знаю,
но вот я не раз сталкивался с тем, что torrent-ы созданные под Windows
не могут быть записаны на некоторые ФС (в том числе ZFS), так как в
Windows ограничение на кол-во символов, а в Unix-ах на байты и кириллица
там становится раза в два длиннее (UTF-8) и уже не влезает:
cdc44c7a1bb63c5822313ac73e99a39bda088bff. Но я считаю что 255
символов/байт это вполне себе достаточно.

В остальном же... особо больше мне ничего не приглянулось и не
запомнилось из этой здоровенной статьи.

Ваш компьютер больше не принадлежит вам

https://habr.com/ru/post/528104/
Ужасный перевод, но я и оригинал читал. Даже не стал комментировать, ибо
и так про отправку запускаемых команд уже упоминал.
(22dfdf4ab8cd4c68c15720af9296091114e3c3f7). Только Apple это малая часть
компьютеров. Но уже не одно десятилетие движение свободного ПО говорит
про то, что проприетарное ПО это когда вы не управляете своим компьютером.
Особенно всё усугубляется когда компьютер подключён к Сети. Это одна из
причин почему я принципиально не связываюсь с проприетарщиной, в том
числе и JavaScript программам, которые многие не относят/не приравнивают
к запуску несвободного кода.

Mike Fraser

http://mikefrasermix.com/credits/
Этот человек создал наверное четверть вообще всех альбомов что у меня на
жёстком диске! Только одних AC/DC пять штук! У некоторых и звук свой
неповторимый -- например группа Septicopyemia обращалась к чешскому
чуваку что сводил альбомы Jig-Ai и звук у них получился именно таким же,
чешским горграйндовым, как и должен быть!

Сборка redo проекта в отдельной build директории

В 401c0f635a1cdfb01068a48a4cdf40791d3db458 писал про полную нормальную
замену autotools redo целями. apenwarr/redoconf по многим причинам мне
не нравится, но он умеет делать (даже заставляет) отдельные, независимые
от кода build-директории. Я у себя нашёл как это реализовать: банальный
и простой shell-скрипт который просто делает иерархию директорий и
жёсткие ссылки на файлы исходного кода. Полностью воссоздаются
директории (find+mkdir, find+ln): conf doc examples src tests, а также
копируется эталонный config файл (с -i опцией, чтобы не перезатереть
ненароком) и базовые {all,install,clean}.do цели. Отрабатывает быстро,
место в общем-то не занимает весь этот исходный код. Ни одного .do файла
не правил. Можно сказать что просто весь проект я жёсткими ссылками
переношу, ну и ладно. Зато теперь я с разными опциями (точнее конфигами)
могу параллельно напересобираться для проверок.

Замена autoutils redo системой

https://redo.readthedocs.io/en/latest/cookbook/redoconf-simple/
В моей C программе всё усложняется конфигурация сборки: есть
опциональные библиотеки, есть выбор методов/библиотек, появилась
зависимость между некоторыми переменными конфигурации. Если выбран метод
использования криптографии из библиотеки YYY, а не XXX, то всякие
XXX_CFLAGS=${XXX_CFLAGS:-`$PKG_CONFIG --cflags xxx`} исполняться не
должны. Их можно просто закомментировать, но это ручной труд. Добавлять
массу if-ов в сам конфиг (который обычный shell файл) -- тоже плохо,
хотя в нём уже есть hardcoded вещи типа добавления -pthread если
включено использование pthread mutex-ов. Плюс пользователю нужно явно
задавать pkgconf/pkg-config команду например, хотя она может быть
определена сама. Некоторые команды (plantuml, dmalloc) опциональны. В
общем или существенно усложнять простой config, который выглядит просто
как какой-то .ini файл, либо... что-то придумывать.

Определение команд, определение наличия библиотек (у меня опциональные
libtai, dmalloc, libtap например) -- всё это отдельные изолированные
друг от друга задачи. Между ними могут быть зависимости, как например
$CRYPTO_CFLAGS зависит от флагов конкретно выбранной криптобиблиотеки.
Раньше config содержал вереницу переменных внутри которых были вызовы
pkgconf, которые запускались все последовательно. Всё это (отдельные
задачи, зависимости между ними) явно задача для системы сборки!

Я помнил что в apenwarr/redo реализации есть redoconf -- штука которая
как-раз для замены ./configure ада, в которой можно набросать отдельными
файлами всякие детекторы. Я по сути взял из неё идеи, но саму
использовать не стал. Во-первых, там намёки на GNU Make. Во-вторых, она
банально просто где-то падала и не работала у меня -- что-то не так в
shell-скриптах. В-третьих, это полноценный такой framework, с кучей
библиотечных shell функций и обёрток -- требующий и изучения и уже не
такой и прекрасный как redo, не привязанный к языкам или чему-то
подобному. В-четвёртых, там очень много делается через создание shell
файлов с соответствующими костылями для всякого escape-а данных.
В-пятых, там подход заточен чтобы делать один большой и жирный compile
скрипт, содержащий все CFLAGS/LDFLAGS/LDLIBS для сборки целей. Я же у
себя для каждой конкретной .o-цели явно задаю и управляю какие конкретно
опции и флаги передаются -- чтобы лучше понимать что от чего зависит.

Но основную идею я заимствовал. Если программа использует $CC, то можно
сделать вот такой детектор, который учитывает и переменные окружения:

    $ cat conf/cmd/cc.do
    echo "${CC:-`command -v cc`}"

можно добавить зависимость от цели учитывающей изменение переменных
окружения (0676a1348e8ffe14a7840c8699d3afdc6857e24c) и учитывать не
поменялось ли значение самой цели:

    $ cat conf/cmd/cc.do
    redo-ifchange ../vars
    . ../vars
    echo "${CC:-`command -v cc`}" > $3
    command -v redo-stamp > /dev/null || exit 0
    redo-stamp < $3

проверка наличия redo-stamp чтобы работало под реализациями без этой
команды -- всё будет работать, просто изменение переменных окружения не
заставит пересобираться (если системы не основаны на хэшах, конечно же).
Программа которой нужна cc команда:

    redo-ifchange ../conf/cmd/cc
    read CC < ../conf/cmd/cc
    $CC ...

Сделать более сложные цели для определения команд, возможно с выводом в
stderr о том что команда не найдена и будет использоваться пустышка --
тривиально. Раньше у меня всё глобально зависело в целом от конфига и
переменных окружения (его касающиеся). Теперь команды сборки
документации зависят только от cmd/makeinfo, cmd/plantuml (который
подставит пустышку, с предупреждением, если настоящий не найден) и
изменение cmd/cc не повлияет на пересборку документации. Плюс для сборки
некоторые .o файлов нужны знания о PCSC библиотеке, добываемые через
pkgconf. Для других .o файлов нужен LibreSSL, тоже через pkgconf. Обе .o
зависят от разных conf/flags/{crypto,pcsc} флагов и поэтому вызовы
pkgconf-а могут быть распараллелены. Определение наличия и
работоспособности libtai библиотеки делается через сборку (прямо внутри
conf/flags/tai) временного файла с C кодом, но знание о $TAI_*FLAGS
нужно только при сборке log.o файла -- пока он дожидается сборки и
проверки наличия libtai, множество других целей уже успеет собраться,
так как они не зависят от conf/flags/tai.

Многие .o зависят от криптографических библиотек. Но им без разницы
какая именно библиотека будет использована. Поэтому я использую общие
$CRYPTO_*FLAGS, значение которых зависит от выбранного метода
криптографии:

    $ cat conf/flags/crypto
    redo-ifchange ../methods
    . ../methods
    src=crypto.$CRYPTO_METHOD
    redo-ifchange $src
    cat $src

а сама значение флагов для CRYPTO_METHOD=SSL (для примера):

    $ cat conf/flags/crypto.ssl
    redo-ifchange ../../config ../cmd/pkg-config
    . ../../config
    read PKG_CONFIG < ../cmd/pkg-config
    cat > $3 <<EOF
    ${SSL_CFLAGS:-`$PKG_CONFIG --cflags libcrypto`}
    ${SSL_LDFLAGS:-`$PKG_CONFIG --libs-only-L libcrypto`}
    ${SSL_LDLIBS:-`$PKG_CONFIG --libs-only-l libcrypto`}
    EOF
    command -v redo-stamp > /dev/null || exit 0
    redo-stamp < $3

тут и зависимость от конкретной pkg-config реализации и возможность
переопределения SSL_* и выхлоп просто в виде трёх строчек в файл.
Библиотеке которой надо использовать CRYPTO_*:

    redo-ifchange ../conf/flags/crypto
    read CRYPTO_CFLAGS < ../conf/flags/crypto
    # или
    { read X ; read X ; read CRYPTO_LDLIBS ; } < ../conf/flags/crypto

Подход с read-ом мне люб тем, что не надо париться с экранированием и
генерированием валидного shell-кода. Изначально у меня был lib.rc с
библиотечными shell функциями, но под конец полностью исчез.

В итоге, что я получил?

* возможность лёгкого добавления детекторов как и в autoconf. Сейчас у
  меня в проекте 14 conf/cmd и 19 conf/flags (всякие флаги сборки кода).
  Плюс с зависимостями между ними
* полное распараллеливание работы этих детекторов
* зависимость конкретных целей сборок совершенно разнородных вещей
  (документация, .o файлы, исполняемые, .a) от только нужным им командам
  и флагам/настройкам
* при изменении переменных окружения (хочу быстро всё пересобрать с
  CC=clang-NEW redo clean install) будут пересобраны только зависящие от
  CC цели (например сгенерированный asn1Parser-ом файл .c из .asn1
  спецификации не будет затронут). Зависимость только от конкретики

Это всё просто офигенно! Есть небольшой недостаток моего подхода: вместо
"redo-ifchange ../vars ; . ../vars" у меня большее количество
зависимостей и из-за read-а каждое чтение каждой команды/флага занимает
строчку. Но зато чистейший pure POSIX shell, никаких shell фунок
самопальных, отсутствие хаков и возни с экранированием строк, которая
присутствовала раньше (а у apenwarr/redoconf так вообще там целые экраны
кода для этого).

Для того чтобы узнать какие вообще опции можно изменить/настроить в
apenwarr/redoconf -- вызывают отдельные функи "регистрирующие" что у нас
есть на руках. У меня в каждом "детекторе" команд/флагов/настроек есть
возможность влияния на него через переменные окружения или тем что
прописано в config-файле. Де-факто это всегда запись/использование
переменных в виде ${WHATEVER}. Что мешает мне просто из всех .do
навыдёргивать эти переменные?

    $ cat conf/vars.list.do
    perl -ne 'print "$1\n" if /\$\{(\w+):?.*\}/' *.do cmd/*.do flags/*.do |
        sort | uniq | fmt > $3
    command -v redo-stamp > /dev/null || exit 0
    redo-stamp < $3

Почему в одном месте perl, а в другом sed? Так исторически сложилось,
лень переделывать :-). После выполнения, я получу красивый полный
список:

    AR ARM_CFLAGS ARM_LDFLAGS ARM_LDLIBS ASN1PARSER CC CFLAGS CLANG_FORMAT
    [...]
    TAI_LDFLAGS TAI_LDLIBS TAP_CFLAGS TAP_LDFLAGS TAP_LDLIBS TASN1_CFLAGS
    TASN1_LDFLAGS TASN1_LDLIBS VERSION

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

Когда я начал всю эту переделку, то совершенно полностью не был уверен в
результате и вообще будет ли оно того стоить. Превзошло все ожидания!

Единственное чего у меня совершенно нет, в отличии от apenwarr/redoconf
-- возможности работы в отдельной изолированной build директории, что
вообще конечно хорошим тоном является. Пока даже не думал как это сделать.
Можно просто наворотить себе git worktree в отдельных директориях, как хак.

Скорость работы LLVM 11 и его инструментарий

Обновился с LLVM 6 до 11. LSP демон стал работать значительно быстрее,
меньше каких-то непонятных warning-ов выдаёт. В
543ea92f9b81c1c8adead550e7ce0cf3cc665240 писал про то, что скорость
прежних задач не должна падать -- тут они справились! А вот всякие
clang-tidy стали работать медленнее... но при этом находят больше
серьёзных недочётов и в (ещё не протестированном) коде нашли утечки
памяти (отсутствие free) и кое где отсутствующие break. За это можно
простить, тем более что оно не интерактивное.

Вообще LLVM/Clang инструментарий очень нравится и насколько понимаю в
GNU GCC нифига подобного ничего нет. И clang-format, который 100%
форматирует весь мой код. scan-build ПОТРЯСАЮЩЕ находящий серьёзные
ошибки, которые и во время ревью человек то нифига не заметит (хитрые
goto/if из-за которых потеряется значение переменной). clang-tidy
выдающий и false positive, но также и полезные вещи типа утечек памяти
или неинициализированные значения. clangd LSP -- как linter отличен!
Куча -Weverything проверок (которые даже в doxygen docstring-и умеют
залезать) и sanitizer-ов, которые в 99% случаев находили некорректности
работы с памятью, переполнения чисел или ошибок из-за их знаковости.
Вовсю моё программирование на C опирается на эти инструменты.

Единственное что я ставил дополнительно это: https://include-what-you-use.org/
С помощью которой я легко корректно и правильно организую include-ы,
ведь задача очень не приятна для человека.

Иерархия файловой системы в Unix-like системах

https://cr.yp.to/slashpackage.html
https://jdebp.eu/FGA/slashpackage.html
https://sta.li/filesystem/
Коллега скинул ссылки на очередной предложение от DJB касательно
управления "пакетами". Точнее того, как их можно было бы устанавливать и
размещать. jdebp.eu продолжает идею ещё дальше. Такой подход мне
нравится, безусловно. Плюс /var/service где daemontools смотрит за
демонами. У sta.li тоже видел предложение по куда более простой
иерархии:

    / - the root home
    /bin - all executables
    /sbin -> /bin # softlink pointing to /bin
    /boot - all boot files
    /etc - system configuration
    /home - user directories
    /var - spool, run, log, cache
    /share - man pages, locales, dependencies
    /include - include/headers
    /lib - static libraries for building stuff
    /mnt - mount points
    /usr -> / # softlink pointing to /

    /dev - devices
    /proc - proc files
    /sys - sys files

    /sucks - stuff that sucks, like ugly gnu library dependencies,
             or systemd fake handlers

Которое мне тоже нравится. Но вот менять это в уже готовой ОС, типа
FreeBSD, не стал бы. Оно красивее, правильнее, но стоит ли оно того?
Если делать дистрибутив/ОС с нуля, то стоит обо всём это задумываться. А
так овчинка выделки не стоит -- уж больно много геморроя.

Хотя это ужасно что мы стали жить в /usr и /usr/local директориях, ведь
история говорит что просто у хакера не хватило места в / ФС и было много
свободного на /usr и поэтому он туда начал всякое устанавливать.

glibc и memset_s

https://en.cppreference.com/w/c/string/byte/memset
Компилировал недавно свою программу на последней LTS Ubuntu, GCC10.
Отругала меня что ничего не знает про memset_s функцию (безопасная
очистка памяти). Действительно grep вообще ничего не показал. Как же
так? А вот так, действительно, glibc положил на опциональные C11 функции
связанные с security. Даже не самая свежая FreeBSD имеет их у себя в libc.

Я то думал что наконец-то в 2011-ом году догадались стандартизировать
наличие функции безопасной очистки памяти. Сделать то сделали, вот
только в GNU/Linux мире это не реализовано. Когда-то я считал что GNU
софт и библиотеки монструозны по размерам, но при этом чего только не
содержат и богаты функционалам. Теперь вижу что они просто монструозны!

Power Up!

https://en.wikipedia.org/wiki/Power_Up_(album)
Вышел новый альбом AC/DC и даже нашёл где его скачать! Хорош ли он?
Слушал перед сном. Когда проснулся сегодня -- до сих пор что-то из него
играло в голове и хотелось его переслушать. В отличии от трёх предыдущих
(20 лет времени) -- в нём уже рок-н-ролльчик, а не блюз, который после
прослушивания у меня ничего не оставлял в памяти. Альбом хорош!

Вот правда сразу же бросилось в уши что он жутко скомпрессирован! Очень
громкий. Но всё же слушать можно, в отличии от Metallica "Death Magnetic".

Рекомендации к просмотру xkcd

Сегодня заметил что на сайте xkcd.com есть рекомендации просмотра:

    xkcd.com is best viewed with Netscape Navigator 4.0 or below on a
    Pentium 3±1 emulated in Javascript on an Apple IIGS at a screen
    resolution of 1024x1. Please enable your ad blockers, disable
    high-heat drying, and remove your device from Airplane Mode and set
    it to Boat Mode. For security reasons, please leave caps lock on
    while browsing.

musl то требует Linux

http://www.musl-libc.org/faq.html
Я про musl упоминал что штука выглядит хорошей, но ни в коем случае даже
мысли не было чтобы его использовать у себя на FreeBSD. У нас и так
хороший BSD libc. А даже если бы и захотелось, то musl всё равно требует
Linux ядро.

Прочитал "Пиратов Карибских морей"

https://www.livelib.ru/book/1000250586-piraty-karibskih-morej-v-riva
С одной стороны получил удовольствие, а с другой как-будто какой-то
бабских роман прочитал, где сплошные интриги и козни на теме любви.
Запомнилось что очень тяжело даётся идентификация героев романа: имена
всюду и везде есть, но вот тяжело мне они запоминаются и я часто только
по контексту понимал кто к кому пришёл. Ну как в некоторых просмотренных
корейских фильмах все на одно лицо.

Железо на шаг впереди, софт делает два шага назад

https://fabiensanglard.net/silicone/index.html
Автор пишет что, не смотря на возрастающую производительность
процессоров и железа в целом, на каждую сохранённую железячниками
инструкцию, софт умудрится сделать на две инструкции больше. Меня
впечатлило что автор говорит что раньше Photoshop на SSD грузился
за секунду, XCode запускался мгновенно. А теперь на Ryzen 5 2600 с
M.2 NVMe он уже просто не в состоянии использовать XCode и Photoshop
грузится на 13сек!

Это нормально что raytracer-ы требуют больше ресурсов потому что они
делают более качественную и лучшую картинку. Компиляторы получили всякие
LTO оптимизации, которые тоже ресурсоёмки. Но вот не нормально что
прежние такие же задачи на новом железе выполняются так же долго.

Именно в этом году я конкретно начал замечать и париться об отзывчивости
системы. Я делал это и прежде, но в этом году у меня обострение какое-то.

* Давным давно я выкинул bash, в первую очередь потому что он медленный.
  Я уже не вспомню где и как именно, но он тупо просто некоторые чисто
  shell вещи умудряется делать так, что я на глаз замечаю задержку.
* Для калькулятора я часто запускал python -- и даже на современных
  мощных Mac системах (коллега проверял) "не прогретый" запуск занимает
  более секунды! Если мне надо посчитать в калькуляторе что-то, то я,
  очевидно, хочу его моментальный запуск! Это происходит не часто,
  поэтому к долгому времени запуска я привыкнуть не могу. Я перешёл на
  zcalc, а теперь вот на dc в rlwrap в tmux с кучей shell-скриптов
  обёртки -- и это работает стремглав, по сравнению с запуском python.
* За последний год я больше работал с Go и не переставал удивляться что
  он способен откомпилировать с нуля mumble-сервер, жирный irc-сервер с
  кучей зависимостей за считанные секунды!
* Когда я что-то рассматриваю и пробую из плагинов для Vim-а, то
  скорость работы (или я замечу задержку или нет) практически на первом
  месте. Возясь с LSP увидел что скорость работы Python LSP сервера
  такая, что я полностью отключил его, ибо мне проще и удобнее руками
  вызывать pylint/pyflake/whatever, а не получать с дичайшей
  асинхронностью по времени warning-и, которые уже не актуальны могут
  быть. Linting clangd для C работает вполне вполне с достаточной
  скоростью и помогает, но вот дополнение методов/функций работает очень
  медленно -- автоматику во время набора поэтому отключил. А вот в Go
  LSP работает практически со скоростью моего набора!
* Когда я стал использовать redo со всякими pkg-config-ами, то весь
  процесс конфигурирования+сборки+установки стал таким быстрым (для моих
  проектов, конечно же), что мне почти физически становится плохо когда
  я вижу что на моём ноутбуке ./configure выполняется дольше чем сама
  сборка. Это проблема configure, но всё же!
* Когда я стал программировать на C, то вижу с какой скоростью всё
  способно компилироваться. C++ -- адовейший ад. У коллеги с мощным
  компьютером видел сколько собирает Rust программу типа PyDERASN-а --
  ещё большее время ожидания, при котором можно прочитать новости успеть
* Недавняя эпопея с статической/динамической линковкой показала
  насколько много впустую тратится время *человека* ожидающего запуск
  программы
* Texinfo собирает мою домашнюю страницу всё равно секунды, но это на
  порядок быстрее чем Python Sphinx. Не то чтобы это критично, но к
  быстрой работе команд/задач очень привыкаешь и офигеваешь как в
  некоторых проектах дока собирается по несколько минут. Давным давно
  для вырезания docstring-ов и их вставки в .texi/.rst файлы у меня был
  Python скрипт и при частой сборке программ я бОльшую часть времени мог
  ждать только факта самого его запуска. Сейчас у меня быстро написанная
  программка на Perl -- работающая просто моментально для глаза (Perl
  вообще очень и очень шустрый)
* Буквально ведь всего несколько лет назад, когда в FreeBSD был GCC,
  сборка полностью всей ОС занимала меньше (на в разы более слабом
  железе) чем сборка сейчас LLVM-а. CMake собирается дольше чем GCC (не
  самый последний GCC, конечно же, где вроде как тьма C++ появилось). А
  скорость сборки всей системы важна, если бы мы максимально старались
  делать статическую линковку (c0de9bbf633b421a57a10db70d6d76b5f195546e).
  Сборка Go, начиная с 1.4, занимает суммарно (без тестов) наверное пару
  минут на ноутбуке

Отзывчивость системы это life-changing! Это не просто "ну, приятно что
быстрее запускаются", а это именно в корне меняет привычки и работу за
компьютером. Огромное количество людей уходит с жирных IDE на Emacs/Vim
только потому что на их 16GB RAM системах оно всё равно всё тормозит (с
моей точки зрения -- до неюзабельного состояния).

Буквально позавчера я устанавливал Ubuntu последнюю LTS на флешку
(обычную такую дешёвую флешку), чтобы на отдельном ноутбуке поработать с
железом и с ней. В ней так много всего позапущено (без GUI! это server
вариант), что когда мне показали приглашение для логина, то логин занял
более чем минуту, прежде чем я увидел строку shell-а! Каждая, *КАЖДАЯ*
команда имеет видимый и ощутимый lag. На этой же флешке я помню как
запускал FreeBSD с GUI и Firefox-ом -- это была юзабельная система.
Большие лаги я наблюдают когда соединяюсь с удалённым VPS-ками по IPv6,
который идёт через третьи страны -- вот на современных Ubuntu,
запущенных на локальном железе, ощущения похожие.

Я, как программист, часто понимаю, конечно же, откуда растут ноги всего
этого, но нужно же иметь совесть! Отдельная тема это смартфоны и
броузеры (штатные, где ничего не отключено из JS-а) -- где всё медленно
и неспешно, в slow-mode-е. У папы на смартфоне я вижу задержку наверное
чуть ли не на каждый клик (не в броузере, а просто в системе), хотя
другие этого не замечают уже, ибо привыкли. Мне в фильмах всегда
бросалось что любое нажатие по любой кнопочке обязательно должно
открывать окошко/менюшку с анимированным визуальным эффектом. В Mac по
умолчанию когда показываются все текущие окна, тоже анимация их
размещения по экране. В фильмах это ладно и простительно. Но нормальный
человек рехнулся что ли за каждым частым действием ждать десятки/сотни
миллисекунд на свистоперделку, вместо того чтобы от компьютера сразу
получить ответ на свою команду? Знаю что в проприетарных системах этими
анимациями часто скрывают, на самом деле, долгое время запуска/работы,
но ведь не всегда же так.

Насколько мог бы "динамический" IPsec между host-to-host системами
(когда одна из сторон "анонимна" например) помочь с хранением
handshake/state и сократить до минимума лишние round-trip-ы до сервера,
дьявольски увеличив отзывчивость системы (HTTP/2 со всякими TLS session
resumption-ами это и пытаются добиться как-раз). Когда люди хотят чтобы
в каждой сетевой программке была поддержка TLS, то меня это бесит! IPsec
надо развивать, а не эти изолированные TLS сессии. Ведь нет же ничего
чтобы хранило state при запуске lynx, curl, wget, whatever -- наверное
только броузер одна из немногих программ которая долго живёт и может
блюсти уже установленные handshake-и. Life-changing когда я стал
использовать OpenSSH долгоживущие сессии и моментально логиниться на
сервер, а не ждать пока TCP/SSH handshake отработает и вся эта не
шустрая асимметричная криптография (пускай даже и *25519!).

Или вот на работе у нас используется OpenVPN. Под пять секунд приходится
ждать пока он подключится! А ведь ping до сервера вообще показывает чуть
больше 2мс!

На глаз видно насколько медленнее работает SSH или IKEv2 с RSA ключами.
Но это уже ладно -- это тема ни программистов, ни компьютеров. Но пора
активнее начать использовать эллиптические кривые.

Я бы на месте пользователей компьютеров и ресурсов Интернетов люто
ненавидел любого программиста, бессовестного и обнаглевшего!

Мужик два года заходил в квартиру через окно

https://lenta.ru/news/2020/11/12/man_seeking_woman/
И всё было удобно и прекрасно, пока к нему не пришла женщина и пришлось
тратиться и ломать замок двери. Жил, не тужил и тут на тебе!

Overhead от динамической линковки

http://harmful.cat-v.org/software/dynamic-linking/
http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols
https://sta.li/faq/
В комментарии http://blog.stargrave.org/russian/71870b1510dfc2727093f2767b994b8596f9b163#comment1
я запускал convert, в котором ldd на полэкрана, в течении 165мс. Когда
руками собрал с нуля, то у меня на полтора экрана вывод ldd и утилита
запускается более чем в два раза дольше. Всё таки 200мс это очень и
очень заметное на глаз время, тем более для long-live утилиты.

Когда я только начал в этом году программировать на C, то задавался
вопросом какие библиотеки мне делать (static vs shared). И все хакеры
говорят в один голос о статической линковке. Есть даже целый "stali"
(static linux) дистрибутив, целью которого является только статическая
линковка, musl и всякое такое. В котором много ссылок на конкретные
примеры всяких размеров программ, времени их запуска и тому подобного.
Plan9 и Go -- имеют только такую линковку.

И вот, судя по ImageMagick, я однозачно теперь тоже за статическую.
Во-первых, если использовать всякие -ffunction-sections+-Wl,--gc-sections,
то в итоговом исполняемом файле не останется лишнего кода в виде
неиспользуемых функций. Во-вторых, даже если размер будет и больше, то
он всё равно при этом будет быстро (быстрее) загружаться, что куда
важнее чем место на диске.

Основной аргумент за динамическую линковку у людей: типа если нужно
обновить OpenSSL, то можно только его обновить, не трогая остального. Но
даже я на своей практике с чистой совестью могу заявить что это брехня
только изредка работающая, ибо регулярно *на практике* несовместимости в
версиях библиотеки, которые препятствуют обновлению и по факту
приходится всё равно пересобирать зависимый от неё софт. Да и в чём
проблема пересборки всего что зависит от неё, пускай это даже и libc?
Отсутствие исходников? Не аргумент, ибо они должны быть в свободном ПО.
Проприетарное -- идёт нафиг. Время сборки/пересборки -- а вот это повод
задумываться над скоростью компилирования. C-компиляторы вполне себе
шустрые например. Go -- аналогично, пересобрать ВЕСЬ Go софт, сколько бы
его не было -- вопросы нескольких минут, как мне представляется на
практике. C++/Rust/etc -- теперь я ещё больше понимаю насколько важно
время сборки. А в идеальной и прекрасной системе со свободным ПО (значит
и исходники будут) на C/Go проблем нет никаких. Скорость,
производительность, простота, безопасность (куча ссылок касающаяся
недостатков динамической линковки про безопасность как-раз),
эффективность! Плюс никаких проблем с тем чтобы иметь софт с самыми
разносторонними по версиям зависимостями, ибо они всё равно вшиваются.

Я однозначный поклонник этого подхода!

Линковка ld и порядок -l аргументов

https://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking
Работал я со своей C программой в LLVM/Clang/FreeBSD, работал в
GNU/Linux, GCC 4.x, glibc. А сегодня в современной Ubuntu с GCC10 не мог
собрать её. Упорно ругается что не может найти символы всякие, которые
из библиотек берутся. Беглый поиск "а не бага ли это GCC?" не дал
результатов. Начал тупо перебирать и менять местами все эти -l
аргументы чтобы заработало, ибо надо успеть это сделать довольно срочно.

Но позже нашёл вот статью в которой объясняет как именно обрабатываются
-l, что магии там нет, всё довольно просто. А я просто совершенно не
понимал (точнее подозревал, но в корне не верно) как линковщик работает.
А всё так "сложно" не просто так -- а чтобы быстро работал ld. Можно
указать пару аргументов (--{start,end}-group) и будет работать всегда и
везде, грубо говоря, но с соответствующим performance overhead.

Соскучился по Ubuntu

Давно я что-то про неё ничего не писал. Нужно тут собрать одну
библиотеку под неё. Скачал самый последний LTS. После установки, первым
же делом сделал apt install build-essential. Ну разве могло оно пройти
успешно?

    [...]
    Err:8 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 linux-libc-dev amd64 5.4.0-42.46
      404  Not Found [IP: 2001:67c:1562::18 80]
    Fetched 38.8 MB in 9s (4,546 kB/s)
    E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-libc-dev_5.4.0-42.46_amd64.deb  404  Not Found [IP: 2001:67c:1562::18 80]

Ладно, apt-get update починил, ещё и GCC10 стал стягиваться.

Хочу установить libtap, libtai -- apt search по ним ничего не показывает.
Хотя в портах FreeBSD, например, обе имеются.

Python Concurrency From the Ground Up

https://www.youtube.com/watch?v=MCs5OvhV9S4
Очень понравилось выступление с живым показом как написать корутину на
Python, без asyncio, from the ground up.

Хоть у мужика и Emacs, но совсем не использует никакого автодополнения
(типа Ctrl-P из Vim), даже в bash всё любит набирать руками.

wpa_supplicant оказывается deprecated, как и ifconfig

https://losst.ru/top-5-prichin-ispolzovat-linux-v-2020
Чисто случайно из статьи вот узнал что wpa_supplicant оказывается тоже
уже устарел и вместо него используется wicd. Про него я не помню чтобы
слышал. Насколько ж давно я с WiFi последний раз работал под GNU/Linux!

HP почти переплёвывает Apple

https://www.linux.org.ru/news/hardware/15995352
HP удалённо блокирует принтеры, чтобы те не печатали. А ещё даже может
достучаться до них и через особые документы, отправляемые на печать
(чтобы и без Интернета мочь поднасрать). Скупердяйство не знает границ,
как верно заметили. До Apple конечно далеко, но всё равно удивляет эта
черта проприетарщиков.

В самолёте попоили собаку

https://lenta.ru/news/2020/11/10/dogplane/
... ну девушка начала оттуда же пить сама. Меня возмущают возмущения
людей :-). Да я сотни раз (тысячи?) так делал со всеми своими собаками,
давая и ложки облизывать, которыми сам же продолжаю есть, и из тарелки
или чашки чего полакать или там мороженое полизать.
Мерзкие пёсоненавистники!

Не забуду как хороша их слюна для заживления порезов/царапин! Был случай
когда я в детстве конкретно ободрал запястье, пришла собака наша, и
давай просто лизать это место. А я на компьютере вроде что-то смотрел.
Потом через несколько минут смотрю на руку -- а там и следа нет!

Конкурс красоты в Новой Зеландии

https://lenta.ru/news/2020/11/10/missnewzealand/
... выиграл мужик. Оказывается аналогично было и в Испании.
https://lenta.ru/news/2018/07/03/transmiss/
Там настолько всё плохо с женщинами, что на их конкурсах побеждают мужчины?
Или просто нормальным уже вход запрещён?

Тупость в статьях про качественный звук

В одном журнале вот увидел:

    Однако теорема Котельникова не дает ясных критериев, какая частота
    дискретизации нужна для КАЧЕСТВЕННОГО восстановления звукового
    сигнала из цифровых отсчетов. Ведь при частоте дискретизации 44 кГц
    на один период сигнала с частотой 22 кГц придется лишь 2 отсчета!
    Замените период синусоиды всего двумя прямоугольными импульсами –
    вот как искажаются высшие гармоники звукового сиг‐ нала в
    аудиозаписях стандарта CD. И лишь низ‐ кочастотные гармоники
    воспроизводятся довольно точно, так как на один их период приходятся
    десятки‐сотни отсчетов. Отсюда следует, что для качественного
    воспроизведения и за‐ писи аудио (например, в профессиональных
    целях) нужна повышенная частота дискретизации (96, 192 кГц...) Для
    решения этих задач по‐ явились «профессиональные» звуковые платы.
    При этом возрос поток передаваемых данных, что потребовало
    использовать более быструю шину PCI вместо ISA. Некоторые из этих
    плат мы рассмотрим далее.

Автор явно и конкретно не понимает что говорит теорема Котельникова. Он
считает что раз на экране увидел два прямоугольничка (два отсчёта для
22kHz) и они не похожи на красивые синусоиды, то вот так вот всё адски
искажается. В 200bf7ba55111f981e69e8e89b7cfcbf9d539379 я публиковал
ссылку на короткие видеоуроки от Xiph.org, а также там есть отдельное
видео как-раз про прямоугольнички и синусоиды. Прямоугольнички -- по
сути это просто другой способ представления данных, а не тот
электрический сигнал который подаётся (да и нельзя такой сформировать).
И там на осциллографах в видео показывают что эти два отсчёта идеально
передадут оригинальную синусоиду. Теорема Котельникова как-раз и говорит
что этих отсчётов достаточно. Буквально достаточно чтобы передать
информацию.

А большие частоты дискретизации нужны для обработки звука, чтобы при его
изменении терялось из-за округления как можно меньше информации. Особенно
важна глубина квантования. Но для конечного результата, CD более чем за
глаза достаточно.

Ctrl-F в режиме поиска

В ced719937ead049475dc5fbb5cb6d51dc5df98f8 писал про Ctrl-F (или q:) для
редактирования истории и текущей командной строки. Но забыл про то, что
аналогично оно работает и для строк поиска ("/", "?"): или Ctrl-F или
"q?" с "q/".

Закон Годвина

https://beldmit.livejournal.com/629418.html
https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%93%D0%BE%D0%B4%D0%B2%D0%B8%D0%BD%D0%B0
Не слышал о таком "законе" раньше. С автором (beldmit) полностью
солидарен что если собеседник переходит на мемы, то разговор можно
считать законченным, ибо это мерзкий сарказм. А он в беседе уже не несёт
ни смысловую нагрузку, ни, зачастую, уважение к собеседнику и
используется когда сказать уже нечего. Хотя, я наверное и сам часто
перехожу на него, но я никогда и не был хоть сколько-то приятным в
беседах.

А в Wikipedia есть ссылка на письмо Линуса в GNOME:
https://mail.gnome.org/archives/usability/2005-December/msg00022.html
где он (этим UI нацистам) припоминает что (форсированный) выбор файла
через иконки в миллион раз медленнее чем возможность ввести к нему путь
(особенно автодополняемый). Сегодня я долго боролся с тем, чтобы
грёбаный GDK заткнулся о том что он не может найти иконки для zathura,
ибо она у меня установлена в отдельной иерархии директорий, победив это
выставлением XDG_что-то-там. Яростно ненавидел и ненавижу подходы GNOME.

PDF просмотр в табах. XEmbed

https://tools.suckless.org/tabbed/
http://git.stargrave.org/cgit.cgi/dotfiles.git/commit/?id=006a3bcc53de2435426073730ca2de002e93b635
https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html
Сегодня меня осенило что ведь можно zathura помещать в табы. Точнее
стоило бы, вроде бы видел что её запускают внутри tabbed. Ибо когда надо
открыть много PDF (потому что надо быстро просмотреть/найти в них что-то,
но не знаешь где именно), то, делая zathura *.pdf, в dwm порождается
много окон, который регулярно помещаются из стэка в главную область экрана.

Вообще это не проблема на самом деле. Тут всё ok. Но у меня давняя
проблема с zathura что при изменении геометрии окна она бывает
"залипает". Или ни на что не реагирует или не реагирует система
рендеринга у неё. И когда окно перемещается из стэка в главную область
dwm, то resize происходит и PDF-ку уже возможно не получится прочитать
из-за глюков zathura. Поэтому я делал for p (*.pdf) zathura $p и
открывая по одной PDF-ке у меня получалось что все окна в главной
области сразу же.

Подумал что одно окно с табами упростит жизнь. До suckless проекта я и
не слышал о XEmbed протоколе X-ов, который позволяет делать
таб-менеджеры и включать в него "детей". Не нужно делать табы в
терминалах или броузерах -- нужно чтобы они поддерживали XEmbed протокол
и за табы будет отвечать внешняя программа, типа tabbed. tabbed имеет
всякие сочетания клавиш для переключения, перемещения, создания
(запуском внешней команды), удаления табов. tabbed можно указать команду
для запуска и ей он сможет передать id своего окна для embedding-а.

Раньше не использовал ничего из этого, так как табы в терминале у меня
tmux-овые, а GUI броузер xombrero сам ими рулит (uzbl, surf не
использую). С zathura это получилось. Вот только... теперь она вообще в
перманентном состоянии "замороженности" внутри tabbed и ничего не
рендерит. Проблема zathura тут стала проявляться 100% времени.

Я смог найти упоминание этой проблемы, но нигде нет намёков на решение.
Но у меня и родная zathura из портов, далеко не самая свежая. А она ещё
и от girara зависит. Пошёл обновлять всё это. Понадобилось ещё и MuPDF
ставить тоже не из портов, ибо этот был не достаточно свежий. Всё это
отдельный квест, ибо никаких привычных configure+make+make install или
redo (:-)!) тут нет. ninja, meson и чисто голые Makefile-ы. В этом году
ещё и не раз видел CMake сборки. Вот зоопарк то развёлся!

Но в итоге всё поставил, и написал скрипт обёртку над zathura который
запускает tabbed если его не нашёл или суёт в уже имеющийся эту zathura.
А на самом деле то мне надо было просто её (+зависимости) обновить чтобы
исчезла бага при resize окон.

Ускорение git clone в 100 раз

https://habr.com/ru/post/527116/
Ожидал что вся статья будет посвящена --depth. Почти так, плюс ещё
упомянули стягивание только нужного ref-а. Стыдоба об этом писать целые
статьи (это тема для небольших блогов/twitter-ов). А вот (единственный,
пока) комментарий куда полезнее, намекающий на --reference, который
учтёт наличие локального репозитория.

Почему IPsec вместо WireGuard?

В 1d5bc1731a1e8f77fed6e7c60bbdeb9db421a87d написал что всё равно
использую IPsec по возможности. Если забыть про то, что IPsec тесно
интегрирован в ОС/ядро и позволяет делать далеко не только VPN туннели,
то всё равно остаётся вопрос эффективности.

IPsec ESP это отдельный тип IP-пакета, в котором (для AES-GCM) : SPI
(4B) + SEQ (4B) + IV (8B) + padLen (1B) + PAD (0-3B) + NextHdr (1B) = 18
+ 0-3 байта overhead. Причём от IV (вместо него использовать ESN) или
SEQ можно было бы для AEAD-ов где это всё счётчики и избавиться уж, но
стандарты гласят вот так.

WireGuard (из его whitepaper): type+reserved (4B) + counter (8B) + I_m
(4B) + UDP заголовок (8B) = 24 байта. В любом случае чуть больше ESP.
Но, при этом ещё и CRC надо считать в UDP заголовке! Хотя он и не нужен,
ибо и так данные аутентифицируются. Так что даже в теории он любом
случае чуть менее эффективен. На практике парсинг ESP возможно отъедает
и больше CPU из-за if-ов всяких, но это уже вопрос конкретной
реализации, которую можно и упростить/ускорить.

Ну а ChaCha20+Poly1305 для ESP уже есть: https://tools.ietf.org/html/rfc7634

И если мне нужно обеспечить защиту только между двумя IP-адресами, двумя
хостями, то в WireGuard-е пришлось бы шифровать IP-пакеты -- это же VPN,
а в IPsec использовать транспортный режим где внутри ESP будет лежать
сразу же TCP/UDP/SCTP/whatever. Но это конечно вопрос решаемых задач. Но
вот у меня по факту нигде нет туннельного режима IPsec, хотя есть пара
туннелей gif-туннелей между двумя хостами, а в остальном только
транспортные между хостами, чтобы не городить между ними никаких
костылей в виде TLS.

Время-вперёд Свиридова

https://ru.wikipedia.org/wiki/%D0%92%D1%80%D0%B5%D0%BC%D1%8F,_%D0%B2%D0%BF%D0%B5%D1%80%D1%91%D0%B4!_(%D1%81%D1%8E%D0%B8%D1%82%D0%B0)
А ещё, когда вспоминал про "трэки vs альбомы" (d0f0adae0afb2d1690b93a924f032582fb19900d)
не упомянул что совершенно не знал про "Время-вперёд" Свиридова. Я до
Олимпиады-2014 считал что мотивчик с трубами это просто такая здоровская
заставка к телепередаче Время. Впервые услышал (почти) дальнейшую тему
этой композиции только при просмотре открытия в Сочи. Офигеннейшая! Да и
только эту "красную" часть открытия я лучшего всего и запомнил,
наверняка из-за музыки.

Как автор curl работает с git-ом

https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/
Всё банально и ничего особо интересного. Но вот обратил внимание что он
не использует git stash, потому что проще сделать отдельную ветку и в
ней коммит. В принципе то оно конечно верно, без stash жить можно. Но...
как я писал в 3605f863a029ba28f8258bc023f94ef1045b20dc -- огромная куча
команд git-а это сахар просто упрощающий жизнь. Лично у меня stash
использует супер часто. Даже не смотря на то, что у меня алиасы на git
branch (Gb) и git checkout (Gc), я всё равно не смогу делать всё так же
быстро и удобно как с git stash-ом. В котором я кстати только в это году
научился (точнее наконец то задумался) делать git stash push
определённых файлов.

Ну тут у каждого свои вкусы и предпочтения. Коллеги любили делать git
remote update, а я никогда, ибо только git fetch. Многие любят делать
git checkout -b, а я только отдельно git branch и git checkout команды
по отдельности (точнее их алиасы). Опять же, куча команд которые чего
только не умеют делать. git pull делаю только если уверен в результате
(мой remote, состояние которого я знаю) или добавляя какой-нибудь --rebase.

Маски-шоу

https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D0%BA%D0%B8-%D1%88%D0%BE%D1%83
https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D0%BA%D0%B8_(%D0%BA%D0%BE%D0%BC%D0%B8%D0%BA-%D1%82%D1%80%D1%83%D0%BF%D0%BF%D0%B0)
Глядя на фильмы Чаплина, постоянно про себя вспоминал про сериал
Маски-шоу, который обожал смотреть по ТВ, когда попадал на него.
До сих пор в голове кучу сценок оттуда помню. А озвучка... по ней
сразу передача узнавалась и существенный вклад в забаву именно она
и вносила.

Посмотрел "Золотую лихорадку" Чаплина

https://ru.wikipedia.org/wiki/%D0%97%D0%BE%D0%BB%D0%BE%D1%82%D0%B0%D1%8F_%D0%BB%D0%B8%D1%85%D0%BE%D1%80%D0%B0%D0%B4%D0%BA%D0%B0_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Конечно же понравилась! Очень впечатлён сценой с домом на краю пропасти.
Так классно сделано, без каких-либо этих компьютеров! Ну и вот фильму
будет почти скоро как сотня лет, а женщины как играли ради забавы с
чувствами мужчин, так и продолжают в своём духе.

Попробовал WireGuard

Я его одобрял, но на деле ни разу не пробовал использовать. Использовал
wireguard-go реализацию и wireguard-tools. Всё собралосб без проблем. С
первого раза всё настроил -- всё заработало, как по маслу. iperf3
показал сильно скачущую скорость, но достигающую 800 Mbps между IPv6
адресами поверх туннеля тоже по IPv6. Для userspace Go реализации я
считаю это отлично. В своём GoVPN я достигал вроде только 700 с чем-то
Mbps. Продолжаю и дальше одобрять этот VPN! Я всё равно по технической
возможности стал бы использовать IPsec (собственно, он у меня везде и
используется), но когда надо пробиться VPN-ом за NAT-ом, то IPsec не
подходит.

А ещё увидел что он тоже использует TAI64N
(7a17418a8316ad41bbb0750c40f24f8448b6599d). Нравится! (C) Борат

Посмотрел "Удар головой"

https://ru.wikipedia.org/wiki/%D0%A3%D0%B4%D0%B0%D1%80_%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BE%D0%B9_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Ещё один хороший французский фильм. В котором Франсуа Перрена играет не
Пьер Ришар, что непривычно. Показывает что не надо опускаться до уровня
всяких уродов и вести и отвечать им также как и они бы поступали. В
фильме типа они сами себя наказывают. Но то фильм, а в жизни даже с
судами фиг добьёшься справедливости.

Посмотрел "Огни большого города"

https://ru.wikipedia.org/wiki/%D0%9E%D0%B3%D0%BD%D0%B8_%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D0%BE%D0%B3%D0%BE_%D0%B3%D0%BE%D1%80%D0%BE%D0%B4%D0%B0
Очень понравился! Оторвать от Чаплина глаз сложно, да как и от красавицы
главной героини. Всё что видел с ним по телевизору нравилось всегда!

Ctrl-F в режиме редактирования строки

Пару недель назад коллега поделился обнаруженной в Vim командой Ctrl-F в
режиме командной строки: оно вызывает "q:" окно, в котором и текущая
строка есть, которую можно отредактировать обычным модальным способом.
Часто хотелось отредактировать строку в Vim-е в ":" через Vim :-). Но
явно плохо искал в документации или забивал на это, или вообще
редактировал строку просто в файле, а дальше копировать в регистр и
выполнял его. А Ctrl-F офигенная штука, нужно не забывать про неё, хоть
и не часто требуется!

10 простых шагов захождения на сайты в 2018 году

Нашёл в одном журнале:

    1. Открываешь сайт.
    2. Отказываешься от пуш-уведомлений.
    3. Закрываешь уведомление о кукисах.
    4. Закрываешь попап с предложением подписки.
    5. Закрываешь онлайн-чат.
    6. Закрываешь окошко «Ваш город....?».
    7. Закрываешь окошко «Не нашли что искали? Оставьте телефон, мы сразу перезвоним».
    8. Закрываешь попап «Подпишитесь на наши соц. сети».
    9. Извиняешься перед окружающими за свои громкие маты
    10.Вспоминаешь, зачем открыл сайт

Спешка людей, качество работы, музыка

Недавно критиковал мысль друга, который считает что темп жизни стал
быстрее и времени у людей мало на что стало хватать, поэтому всё нужно
здесь и сейчас.

Не спорю что очень многие стали всюду и везде спешить. Вот только...
кому это надо и кому от этого лучше? Если бы они успевали делать больше
чем "не спешащие" -- ok. Вот только беда в том, что это не так. Людям
нужно узнать ответ на вопрос "почему мой nginx вот тут не работает"
здесь и сейчас в stackexchange/google -- на этот вопрос они, допустим,
получат ответ, вот только ни знаний, ни понимания он не добавит. У них
будут снова и снова возникать аналогичные вопросы, тогда как один раз,
посидев подольше с документацией, пошевелив мозгами, можно впредь все
эти вопросы закрыть. Но о гугл-программистах уже писал:
7cdc4d886c28ff3b454a20f3328c9b6f5ff69036
Почему то очень хочется вставить цитату Пратчетта (хотя может и не к месту):

    Дай человеку огонь, и ему будет тепло до конца дня. Подожги
    человека, и ему будет тепло до конца его жизни.

Побыстрее пройти курсы, побыстрее пройти tutorial -- всё ведёт к
непониманию и дорогой цене такого сотрудника, который и обманывает
надеждами и ожиданиями, и за которым или переделывать всё надо или
доделывать или помогать постоянно.

С одним коллегой мы лучше других знаем Vim только потому, что когда
понимаем что сейчас что-то явно можно лучше в нём сделать для какого-то
редактирования, то мы остановимся и пойдём искать нужное в документации.
Иногда просто так читаем документацию, какие-то её разделы, ибо
информации много, но каждый раз что-нибудь от отложится в голове.
Встречал людей которые годами пользуются Vim, но, с моей точки зрения,
не намного дальше vimtutor ушли. Оно конечно уже всё равно эффективнее
чем блокнот/nano/whatever, но чем больше познаёшь инструмент, тем больше
понимаешь и ценишь как он экономит наше время. Можно сразу после школы,
а то и недоучившись пойти работать, а можно ещё несколько лет потратить
на обучение и получить базу знаний которая будет фундаментом до конца
жизни, стоящего этих лет.

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

Недавно с отцом говорили о гитарах и музыкантах и есть известный факт
что многие хотят и мечтают стать рок-звёздами (ok, мечтали, раньше --
теперь мечтают рэп-звёздами или это уже тоже вышло из моды?), особенно
гитаристами, но только мало кто, особенно будучи подростком, понимает
что знание трёх аккордов и умение фигачить как Ангус Янг -- разделяет
гигантская пропасть. Все эти наши великие гитаристы всю жизнь, грубо
говоря, каждый день часами пилят и пилят, пилят и пилят одно и то же.
Это колоссальное дрочево, колоссальный труд. У большинства людей
терпения на это не хватит. А видят люди только получившиеся сливки их
работы -- концерты и выступления. Запись альбома может длиться
относительно недолго, типа арендовали сколько-то раз студию, записались,
потом отдельно где-то это всё сводится. Но перед этим годами пилят и
пилят одно и то же. Папа то у меня играл в ансамбле на гитаре и до сих
пор дома её в руки берёт. А я пробовал научиться, даже ноты научился
читать (сейчас то конечно уже забыл), но понял что я не настолько хочу
играть, ибо это чёртова прорва времени нужна и терпения.

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

Идёшь куда-нибудь, пересёкся на улице со старым знакомым. Ты рад ему,
многое хотел бы расспросить, но зная что у вас около полуминуты времени,
ибо вы оба имеете дела, ты не будешь задавать вопросы о жизни и прочем,
кроме чисто для галочки. Ты бы мог за полминуты узнать как и где живёт,
где работает, женат ли, есть ли дети, всё такое прочее, но вот так вот
шустро полученная информация будет сродни допросу. По хорошему можно
договориться о встрече в обстановке без ощутимых временных ограничений.
Тут можно было бы как-раз и сказать: вот, все всюду спешат и свободное
время -- роскошь. А я скажу что это люди себе (точнее СМИ) вбивают что
они как-будто такие занятые. По хорошему можно прям сейчас на улице было
бы оторваться от похода в магазин или какому-то запланированному
посещению инстанций, но они никуда не убегут, а вот с другом/знакомым ты
уже возможно не пересечёшься. Уверен что мало кто когда пожалел бы о
таком спонтанном забивании на дела, ради разговора с другим человеком.
Нам вбивают эти ценности спешки, которые не дают ничего полезного в
жизни, разве что чуть более скоростное перемалывание дел в обществе
потребления, где выгода будет только производителям, где спешащие люди
ими не являются.

          ------------------------ >8 ------------------------

А вообще хотел написать про музыку. Сегодня вот упомянул про Peccatum и
Starofash группы. И особенно у Starofash есть много длинных композиций.
Пять минут может идти медленная полу-унылая мелодия, а потом что-то
забойное. Даже в black метале типа Funeral Mist есть трэки за 10мин. И
вот я подумал что ведь все эти спешащие люди в принципе не стали бы
слушать такую музыку. Её не поставят по радио, ибо можно было бы
проиграть в три раза больше трэков, между которыми вставить рекламу. На
работе с коллегой выяснили что в целом (в основной массе) люди перестали
слушать альбомы. Они слушают единичные трэки. Этот же коллега тоже
альбомы не слушает. Почему то в блоге об этом не писал, но что несколько
лет назад, что сейчас я считаю что половина рок-музыки которая у меня
есть: по настоящему воспринимается только прослушивая целым альбомом.

Когда-то я был просто шокирован прослушиванием альбома Pink Floyd "The
Wall". Все знают и все слышали основной трэк с детским хором из него. И
я лет 20 его знал и слышал. Но как-то дома, вроде папа, поставил
полностью этот альбом. К этому трэку очень долго всё подходит, но оно
настолько хорошо с ним сочетается, что у меня точно были мурашки по коже
от ощущений! Можно сказать, что я за 20лет слушания -- впервые его
услышал и прочувствовал!

Gorguts "Colored Sands" (fc345478530d9a9161fa81f9ecabdec6aa876d40) --
если с него поставить сразу "Enemies Of Compassion", где сразу бойкое
рубилово, то... не, удовольствие конечно получишь, бесспорно, но не
такое как если бы перед этим играл симфонический "Battle Of Chamdo"
трэк. И тем более не такое как если перед ним все остальные четыре
трэка. Это совершенно разные уровни впечатлений!

Есть много альбомов (какой-то от Flying Colors, какой-то от Fredrik
Thordendal, да тот же Pleiades' Dust от Gorguts) которые можно считать
одним большим трэком. Да, какие-то части нравятся больше, их можно
переслушать, но они не могут восприниматься отдельно от всего
остального. Если бы на альбомах Starofash вырезать унылые пианино,
оставив вокал Ihsahn-а с электрогитарами... это уже совершенно не то.
Тоже имеет ценность, но не такую, не с такими сильными ощущениями.

Ещё в школе один друг спросил почему на "Secret Of The Runes" Therion-а
два последних трэка на альбоме (кавер на "Summernight City" ABBA и
Crying Days) помечены как "бонус", разве на других релизах альбомов их
нет? Блин, да ведь там все они объединены одной общей тематикой,
(Ginnungagap, Midgård, Asgård, Jotunheim, Schwarzalbenheim, Ljusalfheim,
Muspelheim, Nifelheim, Vanaheim, Helheim), а тут внезапно появится ABBA?
Наборы медленных и быстрых композиций создают общую атмосферу. На
переходах сильнее всё чувствуется.

На концертах стараются давать разогрев! Бывают концерты без него, и
вроде бы и группа которую годами ждал, и играют здорово, но ты не
накачан энергией. На концерте люди как конденсаторы -- без заряда
колбаситься сложно начать. А ещё в самом начале концерта нужно тупо и
привыкнуть ушами к звуку. А ещё когда выступление группы начинается, то
куча людей передислоцируется кто подальше от сцены, кто поближе и это
отвлекает. Поэтому я считаю ОЧЕНЬ круто что Rammstein в прошлом году
(смотрел только видео) вышли с каким-то вообще медлячком заупокойным.

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

Повторюсь что во всём нужен баланс и мера. Быть нерасторопным и
медлительным тоже наверное плохо. Шустрая молодёжь наверное побольше
успевает попробовать... что можно быстро попробовать. Но вот например
как минимум половины рок музыки люди уже не в состоянии воспринять и
получить непередаваемые эмоции, ибо альбомы люди не слушают (а я с
трудом вспоминаю когда я отдельно трэк то себе ставил, не говоря про
shuffled проигрывание). Безусловно отдельным трэкам и сборникам есть ещё
какое место в жизни! Много мест где музыкальный фон бы не помешал, но
времени всего 15мин например. Или я вот поставлю далеко не каждый
альбом, если знаю что меня могут прервать (куда-нибудь пойти), отвлечь и
всё такое (лучше не слушать, чем оторваться от прослушивания, пускай
даже в фоне пока пишешь код -- это как не кончить: лучше даже и не
начинать тогда).

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

И по жизни у меня как-то двояко получается: с одной стороны я против
спешки именно в жизни. Если я весь в работе, но мне позвонила мама
предложив пойти с ними погулять по нашему королёвскому парку, а я
разозлён от того что я только начал, только вошёл в раж и работа идёт
как по маслу -- но с годами я понимаю что общение с людьми (близкими)
сильно ценнее. Именно с близкими, друзьями, родственниками, возможно
коллегами. В этом году я понял что (@#$%!) без отдыха, но не выходит
работать, можно выгореть. И это будет дороже чем... если бы не выгорать
и своевременно например отдыхать (по ivi я помню, что доходил до такого
состояния что или разосрусь так что меня обязаны будут уволить, или...
меня директор просто насильно, похоже очень хорошо понимая людей,
выгонял в отпуск, после которого всё нормализовывалось). С другой
стороны я всегда быстро хожу, ненавидя неспешное передвижение людей,
ведь какой-то толк тратить время на перемещение? Мне доставляют почти
физические страдания наблюдения за тем, как люди медленно редактируют
текст (плохо зная редактор или не используя эффективный редактор
(+возможно клавиатуру, променивая эстетику на эффективность)). В меня
вселяется бес когда я вижу как на смартфонах людей или в броузерах с
JS-ом еле-еле неспешно загружаются и подгружаются с крутилками и
свистоперделками анимированными их сайты. Сейчас меня вообще много что
бесит, особенно когда вот юзаешь go, C, redo, Ethernet (вместо WiFi,
который вижу у других людей). Возможно я просто всё смешал: работа
работой, а общение/развлечения это уже другое, а обучение так вообще
третье.

Но если брать эффективность клавиатур/редакторов, то некоторые говорят
что они много думают, но мало набирают. Ok, допустим, и моя специфика
работы другая. То что надумал -- надо ещё в сотнях и тысячах строк кода
оформить. Мне не раз говорили что я много пишу текста (письма там)
потому что могу, потому что клавиатура тактильная. И любой большой
текста значит написан "ещё одним с тактильной клавой". Тоже возможно
верно и возможно мне не стоит изливать мысли потому что могу, а лучше бы
пошёл спать в час ночи (сейчас) и было бы больше проку :-). Но в целом,
считаю, спешка мало чего хорошего даёт. "Поспешишь -- людей насмешишь!"
Есть места где стоило бы (не ждать например полдня другого самолёта,
потому что пару минут кто-нибудь не удосужился поднапрячься и поспешить,
раз проспал), но в целом в жизни спешка полезна только изредка.
Постоянная -- приводит к гугл-программистам и отсутствию кучи эмоций,
переживаний и ощущений.

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

RPi400 как старый добрый Спектрум

https://martinpeck.com/blog/2020/11/06/Raspberry-Pi-400/
Тоже в детстве подключал Спектрум к телевизору и магнитофону. Вот только
у нас был не красивенький встроенный в клавиатуру, а отдельная коробка с
разъёмами от космических аппаратов, к которой отдельно клавиатура
подключалась.

Заценил Peccatum и Starofash

https://en.wikipedia.org/wiki/Peccatum
https://en.wikipedia.org/wiki/Starofash
https://www.youtube.com/watch?v=xkYQXS4_R-E
На одном альбоме Ihsahn-а заинтересовался что за женщина поёт. Оказалось
что его жена, с которой у него даже совместный проект Peccatum. А потом
у неё свой Starofash.

В целом оба проекта понравились. Много правда есть унылого и неспешного,
особенно у Starofash, где даже по пять минут нет ни одной электрогитары.
Но я успел даже по два раза все альбомы прослушать. Ибо есть пять минут
уныния, а потом что-то клёвое и забойное.

Ну а Ihsahn вообще офигенный! Всё что с ним не слышал -- всё очень
здоровское и достойное! Emperor, сама его группа Ihsahn (выступление
которой в живьём не забуду, особенно мрачнейший The Grave впечатлил) и
вот эти ещё две. Плюс в скольких он проектах не подпевал как гость --
всегда голос узнаётся. Альбомы самого Ihsahn я за последние дни
переслушал по несколько раз. Причём у него же вот и совсем спокойные
есть (с выступления в Москве): https://www.youtube.com/watch?v=zuS_bj3N2mc
но и тот же Grave: https://www.youtube.com/watch?v=1Mrc9za28Ck

Команды git-а: worktree, subtree

https://blog.meain.io/2020/bunch-of-git-stuff/
Показаны примеры применения относительно новых команд worktree/subtree.
Первую я на практике использовал несколько раз -- есть случаи когда
реально полезно и удобно с ней. Но запросто у человека может и не
возникнуть надобности в ней. subtree не использовал, и вот с ходу пока
даже не могу представить когда бы понадобилась лично мне (так то в
статье есть примеры).

Вообще если бы я не знал git, то судя по статьям/рассылкам/блогам вряд
ли бы к нему подступался, ибо только ленивый не говорит что он дико
сложный и не понятный. Это также подтверждалось постоянно и на работах,
где люди с трудом въезжают в него. Да и если объективно прикинуть, то
достаточно посмотреть на git reset: что делает эта команда? Чего только
не делает! git checkout? Аналогично! Ну или я (до сих пор), как минимум,
не в состоянии коротко и ясно сказать для чего они. Они много для чего и
это увеличивает порог входа.

В ivi из-за плохих пониманий git-а (точнее применимости и допустимости
некоторых практик) некоторым командам запрещалось делать git cherry-pick
или rebase-ы, особенно интерактивные. git -- мощный инструмент, но
который в "плохих" руках может и вредить. Защиты от дурака в нём не много.

У меня никогда не возникало проблем с git-ом. Во-первых, мне никто
никогда с ним не помогал -- весь путь его "познания" проходил сам (с
коллегами). Во-вторых, мне кажется я использовал его фичи только после
их познания/узнавания и у меня не возникало потребностей в том что не
знал. Возможно просто везло, а не как новичкам приходящим в команду и
которых сразу бросают в пучины git rebase. Плюс мне кажется что на меня
снизошло какое-то озарение после прочтения:
http://www.ftp.newartisans.com/pub/git.from.bottom.up.pdf
после которого git выглядит чрезвычайно простой штукой.

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

Я не использовал ни Mercurial (только hg pull/clone), ни Bazaar, ни Arch
(на который вроде как и забили), ни Darcs. Читал про них. Mercurial
выглядит чище и проще, не является нагромождением всего и вся
раскиданным и пересекающимся в разных командах. Но про него от очень
опытных пользователей, которые и хорошо умеют git, наслышан про его
негибкость и сложности делать относительно сложные вещи. Для новичков
Mercurial, насколько понимаю, хорош, но для людей которые чётко понимают
что хотят сотворить с историей коммитов -- он будет занозой. Просто
наслышан о таком мнении от самых разных опытных людей, которые в итоге
переходят на git.

А ещё отдельная боль с git-ом это Github. Точнее проблема с людьми,
упорото считающих что git и Github это синонимы. Github закрывает
репозитории? А, нам всем конец, всё пропало, как жить дальше!? Только
ленивый не напоминает в комментариях всяких ресурсов что git как бы
децентрализованная система.

В общем, git штука с большим порогом входа, в том числе из-за неряшливых
команд, но очень мощный инструмент. И из-за своей мощности (возможностей
тасовки и вообще работы с коммитами) он стоит изучения/использования.
Можно не знать и 90% всех его имеющихся команд и их опций и отлично жить
с ним.

Синхронные и асинхронные коммуникации на работе

https://habr.com/ru/post/526754/
Во-во-во! Все точно и по делу сказано! И БЕЗУМНО печально что многие
люди не понимают всего написанного. И крайне удручает когда на работе
вместо асинхронных методов становятся популярны синхронные, ведь это же
(@#$%!) так удобно, так быстро и шустро все стали отвечать красотке Оле!
А ещё удручает когда молодёжь, по жизни не пользуясь асинхронными
методами общения, и не умеет, и не понимает и не знает как использовать
тот же email/tracker. Или использует tracker "на отвали" чтобы там
надоедливому менеджеру завести всё же тикет, вот только при этом он ещё
и сразу напишет в синхронном общении о том что он сделал тикет. И
полностью поддерживаю основную мысль:

    Самая важная мысль. Асинхронная коммуникация -- это прежде всего
    уважение ко времени и планам, а также ко вниманию и сосредоточенности
    коллег.

Хотя конечно есть и крайности этого подхода, когда можно неделями по
неспешной, уважающей окружающих, почте ни к чему не приходить и долго
мусолить. Иногда бывает надо и полезно собраться синхронно всем
пообщаться. И тут тоже крайность часто бывает: регулярные собрания с
кучей воды и болтовни не по делу или когда есть много людей которых не
касается обсуждаемый вопрос. И ладно бы потерпеть 5мин, если бы они
длились столько.

Посмотрел "Чапаева"

https://ru.wikipedia.org/wiki/%D0%A7%D0%B0%D0%BF%D0%B0%D0%B5%D0%B2_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Кроме фильмов Чаплина, даже не вспомню что я ещё настолько старого смотрел.
Фильм очень понравился! Очень необычно сейчас такое смотреть -- совсем
по другому постановка сделана. В начале то так вообще просто небольшие
сценки, как бы не связанные между собой. Треть фильма я как-будто уже
знал, ибо столько фраз узнавал! А развязка фильма, с концом Чапаева,
сделана так коротко и быстро! И если в этом фильме она занимала,
допустим 30-40% (ну так, на память/на глаз) фильма, а всё остальное это
набор очень смешных сцен, то в современных фильмах бы на смешное
оставили 20%, дальше 60% времени медленно и угрюмо бы показывали
неспешную нагнетающуюся развязку, немного action-а, а дальше ещё минут
15 все бы горевали и грустили под унылую музыку. А тут -- пострекотали
по плывущему Чапаю и сразу титры. Но очень много смешного и забавного в
нём -- это запоминается!

gu в Xombrero

В Xombrero броузере есть "gu" команда, которая переходит на URL на
"ступень выше" -- отрезает слово до следующего слэша. Очень часто
хочется отрезать больше чем один слэш, например когда я в каком-то блоге
на "://.../whatever/2020/01/02" и gu меня бросит на "://.../whatever/2020/01",
потом на "://.../whatever/2020", и т.д.. А часто бывает так, что перейдя
по уровень выше, тебе сделают редирект снова на низлежащий уровень. И
мне приходится уже "O" командой редактировать ссылку, backspace-ом
удаляя нужный кусок URL-а.

А вчера у меня какой-то нейрон сказал голове "а что если добавить
число перед gu, как в vi можно же для кучи команд добавить число". И
действительно "3gu" сразу откидывают до трёх уровней. Почему мне эта
идея в голове не приходила столько лет и сколько времени я терял на
ручное удаление?! Ну или почему я так плохо читаю доки?

Обновление matterircd

Обновил локальный matterircd: мост между Mattermost (который у нас на
работе используется) и IRC клиентом.

Пока возился с обновлением, смотрением как какие опции конфига влияют на
поведение, заметил что MM в целом очень не прочь потерять сообщения. Раз
в несколько месяцев но выясняется что какие-то сообщения я не видел и их
реально нету в логах irssi. А выясняется когда точно известно что что-то
посылали или точно на что-то ждёшь ответа. Причём matterircd использует
прям буквально ту же самую кодовую базу что и сам сервер MM. Так что MM
вообще не гарантирует доставки.

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

s/XXX/ позволяет удалить своё сообщение, а s/XXX/new text --
отредактировать. Но там нужно самостоятельно высчитывать номер *своего*
сообщения и у меня это плохо выходит и мне логика не всегда понятна их
нумерации (как-будто даже какой-то баг).

Почему я считаю man-ы плохим форматом документации?

Мне казалось что об этом писал в блоге, но что-то с ходу не нашёл.

man-ы мне в первую очередь не нравятся тем, что в них нет ссылок и
возможности перехода по ним. Напишут "смотрите EXAMPLES", и вводи
"/EXAMPLES", а ещё лучше с не забывать "/^EXAMPLES". Напишут смотреть
другой man, и снова делать это всё руками. А как открыть man сразу на
нужной секции? Штатного способа не предлагают. Хотя можно и сделать хак
в виде: man -P "less +/^EXAMPLES" ...

Другое дело info! То самое, что является единственным и основным
форматом документации в GNU. Оно уже структурировано, имеет ссылки. По
сути это уже гипертекстовый документ/формат, куда раньше появившийся чем
HTML. Можно одним вызовом (-n опция) прыгнуть на нужные ссылки/ноды.

man для простых и коротких команд, чисто классических по идеологии Unix,
ещё терпимо, так как зачем им ссылаться на что-то, ведь команда
выполняет свою чётко заданную работу. Но огромных программ тоже не мало.
Один GnuPG чего стоит (но у него и info есть (собственно, man-ы в нём из
него делаются)). А вот когда речь про документацию на библиотеку (C), то
без ссылок жизнь не мила. Один man perl содержит *только* ссылки на
несколько десятков других man-ов, как и man zsh содержит ссылки или иди
в zshall.

info ещё приятен тем, что он сам по себе human-readable формат, который
можно и без дополнительного ПО прочитать. man не читабельный, но его
формат всё же достаточно прост для простых утилит -- да и кто когда-либо
жаловался на то, что он не может прочитать man? Идеология вызова
каких-нибудь eqn и tbl процессоров (в дополнении к troff) мне нравится
даже больше чем жёстко отрендеренный info. Но, так как на практике это
всё равно всё смотрится в терминале, то желания перерендерить не
возникает -- is good enough.

Как альтернатива info мог бы выступать HTML, который тоже из терминала
можно смотреть текстовыми броузерами. Но, если каждую ноду выносить в
отдельный .html, то нельзя будет искать по всей документации к
программе/библиотеке! А в .info можно по всей. Делать одну большую
.html-ку решает проблему, но её будет неудобно читать, но это уж можно и
потерпеть.

А если документация просто огромна? .info позволяет разделять её на
отдельные файлы:

      6942 gnupg.info
    300360 gnupg.info-1
    271959 gnupg.info-2

где в головном .info есть ссылки на -[12], динамически подгружаемые
файлы по мере надобности. С .html такой возможности нет (если только не
терять возможность поиска). .info же делает это просто автоматически.

В общем случае .info позволяет и картинки встраивать (точнее ссылаться
на них, в отдельных файлах), но я видел работоспособность этого только в
Emacs графическом.

По мне так это прям чуть ли не идеальный формат для документации. Ok, на
самом деле Microsoft CHM тоже выглядит как в теории хорошая
альтернатива, если бы конечно не была проприетарной. Это и HTML, который
может быть перерендерен как надо (или в терминале смотришь, или в GUI на
4k мониторе), и ещё и сжат в одном bundle-е, и ещё и поиск по нему
возможен. С обычным .html, в принципе, тоже никто не запрещает
использовать grep по файлам, но удобно ли это? Но готовых решений для
.chm просмотра (с поиском) мне не известно чтобы написали, тогда как
.info существует уже больше тридцати лет (судя по Wikipedia, ссылающейся
на ITS Emacs, почти 40 лет).

          ------------------------ >8 ------------------------

Но .info ещё нужно и чем-то создать. Штатно предлагаемый GNU Texinfo это
отдельный формат мне так нравящийся!

* Писать руками .man -- небольшого размера ещё терпимо, но в целом
  увольте этим заниматься!
* Писать HTML от руки можно, хотя и не очень удобно читать его исходный
  код. Но терпимо, но всё же не даром не многие на нём пишут напрямую.
* Markdown -- полностью не признаю этот формат. Ибо НЕТ такого формата!
  Есть только с десяток (больше?) разрозненных малосовместимых между
  собой диалектов. И я уже десятки раз видел как кто-то даёт "markdown",
  но именно моим процессором оно не обрабатывается. ОЧЕНЬ небольшое
  подмножество будет работать гарантированно везде. Настолько небольшое,
  что мне в принципе оно не интересно, ибо это несерьёзно. А писать на
  "github markdown", "XXX markdown", "whatever markdown"... серьёзно?
* reStructured Text -- так как его реализаций не много (не одна ли
  docutils?), то он будет работать, в отличии от Markdown, везде. Именно
  reST, а не Sphinx надмножество. Мне он нравился и хоть он и зависит от
  Python, но я на reST/Sphinx писал всё на свете. Даже web-сайты были
  когда-то все на нём сделаны, ибо HTML выхлоп у него вполне себе
  хороший. Но... его возможностей форматирования мне не хватало
  частенько. Сделать жирную ссылку -- проблема (собственно, я даже не
  помню можно ли это в принципе сделать). Делать сложные структуры с
  многоуровневыми списками и табличками внутри -- ± можно, но уже очень
  сложно читается и требует большой аккуратности из-за отступов.
  Генерировать reST тоже становится проблематично
* AsciiDoc -- использовал его на первой работе (не мой выбор). Мало чего
  по нему помню, но, хотя бы, это вроде бы действительно отдельный
  нормальный формат, а не куча диалектов под одним именем (ненавижу
  сраный Markdown!). git документация написана на нём. Выглядит как
  хорошая альтернатива reST, но всё равно зависит от Python, в котором
  де-факто reST
* Texinfo -- на этот формат я возможно не смотрел потому что он ещё с
  80-х годов. Возможно потому что есть "tex" и кажется что имеется связь
  с TeX. Но это лучший формат что я видел для создания .html (и конечно
  же .info)! Некая золотая середина между гибкостью и свободой
  самовыражения HTML и лёгкостью чтения/написания reST! Плюс написал на
  C/Perl, поэтому работает очень быстро, не требует тяжёлых Python-ов.
  Удобен для машинного генерирования. Удобен для работы в редакторе.
  Имеет множество плюшек и сахара для создания документации по исходному
  коду (reST не имеет, но Sphinx через директивы поддерживает).

Texinfo явно сильно заточен для создания доки по программам. Может
мешать местами его древовидная работа с нодами, однако такая же
древовидная требуется и в Sphinx например. Всё же Texinfo/Sphinx это не
general purpose средства, а для определённых задач. Но это всё равно
перекрывается простотой, гибкостью, удобством работы с ним. Вообще
Texinfo создавался сразу же и для того, чтобы из доки можно было сделать
.tex файлы и сразу из них отрендерить печатный вариант (книгу). Это
никогда не проверял как работает и априори полагаю что с кириллицей
возникнут проблемы. Sphinx тоже умеет генерировать .tex (LaTeX? не помню
уже), который с кириллицей не работал из коробки. .info файлы вроде
Sphinx-ом плохо генерировались.

А ещё, что скорее является anti-feature, но Texinfo это единственное
через что я смог сделать максимально работоспособный Word-compatible
выхлоп. Texinfo создаёт Docbook, который можно открыть в LibreOffice и
он его отлично отрендерит, даже со всеми таблицами и *почти* не
потерянным форматированием (насколько помню, только заголовки почему-то
были не нужного размера -- но они были всё же заголовками). Сделать
что-то из Sphinx-а, чтобы было так же похоже на ожидание, что через
*Office-ы можно было бы сконвертировать -- не выходило.

Когда я восхищаюсь огромному количеству документации в man-ах
OpenBSD/FreeBSD, то я восхищаюсь и аплодирую именно наличию
документацию, а не её формату. Но GNU выбор Texinfo/Info я считаю лучшим
что есть.

Почему федеративные системы не взлетают?

https://beldmit.livejournal.com/628814.html?nojs=1
Человек пишет что с 1994-го года был и в Фидо и где только не был и
всегда существовали централизованные системы, которые на порядки были
популярнее федеративных (автор пишет про распределённые, но я всё же
разделяю их с федеративными). И с причиной их популярности я полностью
согласен:

    Причина провала скорее всего предельно проста. Порог вхождения в
    централизованные системы низок, потому что коммерсанты это в
    состоянии сделать.

Говорит что взлетели только электронная почта ("которая сейчас скорее
умирает, а коммерчески безнадёжна уже давно") и BitTorrent. В целом
согласен. Я бы ещё добавил news/NNTP (которые умерли). Ну и мне не
понятно в каком месте email умирает. Чтобы умереть -- нужно чтобы
появилась замена хоть какая-то. Для email-а её нет даже отдалённо.

Я бы ещё наверное добавил всё же RSS/Atom с домашними страничками и
блогами. У меня уже более 300+ feed-ов, и их количество только растёт,
ведь каждый год всё больше и больше людей слезает с соцсетей.

netpbm формат и генерирование картинки в 5LoC bash

https://www.vidarholen.net/contents/blog/?p=904
Я давний "поклонник" netpbm утилит и форматов. Мне кажется что уже
наверное лет 15 я для работы с изображениями только его и использую.

    #!/bin/bash
    exec > my_image.ppm    # All echo statements will write here
    echo "P3 250 250 255"  # magic, width, height, max component value
    for ((y=0; y<250; y++)) {
      for ((x=0; x<250; x++)) {
        echo "$((x^y)) $((x^y)) $((x|y))" # r, g, b
      }
    }

netpbm это набор утилит для работы с PNM файлами. PNM-ы бывают: PBM
(bitmap, монохромный), PGM (graymap, серый), PPM (pixmap, цветной), PAM
(цветной, ещё и с альфа-каналом). Каждый из них может быть представлен
в ASCII текстовом формате (как в примере выше), где задаётся формат,
размеры изображения и глубина на канал. Или в аналогичном, но бинарном
формате. Например когда я недавно занимался сканированием фотографий, то
мне надо было и обрезать, и scale-ить, и менять глубину цвета, и кучу
других подобных вещей. Изображение перегоняется в PNM, дальше через
pipe-ы применяются фильтры, дальше PNM преобразуется в нужный формат
(JPEG2000, WebP, и т.д.).

Ещё вот позже появился suckless проект: https://tools.suckless.org/farbfeld/
где формат тоже предельно прост:

    8      -- "farbfeld" magic value
    4      -- 32-Bit BE unsigned integer (width)
    4      -- 32-Bit BE unsigned integer (height)
    [2222] -- 4x16-Bit BE unsigned integers [RGBA] / pixel, row-major

В принципе мне он нравится больше, так как наборы PNM форматов это
только ведь об эффективности. Хотя... в том числе и про удобство для
генерирования/обработки наверное тоже, но преобразовать в RGBA и обратно
совсем не проблема. Из коробки farbfeld, конечно же, имеет и конвертеры
в PAM/PPM.

URL в C коде

https://susam.in/blog/urls-in-c/
https://susam.in/ -- абсолютно валидная строка в C, так как "http:" это
label, а "//" это начало комментария.

Закат useability

https://datagubbe.se/decusab/
Понравилась статья с примерами современных графических интерфейсов.
Аналогичное касается ведь и web-страничек. Почему у меня прям сразу же
рвотные позывы когда кто-либо предлагает через страничку в броузере
юзать какой-нибудь Mattermost? Да потому что рехнёшься пытаться понять
где там вообще элементы управления, не говоря об их использовании. Один
только факт когда убираются/исчезают полосы прокрутки... сколько же
ненависти это вызывает и непонимания как это используют, ведь автор
подобного интерфейса явно садист.

Впервые заюзал redo-stamp, хоть что-то кроме redo-ifchange

Хочется вшивать версию библиотеки в исходный код/документацию. Для
получения версии библиотеки я использую информацию о текущем git
коммите. Если сделать цель типа:

    $ cat VERSION.do
    git describe --tags @ 2>/dev/null || git describe --always @

то она конечно сработает, но только один раз, так как у неё нет
зависимостей. Делать зависимости на .git/* объекты -- ну как-то не
хорошо, но (не проверял) наверное что-то типа (само собой, вместо cat,
надо использовать git команды для получения соответствующей информации):

    redo-ifchange .git/`cat .git/HEAD | cut -d\  -f2`

Хочется сделать зависимость от вывода команды -- именно от вывода, а не
факта изменения файла с содержимым git-describe. apenwarr/redo, как и
redo-c смотрят на метаинформацию файла, а не на хэш от содержимого.
Поэтому задачу, без постоянной пересборки всего что зависит от версии,
не знаю как выполнить через redo-ifchange/ifcreate.

Но многие redo реализации имеют redo-stamp команду, которая позволяет в
зависимости добавить хэш от произвольных входных данных. Цель будет
выполняться/проверяться всегда, но считаться "обновлённой" только если
хэш поменяется:

    $ cat VERSION.do
    [ -n "$VERSION" ] || VERSION=`git describe --tags @ 2>/dev/null || git describe --always @`
    echo $VERSION > $3
    redo-always
    redo-stamp < $3

Работает на ура! При пересборке проекта цель VERSION высвечивается, но
если её содержимое не меняется, то и зависимости не пересобираются. А
чтобы оно работало с redo-c, в котором нет redo-stamp, то я решил просто
проверять наличие этой команды, но уже конечно без пересборки если
версия изменится.

    $ cat VERSION.do
    [ -n "$VERSION" ] || VERSION=`git describe --tags @ 2>/dev/null || git describe --always @`
    echo $VERSION > $3
    if command -v redo-stamp >/dev/null ; then
        redo-always
        redo-stamp < $3
    else
        echo No redo-stamp command found: VERSION is built only once >&2
    fi

Узнать размер файла в "Linux"

https://losst.ru/razmer-fajla-v-linux
Ох ох ох! Перемешаны намешаны ls/stat команды и du. Нельзя же так. du
показывает именно disk usage, который может *существенно* отличаться от
значения ls/stat из-за сжатия и sparse областей как минимум. Посмотрев
на du, может быть потом очень неприятно видеть что при копировании на
какой-нибудь FAT оно не уместится там.

Бойкотирование Wayland

https://www.opennet.ru/opennews/art.shtml?num=54022
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
https://refi64.com/posts/dont-boycott-wayland.html
Меня терзают смутные сомнения и воспоминания о том, что вот подобные
высказывания мы все где-то уже слышали, о том что всё ломается, все
заботятся только о GNOME, ничего не даёт действительно полезного и
нового:

   В сообщении говорится: "Wayland не решает никаких проблем, которые у
   меня есть, но ломает почти все, что мне нужно. И обычно оно остаётся
   сломанным, потому что связанные с Wayland люди, похоже, заботятся
   только о GNOME и отдаляют всех остальных в этом процессе. НЕ
   УСТАНАВЛИВАЙТЕ WAYLAND! Пусть Wayland не уничтожит все, чтобы потом
   другим людям не пришлось устранять ущерб, который он нанесёт. Или
   сделайте больше Red Hat/GNOME-специфичных компонентов (glib, Portals,
   Pipe wire) обязательными зависимостями!"

Ах да, всё это было уже про systemd :-)! Учитывая что творилось с
systemd и что всё завязывалось на GNOME -- поверю высказыванию Симона
Петера, ибо сложно поверить что GNOME-people могут достойно делать
достойные замены. Список того, что ломает Wayland, очень похож на
аналогичные списки того что творил/ломал systemd. История повторяется.

Хотя лично у меня особо никакого мнения нет. Я и X.org плохо знаю. Читал
про то, как работа с графикой идёт в Plan 9 -- вот это мне однозначно
нравилось своей незатейливой простотой. X.org выглядит монстром. Просто
Mir/Wayland не знаю. Если это сильно более простые штуки чем X-ы, то
одобряю. Но... боюсь что в "простоту" могут вкладывать совершенно другие
значения чем я представляю. Ведь кто-то умудряется говорить и про
простоту systemd, его модульность и прочее прочее. Но всё говорит про
то, что Wayland это классический продукт GNOME/Freedesktop.org, поэтому
мало чего хорошего (для Unix-like) системы ждать не приходится, ведь под
ними и DBus, PulseAudio, XDG_* -- то, чей подход в принципе мне чужд.
Хотя что-то из их https://www.freedesktop.org/wiki/Software/ использую.

Может ли время на компьютере идти вспять?

Вот только что:

    ~|0|0-% fdm -a XXX fetch
    stcnet: 0 messages processed in -0.252 seconds

проверило сообщения ещё до вызова команды.

Использую очередную библиотеку от DJB: libtai

https://cr.yp.to/libtai.html
https://cr.yp.to/proto/tai64.txt
https://cr.yp.to/y2k.html
https://cr.yp.to/proto/utctai.html
В одной C-шной библиотеке сделал возможность выбора между обычным POSIX
gettimeofday+localtime и libtai. libtai работает значительно быстрее
(ну, как минимум, потому что сама библиотека не занимается
форматированием вывода для человека), имеет простой интерфейс, всё что
нужно для сериализации/десериализации. Хочется наносекунды, хочется
аттосекунды -- отрезай сколько надо байт, делов то! А преобразовать в
человекочитаемый формат можно tai64nlocal утилитой из состава
daemontools, но уже асинхронно по времени.

Конец жёсткой воде

Все годы что я живу в своей квартире -- вода была очень жёсткой. Пару
раз вскипятишь воду в чайнике -- покроется дно известью, даже после
фильтра настольного. Но последние несколько месяцев дно чайника, как и
известковые разводы в ванне исчезли напрочь! Явно в доме что-то
установили/поменяли. Здорово стало, хотя меня особо и не напрягало.

Широковещательные поэмы от ISP и bad.horse

https://gist.github.com/riobard/c7eb86aa3586c36ffaa75f7be3b57d66
Китайский модем каждые десять секунд широковещательно рассылает поэму. А
по ссылкам есть ещё bad.horse, который если traceroute-нуть, то у меня
получится:

    [...]
    10  * * *
    11  * * bad.horse (162.252.205.131)  156.364 ms
    12  bad.horse (162.252.205.132)  161.045 ms  161.285 ms  158.751 ms
    13  bad.horse (162.252.205.133)  164.067 ms  165.241 ms  165.877 ms
    14  he.rides.across.the.nation (162.252.205.134)  169.005 ms  170.896 ms  171.162 ms
    15  the.thoroughbred.of.sin (162.252.205.135)  176.320 ms  176.025 ms  175.966 ms
    16  he.got.the.application (162.252.205.136)  179.019 ms  180.848 ms  179.054 ms
    17  that.you.just.sent.in (162.252.205.137)  186.400 ms  185.948 ms  184.481 ms
    18  it.needs.evaluation (162.252.205.138)  191.208 ms  191.067 ms  189.537 ms
    19  so.let.the.games.begin (162.252.205.139)  193.995 ms  193.859 ms  196.915 ms
    20  a.heinous.crime (162.252.205.140)  201.016 ms  201.346 ms  202.818 ms
    21  a.show.of.force (162.252.205.141)  205.960 ms  203.942 ms  204.386 ms
    22  a.murder.would.be.nice.of.course (162.252.205.142)  209.347 ms  210.882 ms  209.746 ms
    23  bad.horse (162.252.205.143)  214.974 ms  214.106 ms  214.396 ms
    24  bad.horse (162.252.205.144)  221.163 ms  219.148 ms  217.232 ms
    25  bad.horse (162.252.205.145)  225.919 ms  224.980 ms  226.189 ms
    26  he-s.bad (162.252.205.146)  231.045 ms  229.682 ms  230.705 ms
    27  the.evil.league.of.evil (162.252.205.147)  236.238 ms  236.093 ms  234.376 ms
    28  is.watching.so.beware (162.252.205.148)  239.283 ms  238.992 ms  238.420 ms
    29  the.grade.that.you.receive (162.252.205.149)  246.061 ms  246.389 ms  246.176 ms
    30  will.be.your.last.we.swear (162.252.205.150)  249.103 ms  249.161 ms  248.959 ms
    31  so.make.the.bad.horse.gleeful (162.252.205.151)  255.942 ms  256.241 ms  268.024 ms
    32  or.he-ll.make.you.his.mare (162.252.205.152)  261.295 ms  261.495 ms  261.173 ms
    33  o_o (162.252.205.153)  268.452 ms  266.378 ms  264.068 ms
    34  you-re.saddled.up (162.252.205.154)  271.004 ms  268.978 ms  270.934 ms
    35  there-s.no.recourse (162.252.205.155)  276.492 ms  274.559 ms  274.304 ms
    36  it-s.hi-ho.silver (162.252.205.156)  280.985 ms  279.162 ms  279.430 ms
    37  signed.bad.horse (162.252.205.157)  279.259 ms  278.678 ms  282.138 ms

Chrome собирается сделать свою собственную БД CA

https://www.opennet.ru/opennews/art.shtml?num=54008
Честно говоря, я думал что там уже давно оно имеется своё, как и Firefox.
Понравился комментарий что теперь чтобы добавить сертификат предприятия
(ну или там свой личный), то:

    * хранилище ОС;
    * хранилище мозиллы;
    * хранилище хрома;
    * хранилище питона (certifi);
    * хранилище java (keystore);

Броузеры то теперь же ещё и за DNS-ом сами начали следить. От ОС скоро
совсем почти никаких функций не будут использовать.

Как аниме создало и убило киберпанк

https://www.youtube.com/watch?v=-wmxo9zrXy0
История аниме и киберпанк жанра. Киберпанк жанр я люблю, но чисто
эстетически, а не потому что считаю и хочу чтобы всё везде было в цифре,
на каждом шагу были бы технологии и тому прочее. Сейчас в аниме
киберпанк умер и заменён на то, что люди наоборот отходят от всех этих
технологий. Из всего что в фильме перечисляется, я смотрел только
"Эксперименты Лейн" да "Ghost in the shell". Ergo Proxy название слышал,
но всех остальных -- вообще нет. В общем интересная передача, лично для
меня, о чём то неведомом.

Открытием было то, что Уильям Гиббсон написал Нейромантика после
"Бегущего по лезвию"! Что в общем-то очевидно если посмотреть на года,
но как-то не задумывался.

Indikom работает ощутимо субъективно лучше

С новым провайдером (cb6bff728abd8e296dd4d10648c3a2b31b7c8343) у меня на
глаз значительно лучше стали работать торренты на раздачу. С Ростелекомом
то они работали, но через какое-то время seeding затухал. Не прекращался,
но опускался до 1-2 MBps. Перезапускаешь клиент -- вновь начинает на 5-6
MBps. С новым же ISP у меня регулярно и все 100 Mbps на выход забиты.
Может совпадения. Я запросто мог бы и грешить на aria2 клиент -- ну мало
ли чего в нём. Хотя ещё есть мысли что может быть MTU в 1500 байт,
вместо 1480 из-за PPPoE играют роль? Я у себя firewall-ом режу все
фрагментированные пакеты, ибо нефиг -- PMTUD должен работать. А если кто
блокирует ICMP -- ну и фиг с ним, у него сломанная и неработающая связь
значит. Может сейчас я просто могу достучаться до людей с неработающим PMTUD?

Джон Ромеро подписал коробку с Doom 3

https://www.doomworld.com/forum/topic/109795-john-romeros-reaction-to-signing-a-doom-3-box-is-priceless/
"Я не делал этого..."

Журнал Downgrade

http://dgmag.in/
http://www.old-hard.ru/
Когда-то был (есть?) журнал Upgrade. А тут вот есть журнал Downgrade.
Много всяких интересных коротких статей уже нашёл в нём, поностальгировать.
А ещё old-hard.ru с трушным DOS-like дизайном!

Acer Veriton FP

http://old-stuff.ru/ACER-Veriton-FP/
https://www.yaplakal.com/forum2/topic1376143.html
Я давно уже хотел вспомнить и найти один моноблок который мне люто
понравился. Давным давно, в конце в 90-х годов, в каком-то журнале в
новостях я увидел фотографию моноблока, которую не могу забыть и по
сей день. Вроде бы ничего особого -- простота и ничего лишнего, но
видимо это мне и запомнилось. В голове этот моноблок всегда рядом с
какими-нибудь Sun и SGI корпусами рядом стоит, как эталон дизайна
который мне нравится. Но... я совершенно не мог найти и вспомнить
хоть что-либо по нему. А сегодня совершенно чисто случайно увидел
таки! Помню что в журнале на нём в качестве benchmark-а запускали
Daikatana.

Black Jack Smokey BBQ соус

Появился у меня тут сабжевый соус для мяса. Я совершенно не гурман, но
котлеты с этим соусом просто божественны!

Как понимая работу TCP, можно убрать дикие задержки на сотни мс

https://jvns.ca/blog/2015/11/21/why-you-should-understand-a-little-about-tcp/
Ruby Net::HTTP посылает заголовок HTTP запроса в одном пакете, а тело в
следующем, плюс не выставляет TCP_NODELAY. А HAProxy, более того, ещё
делает и delayed TCP acknowledgement. Вот так вот можно получить
огромные задержки при HTTP запросе.

RocknMob Moscow -- Metallica "Sad But True"

https://www.youtube.com/watch?v=FmMo9CNYnm4
Даже не слышал о таких мероприятиях. Во там круто то!

С этим карантином и отсутствием концертов, я как никогда понял что
*только* на них я чувствую себя расслабленным и в своей тарелке, на
одной волне с остальными. Дай мне сейчас выбор оказаться в постели с
девушкой или пойти на трушный метал концерт... даже не знаю что и
выбрать, не лёгкий вопрос. Да и мой первый поцелуй в жизни произошёл
именно на метал концерте.

История BSD и как я засветился в видеоролике

https://youtu.be/CMfveo_I0YI
В комментариях к новости на OpenNet увидел ссылку на получасовое видео
про историю BSD систем. Чуть не упал со стула, внезапно увидев старую
фотографию своего домашнего рабочего места на 18:55! Но и без этого,
рассказ достаточно глубокий и содержащий кучу роликов и фотографий!

Локальный unbound для особых DNS зон

На работе многое стало работать через DNS доступный только изнутри через
VPN. Использовать его для всех запросов я по понятным причинам не хочу.
То есть, для одних зон надо использовать один DNS resolver, а для
остальных -- свой локальный. Знаю что это можно сделать unbound-ом,
поэтому и заюзал его:

    $ cat unbound.conf
    server:
            verbosity: 1
            do-daemonize: no
            interface: ::1
            interface: 127.0.0.1

    forward-zone:
            name: "work.domain"
            forward-addr: WORK-DNS-ADDR

    forward-zone:
            name: "."
            forward-addr: 2001:470:20fb:1::1

Очень просто и незатейливо получается.

Снова про цвета в фильмах

https://habr.com/ru/post/525252/
В догонку к b41b585f902490ba9a180e3530f075cb8f256381 вышла ещё одна
статья, в противовес. Очень понравился комментарий, ибо забавно отражает
реальность (всё так и есть!):

    * Режиссёр и/или сценарист: придумывают уникальную гамму,
      соответствующую атмосфере фильма
    * Художник: Рисует концепты, предлагает их режиссёру
    * Куча народу: делает тестовые снимки и съёмки
    * Команда, ответственная за реквизит: подбирает и создаёт декорации и
      костюмы, чтобы они не сильно выбивались из общей палитры после
      постпроцессинга
    * Команда VFX: пишут сложные фильтры, настраивают их для каждой снятой
      сцены по отдельности
    ...
    * Программист: Тенденция к обеднению цветов!
    ...
    * Bonus track: среднестатистический российский зритель смотрит всё это
      на пережатой вхлам пиратке, с разрешением из середины 2000-х на
      экранчике китайского телефона. Или на мониторе/телевизоре с
      вырвиглазными «улучшайзерами»

Очень часто там упоминают фильм Амели. Незабываемый своими красками!
Хотя, по идее, он тоже не богат цветами, просто они там более тёплые что ли.

OpenVPN с ChaCha20-Poly1305 и IPv6

https://www.opennet.ru/opennews/art.shtml?num=53981
Сам я OpenVPN не использую (ну кроме доступа по этому архаичному
рудименту до работы) и вообще сторонюсь его. Но удивляет их неспешность
добавления ChaCha20-Poly1305, и удручает то, что прежде, судя по
новости, без IPv4 туннель всё равно нельзя было юзать. Какое же у них
всё древнее!

FreeBSD в jail может запускать Linux

https://www.freebsd.org/releases/12.2R/relnotes.html
https://forums.freebsd.org/threads/setting-up-a-debian-linux-jail-on-freebsd.68434/
Судя по форуму, похоже это и раньше вполне себе было возможно. Сам не
пробовал, да и наверное нафиг мне надо, но выглядит интересно. FreeBSD
уже давно по сути позволяет запускать больше софта чем GNU/Linux, ибо и
свой и Linux-овый позволяет запускать. Помню что Linux-версия Quake3 на
FreeBSD шла быстрее на 10% (по FPS-ам).

Facebook цензура по музыкальным вкусам

http://www.hitkiller.com/satanath-records-za-publikaciyu-pesni-burzum-udalili-stranicu-nashego-lejbla.html
Упомянул Burzum? Бан тебе в жбан! Мне кажется уже и недели не проходит о
новостях о полнейшей цензуре в этих централизованных соцсетях на всё что
ни попади. И ведь верно заметили в комментариях что политика политикой
(взгляды), но Burzum в музыку её не тащил.

Интереснейшее видео про растопку паровоза в мороз

https://m.youtube.com/watch?v=UXR9CWzR7Yk
Я только мельком минуту суммарно посмотрел/послушал, но точно хочется
полностью заценить!

Дизайн ноутбучной клавиатуры

https://mdex-nn.ru/page/ugadaete-model-noutbuka.html
И у них в рекламе ещё и говорится про "великолепную эргономику"!
Bullshitest marketing во всей своей красе, переплюнули Apple.
Вот искренне любопытно чем же думают эти дизайнеры, которые сами
небось даже не пробовали поработать за сие творением.

Посмотрел "Борат 2"

https://ru.wikipedia.org/wiki/%D0%91%D0%BE%D1%80%D0%B0%D1%82_2
В целом фильм понравился. Было 2-3 момента с совсем сортирным юмором, но
многое другое меня очень и очень позабавило! Хотя с одной стороны
скользких тем полно: антисемитизма, расизма и... какое там слово
используется когда женщинам указывают своё место? Но с другой: наоборот
показывают (даже посвящают фильм одной из женщин пережившей холокост)
глупость всего этого, что все люди -- люди... ну возможно кроме
демократов. В отличии от прошлого фильма, тут сплошной политический
контекст. Но, как я вижу, фильм показывает насколько плохи политика,
промыв мозгов СМИ, антисемитизм и прочее подобное. Главное это семья,
дружба и подобные человеческие ценности. Саша Барон Коэн заметно
постарел. Понятно почему Трамп так невзлюбил этот фильм. А ещё в фильме
засветился Том Хэнкс и музыка Little Big.
https://www.vulture.com/article/whos-who-in-borat-2-a-guide-to-every-notable-cameo.html
а тут много информации о том, кто есть кто и как. Где вот пара сортирных
моментов особо не оставила плохого в памяти участвовавших там людей. В
общем, мне нравится, хотя на половине или даже до 2/3 фильма не мог
понять. Но первая часть, мне кажется, лучше -- там больше житейских тем
затрагивается, нет политики, меньше сортирного юмора (хотя и тут его
почти нет, в отличии от кучи голливудщины где его 100% на весь фильм),
ну и наверное потому что оно впечатляет как первое подобное. Но я
остался доволен просмотром, очень!

Сыграл в настольную игру "Паранормальный детектив"

http://boardgamer.ru/paranormalnyj-detektiv-obzor-igry
Собрались играть вчетвером в неё. Впервые видим. Суть: кто-то умер, его
призрак (один из игроков) жив и может общаться через разные
"паранормальные" средства связи с группой детективов. Они (остальные
игроки) могут задавать вопросы чтобы воссоздать картину произошедшего.
И прилагается множество историй. Историю знает только призрак. Исходные
данные для детективов только: где и какие повреждения на человеке, ну и
например голый ли он, плюс пол. Не знаю как у других, но у меня точно
были сомнения вообще в возможности на основе этих данных и ответов
призрака (ответы в виде карт таро (символы), в виде чего-то сделанного
верёвочками, или указателем на всякие холодно/горячо, и т.д. -- нигде
нет возможности просто словами сказать) можно ли воссоздать картину.
Сыграли всего один раз, но почти почти полностью приблизились/воссоздали
историю. История такая:

    Мужчина с любовницей в номере отеля. Он -- лунатик, но любовница
    этого не знает. После выпитого и проведённого в постели времени и
    жаркой погоды ночью стало жарко и любовница открыла дверь на балкон.
    А мужчина лунатик встал, вышел туда, ну и перекувыркнулся через
    перила, разбившись о скалы.

Наша окончательная версия (играли сообща) отличилась только тем, что они
поссорились между собой и, зная что он лунатик, любовница его
направила/вывела на балкон. Вообще это конечно важнейший вопрос:
умышленно ли она его грохнула так хитро или это был такой несчастный
случай, но уж мелочи. И после такого близкого совпадения с историей,
игра однозначно сильно понравилась! А призраку, с одной стороны, и
сложно объяснять это всё через каналы связи типа пальцем на спине
нарисовать, а с другой и очень забавно слушать куда заходят
предположения детективов.

Дефицит цветов в современных фильмах

https://habr.com/ru/post/524978/
https://habr.com/ru/post/366071/
После подобных статей -- невозможно не замечать бледность оранжево-синих
фильмов. Никогда об этом самостоятельно не задумывался, но замечал что
всякие современные голливудские фильмы уж очень какие-то не сочные и не
яркие. Вроде картинка суперская, но какая-то холодная. Когда про себя
вспоминаешь фильмы, то, действительно, Форрест Гамп это широчайшая
палитра в голове! Но и удивляться бледности в Джокер не стоит -- мы же
видим рассказ про больного на голову человека, так что можно считать что
мы через его призму видим мир. То что куча зелёного в Матрице -- ну тоже
в тему, тоже трушно. Трансформеров я когда-то смотрел и мне реально
запомнилось безжизненность цветов! А больше всего впечатляют плакаты,
прям под один шаблон все сделанные:
https://habrastorage.org/getpro/geektimes/comment_images/458/cc8/80b/458cc880bfd0382211ea6cd517b6327e.jpg
https://pbs.twimg.com/media/DgscG-sXUAElnJQ?format=jpg&name=small
Но всё же далеко не все фильмы делаются такими, не всё так плачевно. Это
как война громкости: mainstream всякий, как голливуд, не брезгует
дичайшей компрессии, но есть и полно "не громких" альбомов.