Spent an hour or so working with claude to write a minimal static web server in COBOL


Comments  on lobsters

https://xn--r1a.website/itpgchannel/3273 - а про COBOL я ошибся, надо признать!

От подписчика:

"И финальный прикол:
Отгадайте, что возвращает этот сервер по урлу - http://localhost:8080///etc/passwd ;)"

https://github.com/jmsdnns/webbol/issues/1

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

"Расширена возможность отправки содержимого core-дампов через сокет AF_UNIX, позволяющая создавать в пространстве пользователя более безопасные обработчики core-дампов, не завязанные на вызов ядром привилегированных процессов. В новой версии добавлен протокол для создания серверов, способных управлять обработкой core-дампов на уровне отдельных задач. Например, для одних процессов можно игнорировать core-дампы, а для других передавать их через сокет. Отдельно подготовлен прототип сервера для управления core-дампами (*)"

Джвадцать лет этого ждал!

(*) На "#almost_memory_safe", а как же.

Будни #bootstrap

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

Cделал все максимально по рабоче-крестьянски - упаковываю в initrd все содержимое bin/ из system #realm, то есть, чтобы в initrd были доступны тулзы для btrfs, надо сделать ix mut system bin/btrfs/progs. Вроде как лишнее дублирование, но зато все максимально прозрачно. Так же в system realm требуется наличие исполняемого файла bin/initrd, который и должен сделать весь heavy lifting - https://github.com/pg83/ix/blob/main/pkgs/set/pg/system/initrd/ix.sh. Никакой помощи от меня, в данный момент, для написания этого файла, нет.

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

Например:

* кто-то пишет, что ядро загружает /sbin/init из initrd, кто-то - что /bin/init, а на самом деле - просто /init

* я долго не мог понять, почему не работает pivot_root для подмены корневой fs, пока не прочел вот этот текст - https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt:

"When switching another root device, initrd would pivot_root and then umount the ramdisk. But initramfs is rootfs: you can neither pivot_root rootfs, nor unmount it. Instead delete everything out of rootfs to free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs with the new root (cd /newmount; mount --move . /; chroot .), attach stdin/stdout/stderr to the new /dev/console, and exec the new init.

Since this is a remarkably persnickety process (and involves deleting commands before you can run them), the klibc package introduced a helper program (utils/run_init.c) to do all this for you. Most other packages (such as busybox) have named this command "switch_root""

Ну да, ну да, кто бы мог подумать?!?

Electronic Arts to be acquired for $52B in largest private equity buyout
Article, Comments

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

Кажется, в сообществе #nix снова начинается какое-то бурление #nixgate

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

Ну и новость немного сбоку, раз речь зашла про CoC.

Эрик Реймонд призывает отказаться от CoC, потому что вреда больше, чем пользы - https://www.opennet.ru/opennews/art.shtml?num=63968

Не могу с этим не согласиться.

#llvmweekly

https://discourse.llvm.org/t/our-ai-policy-vs-code-of-conduct-and-vs-reality/88300

TL;DR - нерадивые контрибуторы шлют в LLVM патчи, сгенерированные AI, плохого качества, даже не разбираясь в том, что AI написал. Что очень сильно отвлекает и так загруженных ревьюеров:

"I’ve been using AI to contribute to LLVM, which has a liberal policy.

The code is of terrible quality and I am at 100+ comments on my latest PR"

"In my experience, folks using AI do a much worse job at understanding their patch, and thus a much worse job at getting better over time. The amount of effort to make these contributors start making better contributions is so much more as to not be worth it anymore"

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

Годный текст.

Люди, например, пишут, что используют LLM для облагораживания своих текстов, особенно когда не являются native english speaker. Я тоже так часто делаю.

#llvmweekly

https://discourse.llvm.org/t/rfc-lightweight-fault-isolation-lfi-efficient-native-code-sandboxing-upstream-lfi-target-and-compiler-changes/88380

А вот это прямо крутая штука.

In process sandbox, реализованный с помощью компиляции в некоторое подмножество инструкций целевой ISA, которое гарантирует, что код не вылезет за пределы выданного ему адресного пространства.

Эдакий #WebAssembly, но с компиляцией в целевую архитектуру, а не в промежуточное представление. Или, если хотите, сильно более лайтовый asan (компиляция в код с bound check + рантайм).

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

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

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

Кодеки, конечно, в такую схему ложатся лучше.

От Google, поэтому есть шанс, что это реально проедет в upstream, и будет доступно всем желающим.

https://discourse.nixos.org/t/the-sc-prepared-to-lie-to-us-and-what-we-can-do-about-it-whistleblow/70103

Какие-то бездны SJW угнетения в #nixgate

📱 Блогеров обязали передавать права от Telegram-каналов боту Роскомнадзора

При регистрации и получении маркировки «А+» требуется запускать специальный бот и добавлять его в администраторы, сообщили в Роскомнадзоре. В ведомстве привели ссылку на подробную инструкцию.

Первый этап регистрации – подача заявления через портал госуслуг. Запуск бота предусмотрен вторым этапом. «Это единственный способ подтверждения для Telegram владения вами регистрируемым каналом», – отметили в Роскомнадзоре.

🔺Полученный на «Госуслугах» номер регистрации будет сверяться с введенным в бот. Как уточнили в ведомстве, его нельзя удалять из канала или лишать прав администратора.

📰 Подпишитесь на «Ведомости»

👤 Евстахий Эпилептик (источник: "ВЕДОМОСТИ")

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

Ой какая красота, лудший док портировали под Wayland!

https://dzen.ru/a/aN1RLqNCZnqR3keD

Верим?

Заметил тут в changelog:

"Для функционирования также требуется поддержка одного из Wayland-протоколов для управления окнами верхнего уровня (wlr-foreign-toplevel-management, plasma-window-management cosmic-toplevel-management)"

https://wayland.app/protocols/wlr-foreign-toplevel-management-unstable-v1
https://wayland.app/protocols/kde-plasma-window-management
https://wayland.app/protocols/cosmic-toplevel-management-unstable-v1

Реально, 3 способа сделать одно и то же, небось и для гнума есть похожее, но:

"Не поддерживается работа с композитным менеджером Mutter - Cairo-Dock не совместим с GNOME и не может применяться с рабочим столом, предлагаемым по умолчанию в Ubuntu Desktop"

И чтобы сложное приложение работало под все композиторы, надо реализовывать все 3 протокола, жесть какая.

Будни #bootstrap

Обновил llvm/clang/etc до версии 21.

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

Но, к сожалению, upver clang тянет за собой обновление spirv тулинга (это формат шейдеров vulkan), а обновление spirv тулинга тянет обновление vulkan, а обновление vulkan тянет с собой обновление mesa. Это не жесткое правило, но вот так оно обычно получается - старая #mesa перестает собираться против нового vulkan sdk.

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

Вот есть такая запчасть, https://github.com/KhronosGroup/SPIRV-LLVM-Translator.

Ее надо одновременно, со всем остальным стеком, обновить до версии 21.

Маленькая проблема заключается в том, что автор этой запчасти сошел с ума, и сказал, что ему нужен снапшот транка vulkan sdk, против которого он хочет собираться.

Ну, то есть, понятно, что произошло?

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

Обновление "встряло"...

В общем, в итоге я сделал странное #herobora - собрал только эту запчасть против нужной ему версии sdk (https://github.com/pg83/ix/blob/main/pkgs/lib/spirv/llvm/translator/21/impl/ix.sh#L23-L25), но использовал в составе стека, скомпилированного с нужной всем остальным версией sdk.

Мораль? Нет ее.

Помните, писал https://xn--r1a.website/itpgchannel/3356, что у GTK теперь Rust, как hard зависимость? #svg

Прилетел он на днях в stable, ну и ко мне, понятное дело.

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

Но, как обычно, решил почитать исходнички, я их всегда люблю почитать.

Номер раз - https://gitlab.gnome.org/GNOME/gtk/-/blob/main/meson.build?ref_type=heads#L495-498

Тут прям красивое - мы хотим опционально современную версию rsvg, НО, если ее нет, то мы соглашаемся на более старую! И, тра-та-та, какое совпадение - мы соглашаемся на самую последнюю версию, которая не требовала Rust для сборки - 2.40.23.

Номер два - https://gitlab.gnome.org/GNOME/gtk/-/blob/main/subprojects/librsvg.wrap?ref_type=heads#L5

Тут написано, что, если в системе нет librsvg, то мы себе соберем свою, причем ту самую, древнюю!

Номер три - https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gdktextureutils.c?ref_type=heads#L38-66

По всему коду есть ifdef для сборки с более старой версией!

Короче говоря, они там, в своем этом GTK, еще не совсем сошли с ума, и оставили возможность собираться без Rust, со старой librsvg.

Я, признаться, всплакнул от умиления, когда обновлял GTK на эту версию, такие они там хорошие ребята!