Друзья, после проведения нескольких стратсессий по медиастратегии нашей компании мы выработали долгосрочный план развития ключевого актива, телеграм-канала @coreinfra – будем просто закидывать сюда интересные нам самим штуки

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

IJON (Марио!), REDQUEEN, GRIMOIRE, Nyx, kAFL и не только: https://nyx-fuzz.com/papers/

– @pgregory

TechCrunch пишет, что Ян Лекун покидает Meta и будет строить свой стартап.

https://techcrunch.com/2025/11/11/metas-chief-ai-scientist-yann-lecun-reportedly-plans-to-leave-to-build-his-own-startup/

Будем с удовольствием следить!

Ян много рассказывает про то, что все неправильно (наш слоняра) учат модели. Путь джедая – обучение (и не только) через доменную модель. Т.е. не через обучение на всем, что попадет под руку, а через построение world model, которое бы предсказывало представление состояния от внешнего события, а не следующий токен или пиксел.

Начать среду предлагаю с видео, самого господина Яна: https://www.youtube.com/watch?v=MiqLoAZFRSE

Слайды в следующем сообщении для тех, у кого не сразу загрузился YouTube.

Ну и чтобы не оставлять такие крутые слайды без дополнительной отсылки – подкрепим Лекуна, другим ресерчем от Toby Ord посвященному вознаграждению за RL для фронтирных моделек:

https://www.tobyord.com/writing/inefficiency-of-reinforcement-learning

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

https://www.youtube.com/watch?v=8-boBsWcr5A

– @pgregory

Partial order aware concurrency sampling

Один из вопросов после моего доклада на митапе затрагивал тестирование, условно, многопоточного кода. Времени развернуто ответить не было – и канал тоже плохо подходит для длинного формата – но для тех, кому интересно это направление, скину статью про то, как это делать правильно. Год назад я бы скинул "A randomized scheduler with probabilistic guarantees of finding bugs" 2010 года, но теперь это будет "Partial order aware concurrency sampling" 2018 года.

Простой рандомизированный алгоритм, гарантирующий эффективное исследование огромного пространства состояний многопоточной программы – что может быть лучше?

– @pgregory

Создавать новые технические штуки довольно сложно. Даже с хорошей центральной идеей часто непонятно как итоговая система должна выглядеть, какие принципы конструирования нужно задать.
Брайан Кантрилл (DTrace, Oxide) делает классификацию таких новых систем со стороны Simple vs Complex и Engineered vs Emergent, рассуждает как системы приходят к тому или иному типу. Спикер классный, есть много хороших мыслей. Прям заряжаешься мотивацией идти и делать "revolutionary system"

https://www.youtube.com/watch?v=Cum5uN2634o

– @nik_myxo

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

– Быстрый, честный и детальный постмортем от имени CEO – единственный правильный вариант, за что респект
– Надеюсь, что те, кто любил смеяться над if err != nil { получили пищу для размышления (но особо в это не верю)
– Лже-корневая причина инцидента – нарушение принципа config is code (и вытекающих отсюда принципов раскатки конфигов)
– Настоящая корневая причина – отсутствие, как выражается один мой друг, облеченного властью технического "человека с дубиной", который держит всю систему в голове и говорит "нет" на любые плохие идеи. Ресурса CTO на это обычно не хватает; это должен быть отдельный человек с очень высокими полномочиями
– Все мы задним умом крепки

– @pgregory

Design, Implementation and Evaluation of the
seL4 Device Driver Framework

Хороший дизайн – это всегда одновременно и простота, и надежность, и скорость. Необходимость компромиссов почти всегда указывает на то, что хороший дизайн нам просто пока неизвестен. Но с течением времени люди начинают находить все больше хороших дизайнов, и статья выше – последний пример, который мне очень понравился. Простые, безопасные и быстрые (быстрее Linux) драйверы – реальная инновация в древней osdev сфере.

– @pgregory

ШОК! Чтобы писать программы БЕЗ БАГОВ, нужно ТОЛЬКО... https://youtu.be/fBdNeDHN8oc

Испытываю слабость к научным результатам с философским подтекстом (типа той же теоремы Геделя). Они встречаются нечасто – и тем приятнее иногда их находить. Сегодняшний экземпляр – "The Platonic Representation Hypothesis", Position Paper ICML 2024.

https://phillipi.github.io/prh/

– @pgregory

Поговорим про образование и развитие тренда «программируемый интерфейс инструментов». Он появился не вчера, но вместе с тем именно сейчас, я считаю, он получает настоящее развитие.

Первый из серии пост про «программируемый интерфейс инструментов» общего характера, следующие посты будут содержать больше примеров и меньше философствования.

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

Немного затизерю: чуть позже мы расскажем про наш подход программируемого фаззера, а сегодня пост — про программируемый трейсинг, а именно DTrace.

Я с очень большим уважением отношусь к почившему ныне Sun и DTrace это еще один пример высокой инженерной культуры компании и законченного технологического продукта. Поэтому начнем с него, а не с bpftrace для Linux, пусть это будет, как дань уважения инженерным командам и компаниям.

Если быть очень кратким в описании и упрощать, то профайлеры делятся на два типа: sample based и event based. Sample based снимают call-stack много раз в секунду, на основании чего делается вывод, какая функция занимает большую часть времени исполнения. Event based — как и следует из названия, всё идёт от события, и дальше измеряются различные интервалы от одного события до другого.

DTrace — это программируемый event-based profiler (в широком смысле слова профайлер, как замечают авторы: «performance analysis and troubleshooting tool»). Где в декларативном стиле описываются различные клозы событий и их обработчики. В момент, когда я познакомился с DTrace, я много программировал на Erlang, и такой подход показался очень лаконичным и понятным.

Если в двух словах описывать идею, то она очень простая: есть список событий называемых пробами, они расставлены в систему или любой софт и используются, как отсечки для обозначения вход в какой-то участок кода или выход из него. И дальше на специальном языке пользователь описывает нужный ему замер, агрегирует, снимает состояние программы, в общем то, что реально нужно ему для отладки. Что примечательно, что футпринт на систему прямопропорционален используемым пробам. Т.е. оверхед локализуется только для используемых в скрипте событий. Вместо того чтобы собирать кучу ненужных стеков и нагружать систему, достаточно подписаться ровно на те события, которые нужны для того, чтобы получить нужное измерение.

Сейчас мы зайдем на более гуманитарную территорию: когда вы пишете такую программу, вы точно понимаете, что измеряете, а когда используете «коробочный» инструмент, представление часто остаётся очень абстрактным. Этот вывод для меня подтверждается проводимыми собеседованиями: часто кандидат не может внятно сказать, что такое load average в выводе top/htop/uptime, и это вполне объяснимо.

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

Все становистя еще проще с AI-Coding агентами: теперь вы легко получаете короткую программу, внимательно ее отсматриваете и точно знаете, что происходит внутри инструмента, её исполняющего. Подход «программный код, как интерфейс» бьется с shift-left подходом, работой с репозиториями и всеми инструментами к которым привык разработчик.

PS:
если думаете чем заняться вечером (на протяжении пары недель), заглядывайте в блог одного из авторов DTrace Адама Левенталя, есть выступления с dtrace.conf, а также ссылки на его подкаст. https://ahl.dtrace.org/

- @tthread

Test post, please don't comment 😉

Включили комментарии в канале – жгите, друзья! Но жгите содержательно и интересно.

Добрый субботний вечер, уважаемые подписчики 😊

Сегодня практический пример, как использовать инструменты типа DTrace. Для более широкого адопшена информации среди подписчиков возьмем аналогичный инструмент в Linux, который называется bpftrace. bpftrace работает поверх eBPF и предоставляет DSL, похожий на DTrace, с помощью которого описываются замеры.

Как пример возьмем вопрос: а что делает процесс, когда он не исполняется? Такой вопрос часто возникает, когда по какой-то причине система не может обслуживать больше клиентов, но вычислительные ресурсы позволяют это сделать. В этот момент мы часто слышим: стоит в диск, стоит в сеть и прочее, но при этом вопрос, а во что конкретно стоим, может поставить нас в тупик. Поэтому это выглядит хорошим примером для того, чтобы показать, как сделать такой скрипт на bpftrace.

На первой картинке — короткий код скрипта, на второй — результат исполнения.

Начнем с первой.

Сначала нужно явно сформулировать, что мы хотим увидеть: время, проводимое процессом, когда он вытеснен планировщиком (здесь и далее речь про CPU-планировщик или task scheduler); состояние процесса, когда он был вытеснен; агрегат суммы замеров времени, проведенного в этом состоянии. Процесс вытесняется, когда на исполнение назначается другой процесс вместо текущего. Поэтому нас интересует одно событие: переключение планировщика задач, в ядре Linux это выражено как событие tracepoint::sched::sched_switch. Состояние характеризуется стек-трейсом исполнения.

Поэтому, сутево, нам нужно сделать следующее: ловить моменты постановки/снятия на исполнение, брать стек-трейс в момент снятия и считать время, прошедшее с момента снятия до момента постановки на исполнение. Далее агрегировать это и вывести на консоль.

Коротко про пробы (probe) — это специальные отсечки, расставленные в коде, которые указывают на то, что произошло какое-то событие. Пробы могут быть уровня ядра — kprobes, и уровня пользовательского приложения — uprobe. Регистрируя в скрипте эти пробы и их обработчики, можно задавать программу для обработки каждого события. У каждой пробы есть аргументы, доступные через args->, можно объявить переменные через @name и использовать различные builtin, которые, как в данном примере, используются для взятия текущего времени через nsecs и текущего стека вызова функций ядра через kstack.

В нашем случае мы регистрируем пробу tracepoint::sched::sched_switch, и в момент срабатывания мы вычисляем, когда наблюдаемый процесс вышел из исполнения CPU-шедулера и когда обратно был взят. Это описывается в коде в строках с 5 по 13.

if (args->prev_pid == 1234) {
    @start = nsecs;
    @kstack = kstack;
}

В строке 5 — проверка, что произошло переключение, где prev_pid == 1234, это значит, что pid 1234 был снят с исполнения. В строке 6 мы запоминаем в переменную @start таймстемп в наносекундах, а в строке 7 запоминаем текущее состояние стека вызовов функций ядра (то, на чем остановилось исполнение в момент вытеснения с шедулера; дальше оно меняться не будет, поскольку код не исполняется).

if (args->next_pid == 1234 && @start) {
    @offcpu[@kstack] = sum(nsecs - @start);
}

В строке 10 — проверка, является ли это событие событием постановки на исполнение pid 1234. И если это так, то рассчитан ли у нас для него @start, или это первое событие с момента начала наблюдений. В строке 11 мы запоминаем в структуру map переменной @offcpu для этого стектрейса обновленный агрегат суммы всех значений дополненный текущей разницей nsecs - @start (суммируем все замеры для текущего стек-трейса и добавляем новый).

Как результат, на второй картинке мы видим отсортированный по возрастанию список стек-трейсов с суммарным временем, в них проведенным. Интересующий нас процесс висит в epoll, что говорит нам о том, что он просто ждет новых соединений и с ним все в порядке =)

- @tthread

Про герметичность окружения и AI Coding.

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

И что интересно: то, что хорошо для AI-coding-агентов, оказывается удобным и для людей.

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

Недавно разговаривал с товарищем, и в голову пришёл такой пример: герметичность — это когда программист садится в поезд Москва–Петушки с ноутбуком, на котором установлено нужное окружение, склонена репа, есть необходимая документация, как по стандартной библиотеке, так и специфичная для домена, проверяющие референс-тесты, в общем всё, что ему нужно, кроме внешнего доступа. А на конечной станции у него получается готовый продукт — делать же в поезде больше нечего =)

Также стоит «снаряжать» и агентов, такое структурирование помогает иметь всё под рукой.

Частным случаем герметичности является монорепа — способ организации кода, который на нашей практике зачастую оказывался наиболее эффективным и практичным.

- @tthread