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://xn--r1a.website/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 я вообще молчу, зачем они ее тащат с собой, когда есть более продвинутые и доступные реализации?

В продолжение темы про #школота

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

В cargo нашли zip bomb(это когда из маленького zip можно получить кучу говна на диске).

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

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

https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/

Вот, например, cloudflare запилила свой nginx.

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

В тексте хорошо рассказано про мою основную причину, почему я когда-то запилил альтернативу nginx(нет, это не мой NIH синдром) - "Some types of functionality are difficult to add".

Под nginx очень сложно писать модули, потому что его API - это или всратая state machine, или ты ждешь, пока у тебя в буфере в памяти образуется все тело запроса, и ты обслуживаешь его целиком.

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

По моим оценкам 12 лет назад, у меня код нужных мне модулей проксирования в корутинной реализации на С++(когда весь state хранится привычным образом, на стеке, и у тебя есть простая линейная модель выполнения и обработки ошибок) был примерно в 10 раз короче по коду, и примерно так же понятнее.

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

Очень бы хотел написать, что перешел на llvm15, но пока обновил только clang, потому что libc++ стала шибко умная:

/ix/store/ElvSJxEDJTM00ADM-lib-c-plus-plus-15/include/__algorithm/iterator_operations.h:100:5: error: static assertion failed due to requirement 'is_same<JSC::DFG::UnlinkedStructureStubInfo &, const JSC::DFG::UnlinkedStructureStubInfo &>::value': It looks like your iterator's `iterator_traits<It>::reference` does not match the return type of dereferencing the iterator, i.e., calling `*it`. This is undefined behavior according to [input.iterators] and can lead to dangling reference issues at runtime, so we are flagging this.
    static_assert(is_same<__deref_t<_Iter>, typename iterator_traits<__uncvref_t<_Iter> >::reference>::value,

Еще они в этой версии libc++ зачем-то решили подменить заголовок stdatomic.h: https://github.com/llvm/llvm-project/blob/main/libcxx/include/stdatomic.h

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

Поэтому с этим заголовком полный раздрай - где-то он определен в libc, как в freebsd, где-то его предоставляет компилятор, как, например, gcc и clang, а тут, вот, его решили предоставить в libc++.

Очень странное решение, причем, fallback в какой-то другой stdatomic.h делается не всегда - https://github.com/llvm/llvm-project/blob/main/libcxx/include/stdatomic.h#L223

В моем setup этот файл получается, по сути, пустой, что тоже сломало дофига кода.

(я этот файл стер к херам, чтобы можно было двигаться дальше - https://github.com/pg83/ix/blob/main/pkgs/lib/c++/15/ix.sh)

Поэтому у меня пока такой странный кадавр из clang15 + libc++14.

Ничего особо странного в этом нет, многие люди обновляют libc++ и clang без привязки к их общему релизному циклу.

Если подумать, то у меня прямо сейчас в сборке участвуют три версии llvm - 13, 14, 15. Довольно странно, да?

Я это делаю, потому что хочу поддержать не самые свежие версии gcc для bootstrap.

Поэтому, первым делом, я собираю libc++13 + clang14, это самая новая связка, собираемая gcc 7.

А уже ими собираю libc++14 + clang15.

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

Science and Technology links (September 16 2022)

Attractive female students get better grades. They lose this benefit when courses move online. A research paper is much more likely to be highly ranked if the author is famous. The USA has many more prisoners than police officers (three prisoners for every police officer), while every other developed country has the reverse ratio. Diluting the blood plasma of older human beings rejuvenate them. Saturated fat, as found in meat and dairy products, is not associated with bad cardiovascular health. In other words, eating butter does not harm your heart. An electric car has reportedly about half the carbon footprint as that of a conventional car.

https://lemire.me/blog/2022/09/17/science-and-technology-links-september-16-2022/

Забавный код в webkit, который перестал собираться в новой версии:

https://github.com/WebKit/WebKit/blob/main/Source/WebKit/Platform/IPC/ArgumentCoders.h#L540

До этого для конкатенации туплов там использовался свой велосипед - https://github.com/WebKit/WebKit/blob/4fb6881d9ccf5c5ee98163978d16d33eb5b57058/Source/WebKit/Platform/IPC/ArgumentCoders.h#L313

fun fact - вот этот вот код на вход получает такие странные типы, что common generic std::tuple_cat не может справиться с конкатенацией(ошибку для желающих разобраться - по запросу), а велосипед - может.

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

Что это за такие хитросооруженные типы, и почему с ними не работает std::tuple_cat - я так и не понял, с ходу, все должно работать. Возможно, баг в libc++.

Иначе, есть два тупла, результат сложения которых определен(его можно получить другим алгоритмом), но std::tuple_cat не справляется с их конкатенацией.