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

Первый сетевой драйвер на #Rust в ядре. https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=cbe0e415089636170aa6eb540ca4af5dc9842a60

Ажно 135 строк кода, 134 из которых - взаимодействие с остальным ядром, ничего интересного, проходим мимо.

Зато классный срачик на похорониксе - https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1429237-the-first-rust-written-network-phy-driver-set-to-land-in-linux-6-8

Коллеги спорят, можно ли писать "боевой" код на С, или нельзя.

Это, очевидно, instance of https://ru.wikipedia.org/wiki/%D0%9D%D0%B8_%D0%BE%D0%B4%D0%B8%D0%BD_%D0%B8%D1%81%D1%82%D0%B8%D0%BD%D0%BD%D1%8B%D0%B9_%D1%88%D0%BE%D1%82%D0%BB%D0%B0%D0%BD%D0%B4%D0%B5%D1%86, поэтому принимать участие в этом обсуждении я не вижу никакого смысла, только скажу, что писать надежный код на С - запредельно дорого.

https://github.com/CuarzoSoftware/Louvre/releases/tag/v1.1.0-1

Чувак прямо как услышал меня:

License updated from GPLv3 to MIT.

Еще одна причина посмотреть на библиотеку внимательнее.

#llvmweekly

https://github.com/llvm/llvm-project/commit/f7407411a1da

Прикольная оптимизация для deque-подобных контейнеров (это когда контейнер состоит из указателей на сегменты, в которых уже и хранятся реальные элементы) - а давайте std::find будет работать не через ++it (который очень дорогая операция, потому что надо проверять, не в конце ли мы сегмента, и прыгать в начало следующего), а как бы знать, что контейнер состоит из сегментов, и поиск внутри сегмента делать более эффективно.

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

.

https://lwn.net/SubscriberLink/954787/41470c731eda02a4/

#gccrs

rust in gcc стагнирует, и далек даже от того состояния, в котором сейчас находится #mrustc. mrustc уже умеет в 1.54, а вот эти вот товарищи пытаются в 1.49, да и то, там конь еще не валялся.

https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=GCC+Rust+Update.pdf

Пролистал слайды про устройство proc macro в gccrs, смерть смерть кладбище, тоска, они собираются точно так же динамически линковать и загружать .so, как это сейчас делает rustc.

А, значит, они мне совершенно бесполезны.

https://www.opennet.ru/opennews/art.shtml?num=60317
https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/

"Использование SSH поверх UNIX-сокета вместо sudo для избавления от #suid-файлов"

Видимо, это не такое уж и безумие, раз пришло в голову не только мне?

(напомню, что я ровно в таком setup живу с самого первого boot в #stal/#ix, по модулю того, что так и не удосужился настроить UDS, вместо сетевого порта)

Тут вот в тележеньке появилась кнопка "похожие каналы". Ну или не появилась, а я просто слоупок.

Вот, два самых похожих на мой канала.

Мне тут почему-то вспоминается анекдот про ВМиК:

- Подскажите, как пройти до ВМК?
- Это где-то между МехМат-ом и цирком, немного ближе к цирку!

https://nickb.dev/blog/the-dark-side-of-inlining-and-monomorphization/ #perf

Зумеры, в очередной раз, переизобретают и переописывают то, что всем заинтересованным людям давно известно - чрезмерный inline-инг (современное его название - мономорфизация, но кому какое дело?) - не только полезно, но и очень вредно.

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

#terminal #rant

https://www.jeffquast.com/post/ucs-detect-test-results/
https://ucs-detect.readthedocs.io/results.html

Монументальный текст (от автора python wcwidth) про то, как разные терминалы работают со всякими "странными" unicode последовательностями.

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

Unicode, в попытке объять необъятное (== унифицировано описать все разнообразие способов передать символьную информацию), идет куда-то не туда.

Вот раньше все было просто - 1 char == 1 клетка на экране (может быть, разной ширины, если не monospace). Потом стало сложнее, разных символов стало настолько много, что они перестали влезать в 1 байт, потом в 2. Были изобретены разные транспортные кодировки, типа utf8, но внутри лежал все тот же самый 4-байтный codepoint.

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

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

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

Как нужно?

1) Нужно пытаться перестать запихнуть в Unicode всякого рода symbol of the day, типа анимированной какахи.

2) Нужно сказать, что терминал - он не для вывода произвольного Unicode текста, а только для такого текста, который имеет разумное (две клетки на символ - неразумное, усложняет вообще все в разы) погружение в концепцию клеток фиксированной ширины. Для всего остального есть браузер.

(я, например, даже не расстроюсь, если в терминале останется только первые 128 символов из ASCII, но, врочем, я и полезность юникодных имен файлов до сих пор не очень осознал)

https://github.com/systemd/systemd/pull/30547 #suid

"add new "uid0" command as alternative multi-call interface for systemd-run, as sudo replacement #30547"

Ну, все, идея пошла в main stream.

Даже, знаете ли, немного обидно, потому что -1 selling point, и уже нельзя сказать про почти любой пакетный менеджер что-то в стиле "а, это там, где еще не вычистили suid бинари с fs", и презрительно покривить носом.

Терпеть не могу статьи в стиле псевдомонолога персонажей в чьей-то там голове, но, тем не менее, свежий подход к тому, как можно сопрягать go с другими компилируемыми языками, минуя cgo:

https://xeiaso.net/blog/carcinization-golang/

TL;DR - конпелируете библиотеку на Rust в #WebAssembly, и загружаете ее в Go через #wazero (pure go #WebAssembly #WASM #WASI runtime)

Что нам это дает? Нам это дает:

* безопасную песочницу
* без ограничений cgo (типа выполнения в отдельно выделенных потоках, и всякое такое)

(это отличается от ранее представленных способов, типа конпеляции всего в WebAssembly, и объединения через WebAssembly VM)

Понятное дело, что тут у нас в полный рост startup/warmup cost, и все, что с этим связано, но способ довольно интересный.

Subscriber's submission

Решил посмотреть, сколько займет времени переписать мои экзерсизы с #qtile (https://xn--r1a.website/itpgchannel/1437, потому что проект, кажется, мертв, мой патч там не то что не мержат, а даже и не смотрят - https://github.com/qtile/qtile/pull/4568), скажем, на #hyprland

Вот, полюбуйтесь, N-Stack layout буквально за копейки 2000 строчек довольно сложного кода - https://github.com/zakk4223/hyprNStack/blob/main/nstackLayout.cpp

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

Подожду, пока проект хоть немного подрастет, ну или поищу какое-нибудь другое место, куда можно встроиться.

#llvmweekly

https://github.com/llvm/llvm-project/commit/9783f28cbb15

Чуваки взяли, и применили clang-format на всю libc++. Респект, уважуха, поменьше бы проекты дрожали над историей, и не ссали переформатировать код для удобства чтения.

#fast_python

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

А вот, пожалуйста, новый-кленовый JIT для python.

Вот цифры про perf:

"По сравнению с традиционным JIT-инструментарием (LLVM -O0) предложенный JIT обеспечивает в 100 раз более быструю генерацию кода и на 15% более быстрый результирующий код. По сравнению с компиляцией в WebAssembly (Liftoff) новый JIT генерирует код в 5 раз быстрее, а результирующий код работает на 50% быстрее. Если сравнивать новый JIT с оптимизирующим JIT (LuaJIT), использующим вручную написанный код на ассемблере, то предложенный вариант оказался быстрее в 13 из 44 тестах, а в среднем отстал по производительности на 35%, при существенном упрощении сопровождения и уменьшении уровня сложности реализации"

Конечно, с использованием LLVM, но, что интересно, LLVM нужен только в момент сборки самого JIT, но не в runtime.

Если что-то такое попадет в mainline, то это будет счастье.

Две ссылки, которые особенно хороши вместе.

https://www.opennet.ru/opennews/art.shtml?num=60360
https://www.theregister.com/2023/12/27/bruce_perens_post_open/

Некто Брюс Перенс, известный oss склочник (https://xn--r1a.website/itpgchannel/145, известен он тем, что пытается нажиться на несуществующем коде, а, конкретно, на busybox, несмотря на то, что его кода там - закрывающие фигурные скобочки), решил, что существующие OSS лицензии не позволяют ему достаточно хорошо наживаться на несуществующем коде, и придумал какого-то очередного кадавра, который должен позволить перераспределить деньги от коммерческих компаний в его кошелек гармонизировать сосуществование коммерческих компаний с ним.

О как.

Для этого предлагается запилить какую-то новую лицензию, код по которой можно использовать, если ты прошел аудит в какой-то третьей компании/фонде, которые авторизованы делать такой аудит. Например, если они принадлежат Перенсу. И раз в год, все желающие использовать софт под этой лицензией, должны проходить такой аудит. А для этого они должны или участвовать в разработке OSS софта, или платить "куда надо" денег.

Там, где есть перераспределение чужого, там всегда есть и злоупотребление, как мы это все прекрасно понимаем. Поэтому понятно, что это влажные мечты, и они не имеют никакого отношения к реальности. Потому что настоящие игроки, стейкхолдеры, которые пишут 95% oss софта, под это никогда не подпишутся, так как они этот софт пишут не для "прямого" зарабатывания на этом софте денег (вот как Гугл пишет свой Хром, например)

И вторая ссылка - https://www.opennet.ru/opennews/art.shtml?num=60358

Разработчики Debian не хотят нести ответственность в рамках https://en.wikipedia.org/wiki/Cyber_Resilience_Act

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

Это, конечно, поставило бы и Red Hat, и вот такую структуру Перенса, и разработчиков, которые решает подзаработать на open source, в интересное положение - хочешь денег, неси материальную ответственность.

Мне кажется, такой подход сделал бы переупаковку oss софта существенно менее прибыльным бизнесом.