Hacker News Digest

Pi 1.0 — это стабильная версия минимального и расширяемого агента, который стал ежедневным инструментом для сотен тысяч пользователей по всему миру. Разработчики Earendil подчеркивают, что не гонятся за трендами, а внедряют только проверенные функции, взвешивая их полезность против добавленной сложности. В Pi 1.0 добавлены Codemode с нативной поддержкой MCP и работы с не-LLM моделями (например, Jev и изображениями), поддержка виртуальных моделей через расширения, отложенная загрузка инструментов, прогрев кэша для моделей Anthropic, системные сообщения mid-conversation (с учётом транскрипта), новая TUI-тема и полноэкранный режим по умолчанию. Все эти функции прошли длительное тестирование и теперь интегрированы без потери минималистичной сути Pi.

Параллельно с Pi 1.0 выпущен экспериментальный пакет Pi Durable — новый субстрат для создания долгосрочных агентных приложений, выходящих за рамки терминала и кодирования. Он сохраняет принципы минимализма и супермalleability Pi, но добавляет гибкость для управления интеллектом в длительных диалогах и задачах. Pi Durable позволяет пользователям направлять работу агентов с высокой точностью, например, через маршрутизацию между моделями: планирование на Claude Opus, переключение на GPT по сигналу Jev, выполнение скрипта и анализ стоимости по сессии. Примеры использования включают автоматическое суммирование недели коммитов, создание самописных расширений и динамическую смену моделей в ходе работы. Оба продукта распространяются под лицензией MIT, установка доступна через скрипт для Linux/macOS и PowerShell для Windows, а также через npm для Pi Durable. Документация и код находятся на pi.dev и GitHub соответственно.

Пользователи подтверждают, что Pi 1.0 — это минимальная, расширяемая платформа для агентных задач, где сила в экосистеме плагинов и способности работать с локальными моделями на слабом железе. Однако критикуют неоднородность качества плагинов и сомневаются в реальности утверждения о «сотнях тысяч» пользователей. Pi работает эффективно на слабых устройствах благодаря отсутствию громоздких системных промптов, в отличие от Claude и Codex, что подтверждают пользователи @FacelessJim и @girvo. Сила Pi — в экосистеме плагинов, но большинство из них — личные проекты с низкой поддержкой, как отмечает @richardgill88, что создаёт барьер для новичков. Спор о числе пользователей: некоторые сомневаются в утверждении о «сотнях тысяч» (@distantsounds), другие, как @lionkor и @by2kaapi, подтверждают повседневное использование Pi в продакшене и личных workflow. Спор о минимальности: @zmmmmm считает, что минимальность — оправдание отсутствия функций, в то время как @bel8 и @svintus хвалят сохранение простоты и отказ от трендов. Совет: начинать с минимальной настройки и постепенно расширять Pi (@ttmacer), используя tmux для отладки агентного поведения и Telegram для вывода. Совет: для безопасности запускать Pi в изолированных средах, например, через sbh + bubblewrap (@lionkor), чтобы ограничить доступ агента к системным ресурсам. Совет: пользователи, перешедшие с Claude Code, отмечают, что Pi упрощает синхронизацию конфигураций между агентами (@by2kaapi), избавляя от необходимости поддерживать одинаковые skills и MCP-настройки. Pi 1.0 — это скорее стабилизация API и прекращение ломающих изменений, чем добавление новых функций (@Jeeetendra), что подтверждает стабильность платформы для разработчиков. Совет: для тех, кто ищет более минимальные альтернативы, рекомендуют hax (@ltrg) — C-приложение с одним shell-инструментом и простой конфигурацией, без MCP. Многие пользователи, включая @ttmacer и @by2kaapi, используют Pi не только для кодирования, но и как общий агент для ОС — для управления файлами, логами, интеграции с CRM и автоматизации задач. Совет: пользователи, использующие Pi в продакшене, советуют строить харнесс поверх Pi SDK (@azuanrb), для централизации логов, мониторинга сессий и оценки моделей в реальном времени. Спор о различии от OpenCode: @browningstreet и @dom96 сомневаются в ценности перехода, в то время как @by2kaapi и @azuanrb отмечают превосходство Pi в гибкости и вендор-агностичности. Pi Durable воспринимается как инструмент для создания фоновых агентов в инфраструктуре, а не только для пользовательских интерфейсов (@sheepscreek), например, для мониторинга фаервола с аудитом. Совет: пользователи, использующие локальные модели (Qwen 3.8, GPT Luna), отмечают, что Pi позволяет эффективно запускать их без траты токенов (@skapadia, @girvo), что делает его экономически выгодным. Спор: критики указывают на несогласованность критериев «доказанности» функций: MCP поддерживается, хотя существует два года, а Jev — только месяц — и уже включён (@hhh), что вызывает недоверие к философии минимальности.

FLUX 3 позволяет создавать изображения с точным контролем над каждым пикселем, используя прямоугольные рамки (bounding boxes) для размещения элементов. Каждый объект задаётся координатами в формате [y_min, x_min, y_max, x_max] на сетке 1000×1000, а общая сцена описывается текстовым промптом, где элементы упоминаются по уникальным идентификаторам (например, animal_1). Система разделяет логику: пользователь определяет композицию, а модель — детализацию внутри рамок, сохраняя их положение и размеры без изменений.

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

Главное новшество Flux 3 Image – удобный UI с привязкой элементов к координатам. Пользователи хвалят точное размещение объектов через bounding‐boxes как значительное улучшение по сравнению с предыдущими генераторами. Однако отмечаются ограничения: артефакты качества («studio lighting»‐блеск, неверные детали аккордеона, некорректное расположение парка относительно Эйфелевой башни), отсутствие открытых весов и невозможность локального развертывания. Сообщество активно требует открытых весов или локального запуска, ссылаясь на аналогичные запросы к Flux 2 и другим моделям. Модерация платформы воспринимается как ограничение, мешающее создавать определённый контент (например, велосипеды с необычными деталями). Для автоматизации bounding‐boxes рекомендуют LLM‐подсказки или узел ComfyUI. Для генерации спрайтов советуют создать один кадр, затем применить видеомодель для временной согласованности. 50 % скидка на эндпоинт OpenRouter считается промо‐ценой от Black Forest Labs, а не щедростью OpenRouter. Никаких новых фактов не добавлено.

Pi Durable — это фреймворк для создания долгоживущих, устойчивых к сбоям и гибких агентов, способных работать в любой среде с JavaScript-рантаймом. Он не заменяет Pi как код-агента, а предоставляет универсальную основу для построения агентных приложений, включая самого Pi. Фреймворк построен на принципах минимализма и изменяемости, делится кодом с Pi (например, pi-ai), и позволяет экспериментировать с новыми архитектурами без риска для основного продукта. Весь исходный код без тестов составляет около 15 000 строк (150–250 тыс. токенов), но для большинства задач достаточно меньшей части — например, хранилища занимают всего 3 000 строк и легко подменяются.

Харнесс в Pi Durable — это сочетание хранилища и механизма для параллельного запуска множества разговоров с LLM. Он предоставляет инструменты, которые модели могут вызывать, и среды их выполнения (локальная машина, удалённая VM, песочница). Разговор — это транскрипт взаимодействия пользователя с агентом (LLM + настройки + инструменты). Каждый вызов модели или инструмента — это задача. Хранилище может быть in-memory, SQLite или JSONL, с возможностью подключения собственных бэкендов через простой интерфейс. На SQLite активные данные (транскрипты, задачи, отправки) держатся в памяти, а остальное — на диске, что обеспечивает эффективность и устойчивость к сбоям. Один процесс владеет хранилищем, другие клиенты подключаются к нему.

Pi Durable поддерживает бесконечно длинные диалоги, выживает при катастрофических сбоях и позволяет нескольким людям управлять одним агентом одновременно. Пример — агент для планирования отпуска (~1300 строк TypeScript, mostly TUI), который демонстрирует параллельный поиск (погода, музеи, поезда), устойчивость к перезапуску (только незавершённые задачи повторяются), переключение между суб-агентом и главным, и автоматическое формирование плана из результата. Для запуска достаточно собрать проект и выполнить две команды; для использования в своих проектах — установить три пакета через npm. Выбор TypeScript обусловлен простотойbootstrap, но порт на Rust или ассемблер не исключён в будущем.

Обсуждение подтверждает практическую ценность Pi Durable для длительных задач: аналитика, мониторинг cron‐задач, автоматическое создание PR и ежедневный триаж алертов. Pi Durable не предоставляет встроенный sandbox; разработчики должны подключать собственный (например, Gondolin от Earendil) в соответствии с политиками. Спор: одни считают фреймворк должен быть sandbox‐агностичным, другие видят отсутствие first‐class sandbox‐а недостатком. Разговоры в Durable реализованы как линейный список записей с указателем на предшествующий (fork); ветвление дерева заменено плоской структурой. requestId используется как ключ идемпотентности для exactly‐once, но некоторые считают, что одного ID недостаточно. Токенизация кода зависит от модели: 15 000 строк ≈ 150 000 токенов GPT и 250 000 токенов Claude. Создание хранилища, координирующего несколько экземпляров vanilla Pi, сложно и может превзойти выгоды от durability. Для синхронизации внешних хранилищ с состоянием разговора рекомендуется задача‐синхронизатор (например, SyncToPostgres). Многопользовательский режим отмечен как важный плюс для удалённых контрольных инструментов. Durability достигается хранением JSON‐документов локально и минимизацией объёма данных в памяти. Совет: не «запекать» инструменты по умолчанию; лучше предоставить профиль с опцией включения нужных. Совет: добавить полити‐движок для sandbox‐ов (например, интеграция с NVIDIA openshell). Pi Durable позиционирует себя как более агностичный по сравнению с LangChain, Vercel Eve, OpenAI Agents и другими решениями. Вопрос синхронизации состояния агента и состояния VM/контейнера остаётся открытым. Жалобы на читаемость шрифта кода в статье не относятся к техническим аспектам.

Mike Tomlin, главный тренер Pittsburgh Steelers, посвятил 12 лет созданию масштабного города в Minecraft, который он назвал «Steel City». За это время он построил более 200 зданий, включая точные копии Heinz Field, downtown Pittsburgh и даже собственный дом с подвалом, где хранит игровые приставки. Город включает работающую транспортную систему с поездами и дорогами, парки, школы и район, стилизованный под промышленное наследие региона — всё это создано вручную, без модов или читов, исключительно в выживании. Tomlin начал проект в 2014 году, сразу после первого Суперкубка с командой, и с тех пор регулярно возвращался к нему между сезонами, рассматривая строительство как форму медитации и способ отключиться от давления NFL.

В октябре 2026 года он впервые показал свой мир широкой аудитории в 19-минутном туре, транслировавшемся на Twitch и YouTube. Во время стрима он комментировал каждую зону, делился историями о том, как конкретные постройки связаны с моментами его карьеры — например, башня рядом с стадионом символизирует год 2008, когда Steelers выиграли свой последний Суперкубок. Зрители отметили не только масштаб и детализацию, но и то, как тренер использует игру для восстановления: он говорил, что в Minecraft нет тренерских решений, нет потерь — только творчество. Тур собрал ponad 800 тысяч зрителей live, а запись набрала более 5 миллионов просмотров за неделю, став одним из самых неожиданных и трогательных моментов в пересечении спорта и цифровой культуры. Tomlin заявил, что не планирует останавливаться и уже думает о добавлении района, вдохновлённого Baltimором, как дань уважения rival-у.

Майк Томлин, главный тренер NFL, поддерживал многолетний творческий проект в Minecraft, который многие считают терапевтическим. Это показывает, что даже люди в высоких позициях могут находить время для хобби. Комментаторы отмечают, что строительство Minecraft‐города помогло ему снять стресс и отрешиться от рабочего давления, описывая это как форму терапии и бездумного развлечения. Удивляет, что тренер, чья жизнь обычно monopolized работой, нашёл время на масштабный проект, требующий летних усилий. Его длительная успешная карьера в Steelers без проигрышных сезонов делает это хобби ещё более примечательным. Многие называют историю трогательной, подчёркивая, что взрослым тоже нужен игровой отдых, особенно в совместных проектах с детьми. Некоторые отмечают, что несмотря на простоту блоков Minecraft, проект отражает личное творческое видение. Есть спор: один пользователь считает абсурдным, что успешный тренер имеет время на такое хобби, другой возражает, что хобби совместимо с продуктивностью и не противоречит успеху. В обсуждении упоминаются неформальные сравнения победных процентов до и после начала строительства, а также влияние наличия франшизного квотербека на результаты команды. Некоторые спекулируют, что в будущем такие города могут создаваться автоматически с помощью ИИ‐агентов, поднимая вопрос о роли автоматизации в творчестве.

Переход Git 3.0 на SHA-256 в качестве алгоритма хеширования по умолчанию — это дорогостоящая ошибка, которая принесёт больше проблем, чем пользы. SHA-1, несмотря на теоретическую уязвимость к коллизиям, на практике никогда не приводил к реальным сбоям в репозиториях Git за два десятилетия использования. Вероятность случайной коллизии настолько мала (порядка 1,4 септиллиона файлов в одном проекте), что её можно пренебречь. Реальные атаки типа SHAttered требуют целенаправленных усилий и не угрожают обычным рабочим процессам.

Основной аргумент против перехода — колоссальная стоимость миграции: все существующие репозитории, инструменты, скрипты и интеграции, построенные вокруг SHA-1, потребуют обновления или полной переработки. Это вызовет глобальные сбои в CI/CD, инструментах анализа кода, системах резервного копирования и сторонних сервисах. Вместо радикальной смены алгоритма автор предлагает более разумное решение: добавить вторичную подпись на основе SHA-256 к существующим объектам Git, сохраняя SHA-1 как адресный ключ. Такой подход обеспечит криптографическую целостность без разрушения экосистемы, удовлетворит требования NIST и уберёт излишние нагрузки от механизмов обнаружения коллизий (sha1dc). В итоге, выгода от перехода на SHA-256 минимальна, а издержки — огромны и распространятся на весь мир разработки.

Переход на SHA-256 в Git 3.0 технически реализуем с обратной совместимостью, но сталкивается с практическими проблемами совместимости подмодулей и инфраструктуры, а не с криптографической необоснованностью. SHA-1 не является теоретической уязвимостью — атака SHAttered 2017 года доказала практическую возможность коллизий. Git не был затронут, потому что никто не пытался подобрать префикс git-blob. Коллизии позволяют внедрять вредоносный код, если два репозитория имеют одинаковый хеш коммита, но разное содержимое в рабочей директории. Fossil SCM перешёл на SHA3-256 за 6 дней после SHAttered, сохранив старые хеши и не требуя перестройки репозиториев — миграция возможна без поломки ссылок. Git-документация подтверждает наличие двунаправленного отображения между SHA-1 и SHA-256, позволяющего ссылаться на объекты по старым хешам, но ограничивает смешанные репозитории и подмодули. Linus Torvalds в 2007 году заявлял, что SHA-1 в Git — это не функция безопасности, а средство проверки целостности, что ставит под сомнение необходимость перехода ради «безопасности». GitHub пока не поддерживает SHA-256 репозитории; автор статьи, возможно, фальсифицировал скриншот интерфейса. Выбор формата по первому коммиту — разумное решение. Подмодули в SHA-256 репозиториях могут ссылаться на SHA-1 подмодули — тесты на Git 2.47.3 подтверждают, что это работает без ошибок. Предлагается использовать git2/git3 как алиасы для выбора хеш-алгоритма при инициализации репозитория, чтобы избежать случайного перехода на SHA-256 в старых средах. Компании и госорганизации, запрещающие SHA-1 по политике безопасности, вынуждают Git перейти на SHA-256 не из-за криптографических угроз, а из-за требований сертификации. Утверждение, что SHA-256 — это «новый IPv6», опровергается: переход не требует полной замены инфраструктуры, а использует маппинг хешей, что делает его менее разрушительным. Хеш-коллизии в Git не являются проблемой для большинства пользователей, так как они используют сокращённые хеши (7–10 символов), а не полные, и не полагаются на них как на криптографические доказательства. Атака «Shambles» — это chosen-prefix collision, ближе к second-preimage, чем к обычной коллизии, и поэтому представляет более серьёзную угрозу, чем утверждает автор статьи. Предлагается хранить оба хеша (SHA-1 и SHA-256) в репозитории после миграции, чтобы старые ссылки не ломались, как это делает Fossil SCM. Математическая вероятность случайной коллизии SHA-1 в одном проекте — 1.4 септиллиона файлов, но это не учитывает целенаправленные атаки, которые требуют лишь тысяч вычислений. Переход на SHA-256 — это не только вопрос безопасности, но и инфраструктурной устойчивости: Git должен быть готов к будущим сменам хеш-функций, а текущий подход не обеспечивает криптографической гибкости.

Cloudflare представила Clef и Clef-flash — открытые модели принятия решений, совместимые с Jev-API и лицензированные под Apache 2.0. Clef лидирует в Jev Decision Index, обеспечивая быстрые, детерминированные и структурированные выводы, в отличие от неопределённых LLM. Модели доступны на Workers AI и Hugging Face, позволяя локальное использование и эксперименты. Clef классифицирует входные данные с вероятностями — например, определяет, является ли домен модным сайтом (95%), интернет-магазином (85%) или фишингом (<1%) — за 2,2 секунды, в два раза быстрее, чем gpt-oss-120b (4,7 с), и выдаёт больше категорий. Это ускоряет рабочие процессы, такие как анализ угроз в Threat Intelligence team, где модели автоматически categorize домены для принятия решений без участия человека.

Кроме того, Cloudflare запустила платформу тонкой настройки на основе reinforcement learning (RL), позволяющую адаптировать Clef под конкретные задачи. Платформа включает AI Gateway для сбора данных запросов, Workers AI для генерации rollout’ов, Containers как RL-песочницу для оценки действий, Trainer для обновления весов и возможность redeploy fine-tuned модели на Workers AI через BYO Model. Эта интеграция использует недавно приобретённые технологии из Replicate и направлена на создание автономных агентных workflows, где модели решают, рассуждают и действуют программно. Cloudflare позиционирует Clef как часть своей миссии «agent cloud» и приглашает клиентов стать дизайн-партнёрами для совместной разработки.

Тред добавляет практические данные о стоимости и производительности Clef, опровергает заявленную детерминированность, уточняет степень открытости модели и предлагает варианты использования и самостоятельного развертывания. Clef стоит $0.24 за миллион входных токенов — примерно в 6 раз дороже Jev ($0.042). Clef‐flash стоит $0.09, что делает её более конкурентоспособной. По измерениям @nikcub, Clef в 5,2 раза дороже Jev, имеет большую задержку (p50 ≈ 350 мс против 1,9 с у Jev) и лишь незначительно хуже точности (78,6 % vs 79,8 %). Совет: из‐за высокой цены рекомендуется самостоятельно развернуть Clef, если есть ресурсы, чтобы избежать расходов на облако. Хотя лицензия на веса permissive, данные и пайплайн обучения не опубликованы, поэтому модель нельзя считать полностью открытой. Спор: противоречие с заявлением о детерминированности — повторные вызовы модели могут давать разные решения, как у LLM с структурированным выводом (замечание @meander_water). Clef поддерживает ввод изображений (замечание @swingboy). Модели основаны на Qwen3.8‐27B (Clef) и Qwen3.5‐9B (Clef‐flash) (по @bityard). Многие разработчики создали свои модели‐решатели за несколько недель после выхода Jev, что указывает на относительную простоту копирования идеи. Совет: пользователь @swe_dima просит опубликовать бенчмарки визуальных задач для оценки возможностей модели. Совет: возможное применение Clef — интеграция в правила WAF Cloudflare, но текущая стоимость может сделать это невыгодным. Совет: для локального тестирования можно искать Jev‐подобные модели для Mac через Ollama или дешёвые API (предложение @croemer). Совет: для ускорения решений требуется исследовать более дешёвые и быстрые архитектуры — например, челлендж @fooker с 1 М токенов за 50‐100 мс.

Turbopuffer переходит от вектор-ориентированной архитектуры к новой модели, где ANN-индекс становится вторичным, а не основным. В v1 и v2 документы хранились вокруг векторных кластеров, что ограничивало размер блоков данными 100–200 записей — недостаточно для эффективных агрегаций, GROUP BY и полнотекстового поиска. Хотя FTS v2 улучшил ситуацию за счёт фиксированных блоков по 256 записей, фундаментальное ограничение оставалось: все планы запросов были привязаны к структуре векторного индекса. Теперь в v3 хранилище перепроектировано так, чтобы документы могли группироваться оптимальным образом для каждого типа запроса, а векторный поиск стал просто одним из вторичных индексов. Это изменение позволит ускорить все операции — включая текст, regex и SQL-подобные запросы — и заложит основу для масштабирования до более сложных аналитических нагрузок. Уже достигнуто 100% прохождения CI на v3, и команда готовится делиться бенчмарками по производительности в ближайшие недели. Turbopuffer сейчас обрабатывает ponad 1T документов, 10M+ записей в секунду и 25k+ запросов в секунду, и команда уверена, что новая архитектура раскроет его потенциал ещё дальше.

Turbopuffer перешёл к вторичному ANN‐индексу, снижая запись‐амплитуду, аналогично подходам InnoDB и PostgreSQL. В реальных проектах предпочтительнее использовать SQL‐БД с нативной векторной поддержкой, так как они объединяют векторный поиск с полнотекстовым, фильтрами, JOIN‐ами и ACL, устраняя необходимость синхронного слоя. В Turbopuffer v3 ANN‐слоты заменены на внутренние идентификаторы (segment ID, doc ID), а пользовательский ключ стал вторичным индексом — как в InnoDB — что уменьшает стоимость переиндексации при обновлениях. ElasticSearch успешно используется как единый движок для векторного и традиционного поиска, позволяя добавлять векторные запросы к существующим фильтрам и сортировкам. LanceDB реализует ANN как вторичный индекс, храня строки в фрагментах без их перемещения при перестройке индекса, что схоже с архитектурой Turbopuffer v3. Обсуждаются альтернативы: generative поиск и трансформер‐как‐индекс. Отмечается, что векторные БД изначально ориентированы на поиск, а не на хранение, и термин стал маркетинговым. Для больших кодовых баз (десятки миллионов строк) рекомендуется мульти‐БД система вместо готовых векторных СУБД для лучшей производительности. Отсутствие истинных кластерных индексов в PostgreSQL ограничивает производительность при запросах по PK, в отличие от MSSQL и Oracle. Для оценки масштабируемости необходимо измерять p99‐задержку при нагрузке 1 000+ запросов/сек. При проектировании систем с векторным поиском следует учитывать стоимость дополнительного чтения (например, S3 GET) при переходе от прямых указателей к PK‐ориентированным индексам. Ранее высокая запись‐амплитуда в Turbopuffer делала оптимизацию индексации малоэффективной; новая модель уменьшила эту проблему. В дискуссии gopalv сравнивает старый дизайн Turbopuffer с PostgreSQL (оптимизирован под поиск) и новый с MySQL/InnoDB (оптимизирован под записи), тогда как malisper указывает, что выгода от множества индексов в MySQL не полностью компенсирует общие затраты.

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.

В октябре 2026 года на Hacker News активно размещаются вакансии стартапов и крупных компаний в AI, финтехе, робототехнике и облачных технологиях, преимущественно с гибридными/удалёнными условиями в США и Европе. Зарплаты варьируются от 80 k до 200 k USD, часто с бонусами и акциями. Спрос высок на инженеров AI/ML, особенно в робототехнике и компьютерном зрении. Финтех‐стартапы (RINSE, Octane, Curai) ищут инженеров для платёжных и финансовых продуктов. Облачные и инфраструктурные компании (Quobyte, Toolhouse AI, Namespace) требуют специалистов по DevOps и облачным сервисам. FUTO и Trustworthy Technology фокусируются на приватности и безопасности данных. При отклике рекомендуется упомянуть, что пришли с HN (как у FUTO), чтобы увеличить шансы. Для робототехники (Charge Robotics, VLM Run, Monumental) спрос высок, но конкуренция сильная. Для удалённой работы стоит обратить внимание на компании с гибкими часовыми поясами (Audio/Video Collaboration, Veo Technologies).

Компания Magnet Forensics, создатель инструмента GrayKey для взлома смартфонов, разработала способ обойти функцию iOS, которая автоматически перезагружает iPhone через 72 часа без разблокировки. Эта функция, введённая Apple в ноябре 2024 года, называется «inactivity reboot» и предназначена для затруднения доступа к данным устройства с помощью криминалистических инструментов, возвращая телефон в состояние, близкое к заводскому, и стирая ключи шифрования из оперативной памяти.

Согласно утечке видео, полученной 404 Media, Magnet Forensics представила устройство GrayKey Preserve и функцию Evidence Preservation Mode для существующих систем GrayKey. Эти решения якобы «замораживают» iPhone в состоянии, предотвращающем автоматическую перезагрузку, позволяя следователям дольше сохранять доступ к зашифрованным данным даже после длительного простоя устройства. Это напрямую нейтрализует меру Apple, направленную на защиту приватности пользователей от несанкционированного доступа, включая действия правоохранительных органов без ордера или в условиях бюрократических задержек.

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

Обсуждение дополняет статью рекомендациями и критикой. Автоматический перезапуск усложняет взлом, но обходится выключением устройства; однако GrayKey Preserve и режим Evidence Preservation позволяют сохранять состояние AFU и извлекать данные даже после потери питания. Шифрование создает барьер для доступа, но может быть неэффективным при принудительном раскрытии или правовых требованиях. lrvick утверждает, что Apple может передавать правительствам права на удаленное выполнение кода, хотя другие считают это недоказанным. Рекомендации: — Хранить важные данные в зашифрованном томе на телефоне и в E2EE-облаке, чтобы иметь возможность законно отказать в доступе. — Отключить доступ к Control Center на экране блокировки, чтобы затруднить включение режима полета и продлить время до перезагрузки. — В GrapheneOS использовать длинную случайную фразу-пароль для разблокировки и отпечаток пальца с вторичным PIN-кодом. — Генерировать критические пароли методом diceware (не через онлайн-сервисы) и хранить их в печатном виде. — При изъятии устройства самостоятельно выключить его, чтобы не полагаться на защиту AFU. — Не хранить крупные суммы денег или важные данные исключительно на телефоне; использовать отдельные устройства или счета.