Hacker News Digest

Oracle запрещает использовать ИИ‑сгенерированный код в OpenJDK, опасаясь угроз безопасности, конфиденциальности и нарушения прав на интеллектуальную собственность. Разработчики могут применять модели в личных целях — для отладки и ревью, но подавать такие фрагменты в репозитории, pull‑request’ах или иных каналах проекта нельзя. При этом внутри компании практики противоречат этой позиции: соучредитель Ларри Эллисон заявлял, что ИИ‑модели уже пишут код Oracle, а со‑CEO Майк Силлиcia отмечал рост эффективности за счёт сокращения штатов. Компания планирует потратить $70 млрд на расширение дата‑центров, что привело S&P к понижению рейтинга до BBB‑.

Ключевые цифры: $70 млрд инвестиций в инфраструктуру, рейтинг S&P = BBB‑ (на один шаг выше «мусорного»), запрет на ИИ‑код в OpenJDK. Яркие факты: внутреннее противоречие политики, когда внешне Oracle заявляет, что «не пишет» код, а внутри использует ИИ‑генерацию; одновременно компания активно инвестирует в ИИ‑инфраструктуру.

Тред обсуждает риски использования ИИ-генерированного кода в OpenJDK — проблемы авторства, безопасности и ответственности. Разработчики считают, что Oracle запрещает такой код, чтобы избежать юридических рисков. Некоторые считают запрет чрезмерным и предлагают вместо полного запрета ввести контрольные меры. Все согласны: ИИ-код следует использовать с осторожностью и обязательно проверять на безопасность и авторство.

Крупнейшие американские технологические компании — Alphabet, Microsoft, Amazon, Meta и Oracle — скрывают около 1,65 трлн долларов долга за пределами балансов, вдвое превышая официально заявленные обязательства. Meta одна несёт около 420 млрд долларов скрытого долга, используя специальные финансовые структуры — дочерние компании, не отражающиеся в отчётах. Такой приём напоминает схемы Enron, чьё банкротство в 2001 году стало следствием аналогичного скрытия долгов.

Эксперты предупреждают, что подобная бухгалтерия — не просто тренд, а признак хрупкости: компании строят гигантские дата-центры на заемные средства, а их прибыли не успевают за инвестициями. Рост долга сопровождается выпуском новых акций, что размывает капитал и подрывает доверие инвесторов. Если спрос на ИИ не оправдает ожиданий, а дата-центры окажутся недоиспользуемыми, финансовая система может рухнуть. Ближайшие отчёты о прибыли за второй квартал станут ключевым тестом: покажут, насколько реальны заявления о «бесконечном росте» или это просто иллюзия, поддерживаемая сложной бухгалтерией.

Тред обсуждает риск скрытого долга крупных технологических компаний: он может искажать оценку активов и провоцировать финансовый крах. Участники расходятся во мнениях — одни считают долг допустимым, так как компании способны его погасить, другие видят в нём угрозу стабильности. Все согласны, что скрытый долг опасен. Рекомендуется осторожно инвестировать в такие компании и внимательно анализировать финансовые отчеты.

Kimi K3 открывает новый уровень конкурентоспособности с закрытой моделью Fable, позволяя сочетать её качество с низкой стоимостью. При тестировании на ~1000 агентных задач совместное использование моделей дало 93 % точности и экономию до ~50 раз по сравнению с использованием только Fable. Оценка охватывала пять семей задач — SWE, Terminal, Algorithmic, Multi‑Language и Legal — и показала, что K3 дешевле во всех категориях, а её точность сопоставима с Fable в среднем, но превосходит её в терминальных и юридических сценариях.

Oracle routing показал, что K3 выбирается для 72‑96 % задач, что указывает на возможность построения почти идеального роутера, хотя для этого нужны большие массивы данных. Графики стоимости‑качества покажут, что K3 находится левее Fable во всех пяти семейах, а различия в специализациях (символьные математические задачи у K3, визуализация и веб‑работа у Fable) позволяют распределять нагрузку так, чтобы получать высшее качество по минимальной цене. Таким образом, открытый дешёвый модель становится базовым, а роутер — ключевым элементом стратегии.

Эффективность K3 + Fable зависит от роутера, который часто неоптимизирован для реальных нагрузок, а экономия токенов может быть иллюзорной: K3 тратит в 3 раза больше токенов на задачу, чем Fable, так что низкая цена за токен теряет смысл при высоком общем расходе. Роутеры могут быть переобучены на тестовых наборах, а не на реальных задачах, что делает результаты необобщаемыми. Использование роутера для переключения моделей внутри задачи не масштабируемо и неэффективно для индивидуальных пользователей. Провайдеры могут произвольно снижать ресурсы инференса K3, делая поведение непредсказуемым. Бенчмарки на arena.ai показывают, что K3 уступает Fable в большинстве категорий, кроме веб-разработки, что ставит под сомнение его статус SoTA. Для индивидуальных пользователей лучше выбрать одну стабильную модель — кэширование и предсказуемость важнее экономии на токенах. Роутеры следует переобучать на собственных рабочих нагрузках, а не на общих тестах. K3 действительно превосходит Fable в задачах с кодом, особенно при анализе больших фрагментов и понимании структуры проекта, где другие модели ошибаются или переизобретают существующее. В Китае K3 и GLM 5.2 стали основным выбором для разработчиков из-за блокировки Fable — это необходимость, а не альтернатива. Открытость китайских моделей без кибербезопасностных ограничений привлекает пользователей, уставших от цензуры западных решений. Утверждения о 50-кратной экономии преувеличены — они основаны на идеальном, несуществующем роутере, требующем постоянного переобучения. Провайдеры, такие как Fireworks, заинтересованы в продвижении K3, так как хостинг открытых моделей прибыльнее, чем закрытых, что создаёт конфликт интересов. K3 и DeepSeek уже используются в продакшене для Rust, Terraform и PostgreSQL, демонстрируя стабильную производительность в локальной инфраструктуре через Bifrost. Для тех, кто хочет использовать роутер, OpenRouter поддерживает динамическое переключение между K3 и Fable.

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

Meta, например, скрытый долг составляет около 420 млрд долларов — почти в три раза больше её открытого долга, а Oracle и другие крупные игроки используют схожие практики, удерживая миллиарды долларов обязательств в оф‑балансных структурах. Эти данные показывают, что суммарный скрытый долг всех компаний уже превышает их открытый долг, создавая новые риски для инвесторов, которые не могут полноценно оценить финансовое положение компаний, участвующих в ИИ‑проектах. Исследование подчёркивает, что без прозрачного раскрытия такой задолженности оценка риска становится крайне сложной, а потенциальные финансовые шоки могут оказаться скрытыми до момента их возникновения.

Тред связывает скрытый долг технологических компаний с использованием SPV и частным кредитованием, отмечая, что SPV, владеющие дата-центрами, несут долговой риск, а не сами компании. @sajithdilshan возражает, что банки не могут игнорировать риски при выдаче кредитов. Эксперты @harry8 и @m101 подчеркивают, что экономически нет разницы между заимствованием под актив и долгосрочной аренда — схема используется для сокрытия долга. @Terr_ предупреждает, что спекуляции на крахе AI-баббла рискованны: рынок может оставаться иррациональным долго.

Traefik отмечает десятилетие развития как облачного прокси-приложения с открытым исходным кодом. За эти годы проект вырос из простого инструмента маршрутизации в полноценную платформу, включающую Traefik Proxy, Traefik Hub API Gateway и решения для управления API. Сообщество сыграло ключевую роль в его эволюции, способствуя появлению функций для Kubernetes, Docker Swarm, веб-приложений и даже шлюзов для ИИ.

Платформа теперь предлагает решения для безопасности, такие как WAF, управление политиками API и интеграции с экосистемами вроде HashiCorp, Microsoft и Oracle. Traefik продолжает адаптироваться к современным потребностям, включая поддержку GitOps и мокирование API, демонстрируя гибкость и устойчивость в быстро меняющейся ИТ-среде.

• Пользователи отмечают сложность настройки и неудовлетворительную документацию Traefik, особенно при нестандартных требованиях.
• Многие предпочитают альтернативы, такие как Caddy, за его простоту и автоматизацию TLS, или Envoy как CNCF-стандарт.
• Traefik хвалят за интеграцию с Docker и автоматическое управление сертификатами, но критикуют за закрытие базовых функций в enterprise-версии.
• Поддержка динамической конфигурации через Docker-лейблы считается сильной стороной, но сам формат конфигурации часто называют запутанным.
• Проект признают зрелым и полезным для конкретных сценариев, но выбор инструмента часто зависит от личных предпочтений и задач.

Deno подала официальную петицию в Ведомство по патентам и товарным знакам США, чтобы оспорить товарный знак Oracle на слово «JavaScript». После сбора более 27 тысяч подписей под открытым письмом проект перешёл к ключевой стадии discovery, требующей серьёзных ресурсов. Цель — доказать, что термин стал общедоступным обозначением языка, а не брендом Oracle, и освободить его для использования разработчиками, конференциями и авторами без юридических рисков.

Для усиления позиции Deno запустила кампанию по сбору $200 тыс. на экспертные опросы, показания свидетелей из индустрии и академической среды, а также юридические расходы. Oracle уже официально отвергла аргументы о generic-статусе термина. Успех дела важен не только для JavaScript, но и для принципов товарного права: победа корпорации создаст прецедент присвоения общеупотребимых понятий.

• Критика сбора средств VC-финансируемой компанией Deno для суда с Oracle из-за товарного знака "JavaScript"
• Сомнения в успехе и целесообразности дела против Oracle с её огромными ресурсами и возможными негативными последствиями для сообщества
• Предложения альтернативных решений: переход на использование названий "JS", "ECMAScript" или "TypeScript"
• Восприятие инициативы как PR-хода или маркетингового хода, а не искреннего общественного служения
• Поддержка цели освобождения названия, но с оговорками относительно мотивов и методов Deno

Почему появился Apache Kafka
LinkedIn, 2012 г.

Проблема интеграции
LinkedIn нужно было передавать данные активности (лайки, просмотры, публикации) в десятки систем: антифрод, ML-модели, веб-функции, витрины, Hadoop. Эти потоки — критичная инфраструктура, а не просто аналитика.

Старые трубы

• Пакетный конвейер: приложения писали XML на HTTP-сервер; раз в час файлы собирались, парсились и грузились в Oracle + Hadoop.
• Realtime-конвейер: метрики и логи уходили в Zenoss, но туда нельзя было добавить новые данные без ручной работы, а данные были изолированы.

Общие боли

• ручное сопровождение и добавление источников;
• постоянные бэклоги;
• point-to-point архитектура без обмена между системами.

Вывод
LinkedIn понял, что нужен один надёжный, масштабируемый и универсальный «шина событий», куда пишут все, а читают кто угодно. Так родился Kafka.

• LinkedIn отказался от Kafka и создал собственную систему Northguard из-за невозможности масштабировать 32 трлн записей/день, 17 ПБ/день и 400 тыс. топиков.
• Участники спорят: Kafka мощна для «огненных шлангов» данных и многократного потребления, но требует экспертизы и ресурсов; для большинства задач достаточно Redis, NATS, RabbitMQ.
• Названа главная фишка Kafka — возможность переигрывать сообщения и строить разные консьюмеры поверх одного лога.
• Сравнивают NATS (Jetstream) и Apache Pulsar как более лёгкие альтернативы; Redpanda тоже упоминается.
• Мнения разделились: кто-то считает Kafka переоценённой и «бюрократичной», кто-то — незаменимой для больших данных.