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

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, и начал использовать его.

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

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