Исследование производительности разных дистрибутивов Linux.

https://www.phoronix.com/review/intel-arrowlake-cachyos/5

Разница между самым быстрым, и самым медленным Linux - порядка 5%, разница между двумя лидерами CachyOS (основан на Arch), и Arch - порядка процента.

По мне так "овчинка выделки не стоит".

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

#selfhost

"Опубликован корректирующий релиз платформы совместной разработки Gogs 0.13.2, в котором устранено 6 уязвимостей. 5 уязвимостям присвоен критический уровень опасности (10 из 10). Исправленные проблемы позволяют непривилегированному пользователю Gogs выполнить код на сервере, изменить данные в репозиториях других пользователей или получить SSH-доступ к серверу"

Проект (git хостинг) написан на memory safe языке (нет, не на том, на другом), поэтому ошибки про обработку "../" в путях.

Мораль?

* Не надо поддерживать свою васянскую инфру (#gitlab #infra), а надо брать, и использовать github.

* По мере переписывания с С/C++ на memory safe языки, CVE меньше не будет, потому что безопасники тоже хотят кушать, просто искать их будут в других местах, возможно, поиск станет чуть дороже.

Пара перлов с opennet, от расто-любов/хейтеров:

"Не понимаю почему такие критически важные для инфраструктуры программы еще не переписали на расте. Неуженли люди осознанно отказываются писать программы без ошибок и приближать цифровой коммунизм?"

"Потому что Раст рекламируют нейросети для компаний, которым нужны новые хомячки-погроммисты за миску риса. Сишник ещё имеет некоторую свободу выбора"

"А вот будь оно на Си..."

Оказалось, у этой задачи есть вполне понятное решение (https://www.tgoop.com/itpgchannel/2543?comment=41578)!

"промоутим джуна в техлида, сами уебываем в стартап в ОАЭ, в американский визу не дают" (новый техлид тащит блокер, релиз, и себя)

Но зачем?

https://www.phoronix.com/news/Hash-Based-Integrity-Linux-RB

"Introduce a new mechanism to ensure only well-known modules are loaded by embedding a list of hashes of all modules built as part of the full kernel build into vmlinux"

Сначала героически создали себе проблему (модули), потом героически ее же и решаем.

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

Я понимаю, какую задачу решали модули 30 лет назад (экономия памяти), а сейчас что? Сейчас все модули и так лежат в initrd, который целиком грузится в память (потом, наверное, очищается, но так можно сделать и в случае включения модулей в ядро).

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

Рубрика "новости из дурки".

Еще один альтернативный броузер, some highlights:

* Написан на С, и на FixScript (язык от того же автора).

* GUI toolkit - GTK2 (GTK2, Карл!!!)

* Вместо javascript - набор регулярок, которые фиксят сайты так, что они могут как-то отрисовываться без JS. 1200 сайтов уже поддержано!

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

У #ghostty случился релиз.

Доставляет способ тестировать производительность терминала (нет, реально, все как у великих - https://www.tgoop.com/itpgchannel/306):

"В проведённых тестах Ghostty оказался быстрее эмуляторов терминала iTerm и Kitty в 4 раза, а Terminal.app - в 2 раза, при выводе на экран содержимого большого файла, например, при помощи команды "cat big_file.txt". При сравнении с Alacritty производительность Ghostty была примерно на том же уровне, но Alacritty отстаёт по функциональности от Ghostty"

В общем, пока эталонное "не нужно".

#terminal

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

https://github.com/pg83/ix/blob/main/pkgs/bld/rust/helpers/patch/bindgen/patch.sh#L11-L14

cat << EOF > .../clang-sys/build/static.rs
pub fn link() {
}
EOF

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

Работает, как часы!

Буррито "рекурсивный"

Кстати, про рекурсию.

Читал тут исходники https://github.com/meyfa/CobolCraft/

Это такой сервер minecraft, но на Cobol.

А я раньше код на Cobol особо не читал, потому что зачем?

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

В Cobol из коробки нет рекурсии! Вы знали? Я не знал.

Вообще, конечно, есть, если через жопу, и со странностями, но не рекомендуется:

https://www.ibm.com/docs/en/cobol-zos/6.3?topic=subprograms-making-recursive-calls

https://stackoverflow.com/questions/27806812/in-cobol-is-it-possible-to-recursively-call-a-paragraph

Судя по ссылкам, рекурсивный вызов без явного на то объявления - это что-то типа местного UB. Наверное, связано это с тем, что в программе нет стека.

Впрочем, зачем рекурсия в языке, которым выставляются счета на оплату?

https://www.ryanliptak.com/blog/every-rc-exe-bug-quirk-probably/

https://github.com/squeek502/resinator

Чувак запилил альтернативный windows resource compiler. Это такая штука, которая позволяет включать в выполняемый файл иконки, и прочую лабуду.

Зачем?

Потому что все предыдущие open source реализации (windres от GNU, llvm-rc от LLVM, и какая-то еще) обладали фатальным недостатком - были написаны не на Zig Нет, реально, они все не совпадают с оригинальным rc.exe в каких-то краевых случаях.

Тут, конечно, интересен подход, с которым коллега подступился к этому "говну мамонта" "от дидов" - а давайте пофаззим новую реализацию до тех пор, пока не перестанет падать функция if (new(input) != rc.exe(input)) { abort(); }. Заодно получим корпус всяких смешных ошибок, и странностей оригинального rc.exe.

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

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

PS: оказывается, коллега уже про это писал, а я и не заметил - https://www.tgoop.com/gepardchan/151

If you'd like to skip around and check out the
strangest bugs/quirks, Ctrl+F for 'utterly baffling'

https://mostlynerdless.de/blog/2024/09/10/hello-ebpf-writing-a-linux-scheduler-in-java-with-ebpf-15/

Я в растерянности, потому что, с одной стороны, это годный текст про еще один userspace scheduler, на основе #sched_ext/#ebpf, а с другой - явный (pun intended) кандидат в серию "новости из дурки", потому что писать userspace scheduler на Java - это, конечно, за гранью.