Снова загружен работой, не до разбора отчета( А пока шутка с внутреннего ресурса:

Сложный код создает сильных инженеров,
сильные инженеры создают простой код,
простой код создает слабых инженеров,
а слабые инженеры создают сложный код.

Приятно осознавать себя на острие прогресса!

Вот, я недавно (ну как "недавно", в первый раз так-то в 22 году, когда я только начал этот quest) писал про #TMPDIR, и тут, внезапно:

https://dotat.at/@/2024-10-22-tmp.html

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

https://systemd.io/TEMPORARY_DIRECTORIES/

А потом и авторы #systemd подтянулись (они вообще горазды пиздить у меня годные идеи, типа https://www.tgoop.com/itpgchannel/1871 #suid). Чуть менее годный, но тоже неплохой, текст, на эту тему. Решение проблемы, которое озвучивается там, мне не нравится.

К сожалению, оба текста недостаточно радикальны.

Софта, в котором захардкожено /tmp или /var/tmp, не так уж и много, и его надо патчить, и исправлять. Надеюсь, теперь это станет mainstream, и кода, который хардкодит эти значения, со временем станет меньше.

https://lore.kernel.org/all/3448a096-849a-4f61-8017-c03a83e22c38@gmail.com/

https://lore.kernel.org/all/20241024095339.GA32487@imap.altlinux.org/

Линус хотел русских троллей, он их и получил.

PS: не надо так делать. Это просто мелочно.

PPS: https://lore.kernel.org/all/20241024095708.189649-1-isage.dna@gmail.com/ - тред уже свели к ad Hitlerum, можно расходиться.

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

Очень годный текст, дает ответы на все накопившиеся вопросы про произошедшее.

Полностью согласен!

В общем, решил эту проблему тем, что отказался от amd_pstate=active (это когда amd_pstate является и scaling driver, и своим же гувернером), в пользу amd_pstate=passive (это когда amd_pstate - только scaling driver) + schedutils в качестве гувернера.

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

Чтобы этот режим заработал, пришлось обновить BIOS.

А, так как ноут китайский (https://www.tgoop.com/itpgchannel/1806), не для внешнего потребления, то это превратилось в небольшое приключение.

Lenovo раздает bios update для моего ноута исключительно в виде exe, который надо запустить под windows 11. Понятное дело, что китайский windows я снес с этого ноута в первые же 10 минут использования.

Проблему обновления я решил с помощью васянской сборки windows 11 live usb, бывают и такие (https://www.hirensbootcd.org/, https://msfree.su/index.php?threads/635/). Вирусов я боялся не очень, потому что куда бы оно мне их установило?

В xfs раздел, или в efi раздел?

Насчет второго я даже немного запараноил, и снял с него все хеши всех файлов, проверил потом до и после загрузки в live cd.

Будни #bootstrap, #mesa, #opengl

В https://www.tgoop.com/itpgchannel/1350 писал про то, как ловко я обошелся с плагинной системой Mesa.

Все шло хорошо, пока разработчики mesa не решили перестать жить во грехе (это когда они делали вид, что отдельные их драйвера - это #plugins, которые как бы не зависят от ядра, и могут быть загружены в runtime), и начали жить как все нормальные люди.

В релизе 24.2.X, они, тихо и незаметно (ну или я не нашел в changelog), стали линковаться с libgallium.so, вместо того, чтобы загружать ее, как драйвер.

Кажется, я должен был быть очень доволен, всратых плагинов стало меньше?

С одной стороны, да, а с другой - я уже привык к тому, что сборка mesa в два этапа (отдельно ядро, и отдельно драйвера) позволяет мне делать зависимость от драйверов только у конечных программ, а не у всего кода, которому зачем-то нужно скомпилироваться с заголовками от opengl, но в runtime opengl не используется. Ну и cache hit так при сборке больше.

Поэтому я взял да и плагинифицировал эту часть mesa взад.

Собственно, это было очень просто, ядро mesa зависит от от libgallium.so всего по одной функции - https://github.com/pg83/ix/commit/04c0c3c9d6392089f2ea452d70c354cf22ae1c0f#diff-028186b4b1abb1353b6639ea94857e1aa9c5a91debd070b864799052bb502644R5 Раньше она загружалась через dlopen, а сейчас связывается во время линковки.

Ну так я и запилил stub, который вызывает dlopen (который, напомню, у меня не настоящий dlopen, а статически слинкованная фабрика - https://www.tgoop.com/itpgchannel/1230), чтобы все работало "как раньше", и чтобы можно было связать драйвер с приложением только в момент линковки этого приложения!

https://discourse.nixos.org/t/nix-team-member-suggests-removing-flakes-data-suggest-it-isnt-a-good-idea-please-remove-the-experimental-flag-instead/54959

Как известно, nix един в трех Ф:

* Фурри
* Фембои
* Флейки (flakes)

Вот, третий столп у них хотят выбить из под ног.

Зачем?

Я понятия не имею, давно запутался в их Санта-Барбаре, и перестал следить.

Вот, кстати, мой вариант dev env:

pg# ix run \
    bin/bash/5 \
    bin/coreutils \
    bld/compiler \
    -- bash
pg# llvm-nm --version
llvm-nm, compatible with GNU nm
LLVM (http://llvm.org/):
  LLVM version 19.1.2
  Optimized build.
pg#
exit
pg# llvm-nm --version
bash: llvm-nm: command not found
pg#

Можно обернуть в какой-нить run.sh, можно даже сделать команду ix env, но зачем, непонятно, потому что и так хорошо.

Фиксацию зависимостей я заменяю на предложение брать #ix из определенного коммита, или делать overlay.

Зачем уметь фиксировать версии всех зависимостей, с одной стороны, понятно, а с другой, много понятных проблем:

* Помимо фиксации версий, все равно, надо привязываться к конкретной версии nixpkgs, иначе под вами могут просто убрать пакет (переименовать).

* Общий срез пакетной базы прогоняет автосборка, а случайных набор версий пакетов она не прогоняет.

Поэтому lock файл я пока делать не хочу.

Предлагаю создать Министерство Linux'а.

Минцифры планирует создать собственное Linux-сообщество для разработчиков из стран, готовых сотрудничать с Россией. Такое решение — реакция на отстранение российских разработчиков от мирового IT-сообщества
. . .
Панченко указал, что будет правильно, если новый форк Linux будет сделан сообществом стран, а не отдельной страной. «Это прибавит веса и авторитета. Но чтобы это сообщество заработало, России придется в нем быть лидером и донором программного кода и экспертизы в его разработке. Но есть важное препятствие — в России не так много разработчиков такого уровня, чтобы мы могли полностью взять на себя ответственность за ядро операционной системы. Поэтому важно срочно растить свои кадры», — рассуждает Панченко.
. . .
Идея Минцифры создать собственное Linux-сообщество выглядит слишком амбициозно, считает член совета директоров российского разработчика НТЦ ИТ РОСА и компании «Рутек» Сергей Кравцов. «Не стоит ожидать, что в официальной ветке Linux будут приняты изменения от российского сообщества. Основные решения относительно развития ядра Linux, по сути, будут оставаться международным сообществом, даже если Минцифры организует локальную команду разработчиков», — считает он.

Минцифры предложило создать собственное Linux-сообщество
https://www.rbc.ru/technology_and_media/28/10/2024/671e424c9a7947704249be2c

https://mitchellh.com/writing/ghostty-is-coming #ghostty #terminal

Тут вот коллега хочет запилить еще один "самый лучший" эмулятор терминала.

В тексте, конечно, есть (притянутое за уши) сравнение, которое объясняет нам, почему же ghostty будет лучше всех, но, на самом деле, это сравнение выглядит так:

          Zig
Alacritty -
Kitty     -
iTerm     -
Ghostty   X

Отдельно доставил пассаж про

"For "platform-native", Ghostty uses the native GUI toolkit on macOS and GTK (plus libadwaita if available) on Linux. This means that Ghostty looks and feels (and really is) a native application on both platforms. This is in contrast to many terminal emulators that use the native GUI toolkits only to create a window"

Вот что у этих людей творится в голове?

обычный вторник

https://www.rbc.ru/technology_and_media/29/10/2024/671fd2389a794726b01d3af3

Что экспонента животворящая делает, а?

"Требования российских телеканалов к Google достигли ₽2 ундециллионов"

Надо нашим законодателям рассказать про https://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F_%D0%90%D0%BA%D0%BA%D0%B5%D1%80%D0%BC%D0%B0%D0%BD%D0%B0, вообще хорошо будет.

https://opensource.org/blog/the-open-source-initiative-announces-the-release-of-the-industrys-first-open-source-ai-definition

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

OSI опубликовали критерии того, может ли считаться AI модель open source.

Критерии, в целом, мутные.

Ждем теперь, когда FSF опубликует критерии свободной AI модели!

По мне так это все чушь, open source AI model - это когда исходники применялки идут под открытой лицензией.

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

Понимаю коллег, хочется бесплатно и побольше, но получается какая-то херня.

#llvmweekly #rant

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696

TL;DR - хочется уметь красиво выводить в отладчике не встроенные типы, для этого предлагается завести секцию, в котороую писать bytecode, который умеет выводить на эран те или иные типы в программе.

Почему не положить туда готовые python форматтеры, которые уже есть, и написаны?

"The logical next step would be to store full Python formatters instead of summary strings, but Python code is larger and more importantly it is potentially dangerous to just load an execute untrusted Python code in LLDB.

To address these problems, I’m proposing a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers"

Объяснение не стоит и выеденного яйца, потому что ТЫ УЖЕ ЗАПУСТИЛ этот бинарь, запусти и Python, в песочнице.

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/10

Или возьми готовый VM, в который llvm уже умеет (hint - #WebAssembly, #bpf, #ebpf https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/12).

Но нет, это было бы слишком просто, на таком фиолетовое не получить.

Вообще, удивительно, в маленький #harfbuzz тащат большой #WebAssembly (https://www.tgoop.com/itpgchannel/1201), а в большой LLDB (который уже умеет в #WebAssembly) тащат самопальный байткод...

Где логика-то?

Тут прямо Уотергейт для проклятого SJW #ddv

https://dmpwn.info/

TL;DR - обвиняют в педофилии, не меньше.

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

Рубрика "новости из дурки".

https://habr.com/ru/articles/853972/