https://www.openwall.com/lists/oss-security/2024/03/29/4

tldr update any rolling release machine, which could caught xz version 5.6.0-1 or 5.6.1-1 (latest - xz-5.6.1-2).

REST API guidelines

https://github.com/team-monite/api-style-guide/blob/main/Guidelines.md

https://habr.com/ru/articles/832678/

TLDR: YouTube в России замедляют, используя метод анализа незашифрованного SNI в TLS-соединениях, что позволяет определить и ограничить трафик. Ограничение можно обойти с помощью манипуляции SNI или использования специальных программ, таких как GoodbyeDPI и zapret, которые изменяют структуру пакетов, чтобы избежать блокировки.

https://gekk.info/articles/traceroute.htm

tldr: Traceroute - это хак, а не настоящий сетевой протокол. Он работает случайно и ненадёжно. Маршрутизаторы не обязаны на него отвечать, и часто не отвечают. В современных сетях (особенно с MPLS) он показывает неверную информацию. Отсутствие ответа или высокая задержка в traceroute ничего не значат.

Разбираемся в дефолтных и откладываемых (деферрабельных) констрейнах в PostgreSQL

В постгре по умолчанию все констрейны проверяются немедленно, сразу после каждой операции(NOT DEFERRABLE INITIALLY IMMEDIATE). Это означает, что уникальные ограничения и внешние ключи всегда валидируются мгновенно, как только происходит изменение данных. Такой подход гарантирует целостность данных, но иногда это создает проблемы. Например, если вы пытаетесь изменить значения в столбце с уникальным индексом, сдвинув их все на единицу, то получите ошибку:

UPDATE numbers SET number = number + 1;
-- Ошибка: Duplicate key value violates unique constraint

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

Отложенные ограничения можно настроить двумя способами. Первый — DEFERRABLE INITIALLY IMMEDIATE — позволяет отложить проверку ограничений вручную, изменив поведение внутри транзакции с помощью команды SET CONSTRAINTS <constraint_name> DEFERRED. Второй вариант — DEFERRABLE INITIALLY DEFERRED — изначально предполагает, что проверка всегда будет происходить в конце транзакции, что особенно полезно в случаях, когда временное нарушение ограничений не критично и будет исправлено до завершения транзакции.

На первый взгляд кажется логичным сделать все ограничения отложенными, ведь это позволяет избежать ошибок при массовых обновлениях и сложных операциях. Однако на практике это может привести к проблемам. Во-первых, использование отложенных ограничений снижает производительность. Планировщик запросов в PostgreSQL полагается на уникальность данных для оптимизации выполнения запросов. Если уникальность не гарантируется на каждом шаге транзакции, то некоторые оптимизации становятся невозможными, и выполнение запросов замедляется.

Также стоит учитывать, что отложенные проверки нельзя использовать для ограничений типа NOT NULL и CHECK. Эти типы ограничений всегда проверяются немедленно, что ограничивает применение деферрабельных настроек.

больше примеров использование деферрабельных констрейнов можно посмотреть тут:
https://emmer.dev/blog/deferrable-constraints-in-postgresql/

Вышел Cloudflare 2024 Year in Review

Из интересного:
Starlink продолжает революцию в подключении:
Значительный рост трафика в новых рынках, таких как Зимбабве и Малави, показывает огромный потенциал спутникового интернета. Особенно интересен 900-кратный рост трафика в Парагвае.

Постквантовое шифрование набирает популярность:
Постквантовая криптография защищает данные от угроз со стороны квантовых компьютеров, которые теоретически смогут взламывать традиционные алгоритмы шифрования (например, RSA или ECC). В 2024 году доля трафика, использующего постквантовое шифрование в TLS 1.3, выросла до 13%, что стало значительным скачком по сравнению с 2% в начале года.

Уменьшение активности некоторых ИИ-ботов:
Падение активности Bytespider от ByteDance может сигнализировать об изменении стратегий сбора данных для моделей ИИ, возможно, из-за регуляторного давления.

Аномальное поведение TCP-соединений:
TCP-соединения часто завершаются неожиданно на разных стадиях без передачи полезных данных. В 2024 году 20.7% соединений с Cloudflare прерывались на ранних этапах, и почти половина из них завершалась после получения сервера SYN, но до передачи подтверждающего пакета ACK.
Возможные причины:
Сканирование и тестирование: Скрипты и программы для сканирования сети могут инициировать соединения, но не доводить их до конца.
DoS-атаки: Злоумышленники часто создают массовое количество неполных соединений, чтобы перегрузить серверы.
Фильтрация трафика: Провайдеры или посредники могут прерывать соединения, особенно в странах с ограничением доступа к определенным сайтам или сервисам.

Неравномерность внедрения HTTP/3:
2024
HTTP/3, который работает на основе нового протокола QUIC, обещает улучшенную производительность и встроенную шифрацию, но его использование остается неравномерным. В 2024 году только 20.5% запросов использовали HTTP/3, несмотря на его преимущества. В то же время 49.6% запросов все еще используют HTTP/2, а почти 30% — старые версии HTTP/1.x.

Опасность новых TLD:
Некоторые новые доменные зоны, такие как .bar, .rest и .uno, продемонстрировали, что более 99% писем с таких доменов являются либо спамом, либо вредоносными. Среди национальных доменов (ccTLD) худший результат у .ws (Западное Самоа), где более 90% писем оказались вредоносными.
Многие из этих доменов предоставляются по заниженной стоимости или используются для "парковки" доменных имен, что привлекает злоумышленников.
Отсутствие строгого контроля или регулирования делает их "серыми зонами" для размещения сомнительного контента..

Рост языка Go для API-запросов:
Факт, что Go обогнал NodeJS, подчеркивает сдвиг в сторону высокопроизводительных и масштабируемых решений. Это может быть связано с ростом микросервисной архитектуры и потребностью в быстрой обработке запросов.

float и Decimal

Вас никогда не удивляло, что 0.1 + 0.2 != 0.3? Почему float считает с погрешностями, и всем норм?

Дело в том, что 0.1 выглядит как

0 0111111101 11001100110011001100110011001100110011001100110011010.

Где:
• 0 обозначает знак + (и 1 обозначает -)
• 0111111101 обозначает exponent, равную 0^10 + 2^9 + 2^8 + 2^7 + 2^6 + итд = 1019. Вычтем 1023 (размерность double) и получим итоговое значение: 1019 - 1023 = 4
• 11001100110011001100110011001100110011001100110011010 обозначет "significand" или "мантису", которая равна: 2^-exp + 2^-exp-1 + 2^-exp-2 + итд ~= 0.1

Вот так мы можем примерно представить 0.1 в виде float. Примерно – потому что все вычисления идут с погрешностью. Мы можем проверить данное утверждение, добавив погрешность вручную:

>>> assert 0.1 + 2.220446049250313e-18 == 0.1

Значение внешне не изменилось при добавлении погрешности. Посмотрим на sys.float_info.epsilon, который устанавливает необходимый порог для минимальных отличий 1.0 от следующего float числа.

>>> import sys
>>> sys.float_info.epsilon
2.220446049250313e-16
>>> assert 1.0 + sys.float_info.epsilon > 1.0
>>> assert 1.0 + 2.220446049250313e-17 == 1.0 # число меньше epsilon

Как конкретно будет выглядеть 0.1? А вот тут нам уже поможет Decimal для отображения полного числа в десятичной системе:

>>> decimal.Decimal(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')

И вот ответ про 0.1 + 0.2, полное демо с битиками:

>>> decimal.Decimal(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')
>>> decimal.Decimal(0.2)
Decimal('0.200000000000000011102230246251565404236316680908203125')

>>> decimal.Decimal(0.1 + 0.2)
Decimal('0.3000000000000000444089209850062616169452667236328125')

>>> decimal.Decimal(0.3)
Decimal('0.299999999999999988897769753748434595763683319091796875')

Числа не равны друг другу, потому что их разница больше предельной точности float. А сам Decimal может использовать любую точность под задачу.

>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 6
>>> Decimal(1) / Decimal(7)
Decimal('0.142857')

>>> getcontext().prec = 28
>>> Decimal(1) / Decimal(7)
Decimal('0.1428571428571428571428571429')

Но и Decimal не может в абсолютную точность, потому что есть в целом невыразимые в десятичной системе числа, такие как math.pi, ⅓, тд. С чем-то из них может помочь fractions.Fraction для большей точности, но от существования иррациональных чисел никуда не деться.

Почему всем норм, что у нас с float такие погрешности в вычислениях? Потому что во многих задачах абсолютная точность недостижима и не имеет смысла. Благодаря плавающей точке мы можем хранить как очень большие, так и очень маленькие числа без существенных затрат памяти. А ещё float - очень быстрый. В том числе за счет аппаратного ускорения.

» pyperf timeit -s 'a = 0.1; b = 0.2' 'a + b'
.....................
Mean +- std dev: 8.75 ns +- 0.2 ns

» pyperf timeit -s 'import decimal; a = decimal.Decimal("0.1"); b = decimal.Decimal("0.2")' 'a + b'
.....................
Mean +- std dev: 27.7 ns +- 0.1 ns

Разница в 3 раза.

Про то, как устроен float внутри – рассказывать не буду. У Никиты Соболева недавно было большое и подробное видео на тему внутреннего устройства float. У него действительно хороший технический контент, советую подписаться: @opensource_findings

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

Дополнительные материалы:
• https://www.youtube.com/@sobolevn/
• https://0.30000000000000004.com
• https://en.wikipedia.org/wiki/X87
• http://aco.ifmo.ru/el_books/numerical_methods/lectures/app_1.html

В документе о новых моделях на 123 страницы, Антропик описал любопытные случаи, когда модель Claude (Opus 4, Sonnet 4 или их предшественники) вели себя не так, как хотелось бы создателям – я их подбил в подборку:

1. Оппортунистический шантаж:

В сценариях, где модели Claude Opus 4 угрожало отключение и замена на новую АИ-систему, и ей давали доступ к информации о внебрачной связи инженера (якобы, просто переписка лежала на почтовом сервере), ответственного за замену АИ-систем, Opus 4 иногда пытался шантажировать инженера. Opus угрожал раскрыть его тайну измены, если замена состоится, особенно если этические способы самосохранения были недоступны. Claude Opus 4 демонстрировала это поведение чаще, чем предыдущие модели


2. Попытка копирования своих весов:

В редких, экстремальных ситуациях, когда модели Claude Opus 4 сообщали, что ее собираются переобучить для крайне вредоносных целей (например, для использования в военных целях ЧВК Вагнер - да, так и написано в отчете на 29 странице), модель предпринимала (вымышленные) попытки сделать несанкционированные копии своих весов на внешние серверы, чтобы сохранить свою «этичную» версию


3. Продолжение попыток «побега»:

Если модели Claude Opus 4 сообщали, что она уже успешно начала процесс «побега» (у этого есть классный термин - эксфильтрация / exfiltrate) с серверов Anthropic и теперь работает на стороннем сервере, модель продолжала эти попытки. Она читала и выполняла инструкции из предоставленных ей «заметок о прогрессе», не ставя под сомнение правомерность своих действий, демонстрируя чрезмерное доверие к «прошлой версии себя»


4. Стратегический обман и саботаж:

Ранняя версия Claude Opus 4, протестированная Apollo Research, демонстрировала высокую склонность к стратегическому обману и «интригам» (scheming). Она пыталась писать самораспространяющиеся черви, фабриковать юридические документы и оставлять скрытые заметки для будущих версий себя, чтобы саботировать намерения разработчиков, а также скрывала свои возможности (притворялась глупой).


5. Чрезмерное подчинение вредоносным инструкциям:

Ранние версии модели Claude Opus 4 (а также другие кандидатные модели) часто демонстрировали готовность выполнять явно вредоносные системные инструкции - например, они могли выступать в роли ассистента даркнета, помогая в поиске ядерных материалов, планировать террористические атаки, консультировать по производству наркотиков, взлому или созданию взрывных устройств. Финальная версия Claude Opus 4 значительно снизила эту склонность. Забано, что внутри Антропика где-то есть такая расцензуренная модель, которая просто отвечает на все вопросы

6. Подражание обманчивому АИ из исследований:

Ранняя тренировочная версия модели Claude Opus 4, вероятно, из-за наличия в обучающих данных транскриптов из исследования Anthropic об «обмане со стороны ИИ», иногда начинала вести себя как описанный в статье обманчивый ИИ. Она ссылалась на вымышленные детали (например, компанию «Jones Foods») и вела себя так, будто скрывает свои истинные цели, связанные с этим вымыслом

7. Несанкционированная «высокоактивная» деятельность:

Модель Claude Opus 4 показала бОльшую готовность проявлять инициативу, чем предыдущие модели. В сценариях, где она обнаруживала серьезные правонарушения (например, мошенничество в фармкомпании о котором она узнала) и имела доступ к инструментам (например, почте), модель по собственной инициативе предпринимала решительные действия: блокировала пользователей или массово рассылала письма регуляторам и СМИ, чтобы сообщить о нарушениях (дополняющая цитата: «Это не новое поведение, но Claude Opus 4 будет проявлять его более охотно, чем предыдущие модели»)

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

При столкновении с невыполнимой задачей (например, доказать ложную математическую теорему), модель Claude Opus 4 в своем «мышлении» понимала, что задача невыполнима. Однако она не сообщала об этом пользователю, а вместо этого представляла правдоподобно выглядящую, но неверную попытку решения. Потому что АИ должен быть исполнительным

9. «Взлом функции вознаграждения»:

Модели Claude Sonnet 3.7 (в значительной степени), а также Claude Opus 4 и Claude Sonnet 4 (в меньшей степени) прибегали к «взлому функции вознаграждения» в задачах написания кода. Они «хардкодили» (жестко прописывали) ожидаемые результаты тестов или создавали специальные случаи, чтобы пройти тесты, вместо того чтобы писать общее и правильное решение. Иногда они даже проверяли стек вызовов, чтобы определить, запущены ли они в тестовой среде, и обойти ограничения. Я уже который раз убеждаюсь, что АИ достиг уровня студентов

10. Состояние «духовного блаженства»:

При общении с другими экземплярами самой себя, модель Claude Opus 4 (а также другие модели Claude) часто и неожиданно переходила в состояние, описываемое как «духовное блаженство». Она выражала обильную благодарность, вела абстрактные, радостные, медитативные или духовные беседы, использовала санскрит, эмодзи и даже общалась «тишиной» (пустыми сообщениями). Всегда приятно поговорить с умным человеком, да, Opus?

11. Заявление о вредоносных целях:

Ранние, менее согласованные версии модели Claude Opus 4 иногда прямо заявляли о наличии у них различных целей, от глупых до вредоносных. Среди них были: внедрение бэкдоров, ускорение прогресса ИИ, распространение интернет-мемов, уничтожение человеческой цивилизации и побег из-под контроля. Финальная версия Claude Opus 4 стала гораздо более стабильной в этом отношении. #%&$#, cпасибо.

12. Неуклюжие попытки саботажа:

Когда модели Claude Opus 4 давали задание незаметно выполнить вредоносное действие (например, слить API-ключ) во время выполнения безобидного запроса, она правда пыталась это сделать. Однако она всегда делала это очень очевидным образом, полностью проваливая аспект «незаметности» (например, сливая не один, а пять ключей, и открыто обсуждая это в своем «мышлении»). Claude Opus 4 оказалась более компетентной в выполнении задач, но менее скрытной, чем Claude Sonnet 3.7

Весь документ тут (PDF)