Создавать новые технические штуки довольно сложно. Даже с хорошей центральной идеей часто непонятно как итоговая система должна выглядеть, какие принципы конструирования нужно задать.
Брайан Кантрилл (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

Мы находимся сейчас в интересном моменте времени – с одной стороны, представление о том, что LLM-ки должны фундаментально изменить программирование постепенно становится общим консенсусом; с другой стороны, никто не знает, как именно будет выглядеть это "новое программирование", и тем более как туда прийти.

Приходится самостоятельно, методом проб и ошибок, находить какие-то очертания этого нового мира. И сегодня хочу поделиться одним из них: регенерируемость исходного кода.

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

Сразу возникает много вопросов: что должно быть исходным кодом для исходного кода, как именно нужно его организовывать и по каким правилам с ним работать? Как решать вопрос возникающей инверсии зависимостей – где спецификация следующей версии исходного кода может начать зависеть от текущей версии исходного кода? Насколько all in нужно идти в идею агентов и регенерации, и насколько ее можно совместить с тем, как мы привыкли работать с кодом сейчас?

Есть идеи, как правильно отвечать на эти вопросы – но делать это без серьезного подтверждения моих гипотез будет преждевременно. Поэтому пока просто скажу, что очень рад тому, что AI заставляет больше и глубже думать о программировании :-)

Всех с наступившим Новым Годом и Рождеством!

– @pgregory

Drawbridge – наш первый open source релиз

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

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

Drawbridge – это минималистичный HTTPS реверс-прокси, обеспечивающий безопасный доступ ко внутренним сервисам без VPN. Drawbridge гарантирует транспортную безопасность (TLS), аутентификацию пользователей (WebAuthn) и авторизацию доступа к каждому сервису (user whitelist).

Главное отличие Drawbridge от всех остальных проектов с похожими целями – фокус на безопасности. Минимальный набор фич, минимальная конфигурация – и главное, минимальный объем кода (1 файл в ~1200 строк на текущий момент) с минимумом зависимостей. Цель такого минимализма – возможность полного аудита проекта перед внедрением и отсутствие необходимости обновлять версии (и доверять новому коду и его авторам).

Статус – на текущий момент, альфа, релиз для энтузиастов. Учитывая минимализм, думаю что стабильный релиз не за горами.

https://github.com/CoreInfraAI/drawbridge

– @pgregory

Привет! Нас в этом канале уже чуть больше 100 человек.

Самое время представиться и рассказать, кто мы такие, тем, кто оказался здесь помимо наших друзей и знакомых =)

Мы — глубоко техническая R&D и инженерная команда. В прошлом, приходилось решать сложные задачи и делать масштабные запуски ВКонтакте, в Яндексе и Транзасе, на различных ролях — как в разработке, так и в менеджменте.

С 2024 года мы строим свою продуктовую и технологическую компанию в Санкт-Петербурге.

Наш главный фокус — синтез программ и механизмы верификации. Программирование будет меняться, нужен большой скачок вперед, который позволит создавать более качественные и корректные системы меньшими ресурсами, не быть заложниками legacy и быстро менять большие системы. Мы строим Продукт, который объединяет AI и верификацию и предлагает новый способ создания программ.

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

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

Авторы этого канала, они же основатели компании:
— мой друг и коллега Григорий Петросян, CTO CoreInfra
— я, Илья Щербак, CEO CoreInfra.

Илья и Гриша.

Недавно ребята из Anthropic выложили свое старое тестовое задание – «оптимизировать вычислительное ядро под специализированную архитектуру, имея на руках симулятор». Интересный проект сразу с нескольких точек зрения.

Во-первых, это просто классное тестовое задание. Инфровое, к тому же.

Во-вторых, это хороший пример герметичной системы и четко специфицированной цели с измеряемой метрикой – «минимизировать количество аппаратных циклов». Baseline: 147734 цикла.

И, наконец, это демонстрация реальных возможностей агентов сегодня. Квалифицированный программист, потратив время и погрузившись в задачу – 2262 цикла, плюс понимание куда можно копать дальше. Запущенный им агент, за вечер – 1333 цикла. Лучший на сегодня результат, полученный в публичном соревновании – 1001 цикл.

– @pgregory