https://groups.google.com/g/llvm-dev/c/HxXbT3qKYgg/m/kvNdxP0oAgAJ #maskray

Впервые с товарищем я столкнулся, когда он пришел в уютненький тредик про busybox style multicall binary для #LLVM(я очень ХОТЕТ). Он, соответственно, рассказывал, что это не нужно, и что это не дает перфа, и что размер не улучшится. Потом я узнал, что он один из авторов LLD, и ведет блог про линкер(не, реально, пишет много про линковку) - http://maskray.me/, правда, половина там на китайском. Короче, неудивительно, что человек, постигший все тайны динамической линковки не хочет оставаться не у дел, потому что статическая линковка проста, как 3 копейки. Пчелы против меда. Ульриха Дреппера про динамическую линковку не стоит слушать по той же причине(https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/).

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

А вот на днях он опубликовал пост про LLD, сравнение с #mold(кстати, Mold особенно хорошо идет с Rust, хехе), и все такое. Коллега совершает стандартную ошибку тех, кто не занимается перфом профессионально - он не делает прямых измерений(perf record), а только косвенные, и строит по ним предположения, как же работает программа.

http://maskray.me/blog/2021-12-19-why-isnt-ld.lld-faster

———
Short news - последнее время вместо HN я читаю lobste.rs, чего и вам желаю. Никакой политоты, только технически интересные штуки.

———
https://tom-kaitchuck.medium.com/designing-a-new-prng-1c4ffd27124d

Товарищ решил, что ему хочется не только посмотреть на срачик Мелиссы О'Нил и автора Хороширо, но и присоединиться к ним. Еще один PRNG.

Я однажды тоже запилил свой PRNG, он был норм, и по скорости, и даже проходил DieHard, Test01, и BigCrush, но у меня хватило ума не внедрять его никуда. Ну был он на 10% лучше, чем тогдашний конкурент? Но если что пойдет не так - не отмоешься же потом(как и произошло с автором Хороширо).

(срачик его с Мелиссой я уже в этом блоге кидал)

Набор ссылок, про log4j:

https://www.gwern.net/Turing-complete
https://drwho.virtadpt.net/files/mov.pdf
https://www.youtube.com/watch?v=pdmODVYPDLA
https://matt.might.net/articles/c++-template-meta-programming-with-lambda-calculus/
https://github.com/osnr/horrifying-pdf-experiments
https://www.youtube.com/watch?v=uNjxe8ShM-8
https://en.wikipedia.org/wiki/TrueType#Hinting_language
https://github.com/jbangert/trapcc#readme

———
https://github.com/google/gitiles/issues/84 #googlesource

Я тут обнаружил, что tar.gz с googlesource.com нестабильны - для одной и той же ревизии может быть разный tgz. Это, конечно, жесть.

Даже авторы Bazel это понимают:

"Prefer http_archive to git_repository and new_git_repository. The reasons are:"

https://docs.bazel.build/versions/main/external.html

Гарантировать целостность git checkout очень сложно(надо правильно трекать не только контент, но и кучу метаинформации про файлы, консистентно с тем, как это делает git(а если ты чекаутишь в систему, в которой нет тех пофайловых атрибутов, которые положили в git? с md5 от tar это работает прозрачно)).

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

Я, конечно, написал код по пересчету чексуммы для tgz, но это жесть. https://github.com/pg83/mix/blob/main/core/misc_cmd.py#L47

———
продолжается неделя линкера!

https://www.linux.org.ru/news/development/16695497?cid=16699902

Годный комментарий в теме про Mold анонимуса с ЛОРа, очень странное явление.

Кстати, каналу 3 месяца(я таки удивлен своему упорству), и наступило время традиционной просьбы закинуть на Патреон дать фидбеку и поделиться ссылкой на канал в доступных лично вам медиа!

(чувствую себя Jimmy Wales, если вы понимаете, о чем я)

https://justine.lol/cosmopolitan/index.html #justine
https://justine.lol/ape.html

Какая-то очень крутая штука, позволяет рожать портабельные нативные выполняемые файлы(под Unix это не очень сложно, с помощью https://en.wikipedia.org/wiki/Shar, но оно работает и под винду). Я только не понял, это больше стеб, или у нее есть реальные применения.

———
http://tree-sitter.github.io/tree-sitter/

Есть такая библиотека для парсинга, tree sitter. И все бы ничего, но для работы(генерации парсеров) ей требуется node.js, а код для highlight написан на Rust. Я лично бы взял С++ и Python, ровно то же самое, только смузи поменьше, но вот описание правил для хайлайтера на scheme меня уже добило. Столько смузи я не выжру.

https://tree-sitter.github.io/tree-sitter/syntax-highlighting

———
https://habr.com/ru/news/t/596425/

Не могу не упомянуть продолжение истории про Apple и поиск ею всякой запрещенки на ваших девайсах. Писал, пишу, и буду писать, что это зло во плоти. (кстати, недовольные политикой Apple могут использовать вот это, например - https://www.opennet.ru/opennews/art.shtml?num=56382)

———
У нас продолжается неделя линкера! На этот раз красивое от автора Mold:

"A classic way to use #mold:

clang before 12.0: pass -fuse-ld=<absolute-path-to-mold-executable>;
clang after 12.0: pass --ld-path=<absolute-path-to-mold-executable>;
gcc: --ld-path patch has been declined by GCC maintainers, instead they advise to use a workaround: create directory <dirname>, then ln -s <path-to-mold> <dirname>/ld, and then pass -B<dirname> (-B tells GCC to look for ld in specified location)."

https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573833.html

Ну, с таким подходом товарищи еще быстрее окажутся на свалке истории. Реально, такое ощущение, что любое упоминание clang для них - это красная тряпка.

Про scheduler в Linux. #sched #gold

Я знал, что шедулер в Linux хуйовый(мат intended), но что на десктопе все сломано настолько, я не понимал. У меня во время компиляции тормозит браузер(любой). И я ничего не смог с этим сделать.

Вот команда запуска компиляции(IO я не трогаю, все в памяти):

chrt --idle 0 cpulimit -l 1400 -i nice -n 20 ./mix realm upgrade

Я ограничиваю число ядер для компиляции(14 из 16), я выставляю nice, я помечаю треды на idle, чтобы они вытеснялись любым более приоритетным кодом.

Команда запуска браузера примерно такая же, только - заменяем на +, —idle на —rr, etc. Команда запуска композитора тоже(все, что затрагивает user facing процессы, запущено с повышенными scheduling privileges).

И это не помогает. На минуточку, я для браузера оставил полноценное ядро(2 гипертреда), у меня число процессов в очереди на выполнение < CPU CORES, и все равно, шедулер как-то умудряется просрать(сука! ненавижу!) все полимеры. Почему так? Я вам расскажу!

Первое соображение - про процессы разработки.

Я уже много раз рассказывал, ядро Linux пишут красноглазые хакеры. Без нормального процесса разработки, тикетов, тестов, etc. Код соответствующего качества. Как нормальный разраб бы оформил шедулер? А вот так:

IScheduler* scheduler = new WorkStealingScheduler(
   some kernel interfaces)...
...
auto job = sheduler->nextWorkItem();

Отметим наличие интерфейсов, чтобы можно было мокать тесты, инкапсуляцию(шедулер имеет доступ только к тем частям ядра, что ему явно передали), etc.

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

Есть, типа, описание, как должен работать шедулер:

https://en.wikipedia.org/wiki/Completely_Fair_Scheduler
https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/

Господа, да если бы он работал по этому алгоритму, было бы счастье! Этот алгоритм by design не допускает лаги, когда у меня число выполняющихся процессов < CPU CORES! Так он уже давно по нему не работает.

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

Шедулер в Linux пишут крупные корпорации - операторы облаков, или разработчики гипервизоров, вот по алгоритму, который я описал выше. Поэтому шедулер в Linux - это 100500 несвязанных(и конфликтующих! между собой) ручек, которые никто не умеет нормально крутить. Стройность CFS там уже давно и рядом не стояла.

Кстати, Con Kolivas отказался от идеи запилить нормальный scheduler для Linux. https://www.phoronix.com/scan.php?page=news_item&px=Con-Kolivas-EOL-MuQSS-CK Я бы, на его месте, послал всю эту пиздобратию еще раньше, когда Ingo Molnar, вместо того, чтобы признать, что Con лучше справился с работой, просто потырил его идеи в свою реализацию.

Второе соображение - пошедулить браузер существенно сложнее, чем пошедулить Apache. Прямо на порядок сложнее. Когда ты шедулишь Apache, тебе пофиг, что ты там где-то просрал квант времени. Когда ты шедулишь браузер, тебе надо выдавать стабильный RPS в 120, и просер одного кванта времени заметен. Тебе нужно реализовывать сложные алгоритмы, что, если ты отпустил lock, то твой квант времени доедает тот, кто этот lock получит(то же самое про запись в pipe). Почему это важно? Потому что тебе нужно, чтобы композитор моментально начал свою работу после того, как ты ему просигнализировал, что твой буфер с окном готов.

Под что тюнят облачные корпорации Linux scheduler? Вопрос риторический.

Итак.

* Шедулер в Linux сломан давно и навсегда(для десктопа, да и для серверов, если вы не большая корпорация со штатом крутильщиков ручек)
* Лучше всего(для десктопа) он работал в 2006 - 2008 году, пока его разработчики тюнили его под свои же workstation. Вот тогда реально все было плавненько.
* Чего там ищет Valve для гейминга в Linux - я не понимаю. https://www.opennet.ru/opennews/art.shtml?num=56390

https://www.phoronix.com/scan.php?page=news_item&px=Sway-1.7-rc1

Вышел новый rc Sway. Самое заметное нововведение - больше не нужно указывать для ./configure —my-next-gpu-wont-be-nvidia

По нынешним меркам хорошо, что не заставили извиняться(только вот кого, Sway или Nvidia?)

А чо, у меня вот шаблон для gnu-тых проектов называется autohell.sh, чего уж тут.

———
https://github.com/endrazine/wcc

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

Прекрасная, прекрасная вещь. Позволяет превратить .exe в .so, .so в .o, ну а то, что можно с помощью lua превратить любой .exe в shell с возможностью вызова любой функции - я уж вообще молчу.

Полагаю, мне это будет полезно, когда я захочу статически слинковаться с NVidia libGL.so

———
https://systemfolder.wordpress.com/2015/01/17/about-box/

А вот коллекция splash screen всякого старого софта. Prehistoric porn, все, как мы любим.

———
В свете поста про scheduler #sched нам пишут телезрители - оказывается, большие компании проблему понимают, и пытаются ее решить. Шедулер в user space - это прекрасно, у меня просто полно идей, как можно сделать хорошо.

https://lwn.net/Articles/869433/
https://dl.acm.org/doi/10.1145/3477132.3483542

———
Ну и выжимка текста про "починку" одного бага в шедулере(ссылка в прошлом сообщении, https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/):

"The original rationale for the behaviour was to maximise cache reuse – but for some applications waiting in the runqueue for the sake of better cache reuse does not pay off. The bug was triggered by a widely used commercial database configured with 64 worker threads.

To fix this bug, we alter the code that is executed when a thread wakes up. We wake up the thread on the local core – i.e. the core where the thread was scheduled last – if it is idle; otherwise if there are idle cores in the system, we wake up the thread on the core that has been idle for the longest amount of time. If there are no idle cores, we fall back to the original algorithm to find the core where the thread will wake up."

Вдумчивый читатель обнаружит, что починка добавляет еще 1 баг. Надо не longest amount, а shortest amount, потому что иначе возможна ситуация, когда будет 10 медленных ядер(напомним про тротлинг CPU) вместо 5 быстрых. Впрочем, возможно, нужно именно longest amount, просто я не понимаю, почему.

https://pythoninsider.blogspot.com/2021/12/python-3110a3-is-available.html

Пишут, что Python 3.11 уже на 20% быстрее, чем 3.10. Не знаю, у меня, кажется, медленнее, будет время - проведу пару тестов.

———
https://habr.com/ru/post/596193/

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

———
https://www.brian.jp/2021/12/24/exiled-from-the-metaverse-before-it-even-started-the-dangers-of-relying-on-facebook/

Писал, пишу, и буду писать, что это(отключение от услуги) не должно быть в компетенции провайдера услуги. #law #provider #yeswecan

———
https://lwn.net/Articles/879739/
Вышел юбилейный systemd.

https://www.opennet.ru/opennews/art.shtml?num=56393
И не столь юбилейный s6.

Из этих двух, я, конечно, выбрал бы s6, а так - ни тот, ни другой.

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

Про #systemd:

* Он слишком сложный. Если я бы хотел не знать, как работает моя система, я бы взял систему с launchd, если вы понимаете, о чем я.

* Он слишком всеобъемлющий. Я не верю, что такой комбайн может работать хорошо, и это, простите, не unix-way. Я предпочту набор хорошо сопрягаемых независимых компонент(в каждом из которых можно разобраться по отдельности).

* Он не решает ни одной моей задачи. В облаках сервисами управляет, условно говоря, снаружи K*, внутри или ничего, или что-то очень простое, типа runit. На десктопе модель systemd слишком сложна. Redhat, скорее всего, пилит systemd для отдельно стоящего сервера с apache/mysql/1c, ну так я не целевая аудитория.

* Мне никто так и не сумел ответить, как systemd должен поднять систему, в которой написано, что B поднимается после A, и должен работать только если работает А, но A находится в состоянии "10 секунд работает, 10 секунд упал".

Я считаю, что зависимости в системе управления локальными сервисами - зло. Управлялка должна оперировать bag of services, и просто пытаться поднять их все, возможно, с exponential backoff(потому что сервисы, в момент запуска, часто жрут больше CPU, чем в процессе работы).

Если вы пытаетесь перенести часть логики по обеспечению надежности своего сервиса в systemd("апач не должен отвечать на запросы, если не поднят mysql"), то вы попали, и мне даже лень подробно объяснять, почему.

Собственно, поэтому это и будет runit, возможно, с несколькими кастомными скриптами(для обеспечения exponential backoff, для управления cgroup, etc).

А, совсем забыл, за что глаз зацепился-то в релизе #systemd:

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

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

Небольшое продолжение про #systemd, конкретно, про #udev(который какого-то хера стал частью systemd).

https://github.com/illiliti/libudev-zero

"Another udev problem is non-portable home-grown language called "udev rules". Udev authors definitely don't know(or care) why it's better to avoid reinventing the wheel. Strictly speaking, I think they did that on purpose to overcomplicate udev as much as possible. Why? So that only authors(RedHat/IBM) can rule and dictate the future of udev. The recent eudev death only proves that it's really hard to support such unmaintainable mess."

Забавно, но я пришел к таким же выводам, весь этот ваш systemd - это классический vendor lock-in, со стороны IBM/RedHat.

———
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154371.html #loongson

В #LLVM приземляют поддержку loongarch. Это ОЧЕНЬ странно. LLVM, на моей памяти, отказали почти ВСЕМ, в их желании поддержать новую архитектуру в LLVM. Их позиция - лучше меньше, но лучше. Почему этот принцип не сработал в данном случае, и кому занесли китайские товарищи(или на кого собрали компромат, хотя какой в современном западном обществе возможен компромат, когда все можно и все, что можно, - хорошо)?

———
https://justine.lol/sectorlisp2/

Lisp, на этот раз с GC, за 436 байта.

Еще ссылок от #Justine:

https://justinetunney.com/dox/unicode.html
https://justinetunney.com/endian.html

Хотел на ее примере написать что-то типа "вот есть же нормальные тетки-программисты, и без всяких этих ваших SJW-конференций https://www.youtube.com/watch?v=xOmQFBirbOg", а потом передумал.

https://hellosystem.github.io/docs/developer/application-bundles.html#making-an-application-load-privately-bundled-libraries

Я тут решил посмотреть, как в helloSystem(писал про нее недавно) сделали поддержку бандлов. Свое исследование я прекратил вот на этом замечательном сниппете текста:

If an application is supposed to load privately bundled libraries, one must patch it so that it loads privately bundled libraries from a path relative to itself ($ORIGIN) rather than from /usr/local/lib:

sed -i -e 's|/usr/local/lib|$ORIGIN/../lib|g' usr/local/bin/falkon
ln -s usr/local/lib .
rm usr/local/bin/falkon-e

This works because by coincidence the string /usr/local/lib has the exact same length as $ORIGIN/../lib. If this was not the case, one would need to either specify the rpath at compilation time, or use a tool such as patchelf.

Всегда было интересно, что у таких людей творится в голове.

———
Мне кажется, что, в последнее время, я вижу по 2 новости в день, что вышло обновление того или иного ответвления от Ubuntu/Debian.

За вчера:

https://www.opennet.ru/opennews/art.shtml?num=56413
https://www.opennet.ru/opennews/art.shtml?num=56415
https://www.opennet.ru/opennews/art.shtml?num=56414

Мне интересно, неужели вот это вот все находит своего пользователя, и зачем это кому-то может быть надо?

И отдельно вопрос про https://www.opennet.ru/opennews/art.shtml?num=56414

Товарищи пишут, что их GUI адаптируется к планшетам и телефонам. Мне интересно, доживу ли я до момента, когда размеры элементов в gui будут указываться в сантиметрах, а не пикселях?

20 лет этого жду, нет, серьезно.

———
https://marc.info/?l=git&m=124111702609723&w=2

Недавно писал про то, что JGit не умеет делать bitwise identical tgz со снепшотами кода.

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

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

Вышла новая версия busybox. Почему-то очень часто, рядом с информацией про релиз busybox, пишут вот такую ересь:

"В то же время автор BusyBox всячески возражает против такой защиты - считая что она ломает ему бизнес."

Брюс Перенс, конечно, является автором закрывающих скобочек в коде, но вообще, он склочный мудак:

http://lists.busybox.net/pipermail/busybox/2006-September/058617.html

Это переписка тогдашнего мейнтейнера Busybox(он, после этого, стал автором Toybox), с Брюсом.

Мейнтейнер, конечно, тогда тоже был не прав, потому что удалил авторство Брюса вот над этими "закрывающими скобочками", но Брюс, конечно, очень плохой человек - он настаивает на том, что он является автором busybox, даже если там не осталось его кода. Очень интересная идея, конечно.

GNU, кстати, согласно с такой трактовкой - один раз автор - всегда автор. Поэтому GNU/Linux, даже если кода GNU у тебя сейчас уже нет(не верите? А попробуйте собрать какую-нибудь #autohell приблуду с gnu triplet, содержащим linux, но не содержащим gnu).

Зачем издания форсят этот унылый мем, что "автору busybox" там кто-то мешает вести бизнес, я не понимаю. Он уже давно не автор.

———
Busybox или Toybox?

Мне, конечно, ближе идея toybox(http://www.landley.net/toybox/faq.html#why_toybox).

Я не верю в деньги или славу от OSS, это примерно как рассчитывать на деньги и славу от профессионального спорта - ну вот сколько вы знаете известных программистов? 100? 1000? Наверное, примерно столько же, сколько и спортсменов.

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

Поэтому toybox почти в каждом телефоне, а busybox на рутерах, и его оттуда постоянно выпиливают, потому что разработчики - склочные #GPL задроты.

Ну и на закуску - busybox про #systemd. https://busybox.net/kill_it_with_fire.txt

———
https://reviews.llvm.org/rG37e6bd8bc8da

К НГ новости совсем закончились, вот, llvm weekly предлагает, в качестве новости, вот такой вот коммит про очередной scope guard.

———
Пишут, что Линусу сегодня 52. Это, конечно, очень важно, и вот вам ссылка на запись одного из его самых первых выступлений на конференциях. Я не слушал, не фанат. https://www.facebook.com/maddoghall/posts/10159125354012025

Решил тут вечерочком собрать себе https://github.com/aristocratos/btop

Думал, задачка минут на 5, все зависимости уже в репе. Ага, конечно.

Судя по всему(в том числе, и по качеству кода, про которое в следующий раз), автор на этом проекте учил С++, и поэтому решил использовать все доступные фичи из C++20.

Например, библиотеку ranges, которой еще нет в clang-13(в полном объеме). Вообще, вопрос в сторону - какого хера авторы компиляторов не использовали готовый код от Эрика? У них там бесконечные ресурсы на перепиливание одного и того же говна? Про libc++ я точно знаю, что ее пилит полтора стажера. Вот какого, спрашивается, хера?

У меня было 2 пути:

* Заиспользовать оригинальные ranges-v3:
https://github.com/pg83/mix/blob/main/pkgs/sys/btop++/mix.sh#L22

Это оказалось достаточно просто, всего лишь фейкаем <ranges> на основе ranges-v3.

Разве что:

1) Релизные ranges-v3 несовместимы с clang-13, потому что лезут в потроха компилятора(https://github.com/ericniebler/range-v3/tree/master/include/std). Пришлось взять транковую версию.

2) Какой-то баг в clang, что он не дал подменить <ranges>, несмотря на корректную манипуляцию с -I, -isystem. Пришлось еще запатчить сами #include <ranges>

Но черт меня дернул, что негоже так хачить, и(второй путь)

* соберу-ка я libstdc++ для этого проекта. Дэээ, забыл, с кем имею дело(проект GNU), товарищи же всегда все делают самым ненатуральным образом. Я собрал, кажется, до меня это никто не делал, судя по объему правок и хаков:

1) Форсим кросс-компиляцию, обманываем насчет host платформы, так как авторы libstdc++ шибко умные(нет), и запрещают кросс-компиляцию если host == target. https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L32

2) Небольшие хаки из-за несовпадения названия некоторых intrinsics:

https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L37

3) https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L42

Самая мякотка. GNU собирают свою библиотеку с разными настройками -std=, разные исходники с разной настройкой. И некоторые аспекты того, что компиляторостроители подразумевают под стандартами, отличается от компилятора к компилятору. Например, авторы g++ очень хотят constinit в c++17, но этого же не существует, поэтому они добавляют кличевое слово __constinit. Оно не работает в clang. В clang есть constinit в с++20, но для этого нужно для этого конкретного файла поменять стандарт, с которым мы его компилируем. Сделал я это через wrapper для clang.

4) В clang aligned new, sized deallocation под опциями. https://github.com/pg83/mix/blob/main/pkgs/lib/c++/std/mix.sh#L53 Включать для c++98 нельзя, что-то ломается в потрохах libstdc++

Короче, собрал, но бестолку, потому что clang не сумел прожевать ranges от libstdc++.

Думаю, собрать всю эту ветку дерева с g++, как того и хотел автор(но это уже в другой раз), потому что с libc++ btop неверно обрабатывает пользовательский ввод. long story про это в следующий раз, а нетерпеливые могут посмотреть на https://github.com/aristocratos/btop/pull/227

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

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

Ну ладно, ладно, обознался. Чувак норм, я ему все объяснил по существу, патч он принял.

Код, конечно, выглядит так, как будто кто-то не справился с починкой сегфолтов от неопределенного порядка разрушения global static, я ему впилил _Exit(), чтобы голову себе не морочить.

Приятный чувак, давненько я в code review так не расшаркивался - "ой, я сделаю, как ты считаешь нужным - нет, делай сам, тебе виднее - ой, ну что ты, хорошо".

Вообще, кодовая база оставляет о себе впечатление "писал вменяемый чувак, просто местами не понимал, как оно внутри работает". Судя по треку bashtop -> bpytop -> btop++, так оно и есть.

https://github.com/aristocratos/btop/issues/5 - вот тут ему, конечно, уже предложили все на Rust переписать.

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

Уязвимости - это как ходить в лес, за грибами. Нашел один - поищи рядом, обязательно найдешь еще.

———
https://www.rogdham.net/2017/03/12/gif-md5-hashquine.en

Если вы думали, что мне подарить на НГ(ну или там на ДР), то вот, прекрасный вариант. Конечно, эту конкретную гифку дарить не нужно, нужно сделать такую же, но с моими инициалами!

———
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ad964f7eaef9c03ce68a01cfdd7fde9d56524868

На прошлой неделе(неделе линкера!) кидал текст про то, как авторы gcc восприняли предложение поддержать #mold в gcc. Но стоило прийти "правильному" человеку, c "правильным" патчем, как все вдруг заткнулись. Впрочем, этим страдают вообще все IT проекты, которые я знаю(и не только OSS), чего уж тут.

———
https://ariadne.space/2021/12/29/glibc-is-still-not-y2038-compliant-by-default/

Тут вот жалуются, что #glibc неправильно подошли к проблеме y38, а musl - правильно. Ну так я спешу огорчить товарищей, что "оба неправильно". Это они просто не видели, как к ABI подходят вменяемые люди, например, разработчики WinAPI(для тех, кто в танке - в каждую структуру с запросом в WinAPI пишут версию(например, размер структуры, который хорошая версия, если поля только добавлять)). А glibc, musl - это так, детские шалости.

Я ничо не понял, но, кажется, это, наконец, про porno + Deep Learning. 30 лет жду.

https://github.com/liaoxiong3x/DeepCreamPy (божечки, название просто огонь)

———
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20211227/992076.html

С моим подходом к разработке запилить новый таргет в LLVM я не смогу никогда. Ну и вообще, документ какой-то "запретительный". Как-то это не круто - типа, сделайте всю работу, а мы подумаем, нужна ли нам такая архитектура, или нет.

———
https://devblogs.microsoft.com/oldnewthing/20211229-00/?p=106061

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

Узнал красивое:

"Indeed, there’s no requirement that the code bytes for the RemoteThreadProc function be contiguous at all! Profile-Guided Optimization will rearrange basic blocks, and the code for a single function may end up scattered across different parts of the program, depending on their usage patterns."

Оказывается, PGO умеет не только функции переставлять, но и отдельные блоки так, что код функции перестает быть непрерывным. Интересно, много ли это дает, и умеет ли #LLVM так.

———
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-2021-Tops
https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-D3D12-Mesa-SSBO
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-22.0-Build-macOS-Zink

У #Mesa все хорошо. Microsoft коммитит в Mesa, Valve коммитит в Mesa. Впрочем, Microsoft не забывает и про альтернативу - https://github.com/microsoft/angle (ссылку я привел, чтобы показать, что MS контрибутит в #ANGLE, сама репа deprecated) Я так понимаю, Microsoft думает, как же у нее в дальнейшем будет устроен OpenGL over DirectX. #zink

———
https://www.opennet.ru/opennews/art.shtml?num=56429
https://www.phoronix.com/scan.php?page=article&item=kde-gnome-wayland21&num=1

Ни на грош не верю тестам от Phoronix, да и сравнение это, скорее, композиторов, а не технологий.

It is a shame, что, для того, чтобы игры не тормозили, в Wayland композиторе надо написать кучу кода.

Что я имею сказать по поводу НГ?

Скажу, что, пожалуй, лучший новогодний фильм это Love Actually, и он есть на КиноПоиске!

Ну и кусочек фильма(правда, больше это похоже на backstage, но не суть) со снегурками в ленту!

https://www.youtube.com/watch?v=eJGqWXSW49I

Держим кулачки за "я устал я ухожу"!

https://github.com/rswinkle/PortableGL

Софтверная реализация чего-то, похожего на OpenGL.

https://github.com/h0MER247/swGL

Или вот еще одна.

https://docs.mesa3d.org/relnotes/21.3.3.html

Bugfix релиз #Mesa. Классный changelog, коротко и по делу:

"Mesa 21.3.3 is a bug fix release which fixes bugs found since the 21.3.2 release."

———
https://garrit.xyz/posts/2021-12-31-btrfs-on-alpine

Про то, как автомонтировать разделы с btrfs на Alpine Linux. Новость довольно бессмысленная, но она меня заставила задуматься, не ломает ли такое использование init мою концепцию "мешка сервисов". IMHO нет, не ломает.

В заметке описан хак вида "как бы нам запустить произвольную команду перед командой mount all, а, у нас же есть зависимости в сервисах, сделаем для этого фейковый сервис".

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

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

———
https://nullprogram.com/

Классный блог про вещи, которые вам вряд ли когда-то понадобятся. "как ускорить ненужно в 4 раза", "как запустить ненужное в ненужном", и так далее. Но написано с огоньком.

———
Продолжаю рассказывать про свой перфекционизм, бессмысленный и беспощадный.

Например, вот стандартная MIT Licence, от github:

https://github.com/pg83/testrepo/blob/main/LICENSE

А вот моя редакция:

https://github.com/pg83/mix/blob/main/LICENSE

(Нет, я не сумасшедший, я скрипт написал. Хороший, кстати, скрипт, он учитывает, что лучше поставить лишний пробел между AB CDE, чем между A BC).

https://robert.ocallahan.org/2021/12/do-we-really-need-link-step.html, пишет нам какой-то городской сумасшедший, и тут же переизобретает косой и кривой линкер.

"An obvious problem is how to handle symbol resolution, i.e. what happens when the compiler emits code for a translation unit that uses symbol A from some other unit --- especially if that other unit hasn't been compiled yet? Here's an option for function symbols: when A is used for the first time, write a stub for A to the final binary and call that. When a definition for A is seen, patch the stub to jump to the definition. Internally this will mean maintaining a parallel hashtable of all undefined symbols that all compiler instances can share efficiently."

———
https://tjournal.ru/news/500911-mincifry-nachalo-peregovory-s-hp-acer-i-lenovo-o-predustanovke-rossiyskih-operacionnyh-sistem-na-kompyutery #altlinux

ALT, ASP изжили себя после внедрения UTF-8(кстати, задачка вам в ленту - https://elementy.ru/problems/2689/Yunikod_na_Novyy_god) и быстрых и дешевых сетей.

* Настроить русский язык в Linux до повсеместного перехода на UTF-8 было очень сложно.

* Скачать пару компакт-дисков по рублю за мегабайт(это мой реальный первый тариф, причем рубли 2000-го года) - очень дорого. Я, помнится, тогда жил на 1000 в месяц, и горя не знал.

ASP честно сдох, ALT решил выжить любой ценой. Как в России выживают нерыночным способом - мы все знаем, не маленькие.

Результат, конечно, немного предсказуем.

———
#fontconfig
Программисты не любят договариваться. Ну, ладно, люди вообще не любят договариваться.

Поэтому мы, например, имеем https://www.freedesktop.org/wiki/Software/fontconfig/

Это такая библиотечка, которая по строчке "Arial;size=22" должна вернуть "/usr/share/fonts/arial.ttf". Не, реально, вот это она и делает, и все. Каталогизирует доступные шрифты в системе.

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

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

Поэтому мы имеем:

* библиотеку, которая принудительно влинковывает в себя полный рендер шрифтов(а как же еще узнать свойства шрифта в файле?), xml parser(потому что правила матчинга написаны на xml), и еще говна самовар. Конечно, даже и в этом случае этих зависимостей можно было бы избежать, но библиотека же ДОЛЖНА уметь классифицировать любой подвернувшийся файл!

* Библиотека из каждого приложения регулярно ходит в fs, чтобы посмотреть, не появились ли там новые шрифты. Сука, ИЗ КАЖДОГО.

* В качестве оптимизации - библиотека ходит не по всей fs, а только в несколько файликов, куда утилита fc-cache складывает результат грепа шрифтов по FS. fc-cache, конечно, тоже не запускается регулярно, потому что это же договариваться пришлось бы.

https://lkml.org/lkml/2022/1/2/187

Титаническая работа, чего тут еще сказать.

Добавлю:

* Признаться, я удивлен, что проект на C довел себя до такого состояния. Все же, это больше свойственно проектам на С++, когда 1 маленький шаблон генерит мегабайты кода(ну, AST, разница невелика).

* Какой автоматикой он пользовался, чтобы понять, что лишнее включено в конкретный .h? Для clang мы ее все знаем.

* "I also improved build speed by
consolidating .c files into roughly equal size build units. Instead of 20+
separate .o's, there's now just 4 .o's being built."

Ахаха, #JOIN_SRCS()

* Интересно, есть цифры про сборку ядра с clang?

———
https://izzys.casa/2021/12/wrapping-up-2021/

Хороший текст про С++, Rust, Zig, и, в меньшей мере, про Swift.

Swift мне из этих языков кажется самым интересным, а то, что он плохо поддерживает Windows - ну так, знаете, сами MS и виноваты.

Пока они были сильные, их политика "сделать все по другому" приносила плоды со знаком +, а теперь приносит плоды со знаком -.

Человечеству IMHO пора уже определиться с тем, сколько корней у root fs, и отменить fork(), как обязательное требование к POSIX, и будет всем счастье.

(Про Zig там волшебно - "Zig also is not an option for me as its clearly written by someone who hates the idea of destructors and implicit behavior, of abstracting your thoughts away in a “set it and forget it” kind of manner. Zig somehow manages to go a step further and feel like I’m writing LLVM bitcode but with control flow constructs. I’d rather just not touch it.")

———
https://graphitemaster.github.io/aau/ #unsigned

Хороший текст про то, почему signed int плохо, а unsigned - хорошо.

Хотел было написать по этой теме много текста, но, КМК, индустрия уже рассудила меня и "3 выходцев из NIVAL"(да, вы все знаете, о ком я), которые топили за signed int.

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

* Возможность вернуть sentinel в любом месте - зло. Гениальные авторы оригинального кода уходят, приходят новые люди, которые не знают, может ли конкретная int f() вернуть число < 0, == -1, или только >= 0, и начинаются проверки на пустом месте, и забытое протаскивание ошибок наверх. А потом в биллинге регулярно вычитаем -1 с чьего-нибудь счета. Плавали, знаем.

* Главный аргумент - reverse iterator по массиву. А часто ли его приходится использовать? Ну и, кстати, в статье очень норм техника для обхода массива в обратном порядке с unsigned индексом, я про такую и не знал.

http://ryanhileman.info/posts/lib43
https://gist.github.com/jboner/2841832

Специально поместил эти две ссылки рядом, чтобы желающие смогли на пальцах прикинуть, сколько времени должен исполняться типичный #autohell ./configure script. По моим прикидкам, если бы не sleep-ы в ядре Linux, секунд 5. А не 1 - 2 минуты, как сейчас.

———
https://www.mattkeeter.com/projects/synthesis/

Классный текст про использование SAT solver. Я в своей карьере использовал SAT solver 1 раз, для какой-то задачки с Эйлера, но знать про такую возможность, конечно, полезно.

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

Очень хорошая подборка материалов - что важного и интересного произошло в 21 году. Заметьте, что в тексте очень много ссылок, и почти все они ведут на новости с opennet.

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

При этом, opennet, по современным меркам, очень странная площадка:

* Там есть Анонимус
* Все посылают друг друга нахуй
* Один из модераторов - фашист(не в смысле "плохой человек", а в смысле Википедии).

При этом:

* Там полное ощущение свободы и вольнодумия

* Даже этого модератора-фашиста все кроют хуями, а он в ответ не раздает банхаммер направо и налево(вот его лог модерирования - https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az=list&forum=vsluhforumID3&open=moderator&n=Michael+Shigorin)(а на большом числе ресурсов модераторы не ссат показать такой лог?)

* Встречаются прямо очень интересные комментаторы.

И вот это слабо почищенное говно читать приятнее, чем эти ваши выхолощенные HN, и прочую левацкую поебень.

На самом деле, сравнивая opennet и HN, лично я прихожу к выводу, что свобода слова таки должна быть абсолютной, а желающие что-то запретить мне читать пускай настроят фильтр себе(а не мне).

Вот как предлагают бороться с троллингом на opennet - https://www.opennet.ru/tips/3195_ublock_filter.shtml

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