Я, знаете ли, довольно редко брюзжу в стиле "зачем A B, лучше бы С", обычно предпочитаю "какого хрена XYZ".

Но вот, в данном случае, хочется именно так - https://www.phoronix.com/news/Mesa-AGXV-Apple-Vulkan-VKCube

Какого хрена Зачем 2 сильных разработчицы(хехе) пишут одновременно opengl драйвер, и vulkan драйвер, когда есть прекрасный #zink, который может сделать opengl поверх vulkan? Лучше бы бросили все силы на vulkan драйвер.

(там есть такое полу-оправдание, мол, apple m1/m2 заточены под metal, и полный vulkan сделать для них невозможно, но IMHO оно так себе)

https://medium.com/@alt.cap/time-to-get-fit-an-open-letter-from-altimeter-to-mark-zuckerberg-and-the-meta-board-of-392d94e80a18

"To accomplish this goal, we recommend a three step plan that will double FCF to $40 B per year and focus the company’s teams and investments:
* Reduce headcount expense by at least 20%;
* Reduce annual capex by at least $5 B from $30B to $25B; and
* Limit investment in metaverse / Reality Labs to no more than $5B per year"

Тут вот коллегам рекомендуют прекратить жрать в 3 рта ужаться.

Это все весьма интересно, но вот у нас с товарищами вопрос - вот эти 20% - они будут выбираться по performance review, или там тоже будут квоты на ЛГБТ и прочие меньшинства?

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

Не очень интересная, но весьма значимая, новость - в Андроид начали приземлять патчи от Алибабы, про поддержку RISC-V.

Что тут примечательно?

* Китаю, видать, больше по душе халявный RISC-V, чем ARM, за который надо платить, а денег они хотят много.

* Предлагаю прочесть коротенький текст https://wiki.alopex.li/RiscIn2022, чтобы проникнуться фактом - ISA - это API, и, на самом деле, современным вендорам пофиг, через какое API они работают. ARM хорош не потому, что это API классное, а потому что у него есть хорошие референсные дизайны. Стоит появиться IP вендору, который предоставит хорошие дизайны для RISC-V, сойдет лавина, запомните этот твит.

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

Продолжаем тему, почему же повторять vfs в userspace - так себе затея. Казалось бы, ничего сложного, но никто, с первого раза, правильно не пишет.

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

* надо или вызывать fork + chroot
* или уметь возвращать root назад, что-то типа effective root, но тут очевидные проблемы с многопотоком

Вышел Python 3.11: Python for WorkTaskGroups, Миша с фороникса пишет, что ажно на треть быстрее - https://www.phoronix.com/review/python-311-performance

В релизе написано, что ажно на 22% быстрее - https://www.python.org/downloads/release/python-3110/. (еще там какой-то научпоп для решения вращающейся черной дыры)

Где они берут такие цифры, я не понимаю, у меня на реальной задаче(скажем, построение сборочного графа для всех пакетов из #IX) профит приходится искать с лупой.

https://habr.com/ru/company/vk/blog/694536/

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

Понятно, что я никак не могу пройти мимо такой значимой штуки!

Какую задачу решали коллеги?

У них есть 200к сгенерированных из php с/с++ исходников, лапшеобразных, без особых мета-изысков. Они не зависят друг от друга, а зависят, грубо говоря, от "php.h". Если вы знаете, что такое cython, то вы знаете, о чем идет речь.

Такая схема сама по себе довольно неплохо ложится в distcc. Упирается все даже не в линковку, а в препроцессинг. Напомню, что в distcc исходник препроцессится локально, прежде чем быть отосланным на воркер.

Собственно, схема nocc очень напоминает схему с distcc:

* локальный оркестратор
* линковка локальная
* кодогенерация локальная
* на воркерах нет full repository view, в пакете для воркера содержатся все нужные данные

Что поменялось:

* content addressable global cache, как для исходников, так и для .o файлов - то есть, мы сначала передаем md5, а потом, если файла нет в кеше, то докачиваем его

* самое, КМК, главное - локально мы не препроцессим исходник, а парсим его примитивным(быстрым!) парсером, майня в процессе includes. На удаленный сервер в пакете отправляется исходник + все нужные заголовки(с компрессией через global cache)

Собственно, тем самым, расшиваем узкое место distcc.

До настоящих распределенных CI/CD систем это пока не дотягивает. Все же, надо уметь раскладывать в граф весь процесс, а не только компиляцию.

Для исходной задачи, конечно, решение весьма разумно, потому что:

* БОльшая часть исходников зависит только от небольшого, и заранее известного, числа заголовков.

* Обладая контролем над системой, можно сделать приятные оптимизации. Например, разметить сгенеренные файлы так, чтобы почти не парсить их на предмет includes(напомню - узкое место - препроцессор).

Что я хочу еще сказать?

С небольшой толикой везения, коллег ждет явный OSS успех!

Потому что их решение обладает интересным свойством - оно ничем не хуже, чем distcc, а в каких-то аспектах сильно лучше.

Пользователям distcc нет никаких причин не перейти на новую технологию.

(Если тут поспекулировать про распределенные CI/CD от того же Яндекса, или Гугла, и их перспективы в OSS - они, конечно, сильно мощнее, но их никто и никогда не сумеет развернуть за пределами инфраструктуры этих компаний)

(воспользуюсь привилегией быть владельцем собственного дистрибутива)

https://github.com/mobile-shell/mosh/releases

Несколько часов назад вышел новый mosh, релиза не было 5 лет, список фиксов внушает. Кто знает, тот поймет.

Тут вот, 10 дней назад, случился порт epiphany на GTK4. https://github.com/GNOME/epiphany/commit/6e5357947679e48aa1c043f221425255105937a1

Я, конечно, завел его раньше всех, и даже сделал для вас скриншот(как обычно, на телефон, для доказательства того, что все работает на реальном железе)

Оно пока жрет 100% одного ядра, и поэтому не очень юзабельно.

Интерфейсы на libadwaita, признаться, мне нравятся меньше, чем gtk3.

Кажется, у меня есть победитель в этом соревновании. #kuroko

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

https://kuroko-lang.github.io/

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

При этом:

pg-> time python3 ./qw.py 

real  0m0.041s
user  0m0.030s
sys  0m0.003s
pg-> time kuroko ./qw.py 

real  0m0.004s
user  0m0.001s
sys  0m0.001s
pg-> cat qw.py
pg-> 

Ну, то есть, эта штука решает мою основную проблему с Python - на нем невыгодно писать часто выполняющиеся скрипты, типа моего враппера для clang, который реализует всякую магию со статической линковкой - https://github.com/pg83/ix/blob/main/pkgs/bld/scripts/wrapcc/wrapcc.py

В некоторых проектах этот враппер замедляет компиляцию в разы, именно из-за долгой подгрузки интерпретатора.

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

Хочу предложить свою теорию, почему оно растет.

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

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

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

Поэтому людям нужно было все меньше и меньше магии для объяснения окружающего мира.

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

Настало время узких специалистов.

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

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

Ну а раз нас снова окружает магия, то и растет магическое мышление.

И совершенно непонятно, почему эта ситуация может улучшиться. Например, с наступлением дипфейков наступает эра, когда мы не просто тонем в потоке информации, а когда мы не сможем ПРИНЦИПИАЛЬНО сказать, что вообще фактологически верно, а что - нет.

pg-> time python3.10 ./ix mut
READY /ix/store/WMzs8auPYT0HprPg-rlm-system/touch
READY /ix/store/FLF6InICfWIWn8f7-rlm-kernel/touch
READY /ix/store/Npg3GsrWkigH1k19-rlm-boot/touch
READY /ix/store/4E7UpTfSwwBw8Weq-rlm-pg/touch
READY /ix/store/UnsOLbAiiYK25ce2-rlm-install/touch
READY /ix/store/bwCWxrGvGTU2qKgF-rlm-pgg/touch

real  0m7.872s
user  0m6.880s
sys  0m0.092s

pg-> time python3.11 ./ix mut
READY /ix/store/WMzs8auPYT0HprPg-rlm-system/touch
READY /ix/store/FLF6InICfWIWn8f7-rlm-kernel/touch
READY /ix/store/Npg3GsrWkigH1k19-rlm-boot/touch
READY /ix/store/4E7UpTfSwwBw8Weq-rlm-pg/touch
READY /ix/store/UnsOLbAiiYK25ce2-rlm-install/touch
READY /ix/store/bwCWxrGvGTU2qKgF-rlm-pgg/touch

real  0m6.800s
user  0m5.767s
sys  0m0.134s
pg-> 

Так, я заново провел все измерения, убрал все возможные валенки, и таки намерял 15% перфа.

Вышеуказанная команда строит описание сборочного графа из шаблонов, там много jinja2, json, конкатенации строк, и все такое. Короче, на мой вкус, очень показательная питонячка.

15% на дороге не валяются, чего уж тут.

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

А теперь про epiphany во всех (остальных) газетах!

У меня, конечно, по интересным мне темам самый свежак!

А еще до 1000-го пользователя(которому я принудительно устанавливаю #ix на ноутбук) осталось всего 10 человек!

(правда, буду честным, когда я смогу это сделать, я понятия не имею, потому что в МСК стараюсь без веских причин не ездить)

https://github.com/pg83/ix/blob/main/pkgs/bld/scripts/wrapcc/kuroko/wrapcc.krk#L50 #kuroko

Мужик сказал - мужик сделал!

Переписал свой самый главный скрипт на python на kuroko. Оно так раз, и заработало, без излишних проблем.

Что могу сказать?

* Бедная стандартная библиотека(это хорошо!), пришлось наколбасить os.makedirs() самому. subprocess тоже нет, но мне хватило и execve().

* Это действительно диалект питона, в отличие от всяких там starlark(которые похожи снаружи, но имеют совершенно другую модель). Ну, то есть, там есть протокол имплементации генератора, протокол доступа к полям, и они похожи на питонячьи.

* В целом, kuroko похоже на такой обрезанный питон, откуда убрали наслоения "ненужно", и переработали так, как будто перед глазами держали всю эволюцию питона, и сразу знали, как надо.

* block scoped, это очень приятно

Мне понравилось, попробую пописать на нем свои однострочники, для разнообразия.

https://xeiaso.net/blog/openssl-3.x-secvuln-incoming

Тут вот все спекулируют, какое нас ждет стрррашшшное CVE в openssl, а я чем хуже?

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

(все же поняли, что это шутка, да?)

Если серьезно, и если вспомнить старое, то почему бы и нет - однажды уже находили баги в каком-то конкретном генераторе ключей - https://research.swtch.com/openssl

Давно не писал про сумасшедших.

Знаете, у многих гениальных людей есть какой-то пунктик, идея фикс.

У кого-то, например, это мечты про статическую линковку во всем мире. Кто-то, как автор #mold, пишет уже второй самый быстрый линкер в мире.

А вот автор #kuroko, например, считает, что command line help должен быть забацан шрифтом с наклоном.

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

Мир динамического связывания, да еще с попытками сохранять ABI, он странный. Иногда я вообще не понимаю, как там хоть чего-то работает, как замышлял автор.

Вот, например:

Compiler stderr:
 ld.lld: error: duplicate symbol: xcursor_images_destroy
>>> defined at xcursor.c:249 (/ix/build/fja88msjMiHf4EQC/obj/../src/gdk/wayland/cursor/xcursor.c:249)

>>>            xcursor.c.o:(xcursor_images_destroy) in archive /ix/store/fja88msjMiHf4EQC-lib-gtk-4/l
ib/libgtk-4.a
>>> defined at xcursor.c:190 (/ix/build/dZwgGctAuARxPc1P/obj/../src/cursor/xcursor.c:190)
>>>            xcursor.c.o:(.text+0x0) in archive /ix/store/dZwgGctAuARxPc1P-lib-wayland/lib/libwayla
nd-cursor.a

ld.lld: error: duplicate symbol: wl_cursor_image_get_buffer
>>> defined at wayland-cursor.c:162 (/ix/build/fja88msjMiHf4EQC/obj/../src/gdk/wayland/cursor/wayland
-cursor.c:162)
>>>            wayland-cursor.c.o:(wl_cursor_image_get_buffer) in archive /ix/store/fja88msjMiHf4EQC-
lib-gtk-4/lib/libgtk-4.a
>>> defined at wayland-cursor.c:155 (/ix/build/dZwgGctAuARxPc1P/obj/../src/cursor/wayland-cursor.c:15
5)
>>>            wayland-cursor.c.o:(.text+0x0) in archive /ix/store/dZwgGctAuARxPc1P-lib-wayland/lib/l
ibwayland-cursor.a

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

Тут, literally, написано, что авторы gtk4 скопировали кусок wayland(а, может, оба скопировали кусок Xorg, это не очень важно) к себе, и, в случае динамической линковки прикопали эти символы, чтобы они не торчали наружу.

Зачем?

* Понадобилась новая функциональность.

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

К чему это может привести?

Да к чему угодно!

* Иногда это просто работает

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

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

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

А вот Гугл пытается объяснить, зачем же он отрывает в Хроме поддержку #jpegxl, а, на самом деле, фактически, убивает свой же формат.

Расскажу старый советский анекдот на тему:

Коммунизм. Жена посылает мужа в магазин за мясом. Тот возыращается с пустыми руками и говорит: "А там на двери была табличка: "Сегодня в мясе потребности нет!"

https://sourcehut.org/blog/2022-10-31-tos-update-cryptocurrency/ #ddv #source_hut

sr.ht решили поиграть в модерацию проектов. Пишут, что удалят все проекты, связанные с крипто.

Я тут вижу 2 возможности:

1) Их попросили убрать все это говно, с угрозой закрытия иначе.

2) Они сами решили поиграть в модерацию своей площадки.

В любом их этих вариантов мне далее с ними не по пути, потому что они или врут мне про реальные причины удаления, или они - проклятые леваки-#SJW.