Мне, действительно, нужно выбрать более подходящее название для дистрибутива, чем mix.
Выберите из списка то, что, на ваш взгляд, наиболее полно отражает концепцию "statically linked Linux/Unix, устроенный максимально прозрачным образом".
Выберите из списка то, что, на ваш взгляд, наиболее полно отражает концепцию "statically linked Linux/Unix, устроенный максимально прозрачным образом".
Anonymous Poll
16%
lunix (motto - "Linux made right")
11%
leanix (lean and mean)
36%
stalix (statically linked linux)
47%
statix (same)
15%
helix (why not?)
#mesa, у меня бомбит
Я как-то говорил, что mesa довольно неплохо написана.
Хочу дезавуировать это утверждение.
Она написана поверхностно хорошо, но, благодаря процессам разработки, это примерно такой же всратый кусок говна, как и ядро #linux.
Тестов нет, коммитят без доработки тестов. Джигит-style разработка - пришет отважный джигит, наговнякал кучку, проблемы пусть решает следующий отважный джигит.
Слабоумие и отвага!
У меня последний рабочий релиз mesa был 22.0.1, при переходе на 22.0.2 наблюдались артефакты в epiphany.
Я, наконец-то, нашел время побисектить это говно, начитался и кода, и коммитов.
Полюбуйтесь, причина поломки - https://gitlab.freedesktop.org/mesa/mesa/-/commit/bbd7f4ff9761b5a2bb5bfb4e56effe204457c3d1
Чувак разделил файл с настройками на два. При этом:
* Новый файл никто не читает. Как, Карл!?
* Поломан код от google, добавленный в 21 году, про вкомпиливание этого конфига в бинарь. Тесты, блядь, где на это? https://github.com/mesa3d/mesa/blob/main/src/util/xmlconfig.c#L39
* Самое интересное, отделенные данные, по идее, никак не должны влиять на связку zink + radv, нет там про это записей. Я предполагаю, что, из-за того, что убрали секцию про radv, там не сработал код по установке дефолтных значений, но это неточно. Второе предположение - что zink наследует настройки d3dvk, или что-то в этом роде.
Я объединил эти два файла взад, в 1 большой - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mesa/t/merge.py
Причем не регулярками, а нормально попарсил xml! Кто молодец?
Вообще, насмотрелся в их трекере разного.
Например, tar.xz от релиза 22.0.4 появился раньше, чем был отведен релизный бранч под него. Как?!?
Стабильные бранчи бывают тупо сломаны посредине, что доставляет при бисекте.
Школота.
БОльшая часть полезного опенсорса затащена грубой, очень грубой, силой, только потому, что в каждый момент времени выгоднее потратить 10 * delta x, чем переписать нормально, и сделать за delta x.
Я как-то говорил, что mesa довольно неплохо написана.
Хочу дезавуировать это утверждение.
Она написана поверхностно хорошо, но, благодаря процессам разработки, это примерно такой же всратый кусок говна, как и ядро #linux.
Тестов нет, коммитят без доработки тестов. Джигит-style разработка - пришет отважный джигит, наговнякал кучку, проблемы пусть решает следующий отважный джигит.
Слабоумие и отвага!
У меня последний рабочий релиз mesa был 22.0.1, при переходе на 22.0.2 наблюдались артефакты в epiphany.
Я, наконец-то, нашел время побисектить это говно, начитался и кода, и коммитов.
Полюбуйтесь, причина поломки - https://gitlab.freedesktop.org/mesa/mesa/-/commit/bbd7f4ff9761b5a2bb5bfb4e56effe204457c3d1
Чувак разделил файл с настройками на два. При этом:
* Новый файл никто не читает. Как, Карл!?
* Поломан код от google, добавленный в 21 году, про вкомпиливание этого конфига в бинарь. Тесты, блядь, где на это? https://github.com/mesa3d/mesa/blob/main/src/util/xmlconfig.c#L39
* Самое интересное, отделенные данные, по идее, никак не должны влиять на связку zink + radv, нет там про это записей. Я предполагаю, что, из-за того, что убрали секцию про radv, там не сработал код по установке дефолтных значений, но это неточно. Второе предположение - что zink наследует настройки d3dvk, или что-то в этом роде.
Я объединил эти два файла взад, в 1 большой - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mesa/t/merge.py
Причем не регулярками, а нормально попарсил xml! Кто молодец?
Вообще, насмотрелся в их трекере разного.
Например, tar.xz от релиза 22.0.4 появился раньше, чем был отведен релизный бранч под него. Как?!?
Стабильные бранчи бывают тупо сломаны посредине, что доставляет при бисекте.
Школота.
БОльшая часть полезного опенсорса затащена грубой, очень грубой, силой, только потому, что в каждый момент времени выгоднее потратить 10 * delta x, чем переписать нормально, и сделать за delta x.
😢9🔥2👍1🤯1🤮1
It is settled. #stalix #ix #mix
#stalix - новое название дистрибутива
#ix - новое название пакетного менеджера
Теперь OS и пакетный менеджер называются по разному, во избежание неоднозначности.
Actually, КМК, stalix объективно самое лучшее название.
Посудите сами:
* STAtically LInked LInuX - какое-то дикое пересечение акронима и того, что сокращаем.
* Звучит очень "чисто", "звонко" и "сочно".
Если бы не коннотация со Сталиным, у меня не было бы никаких сомнений, и я бы даже не стал устраивать опрос.
Меня удивило и ободрило, что так много людей посчитало, что stalix - норм.
Так же я поспрашивал импортных друзей, на предмет того, будет ли это восприниматься как отсылка к дедушке Джо.
Получил два вполне подходящих мне мнения:
* Всем похуй.
* А тем, кому не похуй - они сделают хорошую рекламу на reddit. Все, что не некролог, как известно, хорошо.
"IX" - пересечение "stalIX" и "unIX", хочу, чтобы название подчеркивало цель быть пакетным менеджером не только для OS stalix, а вообще, для unix-like OS.
Ну и, конечно же, интересная история, которая со мной случилась в момент перименования.
Я сначала сделал ln -s /mix /ix, потом сделал полный ребилд всего и вся по новым путям.
А потом я сделал "./ix gc", и вот тут-то случилась жопа.
gc - это была одна из команд, которую я не перенес в граф, и она выполнялась бинарем пакетного менеджера, в котором я не переименовал mix в ix.
Поэтому он посчитал, что корней для gc нет, и снес все пакеты в /mix/trash/
А я напомню, что у меня раз в 100 секунд запускается процесс, который очищает корзину, это такая оптимизация, чтобы делать это async.
Кажется, я секунд за 10 успел:
* в открытом MC найти в trash бинарник busybox
* c помощью этого бинарника вернуть все пакеты в /ix/store/
* тут мне очень помогло, что у меня предусмотрительно на пятом tty запущена рутовая консоль без логина, для подобных аварийных случаев. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mingetty/runit/ix.sh#L9
Это был первый раз с нового года(а я под новый годе переехал на mix полностью), когда я был близок к потере установленной системы.
Но все обошлось, пути я поменял!
#stalix - новое название дистрибутива
#ix - новое название пакетного менеджера
Теперь OS и пакетный менеджер называются по разному, во избежание неоднозначности.
Actually, КМК, stalix объективно самое лучшее название.
Посудите сами:
* STAtically LInked LInuX - какое-то дикое пересечение акронима и того, что сокращаем.
* Звучит очень "чисто", "звонко" и "сочно".
Если бы не коннотация со Сталиным, у меня не было бы никаких сомнений, и я бы даже не стал устраивать опрос.
Меня удивило и ободрило, что так много людей посчитало, что stalix - норм.
Так же я поспрашивал импортных друзей, на предмет того, будет ли это восприниматься как отсылка к дедушке Джо.
Получил два вполне подходящих мне мнения:
* Всем похуй.
* А тем, кому не похуй - они сделают хорошую рекламу на reddit. Все, что не некролог, как известно, хорошо.
"IX" - пересечение "stalIX" и "unIX", хочу, чтобы название подчеркивало цель быть пакетным менеджером не только для OS stalix, а вообще, для unix-like OS.
Ну и, конечно же, интересная история, которая со мной случилась в момент перименования.
Я сначала сделал ln -s /mix /ix, потом сделал полный ребилд всего и вся по новым путям.
А потом я сделал "./ix gc", и вот тут-то случилась жопа.
gc - это была одна из команд, которую я не перенес в граф, и она выполнялась бинарем пакетного менеджера, в котором я не переименовал mix в ix.
Поэтому он посчитал, что корней для gc нет, и снес все пакеты в /mix/trash/
А я напомню, что у меня раз в 100 секунд запускается процесс, который очищает корзину, это такая оптимизация, чтобы делать это async.
Кажется, я секунд за 10 успел:
* в открытом MC найти в trash бинарник busybox
* c помощью этого бинарника вернуть все пакеты в /ix/store/
* тут мне очень помогло, что у меня предусмотрительно на пятом tty запущена рутовая консоль без логина, для подобных аварийных случаев. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mingetty/runit/ix.sh#L9
Это был первый раз с нового года(а я под новый годе переехал на mix полностью), когда я был близок к потере установленной системы.
Но все обошлось, пути я поменял!
🔥18😁1
https://groups.io/g/simh/topic/new_license/91108560
https://github.com/simh/simh/issues/1059
https://www.reddit.com/r/linux/comments/uua97p/unix_emulator_project_maintainer_removes_foss/
https://www.reddit.com/r/emulation/comments/ut0uvn/maintainer_of_open_source_emulation_software_simh/
Читал последние несколько дней, наконец, дочитал, пишу.
Совершенно феерический тред про взаимодействие автора simh4, форка simh3 - симулятора разных древних аппаратных архитектур, типа PDP-11.
Автор симулятора запилил довольно controversal фичу - начал дописывать к raw images с образами OS свою метаинформацию в конец файла.
Спорная вещь, учитывая, что raw image это не его приватный формат, который он может менять, как ему угодно.
Короче, запилил, к нему посыпались возмущенные пользователи с "какого хера твоя программа попортила мои образа".
Откатывать это он отказался, люди начали форкать его поделие. Автора simh4 это возмутило до глубины души, и он поменял лицензию на свой код в этом проекте. Что, начиная с ревизии X, ты не имеешь право менять такой-то файл, функцию такую-то. А если поменял, то не имеешь права пользоваться кодом автора, начиная с ревизии X.
По ссылкам - мега-срач по этому поводу. Там все хороши.
И поехавший автор, и community, которое вообще не понимает, что такое лицензии, и собирает петиции, чтобы отобрать на гитхабе владение организацией simh у этого чувака.
ЖЫР, цирк с конями, и вообще, красивое.
https://github.com/simh/simh/issues/1059
https://www.reddit.com/r/linux/comments/uua97p/unix_emulator_project_maintainer_removes_foss/
https://www.reddit.com/r/emulation/comments/ut0uvn/maintainer_of_open_source_emulation_software_simh/
Читал последние несколько дней, наконец, дочитал, пишу.
Совершенно феерический тред про взаимодействие автора simh4, форка simh3 - симулятора разных древних аппаратных архитектур, типа PDP-11.
Автор симулятора запилил довольно controversal фичу - начал дописывать к raw images с образами OS свою метаинформацию в конец файла.
Спорная вещь, учитывая, что raw image это не его приватный формат, который он может менять, как ему угодно.
Короче, запилил, к нему посыпались возмущенные пользователи с "какого хера твоя программа попортила мои образа".
Откатывать это он отказался, люди начали форкать его поделие. Автора simh4 это возмутило до глубины души, и он поменял лицензию на свой код в этом проекте. Что, начиная с ревизии X, ты не имеешь право менять такой-то файл, функцию такую-то. А если поменял, то не имеешь права пользоваться кодом автора, начиная с ревизии X.
По ссылкам - мега-срач по этому поводу. Там все хороши.
И поехавший автор, и community, которое вообще не понимает, что такое лицензии, и собирает петиции, чтобы отобрать на гитхабе владение организацией simh у этого чувака.
ЖЫР, цирк с конями, и вообще, красивое.
GitHub
simh changes .dsk image files by silently adding signature · Issue #1059 · simh/simh
Context This is a new feature but it is a very BAD one: when a disk image it attached to a device in simh, the simulator appends some kind of a signature to the disk image. WHY is this necessary? I...
😁7🤩2
Совершенно феерические рекламы 80-годов про продажу компьютеров.
Да, я сексист, мне нравится, идите в жопу.
https://rarehistoricalphotos.com/vintage-computer-ads/
(КДПВ следующим постом, телега почему-то не дала объединить)
Да, я сексист, мне нравится, идите в жопу.
https://rarehistoricalphotos.com/vintage-computer-ads/
(КДПВ следующим постом, телега почему-то не дала объединить)
Rare Historical Photos
Vintage Computer Ads that Show How Far We've Progressed, 1970-1990 - Rare Historical Photos
In this article, we’ve collected some retro computer ads to give you a hands-on look into what made the tech headlines before the age of smartphones.
🔥4👎1
#allocator #tcmalloc #mimalloc
Давеча писал про свой дефолтный аллокатор, и про то, что это, во многом, эмоциональное решение.
Короче, я привел свои эмоции в соответствие реальности, и перешел на tcmalloc по дефолту.
* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/c/alloc/ix.sh#L5 - по сути, это изменение 1 строчки кода, после чего весь репозиторий будет линковаться с tcmalloc, если не указано обратное
* конечно, реальное изменение было несколько больше, потому что, я напомню, цепочка #bootstrap у меня теперь строится автоматически, и теперь tcmalloc может использоваться раньше в этой цепочке, когда мой инструментарий был недостаточен, чтобы собрать его полную версию. Самое простое - не готов perl, для запуска GNU autohell скриптов. Поэтому я взял более свежую версию gperftools, где есть поддержка cmake. Сборка cmake там пока молодая, немного кривая, за ней приходится подрихтовывать сборочные артефакты руками - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/tcmalloc/cmake/ix.sh#L52
(кстати, пользуясь случаем - полайкайте, чтоли, https://github.com/google/tcmalloc/issues/126 - прошу G-word company, чтобы они поддержали сборку каноничного tcmalloc без Bazel)
* Число пересборок библиотек стало меньше. Потому что раньше я принудительно собирал некоторые гуевые приложения с tcmalloc, а остальные - с mimalloc, а сейчас все получается с tcmalloc. Поэтому всякие mesa + gtk + qt раньше собирались по 2 раза, а теперь 1.
* у tcmalloc очень большой footprint - размер на диске 600Kb. 400Kb сам tcmalloc + 200Kb c++ runtime. Это довольно дофига, сильно вырос объем дискового пространства, занимаемого базовыми утилитами OS.
Я, наконец-то, нашел время это все подрихтовать, теперь базовые утилиты собираются с другим набором флагов - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/set/system/0/ix.sh#L4 :
* curses=netbsd говорит нам, что не нужно использовать ncurses для этих утилит. На минус куча лишних terminfo в базовом образе.
* intl_ver=no говорит нам, что не надо использовать gnu gettext для интернационализации, не нужно это в утилитах, которые не видит пользователь. Вообще, предполагается, что каждый пользователь сам, в своем #realm, решает, какие утилиты использовать
* purec=musl/unwrap говорит нам, что мы используем libc musl без переопределения аллокатора. Встроенный в musl аллокатор как раз хорош для такого рода использования.
Ну и, раз я уж этим занялся, то я аккуратно:
* почикал из системных пакетов неиспользуемые тулзы. Например, https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/dbus/sys/ix.sh#L5 - Действительно, зачем в системном пакете что-то, отличное от dbus-daemon? Клиента, если надо, пользователь поставит в свой #realm.
* Редко запускаемые, one-shot программы пожал с помощью upx. busybox не пожал, нефиг разжимать при каждом запуске cp/rm/mv/etc. Демоны тоже жать не стал, им нужен backing store за замапленной программой в памяти. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/iwd/sys/ix.sh#L12 Кстати, fun fact - upx почти не имеет смысла с динамической линковкой, но хорошо помогает в случае статической. В копилку примеров решений, которые по разному работают в разных мирах.
После всех этих действий объем базового #realm упал с 40 мегабайт до 17 - https://pastebin.com/raw/6b9Xtg5n (причем 7Mb из них - сжатая в 1 файл питонячка бинаря ix - graph executor моего пакетного менеджера, который надо переписать на С++/Rust).
Напомню, что мой базовый #realm позволяет поднять OS с настроенной сетью и серверной частью seat/input/sound/etc.
Давеча писал про свой дефолтный аллокатор, и про то, что это, во многом, эмоциональное решение.
Короче, я привел свои эмоции в соответствие реальности, и перешел на tcmalloc по дефолту.
* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/c/alloc/ix.sh#L5 - по сути, это изменение 1 строчки кода, после чего весь репозиторий будет линковаться с tcmalloc, если не указано обратное
* конечно, реальное изменение было несколько больше, потому что, я напомню, цепочка #bootstrap у меня теперь строится автоматически, и теперь tcmalloc может использоваться раньше в этой цепочке, когда мой инструментарий был недостаточен, чтобы собрать его полную версию. Самое простое - не готов perl, для запуска GNU autohell скриптов. Поэтому я взял более свежую версию gperftools, где есть поддержка cmake. Сборка cmake там пока молодая, немного кривая, за ней приходится подрихтовывать сборочные артефакты руками - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/tcmalloc/cmake/ix.sh#L52
(кстати, пользуясь случаем - полайкайте, чтоли, https://github.com/google/tcmalloc/issues/126 - прошу G-word company, чтобы они поддержали сборку каноничного tcmalloc без Bazel)
* Число пересборок библиотек стало меньше. Потому что раньше я принудительно собирал некоторые гуевые приложения с tcmalloc, а остальные - с mimalloc, а сейчас все получается с tcmalloc. Поэтому всякие mesa + gtk + qt раньше собирались по 2 раза, а теперь 1.
* у tcmalloc очень большой footprint - размер на диске 600Kb. 400Kb сам tcmalloc + 200Kb c++ runtime. Это довольно дофига, сильно вырос объем дискового пространства, занимаемого базовыми утилитами OS.
Я, наконец-то, нашел время это все подрихтовать, теперь базовые утилиты собираются с другим набором флагов - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/set/system/0/ix.sh#L4 :
* curses=netbsd говорит нам, что не нужно использовать ncurses для этих утилит. На минус куча лишних terminfo в базовом образе.
* intl_ver=no говорит нам, что не надо использовать gnu gettext для интернационализации, не нужно это в утилитах, которые не видит пользователь. Вообще, предполагается, что каждый пользователь сам, в своем #realm, решает, какие утилиты использовать
* purec=musl/unwrap говорит нам, что мы используем libc musl без переопределения аллокатора. Встроенный в musl аллокатор как раз хорош для такого рода использования.
Ну и, раз я уж этим занялся, то я аккуратно:
* почикал из системных пакетов неиспользуемые тулзы. Например, https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/dbus/sys/ix.sh#L5 - Действительно, зачем в системном пакете что-то, отличное от dbus-daemon? Клиента, если надо, пользователь поставит в свой #realm.
* Редко запускаемые, one-shot программы пожал с помощью upx. busybox не пожал, нефиг разжимать при каждом запуске cp/rm/mv/etc. Демоны тоже жать не стал, им нужен backing store за замапленной программой в памяти. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/iwd/sys/ix.sh#L12 Кстати, fun fact - upx почти не имеет смысла с динамической линковкой, но хорошо помогает в случае статической. В копилку примеров решений, которые по разному работают в разных мирах.
После всех этих действий объем базового #realm упал с 40 мегабайт до 17 - https://pastebin.com/raw/6b9Xtg5n (причем 7Mb из них - сжатая в 1 файл питонячка бинаря ix - graph executor моего пакетного менеджера, который надо переписать на С++/Rust).
Напомню, что мой базовый #realm позволяет поднять OS с настроенной сетью и серверной частью seat/input/sound/etc.
GitHub
support another build system · Issue #126 · google/tcmalloc
Please, please support anything but bazel. bazel is very uncommon, huge, and depends on java. Having java in build toolchain is not always possible. (this is off-topic, but I can not really underst...
👍8🤯2❤1
https://keunwoo.com/notes/rebooting/ #reboot
Хороший, только очень длинный текст, в котором написаны 2 простых мысли:
* В любой системе нарастает энтропия. По другому - в системе есть https://ru.wikipedia.org/wiki/Гейзенбаг.
* Перезагрузка(VM, хоста, программы) - это простой способ вернуть систему из состояния с накопившейся ошибкой в состояние без такой ошибки.
Люди, которые меня знают поближе, знают, что я люблю давать пару странных архитектурных советов:
* Периодически рестартовать свои программы на кластере. Обычно достаточно обновления версий, если оно регулярное.
* Несколько более странный совет - вставлять в свою программу abort() в случайные места. В проде, именно в проде.
Попробуйте пофантазировать, почему это хорошо и правильно, и от каких проблем защитит вас.
———
https://hpdevone.com/
Какой-то странный forced mem от HP и ноутбук на PopOS. Написали про это поделие на 5 форумах, которые читал сегодня.
Расскажу вам такую историю.
Я очень странно отношусь к своей технике. Например, экран и клавиатуру ноутбука я могу не протирать по несколько месяцев, потому что зачем? И потому что лень.
Однажды я ехал на переднем сиденье такси, с ноутбуком. Водитель половину поездки пялился на мой ноут, потом достал из бардачка спиртовую салфетку, протянул мне, и сказал: "Протирай!". Больше за всю поездку мы не перемолвились ни словом.
К чему я клоню?
Я, с полгода назад, рассказывал, какой охуенный ноут я купил - #Xiaomi, Ryzen, OLED, 4K. https://aliexpress.ru/item/1005002697829975.html?sku_id=12000027107974063&spm=a2g0o.search.0.0.4f227153dK0TN4
Стоит дешевле, чем собрат от HP, начинка лучше, и просто божественный OLED экран!
Он настолько крутой, что я завел себе привычку вытирать его 3 раза в неделю спиртовой салфеткой! Никогда в жизни такого не делал, а тут делаю.
Это не реклама, ноут реально офигенный. Stal/IX я разрабатываю на нем, его 8/16 ядер не простаивают ни секунды.
Хороший, только очень длинный текст, в котором написаны 2 простых мысли:
* В любой системе нарастает энтропия. По другому - в системе есть https://ru.wikipedia.org/wiki/Гейзенбаг.
* Перезагрузка(VM, хоста, программы) - это простой способ вернуть систему из состояния с накопившейся ошибкой в состояние без такой ошибки.
Люди, которые меня знают поближе, знают, что я люблю давать пару странных архитектурных советов:
* Периодически рестартовать свои программы на кластере. Обычно достаточно обновления версий, если оно регулярное.
* Несколько более странный совет - вставлять в свою программу abort() в случайные места. В проде, именно в проде.
Попробуйте пофантазировать, почему это хорошо и правильно, и от каких проблем защитит вас.
———
https://hpdevone.com/
Какой-то странный forced mem от HP и ноутбук на PopOS. Написали про это поделие на 5 форумах, которые читал сегодня.
Расскажу вам такую историю.
Я очень странно отношусь к своей технике. Например, экран и клавиатуру ноутбука я могу не протирать по несколько месяцев, потому что зачем? И потому что лень.
Однажды я ехал на переднем сиденье такси, с ноутбуком. Водитель половину поездки пялился на мой ноут, потом достал из бардачка спиртовую салфетку, протянул мне, и сказал: "Протирай!". Больше за всю поездку мы не перемолвились ни словом.
К чему я клоню?
Я, с полгода назад, рассказывал, какой охуенный ноут я купил - #Xiaomi, Ryzen, OLED, 4K. https://aliexpress.ru/item/1005002697829975.html?sku_id=12000027107974063&spm=a2g0o.search.0.0.4f227153dK0TN4
Стоит дешевле, чем собрат от HP, начинка лучше, и просто божественный OLED экран!
Он настолько крутой, что я завел себе привычку вытирать его 3 раза в неделю спиртовой салфеткой! Никогда в жизни такого не делал, а тут делаю.
Это не реклама, ноут реально офигенный. Stal/IX я разрабатываю на нем, его 8/16 ядер не простаивают ни секунды.
👍6🔥5😁3❤1
#alsa #gold
Победил проблему со звуком. Как? Что было?
Было 3 одновременных неприятных бага, которые устроены так, что, пока не заборешь все 3, звука не будет, и даже не будет понятно, есть у тебя прогресс, или нет.
* Как я уже рассказывал, система у меня определяла 2(на самом деле 3, но это неважно) аудиокарточки - hdmi выход в видеокарте, и встройку. alsa выбрала в качестве карты по умолчанию hdmi выход, поэтому звук, даже если и шел куда-то, то, явно, не туда.
* libalsa silently fail, если в системе нет группы audio. Конечно, нам в протокол общения с ядром обязательно надо указать эту информацию, даже если пользователю не нужен доступ к этой группе(у меня пользователи напрямую не ходят в alsa, а ходят в мультиплексор sndiod). Повторю - наличие пользователя в этой группе не нужно, важно наличие этой группы на машине. PZDS.
* В alsa все выходы по умолчанию mute. Это не было бы проблемой, если бы я знал/помнил, как это выглядит в "графическом" alsamixer. Выглядит оно... незаметно, скажем так. То, что каналы замучены, я нашел в полном большом выхлопе какой-то отладочной тулзы.
Наверное, стоит упомянуть, что, прежде чем чинить alsa, я попробовал вывести звук через alsa oss emulation, но у меня, с ходу, не получилось, потому что oss сейчас, конечно, уже так себе поддерживается в клиентах. Например, я нигде не смогу указать, что нужна именно вторая карта(к этому моменту я уже понимал, что звуковые карты перепутаны).
Все заработало? Нет!
Но сначала история из прошлого.
Я думаю, многие помнят, что в Я была попытка "завести" офис в Калифорнии. В этот момент времени в компании работало довольно много импортных разработчиков, на встречи с которыми я регулярно попадал.
Нужно сказать, что Я, к тому моменту, была компанией очень молодой, работала там вчерашняя школота и студентота, а новые разработчики были опытные и повидавшие всякое.
Помню замечательный момент, когда на одной из таких встреч наш молодой и задорный руководитель транспортного цеха начал рассказывать, какой и куда код нужно распихать по разным системам робота и поиска Яндекса, и употребил замечательное слово "протаскивание".
В этот момент один из импортных разработчиков, видимо, доведенный до отчаяния окружающей школотой, начал орать на нас отборным английским матом, выделяя два основных поинта:
* there is no such thing as "protaskivanie"! #protaskivanie
и
* what the hell code are your writing?
Короче, система должна быть устроена так, что не нужно заниматься протаскиванием данных ни в какую сторону.
Представляйте данные на верних уровнях в том же формате, как они используются на нижних, и не занимайтесь ручным преобразованием этих форматов.
К чему это я?
Авторы #sndiod решили позаниматься "protaskivanie" - они погрузили формат описания звукового устройства в какой-то свой формат, и мне понадобилось еще полчаса чтения кода, чтобы понять, что нужно запускать не "sndiod -f 1", а "sndiod -f rsnd/1". Что такое этот rsnd, и зачем он там нужен, я не понял.
С другой стороны, я пытаюсь делать так, чтобы "protaskivanie" не было нужно, поэтому я сделал так, что номер карты можно указать параметром ко всему #realm, и он попадет прямо в самый скрипт настройки sndiod:
Этот флажочек сам пробулькивается до конечного скрипта:
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sndio/runit/scripts/ix.sh#L8
После этого все заработало, звук появился сразу и везде, кроме epiphany, потому что там аццкий gstreamer, с которым я еще вообще не разбирался.
Победил проблему со звуком. Как? Что было?
Было 3 одновременных неприятных бага, которые устроены так, что, пока не заборешь все 3, звука не будет, и даже не будет понятно, есть у тебя прогресс, или нет.
* Как я уже рассказывал, система у меня определяла 2(на самом деле 3, но это неважно) аудиокарточки - hdmi выход в видеокарте, и встройку. alsa выбрала в качестве карты по умолчанию hdmi выход, поэтому звук, даже если и шел куда-то, то, явно, не туда.
* libalsa silently fail, если в системе нет группы audio. Конечно, нам в протокол общения с ядром обязательно надо указать эту информацию, даже если пользователю не нужен доступ к этой группе(у меня пользователи напрямую не ходят в alsa, а ходят в мультиплексор sndiod). Повторю - наличие пользователя в этой группе не нужно, важно наличие этой группы на машине. PZDS.
* В alsa все выходы по умолчанию mute. Это не было бы проблемой, если бы я знал/помнил, как это выглядит в "графическом" alsamixer. Выглядит оно... незаметно, скажем так. То, что каналы замучены, я нашел в полном большом выхлопе какой-то отладочной тулзы.
Наверное, стоит упомянуть, что, прежде чем чинить alsa, я попробовал вывести звук через alsa oss emulation, но у меня, с ходу, не получилось, потому что oss сейчас, конечно, уже так себе поддерживается в клиентах. Например, я нигде не смогу указать, что нужна именно вторая карта(к этому моменту я уже понимал, что звуковые карты перепутаны).
Все заработало? Нет!
Но сначала история из прошлого.
Я думаю, многие помнят, что в Я была попытка "завести" офис в Калифорнии. В этот момент времени в компании работало довольно много импортных разработчиков, на встречи с которыми я регулярно попадал.
Нужно сказать, что Я, к тому моменту, была компанией очень молодой, работала там вчерашняя школота и студентота, а новые разработчики были опытные и повидавшие всякое.
Помню замечательный момент, когда на одной из таких встреч наш молодой и задорный руководитель транспортного цеха начал рассказывать, какой и куда код нужно распихать по разным системам робота и поиска Яндекса, и употребил замечательное слово "протаскивание".
В этот момент один из импортных разработчиков, видимо, доведенный до отчаяния окружающей школотой, начал орать на нас отборным английским матом, выделяя два основных поинта:
* there is no such thing as "protaskivanie"! #protaskivanie
и
* what the hell code are your writing?
Короче, система должна быть устроена так, что не нужно заниматься протаскиванием данных ни в какую сторону.
Представляйте данные на верних уровнях в том же формате, как они используются на нижних, и не занимайтесь ручным преобразованием этих форматов.
К чему это я?
Авторы #sndiod решили позаниматься "protaskivanie" - они погрузили формат описания звукового устройства в какой-то свой формат, и мне понадобилось еще полчаса чтения кода, чтобы понять, что нужно запускать не "sndiod -f 1", а "sndiod -f rsnd/1". Что такое этот rsnd, и зачем он там нужен, я не понял.
С другой стороны, я пытаюсь делать так, чтобы "protaskivanie" не было нужно, поэтому я сделал так, что номер карты можно указать параметром ко всему #realm, и он попадет прямо в самый скрипт настройки sndiod:
pg-> ./ix list system
{'flags': {'alsa_device': '1', 'failsafe': '1'},
'name': 'set/system/0'}
Этот флажочек сам пробулькивается до конечного скрипта:
https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sndio/runit/scripts/ix.sh#L8
После этого все заработало, звук появился сразу и везде, кроме epiphany, потому что там аццкий gstreamer, с которым я еще вообще не разбирался.
🔥10😁4👍1
commit -m "better"
веселых картинок в ленту!
Долго думал, откуда целых три блевотных смайлика на прошлое сообщение.
И я все понял!
Все верно, "./configure; make; make install" без указания —prefix превращает любую систему в slackware, виноват, обещаю исправиться.
И я все понял!
Все верно, "./configure; make; make install" без указания —prefix превращает любую систему в slackware, виноват, обещаю исправиться.
😁19👍5
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🔥2👏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 юниты.
👍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