Hacker News Digest

В JavaScript "🤦🏼‍♂️".length == 7 — не ошибка, а результат подсчёта UTF-16 кодовых единиц.
Эмодзи состоит из 5 скалярных значений Unicode, но в UTF-16 они занимают 7 code units:

• 🤦 U+1F926 → 2
• 🏼 U+1F3FC → 2
• ZWJ U+200D → 1
• ♂ U+2642 → 1
• VAR-16 U+FE0F → 1

Итого 7 — именно это и возвращает .length.

Другие языки считают по-своему:

• Python 3 → len("🤦🏼‍♂️") == 5 (кодовые точки, но допускает суррогаты).
• Rust → "🤦🏼‍♂️".len() == 17 (байты UTF-8).
• Swift → "🤦🏼‍♂️".count == 1 (расширенный графем-кластер).

Каждый подход отвечает на свой вопрос: «сколько code units / bytes / графем». Ни один не универсален; выбор зависит от задачи.

• Обсуждение вокруг статьи показало, что «длина строки» не имеет единого определения: бывают байты, UTF-16/UTF-32 код-юниты, скалярные значения Unicode и расширенные графем-кластеры.
• Пользователи жалуются, что разные языки и API возвращают разные числа для одного и того же эмодзи, что ломает UI-ограничения, индексы БД и обработку текста.
• Часть участников считает, что нужно явно различать «длину для хранения», «длину для отображения» и «длину для человека»; другие мечтают вернуться к чистому ASCII.
• Примеры кода на Java, Python, Raku и JS показывают, как получить каждый из вариантов длины, но подчеркивают отсутствие общего стандарта.
• Итог: «length» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.

Top Secret — новая open-source библиотека от thoughtbot для удаления чувствительных данных из произвольного текста.

Проблема: регулярки не ловят всё (имена, адреса, карты). Решение: смесь regex и NER (распознавание именованных сущностей) через гем mitie-ruby.

Как работает:

1. TopSecret::Text.filter заменяет сущности на токены [PERSON_1], [LOCATION_1] и возвращает mapping.
2. После ответа LLM вызываем TopSecret::FilteredText.restore, чтобы вернуть реальные значения.

Пример:

input  = "Ralph lives in Boston."
filtered = TopSecret::Text.filter(input)
#=> "[PERSON_1] lives in [LOCATION_1]."
mapping  = { PERSON_1: "Ralph", LOCATION_1: "Boston" }

response = "Hi [PERSON_1]! How is the weather in [LOCATION_1]?"
TopSecret::FilteredText.restore(response, mapping: mapping)
#=> "Hi Ralph! How is the weather in Boston?"

Подходит для чат-ботов, где нужно скрыть персональные данные, но сохранить контекст.
Код и демо: GitHub и стрим.

• Обсуждают лёгкий NER-фильтр на базе MITIE для автоматического скрытия чувствительных данных в строках.
• US Marshalls уже заинтересовались такой «авто-редактурой».
• Участники предупреждают: NER не 100 % точен, модель старая (~10 лет) и плохо переносится на новые домены.
• Возникает вопрос, можно ли применять фильтр к стримингу/шерингу экрана: технически возможно через accessibility-API, но нужно определять координаты сущностей и бороться с ложными срабатываниями.
• Для продакшена с длинными диалогами 1 с на инференс может быть медленно; логировать через LLM-фильтр тоже рискует «убить» скорость.

21 августа 2025
Инцидент Cloudflare ↔ AWS us-east-1

• 16:27 UTC — один клиент на AWS us-east-1 резко увеличил объём запросов к кэшу Cloudflare.
• Проблема — ответный трафик переполнил прямые линии пиринга между Cloudflare и AWS, вызвав высокую задержку, потери пакетов и сбои до origin-серверов.
• 19:38 UTC — влияние существенно снизилось; остаточные задержки до 20:18 UTC.
• Масштаб — только трафик между Cloudflare и AWS us-east-1; глобальные сервисы не пострадали. Это не атака и не BGP-хайджек, а перегрузка каналов.

Почему произошло

Cloudflare работает как обратный прокси: если контент не в кэше, запрос идёт к origin-серверу клиента. Внутренняя сеть рассчитана с запасом, но несколько edge-линков к AWS-оборудованию оказались недостаточны для внезапного скачка. AWS, пытаясь снять нагрузку, отозвала часть BGP-префиксов, что лишь перенаправило трафик на ещё более узкие каналы через офф-сайт интерконнект.

Что делаем дальше

1. Увеличим пропускную способность всех линков к AWS us-east-1.
2. Внедрим более агрессивное автоматическое шейпирование трафика, чтобы локальные перегрузки не распространялись.
3. Улучшим алгоритмы балансировки и отказоустойчивости между пиринговыми точками.
4. Добавим ранние оповещения и автоматические сценарии отключения «проблемных» клиентов при аномальном росте трафика.

Приносим извинения за неудобства и благодарим за терпение.

• Один клиент Cloudflare сгенерировал всплеск трафика, перегрузив каналы к AWS us-east-1 и вызвав отказ.
• Проблема усугубилась тем, что AWS автоматически отозвал BGP-маршруты, а резервные линии оказались недостаточными.
• Участники обсуждают необходимость пер-клиентских лимитов, rate-limiting на краю сети и улучшенной наблюдаемости.
• Некоторые считают, что единственное долгосрочное решение — уход из us-east-1 из-за хронических проблем масштабирования.
• Возникли шутки и догадки о том, кто именно был «тем самым клиентом».

• История: от pre-fork до epoll — каждый шаг уменьшал сисколлы, но они всё ещё оставались узким местом.
• io_uring — кольцевые очереди в памяти: сервер пишет команды, ядро асинхронно их выполняет и кладёт результат обратно. При высокой нагрузке strace не покажет ни одного сисколла.
• 1 поток = 1 ядро без разделяемых структур; память берётся только из локального NUMA-узла.
• Память: заранее выделяем фиксированный буфер на соединение — без brk/mmap, без фрагментации.
• kTLS — после рукопожатия шифрование переходит в ядро. Плюсы:
  1. Работает sendfile, данные не копируются в userspace.
  2. Возможно аппаратное ускорение NIC.

• io_uring даёт «zero-syscall» при высокой нагрузке, но требует ручного управления памятью: безопасность не обеспечивается ни borrow checker, ни runtime.
• На большинстве облачных платформ io_uring выключен по умолчанию, поэтому остаётся нишевым.
• Автор статьи сначала чистит код, а потом будет мерить производительность — что вызвало одобрение читателей.
• Обсуждаются альтернативы: epoll, kTLS, DPDK, eBPF, а также споры «один поток на ядро» vs oversubscription.
• Некоторые считают, что сложность io_uring и async Rust — цена за неспособность ОС ускорить syscalls без нарушения обратной совместимости.

Всё коррелировано

В реальных данных почти все переменные связаны между собой, и корреляции не исчезают при росте выборки. Это ставит под сомнение стандартное нулевое гипотезное тестирование: при достаточном объёме данных нулевая гипотеза всегда отвергается, а отказ от отвержения лишь говорит о нехватке данных. Даже направленный эффект подтверждает теорию лишь на 50 % — как случайное угадывание.

Исторические заметки

• 1904 — «Student» (Госсет) замечает, что в биометрии всё связано.
• 1920 — Торндайк формулирует «всё связано со всем».
• 1938–39 — Берксон и Торндайк подтверждают: корреляции не случайны.
• 1950-е — Гуд, Сэвидж, Фишер обсуждают «всё-равно-ложную» нулевую.
• 1960-е — Наннали, Бакан, Мил указывают на бессмысленность p > 0.05.
• 1976 — Лёлин и Николс: в исследовании 850 близнецов 90 % пар переменных коррелированы.
• 1990-е — Мил: «фактор грязи» (crud factor) делает большинство «подтверждений» иллюзорными.
• 2000-е — Уоллер, Килгарриф, Старбак повторяют: «всё коррелировано» в психометрике, лингвистике, экономике.
• 2013–2023 — Гельман, Лин, Киркегорд, Шен, Гордон, Дауни: эмпирические датасеты подтверждают закономерность.

Практические выводы

• Любая теория предсказывает не только наличие, но и размер эффекта; без него подтверждение тривиально.
• «Спарсность» (редкие ненулевые связи) в соцнауках — миф.
• Вместо p-value нужны байесовские оценки и априорные модели размера эффекта.

• Статистическая значимость ≠ практическая важность: p-value лишь показывает, насколько «хорошо» измерена разница, но не её смысл.
• Многие наблюдаемые корреляции — «фоновый шум» данных; без эксперимента или теории они бесполезны.
• Большие N и множественные проверки порождают ложные значимости, особенно если гипотезы формулируются постфактум.
• Критика статьи: смесь верных статистических замечаний с политическими спекуляциями и отсутствием практических рекомендаций.
• Вывод: нужны эффект-размер, каузальные методы и заранее заданные гипотезы, а не охота на p < 0.05.

Почему античиты не работают в Linux

Доля геймеров на Linux растёт благодаря Steam Deck и надоедливым «фичам» Windows. Однако почти все сетевые хиты с античитом не запускаются или не подключаются к серверам: PUBG, Call of Duty, Rust, R6 Siege, EA FC 24, Destiny 2, Valorant, League of Legends и даже FACEIT/ESEA для CS2.

Как работают читы и античиты

Чит либо внешний процесс, читающий/писующий память игры, либо внедрённая DLL. ОС не даёт процессам трогать чужую память благодаря виртуальному адресному пространству: каждая программа «думает», что владеет всей ОЗУ, а процессор и ядро переводят виртуальные адреса в реальные.

Античиты борются с этим двумя путями:

1. Пользовательский режим – сканируют память, читают файлы, ловят подозрительные потоки. Легко обойти, если у чита есть root-доступ.
2. Ядро (kernel) – драйвер внутри ядра Windows имеет полный доступ к железу и памяти, может скрывать свои структуры и блокировать вмешательство. Vanguard, EAC, BattlEye и пр. работают именно так.

Почему это невозможно в Linux

• Linux — открытая система. Любой может собрать своё ядро, поставить патч, изменить ABI.
• Античиту нужен стабильный, неизменяемый и закрытый интерфейс ядра. В Linux этого нет: модуль, собранный под 6.9, не загрузится под 6.10, а пользователь может вообще отключить модульные загрузки.
• Даже если разработчик выпустит проприетарный модуль, сообщество его не примет: безопасность, GPL-лицензия, репутационные риски.
• Попытки «запечатать» Linux (secure boot + immutable образ) противоречат свободе системы и всё равно не гарантируют, что пользователь не пересоберёт ядро без проверок.

Что можно сделать

1. Играть в поддерживаемые игры: Apex, Fortnite, CS2, Elden Ring и др. уже работают через Proton.
2. Двойная загрузка или VFIO-виртуалка – запуск Windows в виртуальной машине с проброской GPU (сложно, но работает).
3. Облачный гейминг – GeForce NOW, Xbox Cloud и т.д.
4. Ждать – пока разработчики не придумают античит, который не требует закрытого ядра (маловероятно).

Вывод: пока Linux остаётся открытой системой, современные kernel-level античиты там жить не смогут.

• Критики считают, что анти-чит на уровне ядра — это по сути rootkit, который подрывает безопасность и конфиденциальность.
• Многие предлагают альтернативы: доверительные сообщества, выделенные игровые машины, серверные проверки или облачные платформы.
• Подчеркивается, что Linux по дизайну даёт пользователю полный контроль, что делает невозможным эффективный, но инвазивный анти-чит.
• Некоторые игроки готовы пожертвовать безопасностью ради «честной» игры, но большинство участников обсуждения считают такой обмен неприемлемым.

Внимание: перед воспроизведением отключите наушники!

Управляй колёсами тележки с телефона

Выбери систему:
Gatekeeper | Rocateq

Gatekeeper

Заблокировать | Разблокировать
(ссылки на .wav)

Rocateq

Заблокировать | Разблокировать
Активировать | Проверка покупки
(ссылки на .mp3)

Как работает

Колёса реагируют на сигнал 7,8 кГц от подземного кабеля. Тот же сигнал можно передать динамиком телефона, воспроизводя подготовленный файл. Держи смартфон рядом с колесом и нажимай «пуск».

Доклад DEFCON 29

• В Нидерландах и соседних странах колёса тележек почти не блокируются; чаще используется система «вставь €1».
• В США, Канаде и Германии блокировки популярны из-за краж бездомными, вандализма и эстетических требований торговых центров.
• Система вызывает побочные эффекты: плоские пятна на колёсах, шум, ложные срабатывания и раздражение покупателей.
• Некоторые хакеры уже экспериментировали с подделкой сигналов, блокируя или разблокируя тележки дистанционно.

Juno проработала вокруг Юпитера дольше, чем предполагалось, и переворачивает представления о гиганте.
Поля планеты увенчаны стабильными геометрическими циклонами размером с континенты; внутренности — не слоистые, а смешанные, «туманное» ядро легче ожидаемого.

Аппарат запущен, чтобы прочитать «запись рождения» Солнечной системы: Юпитер сформировался первым и хранит условия той эпохи.
Гравиметрия, магнитометры и радиолокаторы заглядывают под облака, измеряя состав, воду и глубину ветров.

Миссия стоила 1,1 млрд $; солнечные панели длиной с баскетбольное поле питают приборы, выдерживающие радиационный шторм.
В сентябре 2025 г. заканчивается расширенная фаза; аппарат рано или поздно погибнет в атмосфере.

Уже сейчас данные заставили теоретиков «выбросить учебники»: неизвестные полярные штормы, перемешанный интерьер, аномальное магнитное поле.
Как сказал руководитель проекта Скотт Болтон, «мы никогда не будем смотреть на Юпитер и Солнечную систему прежними глазами».

• Juno обнаружила ряд результатов, противоречащих теориям формирования планет, включая источник магнитного поля Юпитера.
• Участники делятся потрясающими снимками JunoCam и ссылками на архивы.
• Некоторые спорят с формулировкой «неоспоримый тяжеловес» системы, указывая на Солнце.
• Появился слух о возможном перехвате кометы C/2025 N1 ATLAS, но сообщают, что у зонда не хватит топлива.
• Упоминается пресс-конференция Apollo-11 и критика идей Авi Loeb со стороны NASA.

Google и Meta заключили 6-летний контракт на облачные услуги стоимостью более $10 млрд. Ранее Meta в основном полагалась на AWS и Microsoft Azure, теперь расширяет партнёрство с Google Cloud. Сделка усиливает позиции Google в борьбе за крупных клиентов и отражает общий рост инвестиций в ИИ-инфраструктуру.

• Meta тратит $65B+ на собственные дата-центры, но пока они строятся, арендует мощности у Google как у «перестраховки».
• Сделка может быть просто объединением старых GCP-проектов в единый корпоративный контракт.
• Google нужен контракт, чтобы остановить отток клиентов и продемонстрировать спрос на свои TPUs.
• Meta ценит именно уникальные TPU Google, которых нет у AWS/Azure.
• Спор о «лучшем» облаке: одни считают GCP слабым, кроме BigQuery и Cloud Run, другие ставят GCP выше «ненадёжного» Azure.

• Y Combinator подал amicus brief в поддержку Epic Games, заявив, что 30 % комиссия App Store подавляет стартапы.
• Участники YC жалуются: отчисления «съедают» маржу, мешают масштабироваться и привлекать инвестиции.
• Популярные модели freemium и подписки становятся невыгодными; многие проекты вынуждены повышать цены или закрываться.
• YC просит суд обязать Apple открыть альтернативные способы оплаты и снизить комиссию, чтобы сохранить конкуренцию и инновации.

• Участники считают, что Apple и Google образуют фактический дуополий, поэтому их магазины приложений нуждаются в регулировании.
• Ключевое требование — дать пользователям право устанавливать приложения из любых источников и разрешить альтернативные магазины.
• Комиссия 30 % называется неподъёмной для стартапов и препятствует появлению новых продуктов.
• Сравнение с инкубаторами вроде Y Combinator (7 % доли) признаётся некорректным: речь идёт о доле от выручки, а не от капитала.
• Некоторые отмечают, что в ЕС Apple уже вынуждена допускать сторонние магазины, а на macOS такая свобода существует давно.