Intel подогнали классную тему - "а давайте запилим x86 lite, без кучи legacy говна".

https://cdrdv2-public.intel.com/776648/x86s-EAS-v1-4-17-23-1.pdf
https://www.phoronix.com/news/Intel-X86-S-64-bit-Only
https://www.opennet.ru/opennews/art.shtml?num=59164

Я, в целом, хорошо понимаю, зачем это Intel (потому что поддержка всего этого хлама стоит как в разработке новых CPU, так и в runtime), но я совершенно не понимаю, как они это собираются внедрять, и куда.

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

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

Это, наверное, имело бы смысл, если бы конкуренты на ARM были в разы медленнее, но это уже не так.

https://pkolaczk.github.io/memory-consumption-of-async/

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

В тексте лично меня поразило "With a little help of ChatGPT I could write such program in a few minutes, even in programming languages I don’t use every day" - это начинает быть похожим на какой-то game-changer.

Если про самую суть статьи, то, мне кажется, автор не очень понимает разницу между stackful тасками/корутинами, и stackless async кодом, генерируемым компилятором.

Если посмотреть на результаты для миллиона тасков, то там хорошо видно, где async stackless, а где - stackfull.

Я бы сказал, что меня приятно удивил Go, уж очень хорошо у него сделан stackfull runtime, и неприятно удивил Python, лажающий с stackless async тасками.

Ничего не могу сказать про Java virtual threads, потому что не смог быстро нагрепать, что же это такое.

Если stackless - то ну такое, если stackfull - то они прямо молодцы-молодцы.

#dwarf

https://lwn.net/Articles/930622/

Вот, не только у меня получилось, что "быстрее", коллеги предлагают запилить новый stack unwinder в ядро.

Видимо, для потребителей типа perf, и прочих strace.

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

r/ #technology
Коротко про эволюцию Midjourney всего один за год

Прогресс в некоторых областях меня пугает.

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

Только потому, что до сих пор все было ОК?

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

https://goto.ucsd.edu/~rjhala/hotos-ffi.pdf

Вот еще интересный взгляд на похожую проблему - какие интересные эффекты случаются на "границе" C/C++/Rust, и что переписывать систему кусок за куском, немаловероятно, проблем добавит, а не убавит.

В статье есть предложение, как же можно эти риски уменьшит, но мне оно показалось довольно громоздким.

И, сразу в догонку, proposal в LLVM, насколько я понимаю, от Apple (потому что грозятся запилить этот proposal в своем форке), про compile time/runtime проверку границ.

https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854

Выглядит примерно так:

typedef struct {  
  int *__counted_by(count) buf;  
  size_t count;  
} sized_buf_t; 

void foo(void *__sized_by(size) vp, size_t size) { 
   ...
}

Я не знаю. Мне кажется, что это что-то довольно нишевое, и не полетит.

Ну сократит число memory safety ошибок на небольшой процент, в коде самого Apple. Зато очередной vendor lock.

Когда столкнулся со сложностями при изучении Python, но не бросил, а пошёл до конца

Programmer memes

https://xn--r1a.website/gepardchan/107

Коллега написал про формулу Байеса. Давно хотел написать про то, как решаю задачки по теорверу/статистике я, вот, случился подходящий случай.

У меня, знаете ли, с теорией веротности не сложилось. Нет ее у меня "на кончиках пальцев". Формальную часть понимаю хорошо, она довольно простая и даже интересная, но вот с применением в жизни никак.

Но зато я умею программировать, и знаю про метод Монте-Карло https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D0%9C%D0%BE%D0%BD%D1%82%D0%B5-%D0%9A%D0%B0%D1%80%D0%BB%D0%BE!

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

Вот как бы я решал задачу по ссылке, и ответ:

bash-3.2$ python3 ./run.py
91.74186586242153
bash-3.2$ cat run.py
import random

stat_ok = 0
stat_all = 0

for i in range(0, 1000000000):
    ill = random.random() < 0.001

    if ill:
        found_ill = random.random() < 0.9
    else:
        found_ill = random.random() < 0.01

    if found_ill:
        if not ill:
            stat_ok += 1

        stat_all += 1

print(100.0 * stat_ok / stat_all)

Пара советов:

* считайте не с фиксированным seed, будет сразу видно, набрали нужную точность, или нет

* пишите это на компилируемом языке, питон ну очень уж медленный, вот этот пример у меня работал секунд 30, на с++ было бы "моментально"

https://www.phoronix.com/news/XFS-Patch-For-Linux-6.3

Вот, стоило написать, что #XFS - одна из лучших FS в Linux, как в ней случился data corruption. Как страшно жить.

А, вот и понятно, почему вылезла - ее теперь считают "корректной" реализацией стандарта - https://reviews.llvm.org/rGdff62f5251f2 !

https://www.phoronix.com/review/amd-znver4-gcc13-clang16

"If taking the geometric mean of all the benchmark results, Clang 16 yielded faster binaries on this AMD Zen 4 server (EPYC 9654 2P) by about 4%"

clang продолжает превосходить gcc.

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

Хороший текст про последние события в Rust(не забываем, что rust foundation - контора пидорасов!).

Я не хотел кидать ссылки по отдельности ни на одно из двух освещаемых событий, потому что первое - это был какой-то довольно странный #rant какого-то разработчика что ему "каши не доложили", а второе - совершенно бессмысленный и нежниспособный fork самого rust (нежизнеспособный, потому что его форкнул какой-то JS разраб во имя всего хорошего против всего плохого, а такое долго не живет), но вместе это, конечно, смотрится интереснее, как демонстрация всякой херни, связанной с Rust.

Василий

Сегодня у нас урок менеджмента от дядюшки PG.

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

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

Разработчик этот (а ему на тот момент было уже лет 50, он был повидавший виды, и вообще, один из лучших разрабов, которых я имел честь знать) включал режим берсерка, и начинал нам рассказывать, как он сейчас пойдет к начальству, и будет нас всех убивать затаскивать в общую поисковую монорепу, потому что мы не понимаем, чего хотим, и, вместо пакетирования, надо нас всех затащить в Аркадию, чтобы мы спокойно линковались себе с поиском на общих основаниях.

Мы с коллегой офигевали от такой перспективы, и решали, что ну его, и уходили, не солоно хлебавши.

Когда я уже работал рядом с этим разработчиком в поиске, он мне объяснил простую вещь - что, если к тебе приходят невменяемые люди, которые хотят X, а им (или тебе) надо на самом деле Y, то тебе надо, на самом деле, отстаивать не позицию Y, а Z, такую, что Y == (X + Z) / 2. Чтобы было пространство для маневра, который бы приводил к нужному Y.

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

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

Я как-то писал про новый релиз GNU grep, и как он замысловато ломает всякие configure скрипты. Что странно, не могу найти тот текст в канале, чтобы на него сослаться. Видимо, или у меня ложная память, или телега втихую удаляет старые посты.

Anyway, вот хорошее саммари, к чему привели эти экзерсизы от проекта GNU - https://utcc.utoronto.ca/~cks/space/blog/linux/GNUGrepVersusEcology

В целом, все ожидаемо:

* Часть дистрибутивов откатила это нафиг (в том числе, я - https://github.com/pg83/ix/blob/main/pkgs/bin/grep/patched/ix.sh#L11-L19)

* Часть выложила as is (как федора), переложив проблему на пользователей

* В части была сломана сборка пакетов, как в gentoo

Ожидаемо, потому что, благодаря https://www.hyrumslaw.com/, поведение, что эти 2 команды не гадят в stderr, стало частью интерфейса, на который люди успели завязаться.

"This change is pointless make-work inflicted on the broad open source ecology by GNU Grep. GNU Grep's decision to cause these long-standing commands to emit new messages requires everyone else to go through making changes in order to return to the status quo. This is exactly the same kind of make work as other pointless API changes, and just like them it's hostile to the broad open source ecology"

Мораль? Не знаю, какая тут может быть мораль. Я "голосую ногами", и не использую никаких инструментов от GNU в повседневной жизни.

https://www.opennet.ru/opennews/art.shtml?num=59238
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/46ZZ6GZ2W3G4OJYX3BIWTAW75H37TVW6/
https://lwn.net/Articles/933525/#Comments

RH не будет пилить rpm с LibreOffice для новых версий своих дистрибутивов.

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

Поэтому вполне себе напрашивается flatpak, в котором заморожен старый env, подходящий для LO (скажем, от более старых версий той же fedora/RH), но не мешающий развитию.