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 композитор/пакетный менеджер, то он сможет построить надежный распределенный сервис? Это, вообще говоря, не очень связанные умения и навыки.

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

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

#rant

https://www.phoronix.com/news/GNU-Hurd-x86_64-2023-Progress

Не понимаю, зачем кто-то вообще пишет новости про #gnu #hurd. Пациент, совершенно точно, мертв.

Вот, например, цитата от его разраба:

"Building packages is not very stable. I have been trying to build gcc-13 for a couple of weeks, without success so far. There are various failures, most often odd errors in the libtool script, which are a sign that the system itself is not behaving correctly. A way to reproduce the issue is to just repeatedly build a package that is using libtool, sooner or later that will fail very oddly.

This means that while the buildd will be ready, I'm really not at ease with letting it start, knowing that it can behave erratically. When I built the initial set of packages for debian-ports (~100 packages), I got something like 5-10 such failures, that's quite high of a rate :/"

Курам на смех, конпелятор пересобирается через раз, рандомные bash скрипты падают со странными ошибками, и оно не может пересобрать себя из под себя (то есть, не self hosted).

https://outage.sr.ht/

Пара цитат:

"In our emergency planning models, we have procedures in place for many kinds of eventualities. What has happened this week is essentially our worst-case scenario: “what if the primary datacenter just disappeared tomorrow?” We ask this question of ourselves seriously, and make serious plans for what we’d do if this were to pass, and we are executing those plans now – though we had hoped that we would never have to"

Вот любой человек, который занимается инфрой профессионально, вам скажет - "не надо гадать/молиться/надеяться, надо проверять". Надо регулярно actually отключать ваш самый важный ДЦ, и убеждаться, что вы без этого работаете, или делать задачки, чтобы оно после этого работало.

"Unfortunately, our colocation provider went through two acquisitions in the past year, and we failed to notice that our account had been forgotten as they migrated between ticketing systems through one of these acquisitions. Thus unable to page them, we were initially forced to wait until their normal office hours began to contact them, 7 hours after the start of the incident"

Какой отсюда надо сделать вывод?

* Мелким потребителям не дают прямой телефон людей, которые что-то могут реально сделать в ДЦ. Крупным - дают, или у них свой крупный ДЦ.

* Люди, которые не занимаются инфрой постоянно, проигнорируют проблемы у провайдера ровно до тех пор, пока оно не выстрелит.

Вообще, хороший текст, почитайте.

https://www.reddit.com/r/programminghorror/comments/18x7vk9/why_does_everyone_keep_telling_me_to_use_c/

Утащу из комментариев, это прекрасно.

https://mstdn.social/@RickyRomero/111666711075000961

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

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

https://blog.tenstral.net/2024/01/wayland-really-breaks-things-just-for-now.html

Классный текст про #wayland.

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

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247

Хочу подробнее остановиться на

"Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps"

Здесь аккуратно написано про следующий факт - люди, которые могут закоммитить новый протокол в wayland (например, позволяющий точно позиционировать окна), по странному стечению обстоятельств, являются стейкхолдерами (в том или ином виде) в kwin(KDE)/gnome shell/wlroots.

И вертели они на хую любые предложения и протоколы, которые не вписываются в их модели работы с десктопом в целом, и окнами приложений, в частности.

Вот, например, зачем человеку, который отвечает за все tiling композиторы принимать proposal, в котором можно разрешить приложению управлять своим положением на экране?

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

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

Собственно, это все описано вот тут - https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%81%D0%B5%D0%BD%D1%81%D1%83%D1%81#%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0

Что с этим делать - непонятно, потому что у владельцев репы с wayland-protocols нет никаких стимулов что-то менять (https://cyclowiki.org/wiki/%D0%9F%D1%87%D1%91%D0%BB%D1%8B_%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2_%D0%BC%D1%91%D0%B4%D0%B0 ), а всем остальным договориться о том, чтобы брать эти протоколы из другого места, кажется нереалистичным.

https://asahilinux.org/2024/01/fedora-asahi-new/ #asahi

Кажется, проблемы с батарейкой коллеги тоже научились решать.

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

Печалит то, что, для того, чтобы достигать приемлемого уровня качества сервиса, коллегам приходится распихивать по всему стеку Linux подпорки для оборудования от Apple, что-то типа "классной психоакустической модели для встроенных в ноутбук колонок в виде plugin к pipewire", и написано оно все на Rust - https://github.com/chadmed/bankstown, то есть, повторить (в #stal/ix) это будет совсем не просто.

Я уже как-то писал, что совсем не понимаю экономику этого проекта. Вот откуда у них там человек, который разбирается в психоакустике, и может, основываясь на результате каких-то измерений, запилить плагин к pipewire на rust?

Я или переоцениваю сложность этой задачи (например, потому что ничего в этом не понимаю), или там какое-то совершенно дикое количество энтузиастов, среди которых есть и такие специалисты. Кода там не очень много, но он весьма специфичный - https://github.com/chadmed/bankstown/blob/main/src/lib.rs

#gnome moment

https://discourse.gnome.org/t/dealing-with-glib-and-gobject-introspection-circular-dependency/18701

В полку сумасшедших прибыло - теперь у нас официально есть кольцевая зависимость glib <-> gobject-introspection (вдобавок к https://xn--r1a.website/itpgchannel/202).

Нормальные люди (оценочное суждение) кольцевые зависимости рвут, ненормальные - документируют, и потом, втихую, наслаждаются страданиями package maintainers.

Иииии rust наносит ответный удар!

https://www.phoronix.com/news/GCC-Rust-Developer-Discussion
https://lore.kernel.org/git/CALNs47s3tUQoOD4ejdoTn6y12ywjL0j5hWU-fUnBLe_o3vV5SQ@mail.gmail.com/T/