С наступающим

Хэнк Муди II SWEET MEMES

https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html

Gentoo goes Binary!

Мне это, конечно, кажется странным.

Прелесть gentoo, на мой вкус, исключительно в ее use флагах. Без них - ну arch и arch, найдите 5 отличий, как говорится.

Если распространять бинарные сборки только для самых популярных наборов флагов - то cache hit у такой инсталляции должен быть очень мал.

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

По слухам, админ канала только проснулся, и начал доедать оливьешечку, и до новостей из мира IT ему пока дела нет, чего он и вам желает!

Вот я балда - КДПВ нарисовал, а текст добавить забыл.

https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html
https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html#motivation

PyPy переезжает в github.

"Open Source has become synonymous with GitHub, and we are too small to change that"

Продолжим славную традицию репоста новогоднего дайджеста от opennet, они лучшие!

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

https://medium.com/@catamphetamine/how-github-blocked-me-and-all-my-libraries-c32c61f061d3

А вот, например, текст от коллеги, которого забанили на #github за обращение (literally) "Ты - пидор!". В целом, думаю, github тут вполне в своем праве, потому что для такого рода общения есть другие места.

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

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

Умер Вирт.

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

Я начинал программировать на его "алгоритмы + структуры данных == программы", и, конечно, с Паскаля.

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

Сухо, лаконично, без излишнего "сахарка" (которым сейчас часто заменяется программирование). Очень "системно", все разложено по полочкам.

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

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

Очень смешная "атака" на npm - пакет, который зависит от всего npm. Не сам, через пару слоев, потому что, видимо, естьограничение на число прямых зависимостей.

Самое примечательное:

"Во-вторых, публикация пакета "everything" фактически заблокировала возможность удаления любых пакетов в NPM, которые оказались в списке его зависимостей. Пакет из NPM может быть удалён автором только если он ещё не используется в зависимостях других пакетов, но после публикации "everything" зависимостями оказались охвачены все пакеты в репозитории. Примечательно, что удаление самого пакета "everything" также оказалось заблокированным, так как 9 лет назад в репозитории был размещён тестовый пакет "everything-else", в котором была указана строка "everything" в списке зависимостей. Таким образом, пакет "everything" после публикации оказался в зависимостях у другого пакета"

Интересно, сколько это тулинга вокруг npm поломало.

Ждем повторения с pypi, cargo, etc?

#rant #gold #reboot

Никогда, никогда не пилите graceful shutdown.

Нажали на кнопку exit/ctrl-c, программа сохраняет все открытые файлы, если это gui программа, а дальше просто exit(0) _exit(0).

Нет, вот зачем-то люди хотят корректно финализировать все инициализированные подсистемы, завершить треды, и так далее.

Нахрена? Какой в этом физический смысл?

Это было важно в OS без защиты памяти (DOS/Windows 95-98-Me), но сейчас-то зачем?

Этот код:

* Никто и никогда нормально не тестирует

* Имеет тенденцию вызывать graceful shutdown от зависимых библиотек, а в нем его тоже никто и никогда не тестирует!

* Имеет тенденцию работать в странных контекстах (signal handler (никто не умеет писать корректные sighandler!!!), atexit, и так далее), а не в обычном flow выполнения программы. (сука, а если там кто-то еще пытается выводить stack trace - то обычно это леденящий душу пиздец по умолчанию)

Вот есть такая https://github.com/WerWolv/ImHex

Она зовет graceful shutdown от библиотеки glfw, причем НЕОЖИДАННО делает это несколько раз - при каждом открытии и закрытии splash screen - https://github.com/WerWolv/ImHex/blob/master/main/gui/source/init/splash_window.cpp#L545

И что бы вы подумали?

Код очистки glfw, в каком-то сраном коде по очистке данных для linux joystick, который никто и никогда не вызывал, не отлаживал, и вообще, всем посрать, что он делает 1 раз при выходе из программы, содержит double free, в вызове regfree() - https://github.com/glfw/glfw/blob/e2c92645460f680fd272fd2eed591efb2be7dc31/src/linux_joystick.c#L337-L348 !

(в транке, кстати, пофикшено уже)

Мораль?

* Не надо маниакально пытаться позвать все cleanup функции, а еще лучше, кладите на них с прибором, OS разберется.

* Всегда нужно рассчитывать на самый плохой вариант, что комп будет выключен по hard shutdown, и писать код соответствующе. А это значит, что нельзя рассчитывать на то, чтобы хоть какой-то cleanup был вызван.

Будни #bootstrap, #cmake #rant

После обновления на новую версию leptonica стал падать cmake configure у проекта tesseract:

-- Configuring done (1.5s)
CMake Error at /ix/store/RvksJ51kmglEFEW1-lib-leptonica/lib/cmake/leptonica/LeptonicaTargets.cmake:61 (set_target_properties):
  The link interface of target "leptonica" contains:

    WebP::webp

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Тут написано, что, мол, найденная leptonica зависит от WebP, но WebP не может быть найдена.

Раскопки привели вот к такому сниппету cmake кода, который был автоматически сгенерен cmake-ом в недрах кода, который он строит для каждого установленного таргета, для поиска его зависимостей:

include(CMakeFindDependencyMacro)
if ()
    find_dependency(OpenJPEG CONFIG)
endif()
if ()
    find_dependency(WebP 0.5.0 CONFIG)
endif()

Вот этот вот if () - это как? Это в каком таком ЯП может вычислиться, и выдать какой-то результат?

Если заменить это на if (TRUE), то configure проходит корректно, конечно.

Будни #bootstrap

Я тут, на праздниках, переделал сборку ядер для #stal/ix

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

Плоский список файлов выглядел как-то так:

https://gist.github.com/pg83/26c276b0289de676a3162a9c797d3926

Погулять по структуре директорий можно тут:

https://github.com/pg83/ix/tree/2dd56c555d97333a778dd26907e5c70f02c80360/pkgs/bin/kernel/6

Я решил это схлопнуть с помощью своего механизма #VFS:

https://xn--r1a.website/itpgchannel/221
https://xn--r1a.website/itpgchannel/1093

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

До сего момента я этот vfs использовал только для погружения pypi в свое дерево:

https://github.com/pg83/ix/blob/2dd56c555d97333a778dd26907e5c70f02c80360/pkgs/pip/mount.py

А сейчас я запилил такой vfs для сборки ядер:

https://github.com/pg83/ix/blob/main/pkgs/bin/kernel/mount.py

Этот скрипт берет список интересных мне ядер из https://github.com/pg83/ix/blob/main/pkgs/bin/kernel/kernels.json, и из каждого такого описания "монтирует" в дерево пакетов пакеты, нужные для сборки того или иного ядра (на каждое ядро надо несколько пакетов - как минимум, отдельный пакет с kernel headers для заданного ядра)

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

# ./ix build bin/kernel/6
^ самое новое ядро из ветки 6.X

# ./ix build bin/kernel/6/1 
^ самое новое ядро из ветки 6.1.X

# ./ix build bin/kernel/6/1/57
^ просто какое-то ядро

https://www.phoronix.com/news/Arch-Linux-Dbus-Broker

Вот, теперь на это "поделие" (https://xn--r1a.website/itpgchannel/531, в кавычках, потому что полтора года назад (как летит время!) часть моих комментаторов почти убедили меня, что какой-то профит от этой штуки есть) переезжает Arch. Печаль, беда, придется собрать для нее 100500 самопальных велосипедных библиотек, которые никто за полтора года так и не поюзал - https://github.com/bus1/dbus-broker/blob/main/meson.build#L24-L29

https://mazzo.li/posts/stopping-linux-threads.html

#pthread_cancel

Неожиданно очень годный текст.

Причем, что интересно, когда я только начал его читать, то подумал, что это опять что-то зумерское, в стиле "ааа async thread cancellation не работает ааа", и не стал читать дальше первой страницы.

Но, вот, сегодня дочитал, и не пожалел.

Сначала автор, действительно, рассказывает, почему разные схемы async thread cancellation не работают, и приходит к простому и понятному решению - а заведите флажок, и, перед вызовом каждой блокирующей функции, проверяйте его, ну и выходите, если он взведен (например, через signal handler).

При этом, он совершенно корректно, говорит, что данное решение - несколько racy, потому что есть момент между тем, как мы проверили флаг, и начали выполнять этот syscall, когда флаг таки может быть взведен!

(часто на это можно наплевать, потому что одним syscall больше, одним меньше - пофиг)

И предлагает хорошее решение этой проблемы, через rseq. Конкретно, как превратить вообще любой системный вызов в точно такой же вызов, но с (атомарной!) проверкой какого-то булева флажка перед непосредственно блокировкой - https://mazzo.li/posts/stopping-linux-threads.html#rseq.

Собственно, это самая интересная часть текста, остальное можно не читать, потому что оно "всем известно, и никому не интересно".

Вот, примерно 2 года назад я озвучил одну из повторяющихся в рамках этой моей площадки тем - "нельзя писать ядро на С, но, так как Линус не может потерять лицо (https://harmful.cat-v.org/software/c++/linus), то пусть хоть Rust, а не С++, несмотря на то, что, c практической точки зрения, С++ подошел бы лучше".

За это время Rust успел попасть в ядро, и, вот, пожалуйста:

https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-29361481f805@zytor.com/

Очень конкретный, очень практичный текст про возможный перевод ядра на С++, от одного из уважаемых kernel hacker.

Это, конечно, будет бомба, если благодаря Rust ядро начнут перепахивать на С++!

https://fosstodon.org/@drewdevault/111739063243946284

sr.ht/codeberg лежат второй день подряд.

И я, как обычно, когда лежат васянские гиты (а sr.ht/codeberg/прочие gitlab - это все васянские гиты), призываю все проекты иметь заркала на github.

Слушайте, ну меня это реально сильно, прямо сильно удивляет.

Почему есть мнение, что "ddos может отразить каждый", "надежная инфра - это просто", "этим может заниматься кто угодно", и так далее?

Почему считается, что, если человек написал компилятор/операционную систему/wayland композитор/пакетный менеджер, то он сможет построить надежный распределенный сервис? Это, вообще говоря, не очень связанные умения и навыки.

Вот, реально, кесарю - кесарево, а слесарю - слесарево.

Не используйте васянские сервисы, или имейте зеркало где-то еще.