https://lzip.nongnu.org/xz_inadequate.html

Текст, в котором автор конкурента xz пытается обосновать, почему xz - "не очень".

Основательно, длинно, мне не понравилось:

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

* чувак весьма догматичен, и бросается словами "правильно", "неправильно", без попытки обоснования.

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

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

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

(задачка на bootstrap - доказать себе, что даже malicious attacker не сможет этим воспользоваться)

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

https://leahneukirchen.org/blog/archive/2024/04/what-autoconf-got-right.html

#autohell

Годный текст про autoconf, от коллеги блоггера мейнтейнера void linux.

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

* "Overrides are possible". В cmake они тоже есть, но не стандартизированы, и работают не всегда ожидаемым образом. В meson это, вообще говоря, боль, потому что там ничего заоверрайдить нельзя, или я не нашел, как, поэтому если попадается какой-то всратый configure test, приходится патчить сборочные файлы.

* "The config.log tells what happened" В meson/cmake лог конфигурирования - это тихий ужас, чаще всего по нему невозможно понять, что же пошло не так.

С чем-то не согласен:

* "There is support for cross-compiling and for host/target separation". Как я уже когда-то писал, в autohell/cmake нет нормальной поддержки кросс-компиляции. #cross В meson немного лучше, там есть отдельные графы для host/target сборок, и можно проверять host свойства системы отдельно. Autohell, в лучшем случае, не мешает кросс-компиляции, cmake - просто вредит ей https://xn--r1a.website/itpgchannel/132.

* "It has few runtime dependencies" - это просто полуправда. Для запуска configure достаточно shell, но для его регенерации нужен m4/perl, а это уже очень и очень много. С точки зрения supply chain attack configure скрипты, конечно, надо всегда перегенерировать, как показал опыт проекта #xz_gate https://xn--r1a.website/itpgchannel/1789.

https://lobste.rs/s/ebnqzl/what_autoconf_got_right

https://blog.dshr.org/2021/03/history-of-window-systems.html
http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm

"История оконных систем", показанная в виде противопоставления двух разных точек зрения:

* на сервер нужно слать данные, которые будут отрисованы оконной системой. Данные - не обязательно пиксельные карты с готовых изображением. Примитив DrawLine(x1, y1, x2, y2) - это тоже данные. Модель ограничивает количество доступных примитивов, которые можно послать на сервер.

* на сервер нужно слать программу, которая может быть проинтерпретирована на стороне сервера, и, в процессе интерпретации, порождать готовое изображение. Например, так работает (а все еще работает?) графическая подсистема macos (там внутре используется PDF, а раньше - display postscript). Или какой-нибудь postscript printer. КМК, это довольно интересная тема, у меня в голове уже лет 10 крутится мысль "а не запилить ли оконную систему, которая бы принимала lua программу, которая бы занималась отрисовкой". Сейчас, конечно, это была бы не lua, а WebAssembly, но сути это не меняет.

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

https://awesomekling.substack.com/p/forking-ladybird-and-stepping-down-serenityos
https://www.opennet.ru/opennews/art.shtml?num=61301

ВНЕЗАПНО автор #ladybird, он же автор SerenityOS, пришел точно к таким же заключениям, только немного с другой стороны - ему надоело велосипедить код в SerenityOS только для того, чтобы продолжать пилить под него Ladybird, поэтому он отправил SerenityOS в свободное плавание, и сказал, что теперь основной target для Ladybird - это Linux.

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

xxx:
это нормально - когда в линуксе что то через жопу приходится делать - то линуксоидам это не нужно

yyy:
Еще раз объясняю принципы СПО.
Видишь голую жопу - сшей трусы и отдай владельцу жопы.
Не умеешь шить - сообщи владельцу жопы, где трусы можно купить.
Не знаешь где купить - просто скажи владельцу жопы "А у вас жопа голая!".
Не хочешь делать ничего из предложенного - заткнись, не твое дело.

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

Вышла новая версия самого лучшего frontend к LaTeX.

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

Думал, оно умерно, а вот нет, не умерло.

Годная вещь.

https://gitlab.freedesktop.org/1

gitlab от freedesktop лежит проходит техосмотр уже второй день. А я даже и не заметил, потому что распределенный кеш исходников.

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

Проклятый #ddv написал пост про то, как в sr.ht все было плохо, но теперь, просто обязательно, будет хорошо!

https://sourcehut.org/blog/2024-06-04-status-and-plans/

Почему хорошо?

* Kubernetes (self managed, ага)

* Ceph (self managed, AFAIK)

* GraphQL

Есть какие-то интересные цифры про текущую инфраструткуру (10 EOL серверов общей стоимостью 50к, очень странно и дорого, за EOL сервера. Может, дисков туда напихали много)

В общем, хорошо, что у меня на этом васянском хостинге больше ничего нет.

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

Витриной, конечно, останется github.

Коду #Kent веры нет.

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

Иначе я не могу объяснить, что у меня bache (не путать с bcachefs) cli падает в кору:

Jun  4 09:56:33 lab1 user.notice dmesg: [   36.169640] bcache[1182]: segfault a
t 8 ip 00000000002ab8ea sp 00007ffefda1a460 error 4 in bcache[236000+94000] lik
ely on CPU 5 (core 5, socket 0)
Jun  4 09:56:33 lab1 user.notice dmesg: [   36.170440] Code: b6 80 10 81 21 00
41 21 c0 41 83 f8 01 b8 02 00 00 00 83 d8 00 5d c3 cc cc cc cc cc cc cc cc cc 5
5 48 89 e5 41 56 53 48 89 fb <8b> 7f 08 e8 8e bb 01 00 41 89 c6 48 89 df e8 c3
d2 01 00 44 89 f0

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

Ну такое.

#lab #home_lab

https://xn--r1a.website/itpgchannel/1827
https://xn--r1a.website/itpgchannel/1887

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

Тополиный пух, жара, и вот это вот все.

Первый датацентр приходится отключать, так как не выдерживает кондиционирование. Дело дошло ажно до того, что слетел контроллер SATA (правда, после охлаждения и парочки ребутов снова поднялся).

С другой стороны, два других датацентра справляются с CI на ура, #minio/etcd, вроде, тоже работают, но уже без запаса.

Принудительные учения, ага.

От следующей новости у меня глаза полезли на затылок, потому что как такое вообще может быть?

https://www.phoronix.com/news/STF-GNU-libmicrohttpd

300к на развитие libmicrohttpd.

Слышали про такую библиотеку?

Правильно, и никто не слышал, потому что клиентов у нее всего ничего - https://archlinux.org/packages/core/x86_64/libmicrohttpd/ И это несмотря на 15+ лет разработки.

Клиентов у нее нет, потому что:

* это встраиваемый http server
* под лицензией LGPL
* мало фич (http/2, http/3 - не, не слышали)

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

Но фонд, который выдал грант, пишет, что пользователей довольно дофига:

https://www.sovereigntechfund.de/tech/libmicrohttpd

"Thousands of projects and businesses use libmicrohttpd, including NASA (Earth Observation satellite data distribution), Sony televisions, security cameras, medical testing laboratories, and numerous Free Software projects. To name just a few: GNUnet, Kodi, GNU Taler, Retroshare, P4P Portal, Gnome Music Player Client CallHome, Open Lighting Architecture, and systemd (journal gatewayd)" (ого какие проекты! про некоторые я даже слышал!)

Я не знаю, есть большое количество встраиваемых http серверов, написанных на более безопасных языках, чем C (Rust/C++). Вот, надо брать сишный биндинг к такой библиотеке (желательно, идущей под MIT/Apache2), и не связываться с поделием от GNU никогда.

Наверное, распил какой-то, или я ничего не понимаю в этой жизни.

Про acme.sh, эксплойты и костыли

Случайно наткнулся на
https://github.com/acmesh-official/acme.sh/issues/4659
(кстати, этот issue открыли ровно год назад 🎉)

История очень эпичная:
- какая-то китайская компания занимается перепродажей сертификатов и захотела сделать бесплатную автоматическую выдачу сертификатов через ACME, как Let's Encrypt
- но увы, сама компания не являются CA и не может выписывать сертификаты, поэтому полностью протокол ACME реализовать не может
- вместо этого китайцы используют RCE-эксплойт (оно же — удаленное выполнение произвольного кода) в acme.sh, который позволяет им вставить костыль в процесс выдачи сертификата. При этом они никакого вредоносного кода у клиентов не исполняют (скорее всего), но варварски эксплуатируют страшную дыру в безопасности
- клиентов, конечно же, просят юзать только acme.sh для выписывания сертификатов
- через некоторое время эта вся история с эксплойтом вскрывается, и появляется issue на гитхабе (ссылку на который я уже давал в самом начале поста)
- далее китайскую компанию, по всей видимости, жестко DDoS'ят (что можно узнать из комментов к issue)
- потом в issue приходит представитель этой самой компании и жалуется, что (далее прямая цитата, орфография сохранена)

we provides HiCA for non profit purpose, to provide ssl for free (RSA). We even donated 1000 USD to acme.sh last year to support the community developers, Except us any CA or reseller did this?

и сообщает, что

finally, we closed HiCA project and keep this before the community investigation finished.

- дыру с RCE, конечно же, в конце концов поправили

Мораль всей этой истории мне придумывать лень, оставлю это в качестве упражнения читателям 🐳 Могу лишь сказать, что использовать уязвимости для того, чтобы что-то закостылить или обойти — не самая удачная идея :)