Как натянуть сову на глобус семантику Rust на C++:
https://docs.google.com/document/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub

Спойлер: увы.

RedHat планомерно сворачивает "бесплатный RedHat Linux", во всех его проявлениях. Интересно, ждет ли ее судьба ELK && MongoDB? https://www.opennet.ru/opennews/art.shtml?num=54219

Microsoft колбасит .NET:
https://www.opennet.ru/opennews/art.shtml?num=56027
https://www.opennet.ru/opennews/art.shtml?num=56020

Тут еще должна была быть ссылка с извинением-неизвинением кого-то из управляющего совета .NET перед сообществом, но я ее не нашел.

———
Я как-то обещал написать про то, как #eBPF && #io_uring поменяют Linux, но так и не написал. Давайте я совсем коротко обозначу свою мысль, а раскрою ее позже.

Благодаря тому, что syscall станут бесплатными(io_uring), и станет возможным безопасно выполнять пользовательский код в контексте ядра(eBPF), ядро станет мигрировать в область микроядра - сервисы в пространстве (kernel-user)space(кто сказал "Microsoft Singularity?!" - https://ru.wikipedia.org/wiki/Microsoft_Singularity), c реализацией ядерной функциональности.

Это не просто спекуляция - сеть уже едет вовсю в (kernel-user)space, а вот теперь и шедулер: https://lwn.net/ml/linux-kernel/[email protected]/ (патчи от нашего бывшего коллеги!) #sched

https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-server #ksmbd

Ахаха, я тут должен сказать "а я же говорил!" :)

"Clearly, those number are impressive, but at the same time recent improvements in Samba's IO performance put this into perspective: by leveraging the new “io_uring” Linux API Samba is able to provide roughly 10x the throughput compared to ksmbd."

И это они еще не начали переписывать сетевые кусочки на #eBPF.

———
https://www.techrepublic.com/article/83-of-it-leaders-believe-the-hybrid-workforce-is-here-to-stay/

Чтобы стать следующим Курцвейлом, нужно делать прогнозы! Вот, делаю. #future

Что будет:

Я считаю, что, конечно, фарш уже не прокрутить назад, и удаленная работа с нами останется. Сначала в каких-то извращенных формах, 2 - 3 дня в неделю в офисе(я же верно понимаю, что FAANG MANGA идет к этому?), остальное время из дома. Потом, по мере привыкания control freaks из менеджмента, все это будет двигаться в сторону полноценной удаленной работы:

* Без коэффициентов. Оплата по труду, а не по тому, откуда ты работаешь.
* Появление в офисе по мере рабочей необходимости, а не обязательные N дней. Тут важно понимать, что "N дней в офисе" - это никакой не компромисс, он не решает никаких задач(в перекрестное опыление на кофепоинте я уже не очень верю, год назад мне все еще казалось, что это работает, а потом я как-то приспособился перекрестно опыляться в TG). Вот, допустим, я хочу работать из домика в деревне, или переехать на окраину города, чтобы жить рядом с зеленым парком и вообще поднять уровень жизни? Как мне помогает "N дней в офисе"? Никак, потому что 5 - N дней приходится решать очень странную транспортную задачу. А зачем мне 5 - N дней вне офиса, если у меня квартира в мегаполисе? Чтобы сидеть в душной коробке(не дай Боже, с неработающей женой и детьми на карантине)?
* Возможно, произойдет разделение команд по признаку mostly remote/mostly office. Вот это, как раз, будет самый настоящий консенсус, а не никого не устраивающий компромисс.

Почему:

* 2 года короны показали, что удаленка - это не леденящий душу пиздец, а вполне понятное проседание на 10 - 20%, которое вполне может быть скомпенсировано меньшими затратами на офис, etc. Это знание теперь с нами навсегда.
* Из-за прагматической конкуренции. Компании из второго - третьего эшелона уже все предлагают удаленку, потому что ну надо же как-то конкурировать наймом с первым? Амазон уже что-то пробует(потому что умеет считать деньги) - https://www.seattletimes.com/business/amazon/amazon-will-allow-many-employees-to-work-remotely-indefinitely/ Остальные подтянутся, когда HR поймет, что это причина оттока/притока сотрудников в компанию. Рынок все расставит по своим местам.
* Самое простое и понятное объяснение - IT все еще рынок, где заправляет рабочая сила, так как Copilot все еще бажит. Если 50% сотрудников будут хотеть full remote(а уже известно, что это всего 10 - 20% проседания!), то рынок подстроится.

Последствия:

* Те компании, что побыстрее перестроятся, соберут сливки и прочую сметану с найма.
* Будем жить в деревне, и не тратить по 2 часа на дорогу. Те, кто хочет, конечно. А молодежь будет наслаждаться упавшими в цене хатами в центре города :D
* Дальнейшая глобализация рынка. У нас ЗП вырастут, у вас упадут(ну, точнее, вырастут не так, как могли бы) :D
* Компромисс "50% хотят 100% remote, поэтому 100% получат 50% remote" просуществует недолго.

https://blog.ffwll.ch/2018/08/no-2d-in-drm.html

Недавно плакался, что для ускорения десктопа используется дорогущее и жрущее батарейку 3D железо. Хотя хватило бы блиттера и смешения по альфа-каналу.

Вот, объяснение, можно сказать, от самих разработчиков dri. Пишут, что 2D сложнее, чем 3D. Интересно, что он этим имеет в виду? Конечно нет, не сложнее. Просто не стандартизировано, в отличие от. Стандартизировать ни у кого желания нет, потому что профит по сравнению с уже существуюшим 3D не то чтобы большой.

———
https://wingolog.org/archives/2021/12/13/webassembly-the-new-kubernetes

Писал про #ebpf + #io_uring, и, буквально, на днях, про #wasm. Короче, идея, что нужна более легкая виртуализация, витает в облаках.

———
https://www.supergoodcode.com/zink-4ever/

Важная для меня тема :) Я в Mix решил строить графический стек в виде #zink + vulkan, чтобы 2 раза не вставать(и чтобы без #LLVM в драйверах*). И оказывается, не прогадал. Уже писал, что zink по перфу догнал классический OpenGL, а теперь просто прекрасное - #zink - самый фичастый из OpenGL в Mesa. Короче, старый стек уже можно закапывать.

Чувак работает на Valve.

Все #хорошее в OSS делают корпорации, когда это не основной их продукт. Гугл продает рекламу, а не браузер, FB, знаете ли, не продает системы сборки, и так далее. А вот результат у mongo и elastic немного хуже. Вот и Valve продает не OpenGL, а игры.

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

*: кстати, в копилку про "не умеют договариваться" и #fontconfig - в нормальной жизни компилятор шейдеров был бы демоном. Тогда и кеш понятно, как устроить, без вычисления md5 от образа библиотеки, и как не запускать llvm в каждом приложении, и как падения ретраить(sic).

PS: тут про компилятор шейдеров я имел в виду штуку, которая SPIR-V в машинный формат переводит.

#ebpf #uring

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.20-User-Space-Block-Drv

Какую хорошую новость я пропустил. FB/RH тащат в ядро user space block device через io_uring.

"IO_uring User-Space Block Driver Coming For Linux 5.20"

https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler (#ebpf #uring #future)

#ebpf едет в шедулер, а, значит, я скоро смогу попробовать запустить в него свои шаловливые ручки #ananicy

"The belief is that with eBPF support for the Linux kernel scheduler it could ease experimentation and exploration of new scheduling policies, allow for application-specific schedulers and other customizable options via the loading of custom BPF programs, and provide a non-disruptive way for changing out scheduling policies within production environments"

Ну и, совсем не удивляет, что "Engineers from both Google and Meta (Facebook) are behind this initiative"

https://www.phoronix.com/news/sched_ext-Ahead-Of-Linux-6.12

Linus жмется, и не пускает #sched_ext в ядро.

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

Ну или, что более вероятно, не хочет оставлять пару заслуженных пенсионеров без гешефта по заносу нужных изменений в переусложненный основной шедулер Linux.

А я-то, было, уже собрал https://github.com/sched-ext/scx, и, потирая ручки, ждал, когда же уже

"The following video is the scx_rustland scheduler which makes most scheduling decisions in userspace Rust code showing better FPS in terraria while kernel is being compiled. This doesn't mean that scx_rustland is a better scheduler but does demonstrate how safe and easy it is to implement a scheduler which is generally usable and can outperform the default scheduler in certain scenarios"

На выходных, от скуки, решил почитать, как это все работает, потому что представления про #ebpf у меня были, в основном, теоретические.

Мама дорогая, сколько они там нахуевертили за 30 лет существования этой технологии, уму непостижимо.

Но, самое главное, они наотрез отказываются пускать через ebpf turing complete код, поэтому, конечно, в текущий момент интересный мне шедулер устроен крайне примитивно - в ядре выполняется только "простой" щедулер, который умеет в round robin внутри каких-то групп процессов, а решения по переносу процессов между группами (довольно медленно!) принимает userspace часть, которая уже и написана на rust (это было про другой шедулер) интересный мне шедулер устроен так - "This BPF backend implements the low level sched-ext functionalities for a user-space counterpart, that implements the actual scheduling policy. The BPF part collects total cputime and weight from the tasks that need to run, then it sends all details to the user-space scheduler that decides the best order of execution of the tasks (based on the collected metrics). The user-space scheduler then returns to the BPF component the list of tasks to be dispatched in the proper order" - не самое рекативное решение.

Понятное дело, что до полноценного сложного шедулера на ebpf пока еще очень далеко.

https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md

Кстати, полезный список ссылок на коммиты, в которых добалялись те или иные фичи #ebpf ядро.

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

Будни #bootstrap

Довольно много софта, которое хочет что-то собирать под #ebpf, путает target компилятор, и freestanding компилятор.

target компилятор - это компилятор, который собирает код под нужную нам платформу.

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

Вот почему-то почти весь код, который я собирал для bpf, ожидает, что он может взять target компилятор, передать ему -target bpf, и все будет хорошо.

А разгадка одна - безблагодатность.

А потом странные ошибки сборки и линковки, с которыми без поллитры не разберешься.

Наверное, потому что все уже привыкли, что host/target - это две разных платформы, и системы сборки как-то (чаще плохо) это поддерживают, а вот третье измерение - это уже перебор.

Хотя, как ни странно, gnu build system изначально имела три платформы, build/host/target, но они значат не совсем то, что нужно для bpf.

Я это называю host/target/for_target, и, мне кажется, это лучше отражает суть происходящего, но протащить это в сборочные скрипты того или иного проекта - это жесть, приходится wrap кучу тулчейнов, чтобы они из контекста понимали, для чего сейчас вызвана компиляция.

Это настолько subtle, что я не смог найти хороший пример для bpf, чтобы из кода было понятно, что тут происходит, но вот вам пример для cargo - https://github.com/pg83/ix/blob/main/pkgs/die/rust/cargo.sh#L57-L95

Я настолько задолбался разбираться, где там и что зовется под host и под target (скорее всего, потому что господа в моноклях сами это не понимают), что пробую компилять/линковать в разных режимах, пока не соберется.

Работает превосходно!

#llvmweekly #rant

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696

TL;DR - хочется уметь красиво выводить в отладчике не встроенные типы, для этого предлагается завести секцию, в котороую писать bytecode, который умеет выводить на эран те или иные типы в программе.

Почему не положить туда готовые python форматтеры, которые уже есть, и написаны?

"The logical next step would be to store full Python formatters instead of summary strings, but Python code is larger and more importantly it is potentially dangerous to just load an execute untrusted Python code in LLDB.

To address these problems, I’m proposing a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers"

Объяснение не стоит и выеденного яйца, потому что ТЫ УЖЕ ЗАПУСТИЛ этот бинарь, запусти и Python, в песочнице.

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/10

Или возьми готовый VM, в который llvm уже умеет (hint - #WebAssembly, #bpf, #ebpf https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/12).

Но нет, это было бы слишком просто, на таком фиолетовое не получить.

Вообще, удивительно, в маленький #harfbuzz тащат большой #WebAssembly (https://t.iss.one/itpgchannel/1201), а в большой LLDB (который уже умеет в #WebAssembly) тащат самопальный байткод...

Где логика-то?

3 года назад я (в первый раз) написал, что #ebpf и #io_uring радикально поменяют Linux, и периодически писал на эту тему.

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

Совершенно прекрасная новость в тему - IETF хочет стандартизировать #ebpf, например, чтобы оффлоадить его выполнение, ну и чтобы сторонные реализации появились.

#ebpf уже сделал большинство ядреных файерволов ненужными, а #io_uring делает userspace реализации быстрыми.

И вторая интересная новость в тему - https://www.phoronix.com/news/DRM-Graphics-Drivers-IO_uring

Кажется, io_uring как способ доставки команд до 3D драйвера - это прямо конфетка.

https://lwn.net/SubscriberLink/1002371/0ff2be6a2c7624ca/

"Process creation in io_uring"

Пишут про добавление clone() в #io_uring.

Я, даже не читая текст, закатил глаза, и подумал "#ebpf", потому что это очень разумно - загрузить через io_uring программу, которая сделает необходимый setup, и позовет clone()

(вообще, напомню в данном контексте свой текст от 21 года - https://t.iss.one/itpgchannel/56)

И, пожалуйста, первый же комментарий про это - https://lwn.net/Articles/1003051/

Но, в целом, этот текст (и дикуссия по ссылкам) не дает ответа на самый главный вопрос - а какая семантика у асинхронного clone()?

Тут же основная проблема - а что происходит, если clone() реально происходит хз когда, когда программа имеет неизвестное состояние блокировок/открытых fd/memory maps и так далее?

Синхронно-то сложно обеспечить нормальное окружение для clone(), а асинхронно - это какой-то леденящий душу пиздец!

#sched_ext

История из серии "очумелые ручки".

В какой-то момент экспериментов с scx, я решил, что надо запускать userspace часть с каким-нибудь RT приоритетом, потому что решения про шедулинг - это важно, и нужно уметь получать их за предсказуемое время, да же?

Вот, сделал запуск через chrt -f 1 - https://github.com/pg83/ix/blob/main/pkgs/bin/scx/rust/land/runit/ix.sh#L5

И получил моментальный freeze всей системы, такие дела.

Так же попробовал bpfland, вместо rustland - по словам авторов, это то же самое, что и rustland, но полностью в ядре, в виде #ebpf программы https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_bpfland/README.md.

Работает оно довольно стабильно, но, к сожалению, отзывчивость GUI оно только ухудшает, артефакты заметны невооруженным взглядом.

Мне интересно, в каких условиях вообще возможно воспроизвести предполагаемый результат?

https://mostlynerdless.de/blog/2024/09/10/hello-ebpf-writing-a-linux-scheduler-in-java-with-ebpf-15/

Я в растерянности, потому что, с одной стороны, это годный текст про еще один userspace scheduler, на основе #sched_ext/#ebpf, а с другой - явный (pun intended) кандидат в серию "новости из дурки", потому что писать userspace scheduler на Java - это, конечно, за гранью.

https://blog.janestreet.com/a-higgs-bugson-in-the-linux-kernel/

История одного #debug, без излишних соплей, люблю такие.

Чувак для воспроизведения бага:

* запилил fuse файловую систему для быстрой генерации контента
* заиспользовал #eBPF, чтобы вывести stacktrace ядра при возникновении ошибки
* написал плагин для wireshark
* взял NFQUEUE, "userspace process for packet filtering", TIL

И все это, буквально, на двух страничках текста.