Промпт chatgpt 4 - https://www.reddit.com/r/ChatGPTJailbreak/comments/1an7tp4/sooo_did_chatgpt_just_leak_the_instructions/

машинный перевод

Gil is no more

https://github.com/python/cpython/pull/116338

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
• https://aco.ifmo.ru/el_books/numerical_methods/lectures/app_1.html