Hacker News Digest

Короткая история Windows XP

Microsoft к концу 90-х стал «фоном жизни» — любое изменение вызывало бурю, а через пару лет продукт становился обыденным. Компания мечтала избавиться от MS-DOS, пробовала XENIX, XEDOS, затем OS/2, но успех Windows 3 разрушил союз с IBM. Спасением стал Дэвид Катлер, перешедший из DEC: его команда создала Windows NT, совместимую с DOS, UNIX и OS/2. План убить DOS-наследие через Windows 2000 отменили 7 апреля 1999 г.

• @ayaros и @Lammy вспоминают XP как «пик Microsoft»: обожают Luna/Neptune UI, музыку из тура и дизайн Watercolor.
• Критики (@krige, @spankibalt) считают тему XP «игрушечной» и скучной, предпочитая Classic Theme или вообще Linux.
• Ностальгия объясняется тем, что XP была первым компьютером миллениалов (@ianhawes), но технически уступала 2000 (@troupo, @lproven).
• Безопасность XP до SP2 была ужасной (@stetrain, @herbst), зато Vista/8 «убили» прогресс (@vjvjvjvjghv).
• Кто-то хранит запечатанную коробку XP (@cyrialize), кто-то даже шептал в OOBE-музыку (@EvanAnderson).

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

• Логотип Multics

• Домой

  • История »
    • Возможности
    • Мифы
    • Project MAC
    • Даты
    • Глоссарий
    • Проект истории
    • Последний сайт
  • Люди »
    • Истории
    • Фотографии
    • Юмор
    • Памятные вещи
  • Библиотека »
    • Статьи и доклады
    • Технические статьи
    • Документы разработки
    • Исходники
    • Симулятор
  • Сайты »
    • Хронология площадок
    • AFDSC (Пентагон, Вашингтон)
    • ASEA (Вестерос, Швеция)
    • Avon (Бристоль, Англия)
    • Bell Canada (2 площадки)
    • CISL (Кембридж, Массачусетс)
    • CNO (Миннеаполис, Миннесота)
    • DND-H (Галифакс, Канада)
    • DOCKMASTER (АНБ, Мэриленд)
    • FORD (Детройт, Мичиган)
    • GM (Детройт, Мичиган)
    • Майнц (Германия)
    • MIT (Кембридж, Массачусетс)
    • NWGS (ВМС США, 4 площадки)
    • OU (Рочестер, Мичиган)
    • PRHA (Сан-Хуан, Пуэрто-Рико)
    • RADC (Рим, Нью-Йорк)
    • RAE (Фарнборо, Англия)
    • STC (Лондон, Англия)
    • System-M (Финикс, Аризона)
    • Systeme X (Лувесьен, Франция)
    • UC/ACTC (Калгари, Канада)
    • USGS (3 площадки)
    • USL (Лафайет, Луизиана)
    • VPI (Блэксберг, Вирджиния)
  • О сайте »
    • Изменения
    • Новости
    • Ссылки
    • Галерея
    • Карта сайта

• Поиск

• Меню: История: Возможности | Мифы | Project MAC | Даты

• Участники обсуждают влияние Multics на современную вычислительную технику: от безопасности и архитектуры до наследия в текущих проектах (например, STOP, происходящий от SCOMP/STOP).
• Делятся воспоминаниями об использовании Multics в британских университетах в 80-х: система считалась быстрой, апгрейды памяти были ощутимыми, доступ через терминалы и JANET, позитивный опыт работы.
• Мнения расходятся: одни критикуют «всеобъемлющесть» дизайна и сложность (в контраст к UNIX), другие подчёркивают сильные стороны Multics — кольца защиты, строгие политики доступа (MAC/ACL), сегментную память и отсутствие переполнений буфера.
• Отмечают ограниченную портируемость Multics к немногим мэйнфреймам, несмотря на теоретическую переносимость.
• Ссылаются на полезные ресурсы: мифы о Multics, оценка безопасности B2, страницы по безопасности данных (AIM/MAC), «Три вопроса» для анализа багов, меморабилии, хронологии и список недавних изменений.
• Обсуждают спад активности оригинальных установок (последние закрытия около 2000 г.), эмулятор DPS8M и печальные новости об уходе участников проекта.
• Несколько комментаторов переосмыслили роль UNIX после знакомства с историей Multics и более ранними идеями (Xerox PARC), видя в Multics самостоятельную и богатую идеями систему, а не только «предтечу UNIX».