Sergey Matveev [Thu, 16 Dec 2021 18:57:03 +0000 (21:57 +0300)]
Rust -- must die
http://rustmustdie.com/
Сайт созданный по аналогии с http://cmustdie.com/.
Даже моих небольших практических знаний по Rust достаточно чтобы
чуть-чуть усомнится в некоторых высказываний, но в целом я согласен
что Rust это та ещё жопа для написания. И на работе коллега подтвердил
что безопасное написание очень часто означает кучу копирования -- значит
медленно.
Sergey Matveev [Thu, 16 Dec 2021 17:43:49 +0000 (20:43 +0300)]
Прочитал "Дневник" Чака Паланика
https://ru.wikipedia.org/wiki/%D0%94%D0%BD%D0%B5%D0%B2%D0%BD%D0%B8%D0%BA_(%D1%80%D0%BE%D0%BC%D0%B0%D0%BD)
Ни с чем прежде у него не знаком (ну кроме фильма "Бойцовский клуб",
хотя чёрт его знает насколько близок он к книге). Очень необычно, очень
детально. Первая половина книги... по мне так скучновата, но возможно
потому что не понятно к чему это всё говорится и к чему всё ведётся. Но
под конец начинается стрёмная кровавая движуха. А это уже понравилось.
Однозначно что-нибудь ещё бы надо у него прочитать.
Sergey Matveev [Thu, 16 Dec 2021 14:10:00 +0000 (17:10 +0300)]
Конвертирование PDF для recoll и определения страниц
http://www.git.stargrave.org/?p=dotfiles.git;a=blob;f=recoll/bin/pdftotext.sh;h=1775278068da0b9d1b844a82888b8b1a0b8088f9;hb=0232bed604be77802bc76422627be707ac2c8838
Для конвертирования PDF в текст я использую mutool convert -F text
утилиту. Но вот беда -- в её выводе нет информации о страницах. recoll
из коробки понимает разделение на страницы если есть "^L" символ. Пока
сделал хак в виде отдельного mutool info вызова для получения количества
страниц и дальше для каждой страницы вызов convert-а, с выводом "^L"
символа. Существенно медленнее, но пока меня не сильно смущает.
Sergey Matveev [Thu, 16 Dec 2021 11:15:26 +0000 (14:15 +0300)]
Снова tar c|tar x vs cp
В dd558b2a665788dfa4a15024397060615bd86d98 уже упоминал про "cp -a": без
этой опции cp будет "терять" всё на свете о файле, кроме его содержимого
(например mtime (863f4e1fadabacdb2de4d6493ba96880e20eb0e8)). А сегодня
обнаружил (это не было новостью -- просто не задумывался прежде) что
сохранить жёсткие ссылки с ним нельзя. Ни в коем случае для серьёзного
backup-а cp использовать нельзя.
И опять же спасает например tar/cpio/pax, которые без дополнительных
опций будут сохранять информацию о таких ссылках в архиве и при
разархивировании воссоздавать их.
Вот только с tar-ом обнаружил неприятную особенность: в нём можно
указать ("T") список путей которые надо добавить в архив, но директории
в нём он рекурсивно добавляет в архив. Например:
find . -type d -mindepth 1 | tar cfT - - | ...
в архив не поместит только сами директории, но и их содержимое. В POSIX
tar команде ничего нет чтобы могло помочь. В GNU tar есть --no-recursion.
В BSD tar есть -n, --norecurse, --no-recursion. Портабельной опции для
find -d | tar нету.
cpio мог бы тут помочь. Но у самого cpio формата сильные ограничения
(например на размер файла). pax, с точки зрения POSIX, был бы тут
идеален и интерфейсом (копировать файлы можно без pipe-а вызывая pax -rw)
и форматом, но он из коробки нигде не присутствует. А если и имеется, то
зачастую не имеет поддержки pax формата.
Так какую же команду можно использовать для создания архива без
ограничений (типа размера), чтобы find-ом можно было только директории
предоставить например? Никакую :-). Не вижу тут решения. Всё не
портабельное или не присутствует гарантированно в ОС (pax). В FreeBSD
cpio команда то на самом деле использует libarchive и поэтому может
создавать pax-архивы. На практике для конкретных систем -- возможности
то имеются.
Sergey Matveev [Thu, 16 Dec 2021 10:30:07 +0000 (13:30 +0300)]
Такой разный код на Си для простой утилиты cat
https://github.com/0intro/plan9/blob/master/sys/src/cmd/cat.c
https://github.com/coreutils/coreutils/blob/master/src/cat.c
К вопросу о сравнении языков программирования: на одном и том же можно
кардинально сложно или просто писать.
Sergey Matveev [Wed, 15 Dec 2021 21:17:41 +0000 (00:17 +0300)]
rcl и несколько индексов
Сегодня я начал использовать recoll (bb337e0d83d3ef04c5ec966f090ade5a162e21a1)
и уже использую несколько индексов, чтобы контексты поиска разделить.
Отдельно RFC, отдельно man-ы и отдельно рабочая директория. И позволяет
распараллелить работу с ними и независимо переиндексировать, но главное
это позволяет разделить знания об особенностях индексирования по разным
директориям (ведь за это отвечают несколько файлов: recoll.conf и
mimeconf, как минимум).
Хочется уметь легко указывать по каким именно индексам я хочу искать. Не
руками же мне "-i ..." опции передавать. rcl теперь если видит что
первые аргументы к нему являются названиями директорий в ~/recoll, то
добавляет их в качестве дополнительного индекса. Теперь:
rcl http authorization -- ищет среди всяких рабочих PDF-ок
rcl man http authorization -- ищет ещё и среди man страниц
rcl rfc man http authorization -- будет ещё и в RFC смотреть
Сейчас заметил что с включённым abstract-ом поиск работает не стремглав.
Надо будет добавить так же просто опцию по отключению его вывода.
Sergey Matveev [Wed, 15 Dec 2021 21:14:38 +0000 (00:14 +0300)]
Мой zsh прогресс
Сейчас я с первого раза, не залезая в документацию, пишу уже вот такие
команды автоматом: vobs=(VTS*.VOB(on)) ; ffmpeg -i ${(j:|:)vobs[2,-1]} ...
Нужно взять все VTS*.VOB-ы отсортированные, без первого, соединить их
список через "|" ну и передать в ffmpeg (для кодирования с DVD). И нигде
не нужно париться с экранированием (хотя с файлами DVD даже под DOS не
было бы проблем). В прошлом году я бы возможно это ещё и не смог бы
синтерпретировать.
Sergey Matveev [Wed, 15 Dec 2021 19:38:19 +0000 (22:38 +0300)]
JFS2 в Linux пришёл из OS/2
https://en.wikipedia.org/wiki/JFS_(file_system)
Эта файловая система пришла в Linux, как оказалось, из OS/2.
Я не знал что и для последней то она была.
Sergey Matveev [Wed, 15 Dec 2021 13:45:28 +0000 (16:45 +0300)]
recoll показал на что способен
http://www.git.stargrave.org/?p=dotfiles.git;a=blob;f=recoll/bin/rcl
Вчера установил recoll (e18bf71655b8a564745dd4f307df4ce034996031), но
только сегодня вплотную с ним поигрался.
* первая задача: среди кучи всяких ужасных PDF-ок связанных с ТК26,
найти все где упоминается например "VKO". Они ужасно отформатированы,
многие ужасно сконвертированы из Word-а. Названия ни о чём не говорят
(идентификаторы рекомендации/стандарта). Многое разнесено и ссылается
друг на друга по куче этих стандартов. VKO находит идеально, без
проблем
* вторая задача искать не тривиальные AND-нутые фразы по RFC: даже
комментировать нечего -- всё отрабатывает без проблем. Хотя, учитывая
что там и .txt имеются -- это можно и grep-ом делать, просто не так
быстро
* третья задача, после которой recoll у меня точно остаётся: замена
apropos. Работает ли вообще этот apropos? С одной стороны я до сих пор
продолжал иногда его вводить когда надо что-то найти в man-ах. Но у
меня стойкое ощущение что банальные вещи у меня и zsh completion
самописный находит прекрасно, а вот чуть более сложные apropos уже не
может. В итоге его запускаешь, но толку никакого. Беру проект на Си в
котором точно помню что есть FreeBSD-specific код, вижу в нём
упоминание PROC_TRACE_CTL_DISABLE. В какой man смотреть за его
описанием? apropos -- молчит. recoll показывает что в
/usr/share/man/man2/procctl.2.gz есть:
by PROC_TRACE_CTL...self. PROC_TRACE_CTL...2).
PROC_TRACE_CTL_DISABLE...as PROC_TRACE_CTL...of PROC_TRACE_CTL...
Я правда написал обёртку над recollq, чтобы она поприятнее для глаз
выводила ABSTRACT (с ним как-то полегче понимать о чём вообще документ
найденный) и в которой ещё и подсветка применяется supercat-а
(d85140c8be0146ddc09312cd4470c1aec828b894):
Sergey Matveev [Wed, 15 Dec 2021 11:19:33 +0000 (14:19 +0300)]
Разукрашивание вывода по регулярным выражениям
http://supercat.nosredna.net/index.html
http://kassiopeia.juls.savba.sk/~garabik/software/grc.html
http://prysm.sourceforge.net/
Куча всяких разукрашивателей, но написаны на Python -- даже пробовать не
хочется это всё уже. Благо, supercat написан на чистом Си, без проблем
собирается и очень прост в использовании: указываем цвет, регулярку и
получаем разукрашенный вывод. Помню что мне не раз подобное требовалось,
но отдельных утилит для этой задачи не искал.
Sergey Matveev [Tue, 14 Dec 2021 20:15:00 +0000 (23:15 +0300)]
Пробую начинать использовать recoll
https://www.lesbonscomptes.com/recoll/
http://www.git.stargrave.org/?p=dotfiles.git;a=commitdiff;h=cbccb5bd5071445788464f183f563cc6a79218c1
Коллега на работе в очередной раз поднял вопрос и напомнил о теме
индексации и поиска информации в документах. По сути я удовлетворяюсь
grep-ом в преобладающем большинстве случаев. Но к сожалению имеются
PDF-ки, как минимум. Да и HTML-ки не всегда удобны для grep-а.
Нашёл recoll программу. Xapian движок -- точно такой же как и в
mu-helper используется (его я использую вместе с Mutt-ом), поэтому язык
запросов мне уже знаком. Есть не только GUI клиенты, но и recallq CLI.
Так как pdftotext у меня нет, ибо не хочу я ставить громоздкий poppler,
ибо я поклонник MuPDF (f5ac4628c014cc4c9fb43f7f15c6bd5cc211d24d), то
пришлось обёртку над mutool писать и переопределять вызов "декодера" PDF
файлов. Делается легко. Работает отлично. HTML-ки, PDF-ки, всякие
случайно попавшиеся под руку файлы словарей -- всё ест и по всему ищет.
С кириллицей не обнаружил проблем. Надо осваивать это всё, а то,
действительно, как в каменном веке перехожу в ~/doc, ~XXX/doc и grep-ом
ищу. Когда понимаю что что-то в PDF-ках, то бывало циклом прогоняю
pdftotext (ну точнее аналог), но это терпимо когда крайне редко делается.
Sergey Matveev [Tue, 14 Dec 2021 09:08:24 +0000 (12:08 +0300)]
Криптономикон
https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%BA%D0%BE%D0%BD
Порекомендовали тут книгу Нила Стивенсона "Криптономикон", потому что в
блоге про неё нет упоминаний. Но я её, конечно же, читал. Просто много
раньше создания блога. Самая шифропанковская среди всей литературы.
Unix-like системы, перехват ван Эйка, PGP, и приглашённый Брюс Шнайер
специально для этой книги создавший вполне себе серьёзный настоящий шифр
Пасьянс (http://www.cypherpunks.ru/Solitaire.html), использующий
игральные карты для "вычислений". Оказалось что у Нила Стивенсона всего
две книги прочитал: эту и Семиевие (ad1e55aca359fd071aea257aaee50fa59d5b3d3e)
Обе круты.
Ещё в Криптономиконе очень нравился вот этот абзац:
В комнате несколько десятков живых тел, каждое -- большой мешок с
потрохами и жидкостями под таким напором, что проткни -- брызнет на
несколько метров. Каждое выстроено на арматуре из двухсот шести
костей, соединенных исключительно ненадежными суставами, которые
обычно скрипят, хрустят и щелкают. Вся конструкция обтянута мясом,
раздута пульсирующими воздушными мешками, пронизана гордиевой
канализацией, в которой булькают кислота и сжатый газ, насыщенные
ферментами и растворителями. Их вырабатывают вонючие куски
генетически запрограммированного мяса, расположенные по всей длине
гибких шлангов. Куски пищи конвульсивно проталкиваются по склизкому
лабиринту, разлагаясь на газ, жидкость и твердое вещество, которые
надо регулярно выводить наружу, иначе человек отравится и умрет.
Сферические, наполненные гелем емкости поворачиваются в слизистых
шарнирах. Бесчисленные фаланги ресничек отбиваются от посторонних
частиц, закукливая их в клей, чтобы потом выбросить. В каждом теле
мышца гонит нескончаемый, циркулирующий поток сжатой жижи. И,
несмотря на все это, пока султан говорит, тела не издают ни одного
звука. Такое можно объяснить лишь властью мозга над телом и, в свою
очередь, властью культурного воспитания над мозгом.
Sergey Matveev [Tue, 14 Dec 2021 05:24:49 +0000 (08:24 +0300)]
Киану Ривз о NFT
https://habr.com/ru/news/t/595349/
Достойный ответ и смех касательно вообще всей темы блокчейна :-)
Уважуха Киану! Хотя, конечно же, понимаю что он вряд ли не понимает что
это всё такое и как работает. Но сам токен скопировать можно -- он прав,
это же набор битиков.
Sergey Matveev [Sun, 12 Dec 2021 07:37:53 +0000 (10:37 +0300)]
Back to BBS
https://alsgeeklab.com/latest-posts/
Масса видео в нескольких частях про BBS-ки. Можно сказать что это некое
дополнение к "BBS: Documentary". Но тут не только про историю, но и про
современность.
Sergey Matveev [Sat, 11 Dec 2021 22:11:14 +0000 (01:11 +0300)]
Суд на моей стороне
Как говорят, не прошло и пол года (на самом деле прошло даже больше), но
суд полностью отказал мошенникам из "Серверного мира" (сейчас это уже
другая компания), которые пытались отобрать у меня деньги
(7f3bd94f2589463beda0c864ef19c9744c488bfa). На кой чёрт всё это затевали
ни я, ни адвокат не знаем.
Sergey Matveev [Sat, 11 Dec 2021 21:13:22 +0000 (00:13 +0300)]
Слепая печать != печать в темноте
Я уже со времён института, курса 3-4-го печатаю в слепую: мне не нужны
надписи на клавиатуре. Внезапно узнал об этом, когда пришёл в институт с
shiny новым китайским Lemote YeeLoong ноутбуком, на котором конечно же
не было никакой кириллицы. И мне ребята заметили это, тогда как я
совершенно не задумывался и не обращал внимание на это. Сейчас у меня и
дома и на работе клава полностью без надписей -- сплошная чернота. Ни
разу не заметил чтобы это что либо затруднило или помешало бы.
Но вот только это не означает что я могу работать в темноте. Во-первых,
есть ровно один момент когда я смотрю на клаву: во время набора
парольных фраз. Видимо, мой мозг не может совершенно без обратной связи
(ведь при наборе пароля ничего и не показывается на экране), поэтому мне
нужно смотреть на клаву. Во-вторых, даже вне паролей я не могу набирать
ничего (эффективно) если не вижу боковым зрением эту самую клавиатуру.
Ниже очков я вижу только жутко размытую верхнюю часть клавиатуры
(примерно где она расположена) и светлые пятна моих рук -- но этого
достаточно, видимо, чтобы корректно их позиционировать подсознательно.
Конечно я могу в полной темноте находить пупырышки над "f" и "j", но
визуальный feedback всё равно нужен, хотя на саму клаву явно я не
смотрю, только "боковое" зрение участвует.
Sergey Matveev [Sat, 11 Dec 2021 21:07:35 +0000 (00:07 +0300)]
Снова ненависть к GnuPG, ну почти...
И я думал что напоролся на какой-то баг! Хочу удалить ключ, делая
"gpg --delete-key", он спрашивает "точно ли хочу вот этот удалить?",
отвечаю "да", выходит и показывает приглашение командной строки. Бац,
снова вижу его в ключнице. Повторяю удаление -- всё равно не исчезает.
Грохаю dirmngr на всякий пожарный -- не помогает. Оказалось, что я всё
это время упорно нажимал "j" в качестве ответа на вопрос с "y/n". Под
моим "stargrave" пользователем у меня немецкая локаль, GnuPG это
прекрасно видит и я уже привык за много лет видеть от него немецкую
тарабарщину, на которую я отвечаю "ja"/"nein". А ключ я удалял под
другим пользователем, у которого английский по умолчанию, где "yes"/"no".
Начинаю понимать о чём ведут речь пользователи, считающие кучу свободного
ПО плохим UI/UX.
Sergey Matveev [Sat, 11 Dec 2021 20:59:14 +0000 (23:59 +0300)]
gpg --fetch-keys оказался с подвохом
Я конечно наслышан про сложность интерфейса GnuPG, но сейчас,
действительно, хочется сильно на него наругаться. В 8358c745a08e2f7632c3054b61641f40177e5fd8 я писал что узнал про
--fetch-keys опцию, думая что это замена "curl | gpg --import".
Так вот она, оказалось, игнорирует все подписи прилагающиеся к
ключу. Что сводит её полезность на нет. Жалко то конечно времени
потраченного на выяснение причин почему у меня нет подписи над
ключом одним, а у собеседника есть.
Sergey Matveev [Sat, 11 Dec 2021 18:10:59 +0000 (21:10 +0300)]
BSDs vs GNU/Linux производительность
https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=1
В рассылке обсуждают эту статью. Бегло посмотрел на результаты и бросается
в глаза разница в zstd компрессоре. Но в рассылке народ повторяет опыт и
на FreeBSD оно чуть ли не на 10% быстрее чем под GNU/Linux. Так что доверия
к этим benchmark-ам как-то не особо много. Ну или софт с дико разнящимися
флагами компилятора собран.
DragonFlyBSD много где выделяется -- а пилит его вроде чуть ли не один
человек толком. Что-то из него переносится неспешно в FreeBSD. Но
использовать эту ОС вряд ли стоит, ибо там даже полностью с потрохами
выпилен IPsec стэк.
Sergey Matveev [Sat, 11 Dec 2021 16:22:42 +0000 (19:22 +0300)]
www. домен
https://dropwww.com/why
https://www.yes-www.org/
Время от времени приходится смотреть в newsboat.err.log файлике что
тами из feed-ов поломалось. Кто-то меняет URL-ы, кто то добавляет
permanent redirect-ы, у кого-то вообще всё пропадает или оказывается на
другом домене.
Сегодня забавно было: кто-то добавил www. (и перенаправляет на него), а
кто-то наоборот удаляет. Есть даже целых два домена на тему "нафиг www."
и наоборот.
Лично я твёрдо за него. Аргумент "и так понятно по протоколу в URL-е что
будет на домене" не принимаю, ибо по HTTP/HTTPS сейчас чего только не
работает и не использует в качестве транспорта. И я против того чтобы по
умолчанию считать домен web-сайтом. Если это часть всемирной паутины, то
пускай так и говорит (www.). Убеждён что нужно физический смысл, суть
отображать в поддомене. Если написано "phlog.", то можно понять что
Gopher-протокол будет на нём обслуживаться. Люди же используют "mail.",
а не "smtp.". Есть у меня всякие "cpan.mirror.", "ctan.mirror." -- видно
что это зеркала. Где-то есть "www." приписка к ним, а где-то нет и там
обслуживается rsync протокол. "git." это для Git протокола, а "www.git."
для web-интерфейса к нему. Хотя, по моей логике, надо использовать
"vcs.", но смирюсь с этим, уж лень менять то, что во всех README
прописано.
Бывают пишут "blablabla.bla" -- учитывая что у тьмы компаний (не говоря
о людях) единственным идентификатором бывает адрес в соцсети
какой-нибудь, то чёрт поймёшь это домен (ведь доменов первого уровня
бывает тьма не связанных с политикой/географией и мало знакомых) WWW
сайта или это адрес в whatever-соцсети? Для Twitter вроде добавляют
at-символ впереди -- не спутаешь, но такое же не везде есть. Можно
добавить "http://", но "www." куда короче и сразу понятно что это. К
тому же, WWW может работать, как минимум, по двум протоколам в URL
(HTTP и HTTPS), не говоря про HTTP/2 и QUIC с HTTP/3.
https://vimeo.com/45041568
https://www.youtube.com/watch?v=grwmUTrO180
https://www.youtube.com/watch?v=nwW1d_KtkJw
Вот сколько не слушаю TesseracT альбомы, но ничего круче Concealing Fate
(несколько композиций под одним общим названием) они всё же не сделали.
Не, есть хиты запоминающиеся, типа Nascent или King-а с последнего
альбома (больше с него вообще ничего не помню), но Concealing Fate
хочется поставить всегда.
Sergey Matveev [Sat, 11 Dec 2021 12:11:35 +0000 (15:11 +0300)]
Зависание USB при пропаже USB аудио
https://forums.freebsd.org/threads/usb-dac-unplugged-hangs-up-rest-of-usb-devices.72061/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727
Давным давно у меня особенность (проблема) есть со звуком: если вывод
происходит на USB DAC, то mpv/mplayer держат открытым файл /dev/dspX.X
и когда USB вынимается, то драйвер в dmesg ругается:
[10409] pcm4: unregister: channel pcm4:virtual:dsp4.vp0 busy (pid 65234)
[10409] pcm4: Waiting for sound application to exit!
mpv при этом остаётся жив, и в целом всё что подключено к этому USB
контроллеру становится неработоспособным (спустя какое-то время чаще).
Было это на ноутбуках прежде, где клавиатура была PS/2 и я мог открыть
крышку и грохнуть программу (mpv). Но на NUC у меня только USB, который
может стать unresponsive для клавы и я ничего не могу сделать кроме
нажатия кнопки питания.
Проблема известна и предлагают: писать грамотно OSS-related софт, чтобы
обрабатывал ошибки и выходил. Не знаю относится ли это к mpv. Ну или
использовать virtual_oss. Я же решил просто насильно грохать софт
занимающий звуковые устройства для которых более нет аппаратуры:
/etc/devd/myaudio.conf:
attach 20 {
device-name "uaudio[0-9]";
match "vendor" "0x0b05";
match "product" "0x17f3";
action "/etc/devd/myaudio-bitperfect.sh $vendor $product";
};
notify 21 {
match "system" "USB";
match "subsystem" "INTERFACE";
match "type" "DETACH";
match "vendor" "0x0b05";
match "product" "0x17f3";
action "/etc/devd/myaudio-killer.sh";
};
/etc/devd/myaudio-killer.sh:
#!/bin/sh -x
export PATH=/usr/local/bin:$PATH
for uaudio in $(sysctl dev.uaudio | perl -F\\. -lane '/%pnpinfo:\s*$/ and print $F[2]') ; do
pcm=$(sysctl dev.pcm | perl -F\\. -lane "/%parent: uaudio${uaudio}$/ and print \$F[2]")
[ -n "$pcm" ] || continue
for dsp in /dev/dsp${pcm}* ; do
pid=$(fstat $dsp | perl -lane "next if /^USER/ ; print \$F[2]")
[ -z "$pid" ] || kill $pid
done
done
Такой геморрой потому что в devd приходит только событие о пропаже ugen
устройства, ничего не известно про аудио подсистему, которая не шлёт
ничего о том что у неё пропал родитель. В bugreport-ах видел есть
коммиты на эту тему -- возможно в новых версиях FreeBSD проблем нет.
Sergey Matveev [Sat, 11 Dec 2021 10:20:10 +0000 (13:20 +0300)]
История Xbox и место России в ИТ мире
https://www.youtube.com/watch?v=bXLr5HsLCbE
Понравилось вступление про купленность в России ИТ-сферы Microsoft-ом.
Ведь по сути нас в 90-е как страну третьего мира просто решили
заграбастать для vendor-lockin-а, который мы до сих пор расхлёбываем.
У нас до сих пор чрезвычайно DOS, IBM PC, Microsoft-центричные люди.
Винда всегда была популярна как игровая платформа.
Серьёзные люди работали на Macintosh-ах.
Очень серьёзные на Unix-ах.
Винда в качестве бизнес-платформы популярна только в России,
потому что в школах и университетах учат программировать под винду,
так как гранты получают в основном только от Microsoft-а. Затем
выпускники идут работать в 1С или банк, где пишут на ActiveX,
который работает только в Internet Explorer-е. Vendor-lock работает
превосходно. Microsoft купила российскую систему образования в сфере
программирования с потрохами.
[...]
Чему вы радуетесь то? Бесконечной зависимости российской экономики
от закрытой операционной системы с кучей backdoor-ов контролируемых США?
И всё это ведь рассказывает не какой-то поклонник свободного ПО с сильно
предвзятым мнением.
Sergey Matveev [Sat, 11 Dec 2021 08:43:59 +0000 (11:43 +0300)]
Gentoo о Python экосистеме пакетов
https://blogs.gentoo.org/mgorny/2021/11/07/the-future-of-python-build-systems-and-gentoo/
Gentoo тоже не выдерживает и пишет о страданиях с полностью поломанной
экосистемой пакетов Python, в которой вообще не понятно что будет
дальше, ибо разработчики просто без оглядки пилят и пилят что-то.
Sergey Matveev [Fri, 10 Dec 2021 18:30:31 +0000 (21:30 +0300)]
Простые задачи на "Linux"
https://www.youtube.com/watch?v=TtsglXhbxno
https://www.youtube.com/watch?v=3E8IGy6I9Wo
Буквально ни одна задача мною бы не выполнялась так как предполагают они.
Насколько же разные подходы у Unix-пользователей (типа меня) и остальных.
Вообще я даже и не представлял сколько сил оказывается было потрачено на
всю эту GUI-ню в нём. И ещё отчётливее становится для кого пилится systemd.
Я бы вряд ли чего смог сделать в GUI GNU/Linux-а, без помощи Google. Но
познавательно!
Sergey Matveev [Fri, 10 Dec 2021 09:10:21 +0000 (12:10 +0300)]
Прочитал "Обмен разумов" Роберта Шекли
https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BC%D0%B5%D0%BD_%D1%80%D0%B0%D0%B7%D1%83%D0%BC%D0%BE%D0%B2
Очень понравилась история! Кроме конца -- совсем уж какая-то
чушь высосанная из пальца. Но 90% всей книги по духу напоминает
"Автостопом по галактике" -- столько забавного абсурда!
Sergey Matveev [Wed, 8 Dec 2021 09:46:05 +0000 (12:46 +0300)]
Github будет форсировать 2FA для популярных NPM пакетов
https://www.opennet.ru/opennews/art.shtml?num=56304
https://github.blog/2021-12-07-enrolling-npm-publishers-enhanced-login-verification-two-factor-authentication-enforcement/
То бишь, если бы я хостил свои NPM-чики на нём, то пришлось бы уходить в
другое место. Вот с какой стати хостер репозитория/проекта вообще смотрит
на популярность проекта? Благо я давно свалил с них.
Sergey Matveev [Wed, 8 Dec 2021 07:55:40 +0000 (10:55 +0300)]
LaTeX и Vim
https://castel.dev/post/lecture-notes-1/
https://habr.com/ru/post/445066/
Человек круто заморочился с snippet-ами в Vim -- прям отличный пример
где они могут пригодится и чем они удобны. А то 99% всех примеров что я
видел: такая банальщина, что делается или аббревиатурами или простыми
vimscript-ами (быстрее их написать чем читать документацию по
snippet-ам). Или же явно сильно выдуманные примеры. А тут прям боевые
применения не тривиальные.
В продолжение его статьи думал что будет TikZ показан, но автор
оказывается иллюстрации делал уже в Inkscape. Не тру, но конечно же в
TikZ нельзя быстро сварганить что-то, так что тут безвыходное положение.
Помню что не было ни одной картинки, ни одной схемы, которую бы я
рисовал от руки (пускай и на компьютере) в курсовых или дипломном
проекте: Gnuplot для графиков, что-то Python/Perl-ом сгенерированное,
был GraphViz, а дальше масса TikZ рисунков. И после института, если надо
было что-то нарисовать, то тоже его использовал, хотя постоянно имея под
рукой tutorial/документацию ибо забывается из-за нерегулярности.
Sergey Matveev [Tue, 7 Dec 2021 09:53:40 +0000 (12:53 +0300)]
zsh $mailpath и atime
Сколько же лет мне потребовалось чтобы допереть до отключения atime на
ZFS разделе где находятся почтовые ящики! Он был единственным, где atime
включён. И только по причине того, что zsh смотрит на atime
файлов/директорий перечисленных в $mailpath (для вывода сообщения о
появлении новой почты). Залез в исходники zsh: действительно,
проверяется atime > mtime ли. Однако, так как у меня maildir-ы, то новая
почта попадает в new/ поддиректорию. А Mutt, при открытии такого ящика,
всё перемещает в cur/, даже если я само сообщение не прочитал (оно всё
равно в Mutt будет иметь метку "N"). Что мешает zsh-у смотреть не за
всей иерархией maildir-а, а только за его new/? Дошло только сегодня.
Теперь atime можно отключить вовсе -- последний dataset где он остался.
Sergey Matveev [Tue, 7 Dec 2021 08:58:05 +0000 (11:58 +0300)]
Прочитал "Цивилизацию статуса"
https://ru.wikipedia.org/wiki/%D0%A6%D0%B8%D0%B2%D0%B8%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_%D1%81%D1%82%D0%B0%D1%82%D1%83%D1%81%D0%B0
Крутая история! Причём самое то интересное для меня в ней было под самый
конец, где главный герой возвращается на Землю, опрашивает разные
категории граждан и видит ужас во что всё (относительно него и меня,
конечно же) превратилось. Частично то ведь что-то есть и в современном
мире, к сожалению.
Sergey Matveev [Tue, 7 Dec 2021 08:53:43 +0000 (11:53 +0300)]
Прочитал "Бесконечную историю" Михаэля Энде
https://ru.wikipedia.org/wiki/%D0%91%D0%B5%D1%81%D0%BA%D0%BE%D0%BD%D0%B5%D1%87%D0%BD%D0%B0%D1%8F_%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F_(%D0%BF%D0%BE%D0%B2%D0%B5%D1%81%D1%82%D1%8C)
Тоже детская книга типа "пунша" (a21dd83bb4d71d771f2dfa3c006a7aeacfb6e3cb),
но уже куда более серьёзная. Дети будут знакомы с понятием рекурсии и
амнезии. Показывает настоящую дружбу. Очень понравилась!
Sergey Matveev [Tue, 7 Dec 2021 08:51:47 +0000 (11:51 +0300)]
Прохождение Downfall
https://www.youtube.com/watch?v=fBgM0d_Ht00
Самая крутая horror игра что я знаю: Downfall
(268649c35a191daa616b2d5c0525dfe74d4e3580), именно 2009-го года, а не
remake 2016-го, где графика уже не создаёт всю нужную атмосферу.
Sergey Matveev [Tue, 7 Dec 2021 08:34:50 +0000 (11:34 +0300)]
Билефельдский заговор
https://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%BB%D0%B5%D1%84%D0%B5%D0%BB%D1%8C%D0%B4%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%B0%D0%B3%D0%BE%D0%B2%D0%BE%D1%80
Бывают забавные заговоры о не существовании всяких городов или даже
государств. Оказывается были слухи что Арзамаса-16 не существует, ибо
это заговор ЦРУ. Но я, можно сказать, всё лето проводил рядом с ним,
будучи ребёнком.
Sergey Matveev [Mon, 6 Dec 2021 11:32:44 +0000 (14:32 +0300)]
Заюзал второй сетевой интерфейс NUC-а
Дошло сегодня на работе что если его поместить в bridge с основным
интерфейсом, то через него можно подключить настольный компьютер и
получить гигабит между ними. А прежде они общались через 100Mbps
коммутатор и перелить 100GB бэкап ZFS-а занимает не один час.
В NUC моём сетевые интерфейсы на разных чипах: I210 (драйвер igb) и
I219 (драйвер em). Последний не поддерживает MSI-X прерывания --
только сегодня узнал про разницу.
Sergey Matveev [Mon, 6 Dec 2021 10:08:16 +0000 (13:08 +0300)]
MySQL не советует использовать один из его разработчиков
https://www.opennet.ru/opennews/art.shtml?num=56287
https://blog.sesse.net/blog/tech/2021-12-05-16-41_leaving_mysql.html
Один из разрабов MySQL не рекомендует его использовать, мол ужасно
не современная штука. Советует PostgreSQL.
А мне MySQL никогда и не нравился: начиная от конфигов, заканчивая в
целом всем подходом к администрированию. PostgreSQL это прям нечто типа
де-факто что берётся для серьёзной SQL СУБД.
Sergey Matveev [Sun, 5 Dec 2021 19:32:51 +0000 (22:32 +0300)]
Forth в компьютерах то давно
https://wiki.laptop.org/go/Open_Firmware
https://wiki.laptop.org/go/Forth_Lessons
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068464.html
https://wiki.freebsd.org/SummerOfCode2014/LuaLoader
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228924
Я знал что в Sun SPARC компьютерах применялся "BIOS" с Forth
интерпретатором встроенным, но, оказывается, Open Firmware и в Apple
Macintosh-ах на PowerPC и в IBM POWER системах применялась. Ну и в OLPC.
Компилятор, декомпилятор, ассемблер, дизассемблер, отладчик исходного и
ассемблерного кода -- всё умещалось в SPI flash-ку. У OLPC даже есть
tutorial по нему. Ну а в загрузчике FreeBSD тоже Forth встроен был, но
сейчас по умолчанию стали использовать загрузчик с Lua. К Lua у меня то
в целом довольно тёплое отношение и тоже могу понять что порог вхождения
в него для большинства пользователей всё же ниже, при этом язык и
реализация довольно минималистичны тоже.
Sergey Matveev [Sun, 5 Dec 2021 15:41:31 +0000 (18:41 +0300)]
Рок-клубы прошлого и концерты будущего
https://moslenta.ru/news/moskovskii-gitarist-vspomnil-o-rok-klubakh-proshlogo-02-12-2021.htm
Среди перечисленных гитаристом из статьи, был во всех (Точка, Б2,
План-Б, Вольта), кроме Апельсина -- но в нём был отец на Sweet группе.
Странно что Вольта причислена к "старым" -- она ж открылась ещё при мне,
вроде уже даже после окончания института. По количеству концертов я
вроде больше всего был в Релаксе (хотя статистику по клубам не веду),
который не раз переименовывался и даже перестраивался кардинально
(застал как "старый", так и "новый"). Если и не по количеству посещений,
то по количеству услышанных там групп это точно. А дальше в Вольте.
http://cluub.ru/club/relax/ (уже закрыт)
http://cluub.ru/club/milk/ (закрыт)
http://cluub.ru/club/planb/ (закрыт)
http://cluub.ru/club/tochka/ (закрыт)
http://cluub.ru/club/yotaspace/
http://cluub.ru/club/moskva_hall/
http://cluub.ru/club/volta/
http://cluub.ru/club/pravdaclub/
http://cluub.ru/concert_hall/izvestiya/
http://cluub.ru/club/arena/
http://cluub.ru/concert_hall/crocus_city/
Но тут список очень скудный, ибо нет кучи других мест, типа "Чеширского
кота", где от слэма от деревянного пола отлетали доски и сотрудники
клуба прям во время выступлений забивали гвозди назад, а зимой отопление
было организовано просто в виде бензиновой тепловой пушки стоящей в
зале. Бывшего X.O., где были Jig-Ai, Rompeprop, Dead Infection и мой
первый поцелуй. 7-Клуба расположенного в подвале обычного жилого дома,
где было незабываемо тесно, и когда я тряс башкой, то волосня попадала
под руки гитаристу питерской группы Engorged Vaginal Abyss.
Был ещё и тут, но это тоже далеко не полный список:
https://concertinfo.ru/place/175
https://concertinfo.ru/place/204
https://concertinfo.ru/place/286
https://concertinfo.ru/place/188
https://concertinfo.ru/place/214
https://concertinfo.ru/place/197
https://concertinfo.ru/place/347
https://concertinfo.ru/place/229
https://concertinfo.ru/place/217
https://concertinfo.ru/place/274
https://concertinfo.ru/place/424
https://concertinfo.ru/place/289
https://concertinfo.ru/place/177
https://concertinfo.ru/place/173
https://concertinfo.ru/place/226
https://concertinfo.ru/place/186
Пока смотрел всё это, то очень и очень не мало групп планируется
выступать в 2022-ом! Lindemann (название тура "Я ненавижу детей"),
Behemoth, 1349, Igorr, Within Temptation, Eisbrecher, Marduk, Lacuna
Coil, In Extremo, даже Coyote Brutal Fest (https://concertinfo.ru/gig/18236/)
и чего ещё только нету. Надеюсь я всё же расчехлю свои dancing shoes.
Sergey Matveev [Sun, 5 Dec 2021 15:19:10 +0000 (18:19 +0300)]
История Samsung
https://16-bits.ru/%D0%BA%D1%80%D0%B5%D0%BC%D0%BD%D0%B8%D0%B5%D0%B2%D1%8B%D0%B5-%D1%82%D0%B8%D1%82%D0%B0%D0%BD%D1%8B-%E2%84%9635/
Бурдж-Халифа оказывается построена Samsung-ом. Даже не представлял что
они и строительством занимались. Как и Goldstar/LG
(48ec95d22f88c8d8bf865feefd77f4ebcc996df7) -- проще сказать что
они не пытались делать (причём очень успешно). Даже ракетами.
Sergey Matveev [Sun, 5 Dec 2021 09:06:50 +0000 (12:06 +0300)]
Quake Horde режим
https://www.youtube.com/watch?v=PZwfy8KD-L0
Первое за 25 лет дополнение для Quake. В видео некто играет очень
хорошо, выпилив 664 фрага за чуть менее чем 8 минут. Насколько же мне
приятен именно такой класс игр стрелялок, где не продохнуть, где каждый
десяток миллисекунд на счету.
Sergey Matveev [Fri, 3 Dec 2021 17:02:06 +0000 (20:02 +0300)]
NNCP развитие и использование людьми
https://jb55.com/log/2021-11-06-airgapped-bitcoin-node-nncp.html
https://blog.taoetc.org/how_to_publish_a_static_site_over_nncp/index.html
Чисто случайно (никакого поиска относящегося к NNCP не делал), ходя по
каким-то ссылкам, внезапно увидел что люди используют NNCP для таких
вещей как airgap BitCoin нода и в качестве транспорта для публикации в
блоги. Кто-то git фигачит поверх NNCP. Приятно что у всех без проблем
получается это собрать из tarball с использованием минималистичного
redo. И что авторы считают что NNCP легко пользоваться. Да и прям
буквально сейчас NNCP упомянут в рассылке обсуждения Gemini протокола и
тоже есть интересующиеся.
Когда я делал очередное изменение шифрованных пакетов
(9dbbfb48af71d290a67a389117411ded7ecc11a6), то подумал про себя что
забавно было бы наблюдать за прогрессом проекта и его изменений форматов
пакетов. Это же ведь и самый долгоживущий более-менее большой проект.
Например на какой-нибудь GoVPN я окончательно плюнул
(9ed0a1b3edd6548e2f9a8b8dadca4975c2bce969).
Простой пакет:
* v1: изначально состоял из:
TYPE || PATHLEN || PATH || PAYLOAD
* v2: дальше к нему добавился приоритет:
TYPE || NICE || PATHLEN || PATH || PAYLOAD
* v3: структура осталась прежней. Вместо zlib-сжатия стал использоваться
Zstandard. Сейчас вот смотрю и понимаю что можно было бы просто ввести
новый TYPE полезной нагрузки.
Типы простых пакетов:
* изначально были FILE, FREQ (file request), MAIL, TRNS (transitional)
* позже MAIL поменялся на EXEC, оставаясь обратно совместимым по
формату. NNCP стал не только почту посылать через вызов sendmail, но и
любую другу команду. Действительно, зачем надо было так себя
ограничивать? Но, видимо, потому что боялся того что было в UUCP, где
даже передача файлов превращалась в вызов "cp" команды, а хочется
эффективности и простоты
* позже узнал что люди применяются nncp-exec для посылки отнюдь не
маленьких простых файлов, а вообще всякой бинарщины. Как минимум, для
которой форсированное сжатие EXEC-пакетов будет даже вредным. Появился
EXEC-FAT тип пакетов, где просто навсего не применяется Zstandard
* ну и относительно недавно появились AREA пакеты, для multicast
рассылки FILE и EXEC(-FAT)
Sync protocol вообще не поменялся с момента создания. Пакеты имеют тип
и, зависимое от него, тело, всё фиксированного размера. Возможные типы:
HALT
PING
INFO || NICE || SIZE || HASH
FREQ || HASH || OFFSET
FILE || HASH || OFFSET || PAYLOAD
DONE || HASH
Пакеты для multicast discovery появились недавно и вообще состоят ровно
из одного (кроме магического числа) из идентификатора отправителя.
Формат еблобов (EBlob, Encrypted Blob) по сути оставался прежним, но
из-за изменения алгоритмов шифрования для зашифрованных пакетов, заодно
менял и шифрование в нём, поэтому три версии.
S || T || P || SALT || BLOB
Где S, T, P это параметры Balloon функции хэширования пароля, соль --
просто рандом, ну а BLOB это зашифрованный на выработанном ключе, кусок
данных. Команда nncp-cfgenc может использоваться для любых данных, не
только конфигов, но в NNCP штатно используется только для них.
Формат .nncp.meta пакетов, описывающих .nncp.chunk файлы, по сути тоже
не менялся, но версия один раз поменялась из-за глобальной замены хэш
функции. Всё очень тривиально:
FILESIZE || CHUNKSIZE || HASH0 || HASH1 || ...
AREA пакеты имеют своё выделенное магическое число, но формат самого
пакета идентичен зашифрованному пакету.
Наконец зашифрованные пакеты:
* v1: первая версия:
NICE || SENDER || EPUB || SIGN ||
SIZE || MAC ||
CIPHERTEXT || MAC || JUNK
SIGN = sign(NICE || RCPT || SENDER || EPUB
Использовала Twofish в режиме CTR, BLAKE2b-256-MAC для MAC.
SIZE зашифрован и для него есть отдельный MAC.
Четыре ключа (шифрование+MAC для SIZE и полезной нагрузки)
вырабатывались HKDF-Blake2b-256.
AES принципиально не хотелось. Почему сразу не выбрал Salsa20
какой-нибудь? Совершенно не могу вспомнить.
* v2: в заголовке появилось RCPT поле, явно указывающее получателя:
NICE || SENDER || RCPT || EPUB || SIGN || ...
Было ли недоработкой отсутствие RCPT прежде? Скорее да. Ничего
серьёзного бы не произошло, но неприятно видеть пакеты по какой-то
причине попавшие в spool, но мы их не можем дешифровать.
* v3: Twofish заменён ChaCha20.HKDF-BLAKE2b-256 заменён BLAKE2Xb.
Минус два криптографических примитива (ChaCha20 используется в SP
протоколе). Данные разбиваются на 128KiB блоки, шифруемые друг от
друга независимо, используя номер блока в качестве счётчика, nonce-а
для ChaCha20.
* v4: BLAKE2b-MAC-256 заменён на Poly1305 и теперь каждый 128KiB блок
аутентифицируется независимо от других. Это увеличивает суммарный
размер шифротекста, так как для каждых 128KiB добавляются 128-бит
Poly1305, но зато существенно упрощает код, и, самое главное то, блок
сначала дешифруется/аутентифицируется, а уж только потом его выход
подаётся например на вход внешней EXEC команды.
Считать ли недоработкой прежний формат? То что в EXEC подаются
неаутентифицированные данные -- ну это уже проблема вышестоящего
уровня, аналогичная "gpg -d < | cmd". А не использование Poly1305 всё
же уменьшало overhead. Мизерный, но всё равно в общем-то избыточный.
* v5: масштабная замена BLAKE2b-256 на BLAKE3 и MTH (Merkle Tree
Hashing). Содержимое самого пакета это повлияло только заменой
BLAKE2b KDF функции на BLAKE3. BLAKE2b XOF использовался для создания
padding-а -- теперь BLAKE3 XOF.
BLAKE3 на момент создания NNCP ещё не существовал. Когда появился и я
проникся скоростью его работы -- для меня это ещё не было поводом
замены BLAKE2b, реализации которого, вообще-то местами могут быть
сравнимы с BLAKE3. Да и вообще скорость настолько высокая, что не
проблема.
Но главное "изобретение" это MTH, который позволяет частями вычислять
хэш пакета. Главное для чего это делалось: не читать докачиваемый в
online режиме файл полностью от и до, а после скачивания только
прочитать его начало до момента начала докачивания. Ведь данные при
скачивании же всё равно через нас прошли -- хотелось бы сразу сделать
над ними вычисления и забыть. Ведь файлы могут быть на практике в
сотни гигабайт: обломались на скачивании первого килобайта, дальше
скачиваем оставшиеся сотни гигабайт и снова с нуля будем считывать их
с диска? С MTH это не нужно. Ну а раз это в любом случае делает формат
хэша над всем пакетом обратно несовместимым, то можно и низлежащий
алгоритм заменить (BLAKE2b на BLAKE3).
* v6: потоковый формат шифрования.
SIZE поле отсутствует, но каждый 128KiB блок может быть зашифрован
одним из двух ключей. В зависимости от ключа, определяется наличие в
начале блока метаинформации о полном размере пакета и pad-а. Теперь
временные файлы не нужны вообще, прежде использованные при получении
данных из stdin-а чтобы узнать их итоговый размер.
Sergey Matveev [Fri, 3 Dec 2021 10:42:23 +0000 (13:42 +0300)]
RISC-V -- плохая ISA, по мнению автора GMP
https://gmplib.org/list-archives/gmp-devel/2021-September/006013.html
https://gmplib.org/list-archives/gmp-devel/2021-September/006017.html
Ну... RISC-V это же RISC. Хотя должны быть разумные пределы.
Sergey Matveev [Thu, 2 Dec 2021 18:17:06 +0000 (21:17 +0300)]
Мемы Фидонета
http://wikireality.ru/wiki/%D0%9C%D0%B5%D0%BC%D1%8B_%D0%A4%D0%B8%D0%B4%D0%BE%D0%BD%D0%B5%D1%82%D0%B0#.D0.A0.D0.B0.D1.81.D1.81.D0.BA.D0.B0.D0.B7_.D0.BF.D1.80.D0.BE_.D1.85.D0.BE.D0.BB.D0.BE.D0.B4.D0.B8.D0.BB.D1.8C.D0.BD.D0.B8.D0.BA
Про холодильник я застал мем! Похоже это единственный раз когда я был в
теме, а не читал про мемы в каких-нибудь wiki или от кого-то выслушивая
объяснение. Настолько он мне понравился, что с тех времён до сих пор он
у меня на диске сохранён (/home/stargrave/notes/fun/Холодильник.txt).
Возможно потому что был маленький, но помню, как глядел я в своей FreeBSD
в Голого Деда, чисто текстовый режим (X-ы не запускал почти никогда),
читаю, читаю, дохожу до конца и разрождаюсь смехом! Сколько потом
других анекдотов/сообщений заканчивалось аналогично! Конечно же, позже
уже надоедая (на то он и мем).
Про пропадающую букву "Н" в курсе был, но не помню чтобы оно сильно
забавляло -- скорее раздражало, как раздражает какая-нибудь дурацкая
кодировка текстового файла.
Болгарина Незабора Бандлов не застал, но это наверное скорее к локальным
эхам и поинтам относится. А у нас в Королёве была одна босс-нода.
Sergey Matveev [Thu, 2 Dec 2021 08:24:14 +0000 (11:24 +0300)]
Детально поизучал Signal и OMEMO протоколы
OMEMO прям полностью основан/повторяет Signal. Только некоторые вещи
чуть упрощены, типа использования только Curve25519 ключа, преобразуя
его в Ed25519 где надо. Никаких XEdDSA не нужно при этом. Я думал
различий будет больше. Хорошие решения в общем.
Sergey Matveev [Thu, 2 Dec 2021 08:12:17 +0000 (11:12 +0300)]
Использовал Jitsi Meet
Какое же это всё говнище!
Во-первых, я Jitsi уже пробовал у себя собирать на FreeBSD --
собирается, но вот не запускается из-за баги в libc, мешающей где-то
этому Java софту. Бага тут именно в FreeBSD и она в более поздних
версиях исправлена -- просто мне лень обновляться. Но я думал что вот
когда обновлюсь, то и Jitsi клиент будет, ибо на работе его пару раз уже
призывали использовали. Оказалось что конференции то он и не держит --
поэтому и смысла нет ставить.
Во-вторых, под Firefox оно или не работает, или FF должен быть хостом,
дабы согласовать все кодеки(?) общим знаменателем. На работе сразу
сказали что надо юзать Chrome-based броузеры. То есть, ни нормального
клиента, ни броузера кроме Chrome не сгодится. Дожили.
Начал искать какие есть LiveCD где Chromium из коробки есть. Ну чтобы не
устанавливать, не тратить время, и вообще не на каждом компьютере
достаточно памяти чтобы в ней уместился его пакет. Успешно вышло с
Knoppix: очень быстро (на порядок или два) загружается, автоматом
размечает партицию для хранения state-а. Просто загрузись и будет
Chromium.
Попробовал на ноутбуке с Core2Duo и 2GB RAM. Если хоть у кого-то при
этом передаётся видео (даже в самом убогом качестве), то ему не хватает
CPU мощи чтобы даже от себя отправлять только голос -- он так лагает,
что разобрать мою речь, говорят, невозможно.
Пошёл за 4-ядерный i5 с 16GB RAM. Аудио в конференции хоть как-то но уже
юзабельно, но если есть хотя бы одно видео, то минимум одно ядро сразу
полностью отъедается. Попробовали расшарить экран программы: в течении
полминуты он может ничего не обновить у меня, хотя в программе не один
раз всё перерисовалось. У двух других вообще не получилось расшарить
окно, чтобы PDF-ку показать.
В общем, всё это лютая жопа. Я бы сказал что неюзабельная.
Sergey Matveev [Thu, 2 Dec 2021 08:09:18 +0000 (11:09 +0300)]
Прочитал "Город" Клиффорда Саймака
https://ru.wikipedia.org/wiki/%D0%93%D0%BE%D1%80%D0%BE%D0%B4_(%D1%80%D0%BE%D0%BC%D0%B0%D0%BD,_1952)
Очень понравилась книга! Люди переселились на Юпитер, а Землю захватили
муравьи :-). Ну и конечно пёсики -- остаются хорошими и добрыми существами
даже через тысячи лет.
Sergey Matveev [Tue, 30 Nov 2021 08:35:58 +0000 (11:35 +0300)]
Tritty
https://github.com/sjmulder/trickle
Эмулятор терминала с ограничением по пропускной способности. Можно
оценить как бы жилось на консолях с 300-600 bps. Vim быстро падает в
режим: 'redrawtime' überschritten, Syntaxhighlighting deaktiviert,
отключая синтаксическую подсветку при выводе после дюжины строк. Конечно
же, пользоваться им абсолютно невозможно. zsh-ем со всякими разноцветными
подсветками и suggestion-ами -- тоже. Видно как не оптимально, с точки
зрения трафика, многое перерисовывается.
Sergey Matveev [Tue, 30 Nov 2021 07:52:40 +0000 (10:52 +0300)]
SmartTV заточены под шпионаж
https://habr.com/ru/company/globalsign/blog/592407/
https://habr.com/ru/company/globalsign/blog/479022/
https://news.ycombinator.com/item?id=29382643
Скоро, пишут, запросто эти ТВ будут раздавать бесплатно, ибо рекламой
всё с лихвой окупится. Ну и слежкой. Только идея этому не нова, а называется
"телекран" из 1984-.
Sergey Matveev [Tue, 30 Nov 2021 01:49:55 +0000 (04:49 +0300)]
Умерла Бонька
Стало плохо собаке. А дальше, судя по рассказу родителей, её просто
замучили до смерти анализами и отказывались вообще что либо делать в
течении часа в ветеринарной поликлинике. Составили протокол и вызвали
полицию зафиксировать этот акт садизма с доведением до убийства.
Sergey Matveev [Mon, 29 Nov 2021 18:02:25 +0000 (21:02 +0300)]
Прохождение концовки NetHack
https://www.youtube.com/watch?v=vwl7OEIBnGE
Показано под каким-то ужасным GUI интерфейсом (дело привычки?), но это
самая захватывающая часть игры, где на каждом уровне пути назад уже не
будет. Прохождение четырёх Равнин: земли, огня, воды и воздуха. А дальше
астральная равнина, где я с трудом понимаю как реально можно остаться в
живых если не повезёт с первым храмом. a3f8f9a70412480c4d8b6731f96dc0a859ec1b63
Sergey Matveev [Mon, 29 Nov 2021 17:58:35 +0000 (20:58 +0300)]
Качество современного Call of Duty
https://youtu.be/uYNxfXBKvik
Забавные нарезки всяких косяков и ленностей разработчиков. С одной
стороны: да и чёрт со всем этим, ибо в Doom/Quake/Medal Of Honour и
без этих потуг в реалистичности играли. С другой, это же жутко дорогая
разработка, в которую вбухивают куда больше денег чем в прежние времена,
и качество хотелось бы тоже на должном уровне. Когда костерок состоит из
двух спрайтов, а дерево сакуры из набора спрайтов плоских... серьёзно,
как в середине 90-х?
Sergey Matveev [Mon, 29 Nov 2021 17:50:05 +0000 (20:50 +0300)]
Пробую шрифт Go
https://go.dev/blog/go-fonts
Сегодня было сильное чувство что что-то надо поменять. Вспомнил про Go
шрифт, но не причины чем он не понравился. Просидел сегодня с ним целый
день. Возможно прежде я его отсеял только когда он появился: судя по
репозиторию, через какое-то время его обновили.
Более компактный -- чуть больше строчек влезает, при отличной
читаемости. Inconsolata LGC на меньших размерах начинала "плясать".
Не знаю почему, но она не всегда рисовала пустышки на месте всяких
иероглифов -- Go-шный же рисует.
То есть, Inconsolata LGC в принципе то устраивала, но Go просто ещё
лучше оказывается. Хотя и чувствую себя каким-то яблочником, ибо у них
всё, к чему притронулась рука Apple, становится лучшим на свете. А я Go
считаю лучшим ЯП, а тут вообще речь про шрифт.
https://www.litmir.me/br/?b=736712&p=1
Просто попалась эта книга по списку, но в тему предстоящего Нового Года.
Годится и для детей маленьких. Про то, как ворон с котом спасли мир от
всего плохо. Понравилась. Лёгкая, очень смешная, добрая.
Sergey Matveev [Mon, 29 Nov 2021 09:47:39 +0000 (12:47 +0300)]
Избавляются от Лены, "Первой леди Интернета"
https://richg42.blogspot.com/2021/11/lena-is-retired.html
https://ru.wikipedia.org/wiki/%D0%9B%D0%B5%D0%BD%D0%B0_(%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5)
https://habr.com/en/company/nag/blog/408831/
Только сейчас узнал почему её изображение обрезано на уровне плеч:
банальное ограничение сканера на геометрию.
Sergey Matveev [Sun, 28 Nov 2021 18:27:53 +0000 (21:27 +0300)]
Solefald любимейшая группа сейчас
https://en.wikipedia.org/wiki/Solefald
https://www.youtube.com/watch?v=kfb08b6iIMs
Если сейчас спросить какая группа у меня любимейшая, то в этом году
однозначно бы ответил что Solefald. В этом году заслушиваю до дыр. Даже
их "викинговые" альбомы заходят. На записи их концерт в стенах какой-то
крепости, похоже -- круто выглядит. Их Cornelius Jakhelln-а в живую в
составе GUT слышал -- вообще полностью грайндкорная тема.
Sergey Matveev [Sun, 28 Nov 2021 09:22:06 +0000 (12:22 +0300)]
Tardigrade Inferno vs Solefald
В 625a35369110ae8ddefef73b50c1f57e52d7bc64 писал что дежавю есть от
прослушивания Tardigrade Inferno некоторых песен. Слушаю "Circular
Drain" Solefald-а и мотивчик с третьей минуты "Sivilisasjonens
Slor-Ravens Fall" трэка прям скопировано Tardigrade-ом в какой-то из
композиций.
Sergey Matveev [Sat, 27 Nov 2021 19:36:53 +0000 (22:36 +0300)]
Переписал torn с Perl на zsh
http://www.git.stargrave.org/?p=torn.git;a=blob;f=torn.zsh
Мой самый старый престарый скрипт из всех что я использовал регулярно по
сей день, где в copyright указан аж 2007-ой год, переписан с Perl на zsh.
Точнее он стал zsh функцией, а не полноценным исполняемым скриптом.
Иногда мне нужна только транслитерация. Иногда нужно всё кроме
транслитерации. На самом деле сейчас я стал меньше транслитерировать
имена файлов, ибо в целом софт и современные Unix файловые системы их
хорошо поддерживают.
Подразумевается что используется это вместе с zmv, но никакой специфики
для него нет. Вместо "torn" вызова можно сделать: zmv "*" '`torn $f`.
Прежде была FORCE_DIR переменная, а теперь достаточно работать с glob-ом
самого zsh. zmv -Q "(**/)*(.)" '`torn $f`'. Можно вызывать tornt функцию,
только для транслитерации. Можно включить интерактивный режим (-i) или
dry-run (-n) самого zmv.
Это же ещё и первый раз когда я написал функцию для использования с autoload-ом.
Sergey Matveev [Sat, 27 Nov 2021 15:56:41 +0000 (18:56 +0300)]
Реклама польских политиков
https://www.youtube.com/watch?v=nUHBN-Qyrow
Не, я конечно в курсе сколько много отличных метал групп в Польше,
сколько я был на их концертах всяких, но у них и политики делают
заявления с death-metal подачей!
Sergey Matveev [Fri, 26 Nov 2021 20:26:32 +0000 (23:26 +0300)]
Цикл в fish и zsh
https://rmpr.xyz/the-fish-shell-is-amazing/
Автор показывает как плюс синтаксис fish:
for i in *.pdf
echo $i
end
по сравнению с "bash/zsh":
for i in *.pdf;
do
echo $i;
done
Во-первых, ";" излишни в этом примере. Во-вторых, в zsh это бы было:
for i (*.pdf) echo $i
И без всяких кавычек в большинстве случаев (впрочем, вроде и fish тоже
экранирует автоматом многое корректно). Куда короче чем в fish.
Хочется несколько команд? for i (*.pdf) { foo ; bar }.
Sergey Matveev [Fri, 26 Nov 2021 17:33:31 +0000 (20:33 +0300)]
Как на порядок увеличить скорость чтения файла в ZFS на NVMe
А точнее как не снижать скорость на порядок. В 032f5e60bc6079a889859150d5b5baf0f80d252a писал что у меня очень не
шустро читаются файлы. Но при этом быстро идёт scrub, resilver и, как
оказалось, dd с ZVOL-ов. Последнее точно говорит что все данные проходят
через круги сжатия и проверки целостности.
Оказалось, что у меня было заблуждение на протяжении 10+ лет касательно
prefetch-а и SSD. То что prefetch может вредить random IOPS-ам, особенно
на HDD -- тут всё очевидно. Но я также считал что оно и для SSD
бесполезно будет тратить пропускную способность.
Отключение sysctl vfs.zfs.prefetch_disable=1 настройки избавило от всех
проблем со скоростью чтения файлов. Предполагаю что банальные задержки
при отправке и ожидания IO запроса и сводят на нет всю производительность.
Как в сетях и модемах: если ждать ответ на каждый запрос, и только потом
отправлять очередной, то канал утилизируется самым плачевным образом. У
меня и в мыслях не было что на таких быстрых и коротких высокочастотных
PCIe это тоже будет заметно проявляться.
Sergey Matveev [Thu, 25 Nov 2021 08:36:11 +0000 (11:36 +0300)]
Проверка производительности пропускной способности памяти
https://zsmith.co/bandwidth.php
Хоть Makefile-ов под FreeBSD нет, но собирается clang-ом без проблем.
А то я даже не знал прежде чем вообще можно было бы померить скорости.
Sergey Matveev [Thu, 25 Nov 2021 08:32:21 +0000 (11:32 +0300)]
Полтысячи новостных лент
http://www.stargrave.org/Links.html
Сегодня обнаружил что в RSS/Atom читалке у меня стало полтысячи лент.
Причём это с относительно недавней зачисткой блогов в которые не пишут
уже пару лет, которых не один десяток ещё набралось бы. При этом тут нет
никаких Hacker News, ибо приоритеты в статьях у них просто безбашенные
какие-то, перестал читать.
Sergey Matveev [Thu, 25 Nov 2021 08:03:03 +0000 (11:03 +0300)]
ИБП не тянет корзину с дисками
Давно я не включал свою корзину с четырьмя SAS 10kRPM дисками. Ни разу с
момента приобретения NUC-а. Вчера она поработала минут пять, а дальше ИБП
начал на одной частоте орать, мол всё, больше не тянет. Пришлось
временно напрямую к розетке подключить. Два сервера (где процессоры под
85-90W), NUC и корзина уже не могут работать. Да и на самом деле с
NUC-ом уже замечал что он может не успеть переключиться.
Sergey Matveev [Wed, 24 Nov 2021 19:38:52 +0000 (22:38 +0300)]
Прочитал "Живущий в последний раз" Генри Лайона Олди
https://fantlab.ru/work444
Не первая книга этих двух братьев (скрывающихся под псевдонимом). До
конца осиливаю их, но как-то особо ничего больше не запоминается. Вроде
бы и не плохо, но и ничего особого. Короче так себе.
Sergey Matveev [Wed, 24 Nov 2021 10:46:41 +0000 (13:46 +0300)]
История трэкбола начинается с боулинга
https://habr.com/ru/post/590299/
В Симпсонах видел серию про "свечной боулинг", где были шары меньшего
размера. Вот и в Канаде для первого прототипа трэкбола буквально
использовался шар для булинга. Видел что бывает совместимость и с
бильярдными шарами.
Я уже много лет только трэкбол везде и использую. С четырьмя кнопками и
колесом прокрутки. Полностью доволен -- оно стоило того. Но я никогда не
пробовал трэкболы где используется только большой палец -- мне кажется
как-то оно даже выглядит не здорово и будет убийственно для суставов.
Sergey Matveev [Wed, 24 Nov 2021 10:17:54 +0000 (13:17 +0300)]
NVMe скорость в моём ZFS
Недавно поработал с 100 GiB архивами и заметил что как-то оно всё не
шустро работает -- ведь должно за пару десятков секунд всё мочь читать с
зеркала хороших NVMe. Посмотрел zpool iostat... с каждой NVMe не более
50-60 MiB/sec при простом чтении здорового файла и выше не поднимается.
То бишь, зеркало из двух нормальных NVMe при последовательном чтении
файла выдаёт в два раза ниже скорость чем один единственный жёсткий диск.
С IOPS-ами всё хорошо -- не раз видел и 50k/sec на каждую. scrub и
resilver показывают 500-600 MiB/sec. Запись без проблем делает и по
полтора гигабайта в секунду. А вот просто чтение -- удручает.
Пробовал крутить всякие sysctl, но ничего не помогает. Загрузился с
LiveCD более современной FreeBSD -- 500-600 MiB/sec с каждой NVMe. Так
что какая-то у меня уж очень древняя система имеющая большие проблемы с
NVMe. Надо бы обновляться, но так ленно.
Sergey Matveev [Tue, 23 Nov 2021 21:44:16 +0000 (00:44 +0300)]
Вуппертальская подвесная дорога в 1902-ом
https://www.youtube.com/watch?v=EQs5VxNPhzk
Для меня это смотрится просто невообразимо, что в 1902 уже были такие
футуристичные штуки, при этом под вагончиками лошади с повозками. Вообще
эта Wuppertaler Schwebebahn для меня является иллюстрацией чего-то из
будущего, даже для современности оно слишком круто выглядит. А тут до
автомобилей всё уже.
Sergey Matveev [Tue, 23 Nov 2021 20:06:42 +0000 (23:06 +0300)]
Прочитал "Открытие медлительности"
https://en.wikipedia.org/wiki/The_Discovery_of_Slowness
В целом книга понравилась, но ничего особенного. Начало скучновато, но
дальше уже действо пошло, когда Франклин пошёл в экспедиции. Под конец
было разочаровался, ибо как-то уж больно скудно информации про сами эти
походы и плавания. Но... а с чем мне сравнивать? С hardcore не
художественными книгами самих Нансенов и Амундсенов, про Шеклтона,
сравнение с Скоттами? "Открытие..." это лёгкое художественное чтиво,
поэтому нефиг было ждать от него деталей. Закончилось всё быстро на
плавании Террора и Эребуса... где самое место взять "Террор" Дэна
Симмонса и поужасаться.
Sergey Matveev [Tue, 23 Nov 2021 20:02:25 +0000 (23:02 +0300)]
Съездил на Рассказовку заценить какие книги предлагают почитать
В одном месте увидел что на колоннах по всей станции метро Рассказовка:
QR-коды на книги. Надеялся что там будет какой-нибудь уголочек с
Хайнлайном, Кларком и Азимовым, но увы. Из близкого к фантастике увидел
(хотя я конечно очень бегло смотрел) Жюля Верна, Конана Дойля, Замятина.
Метро какое-то стало просто огромное! Я на эту поездку суммарно потратил
в метро почти три часа времени!
Sergey Matveev [Sun, 21 Nov 2021 19:39:00 +0000 (22:39 +0300)]
Замена распаяной памяти в ноутбуке
https://gregdavill.github.io/posts/dell-xps13-ram-upgrade/
Никогда не видел фотографии того, как реально эти шарики приделывают к
микросхемам. Я вообще тут мало чего понимаю, но посмотреть интересно.
Sergey Matveev [Sun, 21 Nov 2021 19:30:36 +0000 (22:30 +0300)]
Стабильность софта под OpenBSD и другими BSD
Где-то читал высказывание о том, что, так как под OpenBSD куча всяких
ASLR, защит стэка и подобных штук, то коряво написанный софт там будет
падать или совершенно некорректно себя вести, чем под GNU/Linux. А ведь
когда я разбирался со всеми этими технологиями
(5916b1b5c4827dccf0a7ced477a8e7d6de45908f), то тоже отметил аналогичное.
Особенно когда сидел под HardenedBSD. Бывает что софт работает какое-то
время, но потом вылетает в случайном порядке. Когда пытался выяснять
причины, находя имеющиеся bugreport-ы, то регулярно всё сводилось к
самому софту, неграмотно написанному или используюшего грязные трюки.
Так что вообще кто-то мог бы это как и недостатком BSD систем назвать:
мол на них не (совсем) работает то, что под GNU/Linux-ом как по маслу.
Но а вообще постоянно встречаешься с тем, что автор точно не задумывался
о других POSIX-совместимых ОС или не о GNU инструментации/компиляторе.
Sergey Matveev [Sun, 21 Nov 2021 19:09:39 +0000 (22:09 +0300)]
Ширли-мырли
https://ru.wikipedia.org/wiki/%D0%A8%D0%B8%D1%80%D0%BB%D0%B8-%D0%BC%D1%8B%D1%80%D0%BB%D0%B8
Ушёл из жизни Валерий Гаркалин. Знаю его только по роли в Ширли-Мырли.
Но зато какой роли! Вообще если спросить какой бы хороший фильм я смог
вспомнить снятый в России в 90-е годы, то только этот в голову и
приходит. Готов пересматривать не раз и продолжать оттуда цитировать.
Sergey Matveev [Sun, 21 Nov 2021 17:46:40 +0000 (20:46 +0300)]
git ls-files вместо find
https://cj.rs/blog/git-ls-files-is-faster-than-fd-and-find/
Любопытный трюк. Хотя я и прежде знал что это будет быстрее, но не
задумывался о реальном применении вместо find. Впрочем пока у меня
нет проектов где бы это точно пригодилось.
Sergey Matveev [Sun, 21 Nov 2021 13:46:01 +0000 (16:46 +0300)]
Более тысячи online BBS
https://www.telnetbbsguide.com/
https://news.ycombinator.com/item?id=29295689
До сих пор есть BBS-ки, список которых не уменьшается. Dial-up конечно
мало уже. Очень нравится что у них на сайте в качестве фоновой картинки
USRobotics Courier -- у меня была модель не X2, а с HST прошивкой, для
наших особо плохих (на тот момент) телефонных линий. Именно с этой
железкой (среди остальных) возникают самые тёплые воспоминания. На
BBS-ках (dial-up) я провёл не одни сутки (суммарно по времени), а дальше
очутился в FidoNet.
Sergey Matveev [Sun, 21 Nov 2021 13:35:31 +0000 (16:35 +0300)]
Избавился от своего асинхронного linter-а Python в Vim
http://www.git.stargrave.org/?p=dotfiles.git;a=commitdiff;h=f8c0bd99dd695bdab50de1086494d3ddbdb661db
http://www.git.stargrave.org/?p=dotfiles.git;a=commitdiff;h=1888ed5c42f3335a5907f608bde1084dcbc45a8b
http://www.git.stargrave.org/?p=dotfiles.git;a=commitdiff;h=fbef79437e9e5c0f6a608cb984be29095d2a9bbd
К великому сожалению, до сих пор попадаются проекты которые хотят чтобы
писались на Python. Обнаружил что LSP сервер может использовать flake8,
в том числе его конфигурационный файл. flake8 работает достаточно шустро
и не мешает и наоборот помогает. А раз flake8 всё равно запускается и
уже работает через LSP, то и надобности в моём "ручном" асинхронном
linter-е уже нет. Хотя ещё до конца не уверен действительно ли мне не
нужен quickfix с полным список сообщений.
Свою систему добавления import-ов очень легко переделать оказалось на
то, чтобы сообщения об отсутствующих import-ах брались из LSP.
Sergey Matveev [Sat, 20 Nov 2021 14:54:54 +0000 (17:54 +0300)]
go stringer
goredo оказался первым проектом где я использовал go generate и stringer
утилиту. В проекте оказалось ровно одно место подходящее для этой штуки,
но в других проектах их десятки. Кому-то конечно же не понравится такой
подход, но мне приятен.
Есть константы:
type InodeTrustType int
const (
InodeTrustNone InodeTrustType = iota
InodeTrustCtime
InodeTrustMtime
)
которые при печати выведут ничего не поясняющее для человека значение.
Хочется добавить нечто типа:
func (i InodeTrustType) String() string {
switch i {
case InodeTrustNone: return "none"
case InodeTrustCtime: return "ctime"
case InodeTrustMtime: return "mtime"
}
}
но геморройно, хотя я так много делал прежде.
Выполнив "stringer -type=InodeTrustType" я получаю
inodetrusttype_string.go файл в котором этот String() метод добавляется.
Причём эффективным образом, создавая:
const _InodeTrustType_name = "InodeTrustNoneInodeTrustCtimeInodeTrustMtime"
var _InodeTrustType_index = [...]uint8{0, 14, 29, 44}
где само числовое значение InodeTrustType-а будет индексом в массиве
смещений в константной строке.
А чтобы это автоматизировать, то можно добавить комментарий прямо в код:
//go:generate stringer -type=InodeTrustType
Sergey Matveev [Sat, 20 Nov 2021 14:50:45 +0000 (17:50 +0300)]
goredo 1.21.0 с mtime-ом
http://www.goredo.cypherpunks.ru/OOD.html
http://lists.cypherpunks.ru/archive/goredo-devel/2111/0073.html
Очередной релиз goredo, в котором можно теперь использовать сравнение
mtime-а файла, игнорируя ctime. В рассылку кинули забавное (но
ожидаемое) поведение, когда скопировав проект в другое место, всякие
redo-ood команды (определяющие протухшие цели) начинают работать на
порядок дольше. Выглядит забавно, но объяснимо. В современных ОС и ФС на
практике думаю можно полагаться и на mtime, который в случае копирования
бы помог.
Sergey Matveev [Fri, 19 Nov 2021 08:42:13 +0000 (11:42 +0300)]
Стоит ли OTR использования в XMPP?
Написал тут одному человеку своё мнение про OTR протокол, почему бы и
сюда не скопировать?
>Do you know about the OTR protocol? Is this worthwhile?
Yes, yes and yes :-)!
>I have a small Prosody server running on my Beaglebone
>Black through which I use mcabber to chat over XMPP with
>two friends.
Both prosody and mcabber were my favourite server/client programs
(when I used XMPP).
>I wonder if OTR is a good alternative.
First of all: they can not be compared so easily, because they are aimed
for very different tasks. OTR is intended to be used in online
interactive conversations only. Main PGP disadvantage is its lack of
so-called forward secrecy feature: if your long-term (and PGP has only
long-term keys) keys are compromised, then every previously sent message
can be decrypted. Ephemeral (Diffie-Hellman) key exchange must be done,
to use ephemeral (non long-term living) keying material for forward
secrecy, but that forces you to do at least one additional full
round-trip, that is not the use case for PGP (where you can just "fire"
message and forget about it).
OTR is aimed exactly for ephemeral conversations, with full forward
secrecy. They use Diffie-Hellman exchange with every message exchange,
so even compromising of current session keys won't harm for future
messages done during the current session/conversation. Of course by the
price of CPU overhead and slightly increased traffic (comparing to
purely symmetrically encrypted ciphertexts), but OTR is for human text
conversations, that are very low traffic with relatively small messages,
so that DH overhead should not be noticeable in practice.
OTR also even offers deniability of the authorship on the message: you
can verify the authenticity of the incoming message immediately, but its
authentication MAC key will be revealed in next messages -- so any third
party can create valid "signature" on any previous message, that means
that noone can prove that only and only you could be the author of some
exact message. Actually I doubt that there was any occasions where it
(deniability property) helped and was useful to anybody, but it is cool
thing in theory that is practically made :-)
OTR additionally has an additional zero-knowledge authentication scheme
SMP: https://en.wikipedia.org/wiki/Socialist_millionaire_problem
That thing technically is just for comparing two strings, without
revealing their values to the opposite side. For example you start
conversation with somebody without preliminary known public key. Or
possibly someone steals the computer of the buddy and its keys are
compromised. And you decide to authenticate that person by asking
question where the answer must be known only to both of you, something
like "what was I wearing yesterday on my head" (of course it should be
something more serious and less predictable). You and the buddy on the
other side enter the expected answer and SMP protocol checks those
strings equality, without revealing possibly compromised opposite side
the exact value of the answer.
OTR is valuable by the fact that it is very widely supported in
software. Its messages are plain-text ASCII Base64 encoded strings, that
can be sent over *any* text protocol. So you can use OTR over virtually
any text-based message protocol. For example irssi IRC client has its
built-in support and no support from the transport (IM) protocol is
needed at all: if I use irssi with bitlbee with XMPP -- I just use
irssi's built-in OTR support. I am sure that OTR is the most widely
supported online IM protocol (I mean by number of implementations and
client support, not by the absolute numbers, where any WhatsApp/Telegram
will beat it).
The only bad thing about OTRv3 (older version are not used) -- it uses
quiet ancient and slow cryptographic algorithms. That is not the real
problem, but its DH key sizes are only 1536-bits. Well, that still
enough nowadays, especially when we are talking about ephemeral keys,
not the long-term used for years (as in PGP). But more modern IM
protocols with elliptic curve based algorithms will be much more faster
(CPU time) and have much smaller key sizes.
There is very good survey on all modern IM E2E protocols:
https://hardenedvault.net/2021/06/02/vault1317-thesis.html
PGP lacks PFS property -- this is the main disadvantage, plus it has
pretty big overhead per message. OTRv3 is very well known, supported and
still beating beating nearly everybody by its deniability property.
Signal protocol -- *very* good, very modern, very effective and very
respectful from cryptographic point of view. OMEMO, OLM -- they are used
in XMPP (optionally) and in Matrix protocol. I have never seen and used
any XMPP client with OMEMO support, but I heard that many used it for
years. OMEMO seems to be quiet good, definitely better than PGP, except
that it is XMPP-specific and requires all participating XMPP-clients to
support it. OTRv4 should be the coolest one, that took in advance all
experience in E2E protocols development and research, but... its author
is in Equador's prison: https://en.wikipedia.org/wiki/Ola_Bini
OTRv4 draft exists and still developed, but it is backwards incompatible
with OTRv3 and requires many libraries/clients update to support it.
So if you have got OMEMO-compatible XMPP-clients, if you do not need
identity anonymity preserving and deniability properties, do not need
interactive zero-knowledge authentication feature (SMP protocol), then
OMEMO can be recommended, at least for better efficiency. OTRv3 is also
not in favour by many people by its inability to send a message when
opposite party is not online (obviously no ephemeral key establishment
can be done), but OMEMO (like Signal and others) can store pregenerated
ephemeral keys on the server, so other people can still send you the
message while you are temporary offline. But MCabber does not support
OMEMO, so OTRv3 is the remaining choice, really better than PGP.
Sergey Matveev [Thu, 18 Nov 2021 11:30:00 +0000 (14:30 +0300)]
Black утилита для форматирования Python кода
https://black.readthedocs.io/en/stable/
Не знаю буду ли использовать, ибо с ходу не пойму нравится ли или нет.
Но за одно точно сильно импонирую проекту: он предпочитает двойные
кавычки одинарным. В проектах где я участвовал на Python не один год --
предпочитали одинарные. Как мне это не нравилось с самого начала, так и
не нравится: в своих проектах никаких одинарных не приемлю (конечно за
исключением стоящих случаев, когда сильно меньше требует экранирования).
Только написал всё это, как понял что не буду использовать, ибо... ну
это же Python мир, как и Linux -- помойка недоговорившихся между собой
людей. То что делает black, например "data[len_ - 4 :]" не годится
flake8, ибо пробел перед ":".
Sergey Matveev [Thu, 18 Nov 2021 08:03:46 +0000 (11:03 +0300)]
Прочитал "Час Дракона" Роберта Говарда
https://ru.wikipedia.org/wiki/%D0%A7%D0%B0%D1%81_%D0%B4%D1%80%D0%B0%D0%BA%D0%BE%D0%BD%D0%B0
Одна из последних книг про варвара Конана. Дочитал, но не понравилось.
Вся книга из серии: пошёл туда, встретил того, зарубил его, пошёл сюда,
там другого замочил, потом порешал с третьими. Идеально для сериалов с
мускулистым Шварценеггером: короткое видео где действие в новом месте,
где всё решается просто тем что Конан мечом помахает и всех положит.
Плюс аппетитные красивые девицы то тут, то там. Но нет, я не хочу на это
тратить время -- уж лучше бабский фэнтези про ведьму от Ольги Громыко
(69a6c3d8d6610bb16dcf87be95fee87e8d50cc9b).
Sergey Matveev [Thu, 18 Nov 2021 07:58:23 +0000 (10:58 +0300)]
Пример почему я считаю Python говном
Качество Python падает с каждым годом. Искренне задолбали все кто его
упорно превращает в обёртку на Си-шными библиотеками. Но вот у меня
стоит shiny new Py310:
>>> import hashlib
>>> "blake2b" in hashlib.algorithms_available
True
>>> hashlib.new("blake2b").update
<built-in method update of _blake2.blake2b object at 0x800b166b0>
>>> from hmac import HMAC
>>> HMAC(b"foo", b"bar", "blake2b")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/stargrave/local/stow/py310/lib/python3.10/hmac.py", line 60, in __init__
self._init_hmac(key, msg, digestmod)
File "/home/stargrave/local/stow/py310/lib/python3.10/hmac.py", line 67, in _init_hmac
self._hmac = _hashopenssl.hmac_new(key, msg, digestmod=digestmod)
ValueError: unsupported hash type blake2b
Хотя документация явно говорит про hmac.new():
digestmod is the digest name, digest constructor or module for the
HMAC object to use. It may be any name suitable to hashlib.new().
Считанные часы как я использую этот Py310 и он уже вовсю падает. Такое
впечатление, что лучший Python который когда либо существовал это Py27.
Хотел бы сказать что-то про Py35/Py36, но не могу из-за появления в них
async-ов.
Sergey Matveev [Wed, 17 Nov 2021 14:24:36 +0000 (17:24 +0300)]
Как выращивать джунов. eross
https://www.youtube.com/watch?v=BkPCRxuMPtA
https://habr.com/ru/company/oleg-bunin/blog/417409/
Посмотрел тут на фоне выступление Евгения Россинского про свой опыт
выращивания junior-разработчиков.
Что-то у меня в блоге вообще не видел упоминания этого человека. А ведь
после собеседования с ним я сразу понял что хочу работать в его компании
(NetStream, которую купила ivi вскоре)! Честно, даже не представлял что
бывают такие разносторонне развитые люди и мастера организации рабочего
процесса. Это ж просто сущий ад и жопа со всякими ИТ-шниками пытаться с
ними сварить кашу! Но лучше я ничего не встречал как было в
NetStream/ivi. После работы там я понял насколько важен менеджмент. И
вскоре ещё и понял про важность того, что сейчас называют soft skills.
Каждый поход в кабинет Жени -- сильно снимал накопившееся напряжение,
непонимание, убирал тёрки между мной и другими коллегами. Помню что
приходил к нему с одной идеей, полностью в ней уверенный, вообще прям
сомнений нет -- а потом выходишь и даже не осознаёшь что тебя полностью
разубедили и повернули в другом направлении. Вообще не представляю
возможен ли был ivi без этого человека -- по моему он связующее звено
было между всеми технарями).
И очень круто что он преподаёт командную разработку: ибо программировать
в институтах учат, а вот делать это вместе с кем-то ещё -- вообще не
показывают. И выходят у нас типа программисты, которые даже не понимают
зачем нужен VCS.
А с ivi у меня кой какая связь до сих пор ещё есть, ибо я туда своего
друга уговорил устроится, ну и написал рекомендательное письмо, после
которого ему Женя сразу же позвонил. Друг там продолжил мой проект на Go.
А ушёл то оттуда только и только потому что предложили работать с темой
напрямую связанной с криптографией, защитой информации и всем таким
прочим: это всё же моя мечта со школы была.
Очень, кстати, верно Женя заметил что вопрос про высшее образование
очень важен, как ни крути.
Sergey Matveev [Wed, 17 Nov 2021 12:37:31 +0000 (15:37 +0300)]
WindowMaker
https://www.windowmaker.org/screenshots/lumpi-wmaker.png
https://en.wikipedia.org/wiki/WindowMaker
Скриншот сильно напоминает то, что и у меня было на рабочем столе на
компьютере с AMD K6-2 процессором. Считаю конечно полным бредом мерится
красотой оформлений, иконок и всего такого прочего, но красивее чем
WindowMaker всё же ничего не видел. Да, он слизан с Стив Джобсовского
NeXTStep-а, поэтому тут они не первопроходцы, но насколько же это краше
чем macOS любой версии. И XMMS я использовал для "замены" WinAMP-а. И
все эти widget-ы с различной статистикой помню настраивал.
Sergey Matveev [Wed, 17 Nov 2021 10:05:05 +0000 (13:05 +0300)]
ДЦ для суперкомпьютеров Яндекса
https://habr.com/ru/company/yandex/blog/589363/
https://www.opennet.ru/opennews/art.shtml?num=56164
В РФ самая мощная троица суперкомпьютеров у Яндекса. И вентиляцию с
охлаждением (free cooling) проектировал для их ДЦ (и не только для них,
но и для ДЦ в финской Мансале) мой отец.
Sergey Matveev [Tue, 16 Nov 2021 11:24:28 +0000 (14:24 +0300)]
Беспорядок Python
https://drewdevault.com/2021/11/16/Python-stop-screwing-distros-over.html
https://xkcd.com/1988/
Полностью солидарен с автором, что Python за последние несколько лет
стал просто ужасным набором несовместимого дерьма:
Sergey Matveev [Mon, 15 Nov 2021 19:18:51 +0000 (22:18 +0300)]
Посмотрел "Человека на Луне"
https://ru.wikipedia.org/wiki/%D0%A7%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA_%D0%BD%D0%B0_%D0%9B%D1%83%D0%BD%D0%B5_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_1999)
Фильм очень понравился. Джим Кэрри очень впечатлил, ибо тут не совсем
"классические" для него роли -- круто сыграл. Да и про Кауфмана узнал,
про которого есть то там, то сям упоминания.
Но не могу сказать что одобряю его подходы. Скорее он как-раз использует
противные мне: игра на чувствах, шок, провокации. Безусловно это будет
работать с его точки зрения: народ об этом говорит, народ это обсуждает.
Но по мне так это грязные трюки, хотя для них нужен и недюжий ум,
воображение и, видимо, знание людей. Но провокации и обман касающийся
смерти людей (не самого Энди, а той старушки например) -- грязно. Не
перевариваю когда играют чувствами и на чувствах. Наверное это делают
чаще чем я замечаю, но значит умело.
С другой стороны, всякие black metal-ы, goregrind-ы и harsh noise-ы ведь
тоже не редко стараются чем-нибудь шокировать, что-то спровоцировать или
высмеять. Для кого-то я сразу сатанист, раз слушаю Behemoth или Marduk.
А goregrind так ту самую тему смерти и насилия затрагивает. Вот только
честно это признаёт и предупреждает, как правило.
Sergey Matveev [Mon, 15 Nov 2021 19:14:51 +0000 (22:14 +0300)]
Статическая линковка cgo программ
https://www.arp242.net/static-go.html
У знакомого было желание использовать sqlite3 в Go. А для этого с ходу
находятся только C-binding-и. У него на GNU/Linux системе поэтому сразу
исполняемый файл начинает зависеть от динамических библиотек и уже не
портируемый. Но ведь можно же Си программы статически слинковать? Вот и
cgo тоже парой опций можно заставить это пытаться сделать. На GNU/Linux
это правда всё равно под обычными дистрибутивами не тривиально, ибо
соответствующие .a версии библиотек могут не стоять. Но у меня собралось
без проблем и плясок.
Sergey Matveev [Mon, 15 Nov 2021 10:12:37 +0000 (13:12 +0300)]
"Архитектура компьютера" Таненбаума вредна?
https://habr.com/ru/post/589091/
Да пошёл бы автор нафиг с таким заявлением! Без этой книги я бы
неизвестно кем бы был сейчас. До дыр зачитывался и ею и "Компьютерными
сетями" и "Распределёнными системами" и "Операционными системами". Его
книги для меня эталон, который с чистой совестью можно порекомендовать
первым делом.
Sergey Matveev [Sat, 13 Nov 2021 08:48:16 +0000 (11:48 +0300)]
Подпись произвольных данных SSH-ем
https://www.agwa.name/blog/post/ssh_signatures
С 8-ой версии OpenSSH стало возможным ssh-keygen командой подписывать
произвольные данные. Пока аргумент "ничего не придётся дополнительно
ставить" ещё не катит, ибо у меня (а сколько людей у которых ещё более
старые системы или системы где еле-еле добавляется новый софт (zstd то
не везде ещё есть!)) ещё не такой новый OpenSSH. Но то, что есть более
простая замена OpenPGP, действительно, радует. Всякие signify есть из
коробки в OpenBSD, но не в остальных системах.
Sergey Matveev [Fri, 12 Nov 2021 09:49:15 +0000 (12:49 +0300)]
Столяров, конечно, странный
http://www.stolyarov.info/node/265
Есть напрягающий комментарий по поводу git-а: мол автор в 2019-ом не то
чтобы не видел git submodule в природе, но даже не слышал про него.
Довольно странно это, ладно.
Но гневный комментарий о том, что у автора не UTF-8, а KOI8-R и поэтому
редиски те, кто подразумевает что у пользователя будет UTF-8 -- это за
границами разумного. Уж извините, но гореть в аду тем, кто не использует
UTF-8, ибо уже задолбали своими кодировками. Да, мне тоже KOI8-R с его
фишкой по превращению в транслит с отрезанным восьмым битом. Но пока по
моему уже забить все эти пляски с кодировками и всюду и везде требовать
UTF-8, как это и стараются делать в новых протоколах, форматах и софте.
Мельком что-то недавно проглядывал в его книгах и не мало у него
токсичных, совершенно субъективных (пускай с которыми я даже и согласен,
типа недопустимости применения JS в том виде как сейчас) ремарок,
которым совершенно не место в подобных книгах, как мне кажется.
С другой стороны, какие-нибудь темы им поднятые касательно "Linux" vs
"GNU/Linux": https://www.linux.org.ru/forum/linux-org-ru/13575141
мне понятны. Я не на стороне "лагеря Linux", но был бы в ярости, если
*мой* текст переиначили. И я точно так же бы или требовал полного
удаления или никаких правок такого рода. Всё не забуду как в "интервью"
в Теплице Социальных Технологий поменяли касательно ZFS одну штуку.
После этого со мной там дел не имеют :-). Править какие-нибудь опечатки,
стилистические вещи, думаю, допустимо, но чтобы я говорил про "SSL"
например -- такого быть не может, если только в качестве исторического
экскурса.
Хотя я нередко вообще употребляю просто GNU, ибо часто ли вообще имеет
значение какое конкретно ядро используется? Ведь есть же Debian с ядром
kFreeBSD, что типа вообще ни капли ни "Linux", но пользователь и не
заметит разницы, ибо он работает в GNU окружении.
Но это всё, конечно, не отменяет что для введения (в программирование)
его книжки выглядят неплохими.
Sergey Matveev [Fri, 12 Nov 2021 08:33:08 +0000 (11:33 +0300)]
GoboLinux
https://en.wikipedia.org/wiki/GoboLinux
https://news.ycombinator.com/item?id=29186222
Из комментариев к "I'm still afraid to use spaces in file names years
old" статье (прочитать не могу её, ибо на Twitter) узнал про
существование GoboLinux, в котором для каждого пакета своя директория и
свой Compile для сборки, прямо как в slashpackage
(f25380e9842d68f2f9ecce0d530db90903eeb66b). И сделали они это очень
давно уже.
Но проблемы с пробелами в путях -- действительно проблемы. Я очень часто
понимаю, при написании shell скриптов, что тут он не будет работать если
появится пробел. Но если скрипт пишется для себя или предполагается
чисто программерский контекст, то не парюсь. Хотя и не хорошо это
конечно и стоило бы рефлекторно стараться писать всё безопасно. Но если
от кириллицы в названиях файлов я как-то меньше стал избавляться (torn
утилита), то от пробелов всегда, через zmv '*' '$f:gs/ /_'
(124141d2c195839c86dcfc7ffcb7c21db922e427) -- меньше головной боли.
Пишут что и "Program Files" в Windows специально назван с пробелом,
чтобы заставлять программистов не забывать о них и писать корректно
работающий софт.
Sergey Matveev [Fri, 12 Nov 2021 07:30:04 +0000 (10:30 +0300)]
Прочитал "Апельсиновую девушку" Юстейн Гордера
https://www.litmir.me/br/?b=10407&p=1
Ну интересная история любви, рассказанная в виде письма умершим отцом
своему сыну. Заканчивающуюся размышлениями стоило ли всё это, стоит ли
жить мимолётно. У меня нет чёткого мнения касательно отца этого парня,
и стоила ли его жизнь, но не позавидую второму мужу его матери. Она
встречалась, как вышло в конце книги, с двумя одновременно. Одному
говорила что "да так, в машине сидел никто". Как только, видимо, стало
понятно что она подцепила на свой крючок другого, то ушла от своего
текущего. Как только он умер (к кому она ушла), через дюжину лет -- то
вернулась назад. То, что я называю запасным планом. И ему ещё
воспитывать не своего ребёнка. С другой стороны... всё же она родила ему
и его собственную дочь, что выглядит не так уж жалко вроде бы. А так то
я уже давно знаю, что если девушка говорит что у неё никого нет, то это
запросто может означать "могу уйти от своего когда угодно, как захочу".
Sergey Matveev [Thu, 11 Nov 2021 20:08:26 +0000 (23:08 +0300)]
Малогалоталотим
https://zen.yandex.ru/media/chitayvsegda/moia-liubimaia-kniga-detstva-o-kotoroi-nikto-ne-znaet-5fa4fa618eb5b23a305a5bf8
http://www.stargrave.org/photoes/eye.jxl
http://www.stargrave.org/photoes/eye.preview.webp
В прошлом посте вспомнил что в детстве "Чарли и шоколадная фабрика"
нравилась. Но всё же вне конкуренции любимейшей книгой тех времён
остаются "Звёздные приключения Нуми и Ники", о которых упоминал в ba901e97207bcfed1dfa0f2286d471fc71cc912a. По ссылке есть фотография
твёрдой обложки книги -- именно такая у меня и была. Её читал отец,
потом привёз в Калининград, откуда мамина сестра до сих пор помнит
название существа на котором они путешествовали (Малогалоталотим), потом
уже я зачитывался в детстве.
Даже картину рисовал с кучей сцен из этой книги. Сохранился скан в
небольшом разрешении её. Помню до сих пор некоторые вещи из неё: в
центре это "смотровое окно" Малогалоталотима на Землю; слева от него
котёл (вроде бы что-то типа желудка Малогалоталотима), подсвеченный
атомными фонариками, в котором еда впитывается через кожу; справа сам
Малогалоталотим летящий в космосе; ниже -- он же, стоящий на земле,
выглядящий тыквой. Ещё какие-то существа у которых вроде бы звёздочки
какие-то играли роль валюты.
Sergey Matveev [Thu, 11 Nov 2021 20:00:54 +0000 (23:00 +0300)]
Критика "Чарли и шоколадная фабрика"
https://ru.wikipedia.org/wiki/%D0%A7%D0%B0%D1%80%D0%BB%D0%B8_%D0%B8_%D1%88%D0%BE%D0%BA%D0%BE%D0%BB%D0%B0%D0%B4%D0%BD%D0%B0%D1%8F_%D1%84%D0%B0%D0%B1%D1%80%D0%B8%D0%BA%D0%B0_(%D0%BF%D0%BE%D0%B2%D0%B5%D1%81%D1%82%D1%8C)#%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F
Оказывается на эту книгу есть куча критики, мол вообще чуть ли не запрет.
Да они офигели! Это одна из самых крутых книг что я читал в детстве и
некоторые части (особенно названия кнопочек в стеклянном лифте)
перечитывал не раз. Критика описывает вещи, о которых я, как ребёнок,
вообще не задумывался даже задумываться. Мне были интересны все эти
технологии и приключения, ничего больше! Хотя было понимание перегибания
палки Вилли Вонкой, даже ужасание.