Чот ржу

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

Только не могу понять, там наши побеждают, или не наши?

Как в Microsoft ловят data race в ядре(hint - c помощью профайлера бедного человека): https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Erickson.pdf #debug

И, собственно, как сделать профайлер бедного человека своими руками: https://programmer.group/x86_-principle-and-example-of-single-step-debugging-for-64-platform.html

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

Сегодня у нас в гостях Michael Forney(https://mforney.org/, не футболист!).

Человеку настолько надоел binary bloat, что он, в одну харю, запилил:

1) Статически слинкованный Oasis Linux. https://github.com/oasislinux/oasis К сожалению, тут мне с ним не по пути, потому что С++ он тоже считает bloat. https://git.sr.ht/~mcf/oasis

2) Переписал выполнитель графов Ninja на C. https://github.com/michaelforney/samurai Используется много где, я в своем дистрибутиве тоже использую как замену Ninja.

3) Переписал coreutils. Coreutils написаны на С, но на особом диалекте от GNU(это такой диалект, где все нужно делать в 10 раз длиннее по коду, чем нужно). Тут я его горячо поддерживаю, сам использую sbase в процессе бутстрапа свего дистрибутива. https://github.com/michaelforney/sbase

4) Вишенка на торте - пилит ажно 2 компилятора C.
* https://github.com/michaelforney/cproc - на базе https://c9x.me/compile/ - это такой очень lightweight аналог LLVM. Кстати, очень многообещающая вещь, когда оно сможет компилировать musl, я еего встрою в свой процесс бутстрапа. https://git.sr.ht/~mcf/cproc Список того, что в его дистрибутиве уже собирается с cproc - https://github.com/oasislinux/oasis/issues/13 (на самом деле, очень впечатляющий список!). Хочет собрать ядро Linux eventually, пожелаем ему успехов.
* Зачем-то учавствует в разработке scc - это еще один многообещающий компилятор С, товарищи пишут его с какой-то дикой скоростью, но заставить его работать у меня пока не вышло. https://git.simple-cc.org/scc/log.html

Какой мой интерес во всем этом? Я ищу простой компилятор для stage0 бутстрапа, чтобы в binary seed класть не 200мб clang, а 2 - 3мб cproc.

TinyCC, хоть и работает(у меня даже получилось собрать с его помощью патченый musl), внутри выглядит хуже, чем GCC. Но это как раз понятно, учитывая, как он начинался(Фабрис Беллард выиграл с его помощью контест на самый обфусцированный компилятор C https://bellard.org/tcc/)

https://twitter.com/alyssarzg/status/1443349503113846785

Еще раз повторю, Apple делает волшебное железо.

Для меня прямо очень удивительно видеть, что у clang больше красных квадратиков, чем у gcc. https://en.cppreference.com/w/cpp/compiler_support

Новый тектонический сдвиг?

Прекрасное от того же автора, что и текст про статическую линковку: #gavin

https://news.ycombinator.com/item?id=28737554
https://yzena.com/yzena-copyleft-license/ (пункт 16)

#copilot

Товарищ заодно еще и автор новой лицензии на OSS, основная фишка которой - запрет на использование исходных текстов под этой лицензией для обучения Copilot. Запасаемся попкорном, наблюдаем за тем, как подобного рода лицензии будут появляться на github. Подумываю тоже присоединиться к инициативе. Не то чтобы я зажал свои исходники для обучения несчастной машины, но интересно же, как GitHub(Microsoft) будет справляться с таким движением.

FSF тоже интересуется, не тырит ли ее бесценный GPL код Copilot: https://www.fsf.org/blogs/licensing/fsf-funded-call-for-white-papers-on-philosophical-and-legal-questions-around-copilot

https://lwn.net/Articles/871195/

Вообще, жить близко к транку - это хорошая идея. Но не в случае ядра.

Любое свежеизготовленное ядро - это, извините, кусок говна. Вы видели процессы разработки ядра линукс? Вы знаете, как оно тестируется?

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

Мое текущее понимание модели разработки ядра - что за FS отвечает мейнтейнер этой FS, который принимает в нее патчи, и мержит их в mainline. У кажого мейнтейнера свои подходы к тестированию, и они далеки от идеальных. Кто отвечает за то, что изменения в mmu не поломают какое-то изменение в FS, я не понимаю. Это явно не мейнтейнер MMU, и явно не мейнтейнер FS. По моему, Linus, то есть, никто.

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

Поэтому что там собирается ловить Гугл, для "a near-mainline kernel for development and testing", я не очень понимаю. Ну, то есть, я совершенно понимаю задачу "сократить число патчей с 9000 до 2000", совершенно понятный ход "выкладывать смерженные ядра на 1000 хостов по мере готовности, а не раз в 2 года". Но вот как они будут отделять баги своих патчей от багов свежеиспеченного ядра - вопрос открытый. Хотя это, в любом случае, улучшит качество свежеиспеченных версий ядра, что хорошо для индустрии. По крайней мере, тестов Гугл на ядро наваяет.

https://blog.cloudflare.com/branch-predictor/

Хороший пост про branch predictor.

Long story short(с заметными упрощениями!):

// branch
if (x) {
    // not taken
} else {
    // taken
}

Branch Predictor = HashMap<Instruction Pointer, N="10011100">, где N - паттерн taken/not taken для последних прыжков по этому IP.

Размер этой таблицы - несколько тысяч элементов(зависит от архитектуры, и от того, что предсказываем(jmp/call))

Можно считать, что not taken branch не стоит почти ничего(кроме паталогических случаев, когда все плотненько забито jmp).

Если не играть с likely/unlikely, код лучше оформлять так(это напрямую не следует из статьи, так говорит опыт):

if (x) {
    // hot code

    if (y) {
        // hot code
    } else {
        // cold code
    }
} else {
    // cold code
}

Паттерн

if (error) {
    return error;
}

// hot code

не самый лучший, потому что бранч будет чаще taken.

Важно смотреть ассемблер, чтобы понимать, что компилятор правильно понял про ветки if, taken они, или нет.

В компиляторах есть атрибуты hot, cold, ими можно размечать код.

Одной строкой:

* до чего довел планету этот фигляр ПЖГвидо.

https://brmmm3.github.io/posts/2019/07/28/python_and_lua/
https://github.com/scoder/lupa

Люди делают offload cpu intensive нагрузки из Питона в Lua, потому что:
- lua параллелится
- lua имеет jit, и в разы быстрее per core.

В Lua, Карл! Даже не в С!

* На просторах интернетов нашел блог создателя musl. Мне зашли два поста:

http://ewontfix.com/18/. Читаем ассемблерные листинги, больше никогда не смотрим в сторону .so
http://ewontfix.com/17/. Legacy в Linux. В Linux треды это процессы, поэтому uid/gid там, на самом деле, пертредные. Рассказ про то, как сложно сделать атомарное изменение setuid для пачки тредов одного процесса(которые, на самом деле, тоже процессы).

* Красивое про musl и #glibc. Сам баг не очень интересен, а вот разница подходов к разработке очень даже.

https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html

* musl, на самом деле, тоже упыри с бесценным мнением. Уже много лет как очень настойчиво отказываются заводить макрос, который бы идентифицировал, что мы сейчас собираемся с musl. Из-за этого нам такой макрос приходится делать самим, и мы не можем апстримить некоторые изменения в некоторые OSS проекты.

https://wiki.musl-libc.org/faq.html

Ждем libc от LLVM! https://llvm.org/docs/Proposals/LLVMLibC.html

https://www.tiobe.com/tiobe-index/ - python-то ого-го! Правда, дельта примерно 0, прост остальные упали.

Недавно наткнулся на ошибку valgrind в библиотеке RE2, if по неинициализированной памяти. Не думая, влепил туда memset, и зря, потому что это был единственный известный мне случай использования if по неинициализированной памяти во благо:

https://titanwolf.org/Network/Articles/Article?AID=a9a4c148-1643-4a82-aac1-a58ebef5d7c3#gsc.tab=0

Кстати:

1) RE2 лучшая библиотека регулярок для C++
2) Цикл про регулярки и про code search от автора RE2, Russ Cox, https://swtch.com/~rsc/regexp/ - это нужно знать всем.
3) Про переписывание компилятора Go с C на Go, от него же. https://www.youtube.com/watch?v=QIE5nV5fDwA Go я не люблю(там нет нормальной обработки ошибок и дженериков), но видос зажигательный.

* https://lists.llvm.org/pipermail/llvm-dev/2021-October/153113.html

LLVM хочет отказаться от фабрикатора, в пользу github PR's(не потому что он плохой, а потому что его забросили). Печаль. Мне гораздо более симпатичны(и удобны) тулзы, которые делают программисты для программистов(хотя они и вырвиглазны), чем те, которые делают дизайнеры для программистов.

* #glibc теперь можно не только собрать c clang, но и слинковать с lld. Вы уже знаете мою любовь к инструментам от GNU, поэтому новость позитивная, конечно. https://www.collabora.com/news-and-blog/blog/2021/09/30/a-tale-of-two-toolchains-and-glibc/

* пост за paywall, https://lwn.net/Articles/871866/ Про реализацию SMB протокола в ядре. #ksmbd Мои 5 копеек:
- судьба #khttpd ничему людей не научила
- нормальные люди из ядра пытаются что-то вынести, а не добавить. Сотни миллионов строк кода в ring 0 - это ненормально.
- почему не попробовали сделать то же самое, но в user space, с помощью #io_uring? io_uring нивелирует стоимость системных вызовов, и чем больше нагрузка, тем меньше получаются расходы на системные вызовы.

* умер Jörg Schilling https://lwn.net/Articles/872489/. Если бы не этот плачевный факт, он бы обязательно попал бы к нам в коллекцию упоротых(в хорошем смысле этого слова) людей. Посудите сами - своя система сборки smake, свой дистрибутив Solaris, так же он автор cdrtools(школота уже не помнит, но мы-то помним, как резали ими компакт-диски под linux). Мы такое любим. :(

#terminal

У нас тут проходил опрос на тему "какой эмулятор терминала вы используете". Я был очень удивлен, увидев, что #Alacritty там занимает предпоследнее место. Давайте я вам расскажу за эмуляторы терминала.

Исхожу я из следующих положений:

1) Благодаря встроенным в эмулятор настройкам, или используя что-то типа Karabiner Elements, keybindings можно настроить произвольным образом. Ну, то есть, можно отобразить любую комбинацию клавиш в любую последовательность ESC codes. Это упражнение можно проделать для любого известного мне эмулятора терминала. Например, я как 20 лет назад привык к keybindings от Konsole, так и использую их везде, хотя предпочтительный эмулятор терминала у меня менялся раза 4.

2) Благодаря tmux и подобным программам можно получить одинаковый(ну, почти одинаковый) user experience в любом эмуляторе терминала. Неудобство управления tmux(все вот эти C-b x) решаются с помощью пункта 1.

Какие у нас остаются различия?

1) Рендеринг шрифтов. Я имею наглость утверждать, что, если вы используете для терминала какой-то "внесистемный" рендеринг шрифтов(например, FreeType под macOS), то вы что-то делаете не так, и вам стоит поменять OS, чтобы не мучить глаза. Если вы используете системный рендеринг шрифтов в эмуляторе терминала, то вам пофиг на то, как называется программа, которая дергает системные функции.

2) Скорость отрисовки. Тут все очень просто, эту метрику можно объективно посчитать. Я инструментировал свой текстовый редактор, чтобы он умел работать с текстом в batch режиме(даем программе текстовый файл, последовательность команд, смотрим, сколько времени они выполняются). На первом месте по этой метрике получается Alacritty, остальные терминалы довольно далеко позади(iTerm, Kitty, Hyper.js, встроенный в macOS).

3) Мерцание. Это совсем не то же самое, что и 2. К сожалению, большинство терминалов написаны совсем рукожопно, поэтому они легко могут читать команды от приложения в буфер фиксированной длины, и когда буфер заканчивается, делать flush изменений прямо на экран. Это совершенно неверная модель, потому что мы легко можем сделать flush в середине отрисовки экрана приложением. По этой метрике все терминалы, за исключением одного, ведут себя довольно плохо. Единственный терминал, который я не смог уличить в мерцании, это Hyper.js(очень неплохой терминал, кстати, к сожалению, его разработку практически забросили(я знаю, что у него был релиз в первый раз за 2 года несколько дней назад, релиз "забагован" по самое не хочу)).

Короче, к чему это я? Мне кажется, что из вышеизложенного текста получается, что почти всегда сейчас нужно пользоваться Alacritty(за исключением того случая, когда для вас очень важно мерцание, тогда можно посмотреть на Hyper.js)

Раз уж начал про эмуляторы терминала, расскажу еще одну интересную вещь.

Изменение размеров окна в них сделано не посылкой in order команды программе внутри терминала, а с помощью посылки асинхронного out of order сигнала SIGWINCH(по примему которого программа должна in order спросить у эмулятора терминала новые размеры окна). Ни один известный мне эмулятор терминала не реализует этот протокол корректно - при изменении размеров окна всегда будут случаи некорректной отрисовки приложения. Правильный протокол выглядит так: когда эмулятор терминала понимает, что окно изменило размер:

1) Нужно послать SIGWINCH приложению(out of order)
2) Нужно дождаться, когда приложение пришлет запрос на определение новых размеров(in order). Послать ему ответ.
3) Вот тут тонкий момент. Так как у нас нет нормального framing и подтверждений о доставке, нужно дождаться, когда буфер в pipe становится пустым, в обе стороны. Это не всегда возможно(например, если прямо сейчас в терминале запущен cat на большой файл), поэтому эту операцию нужно делать с timeout.
4) Только в этот момент можно поменять в своих структурах данных размерности окна на новые. Если это сделать раньше, возможны глюки.

К сожалению, что эмуляторы терминала, что программы, тут предпочитают логику на sleep.

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

Тут должна быть шутка про JS разработчиков, или про Memory Safety в Rust, но мне немного лень.

Например, 2 разных подхода к оценке реализации асинхронности(вторая ссылка не про C++, но она точно так же применима к С++, или к Python):

https://habr.com/ru/company/yandex/blog/575062/
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ (названия каждой новой главы доставляет)

Или, например, как сдизайнен async API в jinja2:
https://jinja.palletsprojects.com/en/3.0.x/api/

Казалось бы, где jinja2, и где async? Но нет, мы же можем передать в нее контекст, который загружает шаблоны по сети.

Я, скорее, согласен со вторым автором. Пока будет такое разделение на 2 мира, и поддержку async придется добавлять руками, дублируя код, async популярным не станет.

Кстати, зачем Python ушел от yield from к async/await - я не понимаю. По сути, как раз в Python не было(вернее, она была еще раньше - обычные функции vs. генераторы, но никогда не было проблем звать функции из одного мира в другом) этой проблемы разделения на 2 мира, и ее добавили искуственно.

PS: как сделать call/cc(очень похожая на корутины тема) в С++, с помощью fork() http://mainisusuallyafunction.blogspot.com/2012/02/continuations-in-c-with-fork.html Осторожно, по ночам будут кошмары.

Оказывается, G уже запилила fuzzer для Linux:
https://github.com/google/syzkaller

С внушительным послужным списком:
https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs.md

Это прекрасно. Интересно, используется ли это в процессах разработки ядра, или работает сбоку?

Фаззить системные вызовы - это хорошо, но мало.

Мне нравится использовать контейнеры, но я не люблю docker.

Нужно понимать, что docker - это не то, что реально выполняет код в контейнере. Это очень простой CLI над несколькими системами Linux. Фактически, задача docker - скачать tar.gz с файлами образа, и запустить какой-то OCI compatible runtime над разархивированной папочкой. Docker - самый старый такой CLI для Linux(если не вспоминать LXC). Поэтому он накопил довольно большой груз проблем.

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

Например, процессы контейнера запускаются этим демоном. Лично меня беспокоит соседство внешнего кода и root демона. Я понимаю, что демон сбрасывает привилегии, но когда это кому мешало? Код может сбежать из контейнера, и наличие некоего демона, который обеспечивает какие-то важные функции для этого контейнера(то есть, обрабатывает запросы от него!), и работает под root - ну такое.

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

Поэтому docker'у я предпочитаю daemonless, rootless решения:

1) Podman. Работает daemonless, умеет работать rootless. Обеспечивает CLI такой же, как у docker. А теперь и под macOS! https://davegallant.ca/blog/2021/10/11/replacing-docker-with-podman-on-macos-and-linux/

2) Семейство udocker. https://github.com/indigo-dc/udocker. Вообще не требует ничего от системы, даже USER_NS. Работает с помощью тулзы под названием proot(https://proot-me.github.io/), которая перехватывает системные вызовы от управляемого процесса с помощью ptrace(считайте, API для отладчика). Написан на python, что для меня глоток свежего воздуха, после засилья Go во всяких CLI для контейнеризации.

3) Таки звать OCI runtime напрямую! Это не rocket science - скачать tgz, распаковать ее, и запустить 1 бинарь:

pg@:~/bundle mkdir rootfs
pg@:~/bundle docker export $(docker create busybox) | tar -C rootfs -xvf - > /dev/null # тут можно позвать curl
pg@:~/bundle runc spec --rootless # создаем config.json, почитайте его, там тоже никакой магии
pg@:~/bundle runc --root /tmp/runc run qw
/ #

Actually, это мой любимый способ. Такой chroot на стероидах, со всеми вытекающими удобствами. Во первых, он совершенно не оставляет за собой "следов" в виде висящих процессов, во вторых, очень гибкий(например, попробуйте под docker build заменить содержимое /etc/hosts - https://stackoverflow.com/questions/38302867/how-to-update-etc-hosts-file-in-docker-image-during-docker-build, и не работает для ipv6), это важно для всяких CI/CD pipeline.

Вместо runc(это OCI runtime от docker) можно взять любой другой - https://github.com/containers/crun, тысячи их!

И вторая важная тема!

Контейнеры под Linux - это не способ изоляции! Контейнеры имеют полный доступ к ядру Linux, и могут произвольно эксплуатировать уязвимости в нем! Поэтому, желательно, использовать какую-то прослойку между ядром Linux, и пользовательским кодом контейнера. Например, для этой цели можно ипользовать gVisor. https://github.com/google/gvisor Это такой эмулятор ядра Linux, написанный поверх ядра Linux. У него есть некоторые недостатки:

* Написан на Go, И требует bazel для сборки - это аццкое сочетание, trust me.
* Пока не умеет в rootless :(

Если приходится использовать docker безальтернативно, я крайне рекомендую посмотреть на gvisor, для более лучшей изоляции.

Интересных ссылок в последние дни нет.

Разве что:

* Новая Зеландия отменила контракт со штатным колдуном. https://boingboing.net/2021/10/13/official-city-wizard-fired-from-new-zealand-city-after-over-20-years-of-public-service.html Оригинальная ссылка недоступна, возможно, происки колдуна.

* Вышла совершенно ничем не примечательная OpenBSD 7.0 Ссылку на changelog не кидаю, там ничего нет. Зато, как обычно, с каждым новым релизом OpenBSD разработчики выкладывают какую-то графоманскую мелодию, которой можно насладиться тут - https://www.openbsd.org/lyrics.html#70 Треш, угар, содомия.

* Российская Государственная Открытая Лицензия - https://habr.com/ru/news/t/583156/ Сейчас запилят православный github, тогда заживем.

* Переписка про удаление GIL из Python - https://mail.python.org/archives/list/python-dev@python.org/thread/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/

Вот что пишет г-н Гвидо про nogil: #gil #fast_python

"To be clear, Sam’s basic approach is a bit slower for single-threaded code, and he admits that. But to sweeten the pot he has also applied a bunch of unrelated speedups that make it faster in general, so that overall it’s always a win. But presumably we could upstream the latter easily, separately from the GIL-freeing part."

"Я с удовольствием использую идеи автора в своем проекте по ускорению Python"

Осталось понять, PRO, или MAX?

Заявления Apple про скорость звучат, как чудо, но M1 они же доставили?

https://www.apple.com/ru/shop/buy-mac/macbook-pro/14-%D0%B4%D1%8E%D0%B9%D0%BC%D0%BE%D0%B2

https://news.ycombinator.com/item?id=28908383 - 1800 коментов, давненько на HN такого не видел.

Очень мне нравится новый экран. 2560x мне было маловато(например, после Asus ROG Flow X13 с его 3840x). Я вижу отдельные пиксели в шрифтах :( Интересно, почему в этой области Apple не пытается быть впереди планеты всей?