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/

Будни #bootstrap

Все же знают историю про то, что размер спейсшаттлов является прямой функцией от ширины задницы лошади?

Вот, в паре скриптов в пакете с gzip нашел прекрасное:

# WARNING: the first line of this file must be either : or #!/ix/store/gF4xURAJ
as4kd5vU-bin-dash-sh/bin/sh
# The : is required for some old versions of csh.
# On Ultrix, /ix/store/gF4xURAJas4kd5vU-bin-dash-sh/bin/sh is too buggy, change
 the first line to: #!/ix/store/gF4xURAJas4kd5vU-bin-dash-sh/bin/sh5

Что тут написано?

Что когда-то, очень давно, в этом скрипте стояли прямые ссылки на /bin/sh, и вот про них было написан комментарий людям, которые бы редактировали этот shell script - мол, под каким-то там Ultrix (что это?) /bin/sh может не работать, берите /bin/sh5.

Но, после серии рефакторингов, и, насколько я понимаю, замены прямой ссылки на /bin/sh на ссылку на shell, найденный в момент выполнения ./configure, случился такой странный казус.

Получается, что мой dash, лежащий в /ix/store, может так себе работать под какой-то несуществующей OS.

https://lobste.rs/s/lgwcpb/statement_regarding_ongoing_sourcehut#c_zz1to9

Из обсуждения этой темы на lobste.rs узнал, что #ddv (ну и еще парочка его коллег) был там забанен пару лет назад, за слишком агрессивный маркетинг sr.ht, https://en.wikipedia.org/wiki/Rage_farming.

Это, конечно, немного в другом свете освещает историю про нападки #ddv на #hyprland https://xn--r1a.website/itpgchannel/1337

#gnu, невменяемые мейнтейнеры

Я как-то рассказывал, что слежу за свежими апдейтами через repology.org. И там, довольно регулярно, настолько, что я обратил на эту странность внимание, ровно про две программы, приходит новая версия, в довольно странном формате - readline 8.2_p10, bash 5.2_p26.

Довольно долго не понимал, что же это за _pX, в "гнусном" ftp/http лежат вот ровно эта версия - 8.2 - https://ftp.gnu.org/pub/gnu/readline/

Оказывается, _p10 - это вот патчи из https://ftp.gnu.org/pub/gnu/readline/readline-8.2-patches/, которые нужно скачать отдельно, и наложить на основные исходники.

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

https://github.com/pg83/ix/blob/main/pkgs/lib/readline/ix.sh#L3-L26

Мягко говоря, не очень удобно, надо вручную прописывать url, sha, и накладывать патч.

В первый раз такое вижу.

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