Свои процессоры сегодня не делает только ленивый!

https://www.ixbt.com/news/2021/10/19/128-ddr5-pcie-5-5-alibaba.html

В догонку - хороший текст на хабре про стоимость процессоростроения, между прочим, от автора epic battle Ядра vs. Elbrus! https://habr.com/ru/post/583780/

Доразбирал прошлый дайджест llvmweekly.org

1) Неплохая заметка про то, как работает линкер - https://blog.llvm.org/posts/2021-10-01-generating-relocatable-code-for-arm-processors/

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

Вторая половина - на мой взгляд, какое-то очень невнятное решение понятной проблемы, которую линкеры уже давно умеют решать(relocatable static binary, c 2 секциями - .text, .data). Так же авторы, IMHO, периодически сваливаются с темы "relocatable" на тему "position independant". pi code является relocatable, но не наоборот, и делать его сложнее.

2) А кто-нибудь понимает, зачем LLVM продолжает пилить свою libc? https://reviews.llvm.org/rGdb8a88fef87e

3) Мы же теперь живем в мире, где участие женщин в IT надо как-то специально, не на общих основаниях, подсвечивать, да? Вот, llvmweekly дает ссылку на "Women in Compilers and Tools meetup" - https://www.youtube.com/watch?v=1-H8RTwCpwA Я тоже даю, я хороший. Cлушать там не о чем.

https://lwn.net/ml/linux-next/20211008113116.4bdd7b6c@canb.auug.org.au/

Например, история, как посрались 2 мейнтенера ядра Linux - разработчик драйвера AMD GPU Simon Ser, и Christoph Hellwig. Второй удалил из интерфейса ядра для модулей функцию, которую использовал первый.

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

Но kernel hackers такие kernel hackers.

PS: посрались знатно, практически с матюгами, и жалобами маме Линусу.

Написал тут AGPL в поиске в русской расскладке, и понял, что пора бы уже написать, почему я не люблю GNU/FSF/GPL.

#GPL

Если совсем коротко:

1) Слух о их полезности для дела бутстрапа OSS "несколько" преувеличен
2) Сейчас они индустрии больше вредят, чем помогают
3) С этической точки зрения они сильно похожи на движение SJW(которое я искренне ненавижу)

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

Поехали, часть первая!

Есть такой тулчейн, под названием LLVM. В него входит дебаггер LLDB, основной конкурент GDB. Я тут, на днях, собирал его для своего дистрибутива MIX, и нарвался на красивое.

Есть такая библиотека - readline. https://tiswww.case.edu/php/chet/readline/rltop.html Она распространяется по лицензии GPL3 (даже не LGPL!). Библиотека решает очень простую задачу - позволяет делать удобный пользовательский ввод, с редактированием, и историей. Понятно, что эта библиотека используется в куче софта - bash, python, gdb, везде, где нужен пользовательский ввод. К сожалению, лицензия библиотеки не позволяет ее использовать в бОльшей части OSS софта, из-за лицензии. Поэтому проект BSD запилил свою реализацию API readline - libedit. http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date#dirlist Реализация, как обычно в мире OSS, неполная, но более-менее работает.

В чем прикол?

1) LLDB содержит в себе интерпретатор питона, для расширения
2) LLDB, как настоящее свободное программное обеспечение, использует libedit
3) Python под Linux настаивает(ну, до недавнего времени) на readline.

Это выливается в ошибки линковки, а если их "починить", то в падения в runtime - несмотря на то, что функции в libedit называются так же, как в readline, структуры данных имеют разный layout.

Очевидное решение - собирать python с libedit для LLDB. Ага, щас, вот феерический тикет про интеграцию libedit в python - https://bugs.python.org/issue13501

long story short - собрать python с libedit стало возможным совсем недавно, заняло это несколько ЛЕТ согласований.

"LLDB is a bit of a special case: LLDB links against libedit, but the Python libedit module is built as if readline is in use. It turns out this "magically" works out, presumably due to the runtime workaround detection. As far as I know this issue would affect Linux as well, but perhaps the version of libedit on common Linux distributions is one with the 0-based vs 1-based history fix?"

Почему так? Потому что какие-то долбоебы решили, что нижележащая инфраструктурная библиотека в Linux должна идти под copyleft лицензией. Извините, но инфраструктурная библиотека под GPL - это леденящий душу п№%дец. Это привело к фрагментации OSS мира, и к потере огромного количества человеко-лет. Что получила GNU/FSF от этого, кроме чувства огромного морального удовлетворения? Ничего. Libedit успешно существует, собака лает, караван идет. Страдают пользователи, исключительно из-за политики FSF.

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

Перечитал текст, и задумался - а имеет ли вообще модуль readline в Python право на существование? Очевидно, сам модуль должен быть под GPL3, раз он линкуется с libreadline. При этом, интерпретатор питона загружает его в runtime. Какой, в итоге, должна быть лицензия конечного продукта? Имеет ли право не-gpl программа загружать gpl .so в runtime?

Таким вопросом задавался не только я:

https://python-list.python.narkive.com/ZktLTSUV/gnu-readline-licensing
https://www.b-list.org/weblog/2009/jul/14/licensing/ - очень интересная тема про то, как могут в одном питоне жить ssl и readline(раньше openssl была несовместима с GPL). А если учесть, что REPL Питона принудительно загружает модуль readline...
https://yarchive.net/comp/linux/gpl_modules.html (про загрузку проприетарных модулей ядра в Linux)

Напишу-ка я в FSF.

Например, блог разработчиков RedHat, с описанием того чудесного мира, куда RedHat собирается тащить десктопный Linux:

https://blogs.gnome.org/uraeus/2021/09/24/fedora-workstation-our-vision-for-linux-desktop/

Что я могу сказать? Я могу сказать, что RedHat тщательно игнорирует тренды современных языков, которые, по умолчанию, делают статическую линковку(Go, Zig, Rust, Swift, etc), навязывая дурацкий FlatPak(https://flatpak.org/) для дистрибуции приложений для Linux. К счастью, ничего они с этими трендами сделать не cмогут, и FlatPak будет постепенно умирать с остатками кода на С/С++. Может быть, трансформируется во что-то более удобное, типа бандлов в MacOS, для более удобного доступа к ресурсам приложения.

PS: flatpak, конечно, строго лучше того dll hell, что есть во всех мажорных дистрибутивах Linux, но "будущее" - вряд ли.

Новости из мира GNU. SFC подала иск за нарушение GPL на компанию #Vizio. https://lwn.net/Articles/873338/

Я прочитал публичную часть иска - https://shoestring.agency/wp-content/uploads/2021/10/SFC_PressKit_10-19-2021_v1.pdf

Все в лучших традициях GNU/FSF:

1) 20 страниц самореламы, без конкретных претензий к компании
2) Передергивания на передергивании. Just to name a few:
"… that you, as the consumer, have specific rights to modify, improve, repair and fix the software in your Linux-based products?"

Вот, из моего третьего пункта следует, что они настаивают на моем праве пофиксить bash в телевизоре. Но вот из их текста кажется, что я имею право лезть в саму прошивку Vizio.

"Vizio has a long history of violating copyleft, furthermore:
Vizio has already been subject to a large class-action suit that alleged that Vizio was misusing its customers’ private information"

Дооо, из того, что на Vizio уже подавали за что-то в суд, следует, что она нарушает copyleft.

3) Actually, на 20 страницах ровно 1 строчка претензий по существу. Что мы из нее узнаем?

"Smartcast is a Linux-based operating system. That means that not only do multiple copies of the Linux kernel appear in the firmware, other GPL’d and LGPL’d programs were found, including U-Boot, bash, gawk, tar, glibc, and ffmpeg."

Вы понимаете, к чему прикопалась эта пиявка? К тому, что в телевизоре есть bash && ffmpeg. bash/ffmpeg/прочее из этого списка, позволю себе напомнить, не идет под AGPL, поэтому требовать на этой основе открытия исходников софта Vizio под GPL нельзя. Можно требовать открытия патчей на bash, но если патчей нет, то и требовать нечего. Есть ли патчи на bash, или нет - иск стыдливо умалчивает.

4) Самая мякотка, которая показывает, насколько GPL защищает права пользователей на самом деле:

"that what makes this litigation unique and historic in terms of defending consumer rights is the fact that it is the first case that focuses on the rights of individual consumers as third-party beneficiaries of the #GPL. "

Сцуко, это ПЕРВЫЙ иск за всю историю #GPL, который подан не от лица разработчика! "Права пользователя на модификацию кода" my ass, ага.

GPL/FSF - это рак индустрии. Чем они вот отличаются от патентных троллей, с такими исками?

Отличный текст от Google, про оптимизацию memcpy: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/4f7c3da72d557ed418828823a8e59942859d677f.pdf #perf

Сравниваются 2 подхода - вручную написанный ассемблер, и автоматически настроенный(под нагрузку) код на С++. Второй способ побеждает(1% перфа Google). Я прямо ОЧЕНЬ советую прочесть хотя бы первую половину статьи, про использование SAT solver для автоматического построения алгоритма из базовых кубиков, это прямо огонь.

Так же дается описание того, как можно настроить memcpy под свою нагрузку.

На мой взгляд, конечно, оптимизацией memcpy должны авторы CPU(кто сказал "rep movsb"?):

1) Не нужно иметь сложный код от архитектуры к архитектуре(поэтому такой memcpy можно всегда инлайнить по месту)
2) Memcpy в процессоре имеет больше доступа к состоянию CPU, и может делать какие-то архитектурные оптимизации. Например, если поспекулировать, то memcpy может работать на уровне протокола синхронизации кешей - CPU читает cache line, и, вместо того, чтобы "прокачивать" его через регистры в output cache line, сразу пишет этот cache line по нужному адресу в свой cache, чтобы протокол синхронизации кешей сбросил этот cache line по нужному адресу в памяти. memcpy в CPU может игнорить write ordering.
3) Профит получит не только Google(не у всех есть 10 студентов, которых можно пустить на решение такой проблемы).

Тут, конечно, есть некоторые сложности(например, взаимодействие такой сложной инструкции и прерываний, взаимодействие с page cache), но они, кажется, решаемы. К сожалению, в x86 rep movsb проигрывает другим реализациям:

https://stackoverflow.com/questions/43343231/enhanced-rep-movsb-for-memcpy

Почему? Почему Intel оптимизирует AES, который не виден cluster wide, но не оптимизирует memcpy, который виден?

Для ARM у меня пока нет данных, но инструкции уже завезли:

https://news.ycombinator.com/item?id=28601386

Текст про то, как проект gnutls разводился с проектом GNU:
https://lwn.net/Articles/529522/

Как ушел мейнтейнер sed && grep, из-за политики FSF и Столлмана:
https://lists.gnu.org/archive/html/bug-gnu-utils/2012-12/msg00011.html

Ульрих Дреппер(один из авторов glibc) о RMS:
https://sourceware.org/legacy-ml/libc-announce/2001/msg00000.html

"Stallman recently tried what I would call a hostile takeover of the glibc development. He tried to conspire behind my back and persuade the other main developers to take control so that in the end he is in control and can dictate whatever pleases him. This attempt failed but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering committee" (SC). The SC is different from the SC in projects like gcc in that it does not make decisions. On this front nothing changed. The only difference is that Stallman now has no right to complain anymore since the SC he wanted acknowledged the status quo. I hope he will now shut up forever.

The morale of this is that people will hopefully realize what a control freak and raging manic Stallman is. Don't trust him. As soon as something isn't in line with his view he'll stab you in the back. *NEVER* voluntarily put a project you work on under the GNU umbrella since this means in Stallman's opinion that he has the right to make decisions for the project."

Каких же потрясающих срачей в интернете нас лишила эта ваша политкорректность!

Как натянуть сову на глобус семантику Rust на C++:
https://docs.google.com/document/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub

Спойлер: увы.

RedHat планомерно сворачивает "бесплатный RedHat Linux", во всех его проявлениях. Интересно, ждет ли ее судьба ELK && MongoDB? https://www.opennet.ru/opennews/art.shtml?num=54219

Microsoft колбасит .NET:
https://www.opennet.ru/opennews/art.shtml?num=56027
https://www.opennet.ru/opennews/art.shtml?num=56020

Тут еще должна была быть ссылка с извинением-неизвинением кого-то из управляющего совета .NET перед сообществом, но я ее не нашел.

———
Я как-то обещал написать про то, как #eBPF && #io_uring поменяют Linux, но так и не написал. Давайте я совсем коротко обозначу свою мысль, а раскрою ее позже.

Благодаря тому, что syscall станут бесплатными(io_uring), и станет возможным безопасно выполнять пользовательский код в контексте ядра(eBPF), ядро станет мигрировать в область микроядра - сервисы в пространстве (kernel-user)space(кто сказал "Microsoft Singularity?!" - https://ru.wikipedia.org/wiki/Microsoft_Singularity), c реализацией ядерной функциональности.

Это не просто спекуляция - сеть уже едет вовсю в (kernel-user)space, а вот теперь и шедулер: https://lwn.net/ml/linux-kernel/20210916162451.709260-1-guro@fb.com/ (патчи от нашего бывшего коллеги!) #sched

Тесты производительности новых M1 - https://www.anandtech.com/show/17024/apple-m1-max-performance-review/5

Очень впечатляет, и я могу только понудеть, что так мало от площади кристалла отдано целочисленным задачам CPU. https://architosh.com/wp-content/uploads/2021/10/M1-pro-max.jpg - меньше 1/10 части кристалла. А вот 1/2, отданная под GPU, у меня будет простаивать.

А мне начинает нравиться llvm-libc!

https://reviews.llvm.org/rG87c016078ad7 - имплементация https://lemire.me/blog/2020/03/10/fast-float-parsing-in-practice/

Если коллеги будут и дальше пушить туда state of the art алгоритмы, это же просто праздник какой-то!

1) Проект GNOME всегда славился тем, что "слизывал" дизайн и концепцию GUI с macOS. Но тут GNOME впереди планеты всей - если вам не терпится попробовать новую "челку" в действии, то это уже можно сделать в GNOME! https://github.com/AlynxZhou/gnome-shell-extension-inotch/

2) Адовейший ад с samsung - https://www.cnews.ru/news/top/2021-10-21_samsung_zapretili_prodavat

3) Заметка про то, что можно сделать неправильно вообще все, но если ваш продукт востребован - то пользователей это не остановит. https://www.quastor.org/p/how-whatsapp-scaled-to-1-billion

4) Продолжаем hate цикл про GNU - https://blogs.gnome.org/aklapper/2009/12/13/to-gnu-or-not-to-gnu/

https://habr.com/ru/news/t/585682/

Ну, TG я еще понимаю, но LJ-то за что?

1) Чот читаю, и ржу, какие девиации бывают у людей на собеседованиях. https://www.linux.org.ru/forum/development/16592727

2) Вот тут раздают serverless cockroarchdb. https://www.cockroachlabs.com/blog/announcing-cockroachdb-serverless/ Мне интересно, cockroarch смогли доставить то, что обещали много лет назад? В частности:
* не нужно админить
* горизонтальное масштабирование
* sql
* open source

Или, как обычно, take any N-1?

3) Хороший текст про http3/quic - https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/
Long story short - ну, такое, непонятно, чем quic лучше, чем tcp(кроме того, что в нем проще экспериментировать)

Bonus: про TCP BBR от нашего коллеги! https://www.youtube.com/watch?v=hOr9GP_czFs

4) Какая-то непонятная(но, наверняка, позитивная!) новость про то, что YADRO присоединилось к OIN. https://www.opennet.ru/opennews/art.shtml?num=56046 У YADRO есть какой-то значимый пул патентов, чтобы это имело смысл?

1) https://groups.google.com/g/golang-dev/c/iuB22_G9Kbo/m/7B1jd1I3BQAJ

В go 1.18 завезут дженерики. Сделают нормальную обработку ошибок - и я, пожалуй, напишу на нем свою первую строчку.

2) X.org переехал на meson, с autoconf. Новость, конечно, позитивная. https://lwn.net/Articles/874152/ Мне вот интересно, что будут делать остальные *nix(не Linux), когда X.org окончательно загнется? https://www.sizeofvoid.org/posts/2021-09-26-openbsd-wayland-report/

3) Из рассылки glibc: https://sourceware.org/pipermail/libc-alpha/2021-October/131776.html

Один из авторов lld пришел в glibc, с просьбой поддержать некую оптимизацию, которую уже умеет делать lld, в динамическом загрузчике glibc. Его (пока) отшили, с предложением, для начала, реализовать нужную фичу в binutils. Тред полон легкого троллинга, с обеих сторон.

4) Про бутстрап Kotlin. https://lists.debian.org/debian-java/2021/04/msg00001.html Видно, что JetBrains не очень запаривались тем, чтобы N+1 версия Kotlin умела собираться N-ой версией. А чо, разраб соберет локально jar-ничек, подложит в CI/CD, и все едет дальше, все довольны.

"Не для славы -
Для забавы
Я пишу!"

(c) я-забыл-кто

"Вы не рефлексируйте, вы распространяйте" (c)

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

На днях столкнулся с Chimera Linux - дистрибутив, достаточно близкий мне по духу(https://chimera-linux.org/, https://github.com/pg83/mix/blob/main/README.md, https://www.opennet.ru/opennews/art.shtml?num=56015).

#chimera

* Built entirely with LLVM
* FreeBSD-based userland
* Binary packaging and a well designed source build system
* Bootstrappable
* Portable

К сожалению, нам не по пути.

1) Для описания сборки пакетов используется Python. Примерно как в homebrew(только там Ruby). Проблема с этим подходом - на Python не очень удобно описывать скрипты сборки, и постепенно на Python появится свой диалект shell, с очень странным синтаксисом и правилами(посмотрите на сборочные скрипты в homebrew). Я пробовал так делать во втором своем подходе к снаряду, мне не понравилось.

2) FreeBSD-based userland.

Есть 2 типа дистрибутивов:
- в которых cp называется /md5(cp content)/bin/cp - Nix, Guix, Mix
- в которых cp называется /bin/cp - все остальные

Первый тип дистрибутивов может себе позволить иметь любой набор программ в PATH для какой-то конкретной цели. Например, использовать cp из gnu coreutils для autoconf проектов, и использовать cp из freebsd для пользователя.

Второй тип дистрибутивов такой роскошью не обладает. И этот новый дистрибутив только и будет заниматься тем, что чинить проблемы запуска autoconf скриптов не с gnu coreutils(вот список хаков, нужных для сборки bsd coreutils под Linux - https://github.com/dcantrell/bsdutils/blob/master/DIFFERENCES). Это я тоже проходил, это плохо работает. Фактически, дистрибутивы второго типа довольно жестко завязаны на gnu coreutils в /bin(а если не завязаны, то они doomed). Ну, ладно, busybox подтянулся, что позволяет существовать Alpine Linux, но и только.

———

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

Как ни странно, мне нравится Microsoft Edge(блин, если бы мне кто 15 лет назад сказал, что я добровольно установлю браузер от Microsoft в свой Linux - я бы повертел пальцем у виска). Например, тем, что у него вертикальные tab'ы. Это очень круто, потому что позволяет более разумно использовать пространство на 16:9 ноутбуках. К сожалению, под Linux Edge все еще не очень с Wayland, а под macOS вертикальные табы отключены(в full screen режиме).

Красивое. В 2000 году Дреппер посылает нах%: Хелвига - https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00053.html, а в 2021 уже заматеревший Хелвиг, будучи мейнтейнером Linux, посылает нах%: кого-то еще. Прекрасно, что что-то не меняется в этом мире. Не забыть бы посмотреть, кого пошлет в пешее эротическое Simon Ser, через 20 лет.

Хелвиг, кстати, в 2000 утерся - https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00070.html Но осадочек, видимо, остался.

https://habr.com/ru/news/t/586410/

Новость, конечно, позитивная!

1) Оказывается, бывают такие ARM, что low perf cores имеют другой набор инструкций, нежели hi perf cores. И, ежели заниматься кулхацкерством, а не спрашивать у OS, что доступно на этих ядрах, то возможно красивое - https://github.com/openssl/openssl/issues/14838

2) Я, на днях, писал, что авторы #glibc послали одного из авторов lld в пешее эротическое с его предложением по оптимизации. Тут стоит добавить:

* Авторы musl послали туда же - https://www.openwall.com/lists/musl/2019/03/06/5 На этот раз, с комментарием: "Нет в стандарте elf? До свидания!"

* А вот авторы ядра Linux оказались сговорчивее - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cf896fb6be3effd9aea455b22213e27be8bdb1d Им таки важнее ехать(-15% размера бинарника), чем шашечки.

Вообще, конечно, Linux "повезло", что с авторами платформенных библиотек, что с авторами платформенных инструментов(gcc, glibc, musl, binutils). Ну, эти капризные принцессы доиграются до того, что с ними не будут иметь дела, вот и все. Тем более, альтернативный стек уже есть.

3) Я думаю, шутку про то, что сценарий для фильма про луддитов делали на луддитских технологиях, не пошутил только ленивый. https://tjournal.ru/tv/463011-scenariy-dyuny-deni-vilneva-napisali-v-movie-master-programme-na-ms-dos-kotoraya-vyshla-30-let-nazad

4) MongoDB Amazon уже переписали поверх своего storage - https://aws.amazon.com/ru/documentdb/. Теперь дело за Microsoft SQL Server? https://aws.amazon.com/blogs/aws/goodbye-microsoft-sql-server-hello-babelfish/

"Support for T-SQL includes elements such as the SQL dialect, static cursors, data types, triggers, stored procedures, and functions. Babelfish reduces the risk associated with database migration projects by significantly reducing the number of changes required to the application. When adopting Babelfish, you save on licensing costs of using SQL Server. Amazon Aurora provides the security, availability, and reliability of commercial databases at 1/10th the cost."

Так себе и представляю:

A: M, дай лицензий на MSSQL в AWS, задешево?
M: Как насчет нет?
A: Ну нет, так нет.