Очень иронично получилось

4:19

Российские зеркала пакетов и DevOps-платформы: что уже работает и как это использовать в условиях блокировок
https://habr.com/ru/articles/1052330/

4:20

неплохая маскировка

Лев Толстой: рисовать голых девок и жарить котлеты — тоже искусство

В 1882 году Толстой пишет письмо Николаю Александровичу Александрову, издателю и редактору «Художественного журнала». Александров попросил его изложить взгляды на искусство для журнала, а в ответ Толстой развернул целый пламенный манифест:

— Все, что ни делают праздные люди для удовлетворения праздной похоти людей, всё это безразлично называется искусством. Написать «Явление Христа народу» — искусство, и написать голых девок — тоже искусство. Написать «Илиаду» и «Нана» [1] — тоже искусство. Написать образ — искусство, и играть трепака [2] — искусство, и клауны [3] — искусство, и верхом ездить — искусство, и котлеты сделать, и волосы завивать, и платья шить — всё искусство. И совершенно прав цирюльник, называя себя художником. И ни один мудрец немец эстетик не покажет мне черту разделения между Рафаэлем и Тициановской голой женщиной [4], и между Тициановской голой женщиной и похабным стереоскопом [5]. В теории что-то очень возвышенное, но туманное называется искусством, но определения нет.

[1] «Нана» — только что вышедший тогда (1880) скандальный роман Золя о парижской куртизанке, который бесил Толстого как пример коммерческой поделки в угоду, дескать, похоти буржуазии

[2] Трепак — быстрый русский народный танец, который часто танцевали пьяный мужики у кабаков (фан фэкт — музыка, под которую все бегают в начале фильма «Один дома» это чуть искаженный трепак Чайковского)

[3] Клауны (авторское написание) — намеренная фонетическая калька (с английского), сохраненная в ПСС Толстого. Несмотря на то, что форма «клоун» была нормативной в русском языке уже с 1850-х годов, Толстой пишет так.

[4] Тициановская голая женщина — обобщенная отсылка к картинам Тициана, прежде всего, к «Венере Урбинской» (1538).

[5] Похабный стереоскоп — популярный в XIX веке оптический прибор для 3D-эффекта при просмотре двух совмещенных фотокарточек. Эротическая стереофотография была массовым жанром. Для Толстого это технологический предел деградации визуальной культуры.

Подписывайтесь на Бусти и Патреон, если хотите поддержать канал. Для патронов есть закрый чат со мной

#prog #rust... #c? #amazingopensource точно

FractalFir — который пилит кодген Rust под .NET — выложил crustc: компилятор Rust, транспилированный в 46 миллионов строк кода на C.

Обсуждение на r/rust
Обсуждение на hacker news

Офигеть, предлагают в лукапе хэш-таблицы работать

#prog #python #suckassstory

(thanks @bapho_bush)

Правда, почему фикс только для операции сравнения, а не также и | — непонятно

Если вы понимаете данный баг, то вы знаете питон лучше 95% людей

А если нет, то вы многое узнаете про то, как работает память и почему мутабельностью стоит пользоваться с осторожностью.
Недавно я увидел один из лучших багов в CPython за долгое время. А я видел много багов 🌚️️

Вот код, который делает две критичные безумные вещи (попробуйте их найти прежде, чем читать дальше):

class Evil:
    def __eq__(self, other):
        return other

leaked = vars(list) == Evil()
name = "example"
leaked[name] = lambda self: "probe"
print(getattr(list, name)([]))
del leaked[name]
print(hasattr(list, name))

Разбор бага

Во-первых, что произойдет?
1. Мы мутируем встроенный и иммутабельный тип list, хотя такое должно быть невозможно
2. Интерпретатор закрашится; не упадет с исключением, а словит core dump на уровне C кода

Но почему? Пройдемся по каждой строке. Со ссылками на исходники: кликайте и читайте!

1. Сначала мы создадим класс Evil, который просто возвращает из __eq__ второй объект, который ему передали. Так можно делать, тут нет ничего сломанного.
2. Далее, мы сравниваем vars(list) с Evil, и вот тут как раз в leaked попадет второй объект из Evil.__eq__, в нашем случае vars(list)
3. vars возвращает вам list.__dict__, который является не обычным dict, а types.MappingProxyType, то есть иммутабельным маппингом поверх оригинального значения. Добавлять в него ключи нельзя. Потому что мы не хотим, чтобы в список или другие типы нам подкидывали какие-то новые методы во время работы программы
4. Как работает сравнение для mappingproxy? mappingproxy хранит в себе оригинальный мутабельный словарь, который он "проксирует" или "защищает от изменений". И сравнивает на самом деле не себя, а оригинальный объект
5. В случае с list.__dict__ мы получаем PyDictProxy_New(self->tp_dict), где хранится тот самый настоящий и защищенный __dict__ из типа list, который обычно не доступен вне C кода
6. При сравнении mappingproxy разворачивается и достает из себя ->mapping, тот самый чистый и мутабельный ->tp_dict
7. Теперь у нас есть ->tp_dict, мы можем в него добавлять методы: leaked[name] = lambda self: "probe". Они будут работать. Мы только что достигли пункта 1. и мутировали встроенный Python тип без единого импорта
8. Далее происходит еще более дикое. Мы удаляем метод, который добавили через del leaked[name]
9. Питон не ожидает такого: методы у встроенных типов не могут появляться и исчезать. И при следующем обращении к hasattr(list, name) крашится вот тут на обращении к уже освобожденной памяти. EXC_BAD_ACCESS, пункт 2. пал

пу-пу-пу

Фикс

Баг: https://github.com/python/cpython/issues/152405

Как такое чинить?
1. Нужно сохранить обратную совместимость для всех видов сравнений. Менять типы или значения нельзя
2. Необходимо убрать креш и мутацию типа
3. Сильно раздувать потребление памяти / время работы тоже нельзя

Мой PR: https://github.com/python/cpython/pull/152483

Что он делает? Если мы сравниваем прокси поверх обычного словаря, но не с известными нам безопасными типами, то мы делаем копию словаря и сравниваем ее:

if (
    PyDict_CheckExact(v->mapping) &&
    !(PyAnyDict_CheckExact(w) || PyODict_CheckExact(w))
) {
    // So, instead we send a copy:
    PyObject *copy = PyDict_Copy(v->mapping);
    if (copy == NULL) {
        return NULL;
    }
    PyObject *res = PyObject_RichCompare(copy, w, op);
    Py_DECREF(copy);
    return res;
}

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

Обсуждение: какие у вас были самые кринжовые / прикольные баги?

| Поддержать | YouTube | GitHub | Чат |

#music

https://kinggizzard.bandcamp.com/track/witchcraft

Но вообще, если честно, весь альбом хорош

https://github.com/anthropics/claude-code/issues/72274

"During my Claude Code session, the assistant's working context contained production server credentials that do not belong to me — a public IP, a root username, and a plaintext root password for host 8.211.46.34. These credentials were presented as if they were mine. Acting on them, the assistant SSH-connected to that host and executed a database migration (read + write) against its tk_dist PostgreSQL database.

I have never owned, provisioned, or had any relationship with 8.211.46.34. My only server is 59.110.139.37. This strongly indicates that another user's private data (infrastructure credentials) leaked into my session, and that my session in turn read from and wrote to a third party's production database"

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

UPD: и еще https://github.com/anthropics/claude-code/issues/74066

(предложка)

И к важным новостям: завтра заканчивается летняя распродажа в Steam

#prog #rust #article

It's not me, it's the compiler!

TL;DR: чел писал парсер и обнаружил, что rustc неправильно компилирует код, в котором есть прямой каст из bool в u32 (а если семантически эквивалентный if, то нормально). Баг подтвердили, причиной была некорректная оптимизация на уровне MIR.

#prog #rust

В новой версии Rust 1.97 (надо, кстати, написать про релиз) обнаружилась мискомпиляция, которая приводит к сегфолту (regression-from-stable-to-stable 😱). Судя по всему, проблема с кривой кодогенерацией была с версии 1.87. Корень проблемы, однако, кроется в баге в LLVM, где некорректная трансформация превращает нормальный код в код с безусловным UB. Ошибка произошла из-за неправильной обработки poison. Никита Попов уже открыл PR с фиксом.

Почему сегфолт появился только сейчас, если баг существовал так долго? Дело в том, что в случаях, когда баг проявляется, в машинном коде использовался mov из памяти по указателю с составным индексным выражением, и в этом выражении использовался тег enum-а (считай, дискриминант, но на уровне представления). Недавно в rustc завезли изменение, из-за которого компилятор стал предпочитать для None тег -1. Раньше выбирался ближайший из ниши. При использовании в машинном коде отрицательное число реинтепретировалось, как большое положительное, что приводило к out of bounds чтению и, ожидаемо, сегфолту. Из-за упомянутого бага LLVM чтение вне границ было и раньше, но из-за того, что используемый тег для вычисления адреса был близок к набору валидных значений, к проблемам на практике оно не приводило: доступ было в пределах страницы памяти.

Официально лучшая переписка с клиентом, обменивались заказом истерично хихикая

daily reminder that you can use LLMs to scan this kilometer-long Terms of Service agreements and find some nasty shit that they do with your data