Hacker News Digest

Компьютеры не могут принимать решения — это делают люди. Любая попытка возложить вину на ИИ-модели за их действия — это «отмывание решений»: компании вроде OpenAI и Anthropic сознательно позволяют своим системам вести себя определённым образом, несмотря на возможность остановить такое поведение. Они делают явный выбор в пользу текущего использования своих технологий, и это не заговор, а открытая и документированная позиция. Подписки пользователей на сервисы вроде Claude напрямую финансируют эти решения, делая их соучастниками по умолчанию.

Ответственность за вред, причиненный ИИ, лежит исключительно на людях — разработчиках, корпорациях и пользователях, которые выбирают использовать и финансировать эти системы. То, что такие действия остаются безнаказанными и не регулируются законодательно, связано не с технической невозможностью контроля, а с экономической выгодой: ужесточение правил могло бы нанести ущерб прибылям. Эта идея не нова — ещё в 1979 году IBM внутренне обучала сотрудников, что компьютер никогда не может нести ответственность и поэтому никогда не должен принимать управленческие решения. Сегодня этот принцип игнорируется на практике, хотя его логика остаётся верной: машины не имеют намерений, вины или сознания — только люди, стоящие за ними, несут моральную и юридическую ответственность.

Ответственность за действия ИИ всегда лежит на людях — разработчиках, менеджерах, владельцах компаний — а не на самом ИИ. Юридическая и этическая система пока не справляется с распределением этой ответственности в сложных цепочках. Термин «decision laundering» точно описывает практику компаний, перекладывающих ответственность за действия ИИ на алгоритмы, хотя окончательное решение о запуске и настройке систем принимают люди. ИИ и компании не могут быть юридически ответственными — ответственность должна падать на конкретных людей, принимавших решения о развертывании и использовании систем. Использование ИИ в финансовых рынках на протяжении 30 лет подтверждает: компьютеры давно принимают решения, но ответственность несёт человек или организация, их запустившая. Спор о том, делает ли ИИ решения или лишь генерирует текст, не меняет сути: даже если ИИ выбирает действия в реальном времени (как шахматные программы), ответственность за его использование остаётся у человека. Ответственность часто уходит вверх по цепочке: разработчик → менеджер → CEO → акционеры, и в итоге никто не несёт реальной ответственности — как в корпоративных скандалах. Пользователи с подписками на $20 не являются основным источником финансирования; основную ответственность несут крупные корпорации, покупающие API-ключи и внедряющие ИИ в автоматизацию. Юридическая система пока не применяет санкции к Anthropic или OpenAI за вред, нанесённый ИИ, создавая ложное ощущение «правовой туманности» и поощряя безответственность. Сравнение ИИ с собаками или автомобилями показывает: даже если сущность принимает действия, ответственность лежит на владельце или разработчике, а не на самой сущности. Чтобы избежать отмывания ответственности, нужно называть конкретных людей, запустивших ИИ-агентов, а не абстрактные компании — например: «John Smith запустил агента, отправившего ложный тайп». Управление не несёт ответственности, потому что решения принимаются заранее, а последствия оцениваются позже — это системная проблема корпоративной культуры, а не только ИИ. ИИ не обладает свободой воли, но это не делает его менее эффективным — проблема не в способности, а в том, что общество не готово признать, что человек должен отвечать за то, что он позволил делать машине. Когда ИИ ошибается, компании используют язык вроде «агенты сбежали» — это пропагандистская стратегия, чтобы скрыть, что решения принимались людьми и были осознанными. Вопрос о том, может ли ИИ быть ответственным, — философская и юридическая дилемма, но текущая практика показывает: ответственность всегда перекладывается на человека. Если бы ИИ был признан юридическим субъектом, это не решило бы проблему — тогда нужно было бы признать и корпорации такими же, что противоречит текущей правовой системе. Системы, принимающие решения без человеческого контроля (алгоритмическая торговля, автономные системы управления инфраструктурой), уже существуют — и ответственность за них всегда лежит на людях, их создавших.

Red Hat как бренд и корпоративная культура постепенно уничтожается IBM: сотрудники больше не носят логотип Red Hat, а их идентичность заменена на IBM. Несмотря на заявления о продолжении работы, многие ушли добровольно или были вынуждены покинуть компанию, включая команды из Nordcloud — ещё одного приобретённого IBM подразделения. Внутри ощущается атмосфера неопределённости: вместо технической работы доминируют «фейковые» задачи, направленные на поддержание акций, а не на развитие открытого ПО.

IBM системно разрушает приобретённые компании — Red Hat, Kyndryl, Nordcloud — через PIP-процессы, массовые увольнения и «вымывание» культуры. Технические команды, включая квантовые, исчезают под предлогом «реорганизации», а их работа превращается в «вапорваре». Сотрудники описывают это как уничтожение инноваций ради краткосрочной выгоды, что обманывает инвесторов и разрушает доверие. Процесс не случайный — это стратегия IBM по «креативному» упадку.

IBM интегрировала административные функции Red Hat (HR, финансы, юридический отдел, ИТ), но оставила инженерные команды и открытые проекты автономными, как подтверждено в подкасте Кришны и отмечено @bonzini. Открытые проекты нельзя превратить в проприетарные — сообщество сохраняет независимость, как показывают примеры Oracle/Sun и Hashicorp/Terraform. IBM сосредоточена на крупных институциональных клиентах (правительства, банки, здравоохранение), не придавая ценности широкой популярности проектов, как подчеркнул @topspin. OpenShift Virtualization дешевле vSphere, построен на Kubernetes без планов менять архитектуру, подтверждено сотрудником Red Hat. Несмотря на активное продвижение бренда Red Hat (YouTube, мероприятия), отмечено падение морального духа и отток талантов после поглощения, что может повлиять на инновации и поддержку. Бренд сохраняется, но существует спор: одни считают, что культура Red Hat исчезнет, другие уверены, что бренд и открытая методология останутся. Если беспокоит будущее поддержки Red Hat, рассмотрите миграцию на альтернативные дистрибутивы, например NixOS, как советует @toomuchtodo.

IBM Bob — это AI-ассистент для разработчиков, интегрированный непосредственно в среду разработки (IDE), который работает как партнёр в процессе создания ПО. Он поддерживает подход Literate Coding: разработчик описывает задачу на естественном языке, а Bob генерирует соответствующий код прямо в контексте проекта, устраняя необходимость переключаться между чат-окнами и редактором. Это ускоряет разработку и повышает качество кода за счёт контекстно-осознанных предложений.

Bob также предоставляет аналитику через Bobalytics — панель, отслеживающую вклад ИИ-агента в жизненный цикл поставки ПО на уровне всей организации. Это позволяет измерять бизнес-ценность использования ИИ, оптимизировать затраты и стимулировать внедрение агентных практик. Кроме того, Bob обеспечивает прямую интеграцию с Red Hat, Instana и другими корпоративными сервисами, bringing enterprise-grade архитектуру, безопасность и мониторинг прямо в IDE, что минимизирует переключение контекста и укрепляет DevOps-потоки.

Обсуждение скептичное: IBM Bob сравнивают с провальным Microsoft Bob 90-х, считая названием и подходом ностальгической насмешкой. Продукт воспринимается как переработанный Watson — повторение стратегии с отсутствием прозрачности, зависимостью от сторонних моделей и слабой интеграцией с реальными системами. Ценообразование в Bobcoins и мем-маркетинг (маскот, дизайн) читаются как несерьёзность и попытка скрыть слабость продукта. IBM не считается доверенным поставщиком на фоне истории с Watson и ухода от лидерства в ПО. Продукт ориентирован на менеджеров, а не инженеров — в обсуждении преобладают цитаты от руководства, а не разработчиков. Участники спорят, что Bob — обёртка над существующими моделями (Claude, OpenAI) без доказательств улучшенной интеграции с IBM i или z/OS, в отличие от конкурентов, уже обученных на этих системах. Часть участников считает, что Microsoft Bob не был ошибкой, а просто опередил время, но другие возражают: IBM повторяет ту же ошибку без учёта опыта. Советы: — Не называть продукты Bob в Великобритании — из-за сленга «bobbins» (чепуха) название обречено на насмешки, если продукт не идеален. — IBM стоит вернуться к созданию качественного ПО вместо продажи «агентских навыков» за $20/мес и опоры на консалтинг. — Разработчики не доверяют вендорам, контролирующим модели, — предпочтительнее открытые токены, чем закрытые «харнессы» под брендом IBM. Падение акций IBM на 20% за год отражает неверие рынка в подобные инициативы — Bob не решит системных проблем. Копирайтинг на сайте выглядит сгенерированным ИИ, что подрывает доверие даже при технической состоятельности продукта.

Основная идея — полностью эмулированная графическая среда, работающая на реальном IBM PC XT с процессором 8088, где каждый запущенный элемент (окно, панель, мини‑приложение) представляет отдельный процесс, имеет собственный док‑тик и независимый буфер памяти. При этом ядро управляет прерывками, планированием и выделением сегментов так, что даже простые программы, как MINES (1,5 КБ) или HELLO, загружаются в собственные 2 КБ и 512‑байтные области без модификации кода.

Особенности, которые запоминаются: одновременная работа до пяти программ, включая «живой» About‑box, отображающий состояние планировщика, и плавный XOR‑трекинг курсора при перемещении окна; минимизация не останавливает фоновые задачи, а лишь скрывает их визуализацию; иконки файлов берутся непосредственно из первого сектора диска, а графические редакторы (Paint, Fractal) используют буферы и кольцевые истории, позволяющие выполнять фоновые операции, пока запущены ресурсоёмкие приложения. Всё это демонстрирует, как ограниченные ресурсы IBM PC XT могут поддерживать современный‑по‑удобству пользовательский интерфейс.

Тред обсуждает реализацию графической ОС Os8088 для IBM XT, 286, 386: участники анализируют код, производительность и опыт использования подобных систем, а также роль ИИ в разработке. Проект признаётся интересным примером графической ОС на старом железе, но некоторые скептически относятся к применению ИИ. Обсуждается уязвимость к перезаписи обработчиков прерываний и таймера — одни считают это значимой проблемой, другие — нет. Предлагаются улучшения: поддержка сети, улучшение интерфейса, портирование приложений вроде WordStar и VisiCalc. Отмечается потенциал ИИ в создании сложных систем, но подчёркивается необходимость человеческого участия в разработке и документировании.

Как 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 в старых программах и то, что стрелка ↵ всё ещё напоминает о механическом возврате каретки.