https://nitter.it/linaasahi/status/1583444549648543744

Между прочим, у #asahi linux какой-то серьезный прогресс за последние несколько месяцев. То год ничего не происходило(с точки зрения графического стека), то на тебе - проходят 99% dEQP - https://chromium.googlesource.com/angle/angle/+/main/doc/dEQP.md - в первый раз слышу, но:

"drawElements (dEQP) is a very robust and comprehensive set of open-source tests for GLES2, GLES3+ and EGL. They provide a huge net of coverage for almost every GL API feature. ANGLE by default builds dEQP testing targets for testing against GLES 2, GLES 3, EGL, and GLES 3.1 (on supported platforms)"

Ну, то есть, явно случилось что-то хорошее.

Еще отмечу, что раньше разработчик(хехе) проверял все на mac(ну, то есть, modesetting занимался mac, а он генерил и слал команды в карточку), то теперь там, в наличии, и modesetting driver для ядра(на rust, ага).

(в фанфары бить пока рановато, прогресс на уровне nouveau, но пользоваться уже можно)

https://github.com/carbon-language/carbon-lang/discussions/2329

У #carbon все еще нет компилятора, но уже есть "Carbon Language community transparency report".

Пишут, что отреагировали на 60+ "плохих" сообщений на discord. К сожалению, ссылок на сами сообщения нет, поэтому еда не очень годная.

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

http://davidbau.com/archives/2010/03/14/the_mystery_of_355113.html

Такая теория чисел нам нравится.

https://daniel.haxx.se/blog/2022/08/12/the-dream-of-auto-detecting-proxies/

Вот тут вот автор curl расписал, почему он не хочет к себе тащить зависимость от libproxy. Давно про нее хотел написать, вот, появился повод.

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

Потому что, в попытке решить простую проблему, добавляет в код кучу новых:

* #plugins Плагинная архитектура - куча загружаемых модулей, каждый под свой DE. Заменяем проблему поиска прокси в DE на поиск плагина для этого DE. Чем это плохо, много раз писал.

* Удивительный факт - плагины используются не по месту! По месу было бы, если бы плагины линковались с библиотеками этого DE, и тогда, действительно, имело бы смысл не загружать в себя чужеродный event loop. Проблема в том, что плагины не линкуются с кодом, а дергают subprocess - https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_kde.cpp#L47 Собственно, это вторая проблема - плагин дергает fork(), чего нельз делать в библиотеке общего назначения.

* Просто код всратого качество - какие-то плагины ловят исключения - https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_kde.cpp#L56, какие-то - нет. https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_gnome3.cpp#L130

* Велосипедизм. https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_gnome3.cpp#L61 - реализация popen2, плохого качества.

Короче, всячески НЕ рекомендую.

Как надо? Надо, конечно, узнавать это через dbus, через xdg portal. Или через переменные среды. Но уж точно не так.

А сегодня у меня короткий рассказ про то, почему же у нас все еще нет self driving cars на наших дорогах.

Дед опять забыл таблетки выпить

"Линус Торвальдс предложил прекратить поддержку CPU i486 в ядре Linux"

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

А, тем временем, на патчи про ускорение сборки ядра от Инго, кажется, положили болт.

#ingo

Я, знаете ли, довольно редко брюзжу в стиле "зачем 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, это очень приятно

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