Подвожу черту в своем микроисследовании USB-C to HDMI тракта для поддержки 4k120HZ.

У меня нет ни одного готового, из коробки, решения (это когда вам сразу продают USB-C to HDMI кабель, в который встроен какой-то преобразователь), которое бы давало устойчивое изображение 4k120hz на всех трех моих подопытных устройствах. В целом, это понятно, потому что нужно, чтобы сошлись звезды, и производитель не пожадничал на сразу двух устройствах - преобразователе сигнала, и на самом кабеле. А в noname кабелях вообще невозможно узнать, из чего они сделаны.

Есть кабель, который работает на 2 из 3 устройствах, и на этом все.

Ultimate решение - это купить отдельно преобразователь USB-C DP в HDMI, и отдельно - хороший hdmi кабель, в палец толщиной и в металлической оплетке.

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

https://www.ozon.ru/product/perehodnik-video-kabel-j5create-usb-c-to-hdmi-2-1-8k-adapter-seryy-chernyy-jca157-849800092/?utm_medium=organic&utm_referrer=https%3A%2F%2Fyandex.ru%2Fproducts%2Fsearch%3Ftext%3DJCA157&utm_source=yandex_serp_products&sh=ZtlDTV-YKA

https://www.phoronix.com/news/Qt-Wayland-Compositor-Restart

Фига, QT-шные приложения теперь будут переживать гибель композитора. Ну теперь Wayland-то точно готов для десктопа!

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

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

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

Так же можно было бы иметь демон, владеющий буферами и соединениями, но "wayland - это же не демон, а протокол, my ass".

Как говорится, доверяй, но проверяй!

Я тут, случайно, в выводе pstree увидел красивое:

flock---unbound 

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

flock---timeout---unbound

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

Посмотрел логи - да, действительно, мой вызов timeout не возымел эффекта. Как будто его и не было.

Не буду утомлять себя рассказом про подробности #debug, сразу расскажу, что было.

https://git.busybox.net/busybox/tree/coreutils/timeout.c#n101

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

Там написано, что команда timeout в качестве child запускает код, который демонизируется, и, далее следит за временем выполнения основного процесса, а потом основной процесс делает exec на нужную команду.

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

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

Починил я это тем, что добавил в цепочку subreaper, https://unix.stackexchange.com/questions/250153/what-is-a-subreaper-process https://github.com/stal-ix/ix/blob/main/pkgs/bin/unbound/runit/ix.sh#L9

Зачем timeout устроен так сложно?

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

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

Дебажил тут один скрипт, который под python2 (да, есть еще легаси в русских селеньях) работал нормально, а под третьим питоном зависал на попытке вывести в stdout кучу (примерно 15 гигабайт) бинарных нулей.

Строчка, приводящая к такой забавной ошибке:

print(six.binary_type(some_func()["id"]))

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

Сломанный скрипт - часть рантайма большой production системы, которую починят, но не "прямо сейчас".

А мне же надо "прямо щас", ну и я испорчен взаимодействием с open source, поэтому я сделал в своем скрипте вот так:

cp $(which mega_script) ./ 
sed -e 's|six.binary_type||' \
    -i mega_script
export PATH=${PWD}:${PATH}

Моя джоба побежала. В будни, когда коллеги обновят сервис, я это уберу, конечно.

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

Мораль?

Мне интересно, сделал бы я так два года назад, еще до активного взаимодействия с open source, или, все же, нет. Не знаю.

Борьба с говнокодом

Programmer memes

Можно ли быть святее папы римского?

Сборки llvm, который можно скачать с их релизной страницы, bootstrapped.

Что это значит?

Что они в процессе сборки собирают новую версию host c++ компилятором, а потом уже им собирают релизную версию нового llvm.

То есть, оно, в каком-то смысле, "самособрано" - мы используем компилятор, собранный этим же компилятором.

Так же они, в процессе, собирают себе libc++, и, скорее всего, какие-то рантаймы.

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

По ссылке https://github.com/pg83/ix/blob/main/pkgs/bin/clang/16/bootstrapped/ix.sh компилятор, не просто bootstrapped, а еще и все зависимости которого собраны им самим же (конечно, логически, физически это невозможно).

Так что, ответ на поставленный вопрос - да, можно!

Запилил ix respawn https://github.com/pg83/ix/blob/main/pkgs/bin/ix/respawn/unwrap/main.c

Это такая штука, которая ищет бинарник ix "где-то" (например, во всех предках текущей директории), и вызывает его с переданными аргументами.

Довольно общая штука для всякого рода инструментов, которые не привязаны к рутовой файловой системе и к PATH.

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

Ужал ее размер до 10к, можно было и меньше, но уже было лень.

Как?

* Выпилил stdio, он даже в musl довольно большой. Оставил только сисколлы и строковые функции.

* Не освобождаю память. А зачем это делать в one shot тулзах?

* Заменил аллокатор. Даже самый тонкий аллокатор давал footprint порядка 50 - 200к. Заменил его на bump allocator своего изготовления - https://github.com/pg83/ix/blob/main/pkgs/lib/bumpalloc/alloc.c

Чем он интересен?

* В нем нет ни единого syscall, потому что он распределяет память из заранее выделенного в программе массива.

* Ну и вообще, он не зависит от libc.

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

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

"блеск и нищета С"

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

Я, перед тем, как начать говнокодить, прочел исходники wlr portal, от simon ser'а, и это тот еще говнокод:

* race condition - https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/src/screenshot/screenshot.c#L120https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/src/screenshot/screenshot.c#L120

* утечка номер раз - https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/src/screenshot/screenshot.c#L133

* утечка номер два - https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/src/screenshot/screenshot.c#L273 (тут их две - одна - при ошибке в выделении памяти, а вторая, более серьезная - если кто-то не позовет remote Close() на созданный хендл xdpw_*)

Ну и решил, что мне это не нужно.

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

https://j3s.sh/thought/write-posix-shell.html

Хороший текст про shell, например.

Полностью согласен с "simply: because shell is an insanely productive language. in fact, i believe that shell is the *most* productive language"

У меня, когда я пишу на shell, в голове всегда борются два начала:

* чистоплюйское, которое говорит, что надо писать на языках, в которых команды пишутся вот так: ['x', 'y', 'z'], потому что не надо думать про пути, про escaping, и про прочую хрень, которая всегда мешает в sh.

и

* getting things done, которое говорит мне, что, если я напишу "x y z", то я сделаю работу в 10 раз быстрее, хотя и не без потенциальных косяков.

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

Очень рад, что, еще на ранней стадии развития #ix, выкинул все попытки погрузить проблематику в скрипты на python, потому что я бы не успел сделать все то, что сделал к текущему моменту времени, если бы выбрал homebrew/nix-like подход.

Я просто оставлю это здесь:

https://www.cnews.ru/news/top/2023-03-01_ssha_pytaetsya_razvalit_mir

"США медленно, но верно закрывает доступ к открытому коду своему главному технологическому конкуренту — Китаю"

"Кроме того, ничто не мешает сотруднику китайской разведки загружать OSS, находясь за границей. И все же, учитывая испорченные отношения между западом и востоком, кажется неизбежным, что западные демократии начнут мешать Китаю получить бесплатный код, они могут попросту сократить его производство"

Сука, что творится в головах у этих людей?

#mesa

Вот пример точно такого же (неприятного) поведения в винде, тоже в драйверах GPU - https://habr.com/ru/company/yandex/blog/721374/

Хаки над хаками, а потом драйвера научатся понимать что-то про "хаки над хаками", и нахуевертят еще всякого говна.

https://www.audioasylum.com/messages/pcaudio/119979/

Украдено у https://discuss.systems/@dan/110008052977994607, пишут, что С++ звучит лучше, чем malloc()

Вы знали? Я раньше не знал, знал только, что провода надо брать специальные, за 5K$.

Продолжение темы на phoronix: https://www.phoronix.com/news/Linux-STMAC-Russian-Sanctions

Горячо, конечно, в каментах - https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1378146-linux-kernel-networking-driver-development-impacted-by-russian-sanctions, их число растет быстрее, чем я читаю.

https://www.phoronix.com/news/Codon-Faster-Python
https://www.opennet.ru/opennews/art.shtml?num=58395

Судя по всему, какая-то горячая тема, что-то по типу #nuitka/cython/etc.

По мне так https://github.com/exaloop/codon - начали за здравие, а кончили уже не так оптимистично.

Любой, любой такой проект сразу, на первой странице, должен говорить, поддерживает ли он стандартные протоколы питона, или нет.

Ну вот реально - если там семантика лукапа методов такая же как в cpython (через 5 лукапов в dict, а иногда и еще больше), то там нет простора для оптимизаций, они всем давно известны, и реализованы в том же pypy.

А если стандартные протоколы не реализованы, и x.y - это что-то другое, нежели в cpython - ну да, можно сделать быстро, но интересный код там не выполнить.

Есть такая очень смешная шутка - "мне не нужен язык с GC, потому что моя программа не производит мусора".

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

К чему это я?

С-style printf - страшное говнище.

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

Например, по числу аргументов - printf("%d %d", 1). Или по несовпадению типов аргументов.

Мой поинт в том, что, конечно, можно героически пытаться решить эти проблемы, как пытается делать compile time std::format в С++ (тоже, очевидно, страшное говнище, как наследник C printf), а можно сделать так, чтобы такое нарушение инварианта не могло возникнуть в принципе.

Мне известно два способа сделать это:

* f-strings в куче языков, f"{a} {b} {a}"
* std iostreams в С++. У них есть свои проблемы (например, они stateful), но вот класс проблем выше в них не может возникнуть: cout<<a<<" "<<b<<" "a;

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

Вот их и надо использовать. В С++, конечно, лучше взять стороннюю реализацию потоков, которая не будет делать миллиарды inline вызовов, приводя к ухудшению времени компиляции и разбуханию кода.

А то, что std::format в текущем виде попал в стандарт, это, конечно, стыд и срам С++. Вот, реально, мало что хорошо было сделано в С++, ну так синтаксис форматированного вывода был сделан неплохо, надо было его и улучшать, в сторону f-strings, которые могли выглядеть "как в python", но, under the hood, превращаясь в вызов operator<<.

Если имеете возможность - не используйте C printf-like форматирование, нигде. Это очевидная ошибка дизайна из 70-х годов, которую упертые фанатики тащат в каждый новый язык.