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

Пишут, что нового кода в Android на Rust становится больше, а на С(и, в меньшей степени, на С++) - меньше.

Это, конечно, очень хорошо.

Думаю, вы уже знаете мою точку зрения, что, с точки зрения безопасности, современный С++(с RAII, контейнерами, и санитайзерами), на практике не сильно опаснее Rust(хотя Rust, конечно, сильно более хайповее!), но вот писать новый системный код на С - так себе идея.

Если честно, то мне, конечно, жаль, что гонку с С выиграл не С++, но и так неплохо получается.

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

И вторая забавная новость.

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

"Услугами FossHost пользовались такие открытые проекты, как GNOME, KDE, GNU Guix, Xiph.Org, Rocky Linux, Debian, OpenIndiana, Armbian, BlackArch, Qubes, FreeCAD, IP Fire, ActivityPub (W3), Manjaro, Whonix, QEMU, Xfce, Xubuntu, Ubuntu DDE и Ubuntu Unity. "

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

Для души можно держать копию и даже мастер на небольшом хостинге, но 1 копия, из которой люди строят реальные пакеты, должна быть на большом хостинге.

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

Вытащу из комментариев.

https://crates.io/crates/fake-static

Баг в компиляторе Rust(висит с 15 года), позволяющий, без применения unsafe, произвольно менять lifetime.

Рекомендуется не использовать в проде! В целом, я всем тоже советую не использовать SEGFAULT в проде, да.

https://daniel.haxx.se/blog/2022/12/06/faster-base64-in-curl/

Тут вот автор curl решил похвастаться, как он ускорил свою же реализацию base64, в xy раз(даже не процентов!).

С точки зрения perf инженегра, это все, конечно, очень слабо:

* Нужно было не велосипедить, а соревноваться со state of the art, хотя бы https://github.com/lemire/fastbase64, или turbo base64.

* Соревновался он с линейным поиском символа в массиве 64 символов - "const char *p = strchr(base64, *s);"

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

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

Мы тут с коллегами выясняли, зачем вдруг antlr стал зависеть от abseil.

Раскопали красивое.

https://github.com/antlr/antlr4/pull/3694/commits/41beb8fe3540114943cb4ee93dafcc170f143c61

"[C++] Introduce synchronization and container abstractions"

А вот так выглядит "container abstraction":

#if ANTLR4CPP_USING_ABSEIL
#include "absl/container/flat_hash_map.h"
#else
#include <unordered_map>
#endif

Я не шучу.

Лучшее предположение - что Гугл занес в antlr, чтобы они, зачем-то, начали использовать велосипед от Гугла, вместо общепринятого класса.

Потому что этот леденящий душу пиздец из макросов я не понимаю как еще объяснить.

В контексте разработческих окружений.

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

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

Что у нас тут интересного?

* Автор пытается делать релоцируемые на fs проекты, вместо content based address. "Пакеты размещаются в отдельном каталоге ~/.tea и не привязываются к абсолютным путям (могут быть перемещены)" Это интересно, но прямо реально сложно, и я пока не нашел у него механизмов, отвечающих за то, чтобы это делать "просто".

* Мякотка, описание сборочного скрипта. https://github.com/teaxyz/pantry.core/blob/main/projects/deno.land/package.yml#L22 - вот это выглядит так себе. Я как-то рассказывал, во что я погружал свою сборку. В yaml я ее тоже погружал, это несложно, потому что большинство того, что я использую - это списки и конкатенация списков. Выглядело это примерно так, как в tea, по ссылке. Проблема с inline shell скриптами, они, на мой вкус, что в yaml, что в языке nix, выглядят херово.

* Довольно богатая метаинформация, например, он знает, что deno умеет интерпретировать javascript/typescript - https://github.com/teaxyz/pantry.core/blob/main/projects/deno.land/package.yml#L11 Это интересно, хотя, с ходу, непонятно, что он с этим делает.

https://www.phoronix.com/news/Linux-6.2-funsigned-char

Интересная (узким специалистам) новость, ядро Linux переходит на сборку с char == unsigned char по умолчанию.

Есть три возможных состояния:

* Везде signed
* Везде unsigned
* На разных платформах по разному

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

Наша монорепа фиксирует везде signed char, это nop на x86_64, и смена дефолта для linux-aarch64 (сюрприз, сюрприз, но там char unsigned по умолчанию).

В целом, я считаю, что unsigned по умолчанию лучше, просто потому что unsigned - это понятный тип, а signed - непонятное нечто. В нашей вселенной не бывает отрицательных чисел так-то! Но, если ты не контролируешь всю кодовую базу(например, тащишь код извне в contrib/), то unsigned char весьма сложно, если вообще не невозможно, пофорсить.

Пожелаем удачи ядру Линуса, особенно вспоминая его способ бороться с багами - https://en.wikipedia.org/wiki/Linus%27s_law

(TL;DR - падать и коркаться будет на наших компах)

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

**: про один такой забавный случай - в следующей серии!

Пост для комментариев (а вдруг). В первый раз вижу такой интересный пост, который имеет ссылку на комментарии в оригинальном канале.

Продолжаю писать и улучшать документацию.

https://github.com/pg83/ix/blob/main/docs/KERNEL.md

Вот, буквы про сборку ядра. Пока на русском, лучше, чем ничего! Кстати, проект (с радостью!) примет помощь в переводе текстов!

Ну, за эйчаров. И всех, кто пытается давать тесты соискателям.

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

"Я прогнал его через тест, который мы обычно выдаем собеседуемым. Там ничего военного, обычная задачка на понимание принципов ООП и Питона.

Эта сволочь написала его почти идеально. Причем не так, как это бы сделал джуниор, а с пониманием тонкостей и очень компактно. Я сам, когда придумал этот тест и прошел его, был более многословен.
Была там и пара моментов, к которым можно было придраться, но эта сволочь исправила их после первой же моей просьбы, причем я сформулировал претензии только общими словами. В общем, такого кандидата я бы взял на работу не задумываясь. Что наводит на размышления. Скорее всего, придется придумывать другие тесты"

Спасибо, Саша.

Обещанное про signed char vs. char vs. unsigned char

Есть такая программа - ragel. Она довольно известна узкому кругу коллег, используется для компиляции регулярок в state machine для целевого языка.

И есть в ней такой файлик - https://github.com/mikkelee/ragel/blob/ragel-6/ragel/common.cpp#L28, а в нем - перечисление всех целочисленных типов на машине, с диапазонами их значений.

Причем, что важно, char идет раньше unsigned char!

Я не буду давать ссылку на место конкретного использования, но оно используется так:

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

linux-aarch64 - char == unsigned char, на linux-x86_64 char == signed char. char в этой табличке стоит раньше всех.

Поэтому ragel, скомпилированный для host == aarch64, берет в качестве базового типа char, а на x86_64 - unsigned char!

Таким образом, сгенерированный файл зависит не от target системы, а от host системы, для которой был скомпилирован ragel.

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

А, ну и еще, автор ragel сошел с ума, и для разработки седьмого рагеля запилил свой язык программирования - http://www.colm.net/open-source/colm/!

Я, к сожалению, не настолько заинтересован в седьмом рагеле, чтобы заниматься бутстрапом этого говна, потому что, в лучших традициях, colm использует ragel для токенизации, а как еще?

Я тут понял, что мне в системе больше симпатичны бинарники на Go, нежели на Python.

Это довольно долго было каким-то "подспудным" ощущением, но я решительно с ним разобрался!

TL;DR - меня напрягает модель работы с внешними библиотеками (особенно с гуевыми) как с фабриками.

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

И, когда ты линкуешь статически слинкованный бинарь с питоном и всеми нужными модулями, ты в этот бинарь тянешь literally все символы из gtk/qt, wayland, opengl, драйвера видеокарты, и так далее.

Компилируемая программа со стадией линковки выкинула бы к херам 3/4 всех доступных символов, и оставила бы только нужное.

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

Отладили с коллегой процедуру установки и сборки ядра.

Видео - уже после boot в систему, в момент пересборки всего мира, из свежеустановленного stalix.

А ведь это мог быть ты, %username%!

Воскресный #rant.

Увидел в потоке обновлений программу под названием codelite https://codelite.org/, и решил собрать ее.

Оченно удивился, когда обнаружил, что ее tgz занимает порядка 100 мегабайт.

Быстрые раскопки показали:

pg-> find . -type f -name '*.a'
./sdk/curl/lib/libcurl.a
./sdk/libssh/lib/libssh.dll.a
./sdk/libssh/lib/osx/libcrypto.a
./sdk/libssh/lib/osx/libssh.a
./sdk/libssh/lib32/libssh.dll.a
pg-> find . -type f -name '*.dylib'
./sdk/hunspell/lib/osx/libhunspell-1.3.0.dylib
./sdk/lldb/osx/lib/liblldb.10.0.0svn.dylib
pg-> find . -type f -name '*.dll'
./Runtime/msys-1.0.dll
./Runtime/pthreadGC2.dll
./sdk/curl/lib/libcurl-4.dll
./sdk/libssh/lib/libssh.dll
./sdk/libssh/lib/libzlib.dll
./sdk/libssh/lib32/libssh.dll
./sdk/libssh/lib32/libzlib.dll
pg-> find . -type f -name '*.exe'
./CxxParser/sed.exe
./Runtime/File2Hex.exe
./Runtime/mkdir.exe
./Runtime/patch.exe
./Runtime/rm.exe
./codelitephp/bin/bison.exe
./sdk/astyle/bin/AStyle.exe
./sdk/clang/lib/clang-format-64.exe
./sdk/clang/lib/clang-format.exe
./universal-ctags/win32/codelite-ctags.exe

Я, конечно, перед сборкой все это говно подчистил, потому что нефиг тянуть за собой всякое:

https://github.com/pg83/ix/blob/main/pkgs/bin/codelite/ix.sh#L30

После такого аккуратного strip оно при установке начало выдавать ошибку, что, мол, не может скопировать какой-то файл на положенное ему место.

Я, почуяв недоброе, пошел смотреть, что происходит:

https://github.com/eranif/codelite/blob/master/universal-ctags/CMakeLists.txt#L11

И, да, этот господин, ничтоже сумняшеся, прикопал какой-то бинарник прямо в репу, и копировал его в host систему. А я его удалил, и обломал всю малину/

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

А почему бы не прикопать сразу готовый бинарник codelite, и не тратить время на сборку, нуачо?

#bs #vendor

https://www.phoronix.com/news/Meson-1.0-RC1

Вот, пожалуйста, #meson хвастается поддержкой Rust.

Писал, и буду писать, что так делать не надо, и надо иметь мета-package manager, типа nix/guix/ix.

Основной массив аргументации тут - https://t.me/itpgchannel/252

Классного текста про IT сегодня не будет, потому что я писал классную доку про IX package manager - https://github.com/pg83/ix/blob/main/docs/IX.md!

Ну и продолжал улучшать и углублять документацию по stal/IX, https://github.com/pg83/ix/tree/main/docs.

Инсталлятор, помимо меня, смогло осилить уже два человека, даже со сборкой ядра на реальном железе, и поддержкой 3D на встройке от Intel, чего я сам никогда до этого не делал!

Продолжение темы про "героическое изобретение всем известных контейнеров в C" - https://www.phoronix.com/news/Linux-6.2-Modules

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

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

Все эти связанные списки в С, все эти *get_property* в GTK программах, которые написаны в стиле

if (strcmp() == 0) {return ...}
if (strcmp() == 0) {return ...}

Я прекрасно понимаю, почему написано именно так - потому что легко добавить еще один элемент, и не надо беспокоиться за память. Но когда пропертей становится больше 100?

Ну и да - по ссылке - замена прохода по связанному списку с таким вот strcmp() на дерево, с огромным ускорением в 1000х раз!

Проблема в том, что, пока выпилили 1 список, в ядро впилили еще 100. Такими темпами, конечно, работы хватит навсегда.

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

Давненько не было ссылок на мою любимую тему про инфраструктурные площадки. #provider #yeswecan

"Как сообщает Fox News, новый глава Twitter полностью распустил консультативную группу по безопасности, которая модерировала спорный контент и состояла из почти 100 экспертов по правам человека"

"С самого начала многомиллиардной сделки по приобретению Twitter господин Маск заявлял: он намерен наконец дать ее пользователям возможность «свободно говорить в рамках закона», а не подвергаться излишней цензуре"

Инфраструктура должна жить по четким внешним правилам, и подвергаться внешнему аудиту, а не сотней sjw-активистов.

UPD: Маск тут будет ничуть не лучше, чем предыдущие, только с уклоном в другую сторону. https://t.me/hn_best_comments/15495

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608387.html

В gcc вмержили gccrs (rust frontend).

Выглядит это всrustо, потому что я никогда не видел, чтобы такой сырой продукт вмерживали бы в mainline gcc.

Ну, то есть, по мощщи эта поделка пока не дотягивает даже до #mrustc, который в состоянии бутстрепнуть современный компилятор Rust.

gccrs, насколько я понимаю, не умеет даже такого (Я не прав? Поправьте!)

Короче, какое-то странное, наверное, политическое, решение.