https://www.phoronix.com/scan.php?page=news_item&px=LibreOffice-WASM-2022 #wasm #WASI

Писал про WASM в Firefox. Мне кажется, что за WASM, конечно, большое будущее(а все же помнят, что я мастер предсказывать уже произошедшие события, да?):

* Оно достаточно вменяемое в среднем. Без встроенного GC там, например.

* Насколько я понял, WASM bytecode сохраняет более полный граф выполнения программы(условно говоря, не goto label, а if - then - else) в сериализованном виде. Я недавно читал статью(к сожалению не сохранил, если вдруг есть под рукой - скиньте, pls), что такая структура позволяет процессору лучше оптимизировать выполнение кода.

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

Короче, вот вам прогноз - на горизонте в 15 лет мы увидим соревнование WASM и RISC-V, в реальном железе(я вот только не очень понял, насколько WASM memory safe по дефолту, поэтому в реальном железе может быть немного другой вариант).

Хотя, конечно, я часто бываю черезчур оптимистичным.

https://medium.com/@losfair/a-comparison-between-webassembly-and-risc-v-e8fb9d37e6cc

То, что WASM заточено на JIT, IMHO, как раз будет только в плюс, потому что процессоры все больше и больше становятся похожи на hi-perf VM.

Почему это не произошло с Java, или на мобильных платформах уже? А все заметили, что сейчас случился ренессанс процессоростроения, и процы в железе под разные задачи не отливает разве что ленивый?

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

Я его строю не только как пакетный менеджер, но и как (мета) систему сборки, построенную по enterprise лекалам. Например: #ix #gold #dev_shell #ix_run

* кросс-компиляция
* из этого следует возможность собрать произвольный код с произвольным набором флагов и опций.

То есть, я могу построить всю программу целиком, включая библиотеки, с такими фичами, как:

* санитайзеры
* debug/release
* разные optimization levels

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

Для всяких bazel/buck/ya/etc это очевидные свойства, но для OSS систем это достаточно свежая вещь.

Короче, мне всегда было интересно, что будет, если там разные программы пособирать с С++ garbage collector в качестве аллокатора.

* Quake работает like a charm, без лагов, памяти жрет раза в полтора больше.
* Браузер не запускается, какие-то проблемы в выделении drm буффера.

Кстати, gc не такая уж и глупость, оно помогает для того, чтобы заставить работать какую-нить бажную программу с use after free, а у меня такие есть(например, M4 некоторых версий).

#bs #vendor #ix_run #dev_shell #gold

Меня удручает состояние современных OSS систем сборки. Расскажу сегодня про такой аспект: каждая уважающая себя современная система сборки хочет иметь в себе пакетный менеджер.

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

Cargo же все видели? Я пару раз писал, к чему приводит эта заявка на всеобъемлимость применительно к cargo - необходимость wrap все зависимости не под cargo в cargo сборку. Это выглядит уродливо, и приводит к проблемам с ромбоводными зависимостями.

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

Я уже писал про .wrap файлы от meson(для них существует целый репозиторий - https://mesonbuild.com/Wrapdb-projects.html).

Про это можно писать бесконечно, вот несколько очень всратых примеров:

* nodejs перепиливает сборочную систему от v8 на autoconf
* webkit переделывает сборочную систему от ANGLE(это реализация opengl от Google) на CMake
* chrome вендорит кучу библиотек, не буду описывать их по отдельности
* telegram вендорит все свои зависимости, и собирает их ни с чем не совместимым образом

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

Кстати, мне с этим живется несколько легче, чем там всяким fedora. В случае динамической линковки вендоринг - это еще и пересечение по путям в fs. В случае статической линковки это все хотя бы не видно наружу, достаточно де-вендорить всякие freetype/fontconfig и прочее.

Chrome, кстати, в этом отношении молодцы, они помогают де-вендорить те части, которые просто необходимо(типа рендеринга шрифтов).

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

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

Представьте себе команду

mix run lib/z lib/freetype bin/make 
    bin/cmake bin/clang/14 bin/ninja -- make -j 16

Эта команда сделает #realm , в котором будут доступны указанные библиотеки, указанные сборочные инструменты, и(вот тут важно!) врапперы для компилятора cc/c++/cpp (ну или rustc, кому что), которые автомагически настроят нужные пути к библиотекам и заголовочным файлам.

Кажется сложным? Ну давайте упростим это в alias mixrun=mix run $(cat mix.shell) —, и будем использовать так:

mixrun make -j 16

Или:

mixrun —sanitize=address —opt=-O2 make -j 8

Тогда в соответсвующем makefile вообще не нужно заниматься autodetect, перечислять всякие -I/-l-L/etc, а просто звать простые команды вида

cc -c x.o x.c

То же самое работает и для cargo, и для любой другой сборочной системы.

Основной point - система сборки уровня проекта не должна заниматься autodetect наличия зависимостей и их доставкой. Nix так умеет, Mix так умеет.

Проблема в том, что, в каждый момент времени автору того или иного OSS проекта проще накостылять очередной vendoring, вместо того, чтобы пойти договариваться со всеми заинтересованными сторонами.

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

Слушайте, ну мужик сказал - мужик сделал! #ix_run #dev_shell

  ...
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/mconf.o
  HOSTCC  scripts/kconfig/lxdialog/checklist.o
  HOSTCC  scripts/kconfig/lxdialog/inputbox.o
  HOSTCC  scripts/kconfig/lxdialog/menubox.o
  HOSTCC  scripts/kconfig/lxdialog/textbox.o
  HOSTCC  scripts/kconfig/lxdialog/util.o
  HOSTCC  scripts/kconfig/lxdialog/yesno.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/mconf
configuration written to .config

*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

> ix run set/menuconfig -- make HOSTCC=cc menuconfig

До этого, чтобы запустить menuconfig для настроек ядра, я запускал сборку ядра через ix, нажмал ctrl-c, шел в оставшуюся сборочную папку, и там, в настроенном окружении, запускал make menuconfig.

Мне было норм, но людям такое, конечно, стыдно отдавать.

Реализовал обещанную фичу, про возможность запуска команды в произвольном #realm.

Стало удобно.

А еще хорошие новости - одному из наших радиослушателей удалось поставить ix, по последней версии инструкции!

Короче, нет причин не попробовать.

https://determinate.systems/posts/introducing-riff #dev_shell #ix_run

Вот, пожалуйста, реализация той же идеи, только для Rust и поверх nix.

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

UPD:

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

Очень просто.

nix-env - это не реализация, это интерфейс, который легко может быть реализован в любом content-addressable package manager.

То есть, когда riff(а, в будущем, pip, npm, go, whatever, etc) будут дергать nix-env, им совершенно не нужно будет знать, что это nix-env из nixos, или тонкая обертка над #ix в #stal/ix.

(я тут, конечно, исхожу из того, что люди будут дергать nix-env через subprocess, потому что сделать биндинги к nixlang - ну такое)

Продолжаем тему кросс-компиляции. #cross #ix_run #dev_shell

Я теперь умею, например, так:

pg-> ./ix run \
    bin/qemu --for_target=aarch64-linux-user \
    bin/convert --target=linux-aarch64 \
    -- qemu-aarch64 '$(command -v convert)'

Что тут написано?

Тут написано: "собери мне realm, в котором есть host qemu, умеющий запускать arm бинарники, собери мне image magick convert под aarch64, и запусти в этом realm программу convert"

Что эта команда выводит на экран:

READY /ix/store/uFlUrE6DQMb3SC2l-rlm-ephemeral/touch
Version: ImageMagick 7.1.0-58 Q16-HDRI aarch64  
    https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI 
Delegates (built-in): bzlib fontconfig 
    freetype heic jng jp2 jpeg jxl lcms 
    openexr pangocairo png raw tiff 
    webp zlib
Compiler: gcc (4.2)
Usage: convert [options ...] 
    file [ [options ...] 
    file ...] [options ...] file

Обратите внимание, что запускается именно aarch64 бинарник convert!

Фактически, я умею в одном сборочном графе манипулировать артефактами, собранными под разные target platform.

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

* https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/ix.sh - дешевая автосборка и CI под другие платформы. Реально, добавить aarch64 в автосборку заняло 2 строчки в сборочных файлах. https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/linux/aarch64/ix.sh - список того, что я регулярно собираю под aarch64. Там есть и gdb, и даже графические программы!

* Новые возможности для #bootstrap. Например, go сейчас не является воспроизводимым с точки зрения классических способов (пакетных менеджеров и систем сборки), потому что последняя версия go, собираемая С-компилятором, не умеет строить код под M1, и не собирается под ним. Я теперь могу подступиться к этой проблеме, написав в сборочном файле для go что-то вроде:

{% block bld_tool %}
bin/qemu(for_target=linux-x86_64)
bin/kernel(target=linux-x86_64)
bin/busybox(target=linux-x86_64)
bin/go/1.4/(target=linux-x86_64)
{% endblock %}

Поднять в этом сборочном узле qemu (который сам себе и собрал), linux kernel, go1.4, и там провести цепочку #bootstrap. И это будет работать, в том числе, под host == darwin.

Мне сейчас кажется, что я достиг чего-то, чего ранее никто не делал в open source. Все автосборочные кросс-компилирующие решения, известные мне, основаны на том, что кто-то руками прикопал заранее собранные инструменты, поэтому они имеют довольно маленький scope.

"ix run" (или любая другая метапоисковая система), конечно, сильно меняет подход к разработке. #ix_run #dev_shell

Свой go-шный portal я собираю, например, вот так - https://github.com/pg83/portal/blob/main/build.sh

ix run set/dev/go -- go build

"Где-то там" строится временный #realm, со всем нужным окружением, в котором запускается свежесобранный go build на мой проект. Оверхед - доли секунды.

Хочется cgo, и зависимость от какий-то C-шной библиотеки?

ix run set/dev/go --cgo lib/gtk/3 -- go build ...

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

#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.

https://nixcademy.com/2023/10/31/cpp-with-nix-in-2023-part-1-shell/

Продолжение темы про использование #ix/nix/guix в качестве dev окружений. #dev_shell #ix_run

Мне мой "ix run", конечно, кажется более простым и лаконичным, чем то, что по ссылке, но, все равно, и то, и другое, - много лучше альтернатив.

Важное отличие #ix от nix/guix - мои артефакты можно невозбранно использовать в любом Linux, а не только там, где есть подходящий store с сотней .so-шек.