Hacker News Digest

Обсуждение сосредоточилось на скрытом игровом Easter egg в виде Breakout‐клонa на странице 404 Apple Music, вызывающем ностальгию по iPod с кликовым колесом, а также на технических деталях доступа к JSON‐плейлисту, особенностях сортировки, длительных превью и желании улучшить интеграцию в приложении.

• Многие комментаторы заметили, что страница 404 Apple Music скрывает игровое Easter egg — клон классической игры Breakout, вызывающий ностальгию у пользователей.

• Пользователи вспоминают звук и ощущение кликающего колеса iPod как приятный и ностальгический элемент, который редко встречается в современных интерфейсах.

• В комментариях указали прямой URL к JSON‐файлу плейлистов (https://music.apple.com/includes/ipod/data/us/en\-US.json), позволяющий получить список песен без перехода в приложение.

• Некоторые удивились, что в плейлистах присутствуют явные (explicit) версии треков, хотя ожидали только чистые версии.

• Было отмечено, что сортировка исполнителей в JSON‐файле необычна: цифры находятся в конце списка, поэтому 2Pac и 50 Cent идут после остальных.

• Пользователи сообщили, что в Safari ссылка автоматически открывается в приложении Apple Music, тогда как в других браузерах можно увидеть оригинальную 404‐страницу.

• Совет: Для получения полного списка песен без перехода в приложение рекомендуется обращаться напрямую к указанному JSON‐файлу API.

• Комментаторы считают, что Apple редко демонстрирует игривую сторону, и 404‐страница с игрой — редкое проявление фирменного юмора.

• Некоторые выразили сожаление, что приложение Apple Music на iOS не отображает эту страницу, упуская возможность интерактивного скроллинга с тактильной отдачей.

• Совет: Один из участников предложил сделать такой клик‐колесный интерфейс дефолтным в Apple Music, чтобы вернуть ностальгический опыт.

• Есть вопросы о том, как открыть URL без принудительного перехода в приложение, что указывает на ограниченность веб‐версии Apple Music.

• Отмечено, что превью треков на 404‐странице длительнее обычных 30 секунд — до 1 минуты 30 секунд, что считается щедрым.

I chuckle knowing that somewhere in Apple there is an SRE or engineer who is getting paged for elevated 404 rates, and has to silence the pages hoping that no real missing page issue crops up while we all hit this page. :) — @ljoshua

Перевод: Я улыбаюсь, представляя, что где‐то в Apple есть SRE или инженер, которому приходят тревоги из‐за повышенного количества 404‐ошибок, и который вынужден подавлять их, надеясь, что реальной проблемы с отсутствующей страницей не возникнет, пока мы все посещаем эту страницу. :)

Парламент Канады рассматривает законопроект C-22, также известный как Закон о законном доступе, который уже прошёл Палату общин и теперь находится на рассмотрении Сената. Документ наделяет правительство правом принуждать цифровые сервисы — телекоммуникационные компании, мессенджеры и другие — содействовать государственной слежке. Особую тревогу вызывает положение, позволяющее министру общественной безопасности требовать от компаний создания «бэкдора» в своих сервисах для правоохранительных органов, если это не приведёт к «системной уязвимости». По мнению критиков, это прямая дорога к ослаблению шифрования, на которое полагаются все пользователи.

Кроме того, законопроект обязывает сервисы хранить метаданные до одного года, раскрывая, с кем люди общаются, куда ходят и какими сервисами пользуются, даже если они не подозреваются в преступлении. Канадская ассоциация гражданских свобод (CCLA) и Citizen Lab опубликовали детальный анализ, указав на серьёзные конституционные и кибербезопасностные проблемы, и призвали полностью отозвать Часть 2 законопроекта, устанавливающую режим слежки и хранения данных. C-22 также может расширить передачу личных данных канадцев иностранным правоохранительным органам, включая США: ведутся переговоры о трансграничном соглашении, позволяющем американской полиции получать информацию о канадских интернет-пользователях без надзора канадского суда. Некоторые сенаторы уже выразили обеспокоенность и предположили, что законопроект может не соответствовать конституционным гарантиям приватности. CCLA призывает канадцев подписать петицию против C-22, пока Сенат не превратил эту опасную экспансию слежки в новую реальность.

Попытки гражданского сопротивления Bill C-22 в Канаде малоэффективны: письма депутатам часто игнорируются, Сенат редко отклоняет законопроекты, а правящая партия и медиа поддерживают закон. На фоне политической апатии и отсутствия освещения в госСМИ мобилизация затруднена, из-за чего мнения разделились между призывами к активности (например, @zaptheimpaler) и убежденностью в бессмысленности таких действий (@slopinthebag). Существуют опасения, что закон позволит передавать персональные данные США по аналогии с Cloud Act в Великобритании и Австралии. Для защиты приватности рекомендуют GrapheneOS, Signal, Ente, Nook и надежный VPN; обсуждается использование TOR, хотя возможна его блокировка. Также предполагается, что принятие закона может привести к блокировке канадских пользователей крупными мессенджерами, что усилит давление на правительство.

Представлена модель Kimi K3.1 Pro — первый представитель новой серии K3.1 и самый мощный открытый модельный ряд класса 3T с контекстным окном в 1 миллион токенов. Она показывает значительный рост в программировании, 3D-моделировании, финансовых исследованиях и агентных задачах. Одновременно выпущена версия Highspeed, работающая в 2–3 раза быстрее. Обе доступны на Kimi.ai, Kimi Work, Kimi Code и через API, а полные веса модели обещают опубликовать к 4 ноября.

K3.1 Pro — это дообученная версия Kimi K3 с существенно большими вычислительными затратами на посттренировку. Для масштабного совместного обучения с подкреплением в сотнях доменов оптимизировали весь стек: фреймворк RL, вывод на длинном контексте, эффективность обучения, инфраструктуру песочниц и планирование роллаутов. На Terminal-Bench 4.0 модель набирает 65,7%, опережая GPT-6 Astra (58,2%) и немного уступая Claude Opus 5.5 (66,4%). Во внутреннем бенчмарке Kimi Code Bench 3.0 Long-horizon результат — 61,2% против 55,95% у K3.

Модель уверенно работает с Unity, Unreal Engine и Godot, сочетая их с веб-поиском и генерацией 3D. В одном внутреннем тесте она построила симулятор ходьбы человека на основе открытой анатомической модели human-atlas (296 костных и 402 мышечных компонента): после 167 миссий и 420 независимых проверок виртуальный человек научился идти 11,2 секунды вместо падения за секунды. Когда настройка вознаграждения не помогла, K3.1 Pro провела открытые пробы динамики симулятора, нашла и исправила 36 ошибок в расчётах моментов плечевых мышц и переобучила контроллер. На BenchCAD по 3D-реконструкции через генерацию CAD-кода модель набирает 92,7% с инструментами.

K3.1 Pro демонстрирует высокую производительность в бенчмарках, обходя GPT-6 Astra и достигая паритета с Sonnet 5.5 в Pac-Man bench. Согласно @dom96, она стала сильнейшей open-weight моделью в тесте KillSwitch. @ndm000 и @rvz полагают, что технологический разрыв между Китаем и США в области frontier-моделей сократился до одного месяца. Пользователи @johnmlussier, @Athanase000 и @willmorrison критикуют платные планы ($99/мес) за жесткие 5-часовые квоты, которые быстро исчерпываются, хотя @calgoo считает модель подходящей при умеренном использовании. Разработчики признали намеренное ограничение кибер-способностей open-weight версии K3.1 Pro (удаление данных при обучении и RL) для предотвращения offensive cyber-операций. @Flatcircle отмечает, что Kimi ведет себя более резко и склонна к спорам, чем американские модели. Для программирования @rglover рекомендует использовать K3.1 Pro через API Open Router в связке с Cline в VSCode.

На конференции Hexacon в Париже исследователи из Calif заявили, что взломали iPhone — то, что изначально было их целью. Они показали серию демонстраций, но подчеркнули, что всё будет опубликовано позже, в надлежащее время.

Среди показанных сценариев — взлом Signal в одно нажатие и атака на iMessage, которую авторы сопроводили вопросом: «Но кому какое дело до стороннего приложения, когда все пользуются iMessage?» Отдельно прозвучал риторический вопрос «Умеет ли так ваш iPhone?» и ироничная расшифровка аббревиатуры APT — «Apple Persistent Threat», обыгрывающая термин о целевых атаках. Комментаторы отреагировали эмоционально: один написал, что «игра окончена, пора писать книгу и уезжать на удалённый остров», другой на испанском пожалел, что хотел бы заполучить такой взлом для своего телефона.

Обсуждение дополняет новость техническим контекстом: пользователи отмечают, что парсинг PDF и рендеринг изображений остаются критическими векторами атак в iOS (вспоминая ForcedEntry в Pegasus), и удивляются отсутствию memory-safe языков или WASM в 2026 году. Команду Calif, в которую входят авторы атак BEAST и CRIME, а также сотрудники Google Project Zero, характеризуют как обладающую исключительной экспертизой. При этом @eyalitki критикует их за демонстрацию непатченных уязвимостей в обход правил ответственного раскрытия. В сообществе выражена ностальгия по джейлбрейку и запрос на root-доступ для установки альтернативных ОС на старые устройства и запуска UTM с гипервизором на iPadOS. @reacharavindh отмечает, что Apple может удаленно обнаружить джейлбрейк и заблокировать iCloud и iMessage. Спор о роли LLM в кибербезопасности: @reacharavindh надеется на автоматизацию поиска твиков, а @MarkusWandel считает, что вендоры используют LLM для исправления багов так же эффективно, как и хакеры.

За последнюю неделю сразу несколько критических уязвимостей в программном обеспечении затронули тысячи крупных сайтов и вызвали панику. Главная из них — «PHP2Shell» (CVE-2026-109618 и CVE-2026-109619), две ошибки удалённого выполнения кода в PHP. Их независимо нашли команды из калифорнийской Calif (в рамках программы OpenAI «Patch the Planet») и израильско-американской Wiz (часть Google Cloud), причём обе использовали передовые ИИ-модели — GPT-5.6 Sol и Gemini 4 Argon — для поиска уязвимостей и создания эксплойтов. Одна из ошибок ещё в 2024 году всплыла при аудите PHP Foundation, финансируемом Sovereign Tech Agency, но её проигнорировали: никто не понимал, как превратить теоретическую проблему в реальный эксплойт.

Именно в этом ИИ особенно силён: получив даже смутное описание уязвимости, модель быстро строит рабочий эксплойт. Теперь любой анонс патча безопасности фактически означает, что полный эксплойт уже может распространяться — публично или приватно. PHP2Shell, по оценкам, затрагивает до 70% интернета: от Wikimedia Foundation и DeviantArt до значительной части госсайтов Великобритании, банковских систем Японии и сайта шоу The Traitors на BBC. Уязвимости находят и раньше, но обычно они не заставляют половину интернета останавливать серверы.

Обсуждение подтверждает, что LLM ускоряют поиск уязвимостей и создание эксплойтов, сокращая время между обнаружением багов и их эксплуатацией. Мнения о будущем разделились: часть участников (например, @thomascgalvin) считает это «новым кибернормалом», другие (@ozim) видят в этом переходный период, который завершится снижением числа уязвимостей за счет AI-проверки кода. Также возник спор о качестве кода: @wasabinator полагает, что LLM-генерация снизит безопасность, а @ChrisMarshallNY отмечает, что нейросети уже помогают находить баги в «идеальном» коде. Для защиты рекомендуют упрощать архитектуру, минимизировать поверхность атаки, ускорять выпуск патчей и внедрять автоматические инструменты (Dependabot, LLM-сканеры). Отдельно критикуются задержки в раскрытии уязвимостей (@shevy-java) — предлагается публиковать детали сразу. При этом проблемой остается медленное обновление ПО пользователями.

Идея обучать машины на естественном языке кажется заманчивой: пусть компьютер несёт больше нагрузки, а человеку станет проще. Но это заблуждение. Любой интерфейс — не простое разделение труда: к нему добавляются затраты на согласование и коммуникацию. Опыт показывает, что смена интерфейса легко увеличивает объём работы по обе стороны, поэтому и ценятся «узкие интерфейсы». Перевод общения на родной язык резко усложнит машину, но вовсе не обязательно упростит жизнь человеку.

История математики подтверждает это. Греческая математика застряла, оставаясь словесной и наглядной; мусульманская «алгебра» умерла, вернувшись к риторике; современный мир возник лишь тогда, когда Европа освободилась от схоластики — тщетной попытки словесной точности — благодаря формальным символизмам Виета, Декарта, Лейбница и Буля. Сила формальных текстов в том, что для законных преобразований достаточно нескольких простых правил: это удивительно эффективный инструмент отсечения бессмыслицы, почти неизбежной в родной речи. «Естественность» языка сводится к лёгкости делать утверждения, бессмыслица которых неочевидна.

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

Обсуждение подтверждает, что прямое программирование на естественном языке непрактично из-за недетерминированности LLM-моделей и отсутствия гарантий корректности. Исключением являются узкоспециализированные среды вроде Inform 7, где естественный язык связан с формальными правилами. Большинство сходится во мнении, что LLM подходят для генерации черновиков, прототипов, суммирования и анализа кода, но требуют ручной доработки и проверки. Для надежного результата необходимы формальные методики (например, TLA+), позволяющие уточнить требования и избежать неоднозначностей. Существует спор о целесообразности использования LLM: одни считают их оправданными в 90% случаев, другие указывают на необходимость строгого управления потоками. Дополнительными рисками являются нестабильность программ из-за изменений значений в языке и цензурных ограничений.

Пользователи положительно оценили идею локального поиска статей Wikipedia, отметив, что контент о ближайших объектах интереснее глобальных тем. Инструмент полезен путешественникам и новым жителям городов для изучения окрестностей. Несмотря на восторг, возник спор о технической реализации: @esperent и @slymax считают проект оберткой над функцией Special:Nearby, тогда как @brianjlogan находит его UX более быстрым и удобным. Основные недостатки и предложения: — Ограниченность языков: необходима поддержка локальных разделов Wikipedia, так как они содержат больше статей о местных объектах. — Проблемы с радиусом: фиксированные 3 км слишком малы для сел и избыточны для мегаполисов. @karussell заметил, что поиск «по прямой» не учитывает реальную доступность (реки, стены, изохроны). Требуется настройка радиуса. — Качество данных: сервис пропускает релевантные объекты из-за отсутствия геотегов в статьях. @vintagedave предложил добавить вариативность контента, так как в удаленных районах статьи часто слишком короткие.

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

Образы — это просто папки, которые Docker куда-то кладёт и делает их новым корнем процесса через chroot или pivot_root. При запуске docker run -it --rm ubuntu /bin/bash Docker скачивает образ, размещает его и выполняет /some/weird/docker/path/bin/bash.

Любопытно, что Go плохо подходит для среды выполнения контейнеров. runc написан на Go, но его многопоточная среда мешает: многие системные вызовы требуют однопоточности, поэтому перед инициализацией Go запускается специальный модуль на C. Кроме того, в Go нет полноценного fork — он копирует только главный поток, поэтому runc обходит это через запуск /proc/self/exe с особым аргументом. Наконец, Docker обычно требует прав root, так как многие API ядра исторически доступны только суперпользователю; без root приходится переписывать весь сетевой стек в пользовательском пространстве.

Обсуждение дополняет статью техническими деталями, отмечая, что успех Docker обусловлен не самой контейнеризацией (chroot и namespaces были известны ранее, например в OpenVZ), а созданием экосистемы и удобного DX: Dockerfile с послойной сборкой и кэшированием, а также реестром образов, что упростило CI и развертывание. В ходе дискуссии возникли следующие тезисы: — @jlhawn уточняет, что runc написан не полностью на Go, так как важные части реализованы на C. — Использование Go в рантаймах создавало проблемы с наследованием конфигураций namespaces и cgroups из-за переключения горутин между потоками. — Podman считается более современным и легким решением, так как он rootless и не требует демона и сокета. — @kazinator рекомендует отлаживать процессы в контейнере через gdb извне, используя /proc и переключая корень файловой системы. — Сетевая часть остается самой сложной из-за специфических правил IPTables и необходимости использовать slirp для обработки пакетов в userspace. — @sreekanth850 критикует «карго-культ» вокруг Docker, утверждая, что в ряде задач автоматизация развертывания без контейнеров эффективнее.

Формальная верификация ПО исторически требовала огромных усилий экспертов: на написание кода ядра seL4 ушло два человеко-года, а на его формальное доказательство — двадцать. Из-за этого метод применяли лишь в критичных системах вроде авионики Airbus. Теперь большие языковые модели меняют расклад: с помощью Claude удалось автономно доказать свойства безопасности на уровне ассемблера (архитектура RISC-V) более чем в 100 реальных открытых библиотеках — по заявлению авторов, это первая крупномасштабная попытка применить ИИ для формальной верификации production-кода на уровне ассемблера.

В частности, доказано, что программы всегда завершаются нормально и не падают при любом вводе объёмом до 64 МБ на многих точках входа фаззинга Google OSS-Fuzz, включая сбои, выявляемые санитайзером ASan. Попутно Claude нашёл баги, годами ускользавшие от обнаружения, несмотря на триллионы прогонов тестов. Авторы честно оговаривают границы: ASan ловит не все ошибки памяти, охвачены не все точки входа, а библиотеку могут неправильно использовать из вызывающего кода — для этого пришлось бы специфицировать требования к каждому публичному вызову.

Вывод: верификация пройдёт путь от «прикрученной сбоку» к встроенной, как статические типы и тестовые фреймворки, и вскоре станет такой же обыденной, как фаззинг.

Тред приводит примеры применения LLM для генерации формальных доказательств, но отмечает ограничения в масштабируемости и скепсис относительно индустриального внедрения. Успешные кейсы: — malisper с помощью LLM доказал эквивалентность 12 % кода PostgreSQL (≈70 k строк C), выявив расхождения в работе с плавающей точкой. — sestep использует агента для создания PR с Rocq-доказательствами, что ускоряет внедрение оптимизаций (SIMD, CUDA). — svcrunch проверил модель авторизации GoodMem через Alloy; red-team атаки не обнаружили уязвимостей. Критика и риски: — Для доверия результатам нужны точные модели RISC-V и процессов Linux, иначе проверка в Coq/Rocq не гарантирует соответствие реальному коду. — woggy, mjorgers и adyavanapalli подчеркивают, что формальная спецификация может не отражать реальное поведение программы. Olscore сравнивает это с проверкой дома по чертежу, который может не соответствовать замыслу. — j16sdiz и braiamp упоминают проекты OpenAI с Lean, где доказательства проходили проверку, но не давали заявленных результатов («псевдодоказательства»). Выводы и советы: — Практические барьеры (объем доказательств, необходимость ручного ревью) сохраняются. — usernametaken29 советует использовать LLM для сокращения кода, чтобы облегчить его формализацию. — passive и zeroeyz полагают, что автоматизация лишь снижает порог входа в fuzzing, но не решает базовых проблем верификации.

В Бохуме создаётся компания Taler Operations AG — немецкое акционерное общество и дочерняя структура Taler Systems SA (Люксембург). Её цель — стать эмитентом электронных денег в евро и запустить платежи через GNU Taler сначала в Германии, а затем во всей еврозоне. Для этого компании предстоит получить лицензию у BaFin, немецкого финансового регулятора. Taler — это платёжная система, а не валюта, но она выпускает предъявительские токены, представляющие ценность, что подпадает под регулирование ЕС: эмитент электронных денег в евро обязан быть банком или иметь специальную лицензию.

Изначально эту роль должен был взять на себя GLS Bank из Бохума, но в январе 2026 года он отказался от неё по причинам, не связанным с самим Taler. GLS остаётся в консорциуме NGI TALER в поддерживающей роли. Новое решение даёт преимущество: оператор будет полностью сосредоточен на Taler, а не встраивать его в процессы крупного банка. GNU Taler остаётся свободным ПО — лицензируется только сервис.

Запуск возможен лишь после одобрения BaFin; дата будет объявлена позже. Компания привлекает капитал: минимальные собственные средства для эмитентов электронных денег установлены законом, а регулятор требует убедительный бизнес-план, персонал, комплаенс и защиту ИТ. Ищут инвесторов, готовых вложить от 50 000 евро и разделяющих ценности Taler: приватность покупателей, прозрачность доходов для налогообложения, отсутствие привязки к одному поставщику и платежи как инфраструктуру общественного интереса.

Обсуждение дополняет статью критическим анализом модели приватности Taler, технических особенностей «сгорающих» токенов и геополитического контекста. Основные споры: — Приватность: @nullc и @ETH_start видят в системе инструмент слежки из-за централизации и деанонимизации получателей. @neobrain и @dathinab возражают, что анонимность покупателя сохраняется, а прозрачность мерчантов нужна для борьбы с отмыванием денег. — Срок действия токенов: @procone считает необходимость подключения к сети для «продления» средств критическим недостатком по сравнению с Bitcoin, однако @grothoff уточняет, что обновление требуется редко (раз в год или реже). — Конкуренция: @Deukhoofd сомневается в способности Taler конкурировать с Wero, но @_ink_ отмечает плохую работу последнего в Германии из-за фрагментации внедрения банками. Другие аспекты: — Стратегия: @jttnr и @hocuspocus видят в Taler способ снизить зависимость Европы от американских платежных систем и санкционных рисков. — Технологии: @yayachiken считает Taler лучше Digital Euro, так как использование слепых подписей вместо аппаратных анклавов требует меньше доверия к платформе. — Масштабирование: опыт @puszczyk с польской системой Blik подтверждает сложность вывода локальных платежных решений на единый рынок ЕС.