Я тут себе собирал свое личное ядро для System/0 #system0. Это оказалось очень сложно, и заняло 4 бессонных ночи(+ целиком прошлое воскресенье).

Ну, то есть, собрать-то легко, а вот сделать так, чтобы оно заработало, очень сложно.

* Первое ядро ничего не писало на экран, и просто мигало капсом(это типа такой kernel panic). https://en.wikipedia.org/wiki/Kernel_panic#Linux. К счастью, от Gentoo я знал историю про то, что ядро себя так ведет с amdgpu, если не может загрузить firmware. Незачет номер раз - в такой ситуации нормальные люди откатывались бы на efi framebuffer, и показывали хотя бы сообщение об ошибке. Видимо, реализовать приоритет драйверов - это очень сложно.

* Загрузка firmware. Ядро напрочь отказалось загружать firmware с файловой системы, а до firmwared дело просто не доходило. Я так понимаю, некоторые штуки надо загружать или только из initrd,или прямо вкомпилять внутрь ядра. Я пока вкомпилял внутрь, причем вообще всю фирмварь для amdgpu, так как я уже писал, что нормального способа узнать, что загружено - не существует. - несколько часов.

* Для интелевых карточек в репе лежит примерно 20 разных фирмварей. Если дать ядру возможность выбора, то драйвер загружает НЕ ТУ фирмварь(оно при попытке поднять интерфейс срет в dmesg). То есть, фирмварь пришлось заблеклистить. На минуточку, драйвер от Intel, загружает фирмварь от Intel, подписанный Intel, для интеловой же карты, и ошибается. - несколько часов.

* Дальше началось самое интересное. Не работал мой тачпад в Sway. Последовательный bisect проблем показал, что ядро не видит тачпад, и не создает для него /dev/input/чегототам. Суммарно на решение этой проблемы ушло часов 20, за которые я успел по настоящему подебажить ядро. Я узнал, что такое шина i2c, hid, как они сопрягаются, и кучу прочего бесполезного барахла. А теперь придется и вам.

Итак, мое текущее понимание устройства ядра(это все довольно поверхностно, физически устроено еще сложнее *):

* Ядро - это такой большой std::map<void*, void*> M, как Spring :))
* Все подсистемы могут туда что-то положить, и зарегистрировать.
* Все подсистемы там могут что-то поискать, и что-то дернуть.

Какие отсюда интересные следствия?

* Если ты забыл что-то вкомпилять в ядро, то посреди цепочки регистрации что-то потеряется, и твое устройство не будет найдено.
* В модулях ядра стоят неполные зависимости. Что это значит? Это значит, что загрузятся не все нужные подсистемы, и мы возвращаемся в пункт 1.
* Зависимость от порядка регистрации. Если его не соблюсти, то в момент регистрации драйвера могут быть зареганы не все нужные подсистемы(пункт 2), и возвращаемся в пункт 1.

В моем конкретном случае я забыл** вкомпилять драйвер для gpio pins. Не спрашивайте что это такое, я к ядру подхожу с чисто практической точки зрения - "проходит или не проходит сигнал", а что там - мне глубоко пофиг.

Поэтому шина i2c видела мое устройство, но сигнал не доходил до HID драйвера, и устройство не могло зарегаться.

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

В конце-концов я нашел модуль про gpio pins, увидел, что его нет в зависимостях ни у i2c, ни у hid, и все стало понятно.

Кстати, собрать ядро со всеми драйверами built in невозможно(будет падать, или бесконечно висеть в probe девайсов), потому что это какое-то безумие - probe у некоторых драйверов работает лишь по факту их включения в ядро, что потенциально ломает систему, если нужного девайса нет. У меня это выражалось в том, что попытка загрузить какой-то левый драйвер для i2c контроллера ломало драйвер для настоящего i2c контроллера.

Почему нельзя вкомпилять в ядро на правах модуля(типа, звать probe только тогда, когда явно попросили init этого драйвера) - непонятно.

Короче, ядро у меня уже свое, но пока не до конца пригодно для всех.

вышел go 1.18

С дженериками.

https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md

Я пока не осилил прочесть этот текст, коллеги, там type erasure или мономорфизация?

Я, конечно, надеюсь, что первое, потому что и дальше можно будет ходить и говорить "дженерики в go - говно"(вместо "в go нет дженериков").

———
https://lwn.net/Articles/887746/

#linux #ci

Мне уже несколько поднадоело писать про то, как linux hackers относятся к тестам, но вот эту цитату Линуса я не могу пройти стороной:

"None of this was really surprising, but I naïvely thought I'd be able
to do the final release this weekend anyway.

And honestly, I considered it. I don't think we really have any pending issues that would hold up a release, but on the other hand we also really don't have any reason _not_ to give it another week with all the proper automated testing."

Я же все верно понимаю? Линус пишет, что, в принципе, конечно, можно и так, но он, мол, не придумал ни одной причины, чтобы не прогнать тесты. И как будто извиняется, что из-за дурацких тестов релиз откладывается еще на неделю.

Норм.

———
https://github.com/terraform-aws-modules/terraform-aws-eks/pull/1937#issuecomment-1068308469

Вчерашний мой PR закрыли. Дискуссия интересная, по очкам я победил, но хозяин - барин.

Я, конечно, продолжил дискуссию в новом тикете, но меня там послали, и тикет просто отменили, как это сейчас принято.

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

Сегодня ссылочный блог, звиняйте.

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

Firefox идет куда-то не туда. У меня такое ощущение, что, в погоне за последней копеечкой, они готовы вообще на все. Я так считаю - им надо или как-то дифференцироваться с хромом, и занять небольшую нишу, или уже сдаваться.

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

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

———
https://lkml.org/lkml/2022/3/17/964

Rust в Linux, v5. #linux_kernel_rust

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

Но сейчас Линус уже старый и сытый, и не хочет кусать руку, которая его кормит, поэтому послать в жопу то, что не осилил понять(речь про С++ и Rust, а я смею заверить, что критика тогдашним, молодым, Линусом, C++ - ну так себе) уже не выйдет.

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

Вот такой вот я злобный и злопамятный С++ программист.

#linux - это embedded. #scheduler

Что такое embedded? Это когда вам дают какой-то заранее собранный и преднастроенный программно-аппаратный комплекс, который выполняет какую-то функцию, и вы его используете, как черный ящик.

Я хочу аргументировать, что все известные и выстрелившие использования ядра Linux - это embedded.

КМК, единственное сомнение в этом утверждении может вызвать использование Linux в датацентрах. Но, если посмотреть на это под правильным углом, то линукс в датацентрах - это тоже глубокий embedded, потому что:

* ядро Linux на реальных железках настраивают и эксплуатируют специально обученные люди

* вендоры предоставляют образа для запуска Linux в своих облаках

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

Можно было бы привести в пример Android, как пример "открытой" системы, но и там:

* Прошивку вылизывает вендор

* Приложения сильно ограничены VM sandbox, которая делает много магии, чтобы они все вместе работали "плавно"

Поэтому "Linux на десктопе" - это оксюморон, он последние лет 10 точится совсем в другом напрявлении. Linux - давно не "OS общего назначения".

Правда, тут стоит отметить еще следующие факты:

* macOS - это что-то типа Android по своим свойствам, потому что Apple тюнит свою OS под ограниченный набор устройств, и очень сильно ограничивает приложения

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

Поэтому, по большому счету, у нас осталось всего полторы OS общего назначения, да и те сдают позиции.

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

Божечки-божечки-божечки, НАЧАЛОСЬ! #linux_kernel_rust

https://lwn.net/ml/rust-for-linux/CAHkG_ewRo5uPOue3ZMAAPAc+eP7MNNU5iVym-JVG1jN7HD+XMg@mail.gmail.com/
https://lwn.net/ml/rust-for-linux/CAKfU0DLS5icaFn0Mve6+y9Tn1vL+eLKqfquvXbX4oCpYH+VapQ@mail.gmail.com/

Какие-то школьники интересуются, когда можно будет использовать crates.io и cargo в разработке Linux. С патчами про Rust все было и так понятно, но надо же иметь хоть немного совести, и подождать, пока поддержка Rust попадет в mainline.

Парсера json им не хватает в ведре, да.

———
https://github.com/microsoft/mimalloc/issues/574

Нашел багу в свежем mimalloc. Как? Очень просто, пересобрал с ним мир, и увидел в логах красивое:

pg-> /mix/store/mAZUHwYPOIGAPJOH-bin
    -coreutils-9-0/bin/sort 
sort: memory exhausted

gnu sort начал так ругаться на пустом вводе.

Стандартов на эту функцию нет, кто формально виноват, непонятно, но есть мнение, что reallocarray(a, n, m) == realloc(a, n * m) для всех n, m, которые можно безопасно перемножить.

Код sort в этом месте тоже совершенно всратый, зачем там выделять память уже после того, как весь ввод обработан - непонятно.

———
https://github.com/WebPlatformForEmbedded/libwpe/commit/064bd78c534d18f9422ddbfe4ca762a42290531c

#igalia lia никак не уймется, и они запилили для WebKit еще один порт, для embedded. Он устроен хитро - есть loader, libwpe, который загружает конкретную имплементацию, которая уже и реализует настройку графического контекста для рендеринга. И есть конкретная референсная реализация для freedesktop проектов, wpe-fdo.

Сделано это всрато:

* loader зависит от libxkbcommon, то есть, наружу протекла абстракция ввода-вывода(от конкретной реализации)

* абстракция, насколько я понял, абстрагирует не только графику, но и звук. Через что они гоняют звук, я пока не понял, как бы не через wayland :D

На днях коллеги из Igalia решили, что, раз уж есть всего одна реализация плагина, то можно ее и не через dlopen открывать. Кстати, придумали элегантное(без шуток) решение - статический loader просто содержит в себе extern на символ из плагина, после чего с ним можно линковаться, как с обычной .so

https://github.com/WebPlatformForEmbedded/libwpe/blob/master/src/loader-static.c#L32

А теперь то же самое, в конкретном плагине:

https://github.com/Igalia/WPEBackend-fdo/blob/master/src/fdo.cpp#L33

Мне понадобился gdb, чтобы найти тут ошибку.

Очевидно, что этот статический loader никто никогда в реальной жизни даже не запускал. Я этим пидарасам так и написал - https://github.com/WebPlatformForEmbedded/libwpe/commit/064bd78c534d18f9422ddbfe4ca762a42290531c#r71375192

Вот моя реализация: https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/wpe/loader/loader.c

#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.

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, они ребята чоткие.

https://www.phoronix.com/scan.php?page=news_item&px=Rust-For-Linux-5.20-Possible

Big news!

Linus говорит, что, вполне вероятно, Rust в Linux будет уже в 5.20.

По #linux_rust_linux вы можете посмотреть, почему я эту новость считаю исключительно хорошей и лулзовой! :D

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

———
Вышла новая телега, 4.0.0.

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

Когда собирал, увидел, что телега написала нативную wayland интеграцию - из репозитория исчез враппер над kwayland - https://git.sr.ht/~pg/ix/commit/790b39736be2579587240f245a6d687f566d5de2#pkgs/bin/telegram/desktop/unwrap/t/ix.sh-1-5

Собственно, ровно оно у меня и сломалось.

Если отжать галку "use system decorations", теперь показывается старый темный window border от телеги. А если включить - то какое-то странное белое нечто, которое рисует явно не sway.

Старые декорации(темные) стали, к тому же, скругленными.

Blueeeh.

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

Facebook пишет swap под Linux, так, как он должен быть устроен. Ручки по настройке в ядре, сложная логика по управлению - в userspace.

Ну невозможно на C без граблей писать сложную логику.

На phoronix обсуждают какую-то презу, в которой объясняется, почему Linux не используют в mission critical системах.

https://www.phoronix.com/news/Linux-On-Airplanes-Challenges

КМК, приведенный выше слайд очень хорошо описывает культуру разработки ядра (а, точнее, ее полное отсутствие).

#linux #kernel

#linux #kernel #ci

https://www.phoronix.com/news/Linux-6.8-Sched-Regression

TL;DR - в процессе слияния ядра 6.8 Линус заметил, что, когда он собирает свежее ядро, будучи загруженным в это свежее ядро (#bootstrap), то у него это ядро собирается в 2 раза медленнее.

Тут, конечно, интересна не причина регрессии, а процесс.

Даже до Миши с фороникса начинает доходить, что что-то в консерватории не так, если такие валенки на пульте находит не автоматизированный CI, а лично Линус в процессе мержа:

"For regressing a workload like code compilation speeds being halved is rather surprising as while the Linux kernel lacks common and robust continuous integration (CI), it seems like kernel developers responsible for the changes would notice such a dramatic change... Especially if the code has been through linux-next and the like"

Все, буквально все (кроме старых линуксхакеров - https://t.iss.one/itpgchannel/264), уже понимают, что одна из самых важных программ в индустрии не может разрабатываться ТАК. Ну, то есть, может, но только в 10 раз медленнее, или дороже, чем могла бы.

Треш, угар, содомия.

Особенно смешно на этом фоне смотрится, как Линус материт Intel за то, что они не тестируют свой код перед мержем - https://www.phoronix.com/news/Torvalds-Unhappy-Linux-6.8-DRM