Слушайте, ну мужик сказал - мужик сделал! #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, по последней версии инструкции!

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

Меня тут спрашивают про мою первую попытку сделать дистрибутив Linux, и что там пошло не так. #gold

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

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

find / -type f | sort > before
sudo make install
find / -type f | sort > after
diff before after > /path/to/store/pkg_name

Команду для удаления пакета, думаю, вы себе можете представить сами.

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

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

Кстати, раз уж про это зашла речь, то потом я перешел на Генту.

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

Я думаю, что это связано непосредственно с темой моего блога - воспроизводимостью и #bootstrap.

Gentoo - это, по сути, "случайное блуждание" в пространстве версий и настроек софта. Если ты однажды напал на бажную glibc, собрал ее с не менее бажным тогда LTO, а потом пересобрал систему новым компилятором, то можете себе представить, как накапливается ошибка. А потом получившимся бажным sed снова собираете какой-то новый gcc.

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

(кстати, в данном случае это вполне формально определено, если посмотреть на процедуру bootstrap как на отображение B, которое переводит один набор бинарников в другой набор бинарников, то нам нужна такая процедура, чтобы B(B(x)) == B(x), то есть B(x) - неподвижная точка для B. Ничо не путаю?)

После получения промежуточных бинарников(инструменты и компилятор) X = B(I), где I - это live cd от fedora(например), все остальные собранные бинари уже зависят только от X, но не зависят от I(потому что X не зависит от I). Поэтому никакого случайного блуждания, зависящего от набора исходных материалов и промежуточно выбранных настроек, речи не идет.

https://www.phoronix.com/news/Linux-THP-Shrinker

Хорошая тема, facebook хочет включить thp на всех по умолчанию, без madvise. Этому мешает тот факт, что большинство huge page в системе получаются прямо очень недоутилизированными.

Меня эта тема заинтересовала, потому что у меня куда-то утекает память.

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

После полного рестарта потребление - несколько сотен мегабайт.

На что, я понять пока не могу.

Думал, что это может быть связано с тем, ч то у меня thp таки включены по умолчанию, но, видимо, нет, потому что рестарт всех программ должен освободить их huge pages в систему.

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

Есть идеи?

Я, на самом-то деле, с какой-то частью этой критики согласен.

1) Совершенно не понимаю похвальбу "функциональным пакетным менеджером". Функциональный язык без side effect для построения описания сборки пакета - это не достижение, а какой-то трешак, как по мне. Почему я должен учить еще 1 язык, который мне больше нигде не пригодится, и погружение shell в которого, кстати, сделано на троечку?

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

Важно не это, важно то, чтобы отображение содержания готового сборочного скрипта на uid ноды было консистентным. Функциональность языка для описания сборочных скриптов тут, возможно, полезна, но совсем не обязательна.

2) Пути в Nix/Guix уж слишком длинные. Я сначала тоже начал с hex-encoded sha, но потом:

* Укоротил длину хеша, чтобы пути влезали на экран. Я не считаю, что мы тут боремся с malicious package maintainer, который будет как-то пытаться сделать так, чтобы подставить зловредный пакет вместо незловредного. Я считаю, что мы тут боремся с "днями рождения", и uid покороче вполне подходит.

* Потом я заменил hex encode на base64, понятно, почему он компактнее? https://github.com/pg83/mix/blob/d12a0becd86f11b9b45222f6bc29e86f46a66249/core/utils.py#L20 Вместо +/= я взял две совершенно случайных буквы, 'PG', чтобы в путях не было какой-то дичи.

* Но меня очень угнетал тот факт, что эти две буквы незаслуженно часто появляются в путях, и я запилил base62 - https://github.com/pg83/ix/blob/main/core/utils.py#L17, после чего все стало совсем хорошо. В python из коробки есть длинная арифметика, поэтому я не стал жестить с оптимизациями этого кода.

Фотографий холостяцкой норы вам в ленту!

А я сегодня, между прочим, занимался сборкой, но не софта(хотя и софта тоже), а кровати.

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

https://discuss.python.org/t/breaking-continuing-out-of-multiple-loops/18354

Тут вот коллеги обсуждают, не добавить ли им goto в python. Ладно, multi-level break, но я, признаться, не вижу особой разницы.

Мне идея кажется всратой, я считаю, что, если нужен break откуда-то глубоко из кода, то следует выделить нужный блок кода в функцию, и позвать из нее return. Так, конечно, сложнее, но IMHO итоговый код получается чище.

Я в инфраструктуре для жизни очень консервативен.

Недавно пришлось сформулировать, почему, мне это показалось интересным, и я решил этим поделиться.

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

Примеры:

1) Обычный выключатель - это черный ящик, он всегда и везде работает одинаковым образом. Возвратный - это протекшая абстракция выключателя, ситуация, когда она протекает - это когда ты идешь ночью наощупь, и пытаешься что-то включить. Не знаю, как вас, а меня клинит в этот момент, когда я нащупываю выключатель, и мое ощущение реальности говорит мне, что он находится в положении ВКЛ, а света нет. Чтобы эта конструкция стала для меня черным ящиком, нужен сервопривод, который будет синхронизировать состояние выключателей с обеих сторон провода.

2) Обычная доставка Озона для меня черный ящик, международная - нет. Международная не является черным ящиком, потому что Озон дает мне handle на объект в другой системе(в Почте России/ЕМС), и говорит: "если там на стыке что-то пойдет не так, то разбираться ты с этим будешь сам". Я не пользуюсь междунароной доставкой Озона, она для меня недостаточно хорошо изолирована. В случае возникновения проблем мне ПРИДЕТСЯ разбираться, как там все работает.

3) Большинство устройств умного дома, да и умные колонки в целом - это вообще не черный ящик, даже рядом не стояло.

Вот, пример с выходных.

Какая-то рандомная умная колонка умеет притворяться тупой bluetooth колонкой. У меня wifi не работает за пределами дома(в другой раз, не все сразу), и, если ее вынести за пределы дома, я не мог ее подключить по bluetooth. Я подумал, что можно внутри дома подключить, и вынести ее за пределы дома. Но нет, когда она теряла соединение с материнским кораблем, то забывала, что делает, и соединение с bluetooth пропадало. Абстракция "тупая bluetooth колонка" - протекла, приходится разбираться, как оно работает внутри.

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

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

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

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

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

BONUS:

Пример свежей технологии, которая, КМК, уже стала таким черным ящиком - это wifi mesh.

Я себе в доме натянул wifi mesh от xiaomi, так, что на всех трех этажах одна и та же wifi сеть, и переключение между устройствами практически незаметно.

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

Mesh подхватил это соединение, увидел, что между устройствами есть более быстрый link, и начал использовать его.

Лезть в конфиги рутеров не пришлось, оно "само".

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

https://www.phoronix.com/review/apple-m2-compilers

Тут вот Миша экспериментирует с clang и gcc в #asahi Linux.

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

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

У нас в Я тоже довольно долго была ситуация, что мы не могли переключиться на clang, потому что важный код под gcc работал на несколько процентов быстрее.

Я воспользовался этим аргументом, и сказал, что мы так никогда не переключимся, а вот если переключимся, и все начнут пользоваться clang, то, через какое-то время, ситуация поменяется.

Так и случилось, буквально, за пару лет.

Что там сейчас, и кто побеждает, я не знаю, потому что там теперь PGO/LTO, а они довольно радикально меняют ситуацию.

Хозяйке на заметку:

Не используйте просто bsdtar для распаковки, он упрется в одно ядро, при использовании ssd/nvme.

Используйте bsdcat | bsdtar, оно займет почти полтора(зависит от кодека, может и к 2 подойти).

https://github.com/pg83/ix/blob/main/pkgs/bld/extract/ix.sh#L9

https://www.ozon.ru/seller/troyanskaya-art-524010

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

Очень предприимчиво, будущее наступило, тихо и незаметно.

Посмотрел я на это, и задумался, не нагенерить ли мне домой таких принтов самому.

Реально, зачем отсматривать тонны шлака, в тщетных попытках найти то, что нравится(тема, стиль), когда можно взять, и сделать?

Про libexec.

В вашей файловой системе, наверняка, есть папочка libexec, или /usr/libexec, в которой лежит всякая дичь, про которую вы не понимаете, зачем она.

Сегодня я расскажу, что же там лежит.

На самом деле, вообще никто не понимает, что туда надо класть, но, по факту, кладут следующее:

* Программы, которые не должен видеть пользователь, но которые может позвать ваша программа. Ну, вот, git кладет туда бинарники или скрипты вида git-X, и тогда вызов драйвера "git X" просто сделает exec на libexec/git-X. Довольно понятно, разумно, не надо замусоривать PATH всяким говном.

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

* Этот пункт я называю "всякое всратое говно, которое лично мне доставляет много проблем". Чаще всего это какие-то .so, на которые вызывающая программа хочет сделать LD_PRELOAD для своей подпрограммы. Сложно?

Сейчас станет понятнее.

1) в coreutils есть программа stdbuf. https://manpages.debian.org/stretch/coreutils/stdbuf.1.en.html - теперь вы знаете, как она сделана(перехватывает и подменяет вызовы через LD_PRELOAD).

2) В mold есть режим —run, который перехватывает вызовы линкера, и заменяет их на вызовы mold. Теперь вы тоже знаете, как оно сделано. (кстати, пока писал текст, посмотрел на trunk mold, сейчас они это кладут в lib/mold/, что не по фен-шую)

Я бы это все делал бы через prctl, но то же я.

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

bin/bin/{{pkg_name}} - программы, вызываемые программами
bin/lib/{{pkg_name}} - библиотеки для LD_PRELOAD из третьего пункта
lib/bin/{{pkg_name}} - сетевой процесс в webkit
lib/lib/ я пока не встречал

(реальная схема чуть другая, но для понимания это неважно)

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

Картинка на миллиард.

“Jeflon Zuckergates”

Занимательная ИИ-генетика.
Stable Diffusion

https://twitter.com/TechBroDrip/status/1565711996279959553

Какая прелесть, нам пишут, что вышел свежий gawk - https://www.opennet.ru/opennews/art.shtml?num=57732

А у меня про него, как раз, уже есть две истории:

* Они отказались от поддержки yacc, им теперь bison подавай, поэтому для #bootstrap я заморозил предыдущую версию.

https://github.com/pg83/ix/blob/main/pkgs/bld/boot/5/gawk/ix.sh

* Ну и мякотка - с этим gawk падает сборка ядра:

awk -f ../arch/x86/tools/gen-insn-attr-x86.awk 
  ../arch/x86/lib/x86-opcode-map.txt 
  > /ix/build/GtyXZzklYHhZgPK5/.../inat-tables.c
make[4]: *** [arch/x86/Build:9: 
  .../src/tools/objtool/arch/x86/lib/inat-tables.c] 
Segmentation fault

Буду ли я это репортить?

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

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

А вот и ответ про этот самый post-link optimizer: #BOLT

https://github.com/llvm/llvm-project/blob/main/bolt/docs/OptimizingClang.md

"That's 22.61 seconds (or 12%) faster compared to the PGO+LTO build. Notice that we are measuring an improvement of the total build time, which includes the time spent in the linker. Compilation time improvements for individual files differ, and speedups over 15% are not uncommon. If we run BOLT on a Clang binary compiled without PGO+LTO (in which case the build is finished in 253.32 seconds), the gains we see are over 50 seconds (25%), but, as expected, the result is still slower than PGO+LTO+BOLT build"

TL;DR - 15% скорости clang, по сравнению с просто LTO+PGO.

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

https://lists.gnu.org/archive/html/bug-gawk/2022-09/msg00006.html

Какой-то коллега из gentoo тоже это заметил, и даже подготовил патч.

Хороший у них там список рассылки.

https://lists.gnu.org/archive/html/bug-gawk/2022-09/msg00008.html

На сообщение о поломанных тестах на risc-v предлагают забить.

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 - ну такое)

Q: Антон, уже несколько дней как вышел clang15, а ты ничего про это не написал. Даже на opennet уже новость висит!!! https://www.opennet.ru/opennews/art.shtml?num=57739

A: В гробу я видел этот ваш пятнадцатый clang Я этот ваш clang пытаюсь завести еще с rc1, и это самый всратый релиз ever. Там включили несколько новых warning, несколько warning подняли до ошибок, некоторые новые фичи бажат, и, в результате, на выходе мы имеем несобирающуюся, кривую и косую, систему. Давайте я просто на нескольких примерах:

* "Для систем на базе архитектуры x86 добавлен флаг "-fzero-call-used-regs", обеспечивающий обнуление всех использованных в функции регистров CPU перед возвращением управления из функции. Указанная опция позволяет защититься от утечки информации из функций и примерно на 20% сократить число блоков, пригодных для построения ROP-гаджетов" #ROP

openssh определяет эту опцию, включает, и мы получаем посыпавшиеся бинари:

-checking if clang supports compile flag 
  -fzero-call-used-regs=all... yes
+checking if clang supports compile flag 
  -fzero-call-used-regs=all... no

make: *** [Makefile:451: host-key] Segmentation fault

* clang теперь отказывается звать функции без ее предварительного определения, и отказывается(в некоторых контекстах) от default int. Беда-беда, но configure скрипты завязаны на это, но вместо их падения мы получаем кучу misconfigure в разном софте:

-checking if setresuid seems to work
 ... not implemented
+checking if setresuid seems to work
 ... yes

-checking whether fpurge works... yes
+checking whether fpurge works... no

-checking if openpty correctly 
 handles controlling tty... no
+checking if openpty correctly 
 handles controlling tty... yes

-checking for sighandler_t... no
+checking for sighandler_t... yes

Да тысячи их. coreutils получаются условно-работающие.

* 19 мая я писал про https://discourse.llvm.org/t/rejected-rfc-stop-defining-the-stdc-and-related-macros-in-c-mode/62468/3

Кажется, оно выстрелило, потому что часть configure скриптов перестала находить правильные размеры для ptrdiff_t, size_t, etc.

configure:20525: clang -c   conftest.c >&5
.[1mconftest.c:86:17: .[0m.[0;1;31merror: .[0m.[1m
expected expression.[0m
if ((ptrdiff_t *) 0)
.[0;1;32m                ^
.[0m.[1mconftest.c:86:6: .[0m.[0;1;31merror: .[0m.[1m
use of undeclared identifier 'ptrdiff_t'.[0m
if ((ptrdiff_t *) 0)
.[0;1;32m

Я это свел вот к таком коду:

| #if STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # if HAVE_STDLIB_H
| #  include <stdlib.h>
| # endif
| #endif

Попытка запретить часть из этих warning тоже ни к чему хорошему пока не привела - ломаются уже другие части этих сраных configure скриптов.

19 же мая я писал, что коллеги из clang осмелели, и решили больше отступать от канвы gcc так, как они считают нужным. Видимо, Остапа понесло...

Доктор: — Вы страдаете извращениями?
Больной: — Что вы, я ими наслаждаюсь!

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

Тут вот вышла книга от Ричарда Столлмана, в которой он рассказывает:

* Как правильно, по мнению GNU, расставлять скобочки в программе на C. Спойлер - не надо так, за это в уважаемом обществе и убить могут. https://en.wikipedia.org/wiki/GNU_coding_standards

* Учение про то, что надо использовать расширения gcc, чтобы проклятые капиталисты не могли своровать безценный код Ричарда код был чище и понятнее. Спойлер - он чище и понятнее не становится, на этих расширениях умеют программировать 3 + 1/2 сумасшедших разработчика glibc, вам к ним не надо.

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

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

Вышел #gtk 4.8.0

Что они сделали нового, можно почитать по ссылке.

А что сломали - у меня!

Для сборки gtk4 требуется набор xml файлов от wayland. Фактически, это такой хреново сделанный protobuf + protoc + , собственно, сами xml(proto) файлы.

Эти файлы требуются только для сборки, но коллеги из gtk зачем-то впилили runtime зависимость от этих файлов. Пришлось выкорчевывать ее sed'ом - https://github.com/pg83/ix/blob/main/pkgs/lib/gtk/4/ix.sh#L39

Насчет runtime я не уверен, в pkg-config с этим сложно. В том плане, что вот написано, что gtk4 зависит от wayland-protocols. Это что значит? Что wayland-protocols нужны в runtime, или нужны для сборки зависимых от gtk4 целей?