If you're curious about getting started with Nix/NixOS, and happen to be located in Moscow, join us this Saturday (the 18th) for a NixOS install party at @undefspace!

(Experienced Nix-users are also welcome, it can't hurt to have more people on hand to answer questions and guide beginners!)

More info in Russian: https://progmsk.timepad.ru/event/2358560/

More info in English: https://discourse.nixos.org/t/2023-03-18-nix-os-install-party-in-moscow/26334

До начала Сигнала в этом году осталось совсем немного времени. Кто из моих дорогих подписчиков пойдет?

Я вот подготовил Плейлист на Яндекс Музыке с музыкой всех артистов, которые в этом году на официальном лайнапе Сигнала.

https://music.yandex.ru/users/v.ambo/playlists/1141

Головокружительная экскурсия по современной российской электронной музыке)

Вчера вечером написал некоторые патчи для моего emacs-конфига. Их на самом деле давно уже хотел написать, они решают маленькие проблемы которые мне постоянно мешали. Об одной из проблем я хочу рассказать, потому что она привела к тому, что "порог раздражения" был переступлен.

Emacs у меня основная часть своей рабочей среды. Он у меня является, конечно, текстовым редактором, но и еще менеджером окон, мэйл-клиентом, чат-клиентом и много другого.

Внутри emacs есть концепция "буферов", один буфер может быть один открытый файл в текстовом редакторе, один чат на Телеграме, или одно десктопное окно (например, браузер). Навигация между ними осуществляется с помощью команды `switch-to-buffer` (или кое-каких альтернатив, например `ivy-switch-buffer`, `helm-switch-buffer` и так далее). Буфер - на стороне emacs-lisp является объектом с некоторыми полями. Одно из них: `buffer-name`.

У всех buffer-switch команд есть одинаковая проблема: Они берут список буферов из emacs, показывают *имена* буферов пользователю, и в результате получают выбранное *имя*. Затем они просят emacs открыть буфер с этим именем.

Кто-то наверно уже понял какая тут проблема. Имени буферов могут меняться, и да, не только могут, но и делают! Например, Телеграм-клиент может показать каличество непрочитанных сообщений в названии, окно с Яндекс Музыкой меняет названия по треку, и так далее. Получается довольно часто такая ситуация, что название меняется при выборе буфера, и `switch-to-buffer` больше не найдет выбранный буфер и просто открывает новый, пустой буфер с старым названием! Когда разработывали эти команды в emacs (да, это совершенно давно, где-то в 70х/80х, большинства нас пока не было тогда!), они никогда не сталкивались с такими ситуациями, и это решение, которое тогда хорошо работало теперь больше просто не адекватно.

Фикс был не очень сложным. Вместо списка имен буферов создаю alist с названием и *с самим объектом*, и после выбора буфера с списка передаю именно этот объект, а не только его название, в функтцию, которая открывает буфер.

Коммит с этой новой функцией здесь: https://cl.tvl.fyi/c/depot/+/9147
Советую её особенно всем пользователям EXWM!

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

Выньте камни из своих ботинок!

Всем привет! В четверг (07.09.2023) я выступлю с докладом "tvix-eval - компилятор и рантайм для Nix, на Rust", на Московском Rust-митапе. Начнем где-то в 19.00, рядом с ВДНХ. После докладов пойдем, конечно, в паб.

Зарегистрируйтесь, это бесплатно, просто хотим понимать, сколько нас будет.

https://progmsk.timepad.ru/event/2560621/

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

В Go нет нормальной системы типов для 21-го века (все на уровне C с 80-x). Однако людям нужны современные фичи типа sum types (которые в протобуфе можно реализовать через oneof), и поэтому они просто заменяют неадекватную систему типов протобуферами.

Вот и все. Food for thought, как говорится.

Years ago on the site formerly known as Twitter, I wrote: "tazjin's law - every infrastructure process not supervised by a reconciliation loop will eventually fail"

This, folks, is still true! Too little software is designed for how fragile everything actually is. Threading a chain of push-based events through a bunch of Rube-Goldberg machines will not work consistently. Stop doing it!

Когда уже не знаешь, что ещё о санкциях сказать.

Теория: Поведение большинства "умных" фич неотличимо от стохастического.

Хочешь написать умную фичу? Тебе не нужно ничего кроме std::rand!

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

Всех с новым годом! Пусть у вас получиться в этом году больше кода удалить, чем написать!

Greetings from the Thaigersprint in Thailand! We published an update on the current status of Tvix this morning: https://tvl.fyi/blog/tvix-update-february-24

Sprint is still going on for another few days, hopefully we'll have even more to show in a week))

Are you interested in Nix? Do you have a week of free time at the end of August? Great!

At the last week-long Nix hackathon (Thaiger Sprint, in Thailand) I decided to organise the next of these events in Kazan, on August 22-29: The Volga Sprint!

We'll get together in and work on various Nix-related projects (which ones is up to you!) for a week, with the occasional extracurricular activity.

Sounds interesting? Read more & sign up at https://volgasprint.org/

My 50 kopecks on the Nix drama:

Ignore it, it's irrelevant. The only thing that matters in the Nix world is nixpkgs, and nixpkgs governance and development is sufficiently stable. Yes, C++ Nix and Tvix, and all other related projects don't actually matter much overall.

Ignore this drama, ignore flakes, just use Nix and contribute whatever is interesting to you to nixpkgs. Don't pay attention to people trying to cause outrage with (badly edited) open letters, don't pay attention to power-hungry twats who think they can "own" Nix by hiring its creator, don't spend your energy getting angry about whether some company that supports US imperialism pays for t-shirts and coffee at some conference.

Ten years down the line only the technical results will matter, and nobody will really remember all these people.

Oh, and come to Volga Sprint! We still have two spots available :)

Так-то, год какой-то закончился. С Новым годом!

Кажется, уже с конца ВолгаСпринта здесь ничего не было. Марк, кстати, о спринте статью написал. Прочитайте, может быть, появится желание в этом году присоединиться к нам)

У меня столько тем, что я не могу выбрать, о чем написать, и в итоге просто не пишу. Надо что-то делать! (Хотя, все мы знаем, как это бывает с новогодними обещаниями...)

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

* Во первых - немного шок-контента для тех, кто меня хорошо знает) Я перестал использовать EXWM, да и даже перестал использовать X11 вообще, из-за отличного нового менеджера окон: niri. Основная идея niri заключается в том, что все окна находятся на бесконечном горизонтальном пространстве, который можно прокручивать влево и вправо. Автор niri живёт в Москве, и недавно выступал на RustCon с докладом об этом. Советую посмотреть, даже если сам менеджер окон тебе не особо интересен.

* Я в Яндексе некоторое время занимался включением libc++ hardening для тестов всех плюсовых проектов в компании. Google недавно делали то же самое (и еще больше - они у себя даже в проде включили!), что меня тоже мотивировал двигаться в сторону мира без с уменьшенным количеством segfault'ов. Это не единственный такой проект у нас сейчас, возможно, даже в этом году где-нибудь об этом с докладом выступлю.

* В мире Tvix'а - время перемен. У нас долго уже держатся два совершенно разных проекта в одном месте: Первый - переписать Nix на Rust (но лучше), и второй - заменить концептуальную модель Nix store. Первый проект тот, который мне больше интересен, и второй в прошлом году даже отделился частично от TVL. Я решил эти проекты явно разделить: Те компоненты, которые связаные со вторым проектом, будут полностью уезжать из TVL на другую инфраструктуру. Подробности об этом в b/431.

Для основного проекта это значит, что нам надо переделать store. Я хочу сделать реализацию, которая работает в принципе так же, как в C++ Nix (т.е. с простыми файлами на диске), но мы, конечно, обе модели поддерживаем, ради наших интерфейсов.

* amjoseph опубликовал, наконец-то, sixos. Это первый прототип альтернативного дистрибутива на основе Nix'а, но с интересными отличиями. Он использует инит-систему s6, которая по разным причинам очень хорошо подходит Nix'у концептуально. А еще более интересно - он унифицировал модель пакетов и сервисов. Я думаю, что этот проект (или что-то похожее) - будущее дистрибутивов на основе Nix'a. Проект сейчас, конечно, очень сырой, но уже очевидно, каким потенциалом он обладает. Обязательно посмотрите доклад (на английском).

Пока что это, вроде, самое интересное. Ну так, наконец-то хоть что-то написал) Наслаждайтесь оставшейся частью каникул!

Последние несколько месяцев у меня иногда возникала проблема с suspend/resume. Выглядела она примерно так: Если я закрыл ноутбук во время, когда зарядник к нему был подключен, то после resume'а иногда все полностью замерло. Единственное решение - force reboot.

Я думал все это время, что я что-то сконфигурировал не так с новым сетапом на wayland, но это случилось недостаточно часто, чтобы была мотивация додебажить это до конца. После нового года проблема стреляла уже три раза, и сейчас как раз (благодаря Путину))) есть время для дебага.

Сразу покажу решение, вдруг кому-нибудь нужно: Помогло отключение новой "фичи" в systemd, в которой при каждом suspend'е активировался так называемый "user slice freeze", который поставит все процессы пользователя на паузу. Эта (мис-)фича появилась в systemd 256, и в NixOS в конце июля.

На этом пост мог бы закончиться, но мне на самом деле было интересно, что это за фича, и кому она нужна? Для первой попытки получения ответа я попробовал читать changelog для systemd 256. В нем написано следующее:

The behavior of systemd-sleep and systemd-homed has been updated to freeze user sessions when entering the various sleep modes or when locking a homed-managed home area. This is known to cause issues with the proprietary NVIDIA drivers. [...]

Несмотря на то, что проблема возникает не только с драйверами NVIDIA (но, например, тоже при использовании NFS/KVM) этот текст никак не обясняет почему так сделано.

Посмотрим дальше на PR, в котором это добавили. Там в описании написано:

As discussed w/ @poettering

Окей, спасибо огромное. Смотрим дальше на коммиты этого PR:

sleep: Always freeze user.slice
Previously, we'd only freeze user.slice in the case of s2h, because we
didn't want the user session to resume while systemd was transitioning
from suspend to hibernate.

This commit extends this freezing behavior to all sleep modes.

Окей, но почему? Смотрим дальше:

homework: Lock/Unlock: Freeze/Thaw user session
Whenever a home directory is in a locked state, accessing the files of
the home directory is extremely likely to cause the thread to hang. This
will put the session in a strange state, where some threads are hanging
due to file access and others are not hanging because they are not
trying to access any of the user's files.

[...]

The solution is to suspend execution of the whole user session by
freezing the user's slice.

Да ладно. Получается, что эта забагенная фича была добавлена для решения проблем с systemd-homed, который сам по себе является нишевым (возможно, даже экспериментальным!) компонентом systemd.

Этот случай хорошо иллюстрирует текущие проблемы с systemd: Да, оно в свое время действительно было шагом вперёд (декларативное описание сервисов, вместо шелл-скриптов? Sign me up!), но оно развивалось в какой-то кроненбергский монстр, в котором из-за запутанной архитектуры отладка, мягко говоря, уже не просто.

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

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

Подробности можно прочитать в посте на Хабре. Я тоже кинул это на lobste.rs для лайков обсуждения.

В Гугле кстати есть похожая система (GWP).

Реализация Перфоратора крутая: ребята используют программу на eBPF, чтобы собрать данные из ядра с высокой частотой. Данные можно потом экспортировать в разные форматы (например, классические флеймграфы, или даже профили для PGO).

В этом году я опять случайно согласился выступить несколько раз, о разных темах. Первое такое выступление будет уже через месяц - на C++ Russia в Москве!

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

Можно ли с этим что-то делать? Ответ - частично да! Что именно и как мы это делаем я вам расскажу на конфе в своем докладе "Ржавеющие плюсы: как внедрять современные проверки С++ в промышленных масштабах".

(если билета еще нет, но подумаешь купить, напиши мне сначала 😇)

Много лет назад, когда я еще был совсем молодым, я начал свой путь в мир серьезного (относительно!) программирования через игру World of Warcraft.

Так сложилось, потому что мне тогда было больше интересно смотреть на то, как эта замечательная игра работает, чем играть в неё. Занимался "пиратскими" серверами и всеми связанными вещами, да, где-то у меня даже лежит футболка с логотипом Noggit'а, и с подписью нескольких из лидов разработки WoW. Этот опыт стал одним из важнейших в моей жизни, и у меня до сих пор есть друзья с тех времён. Представьте только: куча подростков пишут многопоточный C++, и разрешают чужим людям подключиться через интернет! Что могло пойти не так... в общем, скучаю)

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

Ну так, десятилетия спустя мне теперь хочется на самом деле играть в эту игру. Хочется именно та версия, которая была тогда: классический WoW без всяких расширений. Оказывается, что все это время люди дальше поддерживали, разрабатывали, починили софт для пиратских серверов - и он теперь реально хорошо работает!

Поэтому решил запустить себе именно такой, и даже сделал его публичным. Если вам скучно, присоединяйтесь: https://warcraft.tvl.fyi
Увидимся там!)

(PS: на сервере есть русский и английский перевод)

В последнее время меня немного заинтересовала та сторона: Guix! С тех пор когда я начал пользоваться Nix'ом уже знал про него, и, конечно, на Lisp уже давно пишу. Почему бы не исследовать его подробно?

Значит я решил поставить Guix System (это их аналог NixOS) на одном ноуте, чтобы посмотреть, как там у них вообще дела.

У меня до этого было что-то похожее на ментальную модель - "Guix - это Nix с Lisp'ом". На самом деле это не так. Да, guix-daemon - это просто nix-daemon который форкнули давно, но буквально всё остальное отличается. Они строили параллельную экосистему на Scheme.

Первый день когда попробовал я написал блогпост (на английском) о сравнении с Nix'ом, может быть, кому-нибудь из вас это будет интересно: https://tazj.in/blog/trying-guix

Вообще-то, что-то в нём есть. Продолжаю пробовать, хотя я пока не справился даже свой относительно простой сетап для десктопа полностью дублировать на Guix. Скорее всего, нужно будет ещё постов написать)

PS: У Guix'а, в отличие от Nix, нету нормальных кэшей с CDN. У них CI занимаются два сервера в Европе: Один из них полностью перегружен и отвечает только 500'ками, другой работает, но медленно. Я поэтому запустил российское (и по идее не только) зеркало для Guix: https://mirror.yandex.ru/mirrors/guix/

#видеозаписи #плюсочетверг

Открываем новую видеозапись выступления:
Винсент Амбо — Ржавеющие плюсы: как внедрять современные проверки С++ в промышленных масштабах

YouTube | VK Видео

Скачать презентацию с сайта C++ Russia

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

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

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

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