Sergey Matveev [Mon, 15 Feb 2021 16:32:51 +0000 (19:32 +0300)]
Невероятно сколько времени страдал с man-ами zsh
А оказывается то там вся документация в Texinfo, который без проблем
генерирует Info! Какого чёрта я не смотрел есть ли другой формат кроме
man? Ведь документация по zsh ОГРОМНА и очень сложно в ней находить
многие вещи, когда нет ничего кроме поиска по регулярке.
Sergey Matveev [Mon, 15 Feb 2021 14:06:52 +0000 (17:06 +0300)]
Зарелизил goredo 1.3.0
https://lists.cypherpunks.ru/pipermail/goredo-devel/2021-February/000008.html
Теперь передаю через временный файл список целей для которых OOD уже
вычислен и они априори известны что протухли. Должно помочь при огромном
количестве OOD решений и целей. Ну и добавил redo-sources, redo-targets
и redo-ood команды. Для чего их использовать -- не знаю, но люди как-то
вроде используют. На этом TODO для goredo у меня пуст.
Sergey Matveev [Mon, 15 Feb 2021 13:49:33 +0000 (16:49 +0300)]
Посмотрел "Пассажиров"
https://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%81%D1%81%D0%B0%D0%B6%D0%B8%D1%80%D1%8B_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_2016)
На самом деле ещё штуки четыре всяких фильмов за последнюю неделю, но о
них и писать не хочется. А Пассажиры понравились даже очень. Конечно,
инженеру болезненно смотреть на многие моменты в фильме, но да и фиг с
этим, всё ж не Гравитация. Особо никакой глубокой мысли то в фильме нет
(кроме главного поступка героя), как и хитрого сюжета, да и череды
абсолютно невероятных совпадений. Но удовольствие большое получил!
Зауважал Криса Прэтта как актёра. Не в том плане, что я к нему негативно
относился прежде, но просто знал его исключительно по комедийным ролям.
И Дженнифер Лоуренс то впервые увидел.
Sergey Matveev [Mon, 15 Feb 2021 13:44:47 +0000 (16:44 +0300)]
Прочитал "Продавца случайных чисел"
https://lleo.me/arhive/2014/prodavec.htm
Понравилась основная идея рассказа, про то, что источники энтропии нужно
искать, мол всякие счётчики Гейгера не подходят для больших масштабов. А
сами числа то эти используются в синтезаторах (еды и прочего). Ну и есть
немного антиутопии, когда люди уже не вступают в брак, а подбирают себе
партнёра ровно на один вечер, просто парой кликов.
Sergey Matveev [Fri, 12 Feb 2021 13:25:20 +0000 (16:25 +0300)]
Оценка людей полезности и продуманности архитектуры софта
Недавно один знакомый вбросил фразу что типа "vi редактор архитектурно
был непродуман" (в отличии от Emacs или (возможно) Vim). Мол что-то
расширить в vi нельзя, а в Emacs/Vim, в которых есть встроенный язык и
редактор строящийся прямо на нём (про Vim я бы тут поспорил на самом деле).
Фраза и эта мысль меня задела тем, что это как-то не очень честно
обвинять в том, что вообще не предполагалось и каких задач не ставилось.
Вообще обижаться тут не на что само собой -- просто у людей есть
принципиально разный взгляд на мир и вещи в нём.
С одной стороны: есть конкретная текущая задача, которую нужно
выполнить. Это можно сделать быстро и качественно, но решение возможно
совершенно не впишется в чуть изменённые условия/требования
использования в будущем. Можно подумать о расширяемости и гибкости, что
возможно в будущем может помочь. С другой стороны: проектированием и
придумыванием можно заниматься хоть 100% времени, так и не начав делать
работу или так и не предоставляя законченного готового варианта, хорошо
решающего задачу. Как всегда, нужна золотая середина.
Я бы на месте Билла Джоя поперхнулся от заявления об архитектуре vi. Ему
надо в кратчайшие сроки написать удобный и достаточно функциональный
редактор. Не годами пилить какой-нибудь Emacs, а за неделю сделать
редактор (говорят что именно за это время он и был написан) чтобы дальше
заниматься исключительно BSD ОС. Причём редактор достаточно маленький
(говорят, 100-1000 раз меньший по размеру чем Emacs) и не требовательный
к ресурсам. С этой задачей Джой справился так хорошо, что, по сути, до
сих пор именно как редактор всё равно vi(m) с его модальностью мощнее.
Насколько по разному могут смотреть на мир люди из одной отрасли! А ведь
рядом всегда сможет найтись человек который скажет что любая
BSD/whatever это полный непродуманный fail, ибо где тонны прибыли
которые можно грести лопатой?
Но вот GNU/Linux экосистема для меня выглядит в целом именно как
экосистема framework-ов и конструкторов. Почему то на ум первым делом
приходит eBPF, который в теории (ну и по функциональности уже заложенной
в ядре) может больше чем DTrace... но *готовых* решений дотягивающих
хотя бы до DTrace уровня так и нет. Сколько всего придумано касательно
изоляции процессов, но ничего настолько удобного и простого типа Jails
(или Solaris Zones/Containers), говорят, до сих пор так и не было.
Ну и желание постоянно всё делать на будущее, на расширяемость это
запросто ведёт и к такому недугу как "ООП головного мозга". Когда
простейшие вещи в коде превращаются в адовый ад для понимания и
поддержке. Я реально встречал код на PHP где на 200 строк кода, не
считая комментариев, делается GET значения из Redis.
Rust, было время, каждую неделю всё так сильно менял в языке что
буквально hello world бы не собирался. До сих пор в README регулярно
встречаю упоминания что нужна такая и только такая версия Rust для
работы такого то софта. Изначально в Rust был даже garbage collector,
потом не стало. Для меня это пример того, как люди просто пилят и
придумывают ради пиления и придумывания -- без какой-либо цели или
вообще понимания что они хотят.
Тогда как в Go почти 15 лет прошло с момента предложения внедрения
generic-ов до его одобрения. Сейчас вот, программируя на Си, не могу не
удивляться огромному количеству продуманных (сверх продуманных) мелочей
по сравнению с Си. Вчера обнаружил что в Си нельзя делать "a, b = c, d;",
что оказалось дико неудобно и уродует код временными переменными.
Собственно сам Go то это результат трудов ещё с начала 90-х, кучки
хакеров.
OpenSSL своими EVP предполагает простую и лёгкую расширяемость за счёт
нечто похожего на интерфейсы. Идея может быть и хорошая, но по факту
внутри OpenSSL всё равно сплошные сплошные "if algo == ..." исключения,
равномерно распределённые по всему коду. Впечатление что изначально
хотели и планировали как лучше, а потом плюнули на всё и просто лишь бы
как, хоть бы как, но сделать задачу, пускай и не красиво. Наверное
худший из вариантов (среди "всё на коленке, да побыстрее, здесь и
сейчас" и "надо годами подумать, классическим waterfall, только потом
начинать"). Тогда как в Go, другая крайность касательно криптографии и
TLS реализации: никакой расширяемости со стороны библиотеки. И
действительно -- так ли она нужна? Может лучше сделать что-то
*существенно* более простым, экономить годы проектирования, но
удовлетворить 99% пользователей ПО, чем тратить кучу ресурсов ради
оставшихся (для них проще сделать fork или отдельное ПО), и крайне редко
что не испортив в целом всё остальное (как минимум, сложностью).
Хех, чисто случайно сейчас увидел новость
https://lenta.ru/news/2021/02/12/svetlakov_badcomedian/
(про BadComedian ничего не знаю, какие фильмы обсуждаются не знаю, но
наверное комедийные, раз Светлаков), где Светлаков верно заметил что:
Этот фильм едет на Канны или это хорошее развлекательное кино,
создающее настроение на праздник?
Ибо тоже не раз слышал критику фильмов, как будто они ориентировались на
Канны(-like). А простая лёгкая комедия тоже нужна. У неё другая задача.
И оценки нужны к ней отдельные.
Или мне этот же знакомый говорил что PyDERASN плохо спроектирован, ибо
он не предусматривает потоковую обработку данных (сейчас это не совсем
так, но только недавно появилось). Мудро конечно просто проигнорировать,
а не оправдываться. Но меня удивляет что человек с опытом продолжает
делать такие оценки (+оценка архитектуры vi). PyDERASN писался так: за
две недели отпуска успеть полностью его сделать и перевести на него
проекты. Если не успеть -- всё насмарку, ибо по вечерам такой проект я
бы не мог пилить, ибо нужно много чего в голове держать и помнить и
поэтому нужно наброситься и растерзать проблему до конца. Если не
перевести проекты, то варианта держать параллельно что-то на pyasn1, а
что-то на pyderasn -- не вариант. Можно PyDERASN вообще было бы не
делать -- но тогда для Python банально просто отсутствовала бы *строгая*
и удобная (с нужным функционалом) DER библиотека. И получается, что или
продолжать бы жить без качественной строгой удобной библиотеки с
некоторыми нужными возможностями без костылей (типа .offset), ибо из-за
проектирования на разработку бы не хватило бы времени (а бизнес не
требует наличия таких библиотек и не стал бы оплачивать время на её
разработку), либо иметь такую, но в которой нет возможности потоковой
обработки... которая до сих пор никому не нужна на практике в решаемых
на работе задачах (ибо размеры данных небольшие и всё всегда в памяти
легко уместится).
Кто-то бы мог заявлять что GoVPN, NNCP, goredo, whatever -- непродуманны
ибо не запустятся, или содержат что-то *принципиально* не совместимое,
на Windows. Я скорее задумаюсь о вопросе возможности их работы на Plan9,
чем о мобильных устройствах и проприетарных системах.
И до сих пор я не знаю по каким критерием меня оценивал один бывший
коллега, заявляя что я вообще вредил. У меня в голове на весах есть
только одно: либо полностью не сделанная задача (для бизнеса -- тоже
вариант, не фатальный, терпимая потеря прибыли), либо сделанная как это
только возможно хорошо в те сжатые сроки (с 8 до 19 фигача и фигача не
останавливаясь, с перерывом только на обед). Я бы мог вообще отказаться
её выполнять -- никто не заставлял. Даже сделанные коммиты -- вообще
никуда не надо бы было вливать или с чем-то мёржить, ибо они актуальны
только для конкретной инсталляции.
Но похоже тут настолько разное мировоззрение у людей и разные подходы,
что состыковаться не получится, компромиссов не найти. Как категорически
разные взгляды в религии, политике, истории и подобном могут быть
непреодолимым барьером. Но если разумные люди на работе не поднимают и
останавливают подобные темы (ибо какое они имеют отношение к работе?
могут только навредить, но не улучшить отношения), то когда встретятся
два человека, один из которых считает что hello world нужно писать как
"master programmer" (bc48396c84d164d4b892a5f833cc738683c22049), а
другой... иначе, то я не знаю как тут можно им будет работать сообща.
Sergey Matveev [Fri, 12 Feb 2021 08:40:45 +0000 (11:40 +0300)]
Newsboat потребление памяти
Сегодня внезапно увидел что newsboat после обновления feed-ов у меня
может выедать под полгигабайта оперативной памяти. И оно только растёт и
увеличивается. Особо это не проблема -- можно выйти/войти и всё равно
читать статьи, но держать постоянно его запущенным, чтобы он
автообновлялся, уже не так приятно, ибо приличный объём RAM теряется в
пустую. Возможно более поздние версии и не имеют такой проблемы, но они
написаны на Rust, что автоматом не рассматривается.
Sergey Matveev [Wed, 10 Feb 2021 22:45:11 +0000 (01:45 +0300)]
Человек устал от anti-Rust дерьма
https://www.boringcactus.com/2021/02/09/anti-rust-horseshit.html
Что общего между "anti-vaxxers, flat earthers, 9/11 truthers" и
anti-Rust-er-ами? Начало радует. Но нет, автор, Rust дерьмо.
Нет, не потому что я "spent 5 minutes installing it, realized that
something was — gasp — different than C", а потому что я потратил неделю
на его сборку (и то не вышло под FreeBSD) на машине с 128GB RAM. Ведь
его авторы чихать хотели на то чтобы его можно было собрать из
исходников? Мол качайте бинарники наши. Это дерьмовый подход. Из серии
"и так сойдёт", "на отвали". Собирал то изначально для bootstrap-а
проект вообще сторонних людей mrustc.
И он дерьмо потому что безумно переусложнённый. Какие проблемы Rust
решает? Ой, да пофиг на вашу memory safety. Главная проблема --
сложность. Почти все проблемы в софте -- из-за сложности понимания,
сопровождения, написания, отладки, и т.д.. Вот Go отличный пример
продуманной простоты. А Rust -- пример как взяли перманентно
усложняющийся C++ и ещё круче навернули поверх него всяких фич. Это
дерьмовый fail. Rust это пример как люди совершенно не учатся на своих
ошибках (C++).
А главное что автор не понимает: Rust это замена C++, но никак не C
(откуда он берёт такую идею?). Собственно, почти со всеми аргументами
Drew DeVault-а я и согласен:
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
Среди всех хакеров кого читаю, среди любителей suckless и вообще Си,
среди людей из TUHS рассылки: никто не смотрит на Rust, как и почти
никто не смотрит на C++. А вот Go у всех в почёте.
Никто не спорит что в идеале бы вообще писать на формализуемых языках
только, формально доказываемые решения. Coq и прочее. Само собой и
memory safety это тоже хорошо. Вот только в мире нужно решать задачи за
*вменяемую* и разумную цену.
Sergey Matveev [Wed, 10 Feb 2021 22:32:39 +0000 (01:32 +0300)]
Познаю программирование на zsh
http://www.git.stargrave.org/?p=dotfiles.git;a=commitdiff;h=d0382ac857db24d7b72bf60c77e347596e9c7e52
Сам zsh то я использую уже давным давно, но как интерактивный shell. Но
со временем скриптов касающихся использования только в его контексте всё
больше становится и надо бы его начать познавать.
Вообще zsh мне нравится даже мелочами: оформлением документации,
примерами, подходом ко всему. Впервые начал использовать его массивы и
ассоциативные массивы. В POSIX shell в принципе этого нет и из-за этого,
думаю, самое большое количество проблем и ненависти к нему -- все эти
переменные которые раскрываются внезапно во что-то неожиданное для
человека. В zsh с этим всё очень непривычно тем, что вот указал команде
переменную одним аргументом... и действительно это будет один аргумент в
котором будет значение переменной. В переменной находятся звёздочки? Ну
значит и будут они подставлены, а не раскрыты автоматом как это штатно
бывает. Огромное количество всяких штук по подстановкам и изменениям
переменных -- куча кода экономится и куда надёжнее работает. Сколько бы
проблем исчезло с подобным shell! Точнее, насколько понимаю, в основном
тема про массивы и корректные (не)раскрытия переменных это заслуга ksh.
Конечно скрипты придётся писать на POSIX shell, никуда не деться. Но для
личных и zsh-only нужд, его возможности очень и очень приятны и круты.
Когда люди сравнивают FISH с zsh-ем, то учитывается только какая-то
мизерная интерактивная составляющая от всех возможностей всего shell-а.
Просто нужно явно отмечать, что сравнивается только интерактив, который
в у FISH много чем интересен и его основные фичи в видел плагинов
появились и в zsh, которые я активно использую
(31ee58d93e7e049a4dea93901180b77addb69398).
Sergey Matveev [Wed, 10 Feb 2021 19:38:42 +0000 (22:38 +0300)]
Zsh guide юмор
http://zsh.sourceforge.net/Guide/zshguide03.html
Вообще в нём очень много юмора и забавных высказываний и просто хороших
пояснений. Например:
While we're at it, why do blocks starting with `if' and `then' end
with `fi', and blocks starting with `case' end with `esac', while
those starting with `while' and `do' end with `done', not `elihw'
(perfectly pronounceable in Welsh, after all) or `od'? Don't ask me.
[...]
if [[ -z "$var is sqrt(`print bibble`)" ]]; then
print Flying pig detected.
fi
[...]
The word `clobber', as in the option NO_CLOBBER which I mentioned in
the previous chapter, may be unfamiliar to people who don't use
English as their first language. Its basic meaning is `hit' or
`defeat' or `destroy', as in `Itchy and Scratchy clobbered each
other with mallets'. If you do:
Sergey Matveev [Wed, 10 Feb 2021 16:02:13 +0000 (19:02 +0300)]
perl -lane
У awk удобный способ задания какие колонки текста и как надо
распечатать. cut не будет ему заменой (даже учитывая 162386cf9a9eb0fb4237c48a7e3862f3ef8a8c60), ибо он не может нормально
переставить колонки местами или иметь негативную нумерацию колонок. perl
конечно же всё это может, но я не знал про "-a" опцию, которая автоматом
делает split $_ в @F. А "-l" автоматом позволит сделать newspace на
выходе удобно. В итоге распечатка последней, а дальше со второй по
четвёртую колонки можно сделать так: perl -lane 'print "@F[$#F, 1..3]"'
Я и про возможности указания индексов массива то забыл уже в нём. А
разделитель можно указать через "-F" (-F: например).
Всё же Perl очень крут в плане удобства и возможностей.
Часто стал видеть в разных примерах использование say вместо print. В
книгах которые читал -- say не припомню. Отличается тем, что добавляет
перевод сразу. Но он является некой (тут я уже не понимаю) опциональной
фичей и поэтому просто "-e" не сработает. perl -anE 'say "@F[$#F, 1..3]"'
Sergey Matveev [Wed, 10 Feb 2021 15:14:31 +0000 (18:14 +0300)]
Суровая правда о разработчиках и разработке
https://habr.com/ru/post/541810/
В принципе солидарен со всем сказанным, что ИТ отрасль тянет многое на
дно. Но мне кажется, что в первую очередь это связано с увеличением
количества в неё вовлечённых, далеко не самого высокого уровня (ага,
даже я впервые связанный список использовал и второй раз в жизни
задумывался о сложности алгоритма -- только вчера). "Моё разочарование в
софте" (bb09bd6fb88009c4db4caf0e8372bbde38a56701) из этой же серии.
Автор статьи, пишет, что работает 15 лет в ИТ сфере. Как и я. Но я не
готов говорить о том что же надо делать.
Sergey Matveev [Tue, 9 Feb 2021 17:48:45 +0000 (20:48 +0300)]
Впервые в жизни использовал связанные списки
Знаю что это база для программиста, присутствующая в любой книге, но на
практике я только сейчас столкнулся с этой штукой. Точнее столкнулся с
необходимостью написать свой собственный аллокатор памяти на Си, в
котором связанные списки применяются. Совсем ничего опыта в Си, а уже
надо такими вещами заниматься.
Sergey Matveev [Tue, 9 Feb 2021 13:12:45 +0000 (16:12 +0300)]
Про театр безопасности
https://soatok.blog/2021/02/09/crackpot-cryptography-and-security-theater/
Различные примеры того, как люди несут всякий бред, а журналисты ещё и
превращают в совершенно несуразные заявления.
Sergey Matveev [Tue, 9 Feb 2021 08:52:47 +0000 (11:52 +0300)]
C editing with Vim HOWTO
http://www.faqs.org/docs/Linux-HOWTO/C-editing-with-VIM-HOWTO.html
Очень короткий howto, но показывающий прям самые базовые команды которые
помогут именно и в первую очередь при редактировании Си кода. Я вот не
сразу догадался использовать "[[" и "]]" в нём. Точно полезный документ
для тех кто не в курсе про ctags, gd и даже "%".
Sergey Matveev [Sat, 6 Feb 2021 23:37:00 +0000 (02:37 +0300)]
Посмотрел "Под кайфом и в смятении"
https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B4_%D0%BA%D0%B0%D0%B9%D1%84%D0%BE%D0%BC_%D0%B8_%D0%B2_%D1%81%D0%BC%D1%8F%D1%82%D0%B5%D0%BD%D0%B8%D0%B8
Один из фильмов про которые даже и писать не хотел что посмотрел.
Хорошие отзывы. Сам Тарантино считает что он в 20-ке лучших фильмов. Я
так и не понял где и чем. По сути весь фильм я мог бы только зевать.
Можно сказать что пожалел потерянного времени. Единственное что вызывало
положительные чувства это увидеть молодых Йовович, МакКонахи и
Зеллвегер, которых прежде такими не лицезрел. Особо то и плохого ничего
не могу сказать, кроме того, что и хорошего и интересного нет. Просто ни
о чём фильм для меня. Что хотели показать? Что передать? Что интересного
рассказать? Банальная скукотища.
Sergey Matveev [Sat, 6 Feb 2021 23:21:05 +0000 (02:21 +0300)]
Посмотрел "Догвилль"
https://ru.wikipedia.org/wiki/%D0%94%D0%BE%D0%B3%D0%B2%D0%B8%D0%BB%D0%BB%D1%8C
Офигеннейший фильм! Хочется написать про то как то, да сё верно, как
крута концовка и размышления в ней. Как точно всё подмечено и показано о
людях, в самую точку. Но, во-первых, много чего можно написать и чуть ли
не пересказать фильм и мысли которые у людей и сами дойдут. А, во-вторых,
у меня что-то нет уверенности что другие воспримут его точно так же как
и я и будет одно мировоззрение и выводы. Те тезисы которые бы были для
меня очевидны -- наверное могут быть восприняты совершенно иначе другими.
В общем -- очень круто! Если множество других фильмов о которых я пишу
мне действительно нравятся, очень (а о тех кто не нравится, даже и не
упоминаю, чаще всего), то это вызывает восторг. Откладывал его, ибо
целых три часа идёт. И на половине фильма были сомнения а не закончится
ли какой-нибудь туфтой. Но нет, три часа стоили того!
Sergey Matveev [Sat, 6 Feb 2021 10:19:24 +0000 (13:19 +0300)]
Посмотрел "Таксиста"
https://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%BA%D1%81%D0%B8%D1%81%D1%82_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_1976)
Очень понравился фильм! Скучно не было нигде. Концовка... неожиданна и
настолько, что, думается, вымышлена в голове таксиста. Но Де Ниро с
ирокезом это круто!
Sergey Matveev [Sat, 6 Feb 2021 08:37:37 +0000 (11:37 +0300)]
В TUHS рассылке обсуждают ZFS и вообще дизайн Unix систем
https://minnie.tuhs.org/pipermail/tuhs/2021-January/022797.html
https://minnie.tuhs.org/pipermail/tuhs/2021-February/022981.html
В этой рассылке всякие хакеры есть, включая и Кена Томпсона и Роба
Пайка, временами там что-то пишущих. И куча людей которые даже с 80-х
принимали участие в написании Unix систем.
Дошла речь про ZFS. Все признают и понимают что тема с кэшом и
управлением памятью в ZFS -- особенная. ZFS не "дружит" с page cache
ядра, что приводит к может приводить к двойному использованию памяти при
mmap операциях (часть оседает в page cache ядра, а часть в ZFS ARC). Все
понимают что это не красиво, но это была цена за простоту разработки.
Но, никого не находится кто бы сказал что "ZFS не нужна". Для всех это
единственная ФС которой можно доверить целостность данных. btrfs не
считается пригодной к использованию (стабильность, надёжность). Поэтому
ZFS есть за что не любить, но деваться, мол, некуда -- всё равно это
лучшее. И в принципе то проблема с page cache не является не решаемой --
просто кто-то должен исправить ситуацию кодом. Но, похоже, ZFS
достаточно хорошо удовлетворяет нужды, что особо никто не чешется в эту
сторону.
Sergey Matveev [Fri, 5 Feb 2021 20:45:07 +0000 (23:45 +0300)]
Самый страшный монстр -- хриссалид
https://www.ufopaedia.org/index.php/Chryssalid
Что-то вспомнил статью в одном старом журнале про топ самых страшных и
нелюбимых монстров из компьютерных игр. Там и краб из Half-Life был и
Кибердемон из Doom. И где-то в топе был хриссалид. И для меня это
действительно самый самый страшный монстр в играх. Его дикое количество
очков действия, его мощные укусы, от которых и танки сразу же ломаются,
и его способность превращать в зомби трупы, из которых в последствии
новые хриссалиды появятся -- вызывают всегда панику. В XCOM-е всегда
если я завидел эту тварь, но бросал всё всё всё и ломился всеми
доступными людьми и танками чтобы побыстрее угробить её! А он же ещё и
живучий. Помню что применял бластеры, которые выносят полэкрана мощным
взрывом, снося жилые дома и их обитателей, лишь бы прикончить
единственного хриссалида.
Ну и конечно же есть другой монстр -- груй (grue). Тот самый что в
Zork-ах и других interactive fiction играх есть. Он настолько страшен,
что никто не может описать как он выглядит. Ибо если встретился с ним,
то не выживешь. Благо, обитает только в тёмных местах и если есть
источник света, то боятся нечего.
Sergey Matveev [Fri, 5 Feb 2021 15:34:29 +0000 (18:34 +0300)]
Навальный и прочие либералы
В новостях время от времени новости из суда показывают и у меня дежавю
сильнейшее. Читая высказывания этой мрази, у меня в голове вопрос:
причём тут это то? Сильнейшее ощущение что совершенно невменяемый
человек, любой разговор с которым всегда и всегда сводится только к
политике и к тому, что у него, мягко говоря, мания величия, и Путина он
обидел и ему вокруг все козни только и делают. О нём ведут речь об
одном, вообще совершенно толком то не связанном с политикой, а он
умудряется её как-то приплетать.
Почему дежавю? Потому что всё не забуду общение с либертарианской
партией, где каждое моё предложение с их стороны сопровождается "на
самом деле, я (stargrave) хотел сказать..." и понеслась тема того, как
плохи силовики и всё такое прочее. Facepalm и попытка ответить про себя
на вопрос "да при чём тут это и как мы вообще пришли к этому?". Даже
забавно. Неужели страны НАТО не могли кого повменяемее и получше нанять?
Стыдобище и позорище.
Sergey Matveev [Fri, 5 Feb 2021 13:01:52 +0000 (16:01 +0300)]
Ребёнок в снежном туннеле
https://lenta.ru/news/2021/02/04/snow/
http://mds-club.ru/cgi-bin/index.cgi?r=84&lang=rus&sbr=2&user=1688&filter=0&article=0&posits=0&sortby=20&search=
Вчерашняя новость и что забавно: буквально вчера я ведь вечером "читал"
(слушал аудиокнигу) "Снежные ходики", где 12-летний пацан перемещается
во времени и встречается со своим отцом и сыном, где все они заплутали
в снежных туннелях. Ну главное что в жизни у школьника всё благополучно
закончилось!
Sergey Matveev [Fri, 5 Feb 2021 09:04:26 +0000 (12:04 +0300)]
cut -w
Обнаружил что BSD cut утилита имеет "-w" опцию, которая использует
whitespace последовательность, в качестве разделителя. awk был приятен
тем, что колонки могут разделяться разным количеством whitespace-ов, и
он по умолчанию делает "\s+" аналог разделителя. cut -w -- тоже. POSIX,
к сожалению не имеет этой опции.
Ну и GNU cut не имеет. С одной стороны удивлён -- они же любят добавлять
тьму всяких фич не стандартных. С другой стороны -- не удивлён, ибо
удобство пользователя это не про GNU/Linux.
Sergey Matveev [Wed, 3 Feb 2021 13:40:43 +0000 (16:40 +0300)]
Cloudflare и TCMalloc
https://blog.cloudflare.com/the-effect-of-switching-to-tcmalloc-on-rocksdb-memory-use/
Интересная статья про то, что просто смена memory allocator-а (с Glibc
на TCMalloc) может в 2.5 раза сократить потребление памяти. FreeBSD
кстати использует jemalloc, который вроде как дружелюбен к многопоточным
приложениям.
Sergey Matveev [Wed, 3 Feb 2021 09:55:30 +0000 (12:55 +0300)]
Bluetooth trackball
https://blog.jfedor.org/2021/01/bluetooth-trackball-mark-ii.html
https://blog.jfedor.org/2019/06/bluetooth-trackball-with-all.html
Какой интересный трэкбол: состоит только из одного шарика, внутри
которого акселерометры, аккумулятор, Bluetooth передатчик, беспроводная
зарядка. Меня правда смущает симметричность полости и наверняка смещение
центра тяжести начинки. Или она достаточно лёгкая чтобы не замечать
этого. Или всё учтено. Но в любом случае мне нравится. Большой шарик это
тема! У меня Kensington Expert с одним из самых больших шариков -- но я
уверен что не прочь и ещё большего.
Sergey Matveev [Wed, 3 Feb 2021 08:27:14 +0000 (11:27 +0300)]
vim --remote
Я давным давно знал что gvim является сервером к которому можно
отправлять команды через обычные вызовы vim команды. На одной работе
руководитель в urxvt мог клацнуть мышкой на Python traceback или имени
файла:строке и у него отправится команда в его запущенный gvim на их
открытие.
Оказалось, что это прекрасно и без проблем работает и просто с обычным
vim, хоть и использует средства X11 (как и буферы обмена требуют его
поддержки). Как будто открывается тьма новых возможностей, особенно с
учётом возможности fzf выполнять любые команды! Напоминает plumbing из
Plan9. Хотя в Emacs, само собой, всё это (как и fzf-like вещи) есть уже
четверть века.
А в fzf и его vim-плагине просто тьма hardcode-а (даже внутри Go кода)
не только bash-измов, но и вообще вызова bash. Я вот удивляюсь: куча
пользователей fzf, как мне кажется, это всякие хипстеры с zsh-ем. И всем
нормально рядом держать bash монстра? У меня то из-за этого и в Vim fzf
для файлов не работает. Что-то профиксил, а на кучу остального просто
лень уже тратить время.
Sergey Matveev [Wed, 3 Feb 2021 07:55:44 +0000 (10:55 +0300)]
Немецкая полиция имеет право на распространение троянов
https://www.ccc.de/en/updates/2011/staatstrojaner
http://news.dieweltistgarnichtso.net/bin/redo-sh.html
Автор redo.sh у себя делает заметку о том, что у них легально разрешено
вставлять зловред в передаваемую информацию. Поэтому нужно проверять PGP
подписи у скачанного софта.
Sergey Matveev [Tue, 2 Feb 2021 21:26:33 +0000 (00:26 +0300)]
fzf
https://github.com/junegunn/fzf
В дополнении к 77ede978e9c24bc8e68ee4e900b9dc5bf94b29f6 попробовал снова
fzf. Всё же штука похоже будет мною использоваться. Как минимум, для
выбора единственного файла для вставки -- вполне себе быстра, экономит
мышку. Совершенно не помню пробовал ли я fzf с интеграцией с zsh. Но
делается легко, говнокода не вижу особо нигде.
Sergey Matveev [Tue, 2 Feb 2021 19:02:57 +0000 (22:02 +0300)]
RISC-V возможно не так хорош, как вы думаете
https://sporks.space/2021/02/01/risc-v-isnt-as-interesting-as-you-think/
https://lobste.rs/s/icegvf/will_risc_v_revolutionize_computing#c_8wbb6t
https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68
https://lobste.rs/s/yqqhxu/llvm_for_m68k_completed_not_merged
Мне вот со школы очень нравилось читать про процессоры, их команды и
прочее. Ещё в школе хотел иметь в будущем Macintosh, потому что в нём
RISC процессор, а не этот CISC уродский. Позже Mac-и стали x86. Теперь
вообще что-то закрытое и страшное.
Всегда нравились MIPS, SPARC. Наслышан про сложность аппаратной
реализации из регистровых окон. Да и есть у многих сомнения в их
реальной пользе и эффективности. ARM-ы никогда не прельщали чисто
эстетически. Хотя я и не прочь бы пересесть на какой-нибудь ARM64, будь
они вовсю доступны и неплохи по производительности. Был под впечатлением
от Alpha, хотя, с точки зрения инструкций, ничего особо выделяющегося.
Не раз читал кучу статей/руководств по MIPS-3D, MDMX, MADMAX, MMX, MAX,
MVI, AltiVec и особенно VIS расширениям. Но особо любимым был и остаётся
IA64. Мне кажется в нём некая крутая золотая середина для рабочих
станций: и RISC, и не шибко минималистичный, и не шибко много чего
имеющий сильно специализированного под узкие задачи, и при этом тьму
команд я могу понять и осознать для чего они и чем могут помочь на
практике, далеко не только в мультимедиа задачах. Всякие его GSR
регистры и аллокации стэка мне красивы. Хотелось бы работать за такой
штукой, только без EPIC/VLIW, которые показали себя на практике
достаточно плохо.
RISC-V один из последних про кого я читал и рассматривал их команды.
И... не раз это делал, но каждый раз в нём не находил ничего интересного
вообще. Его конечно и не должно быть -- это должен быть простой,
скучный, дешёвый, хорошо выполняющий свои задачи процессор. Но никакой
эстетической красоты для меня, хотя у меня совершенно нет никакого
предвзятого отношения и наоборот хочется порадоваться что, мол, может
быть вскоре всё же будут дома RISC-V процессоры подобные, на замену
динозаврам монструозным amd64? Но про себя тоже отмечал, как и в этих
ссылках, что большая раздробленность инструкций (и сразу вспоминается
ARM, где ещё попробуй запустить что-нибудь на разных процессорах). С
одной стороны вроде бы и минимализм есть, в виде даже отсутствия CAS-а
(ему на замену LL/SC) и вообще необязательности (не в "базовом" наборе)
атомарных инструкций. С другой суммарно не мало всего в нём может быть.
Да и минимализм тоже должен быть без крайностей -- говорят что CAS
инструкция всё же дала бы куда больше эффективности для general purpose
компьютера, чем она бы усложнила сам процессор.
Посмотрим в общем. Много пишут о проблемах в отсутствии стандартизации
"обвязки" (привет MIPS). В том что возможно будет множество
проприетарных расширений (привет MIPS и ARM). RISC-V мне в любом случае
более люб чем ARM, но вот чёрт его знает взлетит ли и будет ли штатно
доступен простым смертным как альтернатива вменяемая.
Sergey Matveev [Tue, 2 Feb 2021 18:30:56 +0000 (21:30 +0300)]
Быстрый выбор файла
Наткнулся на Facebook PathPicker утилиту:
https://github.com/facebook/pathpicker/ (fpp)
Давно хотел что-то похожее, но сделал только жалкое подобие в виде qq: 5d2d9f386d547b8e436829db5c6533b17feffe8e. Утилита временами странно себя
ведёт при выборе. Из коробки не работает с zsh, ибо shell скрипты для
неё писал человек явно не сведущий в shell-е совсем. В целом штука
понравилась: захотел выбрать несколько файлов -- вызвал через tmux её
(https://github.com/tmux-plugins/tmux-fpp -- тоже кстати из коробки не
работающий скрипт, бл@, ну bash не стоит на куче систем из коробки, с
чего вы взяли!? да и не используют его опытные пользователи)
интерактивно выбрал, а дальше либо в редактор, либо команду набирай. Но
при выборе всего буфера, всего окна -- она ощутимо медленно работает.
Мне приходится ждать пока она отпарсит окно. Да и ввод команды там не
самый удобный. git add -- ещё терпимо. Но что-то сложнее уже хотелось бы
в shell-е, а результат этой команды добавить к уже набранному тексту.
Нашёл ещё ряд утилит которые интерактивно позволяют что-то выбирать:
* https://github.com/mooz/percol -- не пробовал, ибо на Python, поэтому
не хотелось бы (скорость)
* https://github.com/peco/peco -- тоже самое, только на Go. Попробовал
-- не работает. Точнее вывод в окне показывает, так сказать, первый
кадр, но вообще не реагирует ни на какие нажатия -- делаю kill.
* https://github.com/mptre/pick -- очень минималистичная утилита на Си.
Работает. Но выбирает только один элемент. Для выбора нескольких
файлов для git add (например) не подойдёт
* https://github.com/junegunn/fzf -- fzf вообще известнейшая штука, но
как-то у меня не срастается с ней дружелюбие. Да и несколько элементов
не выбрать
* https://github.com/robbiev/numberwang -- среди вывода просто ищет всё
что похоже на файлы и даёт номерами выбрать интересующие, копируя
результат в буфер обмена. Никакого красивого интерактива, очень всё
примитивно, но... вообще выглядело именно как то что мне надо.
Однако... на большом выводе (буфер tmux) он жутко тормозит! Да и когда
файлов много, то хотелось бы поплотнее умещать в несколько столбцов,
чтобы не прокручивать экран
* https://github.com/edi9999/path-extractor -- штука которая занимается
только выборкой файлов из ввода. Самое главное: поддерживает
"файл:строка" формат. В отличии от numberwang-а, работает очень
быстро. Остаётся только заиметь для неё TUI какой-нибудь
Но мне же по сути достаточен выхлоп numberwang, только бы в колонки в
его. Помню что print команда из zsh, который у меня и так стоит, умеет
делать в несколько колонок. Поэтому я взял и написал на zsh (один из
первых опытов программирования именно на нём) отображение и спрашивание
вариантов выбора:
http://www.git.stargrave.org/?p=dotfiles.git;a=commitdiff;h=62bccf2a97581ed475dd46068621d0dffa21d5c9
Ну и синтегрировал с tmux-ом. Теперь могу где угодно нажать P-o,
отобразиться выбор "файлов", ввожу их номера, enter, и на 20 секунд оно
будет в буфере обмена (если программа полностью закроется, то и у буфера
обмена не будет источника), и я могу вставить в командную строку или ещё
куда результат.
Для git команд это точно будет полезно. А вот выбирать одиночный файл
пока выходит не супер быстро, ибо сырое представление файлов отличается
от разукрашенного и структурированного и не сразу находишь нужный файл,
чтобы ввести его номер. Возможно нужно сделать отдельный popup с выбором
единичного файла на основе pick утилиты. А вообще разукрашенный вывод
fpp, который внешне полностью похож на входные данные -- действительно
помогает для восприятия (только плохо и медленно работает). Может всё же
напишу на Go fpp аналог, тем более что самая сложная часть по
выпарсиванию имён файлов уже есть готовая.
Sergey Matveev [Tue, 2 Feb 2021 06:41:52 +0000 (09:41 +0300)]
Трампа на Нобелевку
https://lenta.ru/news/2021/02/02/nobel/
Ага, после убийства Сулеймани, в самый раз говорить о премии мира.
Впрочем, я офигевал от присуждения этой премии Нельсону Манделе,
который фактически уничтожил одну из передовых стран в мире.
Sergey Matveev [Tue, 2 Feb 2021 06:04:09 +0000 (09:04 +0300)]
Насколько маленьким может быть ядро Linux?
https://habr.com/ru/post/540214/
Кхм, а ведь я использовал какой-то дистрибутив GNU/Linux на двух 3.5"
дискетах, запускаемый на i386, где был и lynx, PPP-клиент, tin, какой-то
почтовый клиент, IRC-клиент. И реально выходил со всем этим в Интернет.
Sergey Matveev [Tue, 2 Feb 2021 05:53:52 +0000 (08:53 +0300)]
GPL, systemd и RedHat
https://unixsheikh.com/articles/the-problems-with-the-gpl.html
https://unixsheikh.com/articles/the-real-motivation-behind-systemd.html
Интересная точка зрения на GPL и его внезапную связь с systemd. Мол,
из-за невозможности творить проприетарное непотребство, RedHat вынуждена
из-за GPL была изобретать systemd. Ну а systemd это поделка созданная
RedHat только и только (что очевидно и ожидаемо) для удовлетворения
собственных нужд, типа hard-code серверов Google, CloudFlare и делания
всего, чтобы избавиться от /etc, ну и иметь удобные backdoor-ы типа
"0day" пользователь получающий root-овые права. Причём тут выпиливание
/etc? Я и сам не понял. Типа отсутствие не hard-coded RedHat-driven
настроек? Как в Fedora документации напрочь отсутствует теперь раздел
(df37da70db7620b53e79b2492c154bc713da78ad) про настройку сети.
Sergey Matveev [Mon, 1 Feb 2021 14:05:57 +0000 (17:05 +0300)]
Исповедь docker hater
https://habr.com/ru/post/467607/
http://www.stargrave.org/www.boycottdocker.org.html
Хорошо отмечено, что принципиально ничего нового docker не изобрёл, ведь
были jail/zone уже. Только популяризировал эту идею. Хотя и далёкой
реализацией и тьмой других проблем. А вообще все проблемы по сути от
незнания людей и неумения использовать свои инструменты.
Раз уж до сих пор есть hater-ы docker, то выложу ка я www.boycottdocker.org
сайт, который в Google выдавался вторым в списке по запросу "docker".
Sergey Matveev [Sun, 31 Jan 2021 14:49:38 +0000 (17:49 +0300)]
Посмотрел "Неуязвимого"
https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D1%83%D1%8F%D0%B7%D0%B2%D0%B8%D0%BC%D1%8B%D0%B9_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC,_2000)
Всякие супергеройские фильмы, по этим комиксам -- совершенно не любитель
смотреть. Чужда мне эта культура. Но вот этот фильм -- очень понравился!
Правда жутко мрачный, в общем-то ближе к ужастикам даже. Но и Уиллис
крут и Джексон! Опять же, на фоне последнего безумия в США, смотреть
фильмы с неграми можно зарекаться, ибо их будут сувать из-за политики,
но некоторым крутейшим актёрам, типа Джексона, всегда будет исключение!
И подана эта вся супергеройская тема с необычного ракурса, и концовка
ещё более стрёмная.
Sergey Matveev [Sat, 30 Jan 2021 13:49:52 +0000 (16:49 +0300)]
Data vs datum
https://shkspr.mobi/blog/2021/01/data-is-data-are/
На работе недавно задавался вопросом касательно множественного или
единственного числа "data". Помню что в одно время (какие-то древние
года, судя по всяким stackexchange), "datum" было множественным числом
"data". А потом всё стало наоборот.
Эта статья говорит что data это единственное, точно так же как "рой"
(пчёл) -- рой один. Но рой состоит из множества пчёл, тогда как "data"
состоит из множества "datum"-ов.
Executive summary: delete the procmail port; the code is not safe
and should not be used as a basis for any further work.
Начал использовать maildrop полтора года назад 28e99fadc65dc461009707282a34247b54f51ce9 и очень доволен заменой. Мало
того что правила получаются короче, так ещё и язык довольно интуитивный,
простой и наглядный чтобы, годами не прикасаясь, мочь без документации
быстро добавить ещё не тривиальные хотелки.
Sergey Matveev [Thu, 28 Jan 2021 19:42:17 +0000 (22:42 +0300)]
One True Linux way и десктопы
https://liam-on-linux.livejournal.com/77016.html
Интересная короткая статья с неожиданной, но забавной концовкой.
Все эти taskbar-ы и прочее -- не меняются со времён Windows 95. Куча
desktop environment-ов повторяют поведение Win95 и всё равно это
делают плохо. У GNOME3 -- независим от Win95. Pantheon -- жалкое
подобие Mac OS X. Ещё есть повторюшки NeXTStep. OpenCDE кто-то может
вспомнить.
Разве это всё не "Linux way"? Мы делим людей на дюжину разных групп,
которые ненавидят друг друга. 3/4 из них делают ту же самую работу
что и остальные, реализуя чью-то совсем чужую идею. Другие будут
использовать другую идею. Один безумец будет что-то совершенно
другое изобретать, наполовину доделывая, а дальше прекращая всё
из-за скуки.
А тем временем, кто-то хардкорный будет использовать нечто ужасное
из 1973-го, но любить до смерти, отказываясь от чего либо более
современного.
А тем временем, люди которые делают работу, просто идут и покупают
Macbook.
Последняя фраза веселит. Ибо автор забывает, что люди которым есть чем
заняться и которые хотят это делать эффективно... вообще не
заморачиваются и не используют desktop environment-ы. В принципе.
Вообще. Я не встречал никого, кто бы не отказался от них со временем. Не
потому что чем-то не нравятся, а потому что не нужны и мешают даже одним
своим присутствием.
Серьёзно? Человек, которому есть чем заняться, будет думать об иконочках
в панельках и resize этих панелек? 20 лет назад я тоже сравнивал KDE и
GNOME, смотрел на другие DE, больше всего мне нравился долгое время
WindowMaker. Но с опытом вся эта тема DE как-то улетучивается. Даже я
конечно же могу потерпеть и какое-то время поработать где угодно, ведь
уж с задачей запуска терминала и разворачивания на весь экран даже macOS
наверное справится. Но если дистрибутив сразу из коробки предлагает
какой-то DE, то он автоматом относится к разряду "для новичков", которым
нужны иконки. Debian, Arch Linux, NixOS, Free/Net/Open/DragonFlyBSD,
Gentoo -- все они из коробки не предлагают ничего подобного, и каждый по
своему является синонимом "серьёзного" дистрибутива/ОС.
Sergey Matveev [Wed, 27 Jan 2021 09:07:40 +0000 (12:07 +0300)]
Уязвимость в sudo
https://www.opennet.ru/opennews/art.shtml?num=54474
Я вот никогда в жизни не использовал sudo. Вообще. Ну кроме чужих
систем, где настроено его использование. И на протяжении всей жизни я
только и делаю что регулярно читаю про очередные серьёзные косяки в нём.
Убеждён, что в 99% случаев людям нужен "su -", а не этот огромный
framework по управлению правами. Да и есть же очень маленький и
компактный doas из OpenBSD: 8dcb0aac0444e1c354b65e7fcd20fd75f72685e4.
Вижу sudo -- сразу себе говорю "до свидания", ибо сложным системам
нечего делать в вопросах повышения прав.
Sergey Matveev [Wed, 27 Jan 2021 08:04:17 +0000 (11:04 +0300)]
Посмотрел "Рестлера"
https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%81%D1%82%D0%BB%D0%B5%D1%80_(%D1%84%D0%B8%D0%BB%D1%8C%D0%BC)
Ещё на выходных. И всё из-за Микки Рурка, где тоже говорят он там хорош
как актёр. И фильм хорош, и Микки ещё как!
Sergey Matveev [Sun, 24 Jan 2021 22:47:32 +0000 (01:47 +0300)]
Как начать любить shell script: узнать размер файла
https://unix.stackexchange.com/questions/16640/how-can-i-get-the-size-of-a-file-in-a-bash-script
Возможно сейчас поздно и поэтому голова плохо соображает, но я осознал
что не знаю как кроссплатформенно узнать размер файла в shell-е. Парсить
ls или менять ему формат -- не серьёзно, ведь есть же stat утилита.
Которую я и использовал прежде. А сегодня проверил такой же ли у неё
способ задания формата вывода как и в GNU? Фиг там! И у ls разный, и у stat.
Пошёл по быстрому искать ответ всё ли так плохо. Да, всё плохо. Много
людей умудряются не понимать для чего нужен du. Если у ls всё же
стандартизованный вывод (ага, нужно выставлять POSIXLY_CORRECT для GNU),
то он бы мог быть портируемым вариантом. "wc -c" мне решение тоже
приходило в голову, но... оно не показывает размер файла из иноды, а
действительно считает кол-во символов сколько из него можно прочитать.
В итоге, пока остановился на perl -e 'print -s $ARGV[0]', хотя тут мог
бы быть и *awk и хоть python однострочник.
Удивительно, сколько лет можно жить, работать с shell, но на такие
простейшие вопросы не знать ответа простого и чёткого.
Sergey Matveev [Sun, 24 Jan 2021 22:01:30 +0000 (01:01 +0300)]
sharness радует
https://github.com/chriscool/sharness
https://testanything.org/
В d0ffbdd295c1583abde17388553038f39747b0cc упоминал что я для тестов в
goredo использовал sharness библиотеку. Просто делается её source, и она
предоставляет простой API, который может сделать проверки и вывести ok
или не ok для TAP протокола тестирования. sharness это вынесенная
библиотека тестирования используемая в Git. В прошлом году познакомился
и с TAP протоколом (простейший способ объяснения запускалке тестов всё
ли в порядке). TAP радует своей простотой и тем, что prove утилита
позволяет запускать тесты параллельно автоматом.
sharness до недавнего времени использовал по сути только как штуку
которая выводит нужные TAP сообщения. Но, он автоматически создаёт
временную директорию и подчищает её после завершения теста. В нём есть
"cleanup" функи позволяющие добавлять команды очистки за собой (например
убить процесс). Есть проверки на выставленные зависимости/prerequisites.
Есть возможность запуска с --debug или --verbose-ом. Есть даже
возможность test_pause-ом прямо во время выполнения теста провалится в
shell временной директории, что невероятно удобно оказалось когда у меня
как-раз запущенные процессы в фоне есть. Сплошные мелочи, но очень
приятные для работы и отладки.
* Починил -autotoss работоспособность при работе nncp-daemon в режиме
inetd. Точнее она и не ломалась -- почему то я её просто для этого
режима не добавлял. Причин не было, просто тупил
* Добавил опцию при которой nncp-caller может совершить вызов только
если есть исходящие пакеты. Внезапно, оказалось что cronexpr
библиотека, которую я использую для парсинга cron выражений -- без
проблем поддерживает даже секундны! А это значит что, совмещая с
when-tx-exists опцией, можно сделать autodialler -- который будет хоть
ежесекундно проверять наличие новых пакетов и связываться для их
отправки
* Ну и наконец-то я осуществил своё ещё прошлогоднее желание о том,
чтобы перевести логи в формат recfile-ов. Я популяризатор RFC 3339
формата структурированных логов: в ivi и на текущей работе. Но сейчас
сам же от них отказываюсь. У меня нет полной уверенности в том что
творю, ведь SD-structured логи честно являются одной строкой -- одной
записью. Но в Python софте они не актуальны, ибо traceback-и
выбрасываются на много строчек, что делает такой журнал нифига не
валидным с точки зрения SD. recfile-ы же и гораздо легче парсятся, и
уже есть инструментарий, и куда более человекочитаемы. А ведь логи в
NNCP это всё же не совсем только журнал, но и штука по которой в
теории предполагалось строить отчёты из серии сколько трафика мы
обменяли с такой то нодой в этом месяце, построить графики
какие-нибудь. Сам я это так и не осуществил, ибо потребностей не было,
но с recfile-ами это уже существенно проще будет проделать
Sergey Matveev [Sat, 23 Jan 2021 18:25:34 +0000 (21:25 +0300)]
Преступное быдло Навального
https://lenta.ru/news/2021/01/23/udar/
https://lenta.ru/news/2021/01/23/eye/
https://lenta.ru/news/2021/01/23/39/
https://lenta.ru/news/2021/01/23/kesar_poletel/
https://lenta.ru/news/2021/01/23/4tisyachi/
https://lenta.ru/news/2021/01/23/dalvostok/
Залез в новости, оказывается сегодня поклонники уголовников решили
собраться и побузить. Благо что таких находится даже в Москве
относительно немного. Меня удивляет только мягкость полиции ко всему
этому сброду.
Sergey Matveev [Sat, 23 Jan 2021 10:21:09 +0000 (13:21 +0300)]
Посмотрел "Сердце ангела"
https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B4%D1%86%D0%B5_%D0%B0%D0%BD%D0%B3%D0%B5%D0%BB%D0%B0
Мало чего я видел с Микки Рурком (только комедийный "Четверг" приходит
на ум), но тут вижу какой он крутой актёр! Да и фильмы в целом очень
понравился! Я ничего про него заранее не знал, но, честно говоря, в
первых же минутах фильма, у меня уже проскочила мысль что сам главный
герой это тот, кого ищут.
Sergey Matveev [Sat, 23 Jan 2021 09:52:31 +0000 (12:52 +0300)]
Let's Encrypt на ZFS
https://letsencrypt.org/2021/01/21/next-gen-database-servers.html
https://github.com/letsencrypt/openzfs-nvme-databases
Let's Encrypt опубликовала то, как они живут с ZFS-ом и MariaDB для
своих довольно нагруженных задач. По железу ничего интересного: stripe
из 12 NVMe зеркал -- да там за миллион IOPS-ов должно быть! В памяти
можно ничего не хранить (индексы БД) -- одни IOPS-ы выжмут всё что надо.
А настройка ZFS ничем не примечательна, но грамотна. Именно такой и
должен быть подход и понимание особенностей dataset-ов:
* выставленный ashift -- must-have, для NVMe даже 8KiB поставили
* включённый hotspare -- так держать. Тем более что несколько терабайт
для их NVMe это вопрос очень небольшого времени
* использование простых зеркал в stripe -- разумно, из-за NVMe и малого
времени resilvering-а. Для HDD конечно было бы неразумно
* используют /dev/disk/by-id/ -- если диск честно отдаёт свой id, то
разумно. Нормальные NVMe думаю что такое. Хотя лично я предпочитаю
создавать GPT с label-ом... содержащим серийник диска :-)
* балансировка дисков по контроллерам и шинам -- как минимум понимают
важность (всё ж у меня и не было сомнений что там квалифицированные
специалисты работают) этого
* atime=off -- так держать. Лично у меня только единственный dataset с
Maildir-ом моей почты для Mutt имеет atime=on
* compression=lz4 -- вообще в случае с дюжиной NVMe у меня бы были
сомнения а не упрёмся ли мы в CPU, но видимо что LZ4 и CPU настолько
хороши, что даже с такой дисковой подсистемой это не бутылочное горлышко
* primarycache=metadata -- правильно, учитывая что у СУБД своё неплохое
кэширование (для задач)
* recordsize=128k -- ну это и так default, всё ok
* xattr=sa -- вот с этим, кроме как на Ceph, не сталкивался, но видел
что надо бы. Хотя на FreeBSD эта настройка вообще не используется
InnoDB раздел -- особый. Как минимум в нём fsync:
* logbias=throughput -- разумно, ибо, как верно заметили, все диски и
так одинаковы по производительности, плюс это не HDD где головку надо
перемещать на ZIL и обратно. throughput тут позволяет "вне ZIL" сразу
записывать данные, что для NVMe разумно
* recordsize=16k -- самая главная настройка по сути. В PostgreSQL это 8K.
Это убирает дичайший overhead который бы был с recordsize=128K
* redundant_metadata=most -- убирает необходимость создания некоторых
копий метаданных. Если это сильно вредит, и раз всё равно зеркало
есть, то разумно
В самой MariaDB отключены checksum-ы -- разумно, так как оно есть в ZFS.
Отключён doublewrite -- ибо записи в ZFS атомарны. write ahead log
бессмысленнен на CoW -- выставлены в размер recordsize. Отключён AIO, ну
потому что это Linux и он говно в котором много что работает плохо, это
очевидно. flush_neighbors отключён, ибо это всё равно CoW и NVMe.
У меня придраться не к чему, всё как надо. Хотя я удивлён что sysctl
никак не настраивали. Но видимо современные ZFS версии и так очень
хорошо себя ведут.
Sergey Matveev [Sat, 23 Jan 2021 09:47:07 +0000 (12:47 +0300)]
Go как основной язык
Я никогда бы не подумал что Go всё же может вытеснить Python для многих
задач которые нужно сделать по быстрому на коленке. Типа интерпретируемый
язык это всё же отдельная ниша со своими удобствами. Но когда я,
относительно недавно, написал генератор всяких XML-ек из recfile-а
(df5af37e96c74dedf26d1a2614cb2fe79a7f52ba) не на Python, а сразу же на
Go, то у меня ощущение что что-то не так. А на днях я вообще задачу
которая вполне себе могла бы быть относительно безболезненно выполнена
на pure shell (запустить процессы в фоне, дождаться завершения, сделать
проверки) -- тоже сделал в итоге на Go. Я толком с XML не работал в Go
никогда и не знаю геморройно ли там или нет. Но много работал в Python.
И воспоминания о боли проведённой с ним, даже заблокировали попытки
написать linksexp на нём -- сразу Go в руки. Python-у конечно есть
место, но уже даже не для простых скриптов трансформирующих recfile в
XML-ки всякие. Всё же Go это величайшее творение величайших умов!
Sergey Matveev [Sat, 23 Jan 2021 09:36:54 +0000 (12:36 +0300)]
Цензура в соцсетях
https://lenta.ru/news/2021/01/23/hamenei/
Последние месяцы, такое ощущение, что все эти VK, Telegram, Twitter,
Facebook, США и прочие только и делают что блокируют/цензурируют друга
друга. Трамп закрыл/запретил/удалил одно, его закрыли в другом месте,
третье место в отместку за это зацензурировало первое. Везде только и
делают что удаляют неугодных для текущего руководства (компании или
властей гос-ва).
В общем-то ничего удивительного само собой -- на то это и
централизованные решения, но в последнее время прям чуть ли не каждая
соцсеть уже является официальным сторонником то одних, то других. Хочешь
пропаганду от РФ? Дуй в Telegram. Хочешь от США, без Китая и Трампа? Дуй
в Twitter. И так далее.
Sergey Matveev [Fri, 22 Jan 2021 14:43:44 +0000 (17:43 +0300)]
Про чистоту языка и заимствования
https://phd-ru.dreamwidth.org/337742.html
Не могу не скопировать сюда, то что, одновременно, и улыбает и вызывает
ненависть :-)
Рашн лэнгвидж впитывает форин вордсы как губка
«Кэшбэк, как перманентная выгода в рамках программы лояльности.»
Как звучит! Просто поэма…
Слово "мерч" я энкаунтрирую первый тайм. Я, конечно, прорюхал, что
это кат от "мерчендайзинга", но не знал, что уже и сокращение стало
вордом русского языка. А вот, в вокабулярии есть (в викибулярии?).
Впрочем, мне меньше всех других стоит к этим заимствованиям
придираться. Что, мой профессиональный жаргон лучше, что ли? Анекдот
из 90-ых годов:
Subj: buffer overflow
Ребят, а эксплойты, связанные с сабжем, отдают рутовый шелл только
ли тогда, когда суид рут у дырявой проги??? А если суид отсутствует,
но рут - владелец екзешника?
Sergey Matveev [Fri, 22 Jan 2021 09:31:36 +0000 (12:31 +0300)]
Chromium вон из репозиториев
https://www.opennet.ru/opennews/art.shtml?num=54452
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%9633/
Мне известен факт что всё больше и больше сайтов (или целых framework-ов)
работают только на Chrome(ium). По факту это уже единственный движок. На
остальных с каждым месяцем всё больше вероятности что что-то не будет
работать. И из самых популярных дистрибутивов, где больше всего "рук",
одну из самых популярных программ, по совместительству единственную
свободную реализацию Chrome движка, хотят выпилить. Web это Chrome, но
свободной версии которого не будет в популярных GNU/Linux дистрибутивах.
Что-то мне это напоминает... ах да, я ж буквально сегодня смотрел
очередной выпуск "Кремниевых титанов", где рассказывали про Flash. Супер
популярную закрытую проприетарную технологию.
А вообще я не понимаю поднятую бучу. Но наверное я потому что уже не
пользователь web-а в современном понимании. Как бы... какое отношение
имеет броузер и возможности какой-то там синхронизации с каким-то там
облаком?
Sergey Matveev [Fri, 22 Jan 2021 07:41:14 +0000 (10:41 +0300)]
Сотовые операторы несуществующих государств
https://nag.ru/articles/article/108076/operatoryi-nesuschestvuyuschih-gosudarstv.html
Интересная статья о сотрудниках сотовых операторов ДНР, ЛНР, Абхазии,
Южной Осетии, Нагорного Карабаха. Аналогично я слышал про Сирию: мол,
там чуть ли не первым делом после боёв (когда они были) восстанавливают
сотовую связь, которая получше чем в Москве.
Sergey Matveev [Thu, 21 Jan 2021 19:28:04 +0000 (22:28 +0300)]
Ускорения GoGOST
http://www.gogost.cypherpunks.ru/News.html#Release-5_002e3_002e0
GoGOST код -- старый. Да и писался когда я не так хорошо понимал
внутренности Go, особенно касательно slice/массивов.
Сделал оптимизации в код Стрибога и Кузнечика:
первый стал быстрее в 15 раз, делая 10.5 MiB/sec, а
второй (проверял Кузнечик-MGM) в 16 раз, выдавая 824 KiB/sec.
В принципе всё очень не шустро, это так.
Sergey Matveev [Thu, 21 Jan 2021 09:17:25 +0000 (12:17 +0300)]
"Миф" о бесплатных квартирах в СССР
https://lenta.ru/news/2021/01/21/soviet_myth/
Ага, развеян. Пустобрех (синоним журналистов) спорол очередную фигню. Ну
или, как всегда, есть параллельные миры с СССРом. То ли два, то ли три
года можно было проработать на стройке и получить квартиру. Это факт.
Отцу за службу в Афганистане тоже выдали двухкомнатную квартиру, да ещё
и с телефоном (что далеко не у всех было).
Понимаю что истина где-то по-середине. Кто-то долго ждёт, кто-то нет.
Каждый (включая меня) показывает наверное всякие крайности. Но факт
остаётся фактом, что простая семья инженеров, без связей или прочего,
без какой-либо жилки коммерсантов/евреев, способна получить хорошую
квартиру за разумное время ожидания. А сейчас кто может купить квартиру?
И не в долгах быть на протяжении 20 лет (ипотека).
Sergey Matveev [Thu, 21 Jan 2021 09:02:20 +0000 (12:02 +0300)]
Баги vim-lsp. Bleeding edge
Время от времени я обновляю vim-lsp плагин (git pull). С ним (или самим
Vim, чистой 8.2 версии без патчей?) и раньше были проблемы: съезжающий
курсор, изменённый changelist и другие косяки. Причём визуальные
огрешности ещё терпимы, но вот порча changelist, из-за которой я не могу
сделать "g:" -- время от времени рождает мысли "а не снести ли vim-lsp?".
Сегодня в одном Си файле я прям +- гарантированно могут повторять
ситуацию из-за которой даже курсор вообще после закрытия какого-то
preview/baloon/popup/hover (путаюсь в них) окошка съезжает. Решил просто
взять и откатиться на мажорный тэг релиза назад. В общем, на два релиза
назад (v0.1.2) всё становится сильно лучше. Ещё не знаю как там дела с
changelist, но хотя бы курсор не убегает по непонятной причине.
Это как-раз одна из множеств демонстраций того почему я не люблю
bleeding edge подход и по сути сразу отвергаю дистрибутивы с ним. Это
конечно здорово что люди будут больше и быстрее тестировать софт,
безусловно, но лично я, когда хочу работать -- я хочу работать, а не
натыкаться на вновь и вновь меняющееся поведение, особенности и баги.
Но это речь только про бездумное обновление просто на свежую версию.
Например какой-нибудь git или mutt я обновляю сразу же с выходом их
новых версий. Потому что там, как правило, всегда что нибудь да
полезное, или хотя бы частенько бывают улучшения производительности.
Мультимедиа библиотеки -- аналогично, ради производительности.
Sergey Matveev [Wed, 20 Jan 2021 13:59:32 +0000 (16:59 +0300)]
"Тетрадь смерти" -- запрещена
https://lenta.ru/news/2021/01/20/animeban/
А ведь она действительно настолько популярна, что даже я её смотрел.
Причём первые 10 (или 20?) серий вроде бы ещё ничего, даже нравились. Но
потом я уже проматывал чуть ли не целыми минутами -- ибо бесконечно
высасывают всё не заканчивающуюся историю. Но это всё только потому что
сериал.
Sergey Matveev [Wed, 20 Jan 2021 13:47:16 +0000 (16:47 +0300)]
ctags зависимостей проекта
http://www.git.stargrave.org/?p=dotfiles.git;a=commitdiff;h=f1d0460ad26badf793c5cafa842ebe9a4c761354
В 7d4a3e2b2839f1c4edf6dbaf587a016ba8183f23 писал про то, что кроме
индексации кода основной рабочей директории, частенько нужны тэги и на
зависимости, на связанные проекты. И я для этого делал символические
ссылки на рабочие директории сторонних проектов/зависимостей.
На работе напомнили что ведь никто ж не мешает использовать несколько
тэг файлов. Проиндексировав один раз какой-нибудь огромный OpenSSL --
его тэги можно отдельно подсовывать где нужно. Плюс переиндексация будет
идти только по реально той части проекта что тебе нужна.
Сразу же мысль о том, чтобы подкладывать какой-нибудь per-project .vimrc
файл и в нём делать set tags+=.... Открыл для себя set exrc и set secure
опции, которые автоматом могут более-менее безопасно подгружать .vimrc
файл из локальной директории. Прежде у меня был даже отдельный плагин
(на три строки) который делал аналогичное -- его можно удалить теперь.
Хотя я его по факту толком то и не использовал.
Но на работе снова подкинули мысль о директории с символическими
ссылками на нужные тэги проектов. И .vimrc никакой не нужен и ничего не
надо писать чтобы искать в иерархии директорий этот .vimrc -- ведь set
tags позволяет задавать поиск по ФС как вглубь, так и "наверх". В итоге
с минимальными правками всё это реализовал у себя и доволен. Одно но:
почему то поиск тэгов со звёздочкой внутри директории не работает --
поэтому приходится делать поддиректорию, что всё равно скрыто от глаз.
Вместо "tags" файла в корне проекта, теперь ".tags" директория, внутри
которой "tags" файл касающийся текущего проекта, плюс опционально
поддиректории со своими "tags" файлами на сторонние проекты (на их
.tags/tags файлы).
Sergey Matveev [Wed, 20 Jan 2021 09:14:08 +0000 (12:14 +0300)]
goredo в портах FreeBSD
https://www.freshports.org/devel/goredo/
Добрый человек взял и запилил порт goredo в FreeBSD! Он правда не
создаёт символические ссылки сразу же, поэтому после установки работать
(redo* команды) ничего не будет, но это уже наверное предполагается на
совести пользователя выставить свою предпочитаемую систему redo как ему
надо.
А ещё я вижу что все используют описание проекта как его начал Kai Hendry:
Go implementation of djb's redo, Makefile replacement that sucks less
мне оно нравится, ничего против не имею, хотя и придрался бы к "Make" vs
"Makefile", но фиг с ним. Сделал и у себя правку на это описание, чтобы
уж везде было одинаково.
Sergey Matveev [Tue, 19 Jan 2021 14:23:28 +0000 (17:23 +0300)]
io/ioutil будет deprecated в Go 1.16
https://www.srcbeat.com/2021/01/golang-ioutil-deprecated/
Всецело одобряю! И яркий тому пример: ReadAll находится в ioutil,
ReadFull в io? ReadFile вне os? Как и TempFile аналогично вне os?
Разумно это всё распихать по нужным местам.
Sergey Matveev [Tue, 19 Jan 2021 11:50:08 +0000 (14:50 +0300)]
Gitlab неюзабельное говно
Как же я его ненавижу, искренне. На работе в одном проекте попробовали
им пользоваться для отправки merge request-ов и их обсуждения.
Он совершенно рандомно (или не понятно для нас как именно) присылает
уведомления на почту о комментариях к коду. Короче что то присылает, а
что-то нет.
Ладно, чёрт с почтой -- я захожу в merge request и нигде не показывается
что у текущего diff-а есть комментарии над куском какого-то файла. Более
того, многие большие файлы свёрнуты. Если нажать на expand all чтобы
раскрыть колоссальные портянки текста, то... опять же, рядом с
комментариями нигде нет никаких слов "comment" или подобного -- текст я
могу искать только по дате или имени автора комментария (или тексту
комментария), которые, очевидно, я не могу знать заранее. В итоге мы в
почту пишем о том что написали там комментарий.
Отвечаю на комментарий и хочу отформатированный текст вставить (кусок
кода). Его предложение через меню о вставке "``" не поможет для
многострочного вывода. Никаких предложений об использовании <pre> нет --
догадался сам. Ввёл их -- жмакнул "edit comment" и вижу что ничего не
обновилось. Точнее он показалась что "edited just now", но
форматирование не обновлено. Ok, снова редактирую, жмакаю "preview",
вижу что всё ok, нажимаю снова edit и снова ничего не обновляется. Снова
повторяю, но уже добавляя просто случайный текст в конец, а не только
<pre> тэги -- помогло.
Когда мне надо вмёржить не default ветку своего репозитория в не default
ветку другого, то интерфейс позволяет выбрать src/dst ветки и
репозитории. Вот только при выборе dst ветки целевого репозитория -- моя
src сбрасывается. А при выборе src, после выбора dst, сбрасывается dst.
Что делать, как быть? А в момент git push Gitlab выдаёт ссылку, где в
GET параметрах указана src ветка (она то уж точно известна ему). Если
использовать именно эту ссылку для создания merge request, то появится
интерфейс вбивания комментария к merge запросу, но в котором если нажать
на change branches, то появится точно такое же меню выбора src/dst
веток, но которое уже будет работать!
Вмержить только часть коммитов -- неа, нельзя. Если только не руками,
конечно же. Про сам интерфейс просмотра изменений, где нельзя увидеть
всю историю push-ей и изменений коммитов -- молчу. Точнее вроде бы в
теории может быть и можно, видя что в URL-е есть всякие start_sha
параметры есть, но мне использовать его GET параметры как CLI что ли
какой-то?
Я уж понятия не имею Github такой же или это Gitlab такой неюзабельный и
корявый (или наш instance такой), но... работать с этим нельзя. Как бы
мне не нравился Gerrit своей Java-природой, дикими тормозами (хотя...
меньшими чем Gitlab) из-за JS-а, но в нём можно делать ревью по
человечески (c6f4f67e4f265306dfc762acfc0a22580c690cc5). Я то вообще
написал плагин для Vim-а чтобы ещё сильнее упростить и сделать этот
процесс более удобным. Но таких глюков и неработоспособностей как в
Gitlab в Gerrit нету.
А с другим коллегой на работе я просто по почте переписку вёл, отправляя
"ссылки" на свои обновлённые ветки -- это ещё более удобный способ. Но
требующий чтобы собеседники умели пользоваться email-ом (а для этого
нужен и работающий почтовый клиент само собой). Вот и выходит: на одной
чаше весов требование использования email-а и удобство ревью и
обсуждения патчей, а на другой чаше... почти неюзабельная возможность
работы. Ну и где-то ближе к середине Gerrit (и похожие на него решения),
который и не совсем удобен, но и не совсем неюзабелен.
Sergey Matveev [Mon, 18 Jan 2021 09:40:36 +0000 (12:40 +0300)]
goredo на YouTube канале Kai Hendry
https://www.youtube.com/watch?v=2qGyn8RGYxY
Ну что ж... короткое видео от Kai Hendry, который с каждым моим письмом в
личной переписке всё больше убеждается что он "sold" этой системе сборки.
Он же сделал пакет для Arch и macOS и использует goredo. А ведь в прошлом
тоже советовал использовать Make.
Sergey Matveev [Mon, 18 Jan 2021 08:44:49 +0000 (11:44 +0300)]
In Extremo -- Palästinalied 2
https://en.wikipedia.org/wiki/Pal%C3%A4stinalied
https://www.youtube.com/watch?v=hVRPGChBoY0
Понятия не имею о чём они поют (судя по Wikipedia -- оправдание крёстных
походов, ибо только христианская религия единственно трушная), но
красиво звучит. Тётя мне как-то говорила что всю жизнь считала
французский язык всем из себя таким красивым, но позже, особенно после
командировок во Францию, поняла что чёрта с два оно так. Как и я замечал
что ничего в нём нет красивого на практике, видя французские фильмы где
слышна родная речь. Это не Милен Фармер со стихами. Вот и с немецким
аналогично похоже -- в стихах очень даже красиво!
Sergey Matveev [Mon, 18 Jan 2021 08:22:55 +0000 (11:22 +0300)]
Всю жизнь не правильно бил жёсткие диски
Ещё в школе я знал что пропускная способность жёсткого диска на внешних
цилиндрах -- выше. Ближе к центру -- хуже, но время поиска тоже ниже.
Поэтому, ещё в школе, я старался размещать разделы диска так: для
хранения -- ближе к внешним цилиндрам, для swap/ОС ближе к центру.
Совсем недавно я проверял работоспособность одного диска для начала
заполняя его случайными данными и нулями. И заметил что к концу его
sequential read/write скорость отличается на десятки процентов.
Очевидно, из этого можно сделать вывод -- первые блоки диска расположены
на внешних цилиндрах.
Вот только осознал я это вчера. А прежде почему-то про себя считал что
жёсткий диск пишет как и CD-ROM -- от центра. В итоге я всю жизнь задом
наперёд разбивал его. Но и никогда замеров скорости не делал, чтобы
понять что что-то не так.
И ведь я ещё же знаю и тот факт что ZFS по умолчанию старается размещать
данные там, где максимальная пропускная способность. И я же видел что
данные то эти она пишет как раз прямо в начало. Что тоже намекает что
внешний цилиндр находится в начале.
Как же долго может занимать осознание и складывание двух простых фактов!
Sergey Matveev [Mon, 18 Jan 2021 08:04:40 +0000 (11:04 +0300)]
Санкции из-за посаженного преступника
https://lenta.ru/news/2021/01/18/nav/
Ага, РФ посадила преступника, мошенника, лжеца, иностранного работника
по попыткам подорвать стабильность в стране и просто редиску -- не хорошая она.
Sergey Matveev [Mon, 18 Jan 2021 07:43:09 +0000 (10:43 +0300)]
Обсуждение WKD в GnuPG рассылке
https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064567.html
Уже не первую неделю идёт обсуждение применения WKD на Github pages.
Которые не работают, потому что Github для sub.sub.github.com домена
выдаёт sub.github.com X.509 сертификат. Уже давно по диагонали
проглядываю письма в этом треде и всё до сих пор почти каждый день я
вижу: "это валидный сертификат", "нет не валидный", "нет валидный", "нет
не валидный". Старожили просто перестали отвечать на это, раз не доходит
до человека.
А сегодня увидел хорошее замечание, что раз Sequoia (реализация OpenPGP
на Rust) успешно работает с WKD и Github-ом, то это как-раз прям анти
реклама этой реализации. Явно не валидный setup с Github pages -- с ней
работает, когда должен падать.
Sergey Matveev [Sun, 17 Jan 2021 19:16:08 +0000 (22:16 +0300)]
Релиз NNCP 5.6.0
http://www.nncpgo.org/Release-5_002e6_002e0.html
Добавлены -autotoss опции, которые ежесекундно запускают тоссер при
наличии работающего соединения. Проверка наличия пакетов довольно
лёгкая, хотя, конечно же, не мешало бы и прооптимизировать всё это, ведь
сам NNCP знает что пришёл новый пакет.
Плюс перевёл NNCP на использование vendor директории, раз минимальная
версия Go стала в нём 1.12. Вообще я и GoGOST с gostls13 уже перевёл на
это тоже, как надо бы и все остальные свои проекты. Ибо удобно создавать
эту директорию (174173f91e592f40199e39e9b5aea51911f2f45f) и не нужны
GOPATH хаки.
Sergey Matveev [Sun, 17 Jan 2021 19:14:00 +0000 (22:14 +0300)]
Релиз goredo 1.0.0
http://www.goredo.cypherpunks.ru/News.html#Release-1_002e0_002e0
Учитываю размер файла теперь. Из-за этого формат state recfile-ов
изменился и поэтому это мажорная, не совместимая, версия. Плюс перенёс
redo-whichdo тест из apenwarr/redo и сделал так, чтобы поведение моего
-whichdo было аналогичным (на самом деле -- более корректным). Плюс
добавил возможность забить на сравнение ctime-а, если нет доверия к
низлежащей ФС, заставляя явно проверять хэш файла.
Sergey Matveev [Sun, 17 Jan 2021 14:07:50 +0000 (17:07 +0300)]
Parler системные требования
https://habr.com/ru/news/t/537702/
Понятия не имею что это за Parler (видел только то, что их отключили от
AWS), но требования впечатляют:
* не менее 40 высокопроизводительных instance (типа i3.metal AWS), в
каждом 64 vCPU, 512 ГБ ОЗУ, система хранения 14 ТБ nVME (Scylla
Cluster);
* от 70 до 100 instance для кластера БД, в каждом 96 vCPU, 768 ГБ ОЗУ,
система хранения 4 ТБ nVME (PSQL Cluster);
* 300-400 простых инстантов, в каждом 8-16 vCPU, 32-64 ГБ ОЗУ.
и это всё для... 8млн. пользователей всего лишь. Так и хочется сказать
что вот они современные модные разработчики. Даже хоть я и писал на
Python, но подобные требования выглядят уж точно как перебор чересчур.
Sergey Matveev [Sat, 16 Jan 2021 11:50:01 +0000 (14:50 +0300)]
Ширина строк в 90 символов
В newsboat (4f59f723102f30f7449779e511b4f523cb88e909), можно указать
ширину текста во время рендеринга HTML. Поставил ради эксперимента 90,
ведь примерно столько я выставляю в linter-ах исходного кода. Не думал
что я вообще это замечу, но мне реально очень неудобно и непривычно
читать текст чуть вот шире "обычного". Через пару недель вот вернул на
80. В исходном коде 90 это граница когда за 80 можно ещё чуть-чуть
вылезти, но 95% перцентиль умещается в 80 символах. В newsboat
получается что почти 100% всего находится в 90 символах. Возможно это
такая сильная привычка конечно, но уж очень замечаю эту ширину.
Sergey Matveev [Thu, 14 Jan 2021 16:40:38 +0000 (19:40 +0300)]
Мысли про слежение за зависимостями в redo
https://groups.google.com/g/redo-list/c/I_BLZJcutCA
Michael Raitza написал хорошие мысли про всю тему с слежением за
зависимостями в redo. А я свои вылил. Я всё же ещё больше стал уверен в
правильности подхода (хотя сомнений и не было) использования контрольных
сумм. Всех не удовлетворить (иначе будет монструозный framework и,
скорее всего, не удобный и/или с большим порогом входа), а подход в
goredo (да и redo-c в целом) максимально удобен и гибок для
преобладающего большинства задач.
Но там в рассылке и всяких хотелок на тему redo-ood, redo-targets,
redo-sources понабросали. Приделаю уж, вроде не сложно. Хотя до конца
всё равно не очень вижу надобности в них, но точно так же как и с
redo-dot, который было просто интересно написать.
Sergey Matveev [Thu, 14 Jan 2021 16:33:38 +0000 (19:33 +0300)]
goredo в macOS и на arm64
https://github.com/Homebrew/homebrew-core/blob/master/Formula/goredo.rb
Нет, я не прикован наручниками в подвале под присмотром, где я только
macOS-ом я могу сообщить что со мной что-то не так, добив ещё и тем,
что надо было повозиться чтобы оно и под arm64 заработало. Просто тот
же Kai Hendry что и добавил порт в AUR, решил и в macOS запилить
поддержку.
Install страница goredo намекает что это на 100% хипстерское поделие, с
macOS-ом и AUR-ом то. А я даже так и не начал готовить порт в FreeBSD...
Sergey Matveev [Wed, 13 Jan 2021 13:11:34 +0000 (16:11 +0300)]
Создание vendor директории в Go
https://github.com/golang/go/issues/30329
https://github.com/goware/modvendor
В своих tarball-ах для Go программ я обычно создавал src/ иерархию
директорий как в $GOPATH/src и говорил что собирать надо просто указав
GOPATH на текущую директорию. Прелесть этого в том, что будет работать и
на старых версиях Go (не знающих про модули) и на новых.
Но GOPATH собираются полностью выпиливать. В принципе ничего страшного:
"поставлять" зависимости в vendor директориях можно было уже давно. Но
придётся отказаться от Go <1.12. Но, насколько вижу, у меня по сути все
зависимости и мой софт именно эту версию минимально и требуют. Так что
смысла поддерживать GOPATH совместимость нет.
Поэтому в goredo начал делать полноценную vendor директорию. go mod
vendor позволяет создать её. Но она не включает кучу файлов, возможно
нужных для поставки (тесты и сопутствующие файлы): ff602609469a5830b0c9be1f24d2d519dbb84561. Я поэтому писал на много
десятков строк адские скрипты копирующие зависимости. Но сегодня нашёл
modvendor утилиту, которая копирует в vendor указанные glob-ы файлов от
каждого модуля. Это у меня заменило целый экран уродливого shell-а.
Теперь только так и буду готовить vendor директорию. Ручной труд всё
равно остаётся, но сильно упрощается.
Sergey Matveev [Wed, 13 Jan 2021 09:40:46 +0000 (12:40 +0300)]
Грайнд-молодость
https://www.youtube.com/watch?v=y7s8fhsveHc
https://www.youtube.com/watch?v=NNruFoV0NDE
https://www.youtube.com/watch?v=MoTaCR7J6FE
https://www.youtube.com/watch?v=AVrWuoA7vGI
https://www.youtube.com/watch?v=NbQ_ZCv-nLA
https://www.youtube.com/watch?v=QwTqWGbykMg
Вспомнил сегодня что-то про Тверских крутых порнограйндеров
Duodildo Vibrator и Septicopyemia ребят из столицы горграйнда нашей
страны (Иваново) -- даже видеозаписи с концертов есть в YouTube.
Sergey Matveev [Wed, 13 Jan 2021 08:39:27 +0000 (11:39 +0300)]
Закадровый перевод фильмов мало где известен
https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D1%8B%D0%B9_%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4
https://en.wikipedia.org/wiki/Voice-over_translation
https://en.wikipedia.org/wiki/Dubbing_(filmmaking)
Оказывается, закадровый перевод фильмов популярен только в Восточной
Европе, Монголии, Вьетнаме и Камбоджи. Переписываюсь с европейцем,
старше меня, и он знаком только с dubbing (дублированным). А у нас целые
поколения выросли на вот таком: https://www.youtube.com/watch?v=pZVSbzA4cm4
И я больше всего предпочитаю именно закадровый (в топку дублирование!) и
желательно одноголосый перевод (2e94b72b12b80b04d00e6b983f193a9ce652a4e9).
Sergey Matveev [Tue, 12 Jan 2021 20:51:13 +0000 (23:51 +0300)]
Google Groups... впечатляют неюзабельностью
Даже не помню толком когда последний раз что-то писал в рассылки на
Google Groups, но сегодня пообменивался там письмами. Тело PGP-MIME
сообщений там насильно меняется, инвалидируя подпись, что делает
невозможным нормальную подписанную отправку писем. Очень удобно и
безопасно, Google! Digest-ы там не в MIME виде и не содержат никаких
Message-ID, поэтому получая их невозможно ответить в трэд. Очень удобно,
Google! Плюс я уж не знаю почему, но все норовят меня поставить и в
копию и в список рассылки отправить сообщение, из-за чего мне по два
раза прилетает. Очень удобно и надёжно: не долетит одним путём, дойдёт
хотя бы вторым. А ещё видно что сообщения из рассылки вырезают огромные
куски цитат, тогда как в оригинале (то что на мой сервер прилетает
напрямую) оно в разы может отличаться по размеру.
Вот реально все эти корпорации стараются сделать всё, лишь бы всё что
касалось email-а было адски неудобным и на грани юзабельности. После
чего, люди конечно же будут говорить email фи, мессенджеры удобнее.
Sergey Matveev [Tue, 12 Jan 2021 19:03:14 +0000 (22:03 +0300)]
Смерть от вентилятора
https://ru.wikipedia.org/wiki/%D0%A1%D0%BC%D0%B5%D1%80%D1%82%D1%8C_%D0%BE%D1%82_%D0%B2%D0%B5%D0%BD%D1%82%D0%B8%D0%BB%D1%8F%D1%82%D0%BE%D1%80%D0%B0
Какие же только не бывают поверья! В закрытой комнате вентилятор может убить.
Но только в Южной Корее.
Sergey Matveev [Tue, 12 Jan 2021 14:23:06 +0000 (17:23 +0300)]
Как сделать красивые текстовые таблицы ещё проще и лучше?
В f445f28611aafab4883fd15795498f45bf5ca239 писал про tbl, который
отлично умеет рисовать сложные таблицы в консоли. Вот только на момент
написания той записи я не знал что он не разбивает автоматом длинные
строки. И не умеет этого. В итоге... решение так себе. Куча решений для
рисования таблиц не умеют объединять строки/столбцы, что бывает нужно,
не говоря про управление положением текста в ячейке.
Снова вернулся к этой теме сегодня и вспомнил про w3m броузер. Как
замену lynx-у он для меня не катит: не удобное управление как минимум.
Нужна возможность навигации по нумерованным ссылкам. Да и, глядя на
документацию, вроде бы ещё каких-то полезностей не хватает. Но, он
офигенно, как оказалось, рендерит таблицы. Пока похоже это чуть ли не
лучшее решение похоже. HTML таблицы вроде бы все умеют рисовать -- даже
не надо вспоминать ничего будет. И он отлично всё масштабирует, бьёт
строки, учитывает rowspan/colspan, <center> и border=1. Плюс достаточно
сделать w3m table.html > out для дампа отрендеренной таблицы,
опционально задав -cols XXX.
Sergey Matveev [Mon, 11 Jan 2021 18:21:42 +0000 (21:21 +0300)]
Advanced editing on UNIX (1993)
http://maibriz.de/unix/ultrix/etc/ae.pdf
В первую очередь, документ призван помочь секретарям.
А то совсем неумело тогда ed-редактором пользовались, позорище.
И ведь на самом деле, ed вполне себе мощный редактор. Не какой-нибудь
там блокнот. А если кому нужна история ввода и возможность
редактирования его строки, то просто запустить с rlwrap ed.
Sergey Matveev [Mon, 11 Jan 2021 16:18:04 +0000 (19:18 +0300)]
BTC на дедушкином ноутбуке
https://lenta.ru/news/2021/01/11/bitcoins/
На старом ноутбуке деда нашли 127 BTC, что дофигище денег. А ведь и у
меня когда-то был 0.1 BTC, где-то полученный просто так, раздаваемый
ради тестирования. Тогда 1 BTC стоил чуть менее 30 руб. вроде. Помню
что, когда понял что BitCoin -- фуфло неработающее (с шифропанковской
точки зрения), то rm -r директории со всем этим сделал.
Sergey Matveev [Mon, 11 Jan 2021 13:18:20 +0000 (16:18 +0300)]
rsync проблемы
Вот уже много лет замечаю что rsync с некоторыми серверами в Интернете
отказывается работать нормально: спустя несколько минут, без разницы что
передаётся (много маленьких файлов или середина какого-то большого), он
просто зависает. Ничего не делает, пока remote peer не отрубит
соединение и пока не сработают timeout-ы rsync-а чтобы он вышел. Пытался
на днях синхронизировать Project Gutenberg библиотеку, но на больших
файлах (.iso) оно по сути просто неюзабельно. Пытался обновляться,
пытался использовать "--whole-file" опцию, которая у многих на всяких
stackexchange помогает, но ничего не помогает. Парой лет прежде я тоже
пытался побороть и вроде даже в truss залазил смотреть что не так, но до
сих пор решения не знаю. Прежде я думал что возможно это у меня с сетью
что-то не так, ибо при PPPoE MTU был ≠1500, но сейчас у меня 1500.
В итоге уже не первый раз я делаю rsync на машине со старой FreeBSD в
совершенно другой (не домашней) сети с куда более древними версиями
rsync-а из портов.
Sergey Matveev [Mon, 11 Jan 2021 08:07:10 +0000 (11:07 +0300)]
USB4 vs Thunderbolt 4
https://fabiensanglard.net/nousb/index.html
Наслышан про сложности USB Type-C и Thunderbolt 3
(6d75cc7b8003ded7a8431fc78569bd24a3b42296), но с USB4, судя по
картинкам, ещё больший зоопарк. Верно автор заметил что прежде у
компьютеров была тьма разных портов, потом много из них заменилось USB,
затем ещё и USB2 (USB1 то всё же слишком медленный для многих задач). А
с USB4 выглядит так, что снова у нас радуга разных портов, отличающихся
визуально только приписками над ними. А Thunderbolt 4 заявляет что будет
"один", как старый добрый USB.
Sergey Matveev [Sun, 10 Jan 2021 17:55:51 +0000 (20:55 +0300)]
Отдельные страницы категорий к ссылкам
http://www.stargrave.org/Links.html
Недавно я приделал категории к коллекции ссылок
(df5af37e96c74dedf26d1a2614cb2fe79a7f52ba), а сейчас они отображаются на
отдельных страницах. Добавил множество статических, поправил кучу всяких
ошибок и недочётов.
Sergey Matveev [Sun, 10 Jan 2021 15:19:44 +0000 (18:19 +0300)]
goredo в AUR и 0.11.0 релиз
https://aur.archlinux.org/packages/goredo/
http://www.goredo.cypherpunks.ru/News.html#Release-0_002e11_002e0
Kai Hendry взял и запилил AUR порт goredo для Arch Linux. А мне пока
влом делать порт для FreeBSD. Очень уж меня напрягает тот факт, что
порты похоже нужно регулярно и постоянно собирать на всё обновляемых
версиях FreeBSD, что тот ещё геморрой (точнее бремя maintainer-а).
Даже NNCP и GoVPN за меня делают другие люди по сути а я и не знаю
откуда они берут всю эту информацию и прочее.
А ещё сделал 0.11.0 релиз, где поправил корявое поведение при указании
кол-ва параллельных задач: REDO_JOBS перебивал -j опцию и мне
приходилось делать REDO_JOBS= redo -j... пока перестал это терпеть. Ну и
заодно взял и добавил BLAKE3, вместо BLAKE2b. Вряд ли у кого упор был бы
в хэш, но всё же почему бы побыстрее штуку не впилить, потенциально
вскоре ещё и получающую (конкретная реализация) неограниченное
распараллеливание из-за Меркле деревьев. Тем более что тут нужна
проверка именно целостности только.
Но я взял не github.com/zeebo/blake3
(4c02094d684f2a9ac2736a67532a8f97eeec527c), а lukechampine.com/blake3,
хотя код последнего мне меньше нравится. Но у zeebo среди зависимых
библиотек есть пара без какой-либо лицензионной информации, что
автоматом является не свободным ПО. Хотя они используются и только для
внутри тестов, но геморрой возиться с созданием fork-а без них. Скорость
lukechampine.com/blake3 всё равно в два раза выше у меня чем у
golang.org/x/blake2b.
Sergey Matveev [Sun, 10 Jan 2021 11:12:34 +0000 (14:12 +0300)]
Термоядерное технопорно
https://habr.com/ru/post/536642/
В отличии от фотографий где показывают всякие элементы ракет, КЛА,
самолётов, тут вообще не понимаю даже назначения половины систем которые
строятся. Но интересно посмотреть на всю эту технику!
Sergey Matveev [Sun, 10 Jan 2021 10:20:12 +0000 (13:20 +0300)]
Снова рабочие места с ЛОРа
https://www.linux.org.ru/gallery/screenshots/16088342
https://www.linux.org.ru/gallery/workplaces/16092031
Вот два ярких примера того, что люди считают настоящим рабочим местом.
Кто-то считает что оно должно быть засрано, а всё где чистенько это
только показуха и позёрство, где настоящей работы не происходит. Я с
этим не согласен, но на первой фотографии всё же наверное нельзя
однозначно сказать что место засрано: поверю что всё на своих местах и
коробочки из под килек... ну просто вот такие вот коробочки.
Но по моему место должно быть удобным. Если человеку с первой фотографии
удобно работать в пространстве его подстилки под манипуляторы (видел что
многих это устраивает), то ok. Если человеку удобно дотянуться до рации
на столе или не приподнимая попы вставить что-то в розетку на столе под
монитором -- ok. Но лично для меня вторая фотография это пример
действительно удобного места.
Много места, много пространства -- очень приятно и стоит того. На работе
и дома у меня одинаковые поднимающиеся столы -- но отличаются площадью.
И вроде бы на работе площади конечно хватает, но приятнее когда перед
тобой здоровая столешница. И когда на ней много свободного места, ибо
когда надо что-то на минуту поставить и у тебя нет для этого места... то
бесит. На второй фотографии глубина стола, правда, удручает и то что
мало мест для ног в сидячем положении -- полностью их вроде бы там не
вытянуть, что я люблю делать.
Когда на столе мало всего -- это тоже жутко здорово, как минимум
потенциальной возможностью что-то положить, хоть системник чтобы его
потрошить. На первой фотографии даже блокнот или A4 листочек уже некуда
положить.
Звукопоглощающие панели -- крутая идея! Я заметил что в новых домах звук
куда лучше проходит по менее полым материалам стен, чем было во времена
СССР. И в спальне я соседей вполне себе слышу и были мысли о ещё лучшей
звукоизоляции (хотя она у меня имеется, при мне покупали рулоны
какого-то пористого материала).
Лично меня ещё смущает прозрачный корпус, но про это уже писал: 0fe54563cd0a99b823d5fd41c55560068e2d83ca. Но подобное место само собой
дорогого стоит, как минимум достаточной площади в квартире и в шкафах
чтобы хранить всё что вывалено на стол на первой фотографии. Никто не
будет спорить что лучше иметь большую квартиру чем маленькую
однокомнатную -- кто бы дал средств на это.
И ещё мне просто приятно что у человека один монитор. Знаю тех у кого по
4-5. Я пытался за свою жизнь жить с двумя или хотя бы с ноутбуком рядом
с открытой крышкой, но так и не нашёл use-case-ов для этого. За
последние лет пять только один момент вспомнил когда я использовал
ноутбук как монитор рядом -- отлаживал http://www.gostipsec.cypherpunks.ru/
где в ноутбуке был вывод tshark в котором мне надо было все эти
считанные байты сравнивать. Хотя дома второй монитор то есть -- но
только он на тумбочке рядом, чтобы подключить к нему какой
компьютер/ноутбук/сервер без затрагивания основного рабочего места.
Sergey Matveev [Sat, 9 Jan 2021 20:38:09 +0000 (23:38 +0300)]
goredo 0.10.0 tarball
https://lists.cypherpunks.ru/pipermail/goredo-devel/2021-January/000000.html
Один человек изъявил желание опакетить goredo для Arch Linux. А я знаю
насколько неудобно собирать Go программы без наличия всех зависимостей
рядом. Поэтому goredo теперь стал иметь и Info/Texinfo документацию и
сайт, с моим "фирменным" стилем и tarball со всеми зависимостями. Плюс
рассылку сделал для него.
А вообще сегодня обнаружил что goredo не очень корректно высчитывал
зависимости для default.do целей который находятся не рядом и выполняют
цели в поддиректориях. И ни один из apenwarr/redo и redo.sh-tests тестов
не покрыл этот use-case. Причём всё в целом работало... просто постоянно
пересобирало что не требуется.
Sergey Matveev [Sat, 9 Jan 2021 16:27:49 +0000 (19:27 +0300)]
Стало трудно вспоминать с кем общаюсь в почте
За последние несколько месяцев у меня что-то стало так много
собеседников (относительно того что было прежде), round-trip-ы общения с
которыми занимают несколько дней или недель. И мне трудновато вспоминать
кто есть кто. Со всех концов Земного шара и самые разные имена, по
которым не дифференцирую людей. Да и среди русскоговорящих это тоже не
помогает. Прям вот хочется завести уже recfile в котором делать пометки
кто есть кто, какие особенности человека (ну в плане кто что попробовал,
у кого какие проблемы, что обсуждали, что надо бы спросить/ответить).
Раньше я например мог запомнить что у "этого вот чешское ФИО", про себя
запоминаю как "чех" и этого хватало. Но сейчас чешских имён стало не
одно. Среди русскоговорящих есть и россияне и украинцы и москвичи: то
что можно упомянуть/вспомнить москвичу, не будет понятно не местным или
зарубежным.
Чувствую себя ещё и каким-то промоутером: на этой неделе на написание
одного письма потратил где-то 4-5 часов времени. Но зато человек решил
после него попробовать и ZFS и zsh (какая взаимосвязь? а на какие темы
ещё со мной можно поговорить :-)?), хотя он и не молод чтобы бросаться
просто так что-то пробовать.
Sergey Matveev [Sat, 9 Jan 2021 13:12:01 +0000 (16:12 +0300)]
Безопасность биометрии
https://shkspr.mobi/blog/2021/01/falsehoods-programmers-believe-about-biometrics/
Ничего нового (65d0e16b4a4135c6a98941fd8612d14afb550805), но снова
повторение того, что как сейчас массово любят использовать биометрию --
ужаснейшая небезопасность. Её нельзя сменить, в отличии от пароля или
токена какого-нибудь. Она публична и её везде люди "оставляют" и вполне
себе успешно всё регулярно копируется злумышленниками. Она подходит для
идентификации хорошо, не более. Либо только как ещё один фактор
аутентификации низкоэнтропийный.
Но в этой статье порадовало то, что дочка научилась разблокировать
телефон пальцем спящего отца... он поэтому теперь спит в перчатках.
Sergey Matveev [Fri, 8 Jan 2021 14:23:51 +0000 (17:23 +0300)]
Релиз goredo
http://www.git.cypherpunks.ru/?p=goredo.git;a=commitdiff;h=14398260feaf14dac68b9bdb1c810ccba7d1e768
Ещё в прошлом году один товарищ убедил что не помешает бы вкинуть про
redo/goredo куда-нибудь. В рассылку apenwarr/redo мне не удобно (по сути
ведь чисто реклама), а вот в dev@suckless.org вбросил, продолжая тему
которая там была поднята ещё в 2013-ом году. Тогда Uriel
(c2aa39a4a2db937c177b2b196eda52acbc51d2a8) сказал, что пока оно не будет
написано на Си или Go -- смотреть не будет ничего Python-овского. Ну как
раз вот моя реализация на Go появилась, как и redo-c за это время. С
того времени там и вкидывали на review .do файлы и сегодня уже лично со
мной связались с этой темой. Как минимум, с той рассылки, несколько
человек но заинтересовались и начали пробовать redo.
Оказывается, goredo то мой вроде как и никогда и не мог собираться на
GNU/Linux системах. Я использовал syscall для определения ctime файла, а
эта структура разнится на FreeBSD и Linux (в FreeBSD/NetBSD/Solaris она
одна, в OpenBSD/DragonFlyBSD/Linux другая). Сегодня починил (использовал
golang.org/x/sys/unix) и заодно прогнал все имеющиеся тесты на Ubuntu
какой-то там последней -- всё тип топ. А то ведь прежде я даже собирать
не пытался на этой ОС.
Sergey Matveev [Fri, 8 Jan 2021 14:01:38 +0000 (17:01 +0300)]
Релиз NNCP
https://lists.cypherpunks.ru/pipermail/nncp-devel/2021-January/000178.html
На днях начал реализовывать деревья Меркле, чтобы можно было частями их
обновлять. В NNCP думал что это пригодится для того чтобы, не зная
точного размера передаваемого файла, в конце обновить заголовок и быстро
пересчитать дерево с результирующим хэшом. Но не доделал, ибо прежде
обнаружил что у меня есть случаи когда файл шифруется потокового сразу в
несколько "обёрток", что так сильно всё усложняет, что плюнул на идею.
Но вот вот почти почти я заиспользовал бы Меркле на практике.
В итоге в NNCP так толком ничего и не сделал, кроме простых bugfix-ов.
Но конечно же это тоже приятно. Обнаружилось что на Go 1.10 оно уже не
будет собираться, так как есть golang.org/x зависимости где используется
GOOS=aix, а 1.10 ничего про это не знает и поэтому не игнорирует файл.
А ещё тут описали свой use-case NNCP (be88dfcd96ff0a7c75ccd803b8e72ad15629e7f6):
https://lists.cypherpunks.ru/pipermail/nncp-devel/2021-January/000159.html
человек прогоняет куда бОльшие объёмы данных чем я, через NNCP. Хотя у
меня больше разнообразия в используемых фичах. Есть баги с сетевыми
программами, но данные не искажаются и не пропадают -- это самое главное.
Sergey Matveev [Thu, 7 Jan 2021 17:06:22 +0000 (20:06 +0300)]
Технологии очков виртуальной реальности
https://youtu.be/LQwMAl9bGNY
Вообще ничего не знаю про подобные очки, кроме того что там внутри линзы
и дисплей. А тут куча всего интересного рассказано и показано.
Sergey Matveev [Wed, 6 Jan 2021 19:41:25 +0000 (22:41 +0300)]
Гировозы
https://habr.com/ru/post/536306/
Ух какие только не придумали транспортные средства! В космосе про
маховики, являющиеся аккумулятором энергии, я в курсе что используется.
Но вот на Земле не слышал что даже целые вагоны перевозят такими.
Sergey Matveev [Wed, 6 Jan 2021 13:49:48 +0000 (16:49 +0300)]
Попробовал github.com/zeebo/blake3
И вообще впервые попробовал BLAKE3, более детально вчитываясь в его
спецификацию.
Очень нравится то, что и в самой спецификации и в zeebo/blake3, Rust
реализации и github.com/lukechampine/blake3 очень простой интерфейс:
либо хэшируй, либо хэшируй с ключом, либо ещё и учитывай контекст (то
что в других хэшах было personalization string, application context).
BLAKE2 вообще предоставлял возможность указывать контекст использования,
но это мало кто из реализаций предоставляет в виде API. В BLAKE3 все
реализации попробованные это дают. Длину хэша какую надо? А вот сколько
прочитаешь из io.Reader выхлопа, столько и будет. Нужен XOF? Аналогично
просто вычитывай. В общем API и простота использования и необходимая
гибкость (ключи, контекст, длина хэша, XOF) -- всё очень нравится.
Без ассемблерных оптимизаций (amd64), скорость BLAKE2b-256 и BLAKE3 на
pure Go у меня примерно схожи. Но, zeebo/blake3 не делает никакого
распараллеливания. А если ассемблерные оптимизации использовать, то
BLAKE3 быстрее раза в два чем BLAKE2b (тоже с ассемблером). А ведь у
него и потенциально неограниченный простор для распараллеливания из-за
хэш деревьев.
Sergey Matveev [Wed, 6 Jan 2021 09:59:35 +0000 (12:59 +0300)]
Торвальдс критикует Intel за ECC память
https://habr.com/ru/news/t/536260/
А мне вот с ходу было сложно поверить что AMD прям реально просто так
даёт на простых процессорах поддержку ECC хоть в простые домашние
компьютеры. Я ведь привык к тому что ECC это удел минимум Xeon-ов, грубо
говоря, поэтому для домашних ПК про неё можно забыть. Я ж поэтому и
покупал себе серверы чтобы там был Xeon только и только из-за моего
желания иметь ECC память, а не ради какой-то там производительности или
подобного. А AMD показывает что это вовсе не роскошь.
Sergey Matveev [Wed, 6 Jan 2021 09:52:22 +0000 (12:52 +0300)]
dd с conv=fsync в Linux
https://abbbi.github.io/dd/
Про себя я был уверен что dd работает минуя подсистему ФС, как минимум
её кэш, ведь речь же не про ФС, а про блочное устройство (если речь про
работу с ним). В FreeBSD это так, никаких conv=fsync у нас нет. А вот в
Linux фиг -- всё равно будет при больших блоках кэш использован и
поэтому нужно пользователю явно руками указывать fsync/direct опции.
Плюс старая история о проблемах PostgreSQL с fsync-ами на Linux: 51b598a5b096892b8156da48dfb386ab755fff14 и здесь проявляется.
Sergey Matveev [Wed, 6 Jan 2021 09:36:33 +0000 (12:36 +0300)]
Github снимает ограничения для Ирана
https://www.opennet.ru/opennews/art.shtml?num=54360
Ну конечно же, как только один из тупиц натовских (потому что не знал
про особенности работы натовских Интернет служб в ряде стран) напоролся
на проблему, так сразу сняли все ограничения. Часть РФ, Сирия тоже у них
на подходе. А Судан, КНДР? Приглашать очередного ноющего натовца? А так
есть список относительно регулярно обновляющийся кто не будет работать в
Иране: https://gist.github.com/alibo/dfd7c258bcc44a0e8c9f7c5bfd3bd2c3 ну
и автоматом, насколько понимаю, в Сирии и запросто Крыму. В Сирии помню
что Go сайты не работают.
Sergey Matveev [Tue, 5 Jan 2021 14:12:31 +0000 (17:12 +0300)]
printf лучше echo?
https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo
Большая развёрнутая подборка того, как отличается поведение echo в
разных ОС, в зависимости от входных данных. Если коротко, то echo точно
работает только с данными чётко и явно контролируемыми программистом
(echo foo), но не получаемыми извне (echo $foo).