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.

Мне тут посоветовали вместо #mosh использовать https://eternalterminal.dev

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

Он, знаете ли, падает у меня, причем очень настойчиво, я фикшу одну ошибку, он падает где-то еще:

pg-> et pg@pg.vla.yp-c.yandex.net
Could not reach the ET server: 
    pg.vla.yp-c.yandex.net:2022

pg-> et -u pg pg.vla.yp-c.yandex.net
Segmentation fault

Штоа?

* Падал при любой попытке вывести исключение. Почему?

376   numFrames = backtrace(stack, 
           MAX_STACK_FRAMES);
377   memmove(stack, stack + 1, 
           sizeof(void *) * (numFrames - 1));

Ну, например, потому что у меня backtrace() возвращает 0, потому что без frame pointer вывести стектрейс - дорогое удовольствие, #musl не умеет. 0 - нормальный результат, https://man7.org/linux/man-pages/man3/backtrace.3.html

* Кидал исключение даже до того, как печатал —help. Почему? Потому что, перед тем, как сделать что-то разумное, пытался перенаправить stderr в файл, и, при этом, содержал некорректную реализацию GetTempDirectory() - https://github.com/MisterTea/EternalTerminal/blob/master/src/base/Headers.hpp#L384 (кто так делает, в 21 веке???), при попытке открыть файл в которой летело исключение. Далее смотри пункт 1. Вообще, неправильное получение tmp dir - этим много кто грешит, поэтому я даже запилил микробиблиотечку, которой патчу клиентов по месту - https://github.com/pg83/ix/blob/main/pkgs/bin/et/ix/ix.sh#L26 https://github.com/pg83/ix/tree/main/pkgs/lib/shim/ix

Настраивать логгирование до парсинга command line - это так-то клиника.

Оно у меня снова падает, и я не уверен, что хочу продолжать этот квест.

Ну я раскопал падение. #debug

https://gist.github.com/pg83/a369133c03715179534c8945c2b6afd6

pg-> /ix/store/q2oDAqRXi4JDSoxV-bin-et-ix/bin/et --help
Remote shell for the busy and impatient
Usage:
  et [OPTION...] [user@]hostname[:port]

  -h, --help                 Print help
      --version              Print version
  -u, --username             Username

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

* username - булева опция
* пытаемся ее получить как строку
* ловим bad_cast в dynamic_cast
* кидаем его, не имея exception handler
* попадаем в std::terminate, который перенастроен библиотекой логгирования
* она пытается вывести в stderr
* у нее не получается(хрен знает, почему)

Там особо красивый сниппет кода:

   2649      std::stringstream reasonStream;
   2650      reasonStream << "Fatal log at [" << m_file << ":" << m_line << "]"
   2651                   << " If you wish to disable 'abort on fatal log' please use "
   2652                   << "el::Loggers::addFlag(el::LoggingFlag::DisableApplicationAbortOnF
   2652 atalLog)";
   2653      base::utils::abort(1, reasonStream.str());

Но abort игнорит текст:

    116 /// @brief Aborts application due with user-defined status
    117 static void abort(int status, const std::string& reason) {
    118   // Both status and reason params are there for debugging with tools like gdb etc
    119   ELPP_UNUSED(status);
    120   ELPP_UNUSED(reason);
    121 #if defined(ELPP_COMPILER_MSVC) && defined(_M_IX86) && defined(_DEBUG)
    122   // Ignore msvc critical error dialog - break instead (on debug mode)
    123   _asm int 3
    124 #else
    125   ::abort();
    126 #endif  // defined(ELPP_COMPILER_MSVC) && defined(_M_IX86) && defined(_DEBUG)
    127 }

* и оно все падает, без внятной диагностики

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

Это эстетика!

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

Я как-то, когда рассказывал про #mesa, вскользь упоминал про то, как она собирается.

Речь шла про то, что, в процессе сборки 3 .so-шек собирается 10 .a-шек, и они каким-то, достаточно произвольным, образом, объединяются в соответствующие .so файлы, с использованием linker script для сокрытия общих частей.

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

Этого требует эстетика динамической сборки!

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

Кстати, ровно в эту же тему можно отнести мой недавний рассказ про дублирование символов в библиотеках #gtk и #wayland. Это же с ума сойти - выделить эти 3 несчастные функции в какую-то совершенно artificial библиотеку, как ее продать пользователю, как опакетить в дистрибутивах, и прочие неприятные вопросы.

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

(пример такого разделения библиотек на части - в следующей серии, и так уже много текста)

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

https://llvm.org/ пишет, что уже можно в clang 15.0.4
Но на https://releases.llvm.org/ ничего нет.
Это все потому, что в(кстати, как правильно, в или на?) github тег уже отвели, но релиз не выложили - https://github.com/llvm/llvm-project/releases/tag/llvmorg-15.0.4
У меня, конечно, весь дистрибутив уже пересобран 8 часов назад, раньше всех! (это я так хвастаюсь)

https://arstechnica.com/tech-policy/2022/09/experts-debate-the-ethics-of-linkedins-algorithm-experiments-on-20m-users/

В статье на серьезных щщах рассуждают, этично ли использовать A/B на кожаных мешках, или нет.

Ну, типа, еслы человек попал в плохой бакет - то это же плохо?

Какой-то левацкий sjw-душок у этого текста, не читайте.

https://kristerw.github.io/2022/11/01/verifying-optimizations/

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

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

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