Уважаемые, я таки запилил https://github.com/pg83/ix/blob/main/docs/INSTALL.md !

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

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

#harfbuzz

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1220100263

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

В общем-то, и понятно, им нужно или:

* Перепиливать интерфейсы друг у друга через DI(https://en.wikipedia.org/wiki/Dependency_inversion_principle)

* Или сливаться в пламенном экстазе в одну библиотеку

Очевидно, ни то, ни то, - не случится.

А у вас бывают какие-нибудь идефиксы?

У меня, если говорить про #bootstrap, вполне бывают, сегодня расскажу про такой.

Я, например, считаю, что в этом процессе - "ни шагу назад"!

Что это значит на практике?

Ну, например, ставил я себе на свой сервак #stal/ix, чтобы отладить и описать процедуру установки.

Когда я собирал ядро, то забыл добавить в него firmware от wifi модуля. Перезагрузился в это ядро, уже в #stal/ix, и получил:

* Работающую систему, но без доступа в сеть.

* Для окончания этой процедуры нужно было еще несколько раз запустить пакетный менеджер, и доустановить нужные пакеты.

Казалось бы, рестартани назад в fedora, доустанови пакеты, и перезагрузись в ix.

Но нет, "ни шагу назад" же!

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

Ну, притащил какой-то левый wifi router, соединил его патчкордом с сервером, сеть появилась.

Успех?

Какое там!

Оказалось, что, для запуска пакетного менеджера мне не хватает:

* модуля jinja2 для python

* и, что самое ужасное, python, который я добавил в инсталлятор, был собран без поддержки openssl, а, значит, не мог выполнить команду python3 -m pip install.

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

Казалось бы, перезагрузись в fedora, и далее по тексту.

Но нет, "ни шагу назад" же!

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

Что я тут могу сказать?

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

* После этого приключения я таки завендорил в IX jinja2. https://github.com/pg83/ix/tree/main/deps Очень не хотелось, но так прямо сильно удобнее. Ну и довольно сильно расширил инструментарий, доступный процессу установки - git, более хороший python, и прочие инструменты для отладки, форматирования дисков, и так далее. https://github.com/pg83/ix/blob/main/pkgs/set/install/ix.sh

Да, это увеличивает время, необходимое для bootstrap realm'а c этими инструментами, но и жизнь облегчает сильно.

Резать его буду потом, когда процедура устоится.

#busybox, #GNU

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

10 лет назад я считал, что это какая-то интересная игрушка, в стиле "засунь дистрибутив Linux на floppy", и что там невозможно "жить" всерьез.

3 года назад я сделал его переоценку, и решил, что busybox вполне себе годится для #realm system, для загрузки системы, ну, и... всё.

Сейчас я уже где-то полгода использую busybox, как основную реализацию posix утилит, да и, в общем-то, как замену grep/sed/find/etc, coreutils, util-linux(!!, набор linux-специфичных системных утилит), и так далее. Даже awk я использую из busybox, он там куцый, но чтобы выбрать строку по значению поля - вполне подходит.

Я даже какое-то время использовал shell из busybox(ash), но, в конце-концов, вернулся на bash(причем 3-ий, в районе четвертого они что-то сильно для меня поломали). По довольно странной причине - у ash плохо работает интеграция с mc. Если бы не это, так бы и использовал.

Ну, ладно, less у них кривой, но кому нужен less в наше время?

Короче, я так скажу - в настоящее время я не вижу смысла строить Linux систему на основе утилит от GNU(косое, кривое, совместимое только с собой, да и то, не всегда, нечто), потому что а зачем? Вам, правда, нужна одна из 1000 этих опций, длиной от 20 символов, которые невозможно запомнить?

Да, тут еще, конечно, важно за это поблагодарить сообщество alpine linux, которое, насколько я понимаю, следит, чтобы всякие говноскрипты были с busybox совместимы. Может, еще openwrt, но это не точно.

#glibc #ABI

Когда они сломали memcpy во flash player - я промолчал, потому что не смотрел ролики в youtube.

Когда они сломали setjmp/longjump для s390, я промолчал, потому что не программировал для big iron.

Когда они сломали ABI DT_HASH в EAC, я промолчал, потому что не играл в игры в Steam Deck.

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

#server_push

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

Чудесный, прекрасный, день.

Он был бы еще лучше, если бы все те злые люди, которые годами потихоньку ели мой мозг про server push, пришли, и сказали, что были все эти годы категорически неправы!

Да, я к вам обращаюсь, вы все меня читаете :D

Я, знаете ли, тот еще мастер предсказывать уже случившиеся события, но, кажется, в случае #zink попал в точку.

https://www.phoronix.com/news/Zink-2022-Refactor-Faster

Вот, пишут, что, на каких-то нагрузках, zink уже быстрее, чем родной opengl от mesa.

Это, конечно, очень хорошая тема, коллеги смогут:

* Выкинуть с кремния бюджет на opengl state tracker, и оставить один там Vulkan.

* Перестать дублировать кучу кода в #mesa, а, значит, теми же силами бежать быстрее.

Так, раз уж сегодня так много интересных ссылок, то у меня продолжение ссылочной ленты.

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

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

Нравится мне эта #sjw-шная логика - "нам не нравится, что написано в mit/bsd/gpl лицензиях, поэтому мы просто не дадим вам делать то, что нам не нравится, хотя лицензия на код явно это разрешает".

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

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

Нет причин не попробовать!

(мне кажется, я столько документации за всю жизнь не написал)

Кстати, был бы благодарен за стрипнутый конфиг линуксового ядра, без модулей, который бы легко и быстро загружался в qemu/virtualbox.

http://new.ya.ru
https://yandex.ru/company/press_releases/2022/2022-08-23

Я пришел в Я, когда Я себя идентифицировал, в основном, как "поисковая компания".

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

В разговорах с Сегаловичем я пару раз спрашивал-предлагал, а не удалить ли нам этот банер нахер, и вообще, не сделать ли ya.ru главной страницей? Лично для меня это всегда был один из selling point google, что меня ничего не отвлекает от ввода запроса.

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

А я как пользовался ya.ru, так и продолжал им пользоваться. Поэтому, как пользователю, мне нравится, что новая главная Я будет теперь выглядеть именно так. Но, если задуматься, то 80-90% моего взаимодействия с поисковой системой идет через строку ввода URL в браузере, поэтому, это, наверное, уже совсем неважно.

Про прекрасный мир среднеотдаленного будущего.

Я так, очень тезисно накидаю.

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

Вот, например, поиск по web, или поиск по товарам, или доставку, или такси, можно "доделать до конца" - сделать так, чтобы они работали, и не доставляли дискомфорта человеку.

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

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

Поэтому в среднесрочной перспективе, когда все стали IT-шниками, а производство становится все дешевле и дешевле, в выигрыше будут не те, кто конкурирует поиском в web, и не те, кто клепает автомобили(это все - просто привычная инфраструктура, которая просто "есть"), а те, кто доставляет чувственные и интеллектуальные удовольствия человекам.

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

https://lwn.net/Articles/905663 #yeswecan #provider

Заметка про одну из моих любимых тем, про инфраструктурные площадки.

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

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

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

https://github.com/tornado-repositories - вот новое место для этого кода, ждем, удалит это github, или нет.

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

https://discourse.llvm.org/t/rfc-lldb-telemetry-metrics/64588

Предложение по добавлению телеметрии в LLDB.

TL;DR - Google(а кто бы сомневался) хочет оптимизировать разработку. Держать телеметрию в виде патчей, думаю, неудобно.

G-word, конечно, в тексте не упомянут, сказано про некую "company that ships LLDB in an internal toolchain could send usage to an internal server for usage aggregation, or a distro could send logs to somewhere in..."

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

Who cares.

Лично мне кажется, что внутрикорпоративная телеметрия - норм.

ЖЫРа пока нет, я ожидал большего.

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

Я вот тоже захотел, но все, что я вижу, по тем или иным причинам, мне не очень нравится.

Ищу хороший белый стол на ножках, без регулировки по высоте(хожу много), ну, вот, как в офисе Я, например. С рабочей поверхностью примерно метра 1.5 - 2 квадратных, угловой/прямой - уже неважно.

Не вычурный, хорошо сбитый. Не фабрики "Большевичка".

* https://www.ozon.ru/category/kompyuternye-i-pismennye-stoly-38454/?text=стол&from_global=true - пролистал страниц 20, треш, угар, содомия.

* https://market.yandex.ru/catalog--kompiuternye-i-pismennye-stoly/18049603/list?srnum=1677&was_redir=1&rt=11&rs=eJwzKlRy4lK82Hix6cK-C7sVLuwCUnsu7L_Yc7EPKLT1YsOFvRe7L-wUuHWml0uJhYNBQFCDIYuhisPIyMjMwtzSoIHx6OJJrAGMVawcIMYsRsJmAQD1hztq&suggest=1&suggest_type=search&text=стол%20компьютерный&hid=10785221&local-offers-first=0&glfilter=21194330%3A22268790 - да примерно то же самое.

* https://ergostol.ru/goods/stol-lord/ - неплохо, но мне кажется, что дорого.

* https://zamm.ru/catalog/v_nalichii/stol_tandem/stol-pryamoy-tandem-glubina-700-mm-70-sm-dlina-1800-mm-180-sm-tsvet-st-belyy-premium-w1000-st9-aa-25_1/ - пока мой лучший вариант.

* https://www.bestmebelshop.ru/catalog/stoly-kompyuternye/stol-kompyuternyy-viktor-3-bms/ - можно накликать интересную мне конфигурацию, цена норм, но вид, КМК, не очень презентабельный, да и фабрика "Большевичка".

Накидайте ссылок, pls.

https://www.phoronix.com/news/Mesa-CI-Begins-Mold

Нам вот тут пишут, что #mesa перешла в своем CI на #mold.

Я уже несколько рас писал тут, что Mesa - те еще пионеры, с них станется. Один с трудом работающий проект будет линковать другой с трудом работающий проект, nuff said.

Пишут, что линковка стала ажно в 20 раз быстрее. С 20 секунд до одной.

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

И, конечно, была интересна мотивация.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6877

TL;DR - lld даже не участвовал в соревновании.

Ну, реально, сравнили какой-то застывший в развитии лет 10 назад gold, никогда не развивавшийся bfd, и mold.

Mold, конечно, победил.

В основном коммите я бы хотел отметить:

* С особым цинизмом забили на воспроизводимость. md5? Не, не слышали. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17992/diffs?commit_id=eb6ce47d4f75d545aaeed94ebe90c8dfbf43a576#1f8d74bba33f14a5cb315d6aeefff120f8c34506_0_6

* https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17992/diffs?commit_id=eb6ce47d4f75d545aaeed94ebe90c8dfbf43a576#ef0374780e379cec309797720f270719b2ba12fb_83_83 - а вот это вообще мякотка. Mold еще не научился работать без багов, но зато придумал interceptor(mold —run xxx), чтобы уметь оборачивать сборочные системы, и подменять в них линкер.

Ебени они там объелись, короче, что первые пионеры, что вторые.

Почему не lld, тема не раскрыта.

Ну, я спросил, чо. https://gitlab.freedesktop.org/mesa/mesa/-/issues/6877#note_1522796

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

Нам пишут, что G-word DE тоже хочет следить за своими пользователями.

На этот раз все вполне себе централизовано, данные попадут в IBM RedHat GNOME.

Я не понял две вещи:

* Почему не в systemd-то сразу?

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

Слушайте, а вы же замечали, как перед релизом проясняется сознание? #gold

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

Что нужно сделать прямо сейчас, любым хаком, а что можно отложить на потом.

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

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

* Средняя сборочный узел половину времени жрет 1 ядро, и почти не жрет памяти(configure), а вторую половину времени может выжирать NCPU ядер(make -j). Поэтому выделять шедулером NCPU ядер на все время работы узла - довольно расточительно, машина недогружена.

* Обычно можно считать, что "make -j" упирается в CPU, и на память можно не обращать внимание, это сильно облегчает задачу. Но есть отдельные типы сборок, когда памяти жрется много в среднем, или в пике(это разные проблемы, на самом деле). И если таких узлов запустить в параллель несколько, то они начнут умирать с OOM.

Я че-то вертел, крутил это, удовлетворительного решения пока не нашел.

Но релиз-то скоро!

(я хотел до конца лета успеть, но, кажется, немного не успеваю)

И, на днях, я, как это заведено перед релизом, сказал "ебись оно там все конем", сделал простую аппроксимацию всего этого дела:

* На машине есть N слотов, каждый из которых может херачить NCPU тредов сборки. В этих слотах выполняются "мелкие" сборки, которые не жрут памяти. Это нам дает N * NCPU максимум выполняющихся компиляций. В целом, можно показать, что "make -j" часть этой конструкции выполнится примерно за то же время, как будто если бы сборки работали последовательно, в NCPU потоков, но с бОльшим пиковым потреблением памяти. В предположении, что памяти нам заведомо хватает, это нормально. Зачем тогда вообще делать N слотов, а не 1? Чтобы configure части тоже имели возможность работать параллельно. Почему не сделать N == NCPU, чтобы одновременно могло работать NCPU configure? Потому что памяти начнет не хватать очень быстро с ростом NCPU.

* На машине есть 1 слот для монопольного исполнения "тяжелых" задач.

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

Work like a charm, привычные уже OOM, когда одновременно шли собираться телега и браузер, пропали.

https://github.com/pg83/ix/commit/eef2c90c8af7b9994464bc1e62f2b2d877c21642 - реализация, она прямо очень простая, потому что раздельные пулы с семафорами у меня уже были(для задач, ходящих в сеть), нужно было только докинуть возможность указать пул прямо в сборочном скрипте.

Слушайте, ну мужик сказал - мужик сделал! #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). Поэтому никакого случайного блуждания, зависящего от набора исходных материалов и промежуточно выбранных настроек, речи не идет.