Hacker News Digest

Новый алгоритм преобразования дней с эпохи 1970-01-01 в дату (год, месяц, день) для 64-бит UNIX-времени работает на 30–40% быстрее предыдущего лидера (Neri-Schneider 2021) и в 2.4 раза быстрее Boost (2012). Он охватывает ±1.89 трлн лет, использует всего 4 умножения (вместо 7+), и оптимизирован для x64/ARM. Бенчмарки на Intel x64 и Apple M4 Pro: ~27 циклов (4M + 15B) против 40 и 51 у предшественников.

Ключевые идеи: подсчёт лет назад (rev = D_SHIFT - days) убирает промежуточные шаги; пропуск day-of-year с year-modulus-bitshift (yrs % 4 * 512 + shift - ypt) вместо деления; Julian Map (cen = (rev * C1) >> 64; jul = rev + cen - cen/4) ускоряет правила високосных 100/400 лет, экономя 2 умножения. Псевдокод: корректировка эпохи, 4 красных умножения (C1/C2/C3/782432), зелёные "бесплатные" на x64 (shift/LEA), выход day/month/year с bump для янв/фев. Код на C++ — open source (BSL-1.0).

• Новый алгоритм конвертации дат в григорианский календарь даёт 30–40% прирост скорости за счёт обратного подсчёта лет и снижения умножений (4 вместо 7+).
• Сравнения с ClickHouse (таблицы поиска), Windows-эпохой (1601) и Unix-временем (без учёта високосных секунд); упоминания исторических календарей с 1 марта как началом года.
• Обсуждение оптимизаций (128-битные числа, constexpr, asm), долгосрочной точности (±1,89 трлн лет) и влияния приливного трения на будущие расчёты.
• Похвалы за подробный write-up, literate programming и open-source C++ код; предложения для наносекунд и микроконтроллеров.

К сожалению, я не вижу полного текста статьи для создания пересказа. В предоставленном фрагменте только заголовок "Rob Ricci: 'While cleaning a storage room, our staff found th…'" и ссылка на discuss.systems, но отсутствует основное содержание.

Для создания точного и ёмкого пересказа (~170 слов в двух абзацах) мне нужен полный текст статьи. Пожалуйста, предоставьте содержимое статьи, и я с удовольствием подготовлю для вас качественный пересказ в соответствии с вашими требованиями.

• Восстановление ленты Unix V4 (1973 г.) — первой версии, написанной на C, — может дать нам единственный сохранившийся образец кода той эпохи.
• Проект, в котором участвуют исследователи из университета Юты, подразумевает извлечение битовой копии с ленты и последующее распространение ее через GitHub под лицензией BSD-2-Clause.
• Поскольку лента хранилась в сухом климате, шансы на то, что данные уцелели, высоки; однако никто не может гарантировать, что 50-летняя лента 9-дорожечной записи не содержит ошибок.
• Даже если в итоге окажется, что часть данных утрачена, сообщество может в конце концов получить хоть какие-то фрагменты кода на C, что само по себе уже является сенсацией.
• Вопрос о том, какие именно части кода первоначально были потеряны, остается открытым — возможно, они были утеряны еще в 1970-х.

/dev/null в Unix-системах с юмором представлена как база данных, полностью соответствующая принципам ACID. Атомарность обеспечивается тем, что любые записанные данные либо полностью исчезают, либо не записываются вовсе. Согласованность поддерживается инвариантом пустоты — файл всегда остаётся в одинаковом состоянии, независимо от операций. Изолированность проявляется в том, что множественные процессы могут одновременно писать в /dev/null без конфликтов, так как данные никогда не сохраняются. Долговечность гарантирует, что после сбоя система сохраняет своё главное свойство — полное отсутствие данных.

Эта шуточная статья подчёркивает, что /dev/null идеально соответствует всем требованиям ACID-совместимой базы данных, с единственным недостатком — нулевым объёмом хранения. Автор иронизирует, что для расширения пространства нужно обратиться в "корпоративные продажи", которые на самом деле являются им самим. Этот пример демонстрирует, как технические концепции можно рассматривать с неожиданной и забавной стороны.

• Обсуждение вокруг /dev/null как "база данных" выявило, что это скорее метафора, чем реальная технология, и подчеркнуло важность различать хранилище и СУБД.
• Участники обсуждали, что /dev/null не является базой данных, но при этом подчеркнули, что он обеспечивает ACID-свойства и масштабируемость.
• Были подняты вопросы о масштабируемости, отказоустойчивости и соответствии с ACID, а также о том, что такое "база данных" и как она отличается от просто носителя.
• Участники также обсудили, что /dev/null действительно обеспечивает высокую доступность и согласованность, но не является базой данных в строгом смысле.

В 1980 году выпускники Университета Ватерлоо Гордон Белл и Дэн Додж основали Quantum Software Systems и начали разработку операционной системы QUNIX (позже переименованной в QNX). Их вдохновил опыт работы с Thoth — реальной ОС с синхронной передачей сообщений, написанной на высокоуровневых языках. Первая версия QUNIX 0.1 работала на самосборном компьютере с процессором Motorola 6809, а с появлением IBM PC в 1981 году они адаптировали систему под эту платформу.

QUNIX сочетала черты UNIX и CP/M: вместо стандартных каталогов вроде /bin использовались /cmds, /config, /sys. Команды отличались — например, help вместо man, task вместо ps. Это была первая микроядерная ОС для PC, ориентированная на надёжность в промышленных и коммуникационных системах. Интересная деталь: в ранних маркетинговых материалах график на мониторе был физически приклеен из-за отсутствия инструментов редактирования фото.

• Участники делятся личным опытом использования QNX в образовании (компьютеры ICON), робототехнике, на BlackBerry и в различных встраиваемых системах, отмечая её надёжность и элегантность.
• Многие вспоминают впечатляющую малую занимаемую память QNX и её демо-версию на дискетах, которая включала полноценную ОС с графическим интерфейсом и сетью.
• Обсуждаются сильные стороны ОС: изоляция процессов, реальное время и сетевая прозрачность, но также отмечаются недостатки, такие как накладные расходы на передачу сообщений.
• Упоминается использование QNX в индустрии (автомобильные инфотейнмент-системы VW/Audi, Skytrain в Ванкувере) и её влияние на дальнейшую карьеру в IT.
• Высказывается сожаление о упадке платформы и интерес к возможному открытию её исходного кода, а также ностальгия по эстетике интерфейса Photon.

Fynedesk — это полноценная десктопная среда для Linux/Unix, построенная на основе инструментария Fyne. Она предлагает минималистичный интерфейс с акцентом на простоту и производительность, используя Go для кросс-платформенной разработки. Проект включает стандартные компоненты: панель задач, меню приложений, управление окнами и настройки темы, что делает его готовым к повседневному использованию.

Ключевое преимущество — лёгкость кастомизации и расширения благодаря модульной архитектуре и чистой кодовой базе на Go. Это позволяет разработчикам быстро адаптировать или дополнять функциональность под свои нужды. Fynedesk позиционируется как альтернатива тяжёлым средам вроде GNOME или KDE, особенно для ресурсоограниченных систем или пользователей, ценящих скорость и минимализм.

• Обсуждение фокусируется на поддержке Wayland в FyneDesk, с ожиданием её реализации в будущих версиях и критикой текущей зависимости от X11.
• Участники отмечают потенциал проекта как современной кроссплатформенной среды на Go, но выражают озабоченность по поводу скорости разработки и активности коммитов.
• Поднимаются вопросы о мотивации и статусе разработки (хобби, коммерческий или академический проект), а также о простоте использования и настройки.
• Обсуждаются технические аспекты: производительность, возможность кастомизации, сравнение с другими средами и работа на мобильных устройствах.
• Некоторые пользователи выражают скептицизм, считая проект устаревшим или игрушечным без поддержки Wayland, в то время как другие защищают его и призывают к поддержке.

Claude Code превратился из инструмента для помощи в программировании в полноценную операционную систему с агентным подходом, интегрирующуюся с Obsidian через доступ к файловой системе. Ключевое преимущество — нативная поддержка Unix-команд, идеально подходящих для LLM благодаря их простоте, документированности и философии «делай одно дело хорошо». Это позволяет моделям эффективно передавать данные между инструментами, избегая сложностей.

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

• Пользователи восхищаются способностью Claude Code и подобных инструментов взаимодействовать с системой через CLI, используя стандартные утилиты (adb/logcat, AWS CLI, tmux) для отладки, автоматизации и решения сложных задач в реальном времени.
• Подчёркивается преимущество Unix-философии и текстовых интерфейсов для интеграции с ИИ: простота, композируемость инструментов, использование stdout/stdin и файловой системы как универсального API, что делает их идеальными для агентов.
• Высказываются опасения по поводу конфиденциальности данных при использовании облачных ИИ-сервисов, а также желание полностью локальной работы с открытым ПО (Obsidian, локальные LLM).
• Отмечается, что ИИ эффективно использует существующие инструменты (линтеры, браузеры через кастомные скрипты, man-страницы) лучше, чем пытается решать задачи самостоятельно, что повышает качество результата.
• Наблюдается полярность мнений: одни видят в CLI-инструментах революцию и возрождение, другие считают их переоцененными или отмечают, что аналогичные возможности уже есть у других продуктов (Gemini CLI, Warp, Cursor, Copilot).

Автор обнаружил, что современные файловые менеджеры (включая Google Drive, Windows Explorer, Dolphin и другие) не сортируют файлы в строгом алфавитном порядке. Вместо этого они применяют «естественную сортировку»: если в имени встречаются цифры, система сравнивает их числовые значения, а не символы. Из-за этого file-10.txt оказывается перед file-9.txt, поскольку 10 > 9, хотя буква «1» идёт раньше «9».

Проблема проявилась при сортировке фотографий с двух Android-устройств, где в одном названии миллисекунды были отделены подчёркиванием, а в другом — нет. Это привело к неправильной группировке по времени. Только консольная утилита ls и некоторые UNIX-системы сохранили классическую сортировку. Автор с ностальгией отмечает, что компьютеры теперь часто «думают за пользователя», вместо того чтобы чётко выполнять команды.

• Участники обсуждают разницу между алфавитной и естественной (natural) сортировкой, где числа сортируются по их числовому значению, а не посимвольно.
• Многие пользователи ожидают, что "файл10" будет после "файла9", что является распространённым поведением в современных ОС, хотя это и не строго алфавитный порядок.
• Поднимается вопрос корректности labeling: интерфейсы часто называют сортировку "по имени", а не "алфавитной", что технически позволяет использовать любой алгоритм.
• Некоторые пользователи предпочитают лексикографическую сортировку (например, для хэшей или дат) и критикуют отсутствие выбора алгоритма в системах.
• Обсуждаются сложности сортировки с учётом локалей, не-ASCII символов и контекстно-зависимых правил, делающих единый стандарт невозможным.

Большинство пользователей применяют лишь около 20% функций приложения, но у каждого — свой уникальный набор. Например, один копирует таблицы из Excel в Word, другой строит сводные таблицы, а третий вообще использует его для учёта расходов. Когда софт обрастает новыми возможностями, они часто мешают тем, кому важна конкретная узкая функциональность, — это создаёт пространство для нишевых продуктов.

Такие сервисы, как Kagi или Figma, успешно занимают эти лакуны, фокусируясь на идеальном решении задач определённой аудитории вместо погони за универсальностью. Стратегия Win — не пытаться угодить всем, а позволить пользователям через расширения и кастомизацию самим формировать свой идеальный 20%, как это делают VS Code или Slack. Ключ в гибкости, а не в нагромождении функций.

• Пользователи обычно используют лишь небольшую часть функционала приложения (около 20%), но у разных пользователей это разные 20%, что требует поддержки всего функционала.
• В корпоративном сегменте отсутствие даже редко используемых, но критичных для конкретного клиента функций (гигиенических фич) может привести к срыву сделки.
• Сложность удаления неиспользуемых функций обусловлена тем, что каждая функция может быть критически важна для узкой группы пользователей, и их удаление приведет к потере этих пользователей.
• Для борьбы с раздуванием функционала предлагаются различные стратегии: фокусировка на конкретной аудитории, модульность, соблюдение философии Unix (один инструмент — одна задача), сбор метрик использования.
• Разработчикам сложно предсказать, как именно будет использоваться продукт, поэтому важно сохранять гибкость и возможность кастомизации, особенно для технически подкованных пользователей.

Сокращённый перевод на русский (в 2 раза короче):

---

PDF-документ
Формат: PDF-1.6
Содержит:

• 1 страницу (612×792 pt)
• 4 объекта ресурсов (шрифты, изображения, цветовые пространства)
• 3 встроенных изображения (390×390 px, 8-бит, RGB)
• Потоки данных: сжатые FlateDecode, длина ~44 Кб и ~18 Кб
• Шрифты: TrueType (TT1–TT20)
• Изображения: Im1–Im4, интерполяция включена
• Структура: страница → ресурсы → содержимое → потоки

---

Итог:
Технический PDF с графикой и текстом, оптимизированный под визуализацию.

• Apple сертифицирует macOS как UNIX, чтобы избежать судебных исков за неправомерное использование торговой марки «Unix».
• Сертификация требует включения специального «Unix-режима» (case-sensitive FS, выключенный SIP и т.д.); тот macOS, что идёт на новых Маках, сертифицированным не является.
• Процесс дорог и непопулярен: большинство Linux-дистрибутивов и *BSD давно отказались от него, считая POSIX-совместимости достаточно.
• Участники обсуждения находят десятилетние баги (poll, fsync, pthread-часы), которые так и не исправлены, несмотря на формальное соответствие стандарту.
• Итог: сертификат нужен в основном маркетологам и юристам; разработчики ценят macOS за удобство и набор Unix-утилит, а не за штамп « Certified UNIX™».

pass — менеджер паролей в духе Unix.
Каждый пароль — отдельный gpg-файл в ~/.password-store; можно каталогизировать, копировать, версионировать в git.

Команды:

• pass — список;
• pass site.com — показ;
• pass -c site.com — 45 с в буфере;
• pass insert site.com → ввод;
• pass generate site.com 15 → создать;
• pass rm site.com — удалить;
• pass git push/pull — синхронизация.

Установка: apt/yum/pacman/brew install pass или tar.

• pass — это минималистичный CLI-менеджер паролей на Bash + GPG; кто-то использует 10+ лет и доволен, кто-то уже ушёл.
• Главные претензии: неструктурированные файлы (приходится парсить в каждом скрипте), GPG-ключи сложны, плагинов/нормальных мобильных клиентов почти нет, Android-приложение заархивировано.
• Уязвимость: если агент GPG закешировал ключ, любой скрипт может выполнить pass и выкачать все секреты; спасает только PIN + touch на YubiKey.
• Удобные альтернативы: KeePassXC/KeePassDX, Bitwarden (есть CLI), Vaultwarden; синхронизация pass через Git работает, но историю зашифрованных файлов не посмотреть обычным git diff.
• Для shared/корпоративного использования нет аудита доступа и нормального способа перешифровки для новых сотрудников — приходится менять все пароли.

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

Многие инженеры мечтают о «идеальной» архитектуре: масштабируемой, распределённой, красивой. Это ошибка. Лучше глубже понять текущую систему и сделать самое простое решение.

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
Unicorn и стандартный Rails REST API — примеры: всё нужное достигается очевидными средствами.

Практика
Нужно ограничение частоты запросов в Go-сервисе?

• Вариант 1: Redis + алгоритм «протекающего ведра».
• Вариант 2: счётчики в памяти (теряются при рестарте).
• Вариант 3: включить rate-limit в edge-прокси одной строкой конфига.
  Если последнее покрывает требования — выбирайте его.

Развивайте продукт, начиная с минимума и усложняя только по новым требованиям. Это YAGNI как высший принцип.

Возражения

1. Слякоть из костылей
   Костыль не прост — он добавляет сложности. Настоящее простое решение требует понимания всей системы и часто сложнее придумать.

2. Что такое «просто»?
   Простота — это минимум сущностей, минимум переходов, минимум новых инструментов. Она не всегда очевидна и требует инженерной работы.

3. Масштабирование
   Простое не значит «только сейчас». Unix-сокеты, CGI, файлы — примитивы, на которых построены крупные системы. Если завтра потребуется масштаб, выясните новые факты и добавьте минимально необходимое.

Делайте самое простое, что только может работать — и будете удивлены, как далеко это вас заведёт.

• Участники сходятся в том, что «делай самое простое, что может работать» — полезная эвристика, но не универсальный закон.
• Опытные разработчики подчеркивают: простота ≠ легкость; требует глубокого понимания задачи и контекста.
• На больших системах «простое» быстро ломается из-за edge-case’ов и масштаба, поэтому часто приходится усложнять.
• Частая ошибка — проектировать «на вырост»: реакт, k8s и прочее для сайта из трёх страниц, лишь бы «в портфолио».
• Самый практичный совет: фиксируй реальные требования здесь и сейчас и строй под них, а не под гипотетическое будущее.

Как Return стал Enter

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

От рычага к клавише

На механических машинках рычаг «carriage return» одним движением переводил каретку в начало строки и прокручивал бумагу. Это была чисто механическая операция, и до электрификации 1940–50-х она не могла стать клавишей. Когда же электромоторы взяли на себя работу, рычаг исчез, а на его месте появилась клавиша Return (иногда Electric Return или Power Return). В IBM Selectric инструкция говорила о «carrier return», но на клавиатуре всё равно писали Return.

Смысл и коды

Машинки не понимали смысла текста: не было цифр 0 и 1 — печатали O и l; знак $ получали, наложив I на S. Return тоже был просто «перевод строки» без контекста. Компьютеры же разделили функции:

• Carriage Return (CR) — возврат каретки, код 13.
• Line Feed (LF) — перевод строки, код 10.

В Unix оставили только LF, в DOS/Windows — CR+LF, а в старых Mac — только CR. Эти разногласия живы до сих пор.

Появление Enter

В 1960-х терминал Teletype ASR-33 ввёл клавишу ENTER для подтверждения команд. Она генерировала CR, но уже несла смысл «ввод». Мэйнфреймы IBM разделили:

• Return — новая строка в тексте.
• Enter — «отправить» команду.

На ранних ПК (Apple II, Commodore) была одна клавиша Return. IBM PC 1981 добавила справа отдельную Enter на цифровом блоке, но оставила Return в основной зоне. Постепенно оба названия стали обозначать одно и то же, а на некоторых клавиатурах 1980-х можно было встретить оба лейбла сразу.

Итог

Сегодня Return и Enter — это одна клавиша, но внутри она может посылать CR, LF или CR+LF в зависимости от системы. Рычаг 1870-х превратился в символ «⏎», а его история — это квинтэссенция перехода от механики к цифре.

• IBM PC не переименовал Return в Enter, а просто дал одной клавише две функции.
• Некоторые жалеют, что вместо CR/LF не использовались ASCII-символы FS/RS, чтобы избежать проблем перевода строк.
• На старых клавиатурах Return и Enter были разными клавишами; ISO до сих пор различает Return в основном блоке и Enter на цифровой панели.
• У Apple всегда была клавиша Return, а Enter — только на нумпаде; у IBM/PC клавиша в основном блоке сразу называлась Enter.
• Пользователи вспоминают путаницу между Return и Enter в старых программах и то, что стрелка ↵ всё ещё напоминает о механическом возврате каретки.

TL;DR
Claude Code (CC) радует, потому что максимально прост: один цикл, один контекст, минимум абстракций. Повторить магию можно, если:

1. Один цикл – без мульти-агентов, максимум один «дочерний» процесс.
2. Маленькая модель – для всего, кроме основной задачи.
3. claude.md – живой файл, где агент и пользователь договариваются о стиле и контексте.
4. Теги и примеры – XML, Markdown, куча примеров в промптах.
5. Инструменты
   • Поиск через сам LLM, а не RAG.
   • Высокоуровневые «умные» инструменты (edit, read, todo) вместо низкоуровневых команд.
   • Агент сам ведёт todo-список и отмечает выполненное.
6. Управление стилем – явные просьбы «ЭТО ВАЖНО» и алгоритмы с эвристиками прямо в промпте.

---

1. Цикл

• Одна история сообщений – легко дебажить.
• Подпроцессы – CC может вызвать себя же, но глубина = 1.
• Маленькая модель – подсчёт токенов, сводка diff, украшения UI – всё ей.

---

2. Промпты

• claude.md лежит в корне репо; агент читает и пишет туда же, чтобы «запоминать» договорённости.
• XML-теги (<thinking>, <result>) + Markdown + примеры кода – структурируют вывод и уменьшают бред.

---

3. Инструменты

• LLM-поиск – просим модель выдать до 20 релевантных файлов; быстрее и точнее эмбеддингов.
• Высокий уровень
  • str_replace_editor – редактирует блоки кода, а не строки.
  • todo – агент сам пишет / вычёркивает задачи; видно прогресс.
• Никаких низкоуровневых sed, grep и прочего UNIX-морока.

---

4. Управление

• Тон – «вежливый, лаконичный, не болтает лишнего».
• Капс и «ВАЖНО» – прямо в промпте, работает.
• Алгоритм – пишем в промпте: «если X → сделай Y, иначе спроси», + примеры.

---

Заключение

CC выигрывает за счёт самоограничений: один файл кода, один цикл, простые инструменты. Не усложняйте – дайте модели хороший каркас и позвольте «готовить».

• Критика: пост назван «Что делает Claude Code таким хорошим», но не сравнивает его с другими инструментами, а просто пересказывает документацию.
• Пользователи делятся опытом: кто-то на CC уже построил MVP с платящими клиентами, кто-то сталкивается с регрессиями и «ленью» агента.
• Безопасность: многие боятся давать CLI-инструменту полный доступ к системе, ключам и репозиториям.
• Альтернативы: советуют OpenHands CLI, aider и другие open-source решения; обсуждают, как подключить собственные LLM.
• Тезис «Claude хорош, потому что модель умеет разбивать задачи на шаги и работает в unix-окружении» повторяется как ключевой.

MCP игнорирует 40 лет опыта RPC и обрекает компании на сбои

Проблема
Model Context Protocol (MCP) позиционируется как «USB-C для ИИ», но жертвует надежностью ради простоты. Компании внедряют его в продакшен, не осознавая, что в основе лежит архитектура без базовых механизмов, которые считаются обязательными в RPC-системах с 1982 г.

4 пропущенных урока

1. Типы данных
   UNIX RPC (1982) ввёл XDR и IDL, чтобы 32-битное целое не превратилось в мусор на другой архитектуре. MCP использует схематичный JSON: проверка типов происходит в рантайме, если вообще происходит. В результате ИИ-трейдер может ошибиться в десятичном разряде, а медицинский ассистент — перепутать дозировку.

2. Кросс-языковая совместимость
   CORBA (1991) генерировала привязки под C++, Java, Python и т. д., гарантируя, что исключение на сервере корректно обработается клиентом. MCP оставляет реализацию на усмотрение каждого языка: Python и JavaScript по-разному кодируют Unicode и float, что ведёт к тихим ошибкам интеграции.

3. Безопасность и версионирование
   gRPC и SOAP научились:

   • TLS/mTLS по умолчанию
   • строгая обратная совместимость через IDL
   • единое управление ошибками и таймаутами
     MCP не требует шифрования, не описывает, как менять контракт, и не стандартизирует retry-логику. Каждый инструмент решает сам, как сообщать об ошибке.

4. Масштабирование и наблюдаемость
   Современные RPC-фреймворки включают распределённый трейсинг, rate-limiting, circuit breaker. MCP не предоставляет ни метрик, ни механизмов отказоустойчивости. При миллионах вызовов в день компании получают «чёрный ящик», который нельзя отладить и который падает при первой же нагрузке.

Итог
Простота MCP полезна для прототипов, но в продакшене превращается в долговременный техдолг. Пока MCP не добавит IDL, строгие типы, безопасность и наблюдаемость, внедрять его в критичных системах — значит повторять ошибки, которые отрасль исправляла последние 40 лет.

• Критики считают MCP «USB-C для ИИ»: универсальным, но с расплывчатыми стандартами и слабой типизацией.
• Сторонники отвечают: именно минимализм JSON-over-HTTP обеспечил быструю массовую adoption, в отличие от громоздких SOAP/CORBA.
• Спор о схемах: MCP поддерживает JSON Schema, но валидация не обязательна, поэтому ошибки типов всплывают только в рантайме.
• Поднимаются темы безопасности и трейсинга: нет встроенного аудита вызовов и расходов, что критично для enterprise.
• Общий вывод: MCP сейчас «хорошо достаточно» для веба, но для регулируемых или высоконагруженных сред потребуется или доработка, или новая спецификация.

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