Не могу не поделиться украденной ссылкой из комментариев - https://www.mccme.ru/free-books/dubna/vau-random-2ed.pdf

Небольшая заметка про природу случайности, то, как мы ее понимаем. Очень живо и понятно написано, без занудства.

Автор текста, Успенский, кстати, очень крутой был чувак - https://ru.wikipedia.org/wiki/%D0%A3%D1%81%D0%BF%D0%B5%D0%BD%D1%81%D0%BA%D0%B8%D0%B9,_%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%BC%D0%B8%D1%80_%D0%90%D0%BD%D0%B4%D1%80%D0%B5%D0%B5%D0%B2%D0%B8%D1%87

Вел у меня матлогику, я (впервые) от него услышал фразу "пустое множество пахнет фиалками" :)

(Я правильно назвал 2 из 4 критериев, которые описаны в этом тексте. Это, конечно, не может не радовать!)

https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.html

Что-то вроде годового self assessment одного из разрабов LLVM.

Мне показалась интересной первая история, про типизированные указатели в LLVM IR.

TL;DR - Раньше с указателем был связан тип, а сейчас не связан.

Казалось бы - данных больше, они богаче, можно больше получить профита?

Но мир жесток, и, несмотря на то, что информации было больше, работать с ней было сильно сложнее (как-то трансформировать и передавать между разными optimization passes), поэтому, в итоге, более простая модель оказалась предпочтительнее.

Меньше потенциальных возможностей, зато профит можно молотить быстрее, и суммарно получается лучше.

https://www.phoronix.com/news/Qt-6.5-Beta-Released

Вышла бета qt 6.5, я стараюсь смотреть на новые релизы пораньше, потому что каждый новый релиз QT приносит мне какую-то новую боль (очень уж у них там большие затейники сборку пишут).

"Qt Grpc is the third new module that provides QtGrpc and QtProtobuf. With QtGrpc it enables communication with gRPC services and QtProtobuf for dealing with protobuf .proto-specifications"

Тут не исправить уже ничего, Господь, жги!

Купил себе планшет.

В последний раз попытка использовать планшет у меня с треском провалилась в конце 19 года. Я тогда купил себе только что вышедший и очень навороченный samsung galaxy s6 amoled, стоил он тогда, ну, скажем, 80к. Может, больше, но точно не меньше.

Характеристики можно посмотреть, например, тут - https://www.samsung.com/ru/tablets/galaxy-tab-s/galaxy-tab-s6-10-5-inch-gray-128gb-lte-sm-t865nzaaser/

Неделю назад мне пришел новенький https://aliexpress.ru/item/1005004733001677.html?sku_id=12000030865279571&spm=.search_results.3.28784aa6tLpBgu

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

Ну, то есть, аналог bleeding edge из 19 года сейчас является совершенным commodity, и стоит в 4 раза дешевле.

Про что этот пост?

Этот пост про то, что, через 30 - 40 лет (ЕБЖ, конечно), никто вам не нальет чашку кофе в ресторане, сколько бы у вас не было денег, просто потому, что, а зачем что-то делать, если можно вообще ничего не делать, и жить на ББД?

Давненько не было новостей про #ksmbd.

https://www.opennet.ru/opennews/art.shtml?num=58377 - сразу несколько CVE в этой поделке.

В целом, мне больше нечего добавить на эту тему, кроме того, что было уже сказано (разгон основной реализации через #uring лучше), и еще раз сказать, что не надо код в ядро тянуть, его надо оттуда убирать.

https://www.openwall.com/lists/oss-security/2022/12/21/6

Оч. смешная бага в парсере procfs. Все ломается, когда в имени процесса есть пробел.

Как-то уже писал, повторюсь. Я принципиально оставил в разрешенных путях для корня IX, и для имен #realm'ов только a-zA-Z0-9_, потому что как ты не экранируй, все равно какой-то инструмент на других символах сломается.

А про взаимодействие ядра и userspace - там везде, конечно, нужен машинно-генерируемый json, без ручных printf.

Я себе клятвенно пообещал, что у меня, в моей личной OS, будет только один syscall, принимающий json, и возвращающий json, все остальное будет мультиплексироваться полями этого json.

https://github.com/rui314/mold/releases/tag/v1.8.0

Вышла новая версия #mold. #money

Removed features:
* The experimental macOS/iOS support has been removed from mold. If you want to use it, please use our #sold linker instead.

В целом, дальше IMHO можно не читать, да и следить за проектом тоже - автор попал в классическую (блин, как летит время, она уже успела ей стать!) ловушку open core, когда фичи перемещают из бесплатной версии в платную.

Наверное, можно отметить, что коллеге подкинули денег от "Uber Open Source" - https://github.com/orgs/uber/sponsoring

Nevertheless, пожелаем этому господину удачи, потому что таких безумцев нашему миру явно не хватает!

#gold #rant про безопасность. Дисклеймер - это личное мнение автора этого блога, не имеющее никакого отношения к компании, в которой он работает.

Есть как бы "общепринятая" точка зрения, что "Security through obscurity" - плохо. Это уже стало мемом, catch phrase, и так далее.

Спросите безопасника, можно ли использовать этот механизм для защиты, и:

* Плохой безопасник рассмеется вам в лицо.

* Хороший - уточнит, как будет использоваться этот механизм, и является ли он основным.

Как вспомогательный механизм, security by obscurity - норм, и википедия, кстати, со мной согласна - https://en.wikipedia.org/wiki/Security_through_obscurity - читайте внимательно, не проглатывайте слова "main", "alone", и похожие.

Если смотреть на эту проблему шире, то безопасность - это не про "безопасно" vs. "небезопасно", а про вероятность.

Почему-то безопасники склонны подходить к проблеме иначе - они ищут параметры в системе, при которых систему можно обмануть, находят, вешают ярлык "not secure", и считают, что хорошо сделали свое дело. Это интересно, но имеет мало смысла, потому что в любой реальной физической системе есть дыра.

Это, конечно, в корне неверно. Нужно считать вероятности исходов, умножать их на возможные потери от исходов, и минимизировать сумму (например).

Почему второй подход не очень принят?

У меня есть два предположения на этот счет:

* Потому что коллеги не очень понимают, что это правильно.

* Понимают, но ничего сделать не могут - такой анализ довольно дорого стоит.

(Есть и третий вариант: все все понимают, но обосновать бюджет гораздо проще лозунгами "у нас тут 100500 малозначащих дыр, давайте их пофиксим, и станет 'безопасно'", чем скучными цифрами про вероятность. Его я решительно отвергаю, как маловероятный)

(Еще раз повторю: все совпадения - случайны, этот текст написан по мотивам обсуждения одного из моих постов про "замороженную энтропию" с несколькими коллегами)

Я, между прочим, запилил первую версию CI - https://github.com/pg83/ix/blob/main/pkgs/die/scripts/ci

Нет, я не упоролся, это вот такой вот CI - 75% пользы за 1% вложений.

Раньше у меня не было знаний про то, как ломают сборку новые версии софта, а теперь они, в каком-то виде, есть.

Могу сделать ssh на сборочный сервер, и сделать там tail на лог.

Думаю, так оно проработает довольно долго, пока не кончится место, и нужно будет что-то радикально улучшить.

Ладно, на самом деле, основная работа в этой задаче была связана не с этим скриптом, а вот с этим вот списком - https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/ix.sh, и починкой всех пакетов, которые должны собираться.

Кстати, проект принимает посильную помощь, и, если у вас есть свободные 8cpu/16gb(еще лучше - 16cpu/32gb), и желание повозиться с CI, github actions, и всем таким прочим - пишите.

https://emiruz.com/post/2022-12-28-composable-sql/

Коллега генерит SQL запросы, используя M4. Это тот самый M4, на котором написаны autoconf макросы, и который отвечает за генерацию configure из них. Наверное, один из самых старых макропроцессоров.

Вспоминается анекдот:

Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.

https://github.com/lite-xl/lite-xl

Классный текстовый редактор, и весьма грамотно сделан.

* Очень небольшая поверхность взаимодействия с системой - буквально, пара десятков довольно простых функций, типа, "отобразить текст", "нарисовать прямоугольник" (кстати, довольно эффективно - https://github.com/lite-xl/lite-xl/blob/master/src/rencache.c#L21) - https://github.com/lite-xl/lite-xl/blob/master/src/api/renderer.c#L354, и поверх этих абстракций стройтся весьма приятный GUI.

* Отрисовкой (скорее даже настройкой контекста) занимается SDL. Это очень правильно, потому что SDL гораздо легче монструозных библиотек, типа QT/GTK, особенно если от GUI нужен всего лишь framebuffer. Есть ощущение, что SDL не любят за пределами gamedev, и зря.

* Вся логика написана на Lua, и потому весьма хакабельна.

https://www.phoronix.com/news/systemd-Git-Stats-2022

Количество коммитов в systemd по годам, или "а ты точно не хочешь использовать systemd?"

https://www.opennet.ru/opennews/art.shtml?num=58403

Градус безумия зашкаливает.

Некто Эрик Реймонд форкнул "ntp classic", для повышения безопасности, и удаления неиспользуемого кода.

При этом:

* "Восстановлена поддержка протокола NTPv1 и проведена чистка его реализации"

* "В системе сборки восстановлена поддержка Python 2.6"

https://withinboredom.info/blog/2022/12/29/golang-is-evil-on-shitty-networks/

#rant по поводу того, что, как выяснилось, в гошечке сокеты по умолчанию не используют nagle.

Обсуждение на HN, https://news.ycombinator.com/item?id=34179426

Я, знаете ли, аж прослезился, потому что целиком и полностью на стороне авторов go, и, видимо, против большинства программистов.

Нужно создавать небуферизованный сокет в качестве основного, и буферизованный поток поверх него, явно. Потому что искать вот эти сотни миллисекунд во всякого рода RPC - то еще развлечение, если не знать про этот алгоритм.

Вот, и Расс Кокс пишет:

"I do remember why, though. At the time, I was working on a variety of RPC-based systems that ran over TCP, and I couldn't understand why they were so incredibly slow. The answer turned out to be TCP_NODELAY not being set"

Мне тут, конечно, не может не вспомниться одна из проигранных мной войн - про поведение файлового потока в нашей монорепе.

Когда-то, очень давно, TFileInput был небуферизованным, и, чтобы получить буферизацию, нужно было использовать вот такую вот конструкцию:

TFileInput fileInput("path");
TBufferedInput input(&fileInput);

Люди, конечно, часто забывали посмотреть на комментарии к этому классу, и считали, что TFileInput буферизован по умолчанию.

Дело осложнялось тем, что ReadLine() работал даже для небуферизованных потоков, с соответствующим проседанием performance, потому что строки читались по одному байту за раз.

Сообщество победило, и TFileInput стал буферизованным.

Как правильно?

КМК, правильно - не делать этот выбор (поведение по умолчанию) вовсе, и иметь TUnbufferedFileInput + TBufferedFileInput(ну или Socket), а решение уже за конечным пользователем.

Трактат "об одной особенности сборки grub".

При попытке собрать grub, без шаманства, получаю вот такую ошибку:

grub_script.tab.c:1123:9: error: variable
    'grub_script_yynerrs' set but not used
    [-Werror,-Wunused-but-set-variable]
    int yynerrs;

Понятно, что господа включили -Werror (чего нельзя делать по умолчанию, как я уже несколько раз писал).

При попытке добавить -w в CFLAGS начинает валиться configure скрипт, забавным образом:

checking for options to get soft-float... no
configure: error: could not force soft-float

Если заменить -w на -Wno-error, валится точно так же:

checking for options to get soft-float... no
configure: error: could not force soft-float

Получается, они там реально накостылили какой-то тест, который зависит от того, что какой-то конкретный конпелятор должен выдавать warning(который превращается в ошибку с помощью -Werror) на какой-то код!

В их configure есть опция --disable-werror, но с ней валится точно так же(потому что эта опция приводит к добавлению -Wno-error к CFLAGS в недрах configure)!

checking for options to get soft-float... no
configure: error: could not force soft-float

Ну, в общем, помогло только запатчить configure скрипт, указав, что этот тест таки выполнился корректно.

Занимался рутинным обновлением софта. #pkgconfig

Контур CI - это очень круто и удобно, потому что как я еще бы заметил, что, с новым libpcap, начала падать сборка wireshark?

Падать оно начало с очень странным сообщением об ошибке:

"ninja: Entering directory `/ix/build/mcpe98eHnOfPdF2O/obj'
ninja: error: '/ix/store/iDo8RMwHvMz5h6hQ-lib-pcap/lib/libpcap.a;/ix/store/3KBy5KQKrWQR6EuF-lib-nl/lib/libnl-genl-3.a;/ix/store/3KBy5KQKrWQR6EuF-lib-nl/lib/libnl-3.a', needed by 'run/tshark', missing and no known rule to make it"

Тут реально написано, что cmake сгенерил некорретный ninja файл - там где-то, в список зависимостей какой-то цели попала вот такая странная строка - 3 статических библиотеки, объединенных через ";"

На самом деле, тут довольно понятно, что cmake просто пишет туда какую-то строку, которую он получил из pkg-config, и там оказалось что-то неожиданное.

Вот diff в libpcap.pc двух разных версий библиотек:

Name: libpcap
 Description: Platform-independent network 
    traffic capture library
+Version: 1.10.2
+Requires.private: libnl-genl-3.0 
+Libs: -L${libdir} -Wl,-rpath,${libdir} -lpcap
-Version: 1.10.1
-Libs: -L${libdir} -lpcap

Подозрение, конечно, вызвало поле Requires.private.

https://people.freedesktop.org/~dbn/pkg-config-guide.html

"Requires.private: A list of private packages required by this package but not exposed to applications. The version specific rules from the Requires field also apply here"

Максимально запутанное объяснение, которое IMHO ничего не объясняет.

Я это понимаю как зачатки package management в pkg-config - набор библиотек, которые должны быть в системе (потому что они нужны по зависимостям каким-то .so в пакете)

В случае статических библиотек получаем вот такую вот странную шляпу, из всех абсолютных путей, объединенных через ;

Кто кого неправильно позвал или понял, я разбираться не стал, потому что информация про транзитивные зависимости у меня и так есть, не нужно ее дублировать в .pc файлах.

Поэтому я просто снес ее к херам из всех .pc - https://github.com/pg83/ix/commit/bac7f907bc4d8841e4eff9aba93c2a0bd765fc96

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

Вот, например, фикс, который нужно применять ко всем файлам meson.build - https://github.com/pg83/ix/blob/main/pkgs/die/c/meson.sh#L107-L109

К сожалению, в meson (и в cmake, но не в autoconf!) автор сборочных скриптов может сказать "а вот это собери как .so, даже если пользователь пакета попросил собраться статически", без возможности override.

Как говорится, факир был пьян, фокус не удался!

Фикс для .pc файлов пришлось откатить, потому что очень нетривиальным образом это сломало сборку одной важной программы - webkit.

Не буду вдаваться в подробности, но там очень замороченная сборка, которая использует разный набор путей поиска заголовков, потому что часть кода они собирают с нативным EGL, а часть кода - со своим враппером, #ANGLE, и это нетривиальным образом ломается от комбинации "мой враппер" + "принудительная починка .pc файлов".

Видимо, вместо "сделать все за один раз" придется откусывать слона по частям.

https://www.opennet.ru/opennews/art.shtml?num=58392

К прошлогоднему тексту про opennet добавить нечего, он остается лучшим источником текстов на почитать.

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1369649173

#harfbuzz

На этот раз в тикет пришел великий и ужасный Матиас Класен (я правильно транслитерировал?) - это тот человек, который виноват во всем плохом, что случается в #gtk и #gnome, и снова рассказал, что "ничего нельзя сделать", но я так просто их не отпущу :))

https://www.schneier.com/blog/archives/2023/01/breaking-rsa-with-a-quantum-computer.html

Гля чо пишут - сломали 2048 bit RSA на современных нам квантовых компухтерах, без миллионов кубит!