Судя по всему, произошло довольно громкое событие: правительство США фактически запретило доступ к самым мощным моделям Anthropic — Claude Fable 5 и Claude Mythos 5 — для иностранных граждан. В ответ Anthropic временно отключила доступ к этим моделям вообще для всех пользователей, чтобы не нарушить экспортные ограничения.
Если коротко по хронологии:
Если вы в последнее время заглядывали в техно-Twitter, то наверняка видели, как люди обсуждают «Ralph Wiggum» так, будто это чит-код. Мемный нейминг делу не помогает, но идея вполне реальна: это официальный плагин для Claude Code, который превращает одиночный промпт в устойчивый цикл. Агент продолжает работать, исправляя собственные ошибки, пока действительно не дойдёт до финишной черты, которую вы задали.
В этом материале объясняется, что это за плагин, как он работает на пальцах, почему он привлекает столько внимания и как безопасно применять его в реальной работе — от рефакторинга легаси до покрытия тестами и greenfield-приложений.
Говорят, всё началось довольно скучно.
Сначала искусственный интеллект научился писать код. Потом научился писать его лучше большинства людей. А потом выяснилась вещь, которую отрасль почему-то проглядела на десятилетия вперёд: самый дорогой ресурс в open source — вовсе не разработка. Не ревью. И даже не CI, пожирающий бюджеты дата-центров. Самым дорогим оказалось то, на что никогда не хватало людей.
Поддержка.
Ответить на issue. Разобраться с чужим, наспех собранным pull request’ом. Обновить зависимость, из-за которой по ночам не спят сразу три континента. Переписать документацию, которую никто не любит писать и все ненавидят читать. Проверить, что новый релиз библиотеки не сломал совместимость у тех, кто поставил её ещё шесть лет назад и с тех пор ни разу не открывал.
Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются (первая — informer и кэш в controller-runtime) и записываются (вторая — Server-Side Apply, patch’и, managedFields). Сегодня — про их жизненный цикл.
Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один.
Привет. В прошлой статье мы в основном говорили про чтение — кэш в controller-runtime, informer’ы, Reflector, DeltaFIFO, почему r.Get в реконсайле не ходит в apiserver. Сегодня поговорим больше про запись.
Kubernetes по своей природе спроектирован так, что одним и тем же объектом могут управлять разные контроллеры — и это нормально. На один Deployment смотрят и deployment-controller (правит status), и HPA (правит spec.replicas), и admission-мутаторы (расставляют labels), и cert-manager (дописывает свои аннотации), и пользователь с kubectl apply. Каждый из них отвечает за свои поля и не лезет в чужие. И всё это работает.
Kubernetes давно стал повсеместной платформой, а написать к нему собственный оператор сегодня — задача нескольких часов. Стандартный путь — kubebuilder на основе controller-runtime: scaffold проекта, типы, реконсайлер. В типовых сценариях этого вполне достаточно. Но как только нагрузка растёт или поведение оператора начинает расходиться с ожиданиями, всплывает целый класс edge-кейсов, причина которых — непонимание того, как controller-runtime устроен внутри. Если вы пишете контроллеры для Kubernetes, этот материал поможет собрать целостную mental model и заранее избежать дорогих сюрпризов в проде.
Привет, Хабр! Мы — команда Cozystack, open-source платформы для построения облаков на своём железе. Хотим рассказать, почему мы решили целиться в направление игровых серверов и что из этого вышло.
