Hacker News Digest

Представлен шрифт 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.

Поисковик Marginalia запустил пилотную программу с экспериментальной поддержкой немецкого, французского и шведского языков. Ранее система была ориентирована исключительно на английский, и её код содержал англоцентричные допущения. Поддержка всех языков одновременно невозможна из-за их фундаментальных различий: японский требует специальной нормализации из-за нескольких алфавитов и отсутствия пробелов между словами, а латинский имеет десятки форм каждого слова с гибким порядком слов.

Система обработки языка включает несколько этапов: извлечение текста, определение языка, разбиение на предложения, нормализацию Unicode, стемминг, POS-теггинг и извлечение ключевых слов. Основные проблемы включают несовершенство стемминга (например, "universe" и "university" считаются одинаковыми), культурные различия в нормализации (например, "tröjan" и "trojan" в шведском) и проблему начальной загрузки для TF-IDF в новых языках. Для решения используется конфигурируемый XML-файл с языковыми настройками и грамматическими паттернами.

• Обсуждение показало, что Marginalia не только индексирует, но и предоставляет API и поисковые виджеты для сторонних проектов.
• Участники обсудили возможность интеграции Marginalia в качестве поискового бэкенда для сайтов-агрегаторов, подобно тому, как HN использует Algolia.
• Разработчик Marginalia упомянул, что работает над фильтрацией по доменам и скоро выпустит публичный API.
• Также обсуждались детали реализации: RDRPOSTagger используется для POS-теггинга, но с оптимизациями, чтобы ускорить обработку.
• Участники отметили, что Marginalia — это не только поисковый движок, но и инструмент для поиска по собственным закладкам и комментариям.

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

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

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

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

Например, в случае с leftpad, многие реализации были формально верифицированы относительно свойства «длина результата равна максимуму из n и длины s», но это не гарантирует, что результат будет визуально корректным при использовании Unicode-символов.

Другая проблема — ошибки в самом инструменте верификации, хотя такие случаи редки.

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

Таким образом, формальная верификация полезна, но требует тщательного подхода к формулировке спецификаций и понимания их ограничений.

• Обсуждение показало, что формальная верификация кода не покрывает аппаратные сбои и ограничения окружения, а также не решает проблему валидации требований пользователя.
• Участники подчеркнули, что доказательство корректности кода не защищает от ошибок в спецификации, а также не покрывает такие факторы как переполнение целочисленных типов и другие архитектурные ограничения.
• Была затронута тема различия между верификацией (verification) и валидацией (validation), где первое касается соответствия кода спецификации, а второе — решаемости реальной задачи.
• Обсуждение подняло вопрос о том, что формальные методы не покрывают такие аспекты как отказ оборудования, влияние космических лучей и другие факторы окружения, что делает их менее полезными в контексте безопасности.
• Участники также обсудили, что даже при наличии формальной верификации, остаются риски, связанные с человеческим фактором, так как спецификация может не отражать реальные требования пользователя.

Python действительно разбивает строку не только по \n, \r и \r\n, но и по целому ряду юникод-разделителей: \x1c, \x1d, \x1e, \x85, \u2028, \u2029 и другим. Это означает, что splitlines() может разбивать строку на части там, где вы этого не ожидаете.

• Обсуждение показало, что splitlines() и split() ведут себя неодинаково, особенно в отношении обработки символов перевода строки и других пробелов.
• Участники отметили, что splitlines() может неожиданно удалять символы перевода строки, если они встречаются в конце строки, в то время как split() этого не делает.
• Также было отмечено, что split() разделяет строку по любому пробельному символу, в то время как splitlines() только по символам перевода строки.
• Несколько человек поделились личным опытом, что они узнали что-то новое из обсуждения, даже несмотря на то, что это уже было в документации.
• В целом, обсуждение подчеркнуло важность внимательного чтения документации и понимания различий между похожими, но не идентичными функциями.

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

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

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

Онлайн-инструмент для рисования ASCII-арта с настраиваемыми кистями разных размеров (1×1, 2×2, 3×3) и возможностью выбора символов из Unicode, включая спецсимволы вроде ✦ или █. Есть ластик, очистка всего холста, настройка размеров сетки (столбцы и строки), а также функции копирования и экспорта в текстовый файл.

Работает в реальном времени с индикацией текущих параметров (например, 90×40, кисть 2px). Автор отмечает, что не все Unicode-символы отображаются корректно из-за ограничений шрифтов, и призывает дать обратную связь через соцсети.

• Отмечены технические проблемы: некорректная работа фиксированной ширины шрифта, нестабильность на мобильных устройствах (особенно в Firefox), неожиданное форматирование текста.
• Высоко оценена концепция и простота инструмента для рисования ASCII-арта, многие называют его интересным и полезным.
• Поступили предложения по улучшению: добавить Undo, использовать только печатные ASCII-символы по умолчанию, улучшить мобильную версию.
• Автор активно отвечает на фидбэк, объясняет выбор символов и делится ссылками на другие похожие инструменты.
• Обсуждение затронуло тему возрождения интереса к ASCII-арту и существование других нишевых инструментов для работы с ним.

Это браузерная игра «Змейка», которая использует 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).

В Unicode существует больше символов, обозначающих «латинскую заглавную букву A», чем букв в английском алфавите. Это наблюдение вдохновило на создание «шифра крика» — замены каждой буквы на один из вариантов A с диакритическими знаками. Например, фраза «SCREAM CIPHER» превращается в «ǠĂȦẶAẦ ĂǍÄẴẶȦ», что выглядит как набор кричащих символов.

Функции SCREAM и unscream реализуют прямое и обратное преобразование, сохраняя при этом регистр и игнорируя не-буквенные символы. Такой подход демонстрирует игривое использование Unicode для создания визуально эффектного, но семантически тривиального шифрования.

• Представлена кодировка zalgo256 с использованием комбинирующих символов Unicode для создания "кричащего" шифра, аналогичного моноалфавитной замене.
• Обсуждаются юмористические и практические аспекты шифра, включая сравнение с ROT13, отсылки к XKCD и потенциальное применение для обхода ограничений длины строк.
• Участники делятся своими реализациями на разных языках (Python, JS, Racket) и идеями по скрытию данных с помощью невидимых символов или эмодзи.
• Поднимаются вопросы безопасности, указывается на отсутствие криптостойкости и обсуждаются технические детали работы с графемными кластерами в Unicode.
• Шифр вызвал оживлённую реакцию, включая шутки о "песчаных людях" из Star Wars и создание чат-ботов для кодирования.

Роб Пайк рассказывает, как Кен Томпсон изобрёл UTF-8 за один вечер, и как они вместе внедрили его в систему менее чем за неделю.

В 1992 году, во время ужина в Нью-Джерси, Томпсон придумал битовую упаковку UTF-8. Изначально в Plan 9 использовалась кодировка UTF от ISO 10646, но она была неудобной. После звонка от представителей IBM и X/Open, которые просили оценить их проект FSS/UTF, Пайк и Томпсон предложили создать улучшенный стандарт.

За ночь Томпсон написал код для упаковки и распаковки, а Пайк адаптировал библиотеки. К пятнице Plan 9 уже полностью работал на UTF-8. X/Open принял их предложение, отказавшись от собственного FSS/UTF из-за недостатка синхронизации в потоке байтов.

Пайк опровергает миф о том, что UTF-8 разработала IBM, а Plan 9 лишь реализовала его, ссылаясь на архив переписки, подтверждающий их авторство.

• Обсуждаются исторические и социально-экономические причины доминирования США в ранней компьютерной индустрии, включая военные разработки и инфраструктуру.
• Выдвигается гипотеза о преимуществе англоязычного мира из-за простого алфавита без диакритиков по сравнению с такими языками, как китайский или хинди.
• Подробно разбирается история создания UTF-8 и критикуется решение Microsoft использовать в Windows NT кодировку UCS-2 вместо UTF-8, названное "ошибкой на миллиард долларов".
• Участники отмечают, что ранние компьютерные кодировки (6-битные, ASCII) наследовали принципы докомпьютерных эпох (телетайпы, перфокарты).
• Обсуждается влияние разных алфавитов на технологическое развитие, проводятся параллели с историей книгопечатания в Европе и Китае.
• Упоминается, что стандартизация Unicode и UTF-8 была сложным процессом с участием нескольких конкурирующих организаций.
• Отмечаются практические проблемы, вызванные использованием в Windows кодировок CP-125X вместо UTF-8, и наследие этого решения в виде API-функций с суффиксами "A"/"W".
• Приводится ссылка на RFC 3629, который ограничил UTF-8 4 байтами на символ, отказавшись от первоначальной поддержки 5- и 6-байтных последовательностей.

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 — не комитетное изобретение, а удачный частный хак, вышедший в мировой стандарт.

• Пользователи жалуются на избыточность и ненужность новых эмодзи, особенно гендерных и расовых вариантов, считая их личным и неуместным в рабочей переписке.
• Некоторые предлагают отказаться от фиксированного списка эмодзи в пользу AI-генерации или полной кастомизации.
• Критикуется приоритет Unicode: вместо полезных символов (например, математических или исторических) добавляются «детские стикеры» и «мусор».
• Поднимаются проблемы отображения: разные платформы рисуют эмодзи по-разному, что искажает смысл.
• Есть ирония по поводу того, как технический стандарт превратился в поле культурных и поколенческих споров.

• Рисование
  Терминал умеет только моноширинные символы и escape-последовательности. Используем нижний полублок ▄, задавая цвет фона (верхний пиксель) и символа (нижний).

  fn print_pixels_pair(top, bottom, (x, y)) {
      println!("\x1b[{};{}H\x1b[48;2;{t}m\x1b[38;2;{b}m▄", y+1, x+1, t=top, b=bottom);
  }
  

• Текст
  Создаём TextCaptureDevice в Skia: перехватываем onDrawGlyphRunList, преобразуем glyph → Unicode, вызываем Rust-функцию draw_text.
  Добавляем очистку текста при заливке прямоугольников:

  if (paint.getStyle() == kFill_Style && paint.getAlphaf() == 1.0)
      clear_text(rect);
  

• Ввод
  Читаем stdin, парсим escape-коды клавиш/мыши, передаём их в Chromium через DOM-события.

• Pipe-режим
  carbonyl --pipe рисует в stdout, позволяя встраивать браузер в скрипты.

• Mojo
  Заменяем GPU-процесс на заглушку, отключая лишние сервисы.

• Layout
  Подгоняем device_scale_factor и viewport под размер терминала, чтобы 1 px = ½ клетки.

• LoDPI
  На 1×-экранах включаем сглаживание, чтобы символы не «дребезжали».

• Цвет
  Палитра 6×6×6 или 24-бит truecolor; приводим цвета к ближайшему доступному.

• Заголовок
  ESC-операторы меняют заголовок окна и вкладки tmux.

• Итог
  Carbonyl запускает весь веб в терминале без X11/Wayland: cargo install carbonyl.

• Carbonyl — терминальный браузер на движке Chrome, удивительно шустрый и юзабельный, особенно с --zoom=300 --bitmap.
• Пользователи просят добавить Kitty Graphics Protocol, sixel/chafa для нормального вывода картинок без ASCII-арта.
• Проект вдохновлён browsh, но работает быстрее; автору даже помог получить работу.
• Запускается в podman, показывает YouTube «кубиками» и почти справляется с капчей (могут помочь мультимодальные LLM).
• Под капотом — Skia и Mojo из Chromium, что позволяет рендерить всё, включая PDF.

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