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

Альтернативный компилятор для Go, на основе LLVM.

Я пока не смог его собрать, потому что его сборка - это тихий ужас, пытающийся собрать завендоренные запчасти с помощью аццкого Makefile - https://github.com/tinygo-org/tinygo/blob/release/Makefile. Этот кошмар пытается собрать llvm, довольно странным образом (оно собирает бинари, а потом выковыривает из сборки получившиеся .a файлы), потом запчасти tinygo с помощью go build, а потом как-то слинковать это в один бинарь.

Треш, угар, содомия.

https://dmitryfrank.com/articles/rust_module_system_encourages_bad_practices

Небольшая заметка про отличия модульной системы Rust и Go.

Мне, однозначно, система Go нравится больше, хотя бы за четкое разбиение пакетов по директориям.

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

https://reviews.llvm.org/rGa6213088812f

Какой-то странный движ вокруг #llvm #libc.

Ее допиливают под GPU target platform, вот, коммит, в котором запилили malloc/free.

С одной стороны, проехаться на растущей популярности этой платформы - норм, но как бы это не заслонило ту конечную цель, на которую надеялся я - стать THE libc для Linux.

https://www.opennet.ru/opennews/art.shtml?num=59297 #uring

Google отключает io_uring на Андроиде, ChromeOS, и, наверное, где-то еще. Пишут, что дырявое решето - 60% всех багов и выплат за поиск багов.

В целом, это все логично и понятно:

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

Но, конечно, это очень печально, потому что мне io_uring виделся как будущее ввода-вывода в Linux, да и вообще, я надеялся, что все сисколлы, рано или поздно, можно будет асинхронно батчить пачками.

https://github.com/harfbuzz/harfbuzz/pull/4131

#harfbuzz #fontconfig #wasm

"This adds a wasm shaper that when called (default, when built), loads a WebAssembly program from the Wasm table of the font and calls its bool shape(font*,buffer*) function to shape the buffer"

Я, с одной стороны, всячески пропагандирую "открытые" системы, типа "там, где передаешь строку, сразу передай user defined dict", или "если требуется процедурное действие, не формализуй его, а позови пользовательский run.sh", но, с другой стороны, понимание, что загрузчик шрифта может позвать произвольный WASM, даже и в песочнице, меня напрягает.

Мысль о том, что интерпретатор wasm будет влинкован в каждую программу, энтузиазма тоже не вызывает. Вот если бы шрифты рендерились отдельным процессом, например, через dbus, было бы гораздо более хорошо.

Это "умение", конечно, сильно облегчило жизнь, в случае, когда авторы не удосуживаются готовить разумные tgz с релизами, так, чтобы они содержали все исходники.

Иногда новый способ экономит мне довольно много исулий по ручному скачиванию всех сабмодулей, например, вот - https://github.com/pg83/ix/commit/e187e1e719050f3bb8cb95c7ac1fddd40f7f19e6

В связи с этим, у меня вопрос задачка на bootstrap - какой командой можно наиболее эффективно скачать срез git репы (репа + бранч/таг + sha коммита в нем), со всеми сабмодулями, рекурсивно, без скачивания лишней истории (можно вообще без истории)?

У меня есть какая-то примерная команда, но, мне кажется, она не очень эффективна.

https://lwn.net/SubscriberLink/934692/5046d466490d9220/

Автор bcachefs, #Kent, хочет, в очередной раз, заапстримить ее.

Не очень понимаю, какую пользовательскую задачу она решает, которую бы не решали уже существующие FS.

Поэтому я не понимаю, какую поддержку получит эта FS в индустрии, и почему не станет уделом маргиналов.

Особенно мне доставил пассаж про

Rust is something that he has been evangelizing about to "anyone who will listen"; he thinks "writing code in C, when we finally have a better option available, is madness". He loves to write code, but not to debug it; writing in Rust "just means a lot less time debugging". He intends to slowly rewrite bcachefs in Rust, which will be a ten-plus-year project, but the use of Rust in bcachefs has already started. Some of the user-space tools have been rewritten in Rust and someone is looking at moving some of that work into the kernel.

"10 человеко-лет", говорит, "положу на переписывание под Rust".

На мой взгляд, это делает перспективы bcachefs еще более туманными.

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

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

https://gmplib.org/list-archives/gmp-devel/2023-June/006162.html

Какой-то чувак положил своим CI сервера проекта GNU gmp. CI этот живет в github, и проверяет сборку ffmpeg для сотни платформ. Проект gmp, широкими мазками, забанили все сети MS на своем сервере.

MS/github считают, что так можно, и проекту gmp нужно заиметь более лучшее железо.

Авторы gmp считают, что MS - контора пидарасов невозможно обслужить 8 гиг пожатого трафика за несколько часов, и отказались убирать блокировку. Не обошлось без левацких заявлений - https://gmplib.org/list-archives/gmp-devel/2023-June/006164.html:

"Note that this abusive traffic is still ongoing, but it is subsiding as I keep adding more and more Microsoft subnets to the firewall rules. I have much better things to do than defend a public service web server against corporate abuse!

What would you advise me to do, should I contact a US lawyer and have them send a cease and desist letter?"

Я, конечно, считаю, что:

* не надо хостить свою инфру, много раз про это уже писал #gitlab

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

GNU gmp (наверняка по глупым политическим причинам) такого зеркала не имеет.

https://github.com/faster-cpython/ideas/blob/main/3.13/README.md
https://github.com/faster-cpython/ideas/blob/main/3.12/README.md

#fast_python

Закончил читать два фундаментальных (если считать ссылки) текста про грядущие оптимизации python.

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

Oh, fun fact - Гвидо, похоже, отодвинули от процесса - https://github.com/faster-cpython/ideas/commits/main

Совпадение? Хм...

https://blog.rust-lang.org/2023/06/20/introducing-leadership-council.html

Тут вот пишут, что распустили Core Team, и завели новый.

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

#wasm #bootstrap

После написания того текста я решил, что мне катастрофически не хватает какого-то решения для поддержки WebAssembly - как для сборки в него, так и выполнения.

Потому что раз всем нужно, то и мне тоже нужно!

Вот, теперь все есть:

pg# cat qw.c 
int f(int a, int b) {
    return a + b;
}
pg# /ix/store/.../bin/clang \
    --target=wasm32 \
    -nostdlib \
    -Wl,--no-entry \
    -Wl,--export-all \
    -O2 \
    -o qw.wasm \
    ./qw.c 
pg# /ix/store/.../bin/iwasm \
    --repl ./qw.wasm 
webassembly> f 1 2
0x3:i32
webassembly> 

Я завел интерпретатор из https://github.com/bytecodealliance/wasm-micro-runtime, llvm jit из него же, тулчейны из https://github.com/WebAssembly/binaryen, https://github.com/WebAssembly/wabt, ну а clang давно уже умеет в wasm.

На самом деле, я немножко мухлюю, потому что надо еще собрать wasm libc (поверх WASI - https://github.com/WebAssembly/wasi-libc), но, в целом, уже все работает, причем без всяких там rust и emscripten.

https://ohadravid.github.io/posts/2023-03-rusty-python/

Неожиданно годный текст про оптимизацию питона через переписывание кода на Rust.

Неожиданно - потому что заголовок совершенно кликбейтный, "python", "rust", "в 100 раз", короче, все, как я люблю. Да и задача, мягко говоря, выбрана странно - чуваки написали кусок пайплайна 3d рендера на python, причем кусок, который непосредственно обрабатывал геометрию. А потом героически оптимизировали этот кусок, хотя ответ, кажется, всем очевиден - не надо обрабатывать геометрию на python.

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

Довольно подробно расписано использование биндингов из Rust в Python + NumPy.

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

https://lwn.net/Articles/935592/

RH закрывает доступ к исходникам, из которых собирает RHEL. По подписке они продолжают быть доступны, все честно.

В комментариях срач, коллеги никак не могут договориться, кто же больше паразитирует на open source:

* RH, переупаковывая и продавая чужой труд
* Alma/Rocky линуксы, пересобирающие RHEL из исходников, ранее доступных всем
* Oracle ...

Я, конечно, считаю, что никто не паразиты, все в рамках того, что ВЫ САМИ разрешили им сделать с вашим кодом. Не хотите - ну возьмите другую лицензию на свой код, но им тогда никто не будет пользоваться, и все.

#wasm #wasi #bootstrap

Я таки собрал какое-то приложение в WASM формате, под платформу WASI (специально постоянно про это упоминаю, потому что набор команд (WASM) и доступные вызовы в систему (WASI) - это разные вещи).

К сожалению, пока ничего не заработало.

Сначало оно ругалось на неподдерживаемые ассемблерные команды:

pg# /ix/.../wasm-interp \
    /ix/.../bin/base64 
0002080: error: unexpected opcode: 0xfe 0x48

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

0020bf: fe 48 02 00 i32.atomic.rmw.cmpxchg 2 0

Попробовал включить в интерпретаторе поддержку тредов, но:

pg# /ix/.../bin/wasm-interp \
    --enable-all \
    /ix/.../bin/base64 
error initializing module:
    invalid import "wasi_snapshot_preview1.args_get"

Оказалось, что интерпретатор собран без поддержки WASI. Пересобрал, но:

pg# /ix/.../bin/wasm-interp \
    --enable-all --wasi \
    /ix/.../bin/base64 
unknown wasi API import:
    `sched_yield`

Тут я пока сдался, потому что WTF?

#wasm #wasi #bootstrap #ix_run

Ну, вот, после пары сегфолтов, я это дело таки завел:

pg# ./ix run \
  bin/b64 --target=wasi32 \
  bld/sh \
  bin/iwasm/fast/er \
  -- \
  iwasm --fast-jit \
  '$(command -v base64)'

  b64      (Base64 Encode/Decode)    Bob Trower 2001/08/03 
           (C) Copr Bob Trower 1986-2015     Version 0.94R 
  Purpose: This program is a simple utility that implements
           Base64 Content-Transfer-Encoding (RFC1113).
           Use -h option for additional help.

https://wasi.dev/ мне кажется черезчур сложным для реализации. Ну и там пока очень мало чего, чтобы стать полноценным OS API - там нет всяких манипуляций с FS, сигналов, треды в зачаточном состоянии, процессов тоже нет.

Жду, когда запилят WASM + Linux ABI. Кажется, это не должно быть очень сложным - нужно запилить тонкую прослойку, которая бы проксировала из контекста интерпретатора в контекст системы всего шесть функций - syscall0, ..., syscall5 (это Linux ABI), а поверх этого сконпелять musl в виде libc.

Это не так гранулярно, зато можно очень быстро получить связку WASM jit + Linux, в качестве target platform.