https://www.reddit.com/r/wayland/comments/uva3os/scrollable_tiling_wm_alternative/
Знаете, обнять и плакать, что называется, как будто сам писал.
scrollable tiling wm, КМК, очень годная тема для ноутбуков.
Это, представьте себе, бесконечная лента окошек в 1 ряд, которую можно скролить влево и вправо, и в каждый момент времени экран ноутбука отображает 2 или 3 сопряженных окна из всей ленты. Новое окно всегда открывается или слева, или справа от текущего.
Проблема в том, что одна из двух существующих альтернатив - это какой-то говнокод на JS для GNOME, и ломается через релиз Clutter, а вторая - заброшенное поделие на wlroots.
———
Из 5 секунд загрузки OS на моем компе:
1 секунду занимает sleep в драйвере amdgpu:
Кстати, загрузка от начала userspace до логина у меня занимает 0 времени.
———
Я занялся энергосбережением для #stal/IX, до сего момента у меня работал "performance" гувернер.
В связи с этим у меня два вопроса - как кошерно настраивать acpi(открытие и закрытие крышки ноутбука, вот это вот все)?
У меня сейчас 2 примитивных скрипта, но, такое ощущение, посреди ночи бывает spurious wakeup, и дальше ноутбук жарит вовсю весь остаток ночи, с закрытой крышкой.
Где взять правильные скрипты для acpid? Или acpid вообще неправильно?
И второй вопрос - cpu frequency scaling.
По идее, политика для ноутбука с большим числом ядер должна быть примерно такой - если есть активные в данный момент времени задачи, то число ядер на full scale должно быть == min(ncpu, числу активных задач), все остальные ядра надо отправлять на low scale. Шедулер должен шедулить задачи на ядра с высокой частотой.
Как настроить linux так, я пока не понял. Не думаю, что это вообще возможно.
Как сейчас принято делать?
Знаете, обнять и плакать, что называется, как будто сам писал.
scrollable tiling wm, КМК, очень годная тема для ноутбуков.
Это, представьте себе, бесконечная лента окошек в 1 ряд, которую можно скролить влево и вправо, и в каждый момент времени экран ноутбука отображает 2 или 3 сопряженных окна из всей ленты. Новое окно всегда открывается или слева, или справа от текущего.
Проблема в том, что одна из двух существующих альтернатив - это какой-то говнокод на JS для GNOME, и ломается через релиз Clutter, а вторая - заброшенное поделие на wlroots.
———
Из 5 секунд загрузки OS на моем компе:
1 секунду занимает sleep в драйвере amdgpu:
[ 0.338250] amdgpu 0000:03:00.0:И еще одну секунду занимает нечто в нечто, делающее нечто:
amdgpu: Will use PSP to load
VCN firmware
[ 1.225631] [drm] reserve 0x400000
from 0xf43f800000 for PSP TMR
[ 3.473944] random: fast init doneПо меркам загрузки винды, наверное, не так уж и много, но зачем?
[ 4.363383] (null): enodev DEV ADDR = 0x00
Кстати, загрузка от начала userspace до логина у меня занимает 0 времени.
———
Я занялся энергосбережением для #stal/IX, до сего момента у меня работал "performance" гувернер.
В связи с этим у меня два вопроса - как кошерно настраивать acpi(открытие и закрытие крышки ноутбука, вот это вот все)?
У меня сейчас 2 примитивных скрипта, но, такое ощущение, посреди ночи бывает spurious wakeup, и дальше ноутбук жарит вовсю весь остаток ночи, с закрытой крышкой.
Где взять правильные скрипты для acpid? Или acpid вообще неправильно?
И второй вопрос - cpu frequency scaling.
По идее, политика для ноутбука с большим числом ядер должна быть примерно такой - если есть активные в данный момент времени задачи, то число ядер на full scale должно быть == min(ncpu, числу активных задач), все остальные ядра надо отправлять на low scale. Шедулер должен шедулить задачи на ядра с высокой частотой.
Как настроить linux так, я пока не понял. Не думаю, что это вообще возможно.
Как сейчас принято делать?
Reddit
From the wayland community on Reddit
Explore this post and more from the wayland community
👍6
Много раз обещал написать, зачем свой дистрибутив Linux, и почему он так устроен. #stal/IX #gold
Часть первая, "зачем".
Мне в современных OS очень много чего не нравится.
* Мне не нравится шедулер Linux. #scheduler
* Мне не нравится закрытые части в macos, ее политика по отношению к приложениям, и, особенно, к инструментам разработчика(профилирование, отладка - все это перестает работать "из коробки")
* Мне, для примера, очень не нравится, что в Unix orphane process прибивается к init'у, я хочу, чтобы все мои процессозапускалки не делали double fork, чтобы видеть completely supervised tree
* Мне не нравится сложность, которую RedHat привносит в Linux, например, systemd - это универсальный(и очень плохой!) запускатор динамического графа задач, система управления загрузкой там вообще сбоку. (правильно, кстати, сделано в macos, там отдельно начальный загрузчик, отдельно socket activation, и так далее) PipeWire - универсальный обработчик графа мультимедия потоков, и нахер он никому не нужен в таком качестве, все вменяемые(да-да, "ни один истинный шотландец") плееры берут дубовый ffmpeg, без вот этой вот всратой динамики и резолве зависимостей плагинов в runtime.
* Мне не нравится наслоение говен на говны в современных LFS/LSB дистрибутивах. Ах, динамическая линковка ведет к dll hell, ну, мы ее оставим, но приделаем ostree и контейнеры для деплоя приложений. Знаете, это решение из серии "сохранить лицо", а не перепридумать, как было бы правильно сделать с самого начала.
Этот список можно продолжать бесконечно, но, я думаю, суть вы уловили.
Я какое-то время думал, как, затратив наименьшие усилия, порешать наибольшее число проблем, которые меня раздражают.
Написать свою OS? Меня этим троллят примерно раз в месяц, и, кстати, я бы запилил неплохую OS(как-нить надо написать, как бы она была устроена). Проблема только в том, что современное(на данный момент времени) графическое приложение я там запущу лет через 15, и то, если сильно не объебусь с архитектурой и инструментами.
Я себе это представляю довольно точно, можно просто посмотреть на динамику развития Linux, и экстраполировать ее исходя из:
* взять нормальный язык, чтобы писать раз в 10 быстрее, чем это делают разрабы Linux
* взяв нормальные архитектурные принципы построения ядра
https://www.opennet.ru/opennews/art.shtml?num=57260 - цифры про размер ядра.
Я так примерно понимаю, что Linux стало норм где-то в районе 2.6, 5 - 10 MLOC. Если взять нормальный язык, надо настругать где-то 0.5 - 1 MLOC.
В общем-то, все предсказуемо, и очень грустно.
В итоге, я решил, что наибольшее число моих проблем может порешать нормальный дистрибутив Linux, который я хорошо понимаю, и могу "загнуть" наиболее подходящим образом.
Например, запилив демон, который прибивает все прибившиеся к init orphane process, постепенно и инкрементально.
Например, отказавшись от динамической линковки и от dll hell, как КЛАССА проблем.
Как это запилить в той же Fedora - это убиться же можно.
Про общую сложность системы, и как я пытаюсь с ней бороться - ну, про это, собственно, и есть весь мой блог.
Из всего вышесказанного следует:
* совершенно бессмысленно меня спрашивать, "почему не systemd"
* "почему не ostree"
* "почему ...
Я пытаюсь как-то по другому решить известные мне проблемы, это исследовательский hobby дистрибутив, а не конкурент для RHEL на его поле.
Если меня устраивает systemd и dll hell, я возьму Fedora, и не буду париться.
Мне же интересно "а как, вообще, можно иначе".
Часть первая, "зачем".
Мне в современных OS очень много чего не нравится.
* Мне не нравится шедулер Linux. #scheduler
* Мне не нравится закрытые части в macos, ее политика по отношению к приложениям, и, особенно, к инструментам разработчика(профилирование, отладка - все это перестает работать "из коробки")
* Мне, для примера, очень не нравится, что в Unix orphane process прибивается к init'у, я хочу, чтобы все мои процессозапускалки не делали double fork, чтобы видеть completely supervised tree
* Мне не нравится сложность, которую RedHat привносит в Linux, например, systemd - это универсальный(и очень плохой!) запускатор динамического графа задач, система управления загрузкой там вообще сбоку. (правильно, кстати, сделано в macos, там отдельно начальный загрузчик, отдельно socket activation, и так далее) PipeWire - универсальный обработчик графа мультимедия потоков, и нахер он никому не нужен в таком качестве, все вменяемые(да-да, "ни один истинный шотландец") плееры берут дубовый ffmpeg, без вот этой вот всратой динамики и резолве зависимостей плагинов в runtime.
* Мне не нравится наслоение говен на говны в современных LFS/LSB дистрибутивах. Ах, динамическая линковка ведет к dll hell, ну, мы ее оставим, но приделаем ostree и контейнеры для деплоя приложений. Знаете, это решение из серии "сохранить лицо", а не перепридумать, как было бы правильно сделать с самого начала.
Этот список можно продолжать бесконечно, но, я думаю, суть вы уловили.
Я какое-то время думал, как, затратив наименьшие усилия, порешать наибольшее число проблем, которые меня раздражают.
Написать свою OS? Меня этим троллят примерно раз в месяц, и, кстати, я бы запилил неплохую OS(как-нить надо написать, как бы она была устроена). Проблема только в том, что современное(на данный момент времени) графическое приложение я там запущу лет через 15, и то, если сильно не объебусь с архитектурой и инструментами.
Я себе это представляю довольно точно, можно просто посмотреть на динамику развития Linux, и экстраполировать ее исходя из:
* взять нормальный язык, чтобы писать раз в 10 быстрее, чем это делают разрабы Linux
* взяв нормальные архитектурные принципы построения ядра
https://www.opennet.ru/opennews/art.shtml?num=57260 - цифры про размер ядра.
Я так примерно понимаю, что Linux стало норм где-то в районе 2.6, 5 - 10 MLOC. Если взять нормальный язык, надо настругать где-то 0.5 - 1 MLOC.
В общем-то, все предсказуемо, и очень грустно.
В итоге, я решил, что наибольшее число моих проблем может порешать нормальный дистрибутив Linux, который я хорошо понимаю, и могу "загнуть" наиболее подходящим образом.
Например, запилив демон, который прибивает все прибившиеся к init orphane process, постепенно и инкрементально.
Например, отказавшись от динамической линковки и от dll hell, как КЛАССА проблем.
Как это запилить в той же Fedora - это убиться же можно.
Про общую сложность системы, и как я пытаюсь с ней бороться - ну, про это, собственно, и есть весь мой блог.
Из всего вышесказанного следует:
* совершенно бессмысленно меня спрашивать, "почему не systemd"
* "почему не ostree"
* "почему ...
Я пытаюсь как-то по другому решить известные мне проблемы, это исследовательский hobby дистрибутив, а не конкурент для RHEL на его поле.
Если меня устраивает systemd и dll hell, я возьму Fedora, и не буду париться.
Мне же интересно "а как, вообще, можно иначе".
www.opennet.ru
В ядро Linux 5.19 принято около 500 тысяч строк кода, связанного с графическими драйверами
В репозиторий, в котором формируется выпуск ядра Linux 5.19, принят очередной набор изменений, связанных с подсистемой DRM (Direct Rendering Manager) и графическими драйверами. Принятый набор патчей интересен тем, что включает 495 тысяч строк кода, что сопоставимо…
👍37🔥3👏2❤1
#stal/IX, часть вторая, почему я делаю так, а не иначе. #gold
* Структура директорий.
Тут все довольно просто, я не понимаю, как сейчас можно пилить новый дистрибутив по LSB/FHS https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Это какое-то жуткое legacy, оставшееся с времен начала Unix, с кучей слабо решаемых проблем(dll hell, атомарные обновления(ostree - это хак, и не уговаривайте в обратном)).
FS должна представлять из себя content adressable storage, по типу git/nix/guix.
Так мы получаем почти бесплатно, just to name a few:
- мультиверсионность
- быстрые накаты и откаты
- атомарные апдейты(переключение всей конфигурации - переключение 1 symlink)
- бесплатное кеширование сборочных артефактов в пакетной системе
- non-root/user package management. Это прямое следствие из content adressable storage.
* Функциональное управление конфигурацией.
Речь идет про то, что, фактически, содержимое etc/ определяется рядом настроек #realm, и описанием пакетной базы.
Руками в etc/ лезть нельзя, оно генерится скриптами подготовки #realm, и вообще, read-only.
Не буду тут много писать, кто знает, тот понимает, а остальным я за 2 предложеняи все равно не объясню.
* Static linking
https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/ - хороший текст с summary, почему основные предъявы к статической линковке не выдерживают серьезной критики.
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/ - я думаю, что вы уже поняли, что я считаю Линуса еще тем упырем, но враг моего врага - мой друг.
- tooling для нее все еще лучше, потому что она простая, как 5 копеек
- судя по форумам, в Linux вечная проблема с динамически загружаемыми плагинами - что-то не нашлось в runtime, и из-за этого ничего не работает. У меня слинковалось - значит, заявленная функциональность будет доступна.
- получившиеся бинари, несмотря на некоторое дублирование объектного кода, быстрее.
- FS чище, нет лишнего мусора, я про каждый файл могу сказать, что он у меня делает. В том же nix/guix могут быть десятки вариантов одной и той же библиотеки, это ungrepable лапша.
- как следствие, эстетически проще иметь разные варианты одной и той же библиотеки, потому что они не мозолят глаза.
- личный фактор
Я последние лет 15 насаждаю статическую линковку в Я, и, в целом, преуспел в этом.
Я имею амбицию показать миру, что на основе этой модели можно получить полноценный, не игрушечный, дистрибутив. Игрушечные, типа stali, oasis, и так далее - это, простите, школьная поделка на фоне того, что уже сделал я.
* Здоровый минимализм. Я хочу иметь возможность обозреть всю систему.
No code bloat, no systemd, no pipewire(?), etc
In general, no vendor lock on RedHat/IBM software.
Красношляпые очень хотят залочить экосистему Linux на себя. На systemd, на gstreamer, как на часть pipewire, etc.
Не вижу в этом ничего хорошего, да и возможности понимать, как работает система, весь этот софт мешает.
Я тут совсем коротенько отмечу, что я не против, если кто-то сделает вариант stal/IX поверх systemd, я этому не мешаю, и даже готов помочь.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/dbus - поштырьте на эту папку, у меня даже runit скрипты не являются частью основного пакета, чтобы можно было параллельно иметь systemd/s6/etc юниты.
* Структура директорий.
Тут все довольно просто, я не понимаю, как сейчас можно пилить новый дистрибутив по LSB/FHS https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Это какое-то жуткое legacy, оставшееся с времен начала Unix, с кучей слабо решаемых проблем(dll hell, атомарные обновления(ostree - это хак, и не уговаривайте в обратном)).
FS должна представлять из себя content adressable storage, по типу git/nix/guix.
Так мы получаем почти бесплатно, just to name a few:
- мультиверсионность
- быстрые накаты и откаты
- атомарные апдейты(переключение всей конфигурации - переключение 1 symlink)
- бесплатное кеширование сборочных артефактов в пакетной системе
- non-root/user package management. Это прямое следствие из content adressable storage.
* Функциональное управление конфигурацией.
Речь идет про то, что, фактически, содержимое etc/ определяется рядом настроек #realm, и описанием пакетной базы.
Руками в etc/ лезть нельзя, оно генерится скриптами подготовки #realm, и вообще, read-only.
Не буду тут много писать, кто знает, тот понимает, а остальным я за 2 предложеняи все равно не объясню.
* Static linking
https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/ - хороший текст с summary, почему основные предъявы к статической линковке не выдерживают серьезной критики.
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/ - я думаю, что вы уже поняли, что я считаю Линуса еще тем упырем, но враг моего врага - мой друг.
- tooling для нее все еще лучше, потому что она простая, как 5 копеек
- судя по форумам, в Linux вечная проблема с динамически загружаемыми плагинами - что-то не нашлось в runtime, и из-за этого ничего не работает. У меня слинковалось - значит, заявленная функциональность будет доступна.
- получившиеся бинари, несмотря на некоторое дублирование объектного кода, быстрее.
- FS чище, нет лишнего мусора, я про каждый файл могу сказать, что он у меня делает. В том же nix/guix могут быть десятки вариантов одной и той же библиотеки, это ungrepable лапша.
- как следствие, эстетически проще иметь разные варианты одной и той же библиотеки, потому что они не мозолят глаза.
- личный фактор
Я последние лет 15 насаждаю статическую линковку в Я, и, в целом, преуспел в этом.
Я имею амбицию показать миру, что на основе этой модели можно получить полноценный, не игрушечный, дистрибутив. Игрушечные, типа stali, oasis, и так далее - это, простите, школьная поделка на фоне того, что уже сделал я.
* Здоровый минимализм. Я хочу иметь возможность обозреть всю систему.
No code bloat, no systemd, no pipewire(?), etc
In general, no vendor lock on RedHat/IBM software.
Красношляпые очень хотят залочить экосистему Linux на себя. На systemd, на gstreamer, как на часть pipewire, etc.
Не вижу в этом ничего хорошего, да и возможности понимать, как работает система, весь этот софт мешает.
Я тут совсем коротенько отмечу, что я не против, если кто-то сделает вариант stal/IX поверх systemd, я этому не мешаю, и даже готов помочь.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/dbus - поштырьте на эту папку, у меня даже runit скрипты не являются частью основного пакета, чтобы можно было параллельно иметь systemd/s6/etc юниты.
Wikipedia
Filesystem Hierarchy Standard
defines the directory structure and directory contents in Linux operating systems
👍18🔥2🥰1👏1
https://www.phoronix.com/scan.php?page=news_item&px=Wayland-1.21-Alpha
Красивое про wayland.
"Two years after the merge request was originally opened, the upcoming Wayland 1.21 release is adding high resolution scroll wheel support for mice to match the work carried out for X.Org and within the Linux kernel drivers. "
Two years.
Не помню, писал ли я это уже, но, КМК, в open source вовсю цветет "трагедия маленького человека, получившего небольшую власть", он же "синдром вахтера".
———
https://lwn.net/Articles/896153/
Это статья про сложность разработки ядра Linux.
Напомню, что есть два вида сложности - inherent complexity, и incidental complexity.
inherent complexity вот этой вот задачки из текста статьи - добавить pure virtual function в интерфейс к FS. Казалось бы, на пару дней для стажера.
Но incidental complexity, которая появилась в этой задаче благодаря нескольким идефиксам Линуса(С вместо С++, очень редкие рефакторинги ядра), потребовала встречи большого количества людей на какой-то конфе.
И эти большие и важные люди целый час обсуждали, как половчее добавить pure virtual function в интерфейс FS.
Текущая модель разработки ядра #linux зашла в тупик, она требует кратных усилий для решения простых задач.
———
https://bethesignal.org/blog/2011/03/12/the-libappindicator-story/
Интересный исторический текст про взаимодействие canonical и redhat(GNOME), в контексте панели уведомлений.
И почему я не удивлен? GNOME во всей своей красе.
———
https://formulae.brew.sh/formula/argp-standalone
Я, давеча, писал, что одна из задач дистростроителя - найти каноничное место с исходником, и использовать его.
У библиотечки arg-standalone(это кусок glibc для парсинга command line options, для non-glibc linux) их ажно целых три:
1) https://www.lysator.liu.se/~nisse/misc/ - оригинал
2) https://github.com/ericonr/argp-standalone - форк, продолжение
3) https://github.com/argp-standalone/argp-standalone - коллеги из freebsd устали, что автор 2) поклал хер на библиотеку, форкнули ее, и продолжают патчить
Все 3 используются, в разных контекстах, разными дистрибутивами.
Кто прав, кто виноват, на кого положиться - непонятно. Я взял версию от freebsd, они ребята чоткие.
Красивое про wayland.
"Two years after the merge request was originally opened, the upcoming Wayland 1.21 release is adding high resolution scroll wheel support for mice to match the work carried out for X.Org and within the Linux kernel drivers. "
Two years.
Не помню, писал ли я это уже, но, КМК, в open source вовсю цветет "трагедия маленького человека, получившего небольшую власть", он же "синдром вахтера".
———
https://lwn.net/Articles/896153/
Это статья про сложность разработки ядра Linux.
Напомню, что есть два вида сложности - inherent complexity, и incidental complexity.
inherent complexity вот этой вот задачки из текста статьи - добавить pure virtual function в интерфейс к FS. Казалось бы, на пару дней для стажера.
Но incidental complexity, которая появилась в этой задаче благодаря нескольким идефиксам Линуса(С вместо С++, очень редкие рефакторинги ядра), потребовала встречи большого количества людей на какой-то конфе.
И эти большие и важные люди целый час обсуждали, как половчее добавить pure virtual function в интерфейс FS.
Текущая модель разработки ядра #linux зашла в тупик, она требует кратных усилий для решения простых задач.
———
https://bethesignal.org/blog/2011/03/12/the-libappindicator-story/
Интересный исторический текст про взаимодействие canonical и redhat(GNOME), в контексте панели уведомлений.
И почему я не удивлен? GNOME во всей своей красе.
———
https://formulae.brew.sh/formula/argp-standalone
Я, давеча, писал, что одна из задач дистростроителя - найти каноничное место с исходником, и использовать его.
У библиотечки arg-standalone(это кусок glibc для парсинга command line options, для non-glibc linux) их ажно целых три:
1) https://www.lysator.liu.se/~nisse/misc/ - оригинал
2) https://github.com/ericonr/argp-standalone - форк, продолжение
3) https://github.com/argp-standalone/argp-standalone - коллеги из freebsd устали, что автор 2) поклал хер на библиотеку, форкнули ее, и продолжают патчить
Все 3 используются, в разных контекстах, разными дистрибутивами.
Кто прав, кто виноват, на кого положиться - непонятно. Я взял версию от freebsd, они ребята чоткие.
Phoronix
Wayland 1.21 Alpha Finally Introduces High-Resolution Scroll Wheel Support
Two years after the merge request was originally opened, the upcoming Wayland 1.21 release is adding high resolution scroll wheel support for mice to match the work carried out for X.Org and within the Linux kernel drivers.
👍9
Про #stal/IX, часть третья. #gold
Про устройство пакетного менеджера.
У меня, по большому счету, было 3 итерации к устройству пакетного менеджера.
* Пекеты представляли из себя описание на языке Python, выполнитель графа для каждой ноды запускал python, который выполнял этот код. Примерно так же устроен homebrew, только там ruby.
Очень быстро я понял, что python совершенно не подходит для этой задачи:
- Он абсолютно не composable, нельзя сконкатенировать 2 скрипта, и получить работающий скрипт, из-за того, что в python важно выравнивание и индентация. Поэтому задача "а вот возьми этот скрипт, и замени там build фазу на вот такую" была совершенно нерабочей.
- Вторая причина общая как для ruby, так для python, так и для всего, кроме posix sh. В этих языках приходится изобретать какой-то dsl, для описания простых действий, которые в shell деллаются простыми командами:
* Вторая итерация - сборочные скрипты в стиле Arch, с метаинформацией в комментариях:
- Задача "возьми вот этот сборочный скрипт, и немношк поменяй в нем build() или список зависимостей" все еще не решалась разумным образом, поэтому цепочка bootstrap содержала в себе много лишнего кода. Ну, типа, приходилось копировать сборочное описание для сборки cmake на самых ранних стадиях, когда еще ничего нет, или уже для более поздних стадий, когда доступен предыдущий cmake и библиотеки.
- Тут меня уже начинало напрягать, что приходется повторять один и тот же boilerplate для вызова meson/cmake/etc. Надо сказать, что, тот же Arch, может звать cmake напрямую. А мне нужно передать 100500 параметров, для того, чтобы обеспечить статическую сборку, и nix-style пути в файловой системе(короче, DESTDIR и PREFIX не по умолчанию)
* В этот момент у меня появилась jinja - язык для описания и подстановки шаблонов, и пакеты стали выглядеть так, как они выглядят сейчас.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/kitty - посмотрите, в t/ лежит шаблон, который специализирует общий шаблон для какой-то сборочной системы, и два его наследника - linux/, darwin/. Посмотрите их перед чтением следующих пунктов.
Тут важно понять, что из этого шаблона строится не shell script, а json, в котором лежат кусочки шелл скриптов для разных фаз(build, configure, etc) сборки, и списки зависимостей.
- Элегантно решаются задачи "а сделай мне все то же самое, но с перламутровыми пуговицами" - расширение и сужение списка зависимостей, замена и проивольные модификации разных блоков.
- Появляется возможность упечь всю логику, связанную с той или иной сборочной системой, в шаблон, и делать ее все более и более сложной.
Примеры:
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/brotli/ix.sh#L7 - а собери-ка мне brotli, но с расширенным списком библиотек, потому что я собираю не либу, а бинарники.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/curl/bleed/ix.sh - а собери-ка мне curl, но с другой http3 библиотекой, и исходниками посвежее.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/gdbm/ix.sh - а собери-ка мне бинарник от libgdbm, и добавь к нему readline(обратите внимание, расширяем не только список библиотек, но и configure флагов)
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/cmake.sh#L43 - базовый шаблон для cmake, посмотрите, сколько я там делаю приседаний, от передачи путей к компилятору, до замены SHARED на STATIC в CMakeLists.txt - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/cmake.sh#L81 Благодаря этому, мои сборочные файлы, которые видит пользователь, lean and mean, там только информация по сути вещей(зависимости), а все эти приседания скрыты от пользователя.
Лиха беда начало, в какой-то момент времени мне стало понятно, что шаблонизатор очень легко решает задачу произвольной настройки сборки того или иного таргета.
Про устройство пакетного менеджера.
У меня, по большому счету, было 3 итерации к устройству пакетного менеджера.
* Пекеты представляли из себя описание на языке Python, выполнитель графа для каждой ноды запускал python, который выполнял этот код. Примерно так же устроен homebrew, только там ruby.
Очень быстро я понял, что python совершенно не подходит для этой задачи:
- Он абсолютно не composable, нельзя сконкатенировать 2 скрипта, и получить работающий скрипт, из-за того, что в python важно выравнивание и индентация. Поэтому задача "а вот возьми этот скрипт, и замени там build фазу на вот такую" была совершенно нерабочей.
- Вторая причина общая как для ruby, так для python, так и для всего, кроме posix sh. В этих языках приходится изобретать какой-то dsl, для описания простых действий, которые в shell деллаются простыми командами:
os.setcwd('xxx')
a = os.environ['yyy'] + '/zzz'
os.setcwd(a)
vscd xxxКороче, этот DSL выглядел всрато, и я совершенно точно не хотел отдавать пользователю это.
cd ${yyy}/zzz
* Вторая итерация - сборочные скрипты в стиле Arch, с метаинформацией в комментариях:
# url https://a.b/c.tgzЭто было уже лучше, но:
# dep lib/c lib/c++
# bld bin/make
build() {
make -j 8
...
}
...
- Задача "возьми вот этот сборочный скрипт, и немношк поменяй в нем build() или список зависимостей" все еще не решалась разумным образом, поэтому цепочка bootstrap содержала в себе много лишнего кода. Ну, типа, приходилось копировать сборочное описание для сборки cmake на самых ранних стадиях, когда еще ничего нет, или уже для более поздних стадий, когда доступен предыдущий cmake и библиотеки.
- Тут меня уже начинало напрягать, что приходется повторять один и тот же boilerplate для вызова meson/cmake/etc. Надо сказать, что, тот же Arch, может звать cmake напрямую. А мне нужно передать 100500 параметров, для того, чтобы обеспечить статическую сборку, и nix-style пути в файловой системе(короче, DESTDIR и PREFIX не по умолчанию)
* В этот момент у меня появилась jinja - язык для описания и подстановки шаблонов, и пакеты стали выглядеть так, как они выглядят сейчас.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/kitty - посмотрите, в t/ лежит шаблон, который специализирует общий шаблон для какой-то сборочной системы, и два его наследника - linux/, darwin/. Посмотрите их перед чтением следующих пунктов.
Тут важно понять, что из этого шаблона строится не shell script, а json, в котором лежат кусочки шелл скриптов для разных фаз(build, configure, etc) сборки, и списки зависимостей.
- Элегантно решаются задачи "а сделай мне все то же самое, но с перламутровыми пуговицами" - расширение и сужение списка зависимостей, замена и проивольные модификации разных блоков.
- Появляется возможность упечь всю логику, связанную с той или иной сборочной системой, в шаблон, и делать ее все более и более сложной.
Примеры:
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/brotli/ix.sh#L7 - а собери-ка мне brotli, но с расширенным списком библиотек, потому что я собираю не либу, а бинарники.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/curl/bleed/ix.sh - а собери-ка мне curl, но с другой http3 библиотекой, и исходниками посвежее.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/gdbm/ix.sh - а собери-ка мне бинарник от libgdbm, и добавь к нему readline(обратите внимание, расширяем не только список библиотек, но и configure флагов)
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/cmake.sh#L43 - базовый шаблон для cmake, посмотрите, сколько я там делаю приседаний, от передачи путей к компилятору, до замены SHARED на STATIC в CMakeLists.txt - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/cmake.sh#L81 Благодаря этому, мои сборочные файлы, которые видит пользователь, lean and mean, там только информация по сути вещей(зависимости), а все эти приседания скрыты от пользователя.
Лиха беда начало, в какой-то момент времени мне стало понятно, что шаблонизатор очень легко решает задачу произвольной настройки сборки того или иного таргета.
🔥13👍2
./ix build bin/xxx --allocator=mimallocВот тут нет НИ ОДНОГО флага, который бы обрабатывался самой системой сборки, это все флаги, которые напрямую пробрасываются во все шаблоны*, и настраивают их поведение:
--nostrip --buildtype=debug --opt=O0
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/c/alloc/ix.sh#L4 - —allocator=
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/build/opt/ix.sh - —opt=
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/std/postinstall.sh#L34 - —nostrip
Система сборки и выполнения графа ничего не знает про эти детали, что позволяет сделать ее очень простой, компактной, и хакабельной.
* - на самом деле, не на все собираемое дерево, а по хитрому алгоритму - на все зависимые библиотеки, и на все зависимые бинари, ЕСЛИ у таргета нет build script. По сути, всегда все прокидываем для hub-целей.
Короче, благодаря правильно выбранному языку шаблонов, получилось добиться очень компактного и хакабельного описания сборки.
И не пришлось изобретать никакого всратого языка, как там в nix, или не пришлось застрять в модели шелл-скрипта, как в Arch.
🔥12
#gold
Много раз жаловался, какой же в Linux херовый #scheduler, что он не может нормально пошедулить браузер во время фоновой нагрузки.
В какой-то момент времени мне показалось, что я таки решил эту проблему, но нифига подобного.
Я добавил в систему #ananicy, чтобы можно было регулировать всякими интересными настройками для выполняющихся программ - rt prio, nice, etc.
Я настроил параметры для самых важных программ в меру своего разумения, что такое RTOS, и как должен работать RT scheduler.
Дальше - "оригинальное исследование" в терминах педивикии, может не совпадать с тем, что написано в более официальных источниках, я эти знания почерпнул на нескольких спецкурсах в своей альма-матери, в то благословенное время, когда там еще пытались учить.
Задача RTOS - не в том, чтобы выполнить вашу задачу максимально быстро, а в том, чтобы выполнить ее за предсказуемое время. Это значит, что, обладая доступом к исходникам, вы можете заранее рассчитать, сколько времени будет занимать тот или иной блок кода.
Задача эта часто противоречит задаче "выполнить заданный код наиболее быстро в среднем"(собственно, это то, что хотят от OS жадные капиталисты в датацентре), и поэтому RTOS и просто OS - это, обычно, разные продукты.
Понятно, где нужно уметь решать такую задачу - в системах контроля за физическими процессами(техникой, ядерным реактором, химическим реактором, в автомобиле, и так далее).
Решается эта задача, если очень грубо:
* Очень простой шедулер. У каждого процесса/треда есть свой приоритет, если в очереди на выполнение есть процесс с бОльшим приоритетом, чем тот, что сейчас выполняется, то выполняемый процесс вытесняется в пользу более приоритетного. В целом, этого уже почти достаточно, чтобы код работал предсказуемо.
* Некоторое расширение модели выше - когда OS делает асинхронную задачу в рамках ядра для какого-то процесса, она должна эту задачу во все свои внутренние очереди тоже класть с приоритетом процесса, которой ее заспаунил. Короче, таска в io queue должна иметь приоритет своего процесса, чтобы io тоже был приоритезированным.
* Priority inversion, priority inheritance. Тут все просто - если процесс с бОльшим приоритетом залочился на mutex, которым владеет процесс с меньшим приоритетом, то надо на время забустить приоритет этого процесса до максимального значения из приоритетов всех процессов, кто хочет этот mutex. Вроде, примерно понятно, зачем это надо, не буду вдаваться в подробности.
Вся эта схема работает, когда все процессы и треды имеют разный приоритет. Если кто-то начинает иметь одинаковый приоритет, то рассчет гарантий на время исполнения становится или очень трудным, или невозможным.
Короче говоря, я разметил все процессы в системе, имея вот это свое понимание, что такое RTOS, и как оно должно работать:
* Композитор имеет класс FIFO, потому что композитор - эта такая штука, которая ничего сама не делает, и только диспатчит сообщения через pipe. Я, опять, долго объяснять не буду, просто подумайте, нужно ли вообще такому процессу иметь возможность быть rescheduled посреди акта своей работы. Мой ответ - нет, не может, это приведет к увеличению latency всей системы, без влияния на throughput.
* По тем же причинам я поставил FIFO для звукового демона, и для dbus брокера.
so long, so good.
Так же я выставил RR класс для web process и gui process браузера epiphany.
* FIFO - это очень простая и понятная штука, тред с FIFO классом выполняется строго по правилам, которые я описал выше.
* RR - это какое-то не до конца мне понятное изобретение в теме, потому что RR класс говорит нам, что RT задачи с одинаковым приоритетом будут обрабатываться через round robin subscheduler. Я думаю, что вы уже поняли, что я считаю такую трактовку RT несколько легкомысленной, потому что что это за херня - задачи с одинаковым приоритетом в RT системе?
Но, в целом, мне это помогло натянуть сову на глобус, потому что процессов от браузера в системе может быть много, и так, действительно, их проще настроить.
Много раз жаловался, какой же в Linux херовый #scheduler, что он не может нормально пошедулить браузер во время фоновой нагрузки.
В какой-то момент времени мне показалось, что я таки решил эту проблему, но нифига подобного.
Я добавил в систему #ananicy, чтобы можно было регулировать всякими интересными настройками для выполняющихся программ - rt prio, nice, etc.
Я настроил параметры для самых важных программ в меру своего разумения, что такое RTOS, и как должен работать RT scheduler.
Дальше - "оригинальное исследование" в терминах педивикии, может не совпадать с тем, что написано в более официальных источниках, я эти знания почерпнул на нескольких спецкурсах в своей альма-матери, в то благословенное время, когда там еще пытались учить.
Задача RTOS - не в том, чтобы выполнить вашу задачу максимально быстро, а в том, чтобы выполнить ее за предсказуемое время. Это значит, что, обладая доступом к исходникам, вы можете заранее рассчитать, сколько времени будет занимать тот или иной блок кода.
Задача эта часто противоречит задаче "выполнить заданный код наиболее быстро в среднем"(собственно, это то, что хотят от OS жадные капиталисты в датацентре), и поэтому RTOS и просто OS - это, обычно, разные продукты.
Понятно, где нужно уметь решать такую задачу - в системах контроля за физическими процессами(техникой, ядерным реактором, химическим реактором, в автомобиле, и так далее).
Решается эта задача, если очень грубо:
* Очень простой шедулер. У каждого процесса/треда есть свой приоритет, если в очереди на выполнение есть процесс с бОльшим приоритетом, чем тот, что сейчас выполняется, то выполняемый процесс вытесняется в пользу более приоритетного. В целом, этого уже почти достаточно, чтобы код работал предсказуемо.
* Некоторое расширение модели выше - когда OS делает асинхронную задачу в рамках ядра для какого-то процесса, она должна эту задачу во все свои внутренние очереди тоже класть с приоритетом процесса, которой ее заспаунил. Короче, таска в io queue должна иметь приоритет своего процесса, чтобы io тоже был приоритезированным.
* Priority inversion, priority inheritance. Тут все просто - если процесс с бОльшим приоритетом залочился на mutex, которым владеет процесс с меньшим приоритетом, то надо на время забустить приоритет этого процесса до максимального значения из приоритетов всех процессов, кто хочет этот mutex. Вроде, примерно понятно, зачем это надо, не буду вдаваться в подробности.
Вся эта схема работает, когда все процессы и треды имеют разный приоритет. Если кто-то начинает иметь одинаковый приоритет, то рассчет гарантий на время исполнения становится или очень трудным, или невозможным.
Короче говоря, я разметил все процессы в системе, имея вот это свое понимание, что такое RTOS, и как оно должно работать:
* Композитор имеет класс FIFO, потому что композитор - эта такая штука, которая ничего сама не делает, и только диспатчит сообщения через pipe. Я, опять, долго объяснять не буду, просто подумайте, нужно ли вообще такому процессу иметь возможность быть rescheduled посреди акта своей работы. Мой ответ - нет, не может, это приведет к увеличению latency всей системы, без влияния на throughput.
* По тем же причинам я поставил FIFO для звукового демона, и для dbus брокера.
so long, so good.
Так же я выставил RR класс для web process и gui process браузера epiphany.
* FIFO - это очень простая и понятная штука, тред с FIFO классом выполняется строго по правилам, которые я описал выше.
* RR - это какое-то не до конца мне понятное изобретение в теме, потому что RR класс говорит нам, что RT задачи с одинаковым приоритетом будут обрабатываться через round robin subscheduler. Я думаю, что вы уже поняли, что я считаю такую трактовку RT несколько легкомысленной, потому что что это за херня - задачи с одинаковым приоритетом в RT системе?
Но, в целом, мне это помогло натянуть сову на глобус, потому что процессов от браузера в системе может быть много, и так, действительно, их проще настроить.
👍10
(продолжение)
И, знаете, эта система приоритетов работала настолько хорошо, что я уже было собрался писать победный пост, как я загнул #scheduler, и у меня все работает плавнее, чем в macos. Кстати, похвастаюсь, что, без нагрузки это УЖЕ так, помогли все мои облизывания и политик шедулинга, и тюнинг аллокатора, и так далее.
Но, конечно, Linux и тут себя показал в своей красе, и это какой-то леденящий душу пиздец.
Я не буду утомлять подробностями #debug, просто расскажу, что происходило.
- я запускал сборку чего-то тяжелого, оно насыщало все CPU.
- в этот момент заходил на сайт с зависшим JS, процесс браузера(который, напомню, RR) начинал жрать 100% CPU.
В этот момент начинал срабатывать какой-то сраный код в ядре, который позволял загруженному на 100% RR треду периодически прерывать выполнение FIFO треда от композитора. Даже на самом деле слегка не так, система ограничила сверху время для FIFO + RR задач в какой-то процент от CPU, что привело к тому, что FIFO задача иногда reschedule посредине своей работы.
В этот момент появлялась какая-та всратая фраза в dmesg, про включение тротлинга, погуглив которую я и узнал, что это just as planned. Ну, то есть, долбоебы-разработчики позаботились о том, чтобы FIFO тред не мог съесть весь CPU, несмотря на то, что я попросил именно это.
Ссылку не дам, потому что затерялась, а восстанавливать весь setup сейчас лениво. Самое близкое, что нашел - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/real_time_throttling
Выглядело это примерно так - движение мышки становилось дерганым, она как будто замирала несколько раз в секунду.
Если вы внимательно прочли мое описание RTOS, то должны согласиться, что такое поведение неприемлемо для RT системы, и, если бы система вела так, как заявлено, то такого эффекта бы не возникало.
Разработчики этой дичи спецкурс моему преподу, конечно, завалили бы.
Короче, TL;DR - выставил я nice для браузера вместо RR, оно, конечно, лучше, чем без nice, но даже и рядом не стояло с правильным, нужным мне, поведением.
#scheduler я пока не победил, но все еще не отчаиваюсь!
И, знаете, эта система приоритетов работала настолько хорошо, что я уже было собрался писать победный пост, как я загнул #scheduler, и у меня все работает плавнее, чем в macos. Кстати, похвастаюсь, что, без нагрузки это УЖЕ так, помогли все мои облизывания и политик шедулинга, и тюнинг аллокатора, и так далее.
Но, конечно, Linux и тут себя показал в своей красе, и это какой-то леденящий душу пиздец.
Я не буду утомлять подробностями #debug, просто расскажу, что происходило.
- я запускал сборку чего-то тяжелого, оно насыщало все CPU.
- в этот момент заходил на сайт с зависшим JS, процесс браузера(который, напомню, RR) начинал жрать 100% CPU.
В этот момент начинал срабатывать какой-то сраный код в ядре, который позволял загруженному на 100% RR треду периодически прерывать выполнение FIFO треда от композитора. Даже на самом деле слегка не так, система ограничила сверху время для FIFO + RR задач в какой-то процент от CPU, что привело к тому, что FIFO задача иногда reschedule посредине своей работы.
В этот момент появлялась какая-та всратая фраза в dmesg, про включение тротлинга, погуглив которую я и узнал, что это just as planned. Ну, то есть, долбоебы-разработчики позаботились о том, чтобы FIFO тред не мог съесть весь CPU, несмотря на то, что я попросил именно это.
Ссылку не дам, потому что затерялась, а восстанавливать весь setup сейчас лениво. Самое близкое, что нашел - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/real_time_throttling
Выглядело это примерно так - движение мышки становилось дерганым, она как будто замирала несколько раз в секунду.
Если вы внимательно прочли мое описание RTOS, то должны согласиться, что такое поведение неприемлемо для RT системы, и, если бы система вела так, как заявлено, то такого эффекта бы не возникало.
Разработчики этой дичи спецкурс моему преподу, конечно, завалили бы.
Короче, TL;DR - выставил я nice для браузера вместо RR, оно, конечно, лучше, чем без nice, но даже и рядом не стояло с правильным, нужным мне, поведением.
#scheduler я пока не победил, но все еще не отчаиваюсь!
👍4
Я думал, что больше всего на свете я ненавижу людей, которые включают -Werror в своем проекте. #werror
Но, вдруг, оказалось, что есть грех и посерьезнее, а именно, включить -Werror в configure скрипта своего проекта:
https://mazzo.li/posts/fast-pipes.html
Интересный текст про передачу большого объема данных через пайпы.
Довольно интересно теоретически, но малополезно практически, потому что, когда вам надо будет передавать столько, вы все равно сделаете преаллоцированный буффер в пошаренной памяти, и будете передавать указатели на его страницы через pipe.
———
Интересное наблюдение - просмотрщики картинок редко когда зависят от imagemagick/graphicsmagic/freeimage/etc.
Это достаточно контринтуитивно, потому что, казалось бы, а где еще применять эти комбайны по загрузке картинок?
90% кода просмотрщика изображений - это фабрика, врапающая загрузку разных форматов в вектор rgb значений.
Моя теория заключается в том, что "так не интересно".
Люди любят OSS, потому что люди любят низковисящие фрукты(в прямом и переносном смысле), а в OSS легко заняться именно низковисящими фруктами.
В больших компаниях, в развитых кодовых базах их давно съели, и злой менеджер заставляет заниматьсяникому не нужным говном задачами, которые займут год и дадут полпроцента НЁХ.
А тут написал вечером загрузку png вдобавок к jpg - у тебя сразу программа в 2 раза лучше стала!
А если добавить поддержку IM, то поле для вкусных и недорогих улучшений сразу и пропадет.
Кстати, КМК, это одна из причин популярности новых языков типа Rust/Go. Они, конечно, лучше, чем старые, а еще там непаханое поле по разработке http сервера.
Это же круто - запилить сотую aio библиотеку, и получить 100500 звезд на гитхабе!
Я тут ничем не лучше, потому что вкусные фрукты вида "написал 5 строк кода, и у тебя в шедулере графа поддержка памяти и CPU ограничений" манят сильно.
Но, вдруг, оказалось, что есть грех и посерьезнее, а именно, включить -Werror в configure скрипта своего проекта:
checking for boost/spirit/Причина:
include/classic.hpp... no
:216:64: error: declaration shadows———
a field of 'subrule_parser<ID, DefT,
ContextT>' [-Werror,-Wshadow]
operator,(subrule_parser<ID2, DefT2,
ContextT2> const& rhs) const
/mix/store/EXZAWbJZCAHZ5qTY-lib-boost/
include/boost/spirit/home/classic/
core/non_terminal/subrule.hpp:229:32:
note: previous declaration is here
typename DefT::embed_t rhs;
https://mazzo.li/posts/fast-pipes.html
Интересный текст про передачу большого объема данных через пайпы.
Довольно интересно теоретически, но малополезно практически, потому что, когда вам надо будет передавать столько, вы все равно сделаете преаллоцированный буффер в пошаренной памяти, и будете передавать указатели на его страницы через pipe.
———
Интересное наблюдение - просмотрщики картинок редко когда зависят от imagemagick/graphicsmagic/freeimage/etc.
Это достаточно контринтуитивно, потому что, казалось бы, а где еще применять эти комбайны по загрузке картинок?
90% кода просмотрщика изображений - это фабрика, врапающая загрузку разных форматов в вектор rgb значений.
Моя теория заключается в том, что "так не интересно".
Люди любят OSS, потому что люди любят низковисящие фрукты(в прямом и переносном смысле), а в OSS легко заняться именно низковисящими фруктами.
В больших компаниях, в развитых кодовых базах их давно съели, и злой менеджер заставляет заниматься
А тут написал вечером загрузку png вдобавок к jpg - у тебя сразу программа в 2 раза лучше стала!
А если добавить поддержку IM, то поле для вкусных и недорогих улучшений сразу и пропадет.
Кстати, КМК, это одна из причин популярности новых языков типа Rust/Go. Они, конечно, лучше, чем старые, а еще там непаханое поле по разработке http сервера.
Это же круто - запилить сотую aio библиотеку, и получить 100500 звезд на гитхабе!
Я тут ничем не лучше, потому что вкусные фрукты вида "написал 5 строк кода, и у тебя в шедулере графа поддержка памяти и CPU ограничений" манят сильно.
mazzo.li
How fast are Linux pipes anyway?
Pipes are ubiquitous in Unix --- but how fast can they go on Linux? In this post we'll iteratively improve a simple pipe-writing benchmark from 3.5GiB/s to 65GiB/s, guided by Linux `perf`.
👍11❤1👎1
https://discourse.llvm.org/t/upcoming-project-policy-changes/62637
Казалось бы, ничего не предвещало, обычный текст про смену политик проекта LLVM, но:
* https://discourse.llvm.org/t/upcoming-project-policy-changes/62637/4
"Users may not be a convicted sex offender or listed on any US state or federal sex offender registry (or other country equivalent)"
ЖЫР, LLVM решили взять на себя функцию суда.
Правда, обсуждение этой темы было довольно тухлым, никому не хочется идти против mainstream SJW идеологии, ну и в бан тоже неохота.
Пока они не решили обсудить фуррей, и не стоит ли их тоже забанить. Нет, really.
https://discourse.llvm.org/t/upcoming-project-policy-changes/62637/14
Я из этого топика узнал, что FurryCon - это такое место, куда съезжаются все фурри, и, на afterparty, снимают все ближайшие отели, и чпокаются там в свое удовольствие.
Но в программе это не объявлено, потому что туда приезжают родители с детьми.
Но все заинтересованные стороны про это знают, и поэтому нефиг удивляться, если там лисичка, вдруг, решила прижать в углу белочку.
Кстати, движение furry мне в чем-то близкО, потому что я(как, я уверен, и ты, аноним!), конечно, в молодости фапал на Гаечку, и у меня даже был соответствующий плакат, с Гайкой, Чипом, и Дейлом, если вы понимаете, о чем я.
Тот факт, что, по версии Диснея, Гайка родила 42 ребенка от Вжика, конечно, разбил мне сердце.
https://daily.afisha.ru/infoporn/23121-urodlivyy-sonik-i-42-rebenka-gayki-i-vzhika-fanatov-shokirovalo-prodolzhenie-chipa-i-deyla/
Казалось бы, ничего не предвещало, обычный текст про смену политик проекта LLVM, но:
* https://discourse.llvm.org/t/upcoming-project-policy-changes/62637/4
"Users may not be a convicted sex offender or listed on any US state or federal sex offender registry (or other country equivalent)"
ЖЫР, LLVM решили взять на себя функцию суда.
Правда, обсуждение этой темы было довольно тухлым, никому не хочется идти против mainstream SJW идеологии, ну и в бан тоже неохота.
Пока они не решили обсудить фуррей, и не стоит ли их тоже забанить. Нет, really.
https://discourse.llvm.org/t/upcoming-project-policy-changes/62637/14
Я из этого топика узнал, что FurryCon - это такое место, куда съезжаются все фурри, и, на afterparty, снимают все ближайшие отели, и чпокаются там в свое удовольствие.
Но в программе это не объявлено, потому что туда приезжают родители с детьми.
Но все заинтересованные стороны про это знают, и поэтому нефиг удивляться, если там лисичка, вдруг, решила прижать в углу белочку.
Кстати, движение furry мне в чем-то близкО, потому что я(как, я уверен, и ты, аноним!), конечно, в молодости фапал на Гаечку, и у меня даже был соответствующий плакат, с Гайкой, Чипом, и Дейлом, если вы понимаете, о чем я.
Тот факт, что, по версии Диснея, Гайка родила 42 ребенка от Вжика, конечно, разбил мне сердце.
https://daily.afisha.ru/infoporn/23121-urodlivyy-sonik-i-42-rebenka-gayki-i-vzhika-fanatov-shokirovalo-prodolzhenie-chipa-i-deyla/
LLVM Discussion Forums
Upcoming Project Policy Changes
The LLVM Project has grown significantly since it began and with that growth we are encountering new territory when it comes to ensuring a healthy, diverse, safe, and thriving community. Recently, we finalized our Code of Conduct and started publishing transparency…
😁9💩3🔥2👍1🥰1
Закончил бутстрап sbcl.
Заняло у меня это около полугода календарного времени.
Не то, что это было очень сложно, просто муторно, ну и цель я себе поставил амбициозную - бутстрап sbcl без работающего бинарника sbcl.
Потому что:
* Под M1 на тот момент не было готовой сборки, хотя код по поддержке был(в виде поддержки darwin вообще + aarch64 в частности)
* sbcl под Linux динамически слинкован с glibc, и у меня просто работать не будет, у меня нет динамического загрузчика от glibc.
Поэтому я решил сделать двойной бутстрап - я собрал интерпретатор Lisp, ecl, с его помощью собрал host sbcl, с помощью которого уже собрал target sbcl.
Cобственно, нащупывание этого решения заняло примерно месяца два - я перебрал несколько интерпретаторов, нашел тот, что в состоянии переварить код sbcl, и так далее.
Потом 4 месяца тягомотины.
Sbcl очень активно использует ffi для загрузки функций из libc и из тела интерпретатора(вот эта тема мне совсем непонятна, на любой символ можно написать extern, зачем делать dlopen?)
Проблема в том, что интерпретатор ecl очень медленный, поэтому итерация "запустить сборку - дождаться, пока сборка вылетит с очередным набором символов, которые не смогли разрешить через dlopen, добавить их в список, повторить" занимает около часа, и это процесс совершенно не инкрементальный - ecl загружает в себя все lisp файлы, потом, имея в себе интерпретируемый образ sbcl, начинает этим sbcl компилировать исходники sbcl. Ошибка резолва dlopen приводит к тому, что весь процесс нужно перезапустить.
Вообще, эта тема с "самосборкой" очень характерна для мира Lisp, для image-based Lisp особенно.
Меня беспокоило, что цепочка (bin ecl + src sbcl) + src sbcl -> bin sbcl даст другой результат, нежели bin sbcl + src sbcl -> bin sbcl даст другой результат, но нет, они байт в байт идентичны, ребята качественно подошли к bootstrap.
То есть, можно сказать, что ecl качественно интерпретирует исходники sbcl.
Потом, конечно, в процессе моей работы, коллеги из sbcl поломали бутстрап через ecl, и мне пришлось удлинить цепочку:
(ecl + src sbcl V1) + src sbcl V1 -> bin sbcl V1
bin sbcl V1 + src sbcl V2 -> bin sbcl V2
По всем канонам, нужно еще бинарь V2 пересобрать сам собой, но я забил.
Кстати, компилятор sbcl довольно шустрый, и код генерит весьма неплохого качества - самосборка у него занимает всего пару минут.
fun fact - у меня не проходил один из тестов на sbcl library, а я не знал, как правильно пропатчить исходник для того, чтобы этот тест отменить. Я пораскинул мозгами, и пришел к выводу, что этот тест так же себя может плохо вести в nix, и потырил фикс у них. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sbcl/t/ix.sh#L26 - я понятия не имею, что делает эта строка на sed, это какое-то аццкое наследие ed.
Зачем мне Lisp?
Ну я, иногда, пописываю чего-нить на нем, мне нравится идея Lisp.
Вообще, мне нравится идея языков с малым исходным смыслом, из которого рождается большое разнообразие форм.
С++/Rust - очень выразительные языки, но и очень перегруженные смыслом.
Lisp/Forth - тоже очень выразительные языки, но исходная смысловая модель в них очень небольшая.
Мне это импонирует, это соответствует моей концепции минимализма.
UPD: мне тут в комментариях, совершенно верно, указали, что Common Lisp огромный, и это так. Я пишу про сам Lisp, без библиотек, про минимальный Scheme, в CLOS я вообще не влезал никогда, например.
Заняло у меня это около полугода календарного времени.
Не то, что это было очень сложно, просто муторно, ну и цель я себе поставил амбициозную - бутстрап sbcl без работающего бинарника sbcl.
Потому что:
* Под M1 на тот момент не было готовой сборки, хотя код по поддержке был(в виде поддержки darwin вообще + aarch64 в частности)
* sbcl под Linux динамически слинкован с glibc, и у меня просто работать не будет, у меня нет динамического загрузчика от glibc.
Поэтому я решил сделать двойной бутстрап - я собрал интерпретатор Lisp, ecl, с его помощью собрал host sbcl, с помощью которого уже собрал target sbcl.
Cобственно, нащупывание этого решения заняло примерно месяца два - я перебрал несколько интерпретаторов, нашел тот, что в состоянии переварить код sbcl, и так далее.
Потом 4 месяца тягомотины.
Sbcl очень активно использует ffi для загрузки функций из libc и из тела интерпретатора(вот эта тема мне совсем непонятна, на любой символ можно написать extern, зачем делать dlopen?)
Проблема в том, что интерпретатор ecl очень медленный, поэтому итерация "запустить сборку - дождаться, пока сборка вылетит с очередным набором символов, которые не смогли разрешить через dlopen, добавить их в список, повторить" занимает около часа, и это процесс совершенно не инкрементальный - ecl загружает в себя все lisp файлы, потом, имея в себе интерпретируемый образ sbcl, начинает этим sbcl компилировать исходники sbcl. Ошибка резолва dlopen приводит к тому, что весь процесс нужно перезапустить.
Вообще, эта тема с "самосборкой" очень характерна для мира Lisp, для image-based Lisp особенно.
Меня беспокоило, что цепочка (bin ecl + src sbcl) + src sbcl -> bin sbcl даст другой результат, нежели bin sbcl + src sbcl -> bin sbcl даст другой результат, но нет, они байт в байт идентичны, ребята качественно подошли к bootstrap.
То есть, можно сказать, что ecl качественно интерпретирует исходники sbcl.
Потом, конечно, в процессе моей работы, коллеги из sbcl поломали бутстрап через ecl, и мне пришлось удлинить цепочку:
(ecl + src sbcl V1) + src sbcl V1 -> bin sbcl V1
bin sbcl V1 + src sbcl V2 -> bin sbcl V2
По всем канонам, нужно еще бинарь V2 пересобрать сам собой, но я забил.
Кстати, компилятор sbcl довольно шустрый, и код генерит весьма неплохого качества - самосборка у него занимает всего пару минут.
fun fact - у меня не проходил один из тестов на sbcl library, а я не знал, как правильно пропатчить исходник для того, чтобы этот тест отменить. Я пораскинул мозгами, и пришел к выводу, что этот тест так же себя может плохо вести в nix, и потырил фикс у них. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sbcl/t/ix.sh#L26 - я понятия не имею, что делает эта строка на sed, это какое-то аццкое наследие ed.
Зачем мне Lisp?
Ну я, иногда, пописываю чего-нить на нем, мне нравится идея Lisp.
Вообще, мне нравится идея языков с малым исходным смыслом, из которого рождается большое разнообразие форм.
С++/Rust - очень выразительные языки, но и очень перегруженные смыслом.
Lisp/Forth - тоже очень выразительные языки, но исходная смысловая модель в них очень небольшая.
Мне это импонирует, это соответствует моей концепции минимализма.
UPD: мне тут в комментариях, совершенно верно, указали, что Common Lisp огромный, и это так. Я пишу про сам Lisp, без библиотек, про минимальный Scheme, в CLOS я вообще не влезал никогда, например.
🔥16👍2
Меня сегодня тянет на философию, а, значит, и вас тоже.
Перед прочтением текста желательно ознакомиться с https://www.scottaaronson.com/writings/bignumbers.html
Можно взглянуть на https://www.quora.com/What-is-the-largest-number-that-can-reasonably-be-written-by-hand #bb
Какое самое большое число можно записать на салфетке?
Физик бы сказал что-то типа "100^500", с большим количеством нулей, и был бы сильно не прав.
Число "максимальное число, которое может вывести на печать машина Тюринга длиной до 1000 символов, и остановиться" сильно, невообразимо сильно, больше.
Но это все так, прелюдия.
https://en.wikipedia.org/wiki/Hierarchy_problem
Я сегодня хочу спросить несколько вопросов про "проблему масштаба" в физике, потому что мне кажется, что физики ее вообще неправильно формулируют, их формулировка не позволяет ничего понять(или даже просто пофантазировать) про окружающий нас мир.
Физики спрашивают, почему физические константы имеют такой большой разброс. Это потому, что они не знают, что такое по настоящему большие числа. 100^500 - это, типа, много.
Я спрашиваю, почему физические константы и величины - это такие МАЛЕНЬКИЕ числа.
* Почему число атомов во вселенной может быть выражено степенной записью числа с небольшими показателями? Почему это, например, не число Аккермана, или число Тюринга?
* Почему все известные физические константы и отношения между ними так хорошо записываются степенной записью числа с небольшими показателями?
* Почему они вообще записываются числами, которые могут поместиться на листке салфетки?
* Почему они вообще записываются числами, которые могут прийти в голову человекообразной обезьяне?
* Ну и финальный вопрос - почему наша вселенная так хорошо описывается числами A^B, с небольшими A, B?
* Есть ли какие-то физические величины, которые так не описываются, и нужна более сильная математическая запись из статьи выше?
Перед прочтением текста желательно ознакомиться с https://www.scottaaronson.com/writings/bignumbers.html
Можно взглянуть на https://www.quora.com/What-is-the-largest-number-that-can-reasonably-be-written-by-hand #bb
Какое самое большое число можно записать на салфетке?
Физик бы сказал что-то типа "100^500", с большим количеством нулей, и был бы сильно не прав.
Число "максимальное число, которое может вывести на печать машина Тюринга длиной до 1000 символов, и остановиться" сильно, невообразимо сильно, больше.
Но это все так, прелюдия.
https://en.wikipedia.org/wiki/Hierarchy_problem
Я сегодня хочу спросить несколько вопросов про "проблему масштаба" в физике, потому что мне кажется, что физики ее вообще неправильно формулируют, их формулировка не позволяет ничего понять(или даже просто пофантазировать) про окружающий нас мир.
Физики спрашивают, почему физические константы имеют такой большой разброс. Это потому, что они не знают, что такое по настоящему большие числа. 100^500 - это, типа, много.
Я спрашиваю, почему физические константы и величины - это такие МАЛЕНЬКИЕ числа.
* Почему число атомов во вселенной может быть выражено степенной записью числа с небольшими показателями? Почему это, например, не число Аккермана, или число Тюринга?
* Почему все известные физические константы и отношения между ними так хорошо записываются степенной записью числа с небольшими показателями?
* Почему они вообще записываются числами, которые могут поместиться на листке салфетки?
* Почему они вообще записываются числами, которые могут прийти в голову человекообразной обезьяне?
* Ну и финальный вопрос - почему наша вселенная так хорошо описывается числами A^B, с небольшими A, B?
* Есть ли какие-то физические величины, которые так не описываются, и нужна более сильная математическая запись из статьи выше?
🔥13
#GNOME hate speech
gtk4 - это FAIL.
https://archlinux.org/packages/extra/x86_64/gtk4/
Почти все проекты, которые перешли на gtk4 - это либо составные части gnome, либо библиотеки, от которых эти составные части зависят.
Почему независимые вендоры не спешат переходить на gtk4?
Мой ответ заключается в том, что довольно много интеграционных библиотек написала Canonical, и они никогда не будут портированы на gtk4.
Речь идет про библиотеки libappindicator, libgtklayershell, и подобные.
Это код интеграции тулкита с desktop environment - уведомления, значки в tray, возможность разработки всякого рода панелей и лончеров.
Почему они не будут портированы на gtk4?
Потому что у GNOME свой, ни с кем не совместимый, путь, и они на херу вертели общепринятые(ну, скажем, в KDE и wlroots) способы интеграции, а gtk3, в основном, используется как gnome-independent toolkit во всяком стороннем софте. Как я уже сказал, это всякого рода панели и лончеры для sway, и так далее.
Видимо, предполагается, что софт на gtk4 должен использовать гномоинтеграции с десктопом, а это совсем не интересно авторам стороннего софта.
———
https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-sourcehut.html
Кеш пакетов для Go от Google ддосит репозитории с этими пакетами.
Кровь из глаз, леденящий душу пиздец, шок, сенсация, поgoраммисты от Google не умеют в элементарный распределенный rate limiter.
Судя по ссылкам на тикеты, они не осилили общий state на разных проксях, зато умеют крутить ручки "ну давайте ходить в 2 раза реже, авось мейнтейнеры отъебутся".
"Currently, a single request for a module may cause refetch traffic for several days after. That may be what you are experiencing. One idea we've been discussing is to make it such that our job only make refresh requests if the module is deemed "popular" enough (e.g. the module has been requested 100 times in the last week). However, this is going to require some re-architecting, and database changes, so it is taking some time to work through."
Зато забанили ДеВолта в своем трекере, да.
У меня, в целом, нет сомнений про общую квалификацию программистов на go, но Google мог бы и получше.
———
https://www.positech.co.uk/cliffsblog/2022/06/05/code-bloat-has-become-astronomical/
rant от старого погромиста про современный софт, и про code bloat.
Не могу не согласиться.
Вообще, я раньше считал, что код нельзя писать во второй раз, и надо переиспользовать по максимуму.
Постепенно я мигрурую к мысли, что какой-то код неплохо бы иногда начинать снова и снова. Знаете, как в отжиге, чтобы выбираться из локального оптимума.
Базы данных все еще недостаточно хороши, и, КМК, им полезно регулярное перепридумывание.
Опять же, до работ Лемира я думал, что парсер float и парсер json - решенные задачи, но нет, даже там есть, что добавить.
Другое дело, если вы переписываете код без внесения в результат чего-то нового - нет, так не надо делать. Еще один такой же base64 никому не нужен.
gtk4 - это FAIL.
https://archlinux.org/packages/extra/x86_64/gtk4/
Почти все проекты, которые перешли на gtk4 - это либо составные части gnome, либо библиотеки, от которых эти составные части зависят.
Почему независимые вендоры не спешат переходить на gtk4?
Мой ответ заключается в том, что довольно много интеграционных библиотек написала Canonical, и они никогда не будут портированы на gtk4.
Речь идет про библиотеки libappindicator, libgtklayershell, и подобные.
Это код интеграции тулкита с desktop environment - уведомления, значки в tray, возможность разработки всякого рода панелей и лончеров.
Почему они не будут портированы на gtk4?
Потому что у GNOME свой, ни с кем не совместимый, путь, и они на херу вертели общепринятые(ну, скажем, в KDE и wlroots) способы интеграции, а gtk3, в основном, используется как gnome-independent toolkit во всяком стороннем софте. Как я уже сказал, это всякого рода панели и лончеры для sway, и так далее.
Видимо, предполагается, что софт на gtk4 должен использовать гномоинтеграции с десктопом, а это совсем не интересно авторам стороннего софта.
———
https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-sourcehut.html
Кеш пакетов для Go от Google ддосит репозитории с этими пакетами.
Кровь из глаз, леденящий душу пиздец, шок, сенсация, поgoраммисты от Google не умеют в элементарный распределенный rate limiter.
Судя по ссылкам на тикеты, они не осилили общий state на разных проксях, зато умеют крутить ручки "ну давайте ходить в 2 раза реже, авось мейнтейнеры отъебутся".
"Currently, a single request for a module may cause refetch traffic for several days after. That may be what you are experiencing. One idea we've been discussing is to make it such that our job only make refresh requests if the module is deemed "popular" enough (e.g. the module has been requested 100 times in the last week). However, this is going to require some re-architecting, and database changes, so it is taking some time to work through."
Зато забанили ДеВолта в своем трекере, да.
У меня, в целом, нет сомнений про общую квалификацию программистов на go, но Google мог бы и получше.
———
https://www.positech.co.uk/cliffsblog/2022/06/05/code-bloat-has-become-astronomical/
rant от старого погромиста про современный софт, и про code bloat.
Не могу не согласиться.
Вообще, я раньше считал, что код нельзя писать во второй раз, и надо переиспользовать по максимуму.
Постепенно я мигрурую к мысли, что какой-то код неплохо бы иногда начинать снова и снова. Знаете, как в отжиге, чтобы выбираться из локального оптимума.
Базы данных все еще недостаточно хороши, и, КМК, им полезно регулярное перепридумывание.
Опять же, до работ Лемира я думал, что парсер float и парсер json - решенные задачи, но нет, даже там есть, что добавить.
Другое дело, если вы переписываете код без внесения в результат чего-то нового - нет, так не надо делать. Еще один такой же base64 никому не нужен.
👍13🔥2
Подхватываем флешмоб.
Меня регулярно спрашивают, почему мои посты про #GNOME такие резкие.
Отвечаю - я их ненавижу!
Они плохие люди, и другие плохие люди.
Они хотят смерти Wayland, и хотят заменить его на dbus! Dbus, Карл!
И, пока я жив, я буду делать все, что в моих силах, чтобы не допустить этого!
Меня регулярно спрашивают, почему мои посты про #GNOME такие резкие.
Отвечаю - я их ненавижу!
Они плохие люди, и другие плохие люди.
Они хотят смерти Wayland, и хотят заменить его на dbus! Dbus, Карл!
И, пока я жив, я буду делать все, что в моих силах, чтобы не допустить этого!
😁46🔥3👍1
Я периодически занимаюсь yak stalix shaving, если вы понимаете, о чем я.
Меня, например, довольно сильно интересует, кто из программ жрет батарейку, и, особенно, кто жрет ее не по делу.
Делаю я это довольно просто, через какое-то время после запуска ноутбука запускаю htop, и смотрю, кто из постоянно висящих процессов сожрал больше всего батарейки.
Мой топ:
epiphany - 20 попугаев
sway - 16 попугаев
ananicy-cpp - 6 попугаев
telegram-desktop - 6 попугаев
Если с первыми двумя все понятно, epiphany - тормозное говно, sway периодически делает много memcpy, то к двум оставшимся есть вопросы.
Я начал с телеги, потому что какого хрена? ananicy писал какой-то пионер, а вот телега, когда ей не пользуются, не должна делать ни-фи-га.
Но нет, strace показал, что телега просыпается 125 раз в секунду, не делает нихрена, и снова засыпает.
(кстати, судя по интеренетам, людям довольно часто рекомендуют это делать, для борьбы с багами. Так-то понятно, что встраиваться в чужеродный и неконтролируемый event loop - так себе идея)
(небольшая ремарка - event loop в glib - 200KB всратейшего кода на C, в QT - 15KB хорошо документированного и простого кода на С++. Это я опять к тому, что на С нельзя писать никакие серьезные объемы кода, ни gui библиотеку, ни ядро Linux, да)
Короче, это тоже не помогло, через какое-то время телега снова начинает сыпать в strace 125 раз в секунду какой-то хней.
Я так полагаю, что это какой-то непонятный таймер, и разработчики просто промахнулись, должно было быть 8 секунд.
Потому что что может телега хотеть делать 125 раз в секунду?
Багрепорт еще не завел, не успел.
Меня, например, довольно сильно интересует, кто из программ жрет батарейку, и, особенно, кто жрет ее не по делу.
Делаю я это довольно просто, через какое-то время после запуска ноутбука запускаю htop, и смотрю, кто из постоянно висящих процессов сожрал больше всего батарейки.
Мой топ:
epiphany - 20 попугаев
sway - 16 попугаев
ananicy-cpp - 6 попугаев
telegram-desktop - 6 попугаев
Если с первыми двумя все понятно, epiphany - тормозное говно, sway периодически делает много memcpy, то к двум оставшимся есть вопросы.
Я начал с телеги, потому что какого хрена? ananicy писал какой-то пионер, а вот телега, когда ей не пользуются, не должна делать ни-фи-га.
Но нет, strace показал, что телега просыпается 125 раз в секунду, не делает нихрена, и снова засыпает.
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
[pid 28550] poll([{fd=5, events=POLLIN},
{fd=16, events=POLLIN}], 2, 8) = 0
(Timeout)
Я докопался, что это происходит в glib/dbus event loop, и хотел уже было списать все на гноморазработчиков, но увидел по исходникам qt, https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixeventdispatcher.cpp , что это несложно переключить на встроенный в qt event loop.(кстати, судя по интеренетам, людям довольно часто рекомендуют это делать, для борьбы с багами. Так-то понятно, что встраиваться в чужеродный и неконтролируемый event loop - так себе идея)
(небольшая ремарка - event loop в glib - 200KB всратейшего кода на C, в QT - 15KB хорошо документированного и простого кода на С++. Это я опять к тому, что на С нельзя писать никакие серьезные объемы кода, ни gui библиотеку, ни ядро Linux, да)
Короче, это тоже не помогло, через какое-то время телега снова начинает сыпать в strace 125 раз в секунду какой-то хней.
Я так полагаю, что это какой-то непонятный таймер, и разработчики просто промахнулись, должно было быть 8 секунд.
Потому что что может телега хотеть делать 125 раз в секунду?
Багрепорт еще не завел, не успел.
GitHub
qtbase/src/gui/platform/unix/qgenericunixeventdispatcher.cpp at dev · qt/qtbase
Qt Base (Core, Gui, Widgets, Network, ...). Contribute to qt/qtbase development by creating an account on GitHub.
👍20
https://www.opennet.ru/opennews/art.shtml?num=57320
Pyston-модуль, для ускорения обычного CPython кода. Новость довольно интересная сама по себе, можно поспекулировать про эти оптимизации, и про грядущий 3.11, который я, например, на своих приборах не вижу, зато команда рапортует про двузначный профит.
Но я хочу поговорить про другой аспект этой шняги. А именно, про то, что компиляцию в native code нужно делать в отдельном демоне, а не в разделяемой библиотеке.
#fontconfig #daemon_vs_dylib
В современных операционных системах слишком многое делается через загрузку разделяемого кода в пространоство процесса, нежели через отдельные демоны.
Just to name a few:
* fontconfig - резолвинг имен шрифтов в пути. Сейчастам дичь в библиотеке, которая раз в 20 секунд перечитывает fc cache.
* Рендеринг глифов в freetype
* Рендеринг svg. Зачем тащить в каждое приложение inferior librsvg, когда можно рендерить все через классный inkscape?
* mesa, shaders - компилятор на основе llvm для шейдеров
* теперь вот компилятор для python bytecode
* clangd - тут хорошо, тут люди подумали головой
* nss модули в libc- тут, уже, вроде, есть консенсус, что не надо так.
Лично я считаю, что это жесть, и что OS-е строение идет не туда.
Посудите сами. Чем меньше возможных состояний у программы, тем лучше:
* Потому что проще тестировать. Для тестирования 2 программ с M, N состояниями нужно порядка N + M тестов, для совокупной программы нужно еще + N*M*alpha тестов. Потому что в совокупной программе все равно будет пошаренный state, типа аллокатора.
* Потому что баги имеют ограниченный scope. Представьте себе проезд по памяти в однопоточной программе, которая конвертирует python bytecode -> native code с помощью llvm. В случае демона, вы можете этого даже не заметить, если проезд произошел "куда надо", или демон просто рестартанет, и вы тоже это не заметите. В случае загрузки .so падает все приложение. А я вам скажу, что тащить в long living program компилятор из llvm - это для очень отчаянных людей. Оно обычно живет в short living процессах компиляции, и даже авторы clangd/xcode понимают это, и изолируют код clang/llvm в отдельных процессах.
* Проще кешировать результат работы того или иного блока кода. Посмотрите, например, как устроено кеширование байткода в pyston, или кеширование шейдеров в mesa. В случае отдельных демонов, которые занимаются компиляцией шейдеров или байткода, можно взгромоздить общесистемный memcached, и просто забыть про эту задачу. Можно не пересобирать svg иконки от запуска к запуску приложения! Да много чего станет проще и лучше.
* Более просто подменить реализацию. Это прямо не очень очевидно, но заменить демон с хорошо определенным интерфейсом существенно проще, чем подменить .so, с кучей торчащих отовсюду запчастей. Ну, типа, не понравилось, как pystond компилирует python bytecode, заменил на что-то более мощное.
* Треды в .so и/или программе, fork() в .so и/или программе.
В случае Linux и прочего OSS, это классическая проблема общин, и что тут можно сделать - совершенно непонятно, в каждый момент времени проще накостылять еще одну .so, чем договориться про устраивающий всех способ запустить session daemon.
В случае macOS, кстати, есть все шансы, что Apple пойдет правильным путем.
Pyston-модуль, для ускорения обычного CPython кода. Новость довольно интересная сама по себе, можно поспекулировать про эти оптимизации, и про грядущий 3.11, который я, например, на своих приборах не вижу, зато команда рапортует про двузначный профит.
Но я хочу поговорить про другой аспект этой шняги. А именно, про то, что компиляцию в native code нужно делать в отдельном демоне, а не в разделяемой библиотеке.
#fontconfig #daemon_vs_dylib
В современных операционных системах слишком многое делается через загрузку разделяемого кода в пространоство процесса, нежели через отдельные демоны.
Just to name a few:
* fontconfig - резолвинг имен шрифтов в пути. Сейчастам дичь в библиотеке, которая раз в 20 секунд перечитывает fc cache.
* Рендеринг глифов в freetype
* Рендеринг svg. Зачем тащить в каждое приложение inferior librsvg, когда можно рендерить все через классный inkscape?
* mesa, shaders - компилятор на основе llvm для шейдеров
* теперь вот компилятор для python bytecode
* clangd - тут хорошо, тут люди подумали головой
* nss модули в libc- тут, уже, вроде, есть консенсус, что не надо так.
Лично я считаю, что это жесть, и что OS-е строение идет не туда.
Посудите сами. Чем меньше возможных состояний у программы, тем лучше:
* Потому что проще тестировать. Для тестирования 2 программ с M, N состояниями нужно порядка N + M тестов, для совокупной программы нужно еще + N*M*alpha тестов. Потому что в совокупной программе все равно будет пошаренный state, типа аллокатора.
* Потому что баги имеют ограниченный scope. Представьте себе проезд по памяти в однопоточной программе, которая конвертирует python bytecode -> native code с помощью llvm. В случае демона, вы можете этого даже не заметить, если проезд произошел "куда надо", или демон просто рестартанет, и вы тоже это не заметите. В случае загрузки .so падает все приложение. А я вам скажу, что тащить в long living program компилятор из llvm - это для очень отчаянных людей. Оно обычно живет в short living процессах компиляции, и даже авторы clangd/xcode понимают это, и изолируют код clang/llvm в отдельных процессах.
* Проще кешировать результат работы того или иного блока кода. Посмотрите, например, как устроено кеширование байткода в pyston, или кеширование шейдеров в mesa. В случае отдельных демонов, которые занимаются компиляцией шейдеров или байткода, можно взгромоздить общесистемный memcached, и просто забыть про эту задачу. Можно не пересобирать svg иконки от запуска к запуску приложения! Да много чего станет проще и лучше.
* Более просто подменить реализацию. Это прямо не очень очевидно, но заменить демон с хорошо определенным интерфейсом существенно проще, чем подменить .so, с кучей торчащих отовсюду запчастей. Ну, типа, не понравилось, как pystond компилирует python bytecode, заменил на что-то более мощное.
* Треды в .so и/или программе, fork() в .so и/или программе.
В случае Linux и прочего OSS, это классическая проблема общин, и что тут можно сделать - совершенно непонятно, в каждый момент времени проще накостылять еще одну .so, чем договориться про устраивающий всех способ запустить session daemon.
В случае macOS, кстати, есть все шансы, что Apple пойдет правильным путем.
www.opennet.ru
Представлен Pyston-lite, JIT-компилятор для штатного Python
Разработчики проекта Pyston, предлагающего высокопроизводительную реализацию языка Python, использующую современные технологии JIT-компиляции, представили расширение Pyston-lite с реализацией JIT-компилятора для CPython. Если Pyston является ответвлением…
👍10🔥2
Меня тут в комментариях спрашивали, что я собираюсь делать с вопроизведением звука через bluetooth, потому что в Linux оно нормально работает только через PipeWire. #cras #sndio
Я на это ответил, что у меня есть 2 варианта:
1) alsa умеет предоставлять bluetooth out, как свое устройство. Этот способ я оставил на самый крайний случай, потому что разработчики alsa упыри, и я не хочу связываться с их способом микшировать звук.
2) Есть такая вундервафля - ChromiumOS. И в ней есть звуковой демон, про который никто ничего не знает, но он умеет в bluetooth.
Сегодня мой рассказ про CRAS - Chromium Audio Server. https://www.chromium.org/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/ . Ну, точнее, про мое хождение по мукам с ним.
Лежит он вот тут - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras
Про этот софт, действительно, никто за пределами ChromeOS никто ничего не знает. Информации 0, даже в Arch нет пакета с ним, я тут первопроходец.
Вот его процедура сборки(точнее, подготовка зависимостей) - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/install_deps.sh
Видно, что коллеги особо не заморачивались, методичностью гугла тут и не пахнет.
* Сборка завязана на glibc, пришлось добавить отсутствующий файл в musl - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/gnushim/ieee754.h
* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L59 - коллеги упустили какой-то missing include.
* без плагинов, монолитный бинарь, google кремень.
* Все бы ничего, но, как выяснилось, в 19 году Гугл препринял попытку переписать часть этого кода на Rust.
Тут я взвыл, потому что компилятор Rust у меня все еще не готов.
Но, пораскинув мозгами, и почитав код - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/rust/, я понял, что они переписали 1(один) файл, и на этом остановились.
Я человек вредный, я полагаю, что там кто-то получил премию за внедрение безопасного языка, а потом на это забили, потому что нафиг никому не нужно.
Так за 3 года в репе и остался 1 файл на rust(по существу, еще там ворох кодогенерации, чтобы обернуть сишные типы).
Я решил, что ну его в жопу, нашел место, в котором был осуществлен акт вандализма, и просто взял имплементаци оттуда.
Кстати, давайте их сравним:
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/rust/src/rate_estimator.rs
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/454c81a0669c2c5ffc7132d870b7421291b6630e/cras/src/server/rate_estimator.c
Выделений памяти там нет, просто фигачим в буфер фиксированного размера семплы, а потом считаем регрессию.
Выводы, конечно, каждый может сделать сам для себя, но так-то rust оказался несколько многословнее, совершенно на пустом месте.
Собственно, остатки сборочного файла - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L64 - это выковыривание зависимости от rust, и добавление старого кода в сборку.
Кстати, хочу на этом примере показать разницу в подходах конвенциональных дистрибутивов, и моего.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L70
Есть ощущение, что коллеги пытаются оформить diff так, чтобы результат был пригоден для редактирования человеком. В данном случае они, честь по чести, отредактировали бы Makefile, добавили туда новый файл, и так далее.
Я же руководствуюсь эффективностью. Мне надо собрать определенный код - я его добавлю в заведомо собираемый файл, одной строчкой. Да, это нечитаемая мешанина на выходе, но зато я решил задачу за 5 секунд, и оно не сломается при обновлении Makefile.
КМК, это очень важно.
Короче, cras я собрал, но пока не могу похвастаться тем, что он у меня заработал.
Кажется, Google не очень заинтересован тем, чтобы этот код использовали где-то вне ChromeOS - доков нет, примера конфига нет, —help не работает!
Пока запускаю strace, читаю код.
Возможно, это гнилое дело, но, на самом деле, очень интересно само по себе!
Я на это ответил, что у меня есть 2 варианта:
1) alsa умеет предоставлять bluetooth out, как свое устройство. Этот способ я оставил на самый крайний случай, потому что разработчики alsa упыри, и я не хочу связываться с их способом микшировать звук.
2) Есть такая вундервафля - ChromiumOS. И в ней есть звуковой демон, про который никто ничего не знает, но он умеет в bluetooth.
Сегодня мой рассказ про CRAS - Chromium Audio Server. https://www.chromium.org/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/ . Ну, точнее, про мое хождение по мукам с ним.
Лежит он вот тут - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras
Про этот софт, действительно, никто за пределами ChromeOS никто ничего не знает. Информации 0, даже в Arch нет пакета с ним, я тут первопроходец.
Вот его процедура сборки(точнее, подготовка зависимостей) - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/install_deps.sh
Видно, что коллеги особо не заморачивались, методичностью гугла тут и не пахнет.
* Сборка завязана на glibc, пришлось добавить отсутствующий файл в musl - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/gnushim/ieee754.h
* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L59 - коллеги упустили какой-то missing include.
* без плагинов, монолитный бинарь, google кремень.
* Все бы ничего, но, как выяснилось, в 19 году Гугл препринял попытку переписать часть этого кода на Rust.
Тут я взвыл, потому что компилятор Rust у меня все еще не готов.
Но, пораскинув мозгами, и почитав код - https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/rust/, я понял, что они переписали 1(один) файл, и на этом остановились.
Я человек вредный, я полагаю, что там кто-то получил премию за внедрение безопасного языка, а потом на это забили, потому что нафиг никому не нужно.
Так за 3 года в репе и остался 1 файл на rust(по существу, еще там ворох кодогенерации, чтобы обернуть сишные типы).
Я решил, что ну его в жопу, нашел место, в котором был осуществлен акт вандализма, и просто взял имплементаци оттуда.
Кстати, давайте их сравним:
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/master/cras/src/server/rust/src/rate_estimator.rs
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/454c81a0669c2c5ffc7132d870b7421291b6630e/cras/src/server/rate_estimator.c
Выделений памяти там нет, просто фигачим в буфер фиксированного размера семплы, а потом считаем регрессию.
Выводы, конечно, каждый может сделать сам для себя, но так-то rust оказался несколько многословнее, совершенно на пустом месте.
Собственно, остатки сборочного файла - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L64 - это выковыривание зависимости от rust, и добавление старого кода в сборку.
Кстати, хочу на этом примере показать разницу в подходах конвенциональных дистрибутивов, и моего.
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/cras/ix.sh#L70
Есть ощущение, что коллеги пытаются оформить diff так, чтобы результат был пригоден для редактирования человеком. В данном случае они, честь по чести, отредактировали бы Makefile, добавили туда новый файл, и так далее.
Я же руководствуюсь эффективностью. Мне надо собрать определенный код - я его добавлю в заведомо собираемый файл, одной строчкой. Да, это нечитаемая мешанина на выходе, но зато я решил задачу за 5 секунд, и оно не сломается при обновлении Makefile.
КМК, это очень важно.
Короче, cras я собрал, но пока не могу похвастаться тем, что он у меня заработал.
Кажется, Google не очень заинтересован тем, чтобы этот код использовали где-то вне ChromeOS - доков нет, примера конфига нет, —help не работает!
Пока запускаю strace, читаю код.
Возможно, это гнилое дело, но, на самом деле, очень интересно само по себе!
🔥13👍1
https://blogs.blackberry.com/en/2022/06/symbiote-a-new-nearly-impossible-to-detect-linux-threat
Простите, но не могу терпеть до завтра :D
"Symbiote: A New, Nearly-Impossible-to-Detect Linux Threat"
"What makes Symbiote different from other Linux malware that we usually come across, is that it needs to infect other running processes to inflict damage on infected machines. Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability."
.so, LD_PRELOAD, я так понимаю, у меня оно даже не запустится.
Простите, но не могу терпеть до завтра :D
"Symbiote: A New, Nearly-Impossible-to-Detect Linux Threat"
"What makes Symbiote different from other Linux malware that we usually come across, is that it needs to infect other running processes to inflict damage on infected machines. Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability."
.so, LD_PRELOAD, я так понимаю, у меня оно даже не запустится.
BlackBerry
Symbiote: A New, Nearly-Impossible-to-Detect Linux Threat
There's a new, nearly-impossible-to-detect Linux threat that may be hiding in your running processes. Learn more about "Symbiote," discovered via new joint research by Intezer and BlackBerry.
😁11👍4🔥2❤1
https://semianalysis.substack.com/p/apple-m2-die-shot-and-architecture?s=r
M2, конечно, разочарование.
За два года Apple выкатили +20% перфа, что, кажется, сравнимо со скоростью роста конкурентов.
Ну и я совершенно не могу понять этого жлобства - 1 CPU ядро занимает порядка квадратного миллиметра, почему бы не напихать их 20 штук?
Ладно, на самом деле, могу, 20 штук напихают в Mac Pro, и продадут за кучу денег.
M2, конечно, разочарование.
За два года Apple выкатили +20% перфа, что, кажется, сравнимо со скоростью роста конкурентов.
Ну и я совершенно не могу понять этого жлобства - 1 CPU ядро занимает порядка квадратного миллиметра, почему бы не напихать их 20 штук?
Ладно, на самом деле, могу, 20 штук напихают в Mac Pro, и продадут за кучу денег.
SemiAnalysis
Apple M2 Die Shot and Architecture Analysis – Big Cost Increase And A15 Based IP
Apple announced their new 20 billion transistor M2 SoC at WWDC. Unfortunately, it’s quite a minor uplift in performance in some areas such as CPU. Apple’s gains mostly came from the GPU and video editing side of things.
😁7
https://lwn.net/Articles/897198/, paywall, но, все равно, тема интересная, не могу не затронуть. #vendor
TL;DR - fedora офигели от сложности де-вендоринга Java, и решили поставлять ее as is, с теми либами, которые вендорит Oracle.
https://lwn.net/ml/fedora-devel/CA+voJeUVXW2XYHKaJ8S2N3KgvSMVUx6TsKFOvDDnjctsdO70jA@mail.gmail.com/ - переписка про это.
Я, с одной стороны, считаю, что это правильный путь, с другой - максимализм Федоры меня поражает, они хотят оставить завендоренными и freetype, и harfbuzz. А это значит, что гуевые Java приложения будут выглядеть ЕЩЕ более вырвиглазно.
С другой стороны, понятно, почему таки вендорить эти библиотеки им нужно - они хотят поставлять один tgz файл для всех версий федоры и rhel, с целью упрощения прохождения java conformance test. Тест нельзя не проходить, если ты хочешь называть финальный продукт Java.
Что еще интересного:
* вендоры периодически патчат уязвимости быстрее, чем это делают дистрибутивы. Это, практически, шах и мат для аргументов в стиле "завендоренные либы содержат уязвимости, кототорые никто не обновляет". Обновляют, просто умеют считать деньги, и не обновляют, когда impact нулевой.
* Пишут, что девендоринг Java, и, тем более, динамическая ее линковка, стоили несколько десятков человеко-лет компании. "To introduce properly working dynamically linked JDK to Fedora took several excellent engineers several years. Even after a decade, there are remaining unfixed issues. And new issues are appearing.", и "This is the holy grail we have been pursuing for last 10 years. But now we gave up. To keep java alive in Fedora, we have to take this one step back." Вообще, тут, конечно, динамическая линковка кажется каким-то совершенно cargo cult, а не чем-то полезным.
* С поддержкой Wayland все не очень понятно.
* Так же рассматривались 2 решения, которые не нашли поддержки - просто переупаковывать сборку от Oracle, или забить на Java в репозиториях at all, потому что для прода все равно ставят Oracle. Ну, понятно, такое не прокатило, а зря.
* Вендоры иногда так патчат забандленные библиотеки, что их невозможно смержить с upstream. Не вижу в этом проблем per se, пусть патчат. На то это и OSS, что можно не договариваться с упырями в upstream, и просто самому себе готовить нужный продукт.
TL;DR - fedora офигели от сложности де-вендоринга Java, и решили поставлять ее as is, с теми либами, которые вендорит Oracle.
https://lwn.net/ml/fedora-devel/CA+voJeUVXW2XYHKaJ8S2N3KgvSMVUx6TsKFOvDDnjctsdO70jA@mail.gmail.com/ - переписка про это.
Я, с одной стороны, считаю, что это правильный путь, с другой - максимализм Федоры меня поражает, они хотят оставить завендоренными и freetype, и harfbuzz. А это значит, что гуевые Java приложения будут выглядеть ЕЩЕ более вырвиглазно.
С другой стороны, понятно, почему таки вендорить эти библиотеки им нужно - они хотят поставлять один tgz файл для всех версий федоры и rhel, с целью упрощения прохождения java conformance test. Тест нельзя не проходить, если ты хочешь называть финальный продукт Java.
Что еще интересного:
* вендоры периодически патчат уязвимости быстрее, чем это делают дистрибутивы. Это, практически, шах и мат для аргументов в стиле "завендоренные либы содержат уязвимости, кототорые никто не обновляет". Обновляют, просто умеют считать деньги, и не обновляют, когда impact нулевой.
* Пишут, что девендоринг Java, и, тем более, динамическая ее линковка, стоили несколько десятков человеко-лет компании. "To introduce properly working dynamically linked JDK to Fedora took several excellent engineers several years. Even after a decade, there are remaining unfixed issues. And new issues are appearing.", и "This is the holy grail we have been pursuing for last 10 years. But now we gave up. To keep java alive in Fedora, we have to take this one step back." Вообще, тут, конечно, динамическая линковка кажется каким-то совершенно cargo cult, а не чем-то полезным.
* С поддержкой Wayland все не очень понятно.
* Так же рассматривались 2 решения, которые не нашли поддержки - просто переупаковывать сборку от Oracle, или забить на Java в репозиториях at all, потому что для прода все равно ставят Oracle. Ну, понятно, такое не прокатило, а зря.
* Вендоры иногда так патчат забандленные библиотеки, что их невозможно смержить с upstream. Не вижу в этом проблем per se, пусть патчат. На то это и OSS, что можно не договариваться с упырями в upstream, и просто самому себе готовить нужный продукт.
🔥6👍1