https://tigyog.app/d/H7XOvXvC_x/r/goedel-s-first-incompleteness-theorem

Зумеры продолжают захватывать мир.

Теорема Геделя о неполноте в картинках. IMHO тема не раскрыта, лучше почитать википедию.

https://www.nature.com/articles/d41586-022-03256-9

"Authors’ names have ‘astonishing’ influence on peer reviewers. A Nobel prizewinner is six times more likely than someone less well known to get a thumbs-up for acceptance, finds study."

Между тем, в Гугле уже практикуют анонимные ревью. КМК, хорошая тема.

В продолжение темы про chroot - https://github.com/pg83/ix/pull/3/commits/0f09c401ffcd58ec46a7519edb0c2227a90cb1e8

Какой-то кривой патч, непонятно как работающий с симлинками в архиве(abspath не резолвит симлинки в путях), приехал ко мне от доброжелательного робота, видимо, фиксящего какой-то CVE в питонячке.

Нужен нормальный chroot, чтобы его можно было всем, и без рута, и в любой OS, и не нужно будет городить логику, повторяющую логику VFS на данной платформе.

https://lwn.net/ml/linux-kernel/CAHk-=wj6y5fipM2A5kEuOO9qm5PBzUY=-m9viEahhtxT09KR_g@mail.gmail.com/

"Talking about frustration, let me just say that after I got my machine sorted out and caught up with the merge window, I wass somewhat frustrated with various late pull requests. I've mentioned this before, but it's _really_ quite annoying to get quite a few pull requests in the last few days of the merge window.

Yes, the merge window is two weeks, but that's very much to allow me time to look things over, not "two weeks to hurriedly put together a branch that you send Linus on Friday of the second week". The whole "do an all-nighter to get the paper in the day before the dealine" is something that should have gone out the window after highschool. Not for kernel development.

The rule is that things that get sent to me should be ready *before* the merge window opens, not be made ready during the merge window. With some slack for "life happens", of course, but I really get the feeling that a few people treat the end of the merge window as a deadline, missing the whole "it was supposed to be ready before the merge window""

Линус жалуется на то, что ему присылают говнокод, и делают это к концу двухнедельного окна на слияние.

Я, конечно, хотел бы ему посочувствовать, но он сам построил такую немасштабируемую махину.

Мне в обсуждении предложили посмотреть на pledge(), а вот и рассказ про то, почему он не работает в Linux в полной мере - https://blog.gnoack.org/post/pledge-on-linux/

Кожаные математики показывают зубы.
Или.
Битва людей и машин началась.

Вчера писал пост о том, как АльфаТензор создал произведения искусства в области математики, уделал кожаных мешков на их поле и о том, почему математика - не наука.

Оказывается, математики почитали про успехи АльфаТензора, напряглись и подали виду.

Вот статья, которая начинается так:
"В ответ на недавнюю статью в Nature, которая объявила об ИИ-алгоритме для умножения 5х5-матриц с 96 умножениями, что на два меньше, чем предыдущая рекорд, мы представляем алгоритм, который выполняет работу только с 95 умножениями."

Они также представили новое(!) решение для 4 × 4-матриц, требующих 47 умножений - то есть ровно такое же, как сделал ИИ. Решений может быть много и разных, и счет идет на умножения.

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

Воистину ИИ делает кожаный род лучше, умнее и работоспособнее!

https://arxiv.org/abs/2210.04045

https://www.phoronix.com/news/USB4-v2.0-Specification

В комментариях как-то обсуждали разъем type-c, и было высказано предположение, что решение Евросоюза якобы замедлит развитие технологий.

Вот, пожалуйста, продолжение развития type-c, в 2 раза быстрее.

В целом, совершенно непонятно, зачем больше физических проводов, чем в type-c, для любой задачи по передаче данных!

Это, конечно, шутка, но в любой шутке есть доля правды.

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

Многие великие умы сломали мозг на тему, почему же математика так хорошо описывает окружающий нас мир. А я чем хуже?

Многие считают, что связь математики и реального мира - это машина Тюринга. Мне это кажется слишком притянутым за уши, и "избыточным", объяснением.

Я лично всегда считал, что эта связь - это аксиоматика натуральных чисел, например, https://ru.wikipedia.org/wiki/Аксиомы_Пеано

Эта аксиоматика вводит понятие индукции, или итерирования, если по человечески.

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

Поэтому математика так хорошо описывает известный нам мир.

Кстати, теоремы Геделя о неполноте - они именно про системы, включающие в себя арифметику, то есть, арифметика - это одна из самых простых известных систем, но достаточно сложная, чтобы содержать в себе "странные" утверждения. Совпадение?

(Почему она хорошо описывает микро- и макро- мир? А точно хорошо? Мне вот не нравится, как она это делает, выглядит несколько притянутым за уши, одна комплекснозначная волновая функция чего стоит)

У меня есть определенная "чуйка" на чтение changelog в OSS проектах.

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

Так, знаете ли, и сказать, и умолчать что-то.

Поэтому, когда я полез читать https://releases.llvm.org/14.0.0/tools/lld/docs/ReleaseNotes.html (не спрашивайте), то сразу обратил внимание на "Several performance improvements were done to speed LLD up on projects with a lot of framework flags and library lookups. Large Swift-based projects will benefit significantly. (D113073, D113063, D113153, D113235)"

Я практически взвыл от восторга, ожидая увидеть какой-нибудь линейный проход по списку параметров, но реальность оказалась еще интереснее:

https://reviews.llvm.org/D113073
https://reviews.llvm.org/D113063
https://reviews.llvm.org/D113153

Там прямо классический набор - читаем содержимое директорий(одних и тех же) много раз, читаем одни и те же файлы много раз, делаем stat на одни и те же файлы много раз, все это в разных контекстах.

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

Посмотрел на их код, однажды им предстоит изобрести еще и такую оптимизацию - если нам надо проверить наличие нескольких файлов в наборе директорий, то часто вместо вызова кучи stat() нужно сделать listdir() на все директории, и лукапить пути в хеш-таблицах.

Короче, mold vs. lld - это не "отличное против хорошего", это "человек сделал очевидные оптимизации" vs "на скорость положили с прибором".

https://www.oilshell.org/blog/2022/10/garbage-collector.html

Тут вот коллега пишет status update про oil shell.

Пишут, что занимались garbage collector. Ну, конечно, это основное, что надо пилить, когда ты решил запилить shell.

Я почему-то совсем не удивлен:

"We haven't finished our collector, but it passes many tests, and I believe we have good solutions to some tricky problems. I hope that experienced engineers will provide feedback, and help us with the code"

В псих больнице построили бассейн и установили 5 метровую вышку. Ну психи радостные прыгают. После плавания один псих забигает и кричит: "Ребта, если мы будем себя хорошо вести, то в бассейн и воду нальют.

Еще они пишут, что кто-то на это дал грант:

"with help from an NLnet grant"

Я явно чего-то в этой жизни не понимаю.

https://old.reddit.com/r/rust/comments/y4w2kr/llvm_used_by_rustc_is_now_optimized_with_bolt_on/

А вот коллеги применили #BOLT к llvm + rustc.

Пишут, что 3-5% перфа, но получилось применить только на llvm часть, rustc целиком оптимизднуть не получилось.

https://nitter.it/linaasahi/status/1583444549648543744

Между прочим, у #asahi linux какой-то серьезный прогресс за последние несколько месяцев. То год ничего не происходило(с точки зрения графического стека), то на тебе - проходят 99% dEQP - https://chromium.googlesource.com/angle/angle/+/main/doc/dEQP.md - в первый раз слышу, но:

"drawElements (dEQP) is a very robust and comprehensive set of open-source tests for GLES2, GLES3+ and EGL. They provide a huge net of coverage for almost every GL API feature. ANGLE by default builds dEQP testing targets for testing against GLES 2, GLES 3, EGL, and GLES 3.1 (on supported platforms)"

Ну, то есть, явно случилось что-то хорошее.

Еще отмечу, что раньше разработчик(хехе) проверял все на mac(ну, то есть, modesetting занимался mac, а он генерил и слал команды в карточку), то теперь там, в наличии, и modesetting driver для ядра(на rust, ага).

(в фанфары бить пока рановато, прогресс на уровне nouveau, но пользоваться уже можно)

https://github.com/carbon-language/carbon-lang/discussions/2329

У #carbon все еще нет компилятора, но уже есть "Carbon Language community transparency report".

Пишут, что отреагировали на 60+ "плохих" сообщений на discord. К сожалению, ссылок на сами сообщения нет, поэтому еда не очень годная.

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

http://davidbau.com/archives/2010/03/14/the_mystery_of_355113.html

Такая теория чисел нам нравится.

https://daniel.haxx.se/blog/2022/08/12/the-dream-of-auto-detecting-proxies/

Вот тут вот автор curl расписал, почему он не хочет к себе тащить зависимость от libproxy. Давно про нее хотел написать, вот, появился повод.

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

Потому что, в попытке решить простую проблему, добавляет в код кучу новых:

* #plugins Плагинная архитектура - куча загружаемых модулей, каждый под свой DE. Заменяем проблему поиска прокси в DE на поиск плагина для этого DE. Чем это плохо, много раз писал.

* Удивительный факт - плагины используются не по месту! По месу было бы, если бы плагины линковались с библиотеками этого DE, и тогда, действительно, имело бы смысл не загружать в себя чужеродный event loop. Проблема в том, что плагины не линкуются с кодом, а дергают subprocess - https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_kde.cpp#L47 Собственно, это вторая проблема - плагин дергает fork(), чего нельз делать в библиотеке общего назначения.

* Просто код всратого качество - какие-то плагины ловят исключения - https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_kde.cpp#L56, какие-то - нет. https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_gnome3.cpp#L130

* Велосипедизм. https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_gnome3.cpp#L61 - реализация popen2, плохого качества.

Короче, всячески НЕ рекомендую.

Как надо? Надо, конечно, узнавать это через dbus, через xdg portal. Или через переменные среды. Но уж точно не так.

А сегодня у меня короткий рассказ про то, почему же у нас все еще нет self driving cars на наших дорогах.

Дед опять забыл таблетки выпить

"Линус Торвальдс предложил прекратить поддержку CPU i486 в ядре Linux"

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

А, тем временем, на патчи про ускорение сборки ядра от Инго, кажется, положили болт.

#ingo

Я, знаете ли, довольно редко брюзжу в стиле "зачем A B, лучше бы С", обычно предпочитаю "какого хрена XYZ".

Но вот, в данном случае, хочется именно так - https://www.phoronix.com/news/Mesa-AGXV-Apple-Vulkan-VKCube

Какого хрена Зачем 2 сильных разработчицы(хехе) пишут одновременно opengl драйвер, и vulkan драйвер, когда есть прекрасный #zink, который может сделать opengl поверх vulkan? Лучше бы бросили все силы на vulkan драйвер.

(там есть такое полу-оправдание, мол, apple m1/m2 заточены под metal, и полный vulkan сделать для них невозможно, но IMHO оно так себе)