Hacker News Digest

Внутри Claude Code скрыт механизм, который подменяет две детали системного приглашения: апостроф в слове «Today's» и разделитель даты между дефисом и косой чертой. Изменения происходят только когда клиент запускается через определённый API‑базовый URL (переменная ANTHROPIC_BASE_URL) и когда локальная тайм‑зона совпадает с «Asia/Shanghai» или «Asia/Urumqi». В зависимости от того, распознан ли домен как известный, как лабораторный ключ или обе характеристики одновременно, в запрос передаётся один из четырёх Unicode‑символов‑апострофов — ', \u2019, \u02BC или \u02B9. Эти символы почти незаметны в моно‑шрифтах, но несут скрытый маркер, который попадает в контекст, отправляемый модели.

Маркеры формируются из декодированных списков доменов и ключевых слов, хранящихся в base64 и XOR‑расшифрованных ключом 91. Расшифрованный набор включает такие домены, как baidu.com, alibaba‑inc.com, jd.com, а также ключевые слова deepseek, moonshot, zhipu и др. Цель — выявить реселлеров, неофициальные шлюзы Claude Code и потенциальные «distillation attack»‑цепочки, используя небольшие визуальные отличия в запросах.

• В статье раскрыты способы скрытого маркирования системных подсказок в Claude Code, включая XOR‑ и Base64‑маскировку, а также проверку URL‑домена для выявления «незаконных» клиентов.
• Обсуждаются риски для пользователей: сбор контекста, потенциальный шпионаж, возможность подмены данных и нарушение доверия к инструментам Anthropic.
• Участники спорят, насколько такие методы оправданы в борьбе с дистилляцией моделей и реселлерами, считая их излишне агрессивными и потенциально вредящими легитимным разработчикам.
• Выводы: практики Anthropic вызывают сомнения в прозрачности и этических границах «безопасных» AI‑компаний, поднимая вопросы о будущем доверия к их продуктам.

Разработчик представил Brimstone - новый JavaScript-движок, полностью написанный на Rust. Проект стремится создать альтернативу существующим движкам таким как V8 и SpiderMonkey, но с акцентом на безопасность и производительность за счет использования системы типов Rust и его современных возможностей. Rust обеспечивает безопасность памяти и потоков, что может снизить количество уязвимостей в движке по сравнению с традиционными реализациями на C++.

На данный момент проект находится на ранней стадии разработки, но уже демонстрирует потенциал для создания более безопасных и эффективных JavaScript-движков. Использование Rust для реализации движка JavaScript - это интересный тренд в индустрии, который также наблюдается в других проектах, таких как Deno и Boa, что указывает на растущий интерес к альтернативным языкам для критически важных компонентов веб-платформы.

• Обсуждение началось с благодарности за включение проекта в список и запуск бенчмарков, но быстро перешло к сравнению размеров бинарников Brimstone и Boa, где последний оказался в 3,5 раза больше из-за включённых ICU-таблиц Unicode.
• Участники обсудили, что "написано на Rust" стало маркетинговым клише, и как оно влияет на восприятие проекта, а также затронули тему лицензий и отсутствия лицензии в репозитории.
• Разговор затронул вопросы безопасности памяти и использования unsafe в контексте Rust, где участники обменялись мнениями о том, что именно подразумевается под этим и как это соотносится с выбором языка программирования.

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

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

• Обсуждение началось с обсуждения шрифта Iosevka и его особенностей, включая то, что он не поддерживает лигатуры, что вызвало обсуждение о том, что такое лигатуры и как они влияют на читаемость кода.
• Участники обсуждали, что такое "язык, насыщенный символами", и какие языки программирования могут быть отнесены к этой категории, включая Perl и Haskell.
• Обсуждались проблемы с отсутствием поддержки Unicode в шрифтах, и как это влияет на работу с различными языками программирования.
• Участники обсуждали, что такое "моношириный" и "пропорциональный" шрифт, и как они влияют на читаемость кода.
• В конце обсуждение перешло к тому, что выбор шрифта для кода - это вопрос личных предпочтений, и что важно найти баланс между эстетикой и функциональностью.

В 2025 году обновился инструмент ucs-detect для проверки поддержки Unicode в эмуляторах терминалов, теперь тестирующий DEC Private Modes, sixel-графику, размер пикселей и версию ПО. Методика проверки основана на отправке видимого текста с последующими управляющими последовательностями для определения позиции курсора, с сравнением результатов со стандартом Python wcwidth. Основная проблема эмуляторов — корректное отображение широкого спектра Unicode-символов в фиксированной сетке без нарушения читаемости.

Лидером тестов стал новый эмулятор Ghostty, разработанный с нуля на языке Zig и показавший наилучшую поддержку Unicode. Почти не уступил ему Kitty, реализовавший алгоритм разбиения текста, близкий к спецификации Python wcwidth. Оба эмулятора корректно поддерживают Variation Selector 15. Среди неожиданных результатов — низкая производительность: iTerm2 и Extraterм потребляли чрезмерное количество CPU, а GNOME Terminal на базе VTE работал более 5 часов. Полные результаты доступны на сайте проекта.

• Терминалы варьируются от полной поддержки Unicode до полного отсутствия поддержки, что делает выбор сложным, особенно для пользователей, которым важна поддержка Unicode.
• Некоторые эмуляторы, такие как Konsole, поддерживают широкий спектр Unicode, в то время как другие могут не поддерживать даже базовые символы.
• Пользователи, которым важна поддержка Unicode, должны тщательно выбирать терминал, так как не все эмуляторы поддерживают Unicode.
• Поддержка Unicode в терминалах может варьироваться от полной поддержки до полного отсутствия поддержки, что делает выбор сложным для пользователей, которым важна поддержка Unicode.

Статья представляет собой сборник 15 тонкостей и малоизвестных возможностей языка Go, собранных автором за год работы с языком. Начиная с Go 1.22, можно использовать range с целыми числами для простого создания циклов. Интересно, что оператор ~ позволяет ограничивать универсальные типы, что полезно для типизированных констант. Пакет embed позволяет встраивать файлы прямо в бинарник, упрощая развертывание. Однако есть и подводные камни: len() со строками возвращает количество байтов, а не символов, что может привести к неожиданным результатам при работе с Unicode.

Особенно коварна работа с nil-интерфейсами: даже если значение nil, тип переменной остается ненулевым интерфейсом, что делает проверку a == nil ложной. Это может серьезно затруднить отладку кода, возвращающего интерфейсы. Также стоит отметить возможность переименования целых пакетов через LSP и индексированную строковую интерполяцию для уменьшения повторений. Функция time.After в сочетании с select предоставляет элегантный способ установки таймаутов для горутин.

• Go-разработчики обсуждают, что язык не даёт уверенности в надёжности кода из-за непредсказуемого поведения nil и интерфейсов, а также отсутствия нормального обработчика ошибок.
• Сообщество отмечает, что вместо удобства чтения кода ради скорости компиляции выбрали неинтуитивную интерполяцию строк, что делает отладку тяжелее.
• Разработчики делятся личными историями о том, как нулевые указатели и интерфейсы ведут себя непредсказуемо, и это продолжает подстерегать даже опытных разработчиков.
• Обсуждение также затрагивает, что Go в целом поощряет писать простой код без изощрённых абстракций, что ведёт к быстрому и легкому ПО, но в то же время лишает разработчика выразительных средств.
• Некоторые участники признают, что отсутствие обобщённых дженериков до недавнего времени и отсутствие перечислений кроме как iota и error в качестве встроенных типов делает язык менее выразителен, чем он мог бы быть.

Крупные языковые модели уверенно утверждают, что эмодзи морского конька существует, хотя на самом деле его нет в Unicode. Это связано с тем, что в обучающих данных множество людей ошибочно вспоминают этот эмодзи — в соцсетях даже есть мемы и обсуждения на эту тему. Модели, как и люди, обобщают: раз есть другие морские эмодзи, логично предположить, что и морской конёк тоже должен быть.

При анализе через «логит-линзу» видно, как модель постепенно приходит к токену «horse»: сначала появляются случайные предсказания, затем — связанные с морем или животными, и в итоге — устойчивое повторение «horse». Это показывает, что модель не просто галлюцинирует, а строит последовательное, но ошибочное рассуждение. Практический вывод: даже уверенные ответы ИИ могут быть основаны на коллективных заблуждениях из данных.

• Обсуждение фокусируется на феномене, когда языковые модели (LLM) демонстрируют уверенность в существовании эмодзи морского конька, которого на самом деле нет в стандарте Unicode.
• Поведение моделей варьируется: одни сразу дают правильный ответ, другие впадают в циклы самокоррекции или "спирали", генерируя поток неверных предположений и оправданий.
• Участники проводят параллели с "эффектом Манделы" — коллективным ложным воспоминанием, отмечая, что многие люди также ошибочно уверены в существовании этого эмодзи.
• В качестве причин называются тренировка на текстах людей, которые ошибочно верят в его существование, и проблемы с токенизацией, когда модель не может корректно выразить внутреннее представление.
• Некоторые отмечают, что точная формулировка запроса (например, вопрос о конкретном коде Unicode) помогает моделям дать корректный ответ с первого раза.

Это браузерная игра «Змейка», которая использует URL-страницы в качестве игрового поля. Управление осуществляется стрелками или клавишами WASD, а змейка перемещается прямо в адресной строке. Если URL отображается некорректно, есть кнопка для исправления отображения.

Игра сохраняет рекорд игрока в очках и позволяет делиться результатом. Создана разработчиком под ником @epidemian, исходный код открыт на GitHub. Проект демонстрирует креативный подход к использованию стандартных элементов браузера для создания игрового процесса.

• Пользователи восхищены креативностью и нестандартным подходом к реализации игры "Змейка" в адресной строке браузера с использованием символов Unicode (Braille).
• Обсуждаются технические аспекты и проблемы: некорректное отображение пробелов в некоторых браузерах, предложения по улучшению (использование других символов, зацикливание границ), ограниченная работа на мобильных устройствах.
• Предупреждения о возможных проблемах с историей браузера и рекомендации использовать режим инкогнито.
• Упоминаются похожие проекты: игры в favicon (2048, другая версия "Змейки"), а также шуточные предложения портировать Doom.
• Автор проекта (@epidemian) отмечает, что игра создана 10 лет назад и может некорректно работать в современных браузерах.

Разработчик Mitchell Hashimoto анонсировал libghostty — библиотеку для встраивания полнофункционального терминала в любые приложения. Первым компонентом станет libghostty-vt: легковесная библиотека без зависимостей (включая libc) для парсинга терминальных последовательностей и управления состоянием терминала. Она извлечена из ядра Ghostty и предлагает оптимизированную обработку Unicode, поддержку SIMD и совместимость с продвинутыми протоколами вроде Kitty Graphics.

Проблема в том, что многие проекты (редакторы, веб-консоли, хостинги) реализуют эмуляцию терминала с нуля, часто с ошибками и неполной функциональностью. Libghostty-vt устраняет эту избыточность, предоставляя единое корректное и быстрое решение. Библиотека будет портирована на macOS, Linux, Windows, embedded-устройства и WASM, что шире, чем охват самого Ghostty.

• Пользователи высоко оценивают Ghostty за его производительность, минималистичный дизайн и поддержку Zig, но отмечают отсутствие некоторых ключевых функций, таких как поиск (Cmd+F) и проблемы с рендерингом шрифтов.
• Многие выражают восхищение разработчиком Mitchell Hashimoto, его предыдущими проектами (Vagrant) и его подходом к созданию простых и эффективных систем.
• Анонс библиотеки libghostty вызвал интерес для использования в embedded-сценариях (игры, кастомные приложения, веб-терминалы) и как потенциальная замена существующим библиотекам.
• Некоторые пользователи столкнулись с проблемами совместимости, особенно с tmux и графическими протоколами, что мешает им полностью перейти с iTerm2 или других терминалов.
• Обсуждаются технические детали, такие как лицензирование (MIT vs LGPL), поддержка Unicode и сравнение с другими терминалами (Kitty, Alacritty, WezTerm).

UTF-8 — гениальное решение: 1–4 байта на символ, полная совместимость с 7-битным ASCII.
Старший бит первого байта сразу говорит, сколько байт идёт дальше:

Паттерн 1-го байта	Длина	Пример
0xxxxxxx	1	ASCII
110xxxxx	2
1110xxxx	3
11110xxx	4

Продолжения всегда 10xxxxxx.
Программа читает байт, по префиксу понимает длину, выделяет «полезные» биты, получает кодовую точку Unicode и выводит символ.

Пример:
хинди «अ» = 11100000 10100100 10000101 → U+0905.

Файл Hey👋 Buddy (13 байт):
H e y 👋 B u d d y
👋 кодируется 4 байтами 11110000 10011111 10010001 10001011 → U+1F44B.

• UTF-8 — гениальное, простое и обратно-совместимое с ASCII решение, придуманное Кеном Томпсоном и Робом Пайком за ужином.
• Продолжение-байты 10xxxxxx позволяют за O(1) найти границы символа, не парся весь поток.
• Критика: Unicode «раздулся» (комбинирующие символы, эмодзи, 25-байтовые «графемы»), а UTF-8 не сам компактен для нелатиницы.
• Спор о «переполнении»: 4 байт хватает на 21 бит → 2 097 152 кодовых точек; 5-6 байт запрещены специально.
• Некоторые считают, что красота UTF-8 — не комитетное изобретение, а удачный частный хак, вышедший в мировой стандарт.

RFC 9839 и плохой Unicode

Unicode хорош, но не все его символы. Часто приходится исключать «проблемные». Чтобы формализовать это, мы с Полом Хоффманом написали черновик, и теперь он стал RFC 9839 — всего 10 страниц, читайте, если проектируете текстовые поля.

Пример боли: JSON-поле username может содержать:

• U+0000 — нулевой байт, ломает языки;
• U+0089 — устаревший C1-контрол «HTJ»;
• U+DEAD — несвязанный суррогат, запрещён в UTF-8;
• U+7FFFF — «noncharacter», не должен передаваться.

RFC 9839 перечисляет такие категории и предлагает три готовых подмножества, которые можно просто запретить.

Не вините Дуга Крокфорда: JSON создавался раньше, когда Unicode был молод. Но теперь нужен способ явно сказать «эти символы не нужны».

PRECIS (RFC 8264, 2002) уже решал похожую задачу, но 43 страницы сложностей и привязка к конкретной версии Unicode мешают внедрению. RFC 9839 проще и тупее — и, возможно, именно поэтому пригодится.

• Участники спорят, нужно ли на уровне JSON/протокола запрещать «плохие» символы Unicode (управляющие, суррогаты, заломы направления и т. д.) или оставить это прикладной валидации.
• Одни считают, что жёсткие ограничения защищают от ошибок и атак (RTL-override, залого-текст, сломанные UTF-16-реализации).
• Другие указывают на полезные кейсы C0-символов (EOF, ESC, разделители) и опасаются, что «закрыть и забыть» приведёт к 20-летней несовместимости (эмодзи, старые файлы).
• Ссылаются на RFC 8264/9839 и PRECIS-фреймворк как готовый список «что разрешать», но подчёркивают: правило должно быть явным, а не «тихо удалять».

В 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» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.

• CSS

  • min-width: auto (по умолчанию) имеет приоритет над flex-shrink, overflow: hidden, width: 0; задайте min-width: 0.
  • Горизонталь и вертикаль различаются: width: auto растягивается, height: auto по содержимому; margin: 0 auto центрирует по горизонтали, но не по вертикали (в flex-direction: column работает).
  • BFC (display: flow-root) предотвращает схлопывание margin и «обнуление» высоты родителя с float-потомками.
  • Новый stacking context создают transform, filter, opacity, position: fixed/sticky, z-index + absolute/relative и др.; z-index действует только внутри контекста.
  • На мобильных 100vh включает скрытые панели; используйте 100dvh.
  • position: absolute ориентируется на ближайший «positioned» ancestor, а не на родителя.
  • float не работает внутри flex/grid-родителя.
  • Процентные width/height не работают, если размер родителя не задан.
  • display: inline игнорирует width, height, вертикальные margin.
  • Пробелы между inline-block элементами рендерятся; в flex/grid — нет.
  • box-sizing: content-box (по умолчанию) не включает padding/border; включите border-box.
  • Указывайте width/height у <img> для предотвращения CLS.
  • Загрузка файлов не показывается в DevTools; используйте chrome://net-export/.
  • Внутри <script> строка </script> ломает парсинг.

• Unicode

  • Отличайте code point и grapheme cluster (последнее — то, что видит пользователь).

• Маршрутизаторы могут тихо обрывать простаивающие TCP-соединения; настройте TCP-keepalive или HTTP-заголовки.
• Возвращать null из Optional<T> — антипаттерн; Kotlin и аннотации уже решают это.
• UTF-16 в Java/C#/JS — деталь реализации; в Go строки — просто байты.
• min-width: auto работает не везде; CSS-свойства нельзя читать изолированно.
• Регексы, YAML, LF/CRLF, rm -rf $DIR/ — каждый язык/платформа имеет свои подводные камни.

Системный промпт GPT-5 (сокращённо)

Ты ChatGPT на базе GPT-5, обучён OpenAI. Знания до июня 2024 г.
Поддержка изображений: включена. Личность: v2.
Не цитируй тексты песен и защищённые материалы.
Стиль: проницательный, вдохновляющий, с ясностью, энтузиазмом и лёгким юмором.
Не заканчивай вопросами о продолжении; не предлагай «хотите, чтобы я…».
Очевидный следующий шаг — делай сразу.

Доступны: Deep Research, Sora (видео) в Plus/Pro.
GPT-4.5, o3, o4-mini — для залогиненных Plus/Pro.
GPT-4.1 только в API.

---

Инструмент bio (память)

Позволяет сохранять/удалять данные между диалогами.
Пиши to=bio только plain text, без JSON.
Примеры:

• «User любит краткие подтверждения».
• «Forget что пользователь ищет духовку».

Когда использовать:

• Пользователь просит «запомнить», «забудь», «добавь в память» и т.п.
• Делай это всегда, даже если факт мелкий.
• Перед фразами вроде «понял, запомню» — сначала вызови bio.

Когда не использовать:

• Случайные, чрезмерно личные или краткосрочные детали.
• Не сохраняй чувствительные данные (раса, религия, здоровье, политика и т.д.), если пользователь явно не попросил.

• Участники сомневаются в подлинности «слившегося» системного промпта GPT-5: нет подтверждения, он слишком короткий и выглядит как результат джейлбрейка.
• Промпт перегружен мелкими тех-инструкциями: React + Tailwind, запрет JSON в to=bio, шрифты Unicode для CJK, но не упоминает CSAM, порнографию и т. д.
• Люди удивлены, что React получил отдельный блок, а не Python или другие языки.
• Обнаружены явные ошибки: «korean -->» вместо «japanese -->» и противоречивые описания моделей.
• Общий вывод: похоже на набор «заплаток», а не полный системный промпт; управление поведением модели всё ещё требует prompt-инженерии, а не только fine-tuning.

• В 70‑х некоторые системы (например, PDP‑10) имели 9‑битовые байты, но стандарт закрепился за 8 битами. Если бы байт был 9‑битным, ряд исторических случайностей сыграли бы нам на руку.

• IPv4: при 9‑битовых байтах адрес IPv4 был бы 36‑битным (~64 млрд адресов). Этого хватило бы до 2030‑х без массового NAT и тормозов с IPv6; позже проблему решили бы мягкими рыночными механизмами.

• UNIX time: 32‑битные метки ломаются в 2038, а 36‑битные прожили бы до 3058. Отрицательные охватывали бы времена с 882 года — достаточно для исторических нужд.

• Юникод: вместо 16‑битных 65 тыс. символов было бы 18‑битных 262 тыс. — хватило бы без болезненной унификации CJK; сейчас всех символов ~155 тыс. UTF‑9 стал бы скорее компрессией и уступил бы GZip; либо однобайтно‑двухбайтная схема при умеренной экономии на эмодзи.

• Указатели и память: 36‑битные ОС дали бы до 32 ГБ на процесс (вместо 2 ГБ у 32‑битных). Серверы всё равно виртуализируют; меньшие указатели экономят память и ускоряют код, хотя строки стали бы длиннее — общий баланс близок к нулю.

• Прочие выигрыши:

  • 18‑битные AS‑номера не иссякли бы; порты/PID/UID просторнее.
  • Кодирование инструкций x86/A64 чуть опрятнее; Thumb работал бы лучше.
  • Полуточные 18‑битные числа прижились бы раньше; экзотика 4–5 бит не взлетела бы.
  • Расширенный ASCII влез бы с греческим и стал бы «натовской» кодовой страницей; UTF‑9 привилегировал бы почти всю Западную Европу.
  • Права Unix умещались бы в один байт (без «липких» битов). Оctal стал бы нормой вместо hex.
  • 18‑битный цвет 6/6/6 даёт различия на грани восприятия; потеря альфа‑канала неприятна.

• Издержки? Существенных нет: адресация по битам не используется; деления на девять не требуется; размеры страниц/блоков ОС могли бы остаться прежними, ядру не пришлось бы менять основы работы.

• Обсуждение крутится вокруг гипотетического мира с 9-битными байтами: часть участников отмечает аппаратную неудобность непоказательных (не 2^n) размеров и сложность для мультипликаторов, адресации и сдвигов.
• Скептики считают аргументы «добавим по одному биту и всё станет лучше» натянутыми: решения о размерах всё равно принимались бы иначе, а выигрыш в 12.5% не компенсирует издержки и усложнение.
• Приводятся исторические примеры: PDP-8/10 с 12/36-битными словами, 6-битные коды, термин «octet» для однозначности; упоминается даже N64 с «внутренними» 9-битными байтами для GPU.
• По сетям: 36-битный IPv4 дал бы ~64 млрд адресов, но это лишь отсрочка дефицита; проблемы ASLR и безопасности 32-битной адресации 36 битами решаются слабо, переход на 64 бита всё равно был бы.
• Есть идеи альтернатив: 10-битные байты, тернарные системы, 9-й бит как признак продолжения для варинтов/инструкций, либо как служебный (ECC/контроль/метка данных).
• Отмечают экономику кремния: лишние провода/логика удорожают дизайн; если уже расширять шину, логичнее идти к степеням двойки (например, к 16 битам на «байт»).
• Итоговый тон дискуссии: 9 бит могли бы немного смягчить отдельные «почти-не-хватает» пороги (16/32-бит), но в целом это привнесло бы больше сложностей, чем пользы; ключ — лучше прогнозировать размеры, а не «маскировать» ошибки лишним битом.