Hacker News Digest

• Используйте клавиши ↑ (Вверх) и ↓ (Вниз), чтобы переместить указатель к нужному загрузочному устройству.
• Нажмите Enter для попытки загрузки или Esc для отмены.

Параметры загрузки:

• Обычная загрузка Windows
• Установить Windows
• Встроенный NIC (IPv4)
• Встроенный NIC (IPv6)

Другие параметры:

• Настройка BIOS
• Конфигурация устройств
• Обновление прошивки BIOS
• Изменить режим загрузки

• Пользователи делятся ссылками на JS-клон Windows XP (win32.run) и настоящие эмуляторы (VirtualXP, v86).
• Все восторгаются ностальгией: звук загрузки, старый ключ продукта, кастомизация TweakXP.
• Замечены неточности клона: шрифты, тени, отсутствие Pinball, «быстрая» загрузка, Python 3 вместо 2.x.
• Кто-то шутит, что запустит сайт на полный экран в офисе, чтобы напугать IT.
• Общий вывод: XP — пик дизайна и функциональности, но перед нами всё-таки симулятор, а не настоящая система.

• Пару дней назад OpenAI впервые за долгое время выпустила открытый языковой модуль. Сроки откладывали из‑за «безопасности». Они много говорят о безопасности — удобно для пиара: на вопросы об этике можно показывать на эти работы и будто бы закрывать тему. Но под «этикой» люди чаще имеют в виду не мат, фильтры и троллейбусные дилеммы, а реальность: управление и подотчётность, использование данных, перераспределение власти и денег, влияние на занятость. Вопрос: что делают люди, управляющие моделями, и как это влияет на общество?

• Такой подменой уже пользовались в теме приватности. В 1990‑х телемаркетинг покупал клиентские базы у компаний, которые не понимали ценность данных. Возмущение породило шаблон: «мы не делимся данными с третьими сторонами». Непроизнесённая часть: «им проще купить нас целиком — это и есть стратегия выхода». Сегодня, говоря о приватности, людей волнует, что делает с их данными именно текущая компания/приложение: школьное, парковочное, для проезда. Но разговор сводят к «чтобы посторонние не получили доступ», а не к «что конкретно делает эта компания». В итоге возникает индустрия соответствия и тестирования, честно решающая второстепенную задачу, чтобы не решать главную. Как политик, который на «поднимете ли налоги?» отвечает «мы вырастим экономику».

• С ИИ иначе лишь потому, что тема новая, и мы опирались на sci‑fi мысленные эксперименты. Они увлекательны и безопасны для бизнеса: никто не хочет «бумажкоскрепочную» катастрофу или симуляцию Black Mirror, а обсуждать это — выгодный пиар и бесплатное внимание прессы. Но такое сужение смещает фокус с реальных последствий и распределения ответственности на удобные, далекие от практики сценарии.

• Обсуждение критикует «этику/безопасность ИИ» за смещение фокуса с практических проблем (доступность жилья/еды, защита данных, рабочие места) на абстрактные «структуры управления» и пиар вокруг гипотетического AGI.
• Часть участников отличает «этику» от «безопасности» (этика шире), указывая на подмену тем и маркетинговую гиперболу; другие считают, что без глобальных договорённостей с санкциями этика неработоспособна.
• Сильная полемика вокруг квалификации «этиков/безопасников»: одни обвиняют их в непрактичности, другие отвечают, что в области много технических специалистов и исследований.
• Ассимовские законы в целом отвергаются как литературный приём, непригодный для реальной инженерии ИИ, особенно в парадигме обучения на данных и «чёрного ящика».
• Большое внимание «приземлённым» рискам: злоупотребления корпоративными данными и скрейпингом, энергопотребление, уязвимости и malware (не зависящие от ИИ), экономическое давление, утрата рабочих мест, концентрация власти.
• Звучит скепсис: регулировать уже поздно, компании преследуют выгоду; «этика» часто служит ширмой или PR, а открытый исходный код и распределение власти рассматриваются как возможная контрмера.
• Есть разногласия о влиянии «сафегардов»: одни опасаются, что жёсткие ограничения ухудшают способности моделей, другие считают, что безопасность неизбежно замедляет развитие, но без неё растут системные риски.

Американская экономика раскололась: бурный ИИ-сектор и вялая потребительская часть.

• В статистике: траты на ИИ в прошлом квартале росли быстрее потребительских расходов; без ИИ рост ВВП был бы слабым.
• В акциях: за два года около 60% прироста рынка дали компании, связанные с ИИ (Microsoft, Nvidia, Meta); без этого бумa доходность была бы посредственной.
• В бизнес-данных: по Stripe, «ИИ-компании» лидируют по росту выручки, опережая остальные группы.

Что это за бум и откуда деньги? ИИ — это чипы, серверы и дата-центры, огромная электроэнергия, сети и охлаждение. Это крайне дорого. За полгода Meta, Google, Microsoft и Amazon вложили $100–200 млрд в чипы и инфраструктуру. Крупнейшие техгиганты строят на рекордных скоростях — крупнейший инфраструктурный проект со времен ранней компьютерной эры или даже железнодорожного бума.

JP Morgan отмечает: доля Nvidia в совокупных капзатратах компаний может стать максимальной со времен пиковой выручки IBM в 1969. По расчетам Пола Кедроски, капвложения в ИИ как доля ВВП уже превысили дотком-уровни и приближаются к масштабам «позолоченного века» железных дорог.

Этот всплеск финансируется беспрецедентной прибылью лидеров технологий. Их доля свободного денежного потока — рекордная со Второй мировой. Сильные действующие модели (реклама Meta, поисковая реклама Google и пр.) генерируют «горы» наличности, позволяя ежегодно направлять сотни миллиардов на ИИ-НИОКР и инфраструктуру.

• Участники спорят, действительно ли ИИ «поддерживает» весь рост экономики США или просто концентрирует капитал в руках 10–15 гигантов.
• Многие сравнивают нынешний бум с «железнодорожной лихорадкой» XIX века и дот-комом 1999–2000 годов: возможен и прорыв, и взрыв пузыря.
• Поднимается вопрос: если ИИ так продуктивен, почему прибыли растут у «продавцов лопат» (Nvidia, Microsoft), а не у клиентов из S&P 490.
• Часть комментаторов считает, что без ИИ деньги всё равно бы не пошли в реальную экономику, а осели бы в выкупе акций или «загородных REIT-ах».
• Скептики предупреждают: рекордные capex на дата-центры могут обернуться масштабным спадом, если спрос на ИИ-сервисы замедлится.

• Леонардо — бывший исследователь видеокодирования, ветеран стандартизации и предприниматель.

• Образование: классическая школа (Лицей Салезиан Вальсаличе), инженер-электронщик (Политех Турина, MSc), межкультурный опыт (Токийский университет, PhD по электрическим коммуникациям).

• Христианско-католическое воспитание сформировало убеждение о миссии, выходящей за личные интересы. В начале карьеры, когда цифровые медиа только зрели, видел свою миссию в разработке интероперабельных технологий цифровых медиа — на благо общества и для использования индустрией.

• Нужна была организация, создающая стандарты цифровых медиа, чтобы потребители могли бесшовно общаться, а индустрия работать на глобальном рынке совместимых продуктов и сервисов. Так в 1987 была задумана, а в 1988 создана группа Moving Picture Experts Group (MPEG).

• Через четыре года MPEG запустила цифровую эру: MPEG‑1 для интерактивных медиа (Video CD), цифрового аудио (MP2) и персональной музыки (MP3). С середины 1990‑х MPEG‑2 стал инфраструктурой для цифрового ТВ по кабелю, спутнику, эфирным сетям и на DVD. MPEG‑4 (первый релиз — 1998) открыл путь интернет‑дистрибуции медиа. Далее последовали семейства стандартов: MPEG‑7, MPEG‑21, MPEG‑A, MPEG‑H, MPEG‑I и др.

• Я председательствовал в группе, добившись более 200 стандартов, роста участия в 20 раз (с 29 экспертов) и расширения тематики от медиа к геномике — «рожденным цифровыми» данным мира.

• 2 июня 2020 я закрыл MPEG и ушел, так как «темные силы» перехватили управление. Ещё до этого у MPEG иссяк импульс — технологически и бизнес‑wise.

• Участники обвиняют MPEG в «патентной мафии»: десятилетиями тормозили отрасль патентами на h.264/265, MP3 и др.
• Основатель MPEG Леонардо Чьярильоне жалуется на «тёмные силы», но критики считают это лицемерием: он сам годами защищал FRAND-роялти.
• Пока MPEG задыхалась в лицензиях, открытые кодеки (AV1, даже несмотря на спорные патенты) и перспективные AI-кодеки (DCVC-RT и др.) начали вытеснять старые стандарты.
• Некоторые считают, что разработка кодеков дорога (сотни инженеров и кластеры CPU), но без патентных оков прогресс мог бы быть быстрее.

• В день выхода открытой модели вроде gpt-oss-120b мы сразу ускоряем её для клиентов, как партнёры запуска OpenAI. К концу дня запуска стали лидерами на NVIDIA по латентности и пропускной способности по данным OpenRouter.

• Быстрая оптимизация обеспечена гибким стеком инференса и экспертизой команды; за время написания поста прибавили ещё ~100 ток/с при 100% аптайме.

• Работы включали:

  • Тесты и бенчмарки в TensorRT-LLM, vLLM и SGLang.
  • Совместимость с архитектурами Hopper и Blackwell.
  • Интеграцию с нашим стеком (в т. ч. NVIDIA Dynamo).
  • Оптимизации: маршрутизация с учётом KV-кэша, спекулятивная генерация с Eagle.

Шаг 1: Первый инференс

• Запускаем базовый инференс в любом доступном фреймворке и на нужных GPU/серверных уровнях.
• Параллелим работу: одни пробуют vLLM и SGLang, другие — TensorRT-LLM; быстрее всего взлетел TensorRT-LLM.
• Важно обслуживать модель и на Hopper (H100), и на Blackwell (B200) для широкой доступности и максимальной скорости.
• Гибкость рантайма позволяет быстро переключать инструменты и обновлять матрицу поддержки.

Шаг 2: Исправление багов совместимости

• Новые архитектуры приводят к тонким несовместимостям; GPT OSS добавил, например, Harmony — новый формат ответов.
• Итеративно чиним и валидируем на скорость и корректность; по возможности контрибутим обратно в open source.
• Благодаря сообществу есть несколько отличных путей запуска GPT OSS, проблемы быстро выявляются и чинятся.

Шаг 3: Оптимизация конфигурации

• Хотя GPT OSS 120B можно запустить на одном H100, оптимально масштабировать на 4–8 GPU для лучшей латентности/throughput.
• Рассмотрены два подхода параллелизма для MoE: тензорный и экспертный. Тензорный даёт меньшую задержку, экспертный — выше системную пропускную способность. Мы выбрали тензорный, так как приоритет — латентность.
• Приняли MoE Backend в TensorRT-LLM (поддерживается на Blackwell, не на Hopper), который добавляет более быстрые CUDA-ядра и превосходит предыдущие решения.

• Обсуждение крутится вокруг запуска и производительности GPT-OSS (20B/120B) на разном железе: от MacBook M-серии и RTX 4090/3050 до датацентровых H100/Blackwell и даже CPU.
• Многие отмечают, что скорость хороша при малых контекстах; при >10k токенов начинается существенная деградация скорости и рост задержек, особенно без MCP/веб-доступа.
• TensorRT-LLM часто даёт лучшую латентность/пропускную способность, но сложен в настройке; альтернативы вроде vLLM/SGLang проще, Llama/Оllama позволяют быстро поднять 20B локально и даже распределить по старым GPU.
• Идут споры о “доступности” H100: купить дорого, но аренда широко доступна и выгоднее для нерегулярных нагрузок; при этом Blackwell с FP4 обещает ещё больший буст, в экосистеме Rust добавляют FP8/FP4.
• Пользователи спрашивают про требования к VRAM, практичную локальную агентную разработку на потребительских GPU, и оптимальные настройки на Mac (например, iogpu.wired_limit_mb).
• Обсуждают техники ускорения (спекулятивное декодирование — вызывающее вопросы пользы), причины падения токен/с при длинных диалогах, и различие prefill vs decode по узким местам.
• Наряду с похвалами скорости есть критика: сложность стеков, неточности/галлюцинации ответов, «извиняльный» контент, и вопрос — зачем OpenAI выпускает OSS-модели и как это соотносится с доступностью железа.

Слишком многие сервисы используют такой вход:

• Введите email или телефон
• Сайт отправит 6‑значный код
• Введите код для входа

Пожалуйста, прекратите.

Почему это плохо для безопасности:

• Злоумышленник может отправить ваш email на легитимный сервис и заставить вас ввести присланный код в фишинговой форме. Вы не можете быть уверены, где именно нужно вводить код. Менеджеры паролей тут не помогают.
• Этот метод реально эксплуатируется: вход Microsoft для аккаунтов Minecraft использует такие коды, и уже множество аккаунтов было украдено (есть подтверждения на Reddit и YouTube, а также в документации Microsoft).

• Обсуждение критикует OTP по email (6-значные коды): уязвимость к фишингу через «партнёра-входа», спам-запросы на сброс пароля и навязывание пользователям вместо пароля/менеджеров паролей.
• Многие считают, что email-коды хуже UX: задержки, переключение аккаунтов, блокировки при путешествиях, навязчивая MFA/телефон, а также баги (отписка от рассылок ломает вход).
• Контраргументы: пароли тоже фишингуемы и часто слабые/повторяются; для нетехничных пользователей код/магическая ссылка понятнее.
• Предпочтения и альтернативы: магические ссылки вместо кодов (менее фишингуемы), TOTP, passkeys, соцлогин, менеджеры паролей, иногда даже IP-ограничения; просьбы дать выбор, а не форсить один метод.
• Безопасность email-OTP можно улучшать: сочетать короткий код и длинный одноразовый токен, строгие антифишинговые меры почтовых сервисов, ограничения на частоту запросов.
• Реальные негативные кейсы: принудительные схемы у банков/сервисов, невозможность входа без телефона, постоянные письма о сбросах, статические «коды» у некоторых приложений.
• В целом тренд: сервисы перекладывают риск на почту/Google; часть участников продвигает переход к passkeys и магссылкам как более безопасным и удобным компромиссам.

• Сатира «Правила, по которым большая империя может быть уменьшена до малой» была напечатана в Public Advertiser 11 сентября 1773 года как пара к «Эдикту короля Пруссии». Франклин ценил их краткость, ёмкость и необычную форму, но «Правила» предпочитал за разнообразие и «энергичные концовки абзацев». В одной он предлагал взглянуть на политику метрополии глазами колонистов, в другой — вообразить себя колонистами. Цель — заставить публику по‑новому увидеть американский вопрос накануне парламентских дебатов и дела о Хатчинсоне и Оливере. Оба текста быстро разошлись и многократно переиздавались по обе стороны Атлантики.

• Эффект был двояким: сатира редко убеждает — открытых она развлекает, упорных злит. Франклин понимал риск: желая осветить колониальные жалобы, он мог все усугубить. По его мнению, правительство публично игнорировало нападки, чтобы не раздувать их, но именно они во многом объяснили ярость против него в начале 1774 года.

• Содержание «Правил» не было новым: он уже высказывал те же тезисы в несатирической форме. Конституционных тонкостей Бостона почти не касался — их трудно высмеивать, — но собрал привычные темы: торговые ограничения, новые налоги, давление армии и флота, общеколониальные и массачусетские сюжеты. Сатира придала им остроту, но ненадолго: вскоре власти ударили по нему и, ирония судьбы, воплотили многие «правила» в Коэрцитивных актах 1774 года.

• Для Public Advertiser. «Правила, по которым БОЛЬШАЯ империя уменьшается до МАЛОЙ. [Частно представлены одному недавнему министру при вступлении в должность; публикуются впервые.]»

• Преамбула: древний мудрец гордился, что хоть и не умел играть на скрипке, знал, как сделать из малого города большой. Автор, «современный простак», предлагает обратную науку — полезную министрам, у которых слишком много дел, чтобы «играть на скрипке».

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

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

• Обсуждение крутится вокруг «Правил» Франклина (1773) как сатирического отклика на политику Британской короны; отмечают, что он провёл в Британии 13–15 лет, тщетно пытаясь повлиять на парламент и короля, и вернулся в 1775.
• Несколько участников считают текст предвестником Декларации независимости и примером того, как сарказм поляризует, а не убеждает.
• Обсуждают «элитную слепоту» и повторяющиеся паттерны власти; некоторые видят уроки для современных империй и Pax Americana, другие предостерегают от редукционистских исторических аналогий.
• Уточняют контекст: в Британии были и сторонники умеренности; критика лорда Норта; корректируют хронологию событий до Лексингтона и Конкорда (1775).
• Замечают особенности типографики XVIII века: частая капитализация слов как стилистика/эмфаза, старинное начертание «s» как «ſ».
• В ветке уходит ответвление о «непрерывности» Китая: спорят о циклах объединения/распада, различиях династий и современного государства, приводят контрпримеры (например, Тайпинское восстание).
• Рекомендуют ресурсы: оригинальную верстку на archive.org, музей Франклина в Лондоне, подкаст «The Rest Is History» о Войне за независимость.

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

Инициатива i4is объявила победителей международного конкурса дизайна поколенческого корабля для 250‑летнего перелета к обитаемой планете. Междисциплинарные команды проектировали среду, способную поддерживать и развивать общество при жестких ресурсных ограничениях.

Условия конкурса требовали совместной работы архитекторов, инженеров и социальных ученых над ключевыми аспектами закрытого общества на века, включая:

• Обитаемость для 1 000 ± 500 человек
• Искусственную гравитацию за счет вращения
• Достойные условия жизни и базовые потребности
• Надежные контуры жизнеобеспечения: пища, вода, отходы, атмосфера
• Механизмы передачи знаний и культуры

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

Благодарности жюри

Работы оценивали эксперты из архитектуры, инженерии и социальных наук (Университет Хьюстона; NASA‑JPL; Университет штата Аризона; Университет штата Орегон; Университет Южной Калифорнии).

1 место

Команда: Giacomo Infelise, Veronica Magli, Guido Sbrogio', Nevenka Martinello, Federica Chiara Serpe

Отзыв жюри

Chrysalis выделился системной целостностью и инновационной модульной архитектурой, глубокой проработкой (включая производство в космосе и подготовку экипажа в Антарктике). Модульная оболочка гибка и масштабируема; большой Купол придает выразительность. Сильны планирование строительства корабля и защита от радиации; конструктив реалистичен. Культурный блок можно развить, но концепт убедителен и зрелищен, отсылает к «Раме» и мировым кораблям 1980‑х.

2 место

Команда: Julia Biernacik, Jakub Kot, Aleksandra Wróbel, Jacek Janas, Michał Kucharski, Wiktoria Kuchta, Natalia Łakoma, Katarzyna Śliwa Наставник: д-р хаб. Michał Kracik Факультет промышленного дизайна (студия «Дизайн для экстремальных сред»), Академия изящных искусств в Кракове

Отзыв жюри

WFP Extreme отмечен за общий уровень и акцент на культуре и обществе: одежда, духовные пространства, «такси‑капсула», персонализированная униформа, защита от радиации. Системная целостность и интерьер при искусственной гравитации требуют доработки, но конструктив уместен для орбитальных применений. Балансирует технические амбиции с тонким видением будущей космической жизни.

• Обсуждение крутится вокруг концепции поколенческих звездолётов и конкурса дизайнов: многие впечатлены идеями и визуалами, но сомневаются в реализуемости.
• Критика охватывает социальные аспекты (учёт женщин, психическое здоровье, подростки на борту, эвтаназия как TBD), управляемость общества и этику многовекового эксперимента.
• Технические возражения: неверные расчёты скорости/времени, колоссальные энергетические и финансовые затраты, ненадёжность замкнутых экосистем (пример Biosphere 2), проблемы с воспроизводством без защиты магнитного поля.
• Обсуждают минимально жизнеспособную популяцию и варианты расширения генетического пула (замороженные эмбрионы), а также альтернативы: замороженные экипажи/эмбрионы, нанобот-/фон-Нейман‑зонды, рельсовые ускорители и орбитальные суперструктуры.
• Скептики ссылаются на художественные и научно-популярные примеры (KSR “Aurora”, “Aniara”, Хайнлайн) как иллюстрации «неизвестных неизвестных» и социальной деградации на пути.
• Есть и прагматики: «реальность» как единственный тест — не один «ковчег», а множество разных подходов; сначала нужно решить земные проблемы и освоить замкнутые биосистемы.
• Итоговый тон смешанный: от воодушевления образовательной ценностью и дизайном до убеждённости, что при нынешних технологиях поколенческие корабли — красивая, но несостоятельная фантазия.

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

Google представила Jules — асинхронного ИИ-агента для программирования — для всех пользователей, завершив публичную бету. Агент выполняет задачи в фоновом режиме: пишет и рефакторит код, правит баги, настраивает пайплайны и документирует изменения, не требуя постоянного участия разработчика. Это помогает параллелить работу, ускорять итерации и снижать контекстные переключения.

Jules интегрируется с инструментами разработчиков, может брать на себя длинные задачи, делить их на шаги, сообщать о прогрессе и запрашивать уточнения только при необходимости. Доступен через Google Labs и ориентирован на повышение продуктивности как отдельных инженеров, так и команд, позволяя запускать больше экспериментальных веток и быстрее проводить ревью.

• Пользователи жалуются на запутанные подписки Google: разные продукты (Jules, Gemini App/CLI, Code Assist) разбросаны между Workspace и GCP, цены и доступ скрыты или требуют согласий и биллинга.
• Опыт с Jules противоречивый: часть считает его слабее Claude Code, Copilot/Claude Sonnet и Gemini CLI (низкое качество кода, проблемы в монорепо, зацикливание, отсутствие кнопки STOP, баги UI), другие довольны асинхронным форматом и считают удобным для пачек задач, тестов и сайд‑проектов.
• Замечены регрессии: лимит задач на бесплатном плане снизили с 60 до 15; качество, по словам некоторых, упало после увеличения дневных лимитов на раннем превью.
• Пользователи хотят интеграции с GitHub (issues, комментирование PR для фидбэка), явного просмотра публичных улучшений кода и лучшей связности с Gemini CLI/Actions.
• Есть путаница в позиционировании: что такое «асинхронный кодовый агент», чем Jules отличается от Gemini CLI и с кем он конкурирует (Claude Code, Codex, Crush).
• Критика брендинга/UX: «детский» лендинг, слабый контраст, плохой пиксель‑арт; общее ощущение, что UI отстает от возможностей модели.
• Итоговое восприятие: интерес к формату асинхронных агентов есть, но текущая реализация Jules часто уступает Claude Code по скорости/качеству и стабильности; пользователи просят прозрачные тарифы и единый продуктовый опыт.