https://www.phoronix.com/scan.php?page=news_item&px=OpenBLAS-Russia-Elbrus-Issue

ебаный стыд

Аргументация, кстати, довольно разумная.

Напомню историю - аккаунты того "вандала", конечно, забанили.

Вот вам еще пример подобного вандализма:
https://github.com/arendst/Tasmota/commit/98cbf2587a1a914bbd16996ebb48dd451d3da448

Я думаю, сейчас мы узнаем, интернационален ли вандализм, или он тоже делится на рукопожатный(назовем его "вандализм за правое дело") и нерукопожатный.

Коллеги из MS, вы меня читаете, обратите внимание на ссылку.

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

Я постепенно приближаюсь к сборке хрома.

* Разбираюсь с depot_tools. Написал скриптец, который заменяет 95% depot_tools - генерит скрипт для загрузки исходников из кучи репозиториев.

https://github.com/pg83/mix/blob/main/pkgs/mix/scripts/deps.py

Он получился довольно простым, потому что я хорошо понял структуру файла DEPS - https://chromium.googlesource.com/chromium/src/+/master/DEPS

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

* Собираю зависимости. На целый день встрял со всратейшей nss/nspr от Mozilla. Я не понимаю, зачем хром стал от нее зависеть, ну да ладно. Some highlights:

- исходники ее так просто не найти и не скачать. Мне кажется, Мозилла их стыдится, и правильно делает.

- для сборки исходников нужны две системы сборки - КАСТОМНЫЙ autoconf(я не шучу)*, и gyp. Немного в сторону - мне кажется, Google наслаждается разработкой систем сборки и их opensource. Я не понимаю, зачем, но она склепала их уже штук 10(и это только известные мне). gyp - вторая по всратости их система сборки, хуже только Android.mk.

- вместо gyp можно использовать третий вариант - на чистых Makefile. Тут, конечно, как в том анекдоте - есть система сборки без бага, но не работающая(gyp), и работающая, но с багом(make)

- товарищи настолько стыдились этого говна, что решили не делать install target. Я не шучу. Устанавливать все надо вручную, экзерсизы на тему можно почитать, например, в сборочном файле для Alpine. https://git.alpinelinux.org/aports/tree/community/nss/APKBUILD Еще там можно восхититься мастерству maintainer по вырезанию лобзиком чего-то полезного из этого мусора. Так же можно обратить внимание на вручную написанные .pc файлы для pkg-config: https://git.alpinelinux.org/aports/tree/community/nss?h=master

- https://git.alpinelinux.org/aports/tree/community/nss/APKBUILD#n56 факт того, что за разрабами приходится дополивать сборку, намекает на то, что они не хотели, чтобы в чужих руках это собиралось.

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

Печальную историю про то, что все это говно вовсю использует dlopen(), я пока оставлю за кадром.

*UPD: не совсем верно написал. Не кастомный autoconf, а кастомную замену для automake, поверх которой работает обычный autoconf.

https://github.com/opengs/uashield #yeswecan #provider

"Voluntary Ukraine security platform to protect us from Russian forces in the Internet"

"protect us"

Так-то это инструмент для ddos. Гитхабу, кажется, насрать.

UPD: меня, конечно, возмущает не факт того, что там невозбранно лежит софт для ddos. Меня возмущает:

1) Неконсистентный подход. Похожие, по сути, вещи кому-то можно, а кому-то - нет.

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

https://www.kommersant.ru/doc/5249015

Наше все Маск про цензуру. Маск, конечно, еще тот жук, достаточно вспомнить, как он своими заявлениями шатал крипту.

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

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

UPD: дополню мысль.

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

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

Короче, лекарство, которое всегда оказывается хуже болезни.

https://tjournal.ru/tech/554723-mincifry-reshilo-zamenit-inostrannye-sertifikaty-shifrovaniya-rossiyskimi-chto-eto-znachit-dlya-polzovateley-runeta

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

Отзыв сертификата у крупного банка, например - это большой удар по экономике.

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

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

https://www.phoronix.com/scan.php?page=news_item&px=KDE-Lower-This-Week

"KDE Activity Lower This Week As Impact From The Russia-Ukraine War"

Класс. Я вот тоже взял отпуск на недельку, привести мысли в порядок :)

———
https://music.yandex.com/album/10330389/track/95874611

Не про IT. Коллеги очень советуют послушать, говорят, успокаивает.

———
https://ria.ru/20220305/gosduma-1776795432.html

"Госдума запустила официальный Telegram-канал"

Я думаю, что ни у кого уже нет сомнений, что "Наше все" Принципиальный Дуров с кем надо договорился. В целом, это неудивительно, после приснопамятных событий я, ради интереса, придумал пару способов как заблокировать телегу в РФ, ничего сложного в этом нет. Думаю, тогда власти были просто не готовы.

———
Одной строкой - хакеры, которые ломанули NVidia, в пятницу ничего не выложили.

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

———
Писал как-то про то, что хочу начать контрибутить в OSS проекты свои патчи для Mix.

Я тут подумал, что довольно много из них общеполезно, как, например:
https://github.com/pg83/mix/blob/main/pkgs/lib/gtk/4/4/0.diff
(такой же есть и для gtk3)

Суть в том, что gtk использует свой механизм для настройки размера курсора, и это, например, ломается в sway, если руками не синхронизировать настройку в dconf/gsettings, и в sway. Я пофиксил это, взяв значение размера из переменной среды, которую устанавливает sway.

Шансы доехать до gtk у этого патча минимальны, потому что, как знают мои читатели, у gtk свой, особый, путь.

Короче. Не хочет кто-нить попробовать затащить это дело? Познакомиться с дистростроением изнутри, так сказать :)

Блин, забыл про веселую картинку в ленту!

В продолжение темы про модель безопасности. #sec_model

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

Еще 2 уязвимости, которые я считаю неважными. И некоторые соображения про их реализацию:

* всякие сложные модели безопасности плохо "компонуются", и получаются какими-то плохо взаимодействующими. Типа selinux + cgroups.

* чем сложнее система, тем сложнее про нее думать кожаному мешку.

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

Как иметь дело с inherent complexity? Я считаю, что с помощью иерархии - верхний уровень разделен на 2 слоя "все/ничего", в рамках каждого слоя можно запускать контейнер с таким же простым разделением.

https://miro.com/about/

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

#bs #vendor #ix_run #dev_shell #gold

Меня удручает состояние современных OSS систем сборки. Расскажу сегодня про такой аспект: каждая уважающая себя современная система сборки хочет иметь в себе пакетный менеджер.

То есть, обеспечивать не только выполнение сборочного графа одного проекта, но и всех сборочных графов всех зависимостей.

Cargo же все видели? Я пару раз писал, к чему приводит эта заявка на всеобъемлимость применительно к cargo - необходимость wrap все зависимости не под cargo в cargo сборку. Это выглядит уродливо, и приводит к проблемам с ромбоводными зависимостями.

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

Я уже писал про .wrap файлы от meson(для них существует целый репозиторий - https://mesonbuild.com/Wrapdb-projects.html).

Про это можно писать бесконечно, вот несколько очень всратых примеров:

* nodejs перепиливает сборочную систему от v8 на autoconf
* webkit переделывает сборочную систему от ANGLE(это реализация opengl от Google) на CMake
* chrome вендорит кучу библиотек, не буду описывать их по отдельности
* telegram вендорит все свои зависимости, и собирает их ни с чем не совместимым образом

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

Кстати, мне с этим живется несколько легче, чем там всяким fedora. В случае динамической линковки вендоринг - это еще и пересечение по путям в fs. В случае статической линковки это все хотя бы не видно наружу, достаточно де-вендорить всякие freetype/fontconfig и прочее.

Chrome, кстати, в этом отношении молодцы, они помогают де-вендорить те части, которые просто необходимо(типа рендеринга шрифтов).

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

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

Представьте себе команду

mix run lib/z lib/freetype bin/make 
    bin/cmake bin/clang/14 bin/ninja -- make -j 16

Эта команда сделает #realm , в котором будут доступны указанные библиотеки, указанные сборочные инструменты, и(вот тут важно!) врапперы для компилятора cc/c++/cpp (ну или rustc, кому что), которые автомагически настроят нужные пути к библиотекам и заголовочным файлам.

Кажется сложным? Ну давайте упростим это в alias mixrun=mix run $(cat mix.shell) —, и будем использовать так:

mixrun make -j 16

Или:

mixrun —sanitize=address —opt=-O2 make -j 8

Тогда в соответсвующем makefile вообще не нужно заниматься autodetect, перечислять всякие -I/-l-L/etc, а просто звать простые команды вида

cc -c x.o x.c

То же самое работает и для cargo, и для любой другой сборочной системы.

Основной point - система сборки уровня проекта не должна заниматься autodetect наличия зависимостей и их доставкой. Nix так умеет, Mix так умеет.

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

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

Веселая картинка в ленту!

https://www.phoronix.com/scan.php?page=news_item&px=MS-DX-HLSL-For-Upstream-LLVM

У меня сегодня негусто, но вот это IMHO большая новость. Microsoft хочет заапстримить в clang/llvm поддержку своего компилятора шейдеров для DirectX. Как часть этой поддержки, если я все верно понял, компиляция шейдеров в Vulkan SPIR-V. Очень надеюсь при жизни увидеть стандартизацию графического API на всех платформах :)

Пост не про IT.

Долго думал, писать его, или нет, но решил, что такой case study может быть интересным.

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

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

Мой use case:

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

После последних действий ЦБ, рубль не является СКВ, а для стройки нужны материалы, которые, по сути, номинированы в рублях лишь частично. Скорее всего, рубль будет падать еще. Поэтому мой основной риск - инфляция, его я и митигирую.

Оголтело бегать по обменникам я смысла не вижу:

* Неизвестно, чем завтра в Государстве Российском(далее ГР) будет являться наличный доллар. Менять на черном рынке на рубли для стройки - то еще(предположительно) удовольствие.

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

* Хранить в банковских ячейках - есть риск того, что конкретный банк навернется, и потом содержимое ячейки придется выковыривать год.

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

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

Ну и, так как я человек советский, конечно, 2000$ под подушку, на самый крайний случай.

В комментарии к тексту напишу, как я обращаюсь с битками.

Я думаю, в ближайшее время меня будет сложно найти в FB, зато можно будет тут:
https://xn--r1a.website/pg_live

https://miro.com/trust/compliance/notice/

Миро всячески старается откреститься от российских корней, чтобы ее не отменили.

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

https://habr.com/ru/company/yandex/blog/655185/

Классный текст на тему от Железного Пети.

Я думаю, техническая суть текста читателям моего бложика и без меня будет понятна, IMHO самое важное, что там написано:

"Неполный авторитет — это значит, что сертификаты НУЦ будут признаваться только для тех доменов, которые помещены в публичный список на gosuslugi.ru/tls. Если посещаемого сайта нет в этом списке, то попытка применить новый сертификат приведёт к стандартной ошибке и не даст посетить сайт. И нет, нельзя выпустить сертификат по маске так, чтобы покрыть все домены второго уровня (например, все *.ru) — на стороне Браузера такое просто не заработает. Кроме того, все входящие к нам изменения этого списка будут проходить через контроль явных ошибок. Если очень грубо, то это первый шаг к Certificate Transparency, чтобы обеспечить аудируемость процедуры выдачи сертификатов."

MITM не будет. С "понятными ограничениями".

https://bugzilla.mozilla.org/show_bug.cgi?id=1758773

Интересный тикет про сертификаты от госуслуг. Пара SJW-шных выжимок:

"Russia started trying to force people to install government root CA certificate"

"- Are you required to trust the root to visit sites not run by the Russian government (e.g. google)?
- Nope, but probably [yet]."

"Ofc, it will be used for doing MITM attacks if a valuable number of users install it.
I think Mozilla, Google and Microsoft should protect privacy of users in Russia." Тут предлагается, по сути, не давать пользователю руками добавлять нужный серт, заблеклистив его. Запрет неугодного сайта - это защита privacy. Свобода - это рабство!

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

Мякотка начинается тут - https://bugzilla.mozilla.org/show_bug.cgi?id=1758773#c17
Товарищ предлагает забанить центры сертификации, которые вздумали играть в политику. Я целиком и полностью поддерживаю это, потому что провайдеры инфраструктуры не могут выступать модераторами этой инфраструктуры(слуште, когда я только начинал писать про эту тему полгода назад, я и представить себе не мог, во что это выльется. Признаться, тогда меня очень бесил Тиндер).

В топике на этой ответили какой-то хней, ссылаясь на большой многостраничный pdf. Я не поленился прочесть, вот релевантный кусок:

"2. The CA obtains evidence that the Certificate was misused;"

Ну, охуеть теперь, под misused, при желании, можно что угодно подвести.

Я продолжаю настаивать, что misused - это когда сайт притворился чем-то другим, а контент на этом сайте не должен волновать CA.

https://bugzilla.mozilla.org/show_bug.cgi?id=1758773#c19

Запасаемся попкорном. Хотя можно и не, потому что результат немного предсказуем. Россия сейчас плохая, поэтому сертификат априори misused же, по извращенной логике cancel culture.

Цитата, очень верно отражающая мое отношение к тому, что CA решили фильтровать контент:

"– Это вот что: если я, вместо того, чтобы оперировать, каждый вечер начну у себя в квартире петь хором, у меня настанет разруха. Если я, посещая уборную, начну, извините меня за выражение, мочиться мимо унитаза и то же самое будут делать Зина и Дарья Петровна, в уборной начнется разруха. Следовательно, разруха не в клозетах, а в головах. Значит, когда эти баритоны кричат «Бей разруху!» – я смеюсь. (Лицо Филипп Филиппович перекосило так, что тяпнутый открыл рот.) Клянусь вам, мне смешно! Это означает, что каждый из них должен лупить себя по затылку! И вот, когда он вылупит из себя всякие галлюцинации и займется чисткой сараев – прямым своим делом, разруха исчезнет сама собой. Двум богам нельзя служить! Невозможно в одно и то же время подметать трамвайные пути и устраивать судьбы каких-то испанских оборванцев! Это никому не удается, доктор, и тем более людям, которые вообще, отстав от развития европейцев лет на двести, до сих пор еще не совсем уверенно застегивают собственные штаны!"

(конец цитаты несколько двусмысленен в текущем контексте, но я не какой-то там левак-цензор!)

Написал там про SJW. IMHO для IT блога это не очень подходящий текст, но ссылку дам, вдруг кому интересно.

https://lobste.rs/s/kfwxvu/microsoft_mimalloc#c_cvykcm
https://github.com/microsoft/snmalloc

Еще один интересный аллокатор от MS. Разбор устройства от автора на lobsters.

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

Не обошлось без интересностей и в системе сборки:

* отсутствует install target. И действительно, кому он нужен, все же будут вендорить код этой либы(нет).

* В статических либах все экспортируемые символы содержат префикс sn_. sn_malloc, sn_free, etc. В .so все в порядке. Я, когда вижу такое, всегда пытаюсь представить, что творится в голове у человека, который принимает такое решение. Что, зачем...

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

Классный срачик между отцами(и матерями!)-основателями ElementaryOS. Пример деловой этики, которую, КМК, я никогда не смогу понять(и простить).

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

———
https://etpgpb.ru/portal/import-substitution

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

———
Вышла новая версия #mesa, 22.0.0. Попробовал ее, epiphany начал писать при старте красивое(пишу по памяти, забыл сохранить):

EGL create context failure, invalid context, last error: EGL_SUCCESS.

Сука.

Хотел бы тут поспекулировать подискутировать на тему обработки ошибок в С/С++/Rust. Мне продолжает казаться, что необходимость указывать строгий тип для канала для возвращения ошибки не всегда хорошо. В С++ очень легко добавить новые типы ошибок в "глубинный" код. Да, иногда это приводит к тому, что внешний код не готов их правильно обработать, но вот такая ситуация, что мы тупо проебали половину контекста ошибки, в С++ случается гораздо реже.

Модель Rust, на мой взгляд, тут где-то между С и С++ - обогащать контекст ошибки сложнее, чем в С++, но компилятор, в отличие от С, с этой задачей поможет.

Интересно, как все это будет стрелять по мере накопления и старения кодовой базы на Rust.