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 целей?

Продолжаем серию фотографий "из жизни хиккимори".

https://t.me/itpgchannel/567

Стол, в итоге, я взял от ZAMM, есть по ссылке в предыдущем сообщении. И кресло, заодно.

Стол хороший, доставка так себе. У меня дом в 100(literally) метрах от границы, до которой они везут сами, везти отказались.

Пришлось везти самому. Удивительный факт - в тарифах Яндекса доехать от Москвы до моего дома на грузовике дешевле, чем на такси.

В первый раз лет за 6 работаю за столом.

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

Но, как говорится, все течет, все меняется.

А еще я на 2 недели ушел в отпуск, и собираюсь за это время добить сайт и документацию, и уже начать писать про #stal/ix более широко.

Уважаемые, а что происходит с рынком standalone мониторов для PC?

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

У меня такое ощущение, что я вернулся в 17 - 18 год, с того времени прогресс там произошел, пожалуй что, в герцах, ну и в цене.

Низкие разрешения, PPI << 100, OLED - да вы чо, OLED там вообще нет. Вот, что я нашел из OLED:

* https://4k-monitor.ru/catalog/dell/Dell_Alienware_AW3423DW/ - более-менее норм вариант, но таких денег я в жизни в руках не держал.

* https://aliexpress.ru/item/1005004442033393.html?spm=a2g2w.productlist.list.1.3b023b79EUXm3u&sku_id=12000029193051824 - единственное интересное мне предложение на алике, магазин создан месяц назад, название - OEM. Ну не знаю, не знаю.

* https://4k-monitor.ru/catalog/gigabyte/Gigabyte_AORUS_FO48U/ - а это уже не монитор, но телевизор.

Вообще, какая-то очень странная ситуация:

* телевизоров OLED >= 45 дюймов - жопой жуй, https://4k-monitor.ru/catalog/?set_filter=Y&arrFilter_P1_MIN=&arrFilter_P1_MAX=&arrFilter_63_1241945380=Y&sort=propertysort_IN_STOCK&order=asc&tab=grid&PAGEN_1=3, но куда же я такого монстра себе поставлю? Телевизор у меня уже есть.

* ноутбуков с OLED, с прекрасным PPI, тоже прилично.

А мониторов - нет.

Вот, вроде, годный текст про это - https://overclockers.ru/blog/RaddaR/show/59201/o-prichinah-otsutstviya-oled-monitorov-v-prodazhe-rasskazal-pcworld

Неужели все реально так грустно, и лучше не будет? И у какого из не-OLED мониторов сейчас хорошая картинка?

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

Тут вот пишут, что вышла новая версия #GNU shepherd.

Важная новая фича:

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

Хорошо, что я это не стал использовать.

А на вид, если не считать того, что конфиги к ней надо писать на диалекте lisp/scheme, выглядело оно вполне ничего так.

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

У меня на первом "прогоне" падало с ошибкой очень много configure тестов. В config.log я обнаружил красивое:

ld.lld: warning: .../lib/libc.a:
 archive member 'alltypes.h' 
 is neither ET_REL nor LLVM bitcode
ld.lld: warning: .../libc.a: 
 archive member 'syscall.h' is 
 neither ET_REL nor LLVM bitcode
ld.lld: warning: .../lib/libc.a: 
 archive member 'version.h' is 
 neither ET_REL nor LLVM bitcode

И действительно,

pg-> llvm-ar t libc.a | grep '\.h'
alltypes.h
syscall.h
version.h

TL;DR - я написал кривой сборочный скрипт, который положил в .a файл еще и сгенеренные заголовки. https://github.com/pg83/ix/commit/49660edbfc0514382f45bc3ffcdd7179ac74cf4c#diff-d0dfd80046e1a8679abbcdebbc7ee3984b5b75653d63cc2469ec0ee6427b7c20L22

Зачем я тут вообще переделываю .a файл? Потому что musl не поддерживает сборку со сторонним аллокатором, но мне же очень надо.

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

Предполагаю, что дело в том, что stderr от линкера стал непустой, и это сломало какие-то тесты.

https://www.jetpack.io/devbox/

Идея явно завладела умами масс, на этот раз на Go, тоже поверх Nix, без привязки к Rust.

Тема явно становится хайповой, мы про это все услышим еще много раз.

https://www.phoronix.com/news/Google-Ghost-Linux-Scheduling

Про user space #scheduler от FB я уже как-то писал, но вот то, что и Гугл делает что-то подобное, я не знал.

С точки зрения API это выглядит очень правильно - агент имеет полное состояние CPU в данный момент(инкрементальными апдейтами), и может отдавать команды вида "запусти тред Х на CPU Y".

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

Почему я думаю, что справлюсь лучше?

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

https://www.kommersant.ru/doc/5558844

Тут вот опять завиральные планы в области импортозамещения производства полупроводников.

"Дело в том, что стратегия развития электронной промышленности до 2030 года была разработана еще в начале 2020 года, к работе над профильным нацпроектом, реализация которого обойдется в 3,2 трлн руб"

Норм, 30 миллиардов долларов за 10 лет.

Почему планы завиральные? Потому что окружающие тоже не стоят на месте:

https://quote.rbc.ru/news/article/606586539a79475feb1f8a2c

"TSMC вложит в производство чипов $100 млрд"

За 3 года. И это одна TSMC.

Давайте зайду с другой стороны.

Мировой GDP - 100 триллионов. Из них производство полупроводников - 1 триллион долларов.

Очень грубая прикидка нам говорит, что на полупроводники работает 1% всего мира.

Россия - 2% населения всего мира.

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

https://www.supergoodcode.com/spaghetti-recipes/
https://www.phoronix.com/news/RADV-Lower-Draw-CPU-Overhead

#mesa Несколько оптимизаций в radv(драйвер vulkan в mesa), от Майка Блюменкранца(я периодически про него пишу).

Я бы тут хотел отметить, насколько в ПЛОХОЙ форме находится GPU стек под Linux, если один залетный программист, умеющий запускать perf, за пару часов работы может показать такой серьезный профит. Это просто кричит нам о том, что все низковисящие фрукты там далеко не съедены.

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

https://lwn.net/Articles/907572/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10735 #CVE

"A flaw was found in python. In algorithms with quadratic time complexity using non-binary bases, when using int("text"), a system could take 50ms to parse an int string with 100,000 digits and 5s for 1,000,000 digits (float, decimal, int.from_bytes(), and int() for binary bases 2, 4, 8, 16, and 32 are not affected). The highest threat from this vulnerability is to system availability"

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

(тут нельзя не вспомнить цитату Линуса про "security glory hole" - https://lkml.org/lkml/2008/7/15/296)

А какой-то упырь в python взял и закоммитил ограничение на максимальную длину обрабатываемого числа, тем самым, сделав из generic алгоритма непонятное УГ. Ну, и, конечно, сломал каких-то клиентов.

А почему мы не ограничим сортировку? А почему не ограничим любой > O(n), или даже просто > O(1) алгоритм?

Короче.

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

А разработчики, видимо, тоже мотивированы эти "CVE" потом "фиксить", самым диким образом.

Про тормознутую реализацию bigint из python я вообще молчу, зачем они ее тащат с собой, когда есть более продвинутые и доступные реализации?