У меня, кстати, есть немного поучительных подробностей про этот мой простой скрипт, который строит зеркало исходников для #IX. #gold

Он, на мой вкус, довольно сильно отражает мой подход к разработке, и, в этом плане, довольно показателен.

* https://github.com/pg83/ix/blob/main/pkgs/die/scripts/prefetch - это первый вариант скрипта, он весьма дуболомный, потому что он по шагам делает ровно то, что я хочу получить в результате - скрупулезно проверяет, не сделан ли был этот шаг на прошлой итерации, пропускает, что уже было сделано, переделывает то, что завершилось с ошибкой. Мерзкая лапша. Этот вариант я выкинул, после того, как получил работающую папку с кешем.

* https://github.com/pg83/ix/blob/main/pkgs/die/scripts/recache - а это второй вариант. Он, вместо того, чтобы делать что-то, описывает построение Makefile, который, будучи запущенным, сделает то, что мне нужно. На мой взгляд, он гораздо понятнее, потому что в 2 раза короче, и, вместо того, чтобы описать действия, описывает то, что нужно получить. Да, все, как я люблю - разложил задачу в граф вычислений, написал метапрограмму, которая описывает этот граф для какого-то движка выполнения графов, и выполняет его. Ну и, в целом, если вы описали свою задачу как программу, которая пишет другую программу, то вы существенно выиграли. А у меня тут аж целых два уровня - python, который генерирует Makefile, который выполняет shell. Заодно я получил распараллеливание закачек, совершенно бесплатно!

* мне несколько человек (кстати, у нас уже целых 5 зеркал!) написали, что, мол, моя программа падает с ошибкой. Да, падает, потому что не все файлы получается скачать - каких-то просто нет, какие-то недоступны в данный момент времени, и так далее. Мне это кажется очень разумным, и отражающим суть решаемой задачи - если нельзя скачать все файлы, то код ошибки должен отличаться от 0. Данную семантику мне обеcпечивает gnu make, даже буде запущенным с -k.

* https://gist.github.com/pg83/7a52dc5569e09102e341f55686fc3333 - выхлоп программы кажется "грязным", потому что перепутан output от разных паралллельных wget, и stack trace в конце. Это тоже важная тема - я очень не люблю причесывать торчащие наружу кишки в процессе разработки и серьезных доработок, потому что все такие "причесывания" ухудшают observability. Вот, реально, скрыл стектрейс - потом, в самый ненужный момент, будешь ебаться с тем, чтобы как-то его получить, потому что без него ничего не понятно. Всякого рода "причесываниями" стоит заниматься, когда код, по сути, завершен, и вы понимаете, что решаемая задача меняться не будет. Вот тогда можно сказать, что, если 1000 раз записал этот stack trace, и он не пригодился - ну и хрен с ним, можно скрыть.

* кто-то заметил, что у меня есть урлы, которые не ведут на исходники, а вообще ведут на динамический html контент - https://github.com/pg83/ix/blob/main/pkgs/die/scripts/urls.txt#L330. Да, есть, да, ведут. Код устроен так, что такой урл на хосте будет скачан 1 раз, переименутеся в ничего не значащий $(sha256sum) от этого html, и на этом все, про него можно забыть. А если бы я занялся выфильтровыванием всех "некрасивых" url из общего файла, я бы обязательно удалил бы что-то лишнее, и потом долго разбирался с багрепортами, что в кеше нет чего-то важного. Фильтрацией этого списка, опять же, можно заняться в будущем, когда будет доказана полезность этих 5 зеркал, когда будут починены и отлажены реальные баги, приводящие к реальным ошибкам у пользователя.

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

Красоту я, конечно, наведу. И url пофильтрую, и ошибку прикопаю, но когда-нибудь "потом".

#llvmweekly принес прекрасное

https://discourse.llvm.org/t/hand-written-in-assembly-in-libc-setjmp-longjmp/73249

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

Но случилась маленькая проблемка - setjmp/longjmp очень сложно написать на inline assembly (он, насколько я понял, таки разрешен), по разным интересным причинам.

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

Помяните мои слова, они этот код напишут как

__attribute__((section, '.text'))
char setjmp[] = {
    // и тут просто байтовое представление
}

Или что-то в этом роде.

https://go.dev/blog/wasi

Вот, в продолжение темы "#WASI as api boundary".

Go поддержал компиляцию в #WASI.

Я, в связи с этим, хочу поспекулировать на тему "WebAssembly as language boundary".

Получается, что программа, однажды скомпилированная в WebAssembly, может использовать рантаймы очень разной природы - на Rust, C/C++, JS, whatever.

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

Это, в целом, заманчиво, потому что пляски с ffi и системным ABI, которые, сами по себе, являются локальными оптимизациями под процессорные архитектуры 80-90х годов прошлого века, утомили. Нужно задавать передаваемые типы, а не исполнять 1000-страничные мануалы, где написано, когда и как что может быть передано в EAX.

https://www.neversaw.us/2023/09/04/understanding-wasm/part3/you-are-here/

А вот еще один, довольно водянистый, текст про WebAssembly/#WASI.

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

Но вот еще одна забавная мысль, которую я оттуда почерпнул - "WebAssembly as security boundary".

Что это значит? Это значит, что достаточно продвинутая WASM VM может эмулировать fork(), и процессы, без поддержки операционной системы, и без переключения контекстов, соответственно.

Идея это не очень новая (кто сказал https://en.wikipedia.org/wiki/Singularity_(operating_system) ?), но, кажется, в случае WebAssembly, мы близки к этому, как никогда ранее.

Вот, опять, ровно те же круги по воде - новая libadwaita, новая версия webkitgtk. Значит, скоро 45-ый #GNOME.

Вот вам соображение - libadwaita и webkitgtk пишет, в основном, #igalia, в первую переносят запчасти из epiphany, а вторую - в ней же и используют.

UPD: вон, даже релиз уже отвели - https://github.com/GNOME/epiphany/tags!

https://drewdevault.com/2023/09/17/Hyprland-toxicity.html

Слушайте, в этом тексте прекрасно все.

Некто Drew DeVault (#ddv, нам он известен как автор #sway, языка #hare, да и к sr.ht #source_hut он приложил руку) написал мощный #sjw текст, что #hyprland community ведут себя плохо, и вообще, обижают трансов.

"Most of them stem from the community’s tolerance of hate: community members are allowed to express hateful views with impunity, up to and including astonishing views such as endorsements of eugenics and calls for hate-motivated violence"

"In one particular incident, the moderators of the Discord server engaged in a harassment campaign against a transgender user, including using their moderator privileges to edit the pronouns in their username from “they/she” to “who/cares”"

В целом, про его склонность к #sjw было все понятно в тот момент, когда он запретил хостить на sr.ht проекты, связанные с криптой, и мне пришлось переезжать обратно на github (https://xn--r1a.website/itpgchannel/702).

Будни #bootstrap

Тем временем, я воспроизвел цепочку сборки rustc/cargo 1.54.0 от проекта #mrustc (большое им спасибо и долгих лет жизни) - https://gist.github.com/pg83/b114dc78ce39a41fb8c895580a005dd0

То есть, у меня есть функционирующие cargo и rustc, которые пока не могут собрать сами себя, из-за того, что rustc хочет линковать и подгружать .so.

Если кто-то хотел интересных задач, да и просто погрузить свои шаловливые ручки в #stal/#ix - сейчас самое время!

https://blog.vaxry.net/articles/2023-hyprlandsCommunity

А вот и ответ #ddv от автора #hyprland.

По мне, он выглядит гораздо более здраво, чем наезд от #ddv, почитайте.

Ну и если бы я верил в теории заговора, то сказал бы, что не могло бы быть лучшего PR этому проекту, чем наезд от #ddv. Например, видно, что этот ответ прочитали в 5 раз больше раз, чем предыдущие посты автора - https://blog.vaxry.net/

https://xn--r1a.website/itpgchannel/1336

Болельщики с мест нам подсказывают, что разработчики #hyprland прогнулись, и пилят CoC - https://github.com/hyprwm/Hyprland/pull/3366

В российских мониторах нашли бесполезные чипы

Существует такой «российский» монитор под названием V-MAX ПЦВТ.852859.300 от компании LightCom, который стоит более 50 тысяч рублей. Почему «российский»? Просто Минпромторг выдал ему 140 баллов «локализованности» за то, что там установлен микроконтроллер К1986ВЕ92QI (32-разрядный чип на ядре ARM Cortex-M3) производства зеленоградского «Миландра».

Но… если выпаять этот микроконтроллер и заменить его обычной проволочкой, чтобы включить цепь питания, то всё будет работать и без него. Потому что в мониторе установлен и спрятан за радиатором ещё один чип — RTD2525AR от тайваньской компании Realtek, который и отвечает за вывод изображения.

https://github.com/llvm/llvm-project/releases/tag/llvmorg-17.0.1

Вышел 17 clang. Почему-то сразу 0.1.

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

Внезапно, переход с 16 на 17 оказался абсолютно безболезненным, все просто собралось, и заработало.

Жизнь их к такому не готовила

Programmer memes

https://gist.github.com/pg83/150749bd29e9c1cc6596c5e0c479d01a

Вот, пожалуйста, 45-ый релиз #GNOME, и их gitlab снова лежит. А зеркало на github они, конечно, снесли, из каких-то очень важных (нет) соображений.

Человечеству совершенно необходим инфраструктурный сервис, который бы по sha256 от данных мог вернуть эти данные.

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

Нужно это:

* чтобы хранить результаты вычисления чистых функций (это когда на вход sha256 от нужных данных, на выход - sha256 от результата, который сохранен в эту самую DHT).

* ну и чтобы я мог запилить кеш исходников для #ix, да и для любого другого дистрибутива (и не только исходников, потому что сборка - тоже чистая функция в терминах первого пункта)

Проблема в том, что такой сервис, в чистом виде, денег не приносит (ну, кроме очевидной, что там будет лежать ворованный контент). А поэтому:

* в чистом виде его никто и не пилит

* а всякие поделия типа https://ipfs.tech/ не являются таким сервисом в чистом виде

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

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

Вот, пожалуйста, в CID в ipfs закодирован тип данных - https://docs.ipfs.tech/concepts/content-addressing/#cid-versions
Вот, пожалуйста, реестр типов их типов - https://github.com/multiformats/multicodec/blob/master/table.csv

Это vendor lock, в чистом виде (не факт, что он удачный именно в случае IPFS, но, тем не менее).

https://github.com/hyprwm/Hyprland/pull/3366

#ddv - хуемразь и ебаный нарцисс, не знаю, что про него еще добавить.

Пара цитат:

https://github.com/hyprwm/Hyprland/pull/3366#discussion_r1329091508

"Do not harass, intimidate, or in any other way discriminate against anyone, particularly with respect to traits including but not limited to their sex, religion, race, appearance, gender, identity, sexuality, and so on."

А теперь для самых наблюдательных - какие споры посчитал возможным иметь #ddv? (спойлер - про политику сраться можно)

https://github.com/hyprwm/Hyprland/pull/3366#issuecomment-1727815552

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

https://github.com/hyprwm/Hyprland/pull/3366#issuecomment-1728007656

Тут он пишет, что назвать его "нарциссом" - это нарушение CoC, nuff said.

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

#hashicorp

OpenTF переименовали в OpenTofu.

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

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

Отдай проект community, например, в ту же Linux/Apache Foundation, сообщество получит контроль над разработкой, а взамен (от крупных корпораций, которые получат представительство в этом проекте) предоставит деньги.

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

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

https://marc.info/?l=openbsd-tech&m=169519004327392&w=2

Короткий текст про hardened malloc из openbsd, и как он помогает отлавливать ошибки:

"I'm happy to say two of the more complex ones are (being) fixed: one turned out to be a reference counting bug in firefox. See http://undeadly.org/cgi?action=article;sid=20230912094727

The other, a write after free that crashed the X server when running picard was diagnosed by me. This one was a bit nasty, as it required instrumenting malloc to print some extra info to find the root cause.

The bug is that the call in https://github.com/openbsd/xenocara/blob/master/xserver/Xext/xvdisp.c#L1002 overwrites the first 4 bytes of the chunk next to the one allocated on line 995"

И, попутно, текст про внутренности SCUDO (тоже hardened malloc, используется в Android) - https://trenchant.io/scudo-hardened-allocator-unofficial-internals-documentation/