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

Сломался ceph + kuber у проекта freedesktop. #gitlab #infra #selfhost

Я бы тут хотел толкнуть мысль, что надежные распределенные решения - это нифига не дешево, и оно имеет смысл только на large scale.

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

Если вы, вдруг, решили на 3 хоста взгромоздить кубер, а в него ceph, чтобы сэкономить на поддержке и администрировании, нужно понимать, что:

* скорее всего, вы не понимаете базовых требований к инфраструктуре, чтобы консенсусное решние было действительно надежным. Например, что нужно быть уверенным, что запись на диск - это реально запись на диск, а не в память контроллера. С ходу - в каких OS/FS какие нужны настройки, чтобы это гарантировать?

* скорее всего, у вас не будет админа или девопса 24/7, который будет решать проблемы вида "у нас на одном из 3 ssd заканчивается место, скоро все наши хитрые консенсусные алгоритмы перестанут гарантировать то, что они гарантируют".

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

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

Поэтому, конечно, freedesktop - школота.

Почитать про развитие событий из первых рук можно, например, тут - https://people.freedesktop.org/~cbrill/dri-log/?channel=freedesktop&highlight_names=&date=2022-06-12&show_html=true

Смешных картинок в ленту!

https://www.opennet.ru/opennews/art.shtml?num=57358 #cve #CVE

"It is all about probability"

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

Full disclosure - я не верю в безопасность. По крайней мере, в том виде, в котором ее нам "продают".

Я не верю в CVE.

Реальные взломы не происходят через публично доступные CVE. Ладно, на самом деле, раз в год бывают ситуации, когда в CVE пишут "ну вот тут у нас сломан chrome, и мы реально встречали взломы через этот баг in the wild". Раз в год, из всех CVE.

Во всем остальном база данных CVE:

* PR для тех или иных работников безопасности. Найти какую-нить дичь, которой присвоят CVE - это всегда полезно для CV.

* Удобная пугалка для RedHat, с помощью которой можно обосновать необходимость платной подписки на обновления софта.

* Удобный аргумент для сторонников динамической линковки. На самом деле, так себе аргумент, потому что пересобрать все зависимости не так уж и дорого(помните, я писал про скорость роста CPU мощностей, и про скорость роста сложности софта?), и скачать их через CDN - тоже.

Я, например, не согласен, что, когда случается баг в zlib, нужно бежать сломя голову, и обновлять всякое старое говно мамонта.

Когда нашли багу в zlib, нужно обновить nginx/envoy/etc, и не более того. Все остальное - в порядке очереди.

Есть один класс проблем, которые нужно чинить быстро - это проблемы в браузере.

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

Так же я не верю в CVE, потому что bug bounty программы от вендоров - это смешные копейки.

Будьте уверены, что реальные zero days люди продают за десятки миллионов долларов, в даркнете.

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

Поэтому CVE, и дыры, через которые реально хачат - это две большие разницы.

Так, введение закончилось, теперь про данный конкретный случай.

Что я про него могу сказать?

Статья на https://lwn.net/Articles/897914/ про него начинается так:

"Today's branded, logo-equipped vulnerability is known as Hertzbleed"

Что тут написано? Что авторы уже придумали красивое название, и завели сайт, посвященный уязвимости.

На самом деле, на этом можно было бы и закончить, и ежу понятно, на кого вся эта показуха рассчитана(не на нас с вами), добавлю только, что я очень хочу, чтобы облачные вендоры уже начали разделять локации с mitigations=off, и с mitigations=on.

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

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

PS: текст довольно controversal, поэтому я тут явно напишу, что это исключительно мое, и только мое, мнение.

#strong_ai

Слушайте, а что вы думаете про https://www.ixbt.com/news/2022/06/14/opublikovan-dialog-s-razumnym-ii-google-lamda-kotoryj-nazyvaet-sebja-chelovekom.html ?

Серьезный фактчекинг мне недоступен.

Это может быть как что-то действительно интересное, так и графомания пары человек. Лично мне кажется больше похожим на очередной AI фанфик.

В любом случае, напомню содержание предыдущей серии моего размышления про сильный AI:

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

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

TL;DR; - зачем плодить големов?

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

И заняться улучшением работы человеческого мозга.

Возможно, однажды мы его проапгрейдим настолько, что он сможет понять, что делать с этой задачей(пониманием, есть ли у какой-то конструкции самоосознание, или нет) вообще, а пока это игры с огнем. Например, эти игры прекрасно объясняют парадокс Ферми.

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

UPD: я прекрасно понимаю, что, с точки зрения наблюдателя, вселенные, в которых X обладает человеческим самоосознанием, и не обладает, могут быть совершенно неразличимы. Для меня это не повод сказать "ну ок, тогда shut up and calc", а повод сказать "наш способ описания вселенной через взаимодействия несовершенен, потому что не позволяет мне сформулировать проверяемое утверждение "я обладаю самоосознанием"".

https://www.opennet.ru/opennews/art.shtml?num=57364 #hare #ddv

Автор sway представил свою новую микроядерную OS.

Знаете, когда он, недавно, представил какой-то всратейший язык программирования, я смолчал.

Все же, автор #sway, #source_hut, и вообще, уважаемый человек.

Но тут он совсем кукухой двинулся - сначала запилил очень странный язык(примерно такой же низкоуровневый, как С, с чертами Go, но по стройности не дотягивает до того же zig), а теперь и новую OS на нем.

Я бы, конечно, предложил ему ix в качестве пакетного менеджера, но он же на неправославном python.

Кстати, все еще предлагаю кому-нить взять задачку про запил graph execution engine на православном С++/Rust.

———
Я, вдруг, понял, что последние пару недель не делаю ничего существенного ни в движке #IX, ни в пакетной базе #stal/IX. Так, рутина по обновлению версий.

Ну, положил вот mariadb, ну пидарасы они - написали своих заголовков для системных библиотек, типа zlib.h, lz4.h, etc, потому что хотят уметь загружать их в runtime. Но это так, не тянет на большую историю.

В связи с этим у меня вопрос к оунерам известных проектов - а чо дальше то?

Есть какой-то мануал?

У меня тут довольно примерное понимание - запилить сайт-визитку со ссылками, запилить документацию по установке, и на этом все.

Накидайте, короче, советов, на тему "как в первый раз выйти в свет"! На чем запилить сайт-визитку?

И смешных картинок в ленту!

https://jmmv.dev/2022/06/autoconf-caching.html

Интересный текст про одну малоизвестную фичу #autohell, и про ее полезное применение.

TL;DR - для configure можно заранее приготовить список ответов на вопросы про систему, которое оно задает.

В тексте указывается специальный ключ для configure скрипта, но, на практике, этим никто не пользуется.

Все просто выставляют переменные среды, которые читает configure скрипт:

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/gdb/t/ix.sh#L33 - вот тут явыставляю, что у меня нет ada компилятора.

Все эти проверки написаны на shell, глючат от версии к версии, никто не полезет разбираться, почему эта конкретная проверка просто зависает, проверяя, что в clang нет поддержки Ada.

Все дистростроители про эту фичу знают, и активно ей пользуются. Почему? Потому что они работают, как говно, недавно писал про такой случай - #werror

Тут возникает резонный вопрос - а что, если посчитать все такие стандартные переменные, записать их в файлик для target platform, и применять перед каждым configure?

Мне, как proud owner своего дистрибутива, это:

* интересно

* довольно просто попробовать

Я однажды это и сделал, но почему-то не написал. Наверное, потому что это было еще до того, как я начал активно писать про #stal/IX, а потом просто забыл.

Статья мне про этот случай напомнила, вот, пишу.

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

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

В целом, профит хороший, скрипты ускоряются кто в 2 раза, кто на 20% - зависит от числа кастомных проверок и от их сложности.

Внедрил ли я это? Нет, пока не внедрил - страшно.

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

Ну и, на самом-то деле, профит не такой уж и большой, autohell в дистрибутивах все меньше и меньше.

Мне эта фича, скорее, интересна в плане кросс-компиляции, когда configure скрипты работают херово, по понятным причинам(криворукие авторы пытаются по запуску host программы что-то узнать про target систему).

Я пару раз писал про то, что совершенно не доверяю тестам от #phoronix.

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

И, буквально вчера, про сложность отлабки проблем с configure скриптами(в общем, не только от #autohell).

Вот, пожалуйте, как в воду глядел - https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-Bizarre-Zstd

TL;DR - Михаил тестировал разные дистрибутивы Linux на perf, и у него оказалось, что zstd сильно медленнее в Arch, чем в остальных дистрибутивах.

Выяснилось:

* Что arch использует cmake сборку(я тоже), остальные - простой Makefile

* В cmake сборке используется не тот стандарт на C, что и в остальных сборках. В Makefile - default, в cmake, вроде, с99, в meson - gnu99(есть и такой, они там совсем кукухой поехали).

* Бага только в многопоточном тесте, бага в использовании тормозного таймера - https://github.com/facebook/zstd/pull/3165/commits/376b9a0be4cc2972f2d2c4074ae1b6dfbe381330

https://github.com/facebook/zstd/issues/3163#issuecomment-1159627324

Что я могу сказать?

* Сборка OSS программ - это очень subtle вещь. Поэтому я, например, так и не перешел на более быстрый shell для запуска configure, и использую всратые coreutils.

* Phoronix заинтересованы в сенсации, а не в корректном и скучном освещении событий. Поэтому, когда там где-то написано, что freebsd выигрывает у linux в 2 раза, или наоборот - то это не заслуга OS, блин, не могут OS реально настолько отличаться, особенно в CPU intensive, а степень кривизны рук авторов configure(которые могут включить ассемблерные вставки только под Linux, например), или Миши, которому насрать.

(Побугурчу про Мишу, его стиль письма очень доставляет. Найдете хоть один текст без слова "exciting" - киньте мне, помещу под стекло. Степень его экзальтированности зашкаливает)

Я ничо делать не стал, потому что, напомню, я плевал на особое мнение upstream, и у меня есть clang wrapper, который определяет оптимизации так, как я считаю правильным.

Ну и проблема только в тесте, а Makefile у них кривой донельзя, не зря я(и Arch) выбрал cmake.

#llvm weekly

https://reviews.llvm.org/rGf06abbb39380

Аааа, llvm busybox style binary приземлился! Пока в довольно ограниченном виде:

(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.

Но лиха беда начало!

В прошлых сериях рассказывал, почему такой multicall хорошо и правильно, и что в llvm community есть сильное мнение против этой фичи. Очень переживал, что оно так и не будет внедрено, поэтому рад несказанно.

———
https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
https://lobste.rs/s/hfjlba/v_language_review_2022

Давеча писал про #vlang, с прицелом на написание необходимых мне сборочных скриптов.

Python ужасно тормозной, например, мой clang wrapper замедляет сборку примерно в 2 раза, а его задача - просто переосмыслить cmd line для запуска настоящего компилятора.

Мне, конечно, тогда напихали за щеку рассказали, что vlang лучше не трогать, потому что его авторы рассказывают, но не показывают.

Вот, по ссылке - разбор современного состояния vlang.

TL;DR; - все плохо, бОльшая часть заявленных фичей не работает, да и корки в типа безопасном языке - ну такое.

———
Bootstrap story.

Собирал себе wireshark. Потому что в транк приземлили поддержку QT6, а QT5 у меня нет, и мне ее лень собирать.

Все прошло, как по маслу, разрабы wireshark молодцы, у них прямо есть опция для сборки wireshark без плагинов.

Но что-то сломалось в сумасшедших скриптах для cmake от QT, они начали писать, что, внезапно, у меня нет glib, хотя он, конечно, присутствовал.

Дебажить cmake скрипты - это дело совершенно безблагодатное, поэтому мне показалось, что проще убрать упоминание про glib в сгенеренных cmake скриптах от QT - https://github.com/pg83/ix/commit/7b46d6133b62f7b09cb37a57ba3817313e90ae7a#diff-19b6fefa6a33c75dfaedcd1b884a63a665b515b6c9894595aec999a951da530bR53

Лучше, конечно, было бы разобраться, но в cmake нет такой возможности.

Все, что оно умеет для отладки - это выдать дамп исполнения, со значениями переменных, которые были в IF(), FOR(), etc.

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

https://www.phoronix.com/scan.php?page=news_item&px=Rust-For-Linux-5.20-Possible

Big news!

Linus говорит, что, вполне вероятно, Rust в Linux будет уже в 5.20.

По #linux_rust_linux вы можете посмотреть, почему я эту новость считаю исключительно хорошей и лулзовой! :D

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

———
Вышла новая телега, 4.0.0.

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

Когда собирал, увидел, что телега написала нативную wayland интеграцию - из репозитория исчез враппер над kwayland - https://git.sr.ht/~pg/ix/commit/790b39736be2579587240f245a6d687f566d5de2#pkgs/bin/telegram/desktop/unwrap/t/ix.sh-1-5

Собственно, ровно оно у меня и сломалось.

Если отжать галку "use system decorations", теперь показывается старый темный window border от телеги. А если включить - то какое-то странное белое нечто, которое рисует явно не sway.

Старые декорации(темные) стали, к тому же, скругленными.

Blueeeh.

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

Facebook пишет swap под Linux, так, как он должен быть устроен. Ручки по настройке в ядре, сложная логика по управлению - в userspace.

Ну невозможно на C без граблей писать сложную логику.

Сегодня смешные картинки категории Б!

https://usebottles.com/

Раньше это был скрипт для установки wine приложения в отдельный environment.

Скрипт разросся в целый магазин, а теперь его оунеры просят дистрибутивы не распространять его через свои репозитории - https://usebottles.com/blog/an-open-letter/

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

"We understand the need of providing a trusted source where users can obtain packages. However, we vastly prefer to provide no support than poor support, just so the user needn’t deal with a bad experience with Bottles directly. We also prefer to avoid telling users that the packagers who unofficially packaged Bottles did so incorrectly and/or didn’t test enough."

Качайте, грят, через flatpak.

———
Давеча писал про большие числа - #bb

Невообразимо большие числа совершенно непонятно, как сравнивать - отношение 2 невообразимо больших чисел может быть как невообразимо большим, так и невообразимо малым(вообразимыми я называю числа вида 100^500 - с ними мы умеем обращаться, и даже представлять, что это такое).

Вот, например, красивый результат - BB(6, 2) > 10↑↑15

Что это значит? Я не понимаю, и никто не понимает, но математика там интересная - https://www.sligocki.com//2022/06/21/bb-6-2-t15.html

Найдут ли когда-нибудь X такое, что BB(6, 2) < 10↑↑X? Глубоко сомневаюсь, эти числа, наверняка, совершенно из разных "классов невообразимости", если вы понимаете, о чем я :D

———
https://www.reddit.com/r/cpp/comments/vcedoe/til_about_the_stdranges_compile_time_tax_everyone/

Тут вот пишут, что простой код вывода в поток стал компилироваться в 2 раза дольше в С++20, из-за включения огромной библиотеки с ranges.

Несколько раз уже писал, что современные языки и компиляторы попали в ловушку последних 5% перфа, из-за которых нам приходится терпеть кратно возросшее время компиляции.

По мне, было бы круто, если бы можно было договориться, и открутить назад последние 20% перфа, но ускорить время сборки в 2 раза. КМК, за освободившееся время вполне можно было бы намолотить эти 20% другим способом.

Но ведь всегда найдется умник, который скажет "а давайте включим в проде LTO".

Я очень последовательно выкорчевываю из кода всякие завязки на X server.

Потому что, если не выкорчевать, то бывает ситуация, когда код, будучи собран под wayland + X11, и, видя наличие X server, предпочитает выбрать рендеринг через X. Вот, например, qemy форсит рендеринг через X, выставляя переменную окружения для SDL - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/qemu/ix.sh#L63 Знали бы вы, как я это дебажил, потому что понять, почему SDL пытается выбрать X, хотя он в него даже не вкомпилен - ну такое.

А нафига оно нужно, если там то hidpi через раз работает, то размер курсора отвалится, то еще чего нить.

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

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/pcmanfm/ix.sh#L30 - вот тут я, например, полностью выпилил возможность ренедрить десктоп в pcmanfm.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/dunst/ix.sh#L27 - а вот тут - хитрый редирект одной реализации виртуального интерфейса в другой, и занулил реализацию через X server. Пришлось заново переопределить некоторые интерфейсные структуры, потому что в них былы завязки на X - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/dunst/ix.sh#L44 Кстати, последовательный naming функций в этом коде доставляет - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/dunst/ix.sh#L29.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/ly/ix.sh#L48 - вот тут я имплементирую целый кусочек xcb, так, чтобы он просто возвращал ошибку соединения, и дальше X никак не использовался.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/lisgd/ix.sh#L19 - а тут притворяюсь куском Xlib, c той же целью.

Куча кода, которая пытается принудительно влинковать X11, хотя она им и не нужна - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/scummvm/ix.sh#L50, https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/lisgd/ix.sh#L15, тысячи их.

Короче, если вы думаете, что в вашей свеженалитой федоре все идет через Wayland - я только усмехнусь, попробуйте убить и удалить XWayland, и посмотреть, что отвалится!

А у меня совершенно точно без X, и это стоило значительных усилий.

Кто-то может сказать, что это дурь, а я скажу, что у меня в Fedora telegram через раз запускался то в Wayland, то через XWayland, и там то были корявые шрифты, то использовался libinput вместо synaptic, и потому то работала плавная прокрутка, то нет. Отлаживать эту проблему я лично затрахался, и больше не хочу.

Смешных движущихся картинок в ленту!

https://drewdevault.com/2022/06/23/Copilot-GPL-washing.html

https://twitter.com/ReinH/status/1539626662274269185

#copilot #strong_ai

"Machine learning is essentially a glorified pattern recognition and reproduction engine, and does not represent a genuine generalization of the learning process. It is perhaps capable of a limited amount of originality, but is also capable of degrading to the simple case of copy and paste."

Что я тут могу добавить?

* А кожаные мешки чем отличаются? Смотрят на чужой код, и выдают какие-то другие его вариации, более хорошо предназначенные для решения конкретной задачи. Процесс обучения человека и машины чем принципиально отличается?

* Ну, что думает MS про обучение на github, всем понятно. А вот тонкий момент - а что, если обучить copilot на утекших исходниках Windows NT, или закрытых драйверах Nvidia, а потом он начнет делать интересные подсказки для авторов Nouveau и ReactOS? Это вот как будет классифицироваться? Насколько я понимаю, сейчас для кожаного мешка из соответствующих проектов читать такое - зашквар, потом код нельзя писать.

* КМК, Дрю ДеВолт таки пиарит на этом свой хостинг source hut, хотя явно заявляет, что не делает этого.

———
https://news.ycombinator.com/item?id=31846593

Пишут, что Я выложил большую модельку.

Ничего про модельку не знаю.

Обсуждение на HN классное - и про Путина, и про Ирак с Ираном, все, как положено.

600 комментариев - IMHO, довольно дофига.

Пеняют, что не нужно называть OSS проект "cocaine".

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

Я уже так пробовал, мне не понравилось почему-то.

Попробую еще раз, потом устрою опрос, как лучше.

#copilot #ddv

https://lwn.net/Articles/898772/#Comments

В продолжение вчерашней темы, обсуждение статьи ДеВолта на lwn.net - https://lwn.net/Articles/898772/#Comments

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

TL;DR - derivative work довольно странное понятие, и оно не может определяться лицензией per se, а пределяется законом. То есть, я не могу в лицензии написать, что вот текст после обработки copilot - это derivative work, с соответствующими ограничениями.

Про хрупкость OSS систем сборок.

Есть такой проект, x265. У него вышла новая версия, я ее обновил, но, почему-то, с новой версией перестал собираться ffmepg, с сообщением от configure, что, мол, x265 не установлен в системе.

configure так посчитал, пому что x265 не установил в доступное место x265.pc, скрипт для pkg-config - основной способ резолвинга зависимостей.

Пристальное разглядывание сборки x265 показало, что установка этого файла зависит от флажка X265_LATEST_TAG - https://bitbucket.org/multicoreware/x265_git/src/9b59d45549f460e41a852cfd276f9b89eed2112a/source/CMakeLists.txt#lines-743

А флажок выставляется только если в системе есть бинарник git, хотя он может и не использоваться для поиска версии в репозитории, если в корне нет папки .git.

Вот так - нет git, нет и x265.pc, и пакета как бы и нету в системе.

Я пока добавил git в зависимости, но так-то у меня для подобных извращуг есть и фейковый git, просто пока не успел его проверить. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/x265/ix.sh#L22

Мораль? Сборка OSS проектов - это говно и палки, а, иногда, и палок не завезли.

https://roman.pt/posts/dont-let-dicts-spoil-your-code/
https://lobste.rs/s/gzemqn/don_t_let_dicts_spoil_your_code

Тут вот коллега убеждает всех, что не надо использовать словари в питоне для взаимодействия разныхслоев в коде. Пишет, что надо все преобразовывать в классы, и как можно раньше переводить ваши данные из json-like словарей в эти иерархии.

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

Сначала я несколько переформулирую задачу, надеюсь, что без https://en.wikipedia.org/wiki/Straw_man

Учем, что в Python (очень упрощенно, но достаточно для моих нужд)

a.b := a.__dict__['b']

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

Плюсы этого подхода понятны - иногда(pun intended) не нужно менять внутреннее представление при изменении формата данных и протоколов.

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

Минусов же - вагон и маленькая тележка:

* Если вам не повезло, то нужно менять и промежуточное представление, и внутренние данные. Это все усложняет, и вы можете стать заложником такого разделения при попытке сменить формат данных.

* Люди, на самом деле, плохо предсказывают будущее, и не везти вам будет сильно чаще, чем хотелось бы.

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

* Performance. На этом не останавливаюсь, и так все понятно. Тут мне могут возразить про туплы и датаклассы - на разборе много потеряете.

* Достаточно subtle вещь, но IMHO важная. В Python dict везде, вы можете очень прозрачно манипулировать этими словарями как объектами, так и как kwargs, и часто это очень удобно. С классами как?

**a.__dict__['b']

? Ну такое.

* На каждое сочетание частей исходных данных классов не наберешься. Я к тому, что разных вариантов нетипизированных словарей у вас может быть очень много(в том числе, data driven), и вам совсем не захочется их все как-то именовать.

* #protaskivanie

Я свои словари разбираю только, если мне нужна полиморфная иерархия классов. И то, я постараюсь словари в поля классов не разбирать, а положить одним словарем все.

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

(Если подумать, то у меня в коде на Python сильно больше словарей и функций, чем классов с методами)

Ну и такое, философское, замечание - вот так вот отказываться от словарей в Python, это как в Lisp от списков.

2 новости, одним блоком, потому что, они, по сути, про одно и то же.

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

Люди запускают ядро Linux в виртуалке во FreeBSD, чтобы использовать драйвер для сетевой карты. Звучит всрато? По мне так огонь - это еще один подход к снаряду "драйвера в userspace".

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

"Применение асинхронной буферизированной записи на базе io_uring до 80 раз снизило задержки в XFS"

Как по мне, обе этих новости про то, что монолитные OS уже отжили свое, потому что современные технологии и практики программирования приводят к тому, что не нужно делать context switch на каждый чих, и выселение сервисов OS в user space не бьет больно по throughput и latency.

Уже писал, и еще раз напишу, что будущее осестроения - это ядра, которые будут заниматься установкой соединений между сервисами, и поддержкой вот таких вот uring между сервисами в user space.

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

Уязвимость в минорной версии openssl. Я подчеркну "в минорной", потому что хочу рассказать про следующий забавный факт.

Примерно в 20 - 30% случаев за каждым релизом какого-то OSS софта, через день-два следует следующий релиз с исправлениями багов.

Тут можно понимающе усмехнуться, и сказать "ну, на то и минорные релизы, чтобы фиксить проблемы мажорных".

Но, дело в том, что это нифига не так - фиксы следуют один за одним именно в минорных релизах. За последнюю неделю:

neovim 0.7.[1, 2]
popt 1.[17, 18, 19?(непонятно, был он, или нет)]
libidn 1.[40, 41]
телега 4.0.[1, 2]
+ топикстартер.

И это только то, что я вспомнил из головы.

К чему это я все?

Не работает этот ваш #semver, хреначат баги в прод без тестов почем зря.

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