Вечерний #rant

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

Мы живем в мире, в котором про любую мелкую херню есть или "проект", ну или "специализированный дистрибутив Linux".

Вот по ссылке нечто, с громким названием:

"новый проект etcd-await-election, который позволяет выполнять операцию "leader election" на нескольких узлах с помощью распределённого хранилища etcd, для того чтобы гарантировать выполнение только одного экземпляра процесса в кластерных окружениях"

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

etcdctl lock ${path} /bin/sh -- \
    -c "ip addr add ${addr} dev eth0; sleep 1000"

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

В etcd из коробки есть возможность выполнить любую команду под блокировкой в этом же etcd, зачем городить огород, и затевать "проект"?

#bootstrap #terminal #rant #cosmic

https://www.phoronix.com/news/Pop-OS-24.04-Alpha-8-August

Тут вон пишут, что скоро выйдет альфа COSMIC desktop.

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

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

https://gist.github.com/pg83/777521db03c528bbeadbf90befc551f7

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

Нуачо, все перепишем на Rust, и проигнорируем традиционные способы эти шрифты найти.

Будни #bootstrap, #rant

Продолжу тему "gobject introspection" #gir

Во-первых, я собрал vala.

https://vala.dev/

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

Но собрать что-то содержательное им оказалось весьма сложно, потому что с внешним миром код на vala общается именно через gir.

А вот эти вот интерфейсные правила собираются очень хрупким образом - частично это парсинг исходников (а там дальше много интересного - какой препроцессор взять, clang, или gcc, какие туда передаются опции, и так далее), и частично - через загрузку интроспектируемого кода в специальном режиме, когда мы просим бинарник выплюнуть все сведения о зарегистрированных в нем типах в виде .gir файла (прощай, кросс-компиляция, ага).

С одним набором настроек собирается gir для libadwaita, но не собирается для libhandy или #harfbuzz (не спрашивайте). Пофиксил - отваливается что-то третье.

Собрать консистентно все gir для всех гномовых либ я пока не сумел, у меня нет столько времени.

В конце-концов, я нашел вот эту вот репку - https://github.com/gtk-rs/gir-files

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

Ну я и присоседился, беру эти файлы у них.

Вроде, как-то оно работает, но весь этот техпроцесс вызывает сомнение.

#rant #cosmic

Сподобился собрать https://lapce.dev/, просто чтобы позырить на GUI в Rust.

Вот, оно падает, с очень похожей диагностикой на cosmic-term, не совсем в том же месте, но по коду где-то рядом, не может найти шрифт:

https://gist.github.com/pg83/298157ce4f9296a690723c0eab41aa9e

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

Только чтобы не зависеть от C/C++ кода для рендеринга шрифтов? Или они там красивее?

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

Не согласны - ну, вот, по ссылке https://github.com/pop-os/cosmic-text/blob/main/src/shape.rs#L251 крейт и строчка кода, расскажите, как оттуда получить норм ошибку.

#rant, #plugins

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

Я, знаете ли, иногда поругиваюсь на #cosmic, и на то, что его пишут пионеры, но, на самом деле, очень пристально слежу за проектом, постепенно собираю его запчасти, и пробую использовать IRL.

Почему?

Потому что:

* Не на С. Будет падать не так часто.

* Без legacy GUI (GTK/QT - и то, и то, - говно лютое)

* И, самое важное, без всратых плагинов. Так уж получилось, что, в среде golang/rust, принято расширять программы не через dlopen(), а через что-то типа embedded scripting lang (e.g lua), или через subprocess + lightweight rpc (e.g \n-delimited json). Мне это безумно нравится, потому что это вполне aligned с тем, как я считаю "хорошо" и "правильно" (оценочное суждение, да).

К сожалению, несмотря на заявления, оно довольно жестко гвоздями прибито к PopOS, и у меня, например, пока не получилось заставить работать их wayland compositor, хотя собрать его получилось вполне.

Ждем, надеемся.

Рубрика "зумеры придумывают новые команды", #rant.

Решил я тут собрать еще парочку программ из #cosmic, и нашел у них в репах странные файлы:

https://github.com/pop-os/cosmic-panel/blob/master/justfile

Это, оказывается, такая замена для Makefile, только:

* безопастно, потому что на Rust (https://github.com/casey/just)

* стильно, модно, молодежно

Плюсов, видимо, не будет, потому что это калька с Makefile.

Сука, зачем, зачем повторять то, что уже работает? Вот, реально, повторять, потому что, как говорится, найдите 5 отличий (я не нашел).

Интересно, почему ее не взяли для https://t.iss.one/itpgchannel/2205?

https://www.phoronix.com/news/Linux-AutoFDO-Prop-v2 #rant

Тут вот Миша с похороника пишет, что, мол, PGO/FDO/#BOLT/Propeller ускоряют системы на базе Linux на 2-10%:

"In turn this can help Linux systems see 2~10% better performance thanks to the more optimized kernel"

Это, конечно, ЛПП, потому что Миша путает "Linux systems" и "Linux kernel".

Да, ядро эти технологии могут ускорить на несколько процентов, но, так как в нормальной Linux системе ядро жрет от силы 5% (потому что ядро, на самом деле, занимается, в основном, тем, что перекладывает указатели на буфера в памяти из одного места в другое (типа, сетевуха через DMA записала содержимое пакета в какую-то область памяти, ядро переложило указатель на этот буфер в какое-нить блочное устройтво, откуда, тоже через DMA, эту память прочел, например, контроллер дисков)), то и профит на всю систему мы получаем в пределах погрешности.

#rant

Многие инструменты, которые мы используем - они как swiss army knife.

И, знаете, очень бомбит, когда ты объясняешь человеку, что, чтобы открыть консервную банку, ему нужен консервный нож из поставки, а он тебе такой "нет, что это за херня, я все привык делать ножом, я и банку открою ножом, а твой консервный нож - это какой-то хак, с ним еще разбираться надо, в первый раз вообще вижу, смотри, как у меня классно ножом получилось"!

Надо знать и понимать используемые инструменты!

#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://t.iss.one/itpgchannel/1201), а в большой LLDB (который уже умеет в #WebAssembly) тащат самопальный байткод...

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

#rant

Каждый уважающий себя растаман считает своим долгом впендюрить какие-то свои сборочные настройки в release/dev profile. #cargo

Например, https://github.com/pop-os/cosmic-panel/blob/master/Cargo.toml#L16

Проблема в том, что эти дети не понимают, что творят.

Они, наверное, думают, что делают мне хорошо тем, что их программа у меня будет собираться в 10 раз дольше, и работать на полпроцента быстрее.

Нет, это не так.

Меня это, в конце-концов, заебало, и я решил это починить.

Благо, https://doc.rust-lang.org/cargo/reference/profiles.html это, вроде, позволяет - запили свой профиль, да передай его в cargo --profile.

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

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

* А если сделать наследование от profile.release, то я получаю в нагрузку все эти лютые донастройки от автора софта.

В общем, как обычно, пришлось решать проблему по рабоче-крестьянски, а именно:

* https://github.com/pg83/ix/blob/main/pkgs/bld/rust/devendor/scripts/strip.py - выпиздить к хуям все авторские экзерсизы. Я было хотел сделать честно, через парсинг toml, но, как оказалось, toml там уже совсем не toml (но об этом в другой раз), поэтому регулярочкой.

* https://github.com/pg83/ix/blob/main/pkgs/die/rust/cargo.sh#L130*-L137 - после выпиливания гениальной авторской мысли, доливаем свои, хорошие, настройки, в которых заведомо нет LTO.

Продолжаю свои страдания по rust. #rant

TIL что

cargo build --package A --package B

и

cargo build --package A
cargo build --package B

- это две разные команды!

Да, да, собрать два артефакта одновременно - это совсем не то же самое, что собрать их последовательно.

Как так получается?

Очень просто, #cargo, когда ему надо выполнить первую команду, строит объединение feature флагов этих двух пакетов, и собирает каждый их этих пакетов с объединением их флагов.

Вот и получается, что, по отдельности, пакеты собираются, а вместе - https://gist.github.com/pg83/d2b61ba29587503d58d191a98829f526

Такое ощущение, что разработчики cargo однажды решили, "а давайте вообще все сделаем по-другому". Не "хорошо" или "плохо", а просто иначе.

#rant

#cargo проектировали сумасшедшие (если его вообще проектировали).

Не верите - попробуйте выразить с помощью cargo "собери мне пакет X с набором фич по умолчанию, за исключением Y".

"Это никому не нужно"?

Ну, как сказать, вот есть у меня пакет, в котором есть ['A', 'B', ..., 'X11', 'wayland'], и я хочу исключить X11.

Спрашивается, что мне делать, и чего употребляли авторы cargo?

2024-ый год, cargo не умеет в -feature, ага. Про -feature_group я вообще молчу, это какой-то космос.

#rant

Продолжаем срывать покровы про #cargo.

Если вы делаете нативную сборку, то бинарники будут лежать в $CARGO_TARGET_DIR/$CARGO_BUILD_TYPE (release/debug)

А если кросс-компилируете, то в $CARGO_TARGET_DIR/$CARGO_TARGET_PLATFORM/$CARGO_BUILD_TYPE

Поэтому install скрипты, которые живут своей жизнью (а это все install скрипты для rust/cargo проектов, потому что cargo не умеет в сколько-нибудь разумный install) работают только или для нативной сборки, или только для кросс-сборки.

Указать этой ебанине блядской что-то в стиле "положи результат ВОТ СЮДА" - невозможно.

Вот, даже рукопожатный #COSMIC хардкодит эти пути (для нативной сборки только) - https://github.com/pop-os/cosmic-edit/blob/3d9240927588efe9a33e16c014979798f78e1d7a/justfile#L11-L13

#rant, #cargo

https://doc.rust-lang.org/nightly/rustc/platform-support.html

Rust считает, что x86_64-unknown-linux-gnu - triplet, описывающий платформу.

Я, наверное, долблюсь в глаза, но вижу тут 4 поля.

Задачка со звездочкой - где тут у Rust стоят группирующие скобки?

#rant

https://infosec.exchange/@wdormann/113625346544970814

"An EXT filesystem can tell the Linux OS how it should behave "if" the filesystem is corrupt, including triggering a kernel panic. In a world where USB thumb drives exist, this seems... not ideal"

Любое блочное устройство надо рассматривать как remote, со всеми вытекающими. Верхний уровень должен уметь делать retry, и указывать таймаут на любую операцию. Проблема в том, что современные FS делают это плохо, и не очень консистентно. Я как-то находил в коде XFS такие retry, но "плохо и мало".

С точки зрения пользователя FS тоже всегда должна рассматриваться как remote, со всеми вытекающими retry и указаниями таймаутов.

К сожалению, API unix такой, и вряд ли он поменяется, потому что огромные объемы софта полагаются на то, что "FS всегда есть под ногами".

#hyprland #rant

Рубрика "зумеры изобретают систему сборки".

Вот что вы делаете, когда система сборки не дает вам */** для исходников, а очень хочется?

(вопрос риторический)

Коллеги из #hyprland изобретают херобору:

https://github.com/hyprwm/Hyprland/blob/main/src/meson.build#L1

globber = run_command('sh', '-c', 'find . -name "*.cpp" | sort', check: true)

А то, что эта команда может зачерпнуть лишнего, и у кого-то появляется hard X11 dep, их, конечно, не волнует.

Будни #bootstrap, #rant

Обновлял rqbit.

Это который упаковывает кучу js кода себе в бинарь, и вызывает для этого npm - https://t.iss.one/itpgchannel/2410

Обновление упало с ошибкой - https://gist.github.com/pg83/cd1ec54f5a4fd4f2e5cfc4b82e063c12

TL;DR - при обновлении приехал новый https://vite.dev/, который притащил за собой новый https://github.com/rollup/rollup (не спрашивайте, это говно бандлит JS код в 1 файл), который переписали на "мамой-клянусь memory safe" языке (https://github.com/rollup/rollup/tree/master/rust), а чтобы не портить пользователям малину, положили в пакет предкомпилированные даже не бинари, а .so для nodejs.

Вона там их сколько, даже для loongson есть:

https://github.com/rollup/rollup/blob/master/package.json#L19-L37

(для #stal/ix нет, ага)

Да, да, никогда такого не было, и вот, опять, зумеры подложили очередную вирусню в репу очередной supply chain attack:

#blob

https://t.iss.one/itpgchannel/1281
https://t.iss.one/itpgchannel/1301
https://t.iss.one/itpgchannel/2264
https://t.iss.one/itpgchannel/2084
https://t.iss.one/itpgchannel/1789
https://t.iss.one/itpgchannel/535

Что я сделал?

Даунгрейднул все эти зависимости, и все заработало:

https://github.com/pg83/ix/blob/main/pkgs/bin/rqbit/ix.sh#L22-L23

Что я буду делать, когда оно перестанет так собираться?

Стану проституткой!

Не знаю, изучу JS, наушники с котоушками у меня уже есть https://t.iss.one/itpgchannel/2444.

Закончил читать шедевральный #rant https://izzys.casa/2024/11/on-safe-cxx/

Rant про состояние сообщества С++, rant огромный, читал я его, с перерывами, несколько дней. Если соберетесь - запаситесь попкорном, оно того стоит. Видно, что у человека просто бомбит от происходящего.

"In reality, this post isn’t really about Gaby Dos Reis, Herb Sutter, and the creator of C++, Bjarne Stroustrup. I lied. It’s about toxic masculinity (oh hey there’s that word) in language design. Remember when I mentioned the weird schoolyard insults and constant bizarre emasculation of Rust and its users? Good"

"This post isn’t about feminism in language design"

"For those of you not in the know, a llamafile is basically for turning an LLM’s weights into an executable. Which is where this post is actually going because surprise shithead, I lied again about this post’s topic. Ok, you’re probably wondering at this point “What the fuck does AI have to do with C++, let alone memory safety in C++” (that or you’re probably along for the ride at this stage and are just rolling with it), and it’s sadly more related than you might realize"

"This article wasn’t ever really about C++ the language. It was about C++ the community, because that’s what C++ really is. Bjarne is too caught up in his own bullshit to see it, same as Herb and Gaby, and as long as this is the situation we’re in, C++ will never be “safe” as a community. You could have the perfect language, but if no one uses it, because there’s no community, what do you have?"

"C++ is not in a unique situation. Far from it. This story has been told before. Leadership refusing to let the next epoch come around, destroying themselves and the world in the process. Leaving the rest of us to pick up the pieces, convincing some of us to take on a mandate to repeat this cycle, to make sure the world stays out of the hands of those would change it, while others shirk this mandate and take upon themselves a different path. Discouraging jolly cooperation, as long as we think we only have these two options before us"

Если вы прочли этот #rant, то точно знаете, что профили от Страуструпа - это треш, угар, и содомия, потому что:

1) их не существует в природе

2) они не решают задачу memory safety, как ее видит индустрия, а решают какую-то другую задачу.

Но Бьерни сучит ножкой, и требует принятия их в стандарт:

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

#cplpl_doomed , ага.

#rant

#cargo разрабатывают какие-то упыри.

Ну вот надо вам передать строковый параметр, как вы это сделаете?

Я сделаю вот так - cargo --config A=B.

К чему пришло извращенное Rust-ом сознание?

Правильно, к cargo --config "A = 'B'", не упустите ничего, особенно того, как в такой схеме экранировать спецсимволы.