Hacker News Digest

За двадцать лет автор провёл цифровую археологию, чтобы возродить классическую Unix-игру Conquer 1987 года. Изначально опубликованная в USENET как "conquest – middle earth multi-player game", эта многопользовательская стратегия в мире Средиземья повлияла на множество последующих игр. В 2006 году автор начал поиск создателей Эдварда Барлоу и Адама Брайанта, чтобы relicensировать код под GPL. Как отметил Барлоу: "copyleft didnt exist when i wrote it and it was all for fun so...".

Поиск авторов напоминал детективную работу - адреса электронной почты 80-х были недоступны, приходилось следовать цифровым следам. После пятилетнего ожидания в 2011 году Брайант сам нашёл статью автора и разрешил распространение кода под GPL. В 2025 году выяснилось, что Брайант создал полную переработку - Conquer Version 5 с расширенными возможностями, которую также согласовал лицензировать под GPL. В истории игры также участвовал MaF, создавший утилиты PostScript для генерации печатных карт.

• Участники обсуждают исторические текстовые игры (Conquer, Trek, Netrek, Empire) и их сохранение для будущих поколений.
• Поднимаются вопросы лицензирования и переноса старого кода на современные платформы, включая использование веб-интерфейсов (ttyd) и репозиториев (bsdgames).
• Автор статьи (vejeta) активно участвует, объясняет сложности сохранения Conquer и делится опытом поиска и реставрации кода.
• Участники делятся воспоминаниями о старых играх и системах (SunOS, IBM minicomputers, PLATO), а также предлагают идеи для музеев и возрождения "Play-by-Mail" игр с использованием ИИ.

52-летняя магнитная лента, обнаруженная в архивах, может содержать утерянные ранние версии Unix, включая код, предшествовавший официальному релизу в 1971 году. Найденная в коллекции Bell Labs, лента хранит копию версии Unix 0, которая считается "святым Граалем" для историков вычислительной техники. Успешное восстановление данных с этого артефакта позволит проследить эволюцию ключевых компонентов ОС, таких как файловая система и ядро, и заполнить пробелы в истории Unix, повлиявшей на современные операционные системы.

Специалисты из Computer History Museum и Unix Heritage Society ведут сложный процесс восстановления данных с деградированной ленты, используя специализированное оборудование. По словам одного из экспертов, "эта лента — как цифровая Декларация независимости для Unix". Если восстановление пройдет успешно, это станет первым случаем извлечения работающего кода из столь ранней версии Unix, предоставив уникальную возможность изучить "первобытный код", сформировавший основу для Linux, macOS и других систем.

• Обсуждение вращается вокруг архивных лент 1972 года, найденных в лаборатории IBM, и возможности их восстановления.
• Участники обсуждают, что это может означать для сохранения наследия Unix и ранних систем, и какие технические и этические вопросы это поднимает.
• Поднимается вопрос о том, что в будущем может быть трудно оценить значение таких находок, и что это может означать для сохранения истории компьютерной эпохи.
• Обсуждается, какие усилия предпринимаются для сохранения таких артефактов, и какие могут быть последствия для общественного доступа к ним.

К сожалению, я не вижу полного текста статьи для создания пересказа. В предоставленном фрагменте только заголовок "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-х.

В Windows 11 25H2 исправлена давняя ошибка, из-за которой опция "Обновить и выключить" на самом деле перезагружала компьютер, а не выключала его. Эта десятилетиями существовавшая проблема вызывала путаницу у пользователей, которые ожидали полного выключения системы после установки обновлений.

Исправление стало частью обновления Windows 11 25H2 и теперь система действительно корректно завершает работу после установки обновлений. Это изменение повышает удобство использования и соответствует ожиданиям пользователей от функции "выключить", устраняя необходимость в дополнительных действиях для предотвращения автоматической перезагрузки.

• Microsoft никогда не призналась, что сломала переключатель «Update and shut down» в Windows 10, и только спустя годы признала проблему
• Пользователи годами сталкивались с тем, что «Update and shut down» просто перезагружала систему, не давая обновлениям примениться, и никакого обходного пути не предлагали
• Обсуждение выявило, что даже в 2024 году проблема всё ещё существует, а виновата в ней архитектура файловой системы Windows, которая не позволяет заменять открытые файлы
• Комментаторы отметили, что Linux и другие Unix-подобные системы сталкиваются с аналогичной дилемой, но там выбор стоит между риском несовместимости после обновления и перезагрузкой для применения обновлений
• В конце-концов, никто не может предложить, как обновлять Windows без перезагрузки, в то время как обновление ядра Linux требует лишь перезапуска служб.

Проект MyraOS представляет собой операционную систему Unix-подобного типа для архитектуры x86, созданную с нуля без использования стороннего кода. Автор проекта Dvir Biton разработал ядро системы, файловую систему, драйверы и пользовательские утилиты самостоятельно, что делает его впечатляющим достижением в области разработки ОС.

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

• Проект получил много похвал за качество кода и полезность, но также вызвал критику за использование устаревших ресурсов и отсутствие современных инструментов.
• Участники обсуждали, что в 2025 году нужно обновить учебные материалы для новичков в разработке ОС, чтобы они не ориентировались на 32-битный x86 и устаревшие устройства.
• Предложения включали: предоставление ISO-образов для тестирования, создание обучающего видео, и сотрудничество с такими проектами как copy.sh.
• Также обсуждались проблемы, такие как управление памятью и отладка, и как они масштабируются в контексте разработки ОС.
• В конце обсуждение сошлось на то, что проект является вдохновляющим примером, но может быть улучшен с использованием современных практик и инструментов.

Предоставленный текст не содержит статьи Кена Томпсона о происхождении Unix, а представляет собой форму подписки на рассылку The New Stack. В тексте отсутствует само содержание статьи, которое предполагалось пересказать. Вместо этого представлена регистрационная форма с полями для ввода имени, фамилии, компании, страны, почтового индекса и профессиональной информации. Форма также содержит информацию о политике конфиденциальности и условиях использования платформы. Для получения пересказа статьи о происхождении Unix необходимо предоставить сам текст статьи.

• Unix и другие проекты рождались в атмосфере открытого исходного кода, сотрудничества и страсти к делу, что противоречит корпоративной культуре.
• Подобные проекты часто не имели четкой организационной структуры, но вместо этого полагались на сильное чувство общности и взаимопомощи.
• Это противоположно тому, как обычно происходят вещи в больших компаниях.
• Истории о ранних днях Unix, ITS и других проектах подчеркивают важность этих ценностей.
• Но в то же время, они показывают, что такие проекты могут быть успешными и влиять на мир, даже если они не следуют традиционной модели разработки ПО.

• Обсуждение охватывает вопросы динамического связывания, загрузки ELF-файлов и влияния различных библиотек на размер бинарника, а также затрагивает тему встроенных файлов в бинарнике и использования shebang-ов в Unix-подобных системах.
• Участники обмениваются ссылками на статьи и инструменты, включая https://cpu.land и https://blog.foletta.net/post/2021-04-19-what-the-
• Обсуждение также касается вопросов, связанных с тем, как стек растет вниз, а не вверх, как это обычно изображается в учебниках, и как это влияет на обучение студентов.
• Участники также обсуждают, что влияет на размер бинарника, и какие еще факторы могут влиять на него, включая использование статической линковки, встроенных файлов и других аспектов.

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

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

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

Автор экспериментирует с созданием простого брокера сообщений, используя только два UNIX сигнала вместо сложных систем вроде Kafka. Он объясняет, что сигналы обычно применяются для управления процессами, но предлагает использовать их для обмена сообщениями. Автор рассматривает различные формы IPC в UNIX, включая каналы, сокеты и файлы, а затем фокусируется на сигналах SIGUSR1 и SIGUSR2, которые являются пользовательскими и могут использоваться для собственных целей.

Основная идея заключается в представлении сообщений как последовательности битов, где каждый бит кодируется соответствующим сигналом (0 - один сигнал, 1 - другой). Это позволяет передавать данные между процессами, используя минимальные системные ресурсы. Автор демонстрирует, как можно "взломать" стандартное поведение сигналов для создания эффективной системы обмена сообщениями, опираясь на двоичное представление данных и возможность перехвата сигналов в коде на Ruby.

• Обсуждение показало, что статья вызвала бурную реакцию: от восторга до критики за clickbait-заголовок и «техническую» неточность.
• Комментаторы подчеркнули, что UNIX-сигналы не предназначены для передачи данных, не гарантируют очередность и могут терять сигналы при конкурентном доступе.
• Было отмечено, что вместо сигналов можно использовать уже готовые механизмы, такие как POSIX message queues.
• Некоторые отметили, что статья может быть интересна как учебный материал, но не как руководство к действию.
• В итоге, обсуждение показало, что читатели ожидают более честных и точных заголовков и отсутствия сенсационализма, даже в контексте развлекательных экспериментов.

На macOS и Linux команда sort упорядочивает строки по-разному даже при одинаковой локали en_US.UTF-8. Например, на macOS python-dev идет перед python3-dev, а на Linux - наоборот. Причина - в файлах LC_COLLATE: на большинство локалей в macOS ссылаются на la_LN.US-ASCII, что представляет собой базовое ASCII-упорядочивание. Даже для нелатинских локалей (китайской, японской, корейской) используется та же ссылка. В то время как на Linux используются более сложные правила сортировки, учитывающие национальные особенности.

Автор обнаружил, что в macOS 122 из 178 локалей используют la_LN.US-ASCII в качестве основы для сортировки. Исследуя исходный код Apple, он нашел, что правила сортировки для la_LN.US-ASCII чрезвычайно просты - это просто базовое ASCII-упорядочивание без учета национальных особенностей. Это объясняет, почему на macOS "python-dev" идет перед "python3-dev", так как дефис (ASCII 0x2D) имеет меньший код, чем цифра 3 (ASCII 0x33).

• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.
• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.
• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.
• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.
• Сортировка строк в Unix-подобных системах зависит от локали, и это может привести к неожиданным результатам, особенно при работе с диакритическими символами.

Исследователь из Карлова университета предлагает отождествить Unix-исполняемые файлы с методами Smalltalk, открывая путь к объединению этих систем. Хотя Unix и Smalltalk существенно различаются в деталях, они демонстрируют поразительные сходства в своей общей структуре. Автор утверждает, что если файлы Unix соответствуют объектам Smalltalk, то исполняемые файлы должны соответствовать методам, а процессы — активациям этих методов. Это позволяет легко реализовать Smalltalk VM через файловую систему Unix.

Однако серьезные накладные расходы, связанные с Unix-процессами, ставят под сомнение практическую реализацию этого подхода. Тем не менее, автор видит несколько путей решения этой проблемы, которые позволят реализовать преимущества Smalltalk в Unix без изоляции в герметичной среде. Такое объединение сохранит плюральность языков Unix, в отличие от необходимости писать все методы на Smalltalk, и позволит преодолеть фрустрацию от существующих, но недостаточно развитых возможностей Unix в области персистентности, динамического обновления ПО, единообразия и открытости GUI.

• Пользователи обсуждают, что Xerox PARC мог бы стать основой для UNIX, но вместо этого остался в истории как упущенная возможность.
• Конференция ICFP/SPLASH 2024 стала поводом вспомнить о том, как давно не было никаких прорывов в области ОС и языков программирования.
• Участники обсуждают, что современные исследования в области ОС и языков программирования не предлагают ничего нового, а лишь переосмысливают старые идеи.
• Участники также отмечают, что даже такие концепции как компонентное программирование и модулярность, которые когда-то были новаторскими, сегодня являются лишь переосмыслением старых идей.
• В обсуждении также поднимается вопрос о том, что сообщество открытого кода могло бы внедрить эти идеи, но вместо этого сосредотачивается на полемике вокруг лицензий и "open source"-а.

Toybox — это минималистичная реализация стандартных утилит командной строки для Linux и Android, написанная на чистом C. Она создана как компактная и самодостаточная альтернатива BusyBox, с акцентом на простоту, корректность и соответствие стандартам POSIX. Проект включает основные инструменты вроде ls, cp, mv и многие другие, сохраняя при этом малый размер и избегая внешних зависимостей.

Разработка ведётся с упором на читаемость кода и портируемость, что делает Toybox полезной для встраиваемых систем, восстановительных сред и случаев, где важны предсказуемость и минимализм. Она часто используется в проектах типа Android Toybox, демонстрируя свою практическую ценность для современных ОС.

• Toybox — это альтернатива BusyBox с более разрешительной лицензией (0BSD/MIT-0), созданная для решения лицензионных проблем и использования в Android.
• Оба проекта предоставляют набор стандартных UNIX-утилит (ls, cp, mv и др.) в виде одного исполняемого файла, что экономит место на диске.
• Изначальная идея Toybox вызывала споры из-за отказа от copyleft, но была принята как компромисс для включения в ОС.
• Название Toybox, вероятно, отсылает к коллекции игрушек (аналогично BusyBox) и может быть связано с песней Soundgarden.
• Проект ценится за чистый код и пермиссивную лицензию, но пока не достиг полной функциональной parity с BusyBox.

В 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).

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

Ключевые особенности включают многоканальные пайпы (multipipes) для связи команд с несколькими входами и выходами, блоки {{ ... }} для асинхронного выполнения процессов и хранение значений (stored values) для обмена данными между произвольными узлами графа. Примеры использования охватывают бенчмарки сжатия, анализ кода, поиск дубликатов и обработку научных данных, демонстрируя гибкость подхода.

• Идея Dgsh оценивается как устаревшая по синтаксису, но перспективная для современных оболочек вроде nushell и elvish.
• Обсуждаются преимущества представления конвейеров данных в виде направленного ациклического графа (DAG) перед линейными пайплайнами.
• Сравнивается удобство Dgsh для создания конвейеров с написанием аналогичных задач на Python, Ruby или в чистом bash.
• Отмечается сложность работы с пайпами и процессами в Python по сравнению с shell-инструментами.
• Упоминаются альтернативные инструменты, такие как Murex, и фреймворки для оркестрации, например Apache Airflow.

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

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

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

IBM IntelliStation POWER 185, выпущенный в 2006 году, использовал процессоры PowerPC 970MP, хотя часто ошибочно причислялся к линейке POWER5. Несмотря на то, что более старшая модель 285 уже применяла DDR2 и POWER5+, 185 откатился к DDR1 и отказался от чипов POWER, вероятно, из-за переиспользования наработок System p5 185 (7037-A50). Это позволило создать менее энергоёмкую и более тихую рабочую станцию с полной совместимостью AIX, которая широко использовалась в госучреждениях и инженерных фирмах США и Японии.

Ключевая особенность системы — аппаратная виртуализация через firmware, что отличает её от Power Mac G5 с тем же CPU. Вероятно, поддержка виртуализации в PowerPC 970MP была добавлена именно по требованию IBM для System p5, тогда как Apple её не использовала. Интересно, что 970MP здесь работал в одноядерном режиме — либо через скрытый переключатель, либо через прошивку, чтобы снизить тепловыделение и позволить использовать компактный кулер. Для «двуядерности» IBM предлагала установить второй такой же чип.

• Ностальгические воспоминания о надежности и гибкости UNIX-систем (AIX, HP-UX) и проприетарных рабочих станциях (IBM, SGI, Sun) эпохи до доминирования Linux.
• Основное преимущество перед Windows XP: специализированное ПО для CAD (например, CATIA V4) и инженерных задач, лучшая производительность, поддержка большего объема памяти и повышенная безопасность.
• Обсуждение технических особенностей архитектуры PowerPC и AIX, включая управление памятью, работу с графикой и редкие особенности вроде валидного нулевого адреса памяти.
• Закат эры проприетарных UNIX-рабочих станций к концу 2000-х из-за конкуренции с более дешевыми и массовыми решениями на x86/Linux и Windows.
• Отдельные комментарии о неудобствах администрирования AIX и использовании специфического периферийного оборудования (трекболов).

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

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

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

Аккаунт sgi-demos на GitHub содержит коллекцию демонстрационных проектов, связанных с графикой и технологиями Silicon Graphics. Эти материалы представляют историческую ценность, демонстрируя передовые для своего времени визуальные эффекты и интерактивные приложения. Многие примеры иллюстрируют ранние достижения в трёхмерной визуализации и компьютерной анимации.

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

• Участники отмечают схожесть интерфейса демо SGI с меню выбора файлов в Super Mario 64 и предполагают историческую связь через партнерство Nintendo и Silicon Graphics.
• Воспоминания о работе с оборудованием SGI (Indy, O2, Octane, Onyx) и различных демо, таких как Flight, jello, bounce, fsn (3D-файловый менеджер), и их влиянии на современные технологии.
• Обсуждение технических аспектов: нестандартное соотношение сторон экранов SGI, использование неквадратных пикселей, проблемы с отображением ссылок и производительностью в браузере.
• Ностальгические истории о розыгрышах с помощью удаленного воспроизведения звука (telnet, команда say) и случайном показе изображений от предыдущих пользователей на SGI O2.
• Упоминание культурного влияния SGI, включая отсылку к фильму "Парк Юрского периода" ("Это же UNIX!") и роль компании в развитии компьютерной графики и игровой индустрии.

Systemd всё чаще становится причиной скрытых ограничений для демонов, вызывая ситуации, когда служба работает при ручном запуске от root, но отказывает в штатном режиме. Это происходит из-за директив вроде ProtectHome= (блокирующей доступ к домашним каталогам) или PrivateTmp= (создающей изолированный /tmp), которые могут приводить к "таинственным" ошибкам вроде "permission denied" или исчезновению файлов в /tmp.

Особенно коварны ограничения на IP-адреса, которые могут неожиданно блокировать DNS-запросы, если демон не использует systemd-resolved. Пока проблему можно решить, удалив ограничения из .service-файла, но в будущем некоторые демоны могут начать требовать эти настройки, что усложнит диагностику.

• Обсуждаются возможности systemd для изоляции и ограничения сервисов через настройки юнитов, что может служить альтернативой контейнеризации.
• Поднимается вопрос сложности отладки и логирования при использовании усиленных настроек безопасности systemd.
• Участники делятся практическим опытом настройки hardening'а для конкретных сервисов (например, Jellyfin) и решения возникающих проблем.
• Высказываются полярные мнения о systemd: от критики за усложнение и нарушение UNIX-принципов до поддержки за гибкость и мощные функции.
• Затрагивается тема культурного феномена хейта вокруг systemd и его сравнение с другими инструментами (Docker, Podman).

Сокращённый перевод на русский (в 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™».

Silicon Graphics Indigo² IMPACT 10000: уикенд-рефаб

Пурпурный «кирпич» Indigo² с MIPS R10000 и IMPACT-графикой пролежал в лаборативе десять лет; пора решить — оставлять или выбрасывать. Включается, но надо проверять.

В доме ещё два SGI:

• Fuel 900 MHz R16000/V12 — тихий, красный, но жрёт батарейки и БП;
• Indy 150 MHz R4400 — любимый пиццабокс, первый SGI, к которому прикасался в 1995-м в Salk Institute (рентген-визуализация + sgidoom).

Indy — упрощённый IP24-вариант той же архитектуры, что и базовый IP22 Indigo². Первые «индиго» 1993 г. (бирюзовые) начинались с 100 МГц R4000 и $35 000 (≈ $78 k сегодня); графика Extreme занимала 3 из 4 слотов EISA.

• SGI 1990-х считалась самой «сексуальной» UNIX-коробкой: Indigo, Indy, Octane, Fuel и O2 вызывали у каждого nerd-а дрожь и мечты.
• Железо ваяли в США и Швейцарии, а IRIX до сих пор называют самым красивым UNIX-интерфейсом.
• Машины снимали для VFX-комиксов и блокбастеров, в лабах стояли как святыня, доступ к Indy разрешали только с третьего курса.
• Сегодня энтузиасты держат по паре рабочих O2/Octane, запускают Firefox по X11, Doom и povray-рендеры, но музеи даром не берут.
• MIPS-процессоры быстро устарели, шум и 50-Гц фликер европейских мониторов помнят все, кто прятал Octane за дверью серверной.

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/корпоративного использования нет аудита доступа и нормального способа перешифровки для новых сотрудников — приходится менять все пароли.

• Пользователи жалуются на путаницу в именах часовых поясов: устаревшие US/*, дубли EST/EDT, городские селекторы вместо простых смещений.
• Корень проблемы — в файлах tzdata нет идентификатора зоны; если /etc/localtime не symlink, ПО вынуждено угадывать, выбирая короткое имя («US» вместо «America/…»).
• Debian по-прежнему показывает пользователю привычные Eastern/Central, но уже маппит их на корректные America/*.
• Предложения «хранить просто -8/-7» проваливаются: нужны история DST, исключения вроде Аризоны, будущие смены законов.
• Вывод: единственное надёжное решение — использовать America/Phoenix, America/Los_Angeles и т. д., а не аббревиатуры или смещения.

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

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

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
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 в старых программах и то, что стрелка ↵ всё ещё напоминает о механическом возврате каретки.

Разработка собственной ОС освобождает от ограничений коллективной работы и позволяет экспериментировать с необычными паттернами. Вдохновлённый статьёй LWN «Object-oriented design patterns in the kernel», я реализовал все сервисы ядра через «виртуальные таблицы» (vtables) — структуры с указателями на функции, обеспечивающие полиморфизм на чистом C.

Базовая идея

struct device_ops {
    void (*start)(void);
    void (*stop)(void);
};

struct device {
    const char *name;
    const struct device_ops *ops;
};

Разные устройства регистрируют свои реализации ops, а вызывающий код работает с единым интерфейсом. Таблицу можно менять на лету без изменения клиентов.

Применение в моей ОС

• Сервисы: сетевой менеджер, оконный сервер и др. описываются структурой

struct service_ops { void (*start)(void); void (*stop)(void); void (*restart)(void); };

Позволяет из терминала запускать/останавливать потоки без хардкода.

• Планировщик: интерфейс yield, block, add, next реализуется разными стратегиями (round-robin, SJF, FIFO). Политику можно заменить без пересборки ядра.
• Файлы: как в Unix, «всё есть файл». Сокеты, устройства и обычные файлы предоставляют одинаковые read/write, скрывая сложность реализации.

Модули ядра
Такой подход легко расширяется динамически загружаемыми модулями-драйверами, как в Linux.

• Обсуждение показывает, что в ядре Linux и других проектах на C давно применяют «объектно-ориентированные» приёмы через структуры с указателями на функции (таблицы виртуальных методов).
• Некоторые считают это удобным и экономным по памяти, другие — источником проблем с читаемостью, отладкой и оптимизацией.
• Упоминаются готовые микро-фреймворки (co2, carbon) и примеры из tmux, где такие паттерны уже используются.
• Спор идёт о необходимости явного параметра this: одни ценят прозрачность, другие — «сахар» неявного this в C++/Java.
• Вопрос «почему бы не перейти на C++/другой язык» сводится к контролю над памятью, отсутствию «магии» и возможности оставаться на C ради производительности и простоты.

PDF-1.2, 8191 объект, линеаризован, 598 xref-записей.  
Содержит структуру документа (каталог, страницы, шрифты, потоки), но без текста.  
Все данные — служебные, читаемого контента нет.

• Книга «The Unix-Haters Handbook» вызывает смешанные чувства: кто-то видит в ней ценный исторический артефакт и живую критику, кто-то — просто троллинг.
• Участники вспоминают конкретные «болячки» Unix: sendmail, csh, права доступа, «всё есть файл», который не всегда работает.
• Многие признают, что за 30 лет часть проблем решена, но новые появились — например, systemd, который теперь вызывает аналогичную ненависть.
• Любовь к Unix всё же сохраняется: дёшевые процессы, пайпы и «всё есть текст» делают систему удобной, особенно с помощью современных ИИ-ассистентов.
• В дискуссии всплыли ностальгия по Lisp-машинам, шутки про EMACS, барф-баг в комплекте книги и даже возможный «systemd haters handbook».

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-окружении» повторяется как ключевой.

• Участники вспоминали старые офис-пакеты и редакторы: Applixware, WordPerfect, Ami Pro, Lotus 1-2-3, iWrite/iDraw/iPaint.
• WordPerfect запускался на Linux через libc5 и патчи (wpunix), а также шёл на HPUX, SCO Unix и даже Data General.
• Всплыли ностальгические моменты: Photoshop на SGI Indy, IE 4 на Solaris, MIT-лаборатории на SPARC/SGI.
• Некоторые считают WordPerfect и Ami Pro более удобными, чем MS Word.
• Apple назван «последней уцелевшей UNIX-компанией», IBM/AIX всё ещё живы в энтерпрайзе.

Короткая история 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».