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

"Проект Airyx развивает редакцию FreeBSD, совместимую с приложениями macOS"

Иногда я не понимаю, что думать, про OSS проекты. Вот этот похож на откровенный стеб - посмотрите на скриншоты, где MacOS, и где вот это поделие? (судя по всему, это вариация GnuSTEP). Сайт(https://airyx.org/) - привет из 80-ых, вырвиглазное нечто. Но Issue tracker и forum живые. Короче, вот про что это? Кто все эти люди, которые качают и ставят себе это поделие?

———
https://www.gwern.net/docs/www/0xeb.net/86e4b3bee45b08ac9249c10b4d649637df73074a.pdf

Феерическая презентация про эмуляцию buffer overflow. Long story short - в оригинальном starcraft от 98 года был проезд по памяти, который эксплуатировался картоделами. Например, благодаря ему запилили карту под starcraft, которая представляет из себя super mario. Карт таких создано было приличное количество, и нужно было, чтобы они продолжили работать в starcraft: remastered от 2017 года. Короче, эпичненько.

———
Мне тут в личных переписках предлагают завести аккаунт на Патреон, или где-то еще. Денег мне не надо, пишу я с гораздо более интересной целью - у меня наполеоновские планы на Mix, но двигать целый дистрибутив в одиночку - ну так себе план. Короче, я ищу себе компанию для этого нелегкого дела. Поэтому лучшее, что вы можете для меня сделать - это привлечь сюда таких же энтузиастов(или, например, рассказать, где их еще можно поискать).

Зачем мне вообще двигать свой дистрибутив? Мне он нравится, но развивать его всю жизнь одному - сложно. Если найдется 100 - 1000 заинтересованных пользователя(а это норм тема, гораздо более странные поделия находят себе пользователей еще больше, выше привел пример), сообща делать это гораздо проще.

Мужик сказал - мужик сделал. Перешел с Alacritty на #kitty. Правда, это оказалось не так просто, как я ожидал.

#terminal

Kitty разрабатывает индус. Не, натурально, зовут его, кстати, #Ковид, и у него есть скрипт для подсчета объема его лапшеобразного кода - https://github.com/kovidgoyal/kitty/blob/master/count-lines-of-code. Код соответствующего качества.

Например, он зачем-то импортировал цельнотянутые исходники glfw в свой проект, наверное, чтобы увеличить line count. https://github.com/kovidgoyal/kitty/tree/master/glfw

Собирать статически слинкованный бинарь это решительно не помогает.

Так же мне очень нравился рендеринг шрифтов в alacritty(они там более crispy), и я долгое время искал, какую функцию рендера шрифтов MacOS нужно дернуть, чтобы получить нужный результат. Нашел, держите:

https://github.com/kovidgoyal/kitty/blob/master/kitty/core_text.m#L504

Так же #alacritty химичит с вертикальным размером шрифта - почти pixel to pixel я получил, когда обрезал шрифт на 85% исходной высоты. В коде Alacritty я с ходу этого не нашел, там слишком много вхождений литерала 85.

https://www.reddit.com/r/archlinux/comments/n9noje/alacritty_vs_kitty/ - вот, например, сравнение этих двух эмуляторов терминала.

https://wezfurlong.org/wezterm/config/files.html - пока занимался сборкой Kitty, ознакомился и с другими эмуляторами. Этот меня порадовал своим подходом к конфигурации. Конфиг - это код на lua, который должен вернуть dict. Кто-то еще помнит поисковый балансер? Гениальная же штука!

Оказывается, зря я гнал на авторов терминалов - все они понимают, что протокол терминала не позволяет нормально НЕ делать апдейты посреди процесса вывода программой своего интерфейса. Вот, пожалуйста, документ про это - https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2. Кстати, наш друг Ковид там тоже засветился. Но если понимают - то что же так криво реализуют существующую схему-то?

Кстати, Kitty мерцает существенно меньше, чем Alacritty, хотя и несколько медленнее.

Купил тут себе новую игрушку. #xiaomi

Давно хотел себе мощный ноутбук с Linux, при этом:

* Желательно AMD. Intel объективно отстали на много лет, при сравнимой производительности у них бешеный теплопакет, и наоборот. От AMD можно взять 16 потоков, от Intel max 8.
* Желательно, без дискретной видеокарты. Меня душит жаба платить за то, что я не использую. Хочется хорошую встроенную - чтобы рисовать ускоренный десктоп, не более того.
* OLED, 4K. Ноутбук с плохим экраном(Apple) у меня уже есть, хочется хорошего.
* Чтобы Linux без танцев с бубном.

Долго искал, пробовал разные варианты, и вот, тададам!!!

https://www.ixbt.com/news/2021/05/24/oled-3-5k-ryzen-7-5800h-100-1055-xiaomi-mi-notebook-pro-15-ryzen-edition.html
https://www.reddit.com/r/linuxhardware/comments/p4a148/2021_xiaomi_mi_notebook_pro_15_ryzen_edition/

Все, как я хотел(не работает только сенсор отпечатков пальцев), и даже лучше:

* Отличная сборка - лучше, чем у dell xps, asus rog
* Цельнопизженный дизайн от Apple. Мне нравится, нечего тут выделываться, и надо воровать лучшее решение на рынке.
* Благодаря AMD сборка в 16 потоков не жарит коленки, как было в моем Mac Book Pro от 19 года.

Что так себе(но было ожидаемо):
* Батарею держит плохо. Ну, топовое ядро + Linux - это заведомо беспроигрышное сочетание. Не думаю, что я со своими требованиями могу найти что-то лучше.
* Ядро хуже, чем M1. Сборка clang где-то 20 минут(топовые результаты можно почитать где-то тут).

Что просто так себе:
* На клавиатуре есть честные pgup/home/end/pgdown, поэтому fn + arrow не работают. В биосе починки я не нашел.
* Тачпад кажется дубовым. Думаю, это особенность libinput, дойдут руки собрать ее - попробую зафиксить.

Что хочу особо отметить:
* ЭКРАН. Экран просто божественный. Он просто бескомпромиссно хороший. Черный - черный. Белый - белый. Везде. Без бликов. При любой скорости скроллинга. Цвета огонь. Шрифты четкие(нет разницы включать AA, или нет - это значит, что точки достаточно мелкие) - на мониторе от Apple вокруг белых шрифтов на черном фоне видно гало. Я не знаю, как это описать - возьмите телефон с хорошим OLED, и представьте, что у вас весь экран такой. Яркость экрана тоже на высоте. Кажется, это первый ноутбук, где я выкрутил яркость не на 100%.
* Не забываем в загрузку ядра добавлять mitigations=off, это 5 - 10% перфа.
* Китайцы не постеснялись сделать в BIOS по умолчанию китайские иероглифы. Я считаю, это правильно. Вот Apple выебы;%ется, и ничего, все равно ее железки раскупают, как горячие пирожки.

В первый раз провел bootstrap с fedora linux, узнал еще много разных и нетривиальных способов, какими сборочные скрипты лезут в систему. perl, например, запускает linker, и по путям к .so пролезает в host систему.

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

Чинят сборку с Emscripten. А я еще удивлялся - чего у меня сломалась статическая сборка питона в 3.11. А это, оказывается, ее шатают для такой благородной задачи. Статическая сборка питона, традиционно, всегда сломана, причем, от релиза к релизу, всегда разным способом. В 3.11 сломали каким-то новым, доселе невиданным, способом(в Modules/Setup оставили модули, часть из которых перенесли в принудительную сборку в Makefile.pre, если кто-то понимает, о чем я), но, надеюсь, раз решили поддержать Emscripten, то больше ломаться не будет. Надо понимать, что сборка под #WASM всегда статическая, сами понимаете, под js в браузере нет никаких .so.

———
https://www.openswr.org/index.html

Начал собирать Mesa, и вот порция свежих знаний. Оказывается, Intel запилил ОЧЕНЬ быстрый software rasterizer для Mesa OpenGL, в десятки раз быстрее, чем llvmpipe. Сравнения с GPU я не нашел, но это уже близко.

———
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.17-AF_UNIX-Optimization

Оказывается, в Linux все AF_UNIX сокеты живут под одним big lock. Я из текста не понял, это один lock на все, или это только изначальное отображение int fd на внутриядерную структуру(которая сама уже живет без этого big lock). В любом случае, это жесть, и разработчики решили это дело поменять хотя бы на шардированный lock. Дело хорошее, всяким local rpc, типа Wayland, D-Bus, etc, должно стать хорошЕе.

Новости бутстрапа.

Я собрал opengl, во всех его ипостасях(egl, gles[1, 2, 3], etc). Про то, что у меня теперь драйвер видеокарты влинкован в Sway, я расскажу отдельно. А сегодня - про Mesa(https://www.mesa3d.org/). Mesa - это:

1) Реализация различных API(OpenGL, Vulkan, D3D(да, да, он там есть, нативный, но разработчики это скрывают, потому что не хотят, чтобы им пользовался кто-то, кроме Wine))
2) OSS ускоренные драйвера(AMD, Intel, Noveau, Mali, etc)

Вы знаете, я был очень приятно удивлен. Я никогда не видел такой хорошей кодовой базы на C. Чистый, понятный, код, разумное разделение на слои и разделение ответственности. Если вы хотите(хз, правда, зачем) научиться, как хорошо писать на С - почитайте кодовую базу Mesa.

Я почитал(зачем? проект загружает драйвера в виде .so, это требует некой творческой доработки для статической линковки), и имею вам сказать следующее:

1) Что-то я разуверился, что #asahi linux достигнет какого-то разумного прогресса в плане ускоренного десктопа. Все очень просто. Код для asahi в Mesa - это 200 килобайт, драйвер и компилятор шейдеров. Код развитого драйвера в #Mesa - 5 и более мегабайт. Я не верю в чудо, что разработчики asahi смогли уместить такую сложную штуку, как Apple GPU, в 200К. Я не видел там реализации по существу, все это больше похоже на какой-то boilerplate. :(

2) Благодаря Mesa появилась система сборки Meson(https://mesonbuild.com/). На ней основана сборка практически всего графического стека Linux. И это очень хорошая(не побоюсь сказать, что лучшая OSS) система сборки:

* Мало внешних зависимостей. Фактически, только Python. Python собрать проще и быстрее, чем CMake.
* Сборочные файлы основаны на кастрированном подмножестве Python, чтобы не жестить(https://mesonbuild.com/GuiTutorial.html). Skylark украл эту идею из Meson. Сборочные файлы по большей части декларативные, но немного императивщины дозволено - все же, OSS, много настроек, вариабельность.
* Действительно хорошая поддержка тулзов - Meson знает про clang, lld, и умеет с ними обращаться.
* Сборочные скрипты очень чистые и понятные - без жести, все очень по существу вопроса.
* Хорошо поддерживает вариабельность сборки(настройки). Настройки лежат в отдельном файле, их можно узнать, не читая сборочные скрипты. Это реально удобно. В gnu #autohell для этого нужно запустить configure, и не факт, что он выдаст все настройки. В CMake это IMHO вообще невозможно - любой -DXXX - это настройка, выгрепать их все - невозможно.
* Поддержка кросс-компиляции.
* Идеальный custom_command - {'inputs': [...], 'outputs': [...], 'descr': '...', cmd: ['A', 'B', 'C']}. Кто занимается системами сборки, тот поймет. Я аж прослезился.
* Не мешает, и даже помогает, задаче герметичной сборки. Это редкость.
* Очень быстрый configure stage.
* Не совсем про Meson, но. Оно поддерживает coverity из коробки. И werror из коробки. Это многое говорит о проектах, которые ее используют.

Подобное есть в Bazel, но он очень тяжелый, и зависит от Java.

В общем, я свои проекты портирую на #Meson, и вам желаю того же. Хорошая, годная, вещь.

Ну и вот еще - https://gms.tf/the-rise-of-meson.html Meson очень быстро набирает популярность!

https://www.youtube.com/watch?v=9vyh1APsMAE #abi

IMHO C++ тоже постепенно тонет. И, вот, IBM зачерпывает водички из-за борта, и заботливо подливает в трюм - https://reviews.llvm.org/D111323

TL;DR - поддержка EBCDIC в libc++. На поддержку ICU у IBM мейнфрейма не нашлось(https://icu.unicode.org/#h.fnv22un0oe4t), а тут на тебе!

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4210.pdf - труп их же триграфов еще остыть не успел.

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

Про #Vizio и GPL я тут уже писал. Дело принимает интересный оборот, я даже не знаю, кто из сторон бОльший негодяй. Vizio просит прекратить суд, потому что правообладателям кода типа пофиг. Е;%ла жаба гадюку, что называется.

———
https://dwheeler.com/trusting-trust/

Про технику diverse double compiling для защиты от trusting trust я тут тоже писал, вот, текст с комментариями про это, и с кучей интересных ссылок. Мне особенно зашла https://static.lwn.net/images/conf/rtlws11/random-hardware.pdf - "Analysis of inherent randomness of the Linux kernel"

Жесть, самый странный #debug в моей жизни.

pg@:~/sources/mix strings ~/mix/realm/stable/bin/sway | grep hello
pg@:~/sources/mix ldd ~/mix/realm/stable/bin/sway
  не является динамическим исполняемым файлом
pg@:~/sources/mix HELLO YES THIS IS DOGHELLOYES THIS IS DOG^C
pg@:~/sources/mix 
pg@:~/sources/mix ldd ~/mix/realm/stable/bin/sway
  не является динамическим исполняемым файлом
pg@:~/sources/mix strings ~/mix/realm/stable/bin/sway | grep HELLO
pg@:~/sources/mix strings ~/mix/realm/stable/bin/sway | grep DOG
HB_SCRIPT_DOGRA
G_UNICODE_SCRIPT_DOGRA
pg@:~/sources/mix 12345HELLOYES THIS IS DOG890
bash: 12345HELLOYES: команда не найдена
pg@:~/sources/mix 12345 HELLO YES THIS IS DOG 890

Я собрал sway, который вместо 6 и 7(пишу с другого хоста) печатает вот то, что вы видите сверху. Я, короче, в шоке. libinput:

5 event4   KEYBOARD_KEY            +1.513s  *** (-1) released
 event4   KEYBOARD_KEY            +1.967s  *** (-1) pressed
HELLO event4   KEYBOARD_KEY            +2.059s  *** (-1) released
 event4   KEYBOARD_KEY            +2.345s  *** (-1) pressed
YES THIS IS DOG event4   KEYBOARD_KEY            +2.433s  *** 
 (-1) released
 event4   KEYBOARD_KEY            +3.082s  *** (-1) pressed
 event4   KEYBOARD_KEY            +3.330s  *** (-1) pressed
^C

Вывод - приходит 1 нажатие, которое далее преобразуется в этот текст. Wayland передает клиентам keystrokes, значит, ошибка в коде клиента. Проверяем:

recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=
[{iov_base="\34\0\0\0\3\0\30\0n\n\0\0
\376\251d\5\10\0\0\0\1\0\0\0", iov_len=3128}, {iov_base=
"", iov_len=968}], msg_iovlen=2, msg_controllen=0, 
msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
write(7, "YES THIS IS DOG", 15)         = 15
timerfd_settime(6, 0, {it_interval={tv_sec=0, 
tv_nsec=40000000}, it_value={tv_sec=0, tv_nsec=600000000}},
 NULL) = 0
epoll_pwait(3, [{events=EPOLLIN, 
data={u32=2820241184, u64=5633522366240}}], 8, -1, [], 8) = 1
read(7, "YES THIS IS DOG", 24576)       = 15
read(7, 0x7ffecfe04050, 24576)          = -1 EAGAIN 
(Ресурс временно недоступен)

[root@dynamic-vpn pg]# ls -la /proc/3101931/fd/7
lrwx------. 1 pg pg 64 дек  3 07:42 /proc/3101931/fd/7 
  -> /dev/ptmx

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

/* Multiple keysyms. */
    TEST_KEY(KEY_6, "HELLO", 0);
    TEST_KEY(KEY_7, "YES THIS IS DOG", 0);

libxkbcommon-xkbcommon-1.3.1/test cat state.c | grep DOG
    TEST_KEY(KEY_7, "YES THIS IS DOG", 0);
    TEST_KEY(KEY_7, "YES THIS IS DOG", 0);

С%ка, я чуть не поседел... Один, печатаю в терминале, и тут на экране появляется "HELLO YES THIS IS DOG"...

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

Вот починка, из одной строчки. Дело в том, что make install этого пакета не ставил необходимые данные. Я посмотрел, что с установленной системе эти файлики похожи на содержимое test/data, и просто скопировал тестовые данные в production. Получилось то, что получилось. Где живут настоящие данные, я пока не нашел, поэтому копирую их из системы, чтобы можно было двигаться дальше.

https://github.com/pg83/mix/commit/df138dda7508c7024a372262b8f593bb8fcfb84d#diff-041427458f79449f1c1f36bb41796c56acaaa27b91363293fb6cb62af04a209eR33

Science and Technology links (December 4th 2021)

It used to be that all the exciting new processors came from Intel and AMD, and they were meant for your PC. The mobile revolution changed that: it lead to the production of fantastic processors that used little energy. We are now moving back into laptops and servers. The leading supplier of servers is probably Amazon: if you want to run servers for your business, your first choice is often Amazon and its cloud computing infrastructure. And Amazon now makes their own processors. Initially, they made low-cost chips that were secondary to Intel and AMD powerful processors. Amazon released its latest processor, Graviton 3. It is a much wider and deeper chip: The N1 core used in the Graviton2 chip had an instruction fetch unit that was 4 to 8 instructions wide and 4 wide instruction decoder that fed into an 8 wide issue unit that included two SIMD units, two load/store units, three arithmetic units, and a branch unit. With the Perseus N2 core used in the Graviton3, there is an 8 wide fetch unit that feeds into a…

https://lemire.me/blog/2021/12/04/science-and-technology-links-december-4th-2021/

https://repositories.lib.utexas.edu/bitstream/handle/2152/86210/P-2018-02_Intel_Address_Hashing.pdf?sequence=3 (TACC уполномочен заявить!)

Тут вот коллега* прислал красивое. Long story short - у ядер процессора, помимо приватных L1/L2 есть общий LLC. Он устроен примерно так - у каждого ядра есть своя частичка LLC, они все объединены общей шиной, все это организовано в 12-way associative hash table(по хешу от адреса мы понимаем, в какое ядро и в какую его ячейку идти за нужным нам cache line).

Статья про свойства этого хеша, и про то, что false sharing иногда бывает очень сильным.

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

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

*: Гулин

———
https://tvl.fyi/blog/rewriting-nix

Товарищи решили переписать пакетный менеджер Nix. Причина - он тормозной, что пипец(подтверждаю, обновить 10 пакетов пустым обновлением у меня занимает секунд 20).

1) Товарищи решили поддержать динамическую генерацию графа(когда ноды могут сгенерить новые ноды). Я считаю, что это жесть и путь в никуда.
2) Интересное - "PS: TVL is international, but a lot of the development will take place in our office in Moscow. Say hi if you're around and interested!" - а я вот не знал.

———
https://riscv.org/announcements/2021/12/riscv-ratifies-15-new-specifications/

Теперь risc-v можно официально использовать в серьезных вещах - векторные расширения и гипервизор, в официальных спеках.

https://codeberg.org/dnkl/foot/wiki/Performance #terminal

Я вот решил попробовать какой-то другой эмулятор терминала, один из самых популярных not hardware-accelerated - #foot. Автор, конечно, всячески пытается сделать вид, что он не конкурирует с alacritty:

1) Но вот в тест, где он рвет #alacritty, "срежиссирован" специально - он строчкой ранее пишет, что alacritty гораздо быстрее рендерит пустые глифы, чем заполненные, и, чтобы показать преимущество своего damage control, показывает этот damage control на полностью заполненном терминале. На терминале с небольшим числом непустых глиф даже его damage control не показал бы преимущества.

2) Чтобы его foot не совсем сильно тормозил, он сделал оптимизацию с копированием части буфера через memcpy, если он считает, что она не изменилась. И набажил - у меня при скроллинге, если предыдущие строки немного похожи на следующие, начинаются глюки отрисовки.

Ну не соревнуешься - так не соревнуйся, сделай простую, как 5 копеек, вещь, которой можно пользоваться без hardware acceleration.

———
https://github.com/dvdhrm/kmscon

#kmscon

Какой-то странный проект по замене линуксовой консоли во frame buffer. Я тоже задумался о такой штуке, но мне показалось, что гораздо проще взять киоск-style композитор на основе wlroots, и слинковать в одну программу эмулятор терминала(любой), киоск-style композитор, libinput, и все такое. Получаем бинарь с клиентом-терминалом и сервером-композитором, который умеет в консоль в fb.

———
Я хочу признаться в одной странности, которая меня никак не отпускает. Я строю prefix trie из путей к проектам в своей системе сборки Mix. Что это значит?

lib/pcre, lib/pcre/2, а не lib/pcre2. lib/tom/math, lib/tom/crypt, а не lib/tommath, lib/tomcrypt. lib/z, а не lib/zlib(а это уже что, граф?), net/wget и net/wget/2, и самое любимое - lib/curses/n, lib/curses/netbsd. Пока не сжал dev/build/autoconf, dev/build/automake, но руки чешутся.

Я хз, зачем я это делаю, но мне нравится!

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

Будни #bootstrap.

Собирал тут правильные данные для xkbcommon(ага, те самые "YES THIS IS DOG"). Думал, задачка на 5 минут, но пришлось собрать Perl с вкомпиленными в него модулями. Не то, чтобы я очень хотел это делать, но по цепочке из GNU-того говна из Perl и Bash в проект приехала зависимость от XML::Parser модуля, которому нужен expat. Я сделал это как-то очень странно - подложил в сборку Perl из исходников модуль из Cpan, и он его каким-то чудом подхватил. Магия.

https://github.com/pg83/mix/blob/main/pkgs/dev/lang/perl5/full/mix.sh#L16

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

———
https://github.com/nineties/planckforth/blob/main/bootstrap.fs

Потихоньку изучаю Forth, и мне таки начинает казаться(кажется, в этом чате мне об этом уже писали), что для задачи бутстрапа из ничего Forth подходит лучше, чем даже Lisp. Есть что-то магическое, когда поток токенов становится все более и более насыщенным смыслом.

———
Решил тут попробовать воспользоваться firefox, а то chrome у меня в Sway глючит. Мне даже понравилось - с помощью расширения Tree Style Tabs получилось настроить Firefox так, как должен выглядеть браузер(скриншот будет в комментариях, если скриншотилка заработает под Wayland).

IMHO Firefox нужно выкинуть свою реализацию Java Script. Это не то, что придает уникальный привкус браузеру(когда у меня clang начинает побеждать gcc, я выкидываю gcc, и не рефлексирую), на это уходит много ресурсов разработки, и в Мозилле работают не самые крутые инженеры. Java Script от Гугла круче.

#LLVM news.

https://reviews.llvm.org/rG6a9487df73e9 - полезная проверка, что строки не конструируются от nullptr. Впрочем, начиная с С++2023 соответствующие конструкторы просто забанены.

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

"The next Women in Compilers and Tools meetup will take place on December 9th. It will feature Sangeeta Chowdhary’s talk, Fast and Precise Approaches to Detect, Debug, and Repair Numerical Errors."

———
https://www.opennet.ru/opennews/art.shtml?num=56291 #yeswecan #provider

Несколько раз уже писал, что инфраструктурная площадка не может сама себе быть судьей, и решать, кто может пользоваться ее сервисом, а кто нет. Вот пример правильного поведения инфраструктурной площадки, всем бы брать с нее пример. С самим решением суда я не согласен*, но это правильный путь.

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

———
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)

"every frame is perfect", ага.

1) Разработчики Firefox умудрились устроить мне мерцание даже в Wayland, хорошо заметно под нагрузкой.

2) Авторы Sway вообще не понимают, как надо делать композитор. При переключении рабочих столов они сначала рендерят frame, показывают его, а потом уже применяют накопившиеся(пока рабочий стол был скрыт) изменения к итоговой картинке. Это приводит к тому, что первый кадр всегда содержит stale данные. И, соответственно, к мерцанию.

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

https://yandex.ru/images/search?from=tabbar&text=wayland%20susann

Так я и полюбил латекс.

Галопом по Европам.

А вы знали, что можно писать не sed -e s///, а sed -e s|||? Я вот узнал всего полгода назад, и мне это уже сэкономило кучу нервов и сил на эскейпинге /. Наверняка это всем давно известно, и никому не интересно, но я вот не знал.

———
https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/

Мозилла начала делать какую-то очень странную вещь. Часть библиотек они компилируют не в исполняемый код, а в #WASM, и джитят во время работы. Это им дает возможность установить менее большую surface для особо опасного кода, и, типа, так безопаснее. Я имею сказать:

1) Норм тащить в проект 1000000 строк кода, чтобы обезопасить 10000? Впрочем, JIT для WASM и так и так бы был.

2) А почему бы не сделать на WASM весь браузер? https://pbs.twimg.com/media/ELxt9LSXUAMlmIp.jpg А, было же такое - https://en.wikipedia.org/wiki/HotJava , не полетело.

———
https://codeberg.org/dnkl/foot/pulls/461 #foot
https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2

#terminfo

Я тут пару раз писал про разные эмуляторы терминала, и сокрушался, что их авторы не хотят реализовывать нормальный протокол для tear-free rendering. Потом я написал, что, оказывается, разработчики терминалов в курсе этой проблемы, и даже изобрели syncronized updates, но почему-то все равно не хотят реализовывать правильный протокол. Я еще раз перечитал доступные тексты, и понял, что разработчики терминалов считают проблему решенной - кому надо(я, например), могут использовать syncronized updates, а проблемы негров(ncurses, например) шерифа не волнуют.

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

https://github.com/pg83/ted/commit/a0aa84567efb7ac0760fde048dae0acf805fd188

В ncurses, наверное, не появится никогда.

Давеча писал, что перешел с git на svn при использовании github. Увы, недолго музыка играла, не работает переименование каталогов. Пришлось откатиться назад, на inferior решение.

———
Про #monospace шрифты! #font

Мне очень нравится шрифт Input Mono, он вышел 7 лет назад, я его эти 7 лет и использую. Это не очень популярный шрифт, и, когда я заметил его использование на одном там скриншоте в одном там чате, я спросил, "не Input ли это Mono". Оказалось, что это JetBrains Mono. Короче, шрифт 1 в 1. Ммм, не то чтобы они похожи, они 1 в 1, пару отличий я искал с лупой, в side by side terminal.

https://habr.com/ru/post/237179/
https://input.djr.com/
https://fonts.google.com/specimen/JetBrains+Mono

Input круче, потому что это не 1 шрифт, это конструктор шрифтов - можно выбрать много разных вариантов(толщина линий, межстрочный интервал, ширина символов, начертание символов). При некоторых настройках, повторю, получается JetBrains Mono. Кажется, единственное заметное визуальное отличие - это написание буквы "u".

С одной стророны, я рад, что самый лучший шрифт наконец-то стал популярным, с другой - жалко, что не под своим оригинальным именем(думаю, Jet Brains просто купили на него лицензию, упоминания этого факта я нигде не нашел).

———
Assembler porn!

https://github.com/haileys/doslinux/tree/master/script

DOS services for Linux, нет, really. Я думал, шутка, почитал исходники - все честно. Запускаем dos, запускаем в нем TSR, которая будет обслуживать прерывание для входа в Linux, входим в unreal mode(офигенный режим, кстати!), копируем ядро в высокую область памяти, входим в него, вместо init запускаем код, который будет передавать управление в dos TSR, и наоборот(потому что важно, чтобы вызов из dos приходил в контексте какого-нибудь существующего процесса Linux). Что-то по типу того, как работал DOS4GW. Я сначала было подумал, что там MMU-less сборка ядра, но нет, все честно.

https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/

Или вот генерация лабиринта за 10 байт ассемблера i386(все же, у x86 очень компактная кодировка)!

https://www.phoronix.com/scan.php?page=news_item&px=More-Apple-M1-For-Linux-5.17

Вот тут вот пишут, что в ядро добавили еще больше M1. В mesa я никакой активности про драйвер не вижу, увы. И, если уж начал про mesa и аппаратное ускорение, то я осилил статически слинкованный opengl и аппаратно ускоренные драйвера в одном бинаре.

pg@:~/sources/mix ls -la /home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
-rwxr-xr-x 1 pg pg 206469240 Dec 10 17:10 
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
pg@:~/sources/mix strip 
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
pg@:~/sources/mix ls -la 
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
-rwxr-xr-x 1 pg pg 78393840 Dec 10 18:51 
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway

Я думал, будет раза в 3 больше. Впрочем, я нашел интересный способ не линковать #LLVM в каждый бинарь.

https://docs.mesa3d.org/drivers/zink.html - реализация opengl поверх vulkan. #zink
https://www.opennet.ru/opennews/art.shtml?num=51026 - компилятор шейдеров от Valve, который не требует LLVM. Все #хорошее в графическом стеке Linux делают корпорации!

Совместно это дает ускоренный OpenGL, не зависящий от LLVM.

К сожалению, Vulkan мне пока не удалось завести. Разработчики Khronos Group - какие-то невменозы. Я тут уже однажды писал, что делают разрабы, когда у них заканчиваются задачи. Ответ - начинают их себе выдумывать на ровном месте. Вот это и делает Khronos Group. Мегабайты кода аццкого качества, задача которого - загрузить .so, экспортировать из нее функцию, которая вернет структуру, заполненную коллбеками(короче, интерфейс). Где-то там происходит нечто, из-за чего какой-то коллбек от драйвера становится nullptr, и все падает. Копипаста между разными репозиториями одного проекта, где-то заголовки используются из системы, в виде библиотеки, где-то их нужно положить рядышком, во время сборки. Разные репозитории имеют не совместимые друг с другом версии. Там 4 важных репозитория, если взять их последние релизы, они не совместимы друг с другом. У этих гондонов даже есть файлик с номерами ревизий, с которыми, типа, работает. Не с зарелиженными версиями, с ревизиями! https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/scripts/known_good.json

Стык загрузчика от Khronos Group и кода Mesa - это жесть. Им там не хватает информации в передаваемых контекстах, поэтому там вовсю всякие пертредные хештаблицы со всякими недостающими запчастями.

Зато я впервые трассировал графический драйвер, это интересно.

Нашел странную упячку в Mesa - там есть шейдерный кеш, и там есть часть ключа в этом кеше, которая зависит от dl_iterate_phdr на какую-то определенную функцию в библиотеке(https://github.com/mesa3d/mesa/blob/main/src/util/build_id.c#L118). Мне кажется, они таким странным способом хотели сказать, что кеш нужно инвалидировать при смене версии библиотеки, очень интересным способом(название исходника как бы намекает на это).

Дело осложнилось тем, что на границе кода #Mesa <-> Khronos Group происходит потеря информации в возвращаемой ошибке, поэтому драйвер просто возвращал "не могу проинициализироваться", без указания из-за чего, и где. Кстати, как эта проблема решается в языках без динамических исключений, типа Rust, когда коллбек имеет более богатую ошибку, чем вызывающий код может прокинуть наверх?

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

https://suricrasia.online/no-knowledge.html

Какая-то очень крутая тема(НЕ zero knowledge proof, это тоже красивое, но другое) - решение задачи "как бы передать кому-то строку, которая выглядит как hash, но не является хешом от каких-то известных тебе данных". Зачем это надо я ХЗ, но прикольно.

———

Продолжение темы про #Mesa и Vulkan. Я таки заставил его работать, это мне стоило 6 часов напряженной отладки. Бага причудливая. Товарищи сделали такой хак - пометили 100 экспортируемых функций как weak, но реализовали только те, что нужны. Драйвер вулкана в такой ситуации получал непустые реализации + nullptr для пустых. В случае статической линковки weak сработал не так, и в качестве реализаций взялись первые нулевые weak символы.

Vulkan, в целом, работоспособен, Sway с ним - нет. Если включить WLR_RENDERER=vulkan, то получаю черный экран, и это неудивительно, поддержка Vulkan в Sway появилась месяц назад. Если делаю MESA_LOADER_DRIVER_OVERRIDE=zink(фактически, форсирую реализацию OpenGL, которая работает поверх Vulkan), то получаю слегонца битую картинку. Неудивительно, думаю, Sway в таком интересном setup запускал только я.

Надо сказать, своей цели "собрать LLVM-free hardware accelerated stack" я достиг, бинарник Sway стал занимать 20 мегабайт.

Немного в сторону - прикольно осознавать, что подобную инсталляцию(musl + static build + clang + #zink + vulkan + sway) на этой планете, скорее всего, соорудил только 1 человек, хотя это тот еще неуловимый Джо.

Узнал прекрасное - в Linux есть 3 драйвера для AMD(Mesa, #AMDVLK, AMDVLK + proprietary code). https://www.linux.org.ru/forum/talks/16466478 Попробовал завести AMDVLK, но он требует X.

Valve топит за Mesa, потому что LLVM генерит медленные шейдеры.

Good news, everyone!

Я прочел https://www.phoronix.com/scan.php?page=article&item=zink-sub-alloc&num=2, установил себе #Mesa посвежее, и у меня заработала связка Sway + #zink + Vulkan!

Вообще, имею вам сказать, что аппаратные драйвера OpenGL, скорее всего, просто умрут, потому что зачем? По словам разработчиков Mesa Vulkan - это такой Gallium 2.0(не могу найти цитату), поэтому логично реализацию OpenGL строить поверх них. Ну и в MacOS будет рулить MoltenVK(https://moltengl.com/moltenvk/, + OpenGL поверх него), потому что никто в своем уме на Metal разрабатывать не будет.

———
https://www.ee.ryerson.ca/~elf/hack/recovery.html

Очень старый текст, напомнил мне ситуацию, в которой приходится запускать скрипты для сборки самых ранних пакетов. Например, первую сборку musl приходится делать в ситуации, когда у меня есть только dash + компилятор. Нет даже cat, echo.

Зацените, как я ловко вывожу блок текста в файл, пользуясь только shell builtin!

https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L18

Или как ловко, сразу после сборки libmusl.a, собираю себе с ним подручный вариант cat, чтобы заполнить все файлы, требующиеся для пакета:

https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L96
https://github.com/pg83/mix/blob/main/pkgs/boot/1/lib/musl/mix.sh#L121

Самый главный хак этого сборочного скрипта - что сборку сразу ведем в outdir, чтобы не заморачиваться с копированием файлов после сборки(команда cp появится позже).

Я считаю, что за этот файл мне нужно дать Нобелевку по posix sh!

———
https://www.kernel.org/doc/html/latest/admin-guide/syscall-user-dispatch.html

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

———
https://arxiv.org/abs/2110.01098

Говорят, что, если в Rust добавить GC, то студенты быстрее его осваивают. Норм же тема!

https://twitter.com/nicuveo/status/1469963644775682049

Красивое, просто показываю.

———
https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=4

Не люблю perf тесты, которые делаю не сам. Вот zstd на FreeBSD - это что? Так же не бывает, что cpu intensive задача на разных OS в 10 раз отличалась.

———
https://github.com/NixOS/nixpkgs/issues/136926 - сломана кросс-сборка #Mesa.

https://habr.com/ru/post/591979/ - про основы кросс-компиляции в разных OSS системах сборки. Спойлер - Meson OK, #autohell и CMake - жесть.

Представление о 6 действиях, как собрать cross-gcc https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/

Про CMake скажу отдельно - у него разных способов контролировать пути поиска тех или иных артефактов штук 10, разных, странных - поштырьте по ссылкам(https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#cmake-system-prefix-path).

Насколько я понимаю, для Mix это нормальное дело. Я строю Nix так, что он всегда кросс-компилирует, даже когда host == target. Это приводит к следующему:

1) Собрать программу полностью в debug/asan/msan/etc - плевое дело. Пользователи интерпрайзных систем сборки к этому привыкли, для OSS это внове.

2) Несколько необычный режим сборки промежуточных артефактов - каждый таргет может быть собран в 3 режимах - lib, bin, data. Нужно это потому, что разные артефакты нужны под host и target платформы, а еще библиотека может зависеть сама от себя, но от своих данных(это достаточно странно, но больше никак не сделать возможность удаления .a файлов, оставляя данные для них(кстати, вот как раз с динамической сборкой это проще - никого не удивляет, что .so живет рядом с share/)).

https://github.com/pg83/mix/blob/main/pkgs/lib/wayland/protocols/mix.sh - вот прекрасный пример, программа может зависеть от библиотеки lib/wayland, от бинарников из lib/wayland, и во время работы ей тоже нужны бинарники из lib/wayland. Если посчитать, то это 3 разных таргета в случае кросс-сборки. В случае host == target часть можно пооптимизировать, но я пока не занимался.

https://www.opennet.ru/opennews/art.shtml?num=56295 #lust
https://harmful.cat-v.org/software/c++/linus

С одной стороны, перестать писать ядро на C - это must have, это давно понимают все большие корпорации(которые и пишут ядро). С другой - для Линуса начать использовать C++ означало бы потерять лицо. Поэтому это будет Rust. Нет, я не думаю, что Rust для этой цели подошел бы значительно лучше С++, но это неважно, оба подходят для этой задачи существенно лучше, чем С.

———
https://github.com/harfbuzz/harfbuzz/issues/2524

Столкнулся тут с прекрасным. Коллеги, на самом деле, еще не поняли, что там по настоящему происходит. Цикл включает в себя не только freetype и #harfbuzz, но и cairo, и #fontconfig.

"Another problem is that currently we include hb-ft in libharfbuzz.so. So removing it will be an ABI break for linux distros. I suggest we do that for harfbuzz 4.0.0. We are just about to release harfbuzz 3.0.0. That gives us about a year to figure out what to do."

"And sadly our package manager cannot automatically do the first-without-then-with-harfbuzz shuffle."

Им разрешение кольцевых зависимостей в пакетных менеджерах подавай. "Дебилы, бл;%:" (с), слов нет.

———
https://github.com/inconvergent/weird

Красивые картинки. Их автору бы познакомиться со Стивеном "Наше все" Вольфрамом(https://habr.com/ru/post/518206/).

https://chromium.googlesource.com/angle/angle/

#ANGLE

Я, давеча, писал про #zink - это OpenGL, реализованный поверх Vulkan(у меня сейчас на нем крутится Sway). Вот это похожая штука, только от Гугла. Я люблю код от Гугла, он у меня не вызывает неприятных эмоций(кроме ограничения на длину строки, но это лечится clang-format). Поэтому надо попробовать! Вырисовывается такой Mesa-free stack - ANGLE + #AMDVLK, или дрова от #Mesa для Vulkan + ANGLE.

———
Меня раздражают фанатики Rust.

Вернее, нет. Меня раздражают фанатики, фанатики Rust в том числе, никаких исключений.

Фанатики Rust хотят, чтобы все было через Rust, никаких исключений. Поэтому они, например, оборачивают C-код в свои crate. Например, libgit2 в Rust - это обернутый C libgit2. При этом, так как это же, все таки, фанатики, они хотят делать вид, что никакого C там нет, поэтому эмбеддят исходники libgit2 прямо в свой crate. А чо, удобно, не нужно возиться с пакетным менеджером, все сделает cargo. Проблемы maintainer никого не волнуют, конечно.

Так как я не люблю фанатизм ни в каком виде, то я такую деятельность не одобряю. К счастью, есть GPL(враг моего врага - мой друг!), поэтому обернуть libiconv таким образом нельзя. Поэтому я очень радуюсь, как у меня обламывается cargo, и просит libiconv из системы.

Ну, и, к счастью, есть проекты, до которых Rust вряд ли когда-нить доберется, типа Qemu. Желание писать на верхнеуровневых безопасных языках чаще всего антикореллирует с желанием копаться в хардверных мануалах, это хуже чем C.

"К счастью", "радуюсь" - потому что я против фанатизма, а вот эти конкретные факты этому конкретно фанатизму мешают. Забавно, что эти факты сами по себе мне тоже не очень ОК, GPL я не люблю, и в Qemu не помешало бы немного C++/Rust.

Это НЕ анти-Rust пост, я уверен, что однажды Rust и его поклонники переживут эти детские болезни, и не будут бояться(а то, вдруг, кто-то ткнет пальцем, и скажет, что чей-та у вас эта либа не на Rust!) использовать код из системы(и из системного пакетного менеджера).