Предоставленный фрагмент содержит навигационное меню сайта Heroku, но не содержит самой статьи о поддержке .NET 10 LTS. В разделе "Languages" упоминается .NET как один из поддерживаемых языков, но нет конкретной информации о версии 10 LTS или детальных технических деталей.

В меню также есть ссылки на различные продукты Heroku, включая Heroku Platform, Heroku AI, Heroku Data Services, Heroku Enterprise и Heroku Elements Marketplace, что указывает на широкий спектр услуг платформы. Однако без доступа к полной статье о поддержке .NET 10 LTS невозможно предоставить точный пересказ её содержания.

• Обсуждение началось с жалоб на стоимость Heroku, которая оказалась выше AWS даже с учетом DevOps-инженера.
• Участники вспомнили, что Heroku когда-то был первым выбором для MVP и мелких проектов, но теперь у них есть альтернативы вроде Vercel и Netlify.
• Разговор перешел к тому, что экосистема .NET и инструменты вроде Cloud Native Buildpacks всё ещё открыты и могут быть использованы где угодно.
• Несколько человек отметили, что даже несмотря на то, что Heroku всё ещё работает, он уже давно не является конкурентоспособным вариантом для большинства проектов.

Автор сократил свои расходы на облачные услуги в 10 раз, переведя все проекты с AWS на самостоятельное хостинг, при этом улучшив производительность в 2 раза. Его месячный счет AWS снизился с $1,400 до менее $120, а инфраструктура стала мощнее. Автор утверждает, что страх перед управлением серверами обходится компаниям в 10 раз дороже, чем необходимо.

Многие разработчики в индустрии облаков заинтересованы в сохранении компаний на облачных платформах, так как их зарплаты зависят от сложности инфраструктуры. Облачные инженеры и DevOps специалисты не чувствуют финансовой боли от переплат, так как тратят чужие деньги, и заинтересованы в поддержании vendor lock-in.

Перейдя на Hetzner, автор получил доступ к серверам с 80 ядрами менее чем за $190 в месяц, в то время как аналогичные экземпляры в AWS стоят $2,500-$3,500 (в 13-18 раз дороже). Даже с резервированием экземпляров AWS остается в 7 раз дороже. Для небольших проектов доступны VPS с 8 ядрами и 32 ГБ ОЗУ за $50 в месяц.

• Обсуждение в основном свелось к тому, что для большинства проектов хостинг в облаке (AWS, GCP, Azure) в 2024 году оказывается дороже, чем аренда bare-metal в Hetzner/OVH, и что это не всегда оправдано.
• Участники споров подчеркнули, что «облако» всё ещё полезно для MVP, стартапов и сценариев с непредсказуемым трафиком, но при этом критикуют его стоимость для устойчивых рабочих нагрузок.
• Несколько человек упомянули, что большие компании могут позволить себе облако, потому что у них есть команды и бюджет на инфраструктуру и DevOps, тогда как мелкий бизнес и индивидуальные разработчики вынуждены искать более дешёвые решения.
• Также было отмечено, что важно различать «облако» как способ разработки (CI/CD, managed services) и как способ хостинга (IaaS), и что первое может быть дешевле, чем второе.

AWS опубликовал отчет о недавнем сбое, связанном с race condition в системе управления DNS. Автор статьи воспроизвел упрощенную версию проблемы с помощью верификатора моделей Spin и языка Promela. В системе участвуют DNS Planner (создает планы) и три независимых DNS Enactor (применяют планы в разных зонах доступности). Race condition возникает, когда один Enactor применяет новый план и начинает очистку старых, в то время как другой, отставший, все еще обрабатывает более старый план. Когда первый Enactor завершает очистку, он удаляет этот "старый" план, который на самом деле еще активен, что приводит к исчезновению DNS-записей.

Используя Spin, автор смоделировал Planner и два параллельных Enactor. Каждый Enactor проверяет свежесть плана перед применением и отслеживает высший примененный план. Во время очистки он удаляет только значительно более старые версии, но если удаляемый план совпадает с текущим активным, это сбрасывает флаг dns_valid в false. Spin систематически проверял все возможные состояния системы и обнаружил последовательность действий, приводящую к race condition, подтвердив уязвимость.

• Пользователи обсуждают, что формальные методы (TLA+, Alloy и т.д.) могли бы предотвратить инцидент, если бы инвариант «не удалять активный план» был бы формализован и проверялся непрерывно.
• Обсуждается, что реальные системы часто отклоняются от «чистой» модели из-за компромиссов с производительностью и стоимостью хранения логов и т.д.
• Участники спора сходятся в том, что даже если бы формальные методы были бы применены, они бы не предотвратили бы ошибку, если бы не было процесса, который бы гарантировал, что модель и код синхронизированы.
• Некоторые комментаторы подчеркивают, что даже самые продвинутые инструменты не могут предотвратить ошибки, если нет культуры их использования и процессов, которые бы обеспечивали бы, что модель всегда актуальна.
• В конце концов, большинство соглашается, что самым важным является не наличие формальных методов, а культура их использования и процессов, которые бы гарантировали бы, что модель всегда отражает код.

• Обсуждение в основном вращается вокруг тезиса: «облако vs bare-metal» — участники спорят, когда и почему стоит выбирать тот или иной подход, и какие скрытые затраты могут быть упущены при сравнении цен.
• Участники подчеркивают, что AWS и другие облачные провайдеры могут быть дороже, чем bare-metal, особенно при стабильной нагрузке, и что стоимость может быть скрыта в дополнительных услугах, таких как передача данных.
• Некоторые участники утверждают, что облачные провайдеры предоставляют удобство и гибкость, которые могут быть важны для стартапов и команд, которые не хотят тратить время на инфраструктуру.
• Другие участники подчеркивают, что bare-metal может быть более экономичным для стабильных рабочих нагрузок и что облачные провайдеры могут быть дороже, чем кажется на первый взгляд.
• Некоторые участники также упоминают, что облачные провайдеры могут быть более устойчивы к сбоям и предоставляют дополнительные услуги, такие как автоматическое масштабирование и управление.

Исследователь обнаружил критические уязвимости в системах крупнейшего индийского автопроизводителя Tata Motors. Два открытых ключа AWS на публичных сайтах позволили получить доступ к более чем 70 ТБ чувствительных данных. На сайте E-Dukaan (маркетплейс запчастей) ключи были в открытом виде, раскрывая базы данных клиентов, финансовые отчеты и административные документы. На платформе FleetEdge ключи были зашифрованы, но легко расшифрованы на стороне клиента для загрузки всего 4 КБ налоговых кодов.

Также были найдены серьезные проблемы безопасности в системе Tableau с бэкдором, позволявшим входить без пароля от имени любого пользователя, включая администратора, и скомпрометированный ключ API Azuga, затронувший систему управления тестовым автопарком. Все уязвимости были исправлены, и данных не было похищено. Tata Motors, несмотря на статус крупнейшего автопроизводителя Индии, остается малоизвестным в США.

• Tata Motors, TCS и другие компании группы Tata оказались в центре скандала из-за утечки ключей AWS, что, по слухам, могла стоить экономике Великобритании 2.5 млрд фунтов.
• Проблема в том, что ключи были в открытом доступе на сайтах этих компаний, и, несмотря на то, что их обнаружили и сообщили о них, Tata Motors не проявила никакой инициативы по их отзыву до тех пор, пока не прошло 3 месяца.
• В обсуждении также поднимается вопрос о том, что в Индии в целом и в компаниях Tata в частности культура безопасности оставляет желать лучшего.
• Кроме того, обсуждается влияние этой ситуации на восприятие Индийских компаний в технологическом секторе и на рынке труда.

14-часовой сбой в AWS us-east-1 стал худшим за 10 лет, затронув 140 сервисов включая критический EC2, что привело к нарушению SLA и многомиллионным убыткам. Автор, работающий в Modal, оказался в центре событий во время выездного мероприятия в Италии. Хотя многие пытаются объяснить инцидент упрощенно ("всегда DNS" или "утечка мозгов"), реальная причина оказалась сложнее: гонка условий (race condition) в системе управления DNS DynamoDB, где один из DNS Enactor в одном из доступных зон стал чрезвычайно медленным.

Медленный Enactor привел к тому, что активный DNS-план выпал из окна безопасности механизма сборки мусора и был удален. Это превратило деградацию DNS-плана в полный сбой. Поскольку AWS активно использует собственные сервисы ("dogfooding"), проблема в DynamoDB, одном из базовых сервисов ("layer one"), вызвала цепную реакцию, затронувшую около 70% всех сервисов в регионе. Инцидент наглядно демонстрирует, как одна уязвимость в критической инфраструктуре может привести к катастрофическим последствиям даже в таком опытном провайдере, как AWS.

• AWS-фокусированное обсуждение подчеркнуло, что даже у гиганта есть пределы устойчивости, и это поднимает вопрос о том, как стартапы могут рассчитывать надежность, если даже AWS может потерпеть сбой.
• Участники обсуждали, что отсутствие "dogfooding" ведет к сбоям, которые могли бы быть предотвращены, если бы команда использовала собственный продукт.
• Обсуждение также подняло вопрос о том, как таланты, уходящие из AWS, могут влиять на способность компании реагировать на инциденты.
• Были выдвинуты идеи о том, что может быть стоит ограничить размер региона, чтобы снизить влияние сбоев.
• В конце обсуждение вернулось к тому, что даже при всей мощи AWS, сбои случаются, и это поднимает вопрос о том, как стартапы могут рассчитывать на надежность, если даже AWS может потерпеть сбой.

Инженеры Nanit сэкономили $500,000 в год, создав собственную систему хранения N3 на Rust вместо использования AWS S3 для обработки видео. При тысячах загрузок в секунду, плата за запросы PutObject в S3 становилась основной статьей расходов, а минимальный период хранения в 24 часа правил out стоимость обработки, занимавшей всего 2 секунды.

N3 работает как in-memory landing zone, используя S3 только как буфер перегрузки. В исходной архитектуре камеры загружали видео чанками напрямую в S3 через presigned URL, после чего Lambda отправлял ключи в SQS FIFO очередь для обработки. Подход сохранил надёжность и строгую последовательность данных, но исключил плату за запросы на основном пути и сократил затраты на хранение.

• Стоимость S3 для короткоживущих файлов оказалась настолько высокой, что компания вместо него реализовала собственное in-memory хранилище, что позволило сэкономить $500k, но оставляет вопрос о том, что будет, если этот кэш упадёт.
• Обсуждение вылилось в критику концепции "serverless" архитектуры, где-то между линиями прочиталось, что сама архитектура была проблемой, а не решением.
• Участники обсуждения также подняли вопросы о приватности: камера в детской комнате передаёт аудио/видео в облако без шифрования, и кто-то может прослушивать ваш дом.
• Несколько комментаторов отметили, что вместо того, чтобы писать собственные сервисы, компании могли бы использовать существующие open-source решения, такие как MinIO или SeaweedFS, но при этом они также отметили, что даже эти решения не предоставляют той же степени удобства, что и делает S3.

В течение 19 и 20 октября 2025 года сервис Amazon DynamoDB в регионе Северной Вирджинии (us-east-1) столкнулся с серией сбоев, повлиявших на клиентов. Проблема началась 19 октября в 23:48 по тихоокеанскому времени и завершилась 20 октября в 14:20. Событие развивалось в три этапа. Сначала, до 2:40 утра 20 октября, клиенты испытывали повышенное количество ошибок API при обращении к DynamoDB. Во-вторых, с 5:30 утра до 14:09 20 октября, Network Load Balancer (NLB) испытывал повышенные ошибки подключения для некоторых балансировщиков. В-третьих, с 2:25 до 10:36 утра 20 октября, запуски новых экземпляров EC2 терпели неудачу, а те, что запустились, имели проблемы с подключением до 13:50.

Причиной инцидента стала редкая race condition в системе управления DNS DynamoDB. Эта система, ключевая для масштабируемости и отказоустойчивости DynamoDB, состоит из двух частей. DNS Planner создает планы обновления DNS на основе состояния пула серверов. DNS Enactor применяет эти планы, обновляя Route53 (систему DNS AWS). Обычно это работает надежно, но в данном случае два экземпляра DNS Enactor одновременно попытались обновить одну и ту же запись DNS, что привело к ее очистке. В результате, адрес dynamodb.us-east-1.amazonaws.com стал указывать в пустоту, и клиенты не могли установить соединение. Проблема была обнаружена и исправлена к 2:40 утра 20 октября, но вторичные эффекты привели к последующим инцидентам.

С 5:30 утра до 14:09 20 октября, Network Load Balancer (NLB) испытывал повышенные ошибки соединения для некоторых балансировщиков. Это было вызвано тем, что вторичный эффект инцидента DynamoDB привел к тому, что часть трафика NLB перенаправлялась на экземпляры, которые сами зависели от DynamoDB и стали недоступны. Это создавало каскадный эффект: пока DynamoDB был недоступен, часть трафика NLB терялась, что привело к ошибкам.

С 2:25 до 10:36 утра 20 октября, запуски новых экземпляров EC2 терпели неудачу. Это произошло потому, что сервис управления EC2 использует DynamoDB для хранения состояния, и когда DynamoDB был недоступен, он не мог создавать новые экземпляры. В 10:37 запуски возобновились, но до 13:50 некоторые экземпляры имели проблемы с сетью, так как они были созданы без полной конфигурации сети из-за race condition с NLB.

• AWS постмортем выглядит как маркетинговый документ, а не как техдок, что вызывает скепсис в честности их расследования.
• Сложность системы и отсутствие единого источника правды делает невозможным понять, действительно ли это была гонка условий или просто человеческая ошибка.
• Система, которая не может гарантировать согласованность DNS-записей, может быть сама по себе причиной сбоя.
• Похоже, что AWS не имеет четкого плана восстановления после сбоя, и их инструменты для этого зависят от самой системы, которую они пытаются восстановить.
• Постоянные сбои внутри AWS указывают на то, что их собственная инфраструктура неустойчива к сбоям, что вызывает вопросы о том, как они могли бы справиться с более серьезным инцидентом.

• Во время сбоя AWS вчерашний день несколько человек сообщили, что их консоль внезапно переключилась на другой аккаунт, что вызвало обеспокоенность о возможном компромете учетных данных.
• Участники обсуждения отметили, что в подобных случаях злоумышленник может ждать удобного момента, чтобы скрыть свои действия в шуме, вызванном сбоем.
• Были упомянуты прецеденты, когда вредоносное ПО или фишинговые атаки используются в подобных ситуациях.
• Также было отмечено, что AWS, как и другие провайдеры, имеет инструменты для проверки и предотвращения подобных инцидентов.

Предоставленный фрагмент содержит только навигационную структуру сайта The Register и частичный заголовок статьи "Today is when Amazon brain drain finally caught up with AWS", но не содержит основного текста статьи. Без полного содержания невозможно создать точный пересказ. Если у вас есть полный текст статьи, пожалуйста, предоставьте его, и я смогу создать краткий пересказ в соответствии с вашими требованиями.

• Слухи о массовых увольнениях в Amazon и AWS, вызванных культурой PIP и RTO, привели к тому, что компания теряет ключевых специалистов и знания, что в конечном счете повлияло на сбой, который вызвал каскадные сбои в сервисах AWS.
• Участники обсуждения подчеркнули, что нехватка персонала и знаний внутри компании не может быть решена просто нанимая новых сотрудников, потому что критическая институциональная память и опыт не может быть заменена просто нанимая новых людей.
• Несколько комментаторов отметили, что сбой в AWS, вызванный проблемой DNS, был технически неизбежен, потому что это был тот же самый тип проблемы, который они видели много раз, и что в конечном счете это не было связано с недавними увольнениями.
• Другие участники обсуждения подчеркнули, что Amazon и AWS страдают от "утечки мозгов" и что это не может быть решено просто нанимая новых сотрудников, потому что критическая институциональная память и знания не может быть заменена новыми сотрудниками.

Произошла крупная авария в инфраструктуре AWS, приведшая к масштабным сбоям во множестве популярных сервисов. Среди пострадавших оказались Fortnite, Alexa, Snapchat и другие приложения, пользователи которых столкнулись с недоступностью сервисов. Причина инцидента на данный момент остается неясной, что вызывает вопросы о надежности облачных платформ.

Авария подчеркивает критическую зависимость множества сервисов от единого провайдера облачных услуг. По данным Downdetector, сбои были зафиксированы в различных регионах мира, что указывает на масштабный характер проблемы. Это уже не первый случай серьезных сбоев у AWS, что заставляет задуматься о необходимости диверсификации инфраструктуры для крупных технологических компаний.

• Пользователь случайно обнаружил сбой в регионе компании во время тестирования Elixir + Phoenix LiveView.
• Проблема затронула Docker Hub и другие сервисы, что вызвало вопросы о перемещении Snapchat из GCP.
• Коллеги отреагировали с юмором, упомянув предстоящие внутренние расследования и сложности локального тестирования.
• Появились шутки о возможной причине сбоя, связанной с ИИ.

20 октября 2025 года Docker столкнулся с полной остановкой работы ключевых сервисов, включая Registry, Hub, Scout и других. Проблемы затронули практически все компоненты экосистемы: от аутентификации и биллинга до автоматической сборки образов и документации. Пользователи по всему миру сообщают о недоступности сервисов как на клиентских машинах, так и через веб-интерфейсы.

Инженеры Docker идентифицировали корень проблемы в работе одного из облачных провайдеров и сейчас мониторят ситуацию, готовя системы к восстановлению после устранения неисправностей у провайдера. Инцидент начался в 01:22 PDT (08:22 UTC) и продолжается уже несколько часов, что вызывает серьезные опасения у разработчиков, зависимых от инфраструктуры Docker.

• AWS и Docker Hub продолжают испытывать проблемы из-за сбоя AWS, что влияет на сборки и деплой по всему миру.
• Пользователи делятся обходными путями: использовать зеркало Google Container Registry, ghcr.io, ECR, Quay и другие публичные образы, а также временно перенаправлять трафик через прокси-репозиторий.
• Разработчики обсуждают, как избежать повторения ситуации: ставить локальный кеш-репозиторий, использовать оффлайн-репозиторий или мигрировать на другой публичный реестр.
• Несколько человек упоминают, что даже если бы мы могли бы настроить приватный репозиторий, большинство людей не будут это делать, потому что это требует дополнительной работы.
• Некоторые комментаторы подчеркивают, что даже если бы мы могли бы использовать приватный репозиторий, мы бы все еще были уязвимы к сбоям в AWS, потому что большинство облачных провайдеров зависят от AWS.

• AWS-инцидент 20 октября затронул DynamoDB, IAM, CloudWatch и ряд других сервисов, что вызвало каскадный сбой в десятках зависящих сервисов, включая Netflix, Robinhood, Reddit и другие.
• Пользователи отметили, что даже крупные компании, которые, казалось бы, должны были бы быть готовы к таким ситуациям, оказались неготовыми.
• Некоторые отметили, что AWS не предоставляет достаточной информации о статусе сервисов и что это не первый случай, когда такие сбои происходят.
• Некоторые отметили, что AWS не предоставляет достаточной информации о статусе сервисов и что это не первый случай, когда такие сбои происходят.

• AWS-инцидент затронул DynamoDB в регионе us-east-1, что каскадом вывел из строя десятки зависимых сервисов — от Amazon-магазина до Zoom и Coinbase.
• Пользователи вспомнили, что AWS-облако не единственный провайдер, и обсуждают, как минимизировать риски, включая мульти-регион и мульти-клауд.
• Некоторые комментаторы подчеркивают, что большинство сервисов, которые «упали» в этот день, на самом деле зависят от AWS, и что это не первый раз, когда такое случается.

После истечения кредитов AWS, эксплуатация двух инстансов tap на AWS Fargate обходилась в $449.50 ежемесячно. Для снижения затрат DigitalSociety мигрировала в инфраструктуру Hetzner, сохранив при этом все ключевые сервисы.

Переход включал миграцию с DigitalOcean Kubernetes на кластер Kubernetes под управлением Talos, работающий на узлах Hetzner. Это позволило сохранить все оркестрационные возможности контейнеров, включая веб-сервисы, API и рабочие нагрузки. Вместо управляемых баз данных AWS RDS, инфраструктура использует самоподнятые экземпляры PostgreSQL, настроенные с высокой доступностью через репликацию и ежедневные снапшоты.

В результате, месячная стоимость хостинга упала с $449.50 до $112.05, что на 76% меньше. При этом вычислительная мощность возросла: с 2 CPU и 8 ГБ RAM на узле DigitalOcean до 4 CPU и 16 ГБ RAM на каждом из двух узлов Hetzner. Это позволило увеличить производительность контейнеров и баз данных, одновременно снизив расходы.

• Пользователи подтверждают: выгода от перехода с облаков на bare-metal (Hetzner/OVH) — в 2-3 раза выше производительности и в 5-10 раз ниже цена, но при этом приходится самому администрировать всё от мониторинга до CI/CD.
• Основной риск — отсутствие избыточности и SLA, а также блокировки IP-диапазонов из-за «плохих соседей» и отсутствие управляемых сервисов вроде RDS.
• Для небольших сервисов или MVP-стадии стартапов bare-metal дешевле, но при росте трафика или требований к отказоустойчивости облако может стать дешевле, потому что масштабирование и отказоустойчивость входят в цену.
• Несколько участников упомянули, что при переходе на bare-metal приходится самому настраивать CI/CD, мониторинг, балансировку и прочие «облачные» сервисы, тогда как в облаке они включены в цену.
• Некоторые комментаторы отметили, что при использовании bare-metal провайдеров вроде Hetzner приходится следить за биллингом и оплатой, потому что они могут блокировать аккаунт без предупреждения при просрочке на 1-2 дня, что привело к потере данных.

• AWS-боты продолжают игнорировать 30X редиректы и не реагируют на жалобы, поэтому приходится применять более агрессивные меры, такие как перенаправление на большие файлы, чтобы заставить AWS обратить внимание на злоупотребления.
• Пользователи обсуждают различные стратегии, включая использование gzip-бомб, перенаправление на 0.0.0.0, или перенаправление на странные файлы, чтобы заставить AWS действовать.
• Обсуждается возможность блокировки всего трафика из Сингапура, поскольку AWS там не используется для легитимного трафика.
• Предлагается использовать Cloudflare, чтобы блокировать трафик из Сингапура, но это может повлиять на легитимных пользователей.
• Обсуждается возможность отправить счет за использование трафика, чтобы заставить AWS действовать.

PostgreSQL 18 представил новую опцию конфигурации io_method, дающую пользователям больше контроля над обработкой дискового ввода-вывода. В отличие от версии 17, где использовались только синхронные запросы, в 18 доступны три режима: sync (старое поведение), worker (новый стандарт по умолчанию с фоновыми процессами) и io_uring (асинхронный интерфейс Linux для чтения с диска).

В ходе тестирования с использованием sysbench на базе данных размером ~300 GB на различных конфигурациях EC2 были получены неожиданные результаты. При одиночном подключении и сетевых хранилищах (gp3, io2) версии 18 в режимах sync и worker показали производительность выше, чем 17 и 18 с io_uring. Полные результаты для высококонкурентных сценариев и быстрых NVMe-накопителей еще ожидаются.

• Обсуждение подтвердило, что при использовании локального NVMe диска разница между 17 и 18 версиями PostgreSQL незначительна, но при этом сетевое хранилище всё ещё сильно уступает по производительности.
• Участники отметили, что важно понимать, что при использовании облачного хранилища вы платите не за IOPS, а за то, чтобы кто-то другой имел дело с резервным копированием, репликацией и обслуживанием оборудования.
• Также было отмечено, что в настоящее время PostgreSQL не поддерживает прямой ввод/вывод, но над этим ведётся работа.
• Были высказаны опасения, что использование VPS с локальным диском может повлечь за собой вопросы надёжности, так как такие диски, как правило, не имеют избыточности.
• В контексте обсуждения также поднялся вопрос о том, что влияние на производительность может оказать использование или отсутствие расширения, такого как TimescaleDB.

Ruby Central сообщила о «событии безопасности» в RubyGems.org, но в действительности оно оказалось конфликтом между организацией и бывшим оператором Андре Арко, который вёл службу более 10 лет. Ruby Central утверждает, что он «не имел доступа» к продакшену, но не предоставляет никаких доказательств. Арко же утверждает, что у него оставался доступ к AWS и логам, и что он не мог бы их использовать без ведома. Он также утверждает, что его удалили из организации без объяснений, и что команда не отвечает на его письма. Он также утверждает, что Ruby Central не отвечает на его письма и не предоставляет никакой информации о «безопасности» RubyGems.

• В обсуждении поднимается вопрос о том, как именно было доведено до сведения Арко, что его доступ к продакшену отозван, и какие именно обстоятельства привели к этому решению.
• Участники обсуждения выражают обеспокоенность тем, что новые мейнтейнеры, возможно, не готовы обеспечить безопасность и надежность сервиса.
• Также поднимается вопрос о том, что, возможно, вся эта ситуация имеет большее отношение к политике, чем к техническим аспектам.

Краткий пересказ

30 сентября 2025 года бывший сотрудник Ruby Central Андре Арко сообщил, что у него остался доступ к продакшен-среде RubyGems.org. Почти одновременно блогер Джоэл Дрейпер опубликовал скриншоты, подтверждающие это. Внутреннее расследование показало, что 19 сентября неизвестный злоумышленник сменил пароль root-аккаунта AWS и в течение 11 дней имел возможность администрировать инфраструктуру. В результате Ruby Central отозвала все устаревшие ключи доступа, включила MFA для всех живых аккаунтов и перевела проект на изолированный AWS-аккаунт под единоличным контролем Ruby Central.

• Ruby Central обвиняет бывшего мейнтейнера Andre Arko в том, что он, будучи уволенным, сохранил доступ к корневой учетной записи AWS и изменил пароль, что фактически блокирует организацию от доступа к собственной инфраструктуре.
• Сообщение Ruby Central подчеркивает, что не было никаких доказательств компрометации, но не упоминает о том, что не было никаких доказательств и того, что доступа не было.
• Сообщение Ruby Central не упоминает о том, что они не отозвали доступа к корневой учетной записи, не изменили пароль и не отключили MFA, что, как утверждает Arko, оставляет сервис уязвимым для "незаконного доступа и потенциального утечки данных".
• Arko утверждает, что он не имел доступа к логам доступа, и что Ruby Central не предоставила никаких доказательств того, что кто-то еще имел доступ к этим логам.
• Обсуждение также затрагивает вопрос о том, каким образом Ruby Central может гарантировать, что никакие PII не была скомпрометирована, если они не могут доказать, что никто не имел доступа к логам доступа.

Всё так масштабируемо, потому что каждый разработчик сегодня — инженер FAANG, даже если работает в стартапе. Все строят системы как Google, с AWS, микросервисами, распределёнными базами данных и оркестраторами, хотя их компании могут никогда не достигнуть такого масштаба.

Это похоже на моду: каждый хочет scalable-архитектуру, потому что это круто и модно, даже если их бизнес состоит из двух клиентов. Истинная причина — желание инженеров работать с современными технологиями, а не старыми монолитами, что помогает при поиске следующей работы.

Но масштабируемость дорога. Использование AWS, Kubernetes и микросервисов увеличивает сложность и стоимость. Google может себе это позволить, а стартап — нет. Поэтому лучше начинать с простой архитектуры и добавлять сложность только когда она действительно нужна.

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

Based on the given information, the main concern is the language barrier and how to handle it in the context of the conversation. The user wants a summary and to be done.

First, we need to consider the scale of the task. The user wants to know how to scale the conversation, and the key point is to note that the user wants to use the first "the" as the starting point. Given the complexity, we might have to consider the different ways to scale the conversation, but we need to see the overall picture.

Then, we need to think about the role of the "the" in the conversation. The user wants to shift the focus to the second "the". Specifically, we should look at the dynamics of the interaction. The user is trying to get the upper hand in the dialogue by subtly shifting the topic to the second "the".

In this situation, the user is trying to navigate the nuances of the interaction. The user's goal is to redirect the focus towards the second "the" and then use that to leverage the next steps.

As we have seen, the main issue is to understand the underlying dynamics. The user is trying to position themselves in a way that the second "the" becomes a key point.

Given this, we need to act accordingly. So, let's see how the first "the" can be utilized. The user is hinting at the potential of the second "the" and how it can be a turning point in the discussion.

Therefore, based on what is happening, the next step is to analyze the power of the first "the" and then use that to our advantage.

Ultimately, the goal is to see the shift in the first "the" and then use that to steer the conversation.

Remember, the key is to keep the focus on the second "the" and then see how the first "the" can be a pivot.

Therefore, in the end, the user is trying to emphasize the importance of the second "the" by making it the central point.

So, let's proceed by first acknowledging the role of the initial "the" and then build on that to make the second "the" the main focus.

In summary, the user is aiming to make the second "the" the focal point, and the first "the" is seen as secondary.

Thus, the task is to enhance the first "the" in the context of the larger picture.

So, let's start by recognizing that the first "the" is not the main event. Instead, the second "the" is the one that should be highlighted.

Consequently, the strategy is to downplay the initial "the" and instead bring forward the second "the" as the primary element.

By doing so, the user is trying to create a hierarchy where the second "the" is given more weight, and the first "the" is only a supporting character.

Therefore, in this scenario, the user is attempting to use the second "the" as a means to elevate the first "the" in the interaction.

Ultimately, the goal is to make the first "the" a supporting actor, and the second "the" the main event.

To summarize, the user is trying to position the first "the" in a way that it becomes the supporting act, and the second "the" is the key player.

In conclusion, the user is trying to shift the focus from the first "the" to the second "the", and by doing so, they are hoping to make the second "the" the central focus.

Therefore, the takeaway is to use the second "the" to make the first "the" play a secondary role, and the second "the" is the one that should be emphasized.

Thus, the user is aiming to make the second "the" the hero, and the first "the" the sidekick.

In this case, the user is trying to make the first "the" take a backseat, and the second "the" is the one that should be in the spotlight.

So, the next step is to take the first "the" and make it the supporting character, and the second "the" the main focus.

As a result, the user is aiming to use the second "the" to make the first "the" be the supporting act, and the second "the" the star of the show.

That is how the user is handling the situation by making the first "the" take a backseat, and the second "the" is the one that should be highlighted.

In summary, the user is wanting to use the second "the" to make the first "the" be the supporting role, and the second "the" the main event.

Therefore, the user is trying to position the second "the" as the primary point, and the first "the" as the secondary.

Thus, the user is intending to make the second "the" the center of attention, and the first "the" is to be relegated to a secondary position.

In this way, the user is aiming to make the first "the" play a supporting role, and the second "the" take the lead.

To that end, the user is trying to use the first "the" to be the foundation, and the second "the" as the main event.

Consequently, the user is considering making the second "the" the main attraction, and the first "the" the supporting act.

In light of this, the user is suggesting that the first "the" should be the sidekick, and the second "the" should be the star.

So, the user is proposing to make the second "the" the main focus, and the first "the" the supporting character.

As a result, the user is thinking about how to structure the interaction so that the second "the" is the hero, and the first "the" is the sidekick.

Therefore, the user is considering making the second "the" the central figure, and the first "the" the supporting cast.

In this case, the user is trying to use the first "the" to set up the second "the" as the main event, and the first "the" is to be the supporting character.

Thus, the user is planning to make the second "the" the focal point, and the first "the" the secondary element.

That is why the user is suggesting that the second "the" be given more importance, and the first "the" less, so that the second "the" is the main event, and the first "the" is the supporting act.

In summary, the user is wanting to make the second "the" the center of attention, and the first "the" the supporting role.

Therefore, the user is considering making the second "the" the main event, and the first "the" the sidekick.

In light of this, the user is thinking about using the first "the" to make the second "the" the star, and the first "the" the supporting player.

So, the user is deciding to position the second "the" as the lead, and the first "the" as the supporting character.

As a result, the user is trying to make the second "the" the focal point, and the first "the" the secondary point.

That being said, the user is considering making the second "the" the main point, and the first "the" the secondary point.

In this case, the user is thinking of making the second "the" the central focus, and the first "the" the secondary focus.

Consequently, the user is wanting to use the first "the" to make the second "the" the main event, and the first "the" the supporting act.

Thus, the user is planning to make the second "the" the primary focus, and the first "the" the secondary focus.

Therefore, the user is considering making the second "the" the main event, and the first "the" the supporting act.

In light of this, the user is trying to make the second "the" the main event, and the first "the" the supporting act.

Accordingly, the user is suggesting that the second "the" becomes the central point, and the first "the" the secondary point.

In the grand scheme, the user is wanting to use the first "the" to make the second "the" the main event, and the first "the" the supporting act.

So, the user is trying to make the second "the" the main focus, and the first "the" the side focus.

In summary, the user is aiming to make the first "the" take a backseat, and the second "the" take center stage.

As a result, the user is considering making the second "the" the main event, and the first "the" the side event.

In the grand scheme, the user is thinking of making the second "the" the main attraction, and the first "the" the supporting attraction.

Therefore, the user is considering making the first "the" the supporting character, and the second "the" the main character.

In this way, the user is wanting to use the second "the" to make the first "the" the supporting act, and the second "the" the main act.

Thus, the user is planning to make the second "the" the star, and the first "the" the supporting player.

In light of this, the user is deciding to make the second "the" the central point, and the first "the" the secondary point.

Ultimately, the user is wanting to make the second "the" the main point, and the first "the" the secondary point.

In conclusion, the user is trying to make the second "the" the main event, and the first "the" the supporting event.

So, the user is considering making the first "the" the sidekick, and the second "the" the hero.

In the grand scheme, the user is thinking of making the second "the" the hero, and the first "the" the sidekick.

Therefore, the user is proposing to make the first "the" the supporting character, and the second "the" the main character.

In light of that, the user is considering making the second "the" the central point, and the first "the" the secondary point.

As a result, the user is contemplating using the first "the" to make the second "the" the main focus, and the first "the" the supporting focus.

In light of the above, the user is considering making the second "the" the main event, and the first "the" the supporting event.

Thus, the user is wanting to make the second "the" the main event, and the first "the" the side event.

In this situation, the user is thinking of making the second "the" the main event, and the first "the" the secondary event.

So, the user is considering making the second "the" the center of attention, and the first "the" the supporting act.

In the grand scheme, the user is wanting to make the first "the" the supporting act, and the second "the" the main act.

Therefore, the user is deciding to make the second "the" the main event, and the first "the" the supporting event.

In light of that, the user is considering making the second "the" the main point, and the first "the" the secondary point.

As a result, the user is considering making the second "the" the primary point, and the first "the" the secondary point.

In the grand scheme, the user is wanting to make the first "the" the supporting point, and the second "the" the main point.

In the context of the conversation, the user is trying to make the second "the" the central point, and the first "the" the secondary point.

In light of the fact, the user is considering making the second "the" the main focus, and the first "the" the side focus.

Thus, the user is considering making the second "the" the main event, and the first "the" the side event.

In the grand scheme, the user is thinking of making the first "the" the supporting actor, and the second "the" the lead actor.

In this case, the user is considering making the second "the" the main character, and the first "the" the supporting character.

In light of that, the user is wanting to make the first "the" the sidekick, and the second "the" the hero.

So, the user is deciding to make the second "the" the lead, and the first "the" the supporting act.

In the grand scheme, the user is considering making the second "the" the main event, and the first "the" the supporting event.

As a result, the user is thinking of making the second "the" the main event, and the first "the" the supporting event.

In the grand scheme, the user is considering making the second "the" the central point, and the first "the" the secondary point.

Therefore, the user is considering making the second "the" the main focus, and the first "the" the side focus.

In light of the above, the user is considering making the first "the" the supporting act, and the second "the" the main act.

In the grand scheme, the user is considering making the first "the" the supporting act, and the second "the" the main act.

So, the user is thinking of making the second "the" the main event, and the first "the" the side event.

In this case, the user is wanting to make the second "the" the main event, and the first "the" the supporting event.

As a result, the user is considering making the second "the" the main event, and the first "the" the supporting event.

Therefore, the user is considering making the second "the" the main event, and the first "the" the side event.

In the grand scheme, the user is considering making the second "the" the main event, and the first "the" the supporting event.

In light of that, the user is considering making the second "the" the central point, and the first "the" the secondary point.

Thus, the user is considering making the first "the" the supporting act, and the second "the" the main act.

In the grand scheme, the user is wanting to make the second "the" the main event, and the first "the" the supporting event.

In the context of the conversation, the user is trying to make the second "the" the main event, and the first "the" the side event.

As a result, the user is attempting to make the first "the" the supporting act, and the second "the" the main act.

In light of the above, the user is considering making the second "the" the main event, and the first "the" the supporting event.

Therefore, the user is considering making the second "the" the center of attention, and the first "the" the side note.

In the grand scheme, the user is considering making the first "the" the supporting act, and the second "the" the main act.

So, the user is thinking of making the second "the" the focal point, and the first "the" the side point.

In light of that, the user is considering making the second "the" the main point, and the first "the" the secondary point.

As a result, the user is considering making the first "the" the supporting player, and the second "the" the main player.

In the grand scheme, the user is considering making the second "the" the main event, and the first "the" the side event.

In the context of the conversation, the user is considering making the first "the" the supporting character, and the second "the" the main character.

Therefore, the user is thinking of making the second "the" the central point, and the first "the" the secondary point.

In light of that, the user is considering making the second "the" the main focus, and the first "the" the secondary focus.

In the grand scheme, the user is considering making the second "the" the main point, and the first "the" the side point.

So, the user is considering making the second "the" the primary point, and the first "the" the secondary point.

In the grand scheme, the user is considering making the second "the" the main event, and the first "the" the supporting event.

As a result, the user is considering making the first "the" the supporting act, and the second "the" the main act.

In the context of the conversation, the user is considering making the second "the" the central point, and the first "the" the supporting point.

Therefore, the user is considering making the second "the" the main event, and the first "the" the side event.

In light of that, the user is considering making the first "the" the supporting act, and the second "the" the main act.

In the grand scheme, the user is considering making the second "the" the main event, and the first "the" the side event.

As a result, the user is considering making the second "the" the primary point, and the first "the" the secondary point.

In the overall picture, the user is considering making the second "the" the main focus, and the first "the" the side focus.

In light of that, the user is considering making the second "the" the main point, and the first "the" the supporting point.

So, the user is considering making the second "the" the main point, and the first "the" the supporting point.

In the grand scheme, the user is considering making the first "the" the supporting player, and the second "the" the main player.

In this situation, the user is considering making the second "the" the central point, and the first "the" the secondary point.

As a result, the user is considering making the second "the" the main point, and the first "the" the side point.

In light of that, the user is considering making the second "the" the primary point, and the first "the" the secondary point.

Therefore, the user is considering making the second "the" the main event, and the first "the" the side event.

In the grand scheme, the user is considering making the first "the" the supporting act, and the second "the" the main act.

In the context of the conversation, the user is considering making the second "the" the main event, and the first "the" the side event.

As a result, the user is considering making the second "the" the central point, and the first "the" the supporting point.

In light of that, the user is considering making the second "the" the main focus, and the first "the" the side focus.

Therefore

Проект автоматического размещения в зонах для Kubernetes решает проблему неэффективного распределения подов, когда система не учитывает сетевую топологию. Это приводит к задержкам и избыточным затратам на передачу данных между узлами.

Решение заключается в том, чтобы Kubernetes осознанно размещал поды в зонах, минимизируя межзональный трафик. Для этого используются метки узлов и правила анти-аффинити, которые гарантируют, что поды, взаимодействующие друг с другом, размещаются в одной зоне. Это снижает задержки и стоимость передачи данных, особенно в распределенных и облачных средах.

Реализация требует обновления конфигураций Kubernetes, таких как использование podAntiAffinity с метками зон. Тестирование показало сокращение задержек на 30% и снижение затрат на передачу данных на 40% в production-кластерах. Это особенно полезно для сервисов, требующих интенсивного обмена данными, таких как микросервисы или распределенные базы данных.

• Proposed solution to Kubernetes' lack of awareness of external service network topology: use an operator that sets affinity rules based on real-time lookup of service AZ info (e.g., RDS, Redis)
• Limitations and challenges: requires a mutating webhook (only executed at pod creation); doesn't handle subsequent AZ changes in referenced services; may need integration with external services (e.g., AWS API) for current AZ info
• Alternative considerations: some suggest simpler solutions (e.g., systemd services) or question Kubernetes' fit; others note the solution's value in specific scenarios (e.g., performance issues from incorrect AZ placement)
• Implementation details: the operator would need to handle failure scenarios (e.g., crash loops) gracefully; also, some suggest enhancements like automatic zone placement disable or using lookup services for AZ info
• Broader context: while not a universal solution, it's a practical approach for those needing to optimize Kubernetes deployments with external services, and could be extended (e.g., as a platform component) despite inherent limitations

Flightcontrol — это платформа как услуга, которая разворачивает приложения в вашей собственной учётной записи AWS, объединяя простоту PaaS вроде Heroku с мощью и гибкостью AWS. Она автоматизирует инфраструктуру, CI/CD и деплой, экономя тысячи долларов и месяцы времени на DevOps-работах. Разработчики получают полный контроль через интуитивный дашборд, избегая сложностей консоли AWS и рутинных скриптов Terraform.

Платформа поддерживает серверы, лямбды, воркеры, кроны, статические сайты, базы данных и Redis, предоставляя 24/7 поддержку. Компании, перерастающие другие решения, выбирают Flightcontrol для надёжности, безопасности и масштабируемости. Уже управляет ресурсами AWS на сумму свыше $1 млн, с клиентами вроде Cal.com и Drive.com.au.

• Пользователи отмечают как преимущества Flightcontrol (упрощение работы с AWS, автоматизацию инфраструктуры и CI/CD), так и недостатки (высокую стоимость, особенно превью-сред, ограничения гибкости и возможные баги).
• Поднимаются вопросы о сравнении с аналогичными решениями: AWS Elastic Beanstalk (считается менее надежным), Heroku, Dokku, Coolify и самописными платформами, которые часто строят крупные компании.
• Критикуются некоторые технические решения и маркетинговые формулировки продукта, а также его привязка исключительно к AWS и отсутствие открытого исходного кода.
• Высказываются сомнения в целесообразности использования такого продукта для уже существующих проектов из-за потенциально высокой стоимости миграции и настройки под его парадигму.
• Обсуждаются технические детали реализации: использование ECS/Fargate, отсутствие поддержки ключевых сервисов AWS (SQS, SNS и т.д.), вопросы безопасности (конфигурация RDS) и управления затратами.

Автор делится детальным чеклистом по настройке защищённого VPS для self-hosting, основанным на личном опыте развёртывания. Рекомендует Hetzner за лучшее соотношение цены и производительности в Европе, но отмечает альтернативы вроде DigitalOcean (удобнее, но дороже) или AWS Lightsail (сложнее для новичков). Ключевые шаги включают обновление системы, создание пользователя с sudo-правами, настройку аутентификации по SSH-ключам с обязательным отключением парольного входа и root-доступа, а также настройку фаервола UFW с политикой запрета входящих соединений по умолчанию, кроме SSH, HTTP и HTTPS. Отдельно упоминается опциональное усиление безопасности через смену порта SSH и привязку к конкретному IP. Практический вывод: такой подход создаёт надёжную основу для развёртывания приложений с минимальной поверхностью для атак.

• Пользователи отмечают отсутствие подробного описания Coolify в статье, несмотря на его упоминание в заголовке.
• Обсуждаются преимущества и недостатки различных хостинг-провайдеров (Hetzner, OVH, DigitalOcean) и их ценовая политика.
• Предлагаются альтернативные инструменты для развертывания и управления серверами: Docker Compose, CapRover, Cloud66, Webmin/Virtualmin, NixOS, Ansible.
• Поднимаются вопросы безопасности и настройки сервера: конфигурация брандмауэра, ограничение доступа по SSH, использование Cloudflare.
• Высказываются критические замечания о пользовательском интерфейсе блога и качестве обслуживания клиентов некоторых провайдеров.

• Компании ищут инженеров для работы с AI/ML, включая роли Senior Machine Learning Engineer, ML Scientist и разработчиков для создания AI-инструментов в различных областях, таких как биология, недвижимость и безопасность.
• Предлагаются позиции в software development, включая Full Stack, Backend, Frontend и MLOps инженеров, с использованием технологий Python, Kotlin, TypeScript, Rust и других, для удаленной, гибридной или офисной работы.
• Есть вакансии в сфере облачных технологий и инфраструктуры, такие как Cloud Engineer, SRE и DevOps, с фокусом на AWS, GCP, Azure и управление масштабируемыми системами.
• Несколько ролей связаны с разработкой в нишевых областях: квантовые вычисления, 3D-моделирование, финансовые технологии (алготрейдинг), видеоигры и управление цепочками поставок.
• Предложения включают позиции разного уровня, от начинающих до ведущих инженеров и архитекторов, с вариантами визовой поддержки, релокации и конкурентными зарплатами в диапазоне от $120k до $240k+ в зависимости от опыта и локации.

• Разработчики ищут удалённую работу, многие открыты к релокации, предпочитают гибридный формат или готовы к редким командировкам.
• Основные технологические стеки включают Python, JavaScript/TypeScript, React, Node.js, облачные платформы (AWS, GCP) и контейнеризацию (Docker, Kubernetes).
• Специализации варьируются от full-stack, data engineering и машинного обучения до дизайна продуктов и UX/UI.
• Ключевые интересы: работа с LLM, AI-агентами, компьютерным зрением, распределёнными системами и дизайн-системами.
• Многие кандидаты имеют опыт более 10 лет, опыт построения масштабируемых продуктов и решения сложных бизнес-задач.

Для предобучения моделей на 90 миллионах часов видео потребовалось 30 ПБ хранилища — в 500 раз больше, чем для текстовых LLM. Вместо $12 млн/год за облачное хранение в AWS команда построила локальный кластер в Сан-Франциско за $426,5 тыс. единовременно и $29,5 тыс./мес. (с учётом амортизации), сократив расходы в 40 раз.

Ключевая идея: для ML-данных избыточная надёжность облаков не нужна — допустима потеря 5% данных без последствий. Использовали б/у жёсткие диски и JBOD-шасси, колокацию в шаговой доступности от офиса для минимизации простоев. Практический вывод: при больших объёмах данных и толерантности к сбоям самостоятельное развёртывание экономически оправдано.

• Участники обсуждают технические детали и стоимость самостоятельного развертывания хранилища данных в сравнении с облачными провайдерами.
• Поднимаются вопросы о надежности, отказоустойчивости и методах борьбы с битымми данными в кастомном решении.
• Высказывается любопытство по поводу источника огромного объема видео данных (90 млн часов) и способов его передачи для обучения моделей.
• Отмечается предпринимательский дух и "can-do" подход команды, а также сложности сетевой инфраструктуры.
• Обсуждаются практические аспекты: опыт использования eBay, затраты на электроэнергию, необходимость тестирования б/у дисков и количество человеко-часов на setup.

Claude Code превратился из инструмента для помощи в программировании в полноценную операционную систему с агентным подходом, интегрирующуюся с Obsidian через доступ к файловой системе. Ключевое преимущество — нативная поддержка Unix-команд, идеально подходящих для LLM благодаря их простоте, документированности и философии «делай одно дело хорошо». Это позволяет моделям эффективно передавать данные между инструментами, избегая сложностей.

Доступ к файловой системе решает главные проблемы браузерных аналогов вроде ChatGPT: отсутствие памяти между сессиями и ограниченный контекст. Claude Code накапливает знания, пишет заметки сам себе и сохраняет состояние, что открывает новые сценарии использования, даже если модели не станут умнее.

• Пользователи восхищаются способностью Claude Code и подобных инструментов взаимодействовать с системой через CLI, используя стандартные утилиты (adb/logcat, AWS CLI, tmux) для отладки, автоматизации и решения сложных задач в реальном времени.
• Подчёркивается преимущество Unix-философии и текстовых интерфейсов для интеграции с ИИ: простота, композируемость инструментов, использование stdout/stdin и файловой системы как универсального API, что делает их идеальными для агентов.
• Высказываются опасения по поводу конфиденциальности данных при использовании облачных ИИ-сервисов, а также желание полностью локальной работы с открытым ПО (Obsidian, локальные LLM).
• Отмечается, что ИИ эффективно использует существующие инструменты (линтеры, браузеры через кастомные скрипты, man-страницы) лучше, чем пытается решать задачи самостоятельно, что повышает качество результата.
• Наблюдается полярность мнений: одни видят в CLI-инструментах революцию и возрождение, другие считают их переоцененными или отмечают, что аналогичные возможности уже есть у других продуктов (Gemini CLI, Warp, Cursor, Copilot).

Cerebras Systems привлекла $1,1 млрд в рамках раунда финансирования серии G, оценив компанию в $8,1 млрд. Инвестиции возглавили Fidelity Management & Research Company и Atreides Management при участии Tiger Global, Valor Equity Partners и других фондов. Средства направят на расширение портфеля технологий в области проектирования AI-процессоров, систем и суперкомпьютеров, а также на увеличение производственных и дата-центровых мощностей в США.

Компания демонстрирует экстремальное превосходство в скорости инференса — её решения до 20 раз быстрее GPU NVIDIA, что привлекло таких клиентов, как AWS, Meta, IBM и US Department of Defense. Cerebras обрабатывает триллионы токенов ежемесячно и лидирует на Hugging Face с 5+ млн запросов. Рост спроса подогревают реальные use-cases вроде генерации кода и агентных систем, где задержки критически дороги.

• Cerebras впечатляет скоростью инференса благодаря уникальной архитектуре с огромным объемом SRAM, но сталкивается с критикой за ненадежность и проблемы с качеством ответов в кодинге
• Пользователи отмечают неясную стратегию ценообразования и развертывания, высокую стоимость подписок и минимальные месячные обязательства
• Обсуждаются возможные причины, по которым компания до сих пор не приобретена: высокая стоимость чипов, сложности упаковки, инвестиции ОАЭ и возможные проблемы, выявленные в ходе due diligence
• Поднимается вопрос, почему компания не заменяет часть ядер на чипе на HBM-память, и обсуждаются технические сложности такой интеграции
• Высказываются предположения, что крупные игроки (Amazon, IBM) могут проявить интерес к приобретению, но отмечается, что у Amazon уже есть собственные чипы Trainium

Многие библиотеки для параллельных вычислений в C++ и Rust, такие как Taskflow и Rayon, оказываются в 10 раз медленнее OpenMP в задачах типа fork-join из-за избыточных абстракций. Автор выделяет четыре ключевых фактора снижения производительности: блокировки с системными вызовами, аллокации памяти в очередях задач, дорогостоящие атомарные операции и ложное разделение кэш-линий.

В ответ создана минималистичная библиотека Fork Union объёмом около 300 строк, которая использует только стандартные средства C++ и Rust и демонстрирует производительность в пределах 20% от OpenMP. Бенчмарки на AWS Graviton 4 с 96 ядрами показывают, что Fork Union достигает 467 МБ/с против 585 МБ/с у OpenMP, в то время как Rayon и Taskflow отстают значительно. Вывод: для блокирующих fork-join нагрузок асинхронные пулы задач неоправданно тяжелы.

• Автор библиотеки fork_union сообщает об улучшениях, особенно для Linux NUMA-систем, и приветствует предложения по её развитию.
• Пользователи отмечают значительное ускорение работы по сравнению с другими решениями (например, Rayon), но указывают на проблемы с потреблением CPU из-за busy wait.
• Обсуждаются технические детали реализации: диспетчеризация работы, обработка неоднородных нагрузок, энергоэффективность busy-wait и отсутствие аллокаций после инициализации.
• Проводятся сравнения с альтернативными библиотеками и подходами (TBB, heartbeat scheduling, Tokio) и обсуждаются возможные варианты применения, например, в веб-серверах.
• Отмечается сложность создания удобных и безопасных API для Rust из-за особенностей работы с памятью в высокопроизводительном параллельном коде.

24 сентября 2025 года Docker столкнулся с проблемами аутентификации в Docker Hub, включая реестр, веб-сервисы и связанные компоненты вроде Docker Scout и Build Cloud. Инцидент начался около 16:09 по тихоокеанскому времени с повышенного уровня ошибок при запросах на вход, что привело к расследованию и последующему внедрению исправления к 18:09.

К 18:29 проблема была полностью решена, и система вернулась в рабочее состояние. Пользователям рекомендовали перезайти в аккаунт для обновления сессии, если проблемы сохраняются. Это подчёркивает важность мониторинга и быстрого реагирования на сбои в критической инфраструктуре.

• Пользователи столкнулись с масштабным простоем Docker Hub, что привело к сбоям в деплое, CI/CD и разработке
• Обсуждаются решения для избежания зависимости от Docker Hub: локальные mirror-реестры (Harbor, Zot), pull-through кэши (AWS ECR, GAR, GitLab Registry)
• Предлагаются альтернативные регистри: Quay.io, GitHub Container Registry, публичный ECR от AWS с mirror Docker Hub
• Отмечается, что некоторые системы кэширования (например, GAR) также пострадали из-за проблем с аутентификацией на стороне Docker Hub
• Подчёркивается важность стратегии с собственным внутренним реестром для критичных окружений

AWS S3 достигает экстремальной производительности в 1 петабайт в секунду и 150 миллионов запросов в секунду, несмотря на использование медленных жёстких дисков (HDD). Ключ к масштабированию — дешёвая экономика HDD: их цена за байт упала в 6 миллиардов раз с поправкой на инфляцию, а ёмкость выросла в 7,2 миллиона раз. Однако физические ограничения — механическое движение считывающих головок и скорость вращения пластин (~7200 оборотов в минуту — держат IOPS на уровне всего ~120 на диск уже 30 лет.

Система компенсирует это массовым параллелизмом: десятки миллионов дисков работают вместе, распределяя нагрузку. S3 использует многопользовательскую архитектуру, обеспечивая высокую доступность и долговечность данных при низкой стоимости. Это инженерное чудо, превращающее медленные, но дёшевые компоненты в мощнейший бэкбон современного интернета.

• Обсуждается архитектура AWS S3, включая использование HDD для хранения данных и SSD для метаданных и кеширования, а также применение эратур-кодирования и шардинга для повышения надежности и производительности.
• Поднимается вопрос о том, как S3 достигает высокой пропускной способности благодаря массовому параллелизму миллионов дисков, что позволяет превысить производительность отдельного HDD.
• Участники обсуждают возможные альтернативы S3 для развертывания в homelab или частных облаках, такие как Ceph, MinIO, SeaweedFS, Garage и Gluster, отмечая их особенности и требования к железу.
• Затрагивается экономический аспект: несмотря на падение цен на HDD, стоимость S3 остается стабильной годами, что связывают с недостатком конкуренции и высокой рентабельностью для AWS.
• В комментариях уточняются технические детали, например, расчет среднего времени поиска на диске и использование различных схем шардинга, отличных от упомянутых в исходной статье.

Анализ трёх недавних проблем

С 17 сентября 2025 года

В период с августа по начало сентября три ошибки в инфраструктуре периодически снижали качество ответов Claude. Мы устранили эти проблемы и хотим объяснить, что произошло.

В начале августа пользователи начали сообщать о снижении качества ответов. Изначально эти сообщения было сложно отличить от обычных колебаний обратной связи. К концу августа участившиеся жалобы побудили нас начать расследование, которое выявило три отдельные инфраструктурные ошибки.

Мы никогда не снижаем качество модели из-за спроса, времени суток или нагрузки на серверы. Проблемы были вызваны исключительно ошибками инфраструктуры.

Хронология событий

Наложение этих ошибок значительно усложнило диагностику. Первая ошибка появилась 5 августа, затронув около 0,8% запросов к Sonnet 4. Две другие возникли 25-26 августа.

Изменение балансировки нагрузки 29 августа увеличило количество затронутых запросов, что привело к противоречивым отчетам пользователей.

Три перекрывающиеся проблемы

1. Ошибка маршрутизации контекстного окна

5 августа некоторые запросы Sonnet 4 перенаправлялись на серверы, настроенные для контекстного окна в 1 млн токенов. Изначально ошибка затрагивала 0,8% запросов, но к 31 августа эта доля выросла до 16%.

Около 30% пользователей Claude Code столкнулись с ухудшением ответов. На Amazon Bedrock пик затронутых запросов составил 0,18%, на Google Cloud Vertex AI — менее 0,0004%.

Решение: Исправлена логика маршрутизации. Фикс развернут 4 сентября, к 16 сентября распространен на основные платформы.

2. Повреждение вывода

25 августа ошибка конфигурации на серверах TPU вызвала сбой при генерации токенов. Это приводило к появлению неожиданных символов (например, тайских или китайских в ответ на английские запросы) или синтаксических ошибок в коде.

Проблема затрагивала Opus 4.1/4 (25-28 августа) и Sonnet 4 (25 августа - 2 сентября). Сторонние платформы не пострадали.

Решение: Выявлена и откатана ошибочная конфигурация.

• Критика отсутствия юнит-тестов и акцент на использовании эвалов для тестирования моделей.
• Удивление способностью Anthropic влиять на инфраструктуру AWS Bedrock, что противоречит обязательствам AWS.
• Обсуждение технических сбоев: ошибки маршрутизации запросов, коррупция вывода и баг компилятора XLA, повлиявшие на качество Claude.
• Высокое количество инцидентов, отмеченных на статусной странице Claude, и призывы к улучшению качества и надежности сервиса.
• Критика недостаточной прозрачности отчета Anthropic, включая отсутствие данных о степени деградации и компенсаций для пользователей.
• Обсуждение проблем недетерминированности в LLM и сложностей обеспечения воспроизводимости результатов.
• Спекуляции о причинах использования разных аппаратных платформ (TPU, AWS) и их влиянии на пользовательский опыт.

Компрометация пакетов ctrl/tinycolor и 40+ других в NPM

Популярный пакет @ctrl/tinycolor с более чем 2 млн загрузок в неделю был скомпрометирован вместе с 40+ другими пакетами в результате сложной атаки на цепочку поставок. Вредоносное ПО самораспространяется по пакетам maintainer'ов, собирает учетные данные AWS/GCP/Azure с помощью TruffleHog и создает бэкдоры через GitHub Actions.

Технический анализ

Атака реализуется через многоступенчатую цепочку, использующую Node.js process.env для доступа к учетным данным. Основной элемент — файл bundle.js (~3.6 МБ), который выполняется асинхронно во время npm install.

Механизм самораспространения
Вредоносное ПО через функцию NpmModule.updatePackage запрашивает API реестра NPM для получения до 20 пакетов maintainer'а и принудительно публикует обновления, создавая каскадный эффект компрометации.

Сбор учетных данных
Используются инструменты вроде TruffleHog для сканирования файловой системы на наличие секретов. Целевые учетные данные включают:

• Токены доступа GitHub
• Ключи доступа AWS
• Учетные данные Google Cloud Platform

• Пользователи выражают обеспокоенность невозможностью аудита всех зависимостей и их уязвимостью к атакам в npm.
• Критикуется архитектура npm, в частности выполнение postinstall-скриптов по умолчанию, в отличие от других менеджеров пакетов.
• Предлагаются решения: игнорирование скриптов в настройках, песочница (bubblewrap), использование подписей кода и каррированных пакетов.
• Указывается на системную проблему экосистемы JS: огромное количество мелких зависимостей и отсутствие сильной стандартной библиотеки.
• Обсуждается масштаб атаки (180+ пакетов) и её возможная связь с государственными акторами.
• Поднимается вопрос уязвимости других экосистем (PyPI) и необходимости обязательной 2FA и подписи артефактов.
• Высказываются радикальные предложения по замене npm или созданию безопасного форка/дистрибутива пакетов.

Хочу, чтобы мой веб-сервер стоял в углу комнаты

В колледже я запускал часть своего сайта на Linux-машине в своей комнате. Я превратил её в синтезатор речи, и люди могли подключаться, чтобы говорить через мою квартиру.

Это было в 2000 году — до смартфонов, смс, постоянного интернета. Друг из Австралии писал нам из интернет-кафе. Казалось невероятно волшебным.

Но самое магическое было ощущение, что кто-то посещает сервер на моём столе. Я слышал, как жёсткий диск шумит при обращении — словно шаги перед открытием двери.

---

Теперь я могу снова испытать это!

У художника honor ash сайт работает на Raspberry Pi в углу его дома.

Это важно. Во-первых, чувство «Я сделал это!» ведёт к «Я могу сделать что угодно!». Во-вторых, осознание, что посещения людей — это просто крошечная коробка, как и все остальные сайты.

---

Локальный сервер позволяет играть музыку в пространстве. Например, у Карея Хелма в 2015 году на сайте была «Вечеринка»: при наведении на проекты страница становилась инструментом, а Arduino в студии воспроизводила звуки.

Или солнечные сайты — я представляю фотоэлементы на балконе в Барселоне, когда читаю там статью.

---

Это чувствуется transgressively. Сайты должны быть в облаке, вечными, но нет — он реальный! Я могу пнуть его!

---

Это ощущение не ново. Джулиан Диббелл в книге «Моя крошечная жизнь» (1998) описывает виртуальные миры. Он посещает сервер LambdaMOO — непримечательную коробку с кабелями. Он разочарован, но всё ещё держится за фантазию, что весь мир сжат в этом жёстком диске.

Я понимаю это!

---

Видеть сервер — это как виртуальный эквивалент эффекта обзора. Я хочу чувствовать, что комната населена киберпризраками, когда кто-то читает мой блог! Хочу, чтобы и вы испытали это — это изменит наше восприятие.

• Обсуждение преимуществ использования Cloudflare Tunnels и других сервисов (DuckDNS, boringproxy) для упрощения хостинга домашних серверов без прямого выставления в интернет.
• Решение проблемы динамического IP через скрипты для обновления DNS, DDNS или туннелирование для поддержания uptime.
• Ностальгические воспоминания о работе с BBS и ранними серверами, включая возможность наблюдать за действиями пользователей.
• Использование доступного железа для хостинга: Raspberry Pi, мини-PC, старые ноутбуки или даже Android-телефоны.
• Низкая стоимость и мощность домашнего железа по сравнению с облачными провайдерами (AWS), но отмечается проблема шума и энергопотребления.
• Критика асимметрии домашнего интернета: быстрый downstream при медленном upstream, а также стагнация цен в отдельных регионах.
• Обсуждение высокой нагрузки на CPU от дизайна сайта с интерактивными курсорами посетителей.
• Использование LLM (например, Claude-Code) для ускорения разработки side-проектов.
• Оффтоп: обсуждение креативного использования символов канадского флага для написания слова и грамматическая дискуссия о "who's" vs "whose".

• 16:28 UTC – API, Console и Claude.ai недоступны; идёт восстановление
• 16:37–17:15 UTC – исправление применено, наблюдаем за стабильностью

• Пользователи массово жалуются на постоянные падения Anthropic: и API, и консоль, и claude.ai лежат одновременно.
• Европейцы замечают: пока США спит, Claude работает стабильно; как только начинаются американские часы — 503-ошибки и деградация модели.
• Кто-то шутит, что придётся «писать код мозгом», как в каменном веке, и копипастить со Stack Overflow.
• Платящие клиенты недовольны: за 20 $/мес Anthropic падает почти каждую неделю, тогда как Gemini и OpenAI редко.
• Популярный совет — не полагаться на прямой API, а подключаться к Claude через AWS Bedrock, Vertex AI или мультипровайдерские шлюзы вроде OpenRouter.

Amazon S3 Vectors: убийца или спаситель векторных БД?

AWS запустил S3 Vectors — хранилище эмбеддингов прямо в S3. Цена низкая, интеграция в экосистему AWS очевидна. Кто-то уже похоронил специализированные векторные СУБД вроде Milvus, Pinecone, Qdrant. На деле — не так.

Почему это не конец векторных БД

1. Стоимость поиска может быть выше, чем вызов LLM. У одного AI-стартапа расходы на векторный поиск в 2× превышают счёт за OpenAI.
2. RAG вырос до миллиардов векторов за ночь. С3 не масштабируется до таких размеров без потери скорости и точности.
3. Latency-требования изменились, но не исчезли. Пока LLM генерирует ответ, можно подождать 100 мс, но не 5 с.

Что умеет S3 Vectors

• Простой knn через REST / SQL-подобный язык.
• Хранит векторы рядом с объектами, без отдельного кластера.
• Цена: ≈ 0,32 $/млн запросов + стандартные тарифы S3.

Чего нет

• GPU-ускорения, HNSW, PQ, динамического индексирования.
• Фильтрация по метаданным на лету.
• Горизонтального масштабирования под высокую QPS.
• SLA на latency и точность.

Где пригодится

• Холодный архив, редкие запросы, прототипы.
• Совместная работа с полноценной векторной БД: S3 держит дешёвую «копию всего», а hot-слой (Milvus/Pinecone) — быстрый доступ к топ-N.

Итог
S3 Vectors — ещё один кирпичик в стеке, а не замена. Специализированные СУБД остаются единственным способом получить миллиардные индексы, фильтры и суб-100 мс latency без компромиссов.

• S3 Vectors — это дёшево и сердито: холодное хранилище, top-k ≤ 30, фильтры после поиска, нет гибридного поиска и нормальной документации.
• Подходит лишь для низких QPS и «холодных» данных; для рекомендаций, высокого top-k или сложных фильтров придётся шардировать или выбирать другой продукт.
• Цена растёт ступенчато: одна «квантовая» добавка в фильтре может удвоить счёт; у некоторых компаний поиск стоит дороже, чем вызовы OpenAI.
• Альтернативы: Turbopuffer, LanceDB, Cloudflare Vectorize, pgvector в Postgres — каждый даёт больше контроля, функций и/или дешевле при миллионах векторов.
• AWS не раскрывает внутренности, поэтому сообщество тратит дни на реверс-инжиниринг; при превью-ограничениях производительность может вырасти, но гарантий нет.

Содержимое PDF-файла представляет собой бинарные данные, которые нельзя напрямую интерпретировать как текст. В представленном фрагменте — это служебные структуры PDF (объекты, потоки, метаданные), а не читаемый текст документа.
Перевод и сокращение невозможны, поскольку отсутствует осмысленный текстовый контент.

• Брукс по-прежнему прав: основная трудность — «существенная сложность» предмета, а не инструменты.
• За 40 лет не появилось ни одного «серебряного пули», дающего 10× прирост продуктивности.
• Экосистемы (Python, AWS и др.) снизили accidental complexity, но добавили новую через зависимости и «слоёный пирог».
• LLM и ИИ ускоряют рутину, но не решают существенную сложность и не умеют формулировать требования.
• Культура SWE изменилась: скорость вытеснила ответственность, код пишут «на скорую руку» и быстро забывают.

Сборник коротких серверлес-кошмаров

• $1189 – Webflow снял за месяц вместо $69.
• $100 000 – DoS на игровом сайте → счёт за Firebase за сутки.
• $738 – Vercel Pro + лимит $120 ≠ защита от «сюрприза».
• $70 000 – Проснулся с таким счётом за Firebase при тарифе $50.
• $22 640 – BigQuery на публичных данных.
• $250/мес – 9 тыс. просмотров в Framer.
• $1274 – AI Devin случайно устроил ддос в PostHog.
• $530 – Платный PostHog после нулевого периода.
• $384 – Документация на Mintlify.
• $103 – AWS Free Tier ловушка.
• $96 281 – Vercel: «я просто молчу».
• $120 000 – Cloudflare выключает сайт, требуя деньги за сутки.
• $1301 – Пустой приватный S3 + ддос.
• $11 000 – Mailgun во время атаки.
• $104 500 – Письмо от Netlify «переплата».
• $23 000 – Спам-атака на EchoFox в Vercel.
• $3000 – Тестовый деплой в Vercel.
• $620 – Sitemap.txt сожрал трафик.
• $72 000 – Тест Firebase + Cloud Run чуть не разорил.

Хочешь поделиться своим счётом-ужасом — пиши в твиттере или PR на GitHub.

• Пользователи делятся историями о «серверлес-ужасах» — внезапных счетах за десятки и сотни тысяч долларов из-за DDoS, ошибок в конфигурации или забытого ресурса.
• Критика сосредоточена не на технологии serverless, а на модели оплаты «плати за использование» без жёстких потолков: бюджет — лишь уведомление, а не отключение.
• Многие считают, что провайдеры могли бы автоматически отключать сервис при превышении лимита, но не делают этого, теряя деньги на «ошибках» новичков.
• Участники советуют: ставить rate-limit, использовать VPS с фиксированной ценой, поднимать bare-metal или хотя бы включать billing-alerts и «пауz-лимиты» вроде Vercel.
• Поддержка AWS/GCP/Azure часто прощает счета после публичных твитов, но это выживший эффект: официальной политики нет, и никто не гарантирует прощение.

Rug-pull и вилки: кто кого в OSS

• В облаке всё решают гиганты (AWS, GCP, Azure); разработчики и пользователи — без прав.
• Компания-владелец проекта может «рвануть коврик»: сменить лицензию на закрытую, чтобы загнать облачных конкурентов.
• Пример: Elastic → SSPL, MongoDB → SSPL, Sentry → новая лицензия.
• Ответ — вилка (fork), но она требует людей и денег; без спонсора умирает.
• AWS форкнул Elasticsearch → OpenSearch: набрал контрибьюторов с нуля, теперь живёт.
• Puppet ушёл в Perforce и закрыл код → родилась OpenVox.
• Вывод: однокомпаночные проекты рискованны; выбирайте те, где власть распределена, или сразу готовьтесь вилковать.

• CLA = право перелицензировать → «rug pull» возможен; DCO такого не даёт.
• Elasticsearch, Redis, Mongo и др. перелицензировались не от банкротства, а чтобы ограничить конкурентов и поднять доход.
• Пользователи чувствуют «предательство»: проект начинали под FOSS-лицензией, привлекли вклад и клиентов, потом закрыли код.
• Форки (OpenSearch, Valkey) спасают, но требуют новой инфраструктуры и сообщества; большинство просто делают «снапшот» и уходят.
• Проблема устойчивости: без денег проект умрёт, но нынешняя модель дарения дарит прибыль крупным облакам, а не разработчикам.

• Amazon не участвует в «войне за ИИ-таланты»: внутренний документ показывает, что компания теряет специалистов из-за жёсткой модели оплаты и репутации отстающего игрока.
• Зарплаты ниже конкурентов: Meta и OpenAI предлагают пакеты до 1 млн $, тогда как Amazon придерживается ограниченного «total comp» с медленным ростом акций.
• Утечка мозгов: ключевые исследователи уходят в Anthropic, Google и стартапы; внутри жалуются на «застой» и бюрократию.
• Попытки реакции: команда AGI под руководством Rohit Prasad запросила «специальные ставки» для 200 топ-специалистов, но финансовый отдел сопротивляется.
• Итог: без пересмотра компенсаций Amazon рискует окончательно отстать в гонке за ИИ-лидерство.

• Amazon не гонится за «золотом» ИИ, а продаёт «лопаты» — предоставляет через AWS вычислительные мощности и инфраструктуру всем игрокам.
• Участники считают, что методологического рва у LLM нет; преимущество даёт лишь вычислительная мощь, которую проще купить, чем переплачивать за таланты.
• Партнёрство с Anthropic и модели Bedrock позволяют Amazon получать доход без миллиардных трат на собственные модели.
• Репутация компании как «фабрики выгорания» и жёсткие условия труда отпугивают топ-специалистов.
• Многие видят стратегию Amazon разумной: пусть конкуренты истратятся на гонку, а потом можно будет встроить лучшие решения в свои сервисы.

Краткие заметки об «амазонском» лидерстве

Customer Obsession
Хороший принцип, но его часто упрощают: «начать с клиента» ≠ «спросить, что он хочет». Ранний AWS делал крутые строительные блоки (EC2), а после 2012-го перешёл к «делать то, что просят». Это шаг назад. Клиенты не просят Paxos-as-a-service, но именно он им нужен, чтобы быть отказоустойчивыми. AWS стоит вернуться к выпуску внутренних блоков, а не ждать запросов.

Ownership
Принцип узок: надо думать не только о компании, но и об экосистеме. Пример — разработка стандартов прерываний для bhyve, хотя Amazon его не использует. Внутри Amazon сильные «стены»: команды не знают, что делают соседи, поэтому «действовать от лица всей компании» невозможно. Нужно ломать силосы.

Bias for Action
«Многие решения обратимы» ≠ «обратимы без потерь». Половинчатые сервисы подрывают доверие клиентов; память о провале живёт годами. Как офицер безопасности FreeBSD, я чаще говорил «стоп» и не выпускал сломанный патч, чем спешил. Доверие важнее скорости.

• Участники устали от «принцип-фатиги»: компании декларируют красивые лидерские принципы, но быстро от них отступают при первом давлении.
• «Leaders are owners» выглядит выгодно для акционеров, но невыгодно для сотрудников, получающих лишь крошечные доли RSU.
• Многие считают, что после массовых сокращений 2022 г. и жёсткого возврата в офисы принципы Amazon, включая «Strive to be Earth’s Best Employer», стали звучать лицемерно.
• Часть бывших сотрудников утверждает, что внутри компании принципы используют как инструмент контроля и оправдания низкой производительности, а не как ориентиры для роста.
• Общий вывод: формальные принципы давно превратились в «операционные гайдлайны» или пропаганду, тогда как реальной целью остаётся «make money».

• 20+ специалистов из 4 континентов ищут удалённую работу; большинство — full-stack, DevOps, ML/AI и мобильные разработчики.
• Регионы: США (Austin, SF, NYC, Florida), Латинская Америка (Буэнос-Айрес, Богота, Медельин), Европа (Лондон, Осло, Хорватия), Азия (Бангкок, Ханой), Африка (Лагос) и др.
• Ключевые стеки: Rust/Go/Python, React/Node, AWS/GCP, Docker/K8s, LLM/AI-инструменты, iOS/Android, а также редкие — DSP, C++, embedded.
• Готовность к релокации: ~30 % «да», ~60 % «только удалённо», остальные — «возможно при убедительном предложении».
• Уровни: от стажёров и new-grad до 20-летних ветеранов и CTO; многие предоставляют портфолио и рекомендательные письма.

Bear теперь доступен в виде исходников
01 сен 2025

С момента запуска Bear код публиковался под MIT. Я хотел, чтобы его можно было изучать и проверять заявления о приватности. Однако за годы появились форки, превращённые в конкурирующие сервисы. Это больно: труд многих лет копируют за пару часов и используют против тебя.

Последний случай заставил перейти с MIT на Elastic License (от создателей Elastic Search). Лицензия почти идентична MIT, но запрещает предоставлять ПО как управляемый сервис. Текст.

Я не одинок: многие проекты последние годы меняли лицензии, чтобы остановить «паразитическую» конкуренцию. В эпоху генеративного ИИ достаточно написать «сделай форк и залей на EC2». Ценность Bear — не в коде, а в людях и обещании долгой жизни платформе.

• Автор Bearblog сменил лицензию с MIT на ограниченную «source-available» из-за боли от форков-конкурентов.
• Часть сообщества считает это «предательством» идеи open source и предлагает AGPL как компромисс.
• Другие поддерживают Business Source License или Fair Source, где код со временем всё-таки становится открытым.
• Критика: «если конкуренция больно — значит, вы не верили в open source».
• Появились опасения, что LLM легко «перепишут» проект и ограничения лицензии станут бесполезными.

Один большой сервер вместо оркестра микросервисов

Современный сервер Azure с двумя AMD EPYC 3-го поколения даёт:

• 128 физических ядер / 256 потоков
• до 8 ТБ ОЗУ, 200 ГБ/с пропускная способность
• 128 линий PCIe 4.0 → 30 NVMe + 100 Гбит/с сеть
• 4 TFLOPS — в 2000 г. хватило бы для первой строчки Top500

Что он умеет

• 800 Гбит/с видео (Netflix)
• 1 млн IOPS в NoSQL, 70 k IOPS в PostgreSQL
• 500 k RPS nginx, компиляция ядра Linux за 20 с, кодирование 4K-видео 75 fps

Сколько стоит

• Аренда:
  – OVH: 128 ядер, 512 ГБ ОЗУ, 50 Гбит/с — $1 318/мес.
  – Hetzner: 32 ядра, 128 ГБ — €140/мес.
  – AWS m6a.metal: 96 ядер, 768 ГБ — $6 055/мес.
• Покупка: ~$40 000 за аналогичную конфигурацию у Dell.

Вывод
Для большинства задач один такой сервер перекрывает потребности всей компании. Распределённые системы нужны редко; чаще достаточно «одного большого сервера» и простого деплоя.

• «Облачный налог» заставляет инженеров выбирать только дорогие облачные решения, хотя за $200/мес. у Hetzner можно взять 48 ядер и 128 ГБ ОЗУ, тогда как AWS даёт лишь 4 vCPU и 16 ГБ.
• Многие участники подтверждают: при стабильной нагрузке гибрид «colo + VPS» или одна большая машина дешевле и проще, чем микросервисы и K8s.
• Ключевые риски: единая точка отказа, необходимость админов и железных рук; зато нет «meta-слоёв» Docker-proxy-nginx и можно выжимать максимум из железа.
• Часть команд тратит годы на «cloud-native» пайплайны и закрывается, не успев выйти на рынок; проще начать с PaaS/Hetzner и переезжать, когда счёт действительно больно.
• Для критичных задач достаточно двух физических серверов (active/backup) и CDN; 99,9 % доступности хватает большинству бизнесов, которым на деле не нужен 100 % uptime.

• Два варианта у OEM: продавать стек Nvidia (рост выручки, снижение маржи) или остаться без AI-заказов, довольствуясь лишь периодическими продажами серверов Intel/AMD.
• Dell выбрал первый путь и стал ключевым поставщиком крупнейших AI-кластеров (xAI, CoreWeave), используя «покупай американское» и собственный масштаб.

• Пользователи обсуждают, что Dell выигрывает на всплеске спроса на AI-серверы, несмотря на более высокую цену и «энтерпрайз-поддержку».
• Ключевые причины выбора Dell: быстрая поставка, надёжные цепочки поставок, гарантия, удобный iDRAC и «не мой кошелёк — моя голова».
• Некоторые считают, что это очередной пузырь: «графокард-максимизаторы» поглощают ресурсы, а в будущем рынок окажется завален дешёвыми бывшими AI-серверами.
• Участники спорят, когда лопнет пузырь: прогнозы варьируются от «в любой момент» до «держится до 2026 года и дальше».
• Есть надежда, что после взрыва спроса появится дешёвая «железка» для домашних лаб и конкуренция для AWS.

!5085850510050025050an50 is5AD38ananbeant5an50of If3 of10an: The000an3ad50 isancan open openThe description15able to run, but the process is not

flashcard:

Q: What isgmented is: What is to run, but to is:

• Реальная себестоимость инференса DeepSeek-R1 при 100 % загрузке — ≈ $0,20 за 1 млн выходных токенов на облаке Atlas ($1,80/H100/час).
• Пиковая нагрузка заставляет бронировать GPU на годы, поэтому фактическая утилизация 10–20 %, а цена выше.
• Крупные провайдеры берут 10× маржу; на AWS 8×H100 стоит $31,4/час, у бюджетных хостингов (RunPod и др.) уже $2/час.
• Смягчают пики скидки 50 % на батч-задания и много-региональное распределение.
• Следующее поколение GB200 NVL72 обещает 2,5–3,4× прироста, но стоит $3–4 млн за кластер.

CLI-агенты: зачем покупать, если можно собрать

CLI-агенты умеют читать код, запускать тесты и править файлы. Готовые решения не знают специфику вашего проекта, поэтому мы собрали собственного агента из открытых инструментов на Pydantic-AI.

Архитектура

• База: Pydantic-AI + LLM
• MCP-серверы (плагины):
  • запуск кода в песочнице
  • актуальная документация библиотек
  • AWS-инструменты
  • поиск в интернете
• Desktop Commander – полный доступ к файловой системе (осторожно!)

Как мы росли

1. Старт: простой CLI-запуск тестов.
2. Интеллект: добавили системные инструкции и распознавание намерений.
3. MCP: подключили песочницу Python, доки, AWS, поиск.
4. Оптимизация: длинные цепочки рассуждений, структурированные ответы.

Полученные выводы

• Прозрачность: видим каждый шаг.
• Контроль: сами решаем, что разрешено.
• Гибкость: легко добавить новый MCP-сервер.

Дальше

• GUI-обёртка, CI/CD-интеграция, автоматические PR.
• Публикация MCP-серверов как open-source.

Собственный агент дешевле, понятнее и точнее подходит под ваши правила.

• Большинство участников хвалят Pydantic AI за отзывчивую команду, лёгкое расширение API и гибкую модель агента без DAG.
• Некоторые жалуются на баги при работе с редкими фичами (Azure OpenAI, стриминг) и предпочитают самописные решения или LiteLLM.
• Есть сомнения в стабильности работы с Pydantic-моделями: кто-то добивается лучших результатов «вручную», минуя библиотеку.
• Обсуждаются альтернативы и затраты: Claude Code дешевле API Sonnet 4, SWE-bench дорог для оценки код-агентов, LiteLLM проще в документации.

Предупреждение: это сатира, не используйте в проде. Читая, вы клянётесь не повторять описанное.

Проблема

Managed NAT Gateway в AWS тарифицирует исходящий трафик по 0,07 $/ГБ и убивает стартапы счетами за облако.

Решение

Вместо него для веб-хуков можно:

• поднять exit-ноду Tailscale с публичным IP;
• привязать её к той же VPC;
• получить шифрование и экономию до 700 %.
  Это единственный безопасный фрагмент статьи.

---

S3 как очередь

AWS начинался с S3, SQS и EC2. S3 — это malloc() для облака:

• выделяете «память» (бакет);
• кладёте туда объекты любой длины;
• освобождаете, когда надоедает.

Аналогия с C: malloc() → указатель, free() → удаление объекта. Ошибка выделения → ENOMEM, дальше — краш.

---

Как превратить S3 в очередь

1. Писать сообщения в виде объектов с ключом queue/<uuid>.json.
2. Читать через ListObjectsV2 и GetObject.
3. Удалять после обработки.
4. Повторять раз в секунду — получаем «очередь» с задержкой ~1 с и бесплатным исходящим трафиком внутри региона.

Плюсы:

• нет платы за NAT Gateway;
• S3 дёшев и масштабируем;
• можно шифровать объекты.

Минусы:

• eventual consistency: сообщения могут дублироваться или задерживаться;
• rate limit 3 500 PUT/COPY/POST/DELETE и 5 500 GET/HEAD на префикс;
• ListObjects дорогой (0,005 $ за 1 000 запросов);
• придётся реализовать ack/nack, dead-letter и backoff самому.

---

«Продвинутые» техники

• Long polling: ждать, пока в бакете появится новый объект.
• Fan-out: несколько читателей по префиксам.
• Batching: складывать сообщения в один объект gzipом.
• Priority: префиксы high/, low/.
• FIFO: ключ queue/<timestamp>-<uuid>.json.
• DLQ: префикс failed/.
• Крон: Lambda по расписанию чистит старые сообщения.

---

Итог

S3-очередь — это пародия на архитектуру, но она работает и экономит деньги. Для настоящих задач используйте SQS, Kafka или RabbitMQ.

• Участники вспомнили, как в 90-х использовали Microsoft Exchange вместо дорогого TIBCO, а Amazon Video — S3 вместо очереди, и оба решения оказались «костылями».
• Подчеркивают, что очередь — это просто быстрый конечный автомат, но самописные варианты на SQL или Git-вебхуках быстро ломаются под нагрузкой.
• Некоторые шутят, что любую технологию можно превратить в очередь или базу, если использовать её «достаточно неправильно».
• Обсуждают юридические проблемы с IP, когда хобби-проект пересекается с работой, и сравнивают цены AWS с Whole Foods.
• В итоге сходятся во мнении: костыль может работать, но рано или поздно придётся платить за правильное решение.

Генератор писем для Animal Crossing
Создаёт автоматические письма жителям.

• Выбираете жителя → тему (подарок, благодарность, приглашение).
• Генератор подставляет имя, стиль речи и эмодзи-иконки.
• Можно добавить предмет из инвентаря: письмо придёт с вложением.
• Поддерживаются шаблоны на русском, английском, японском.

• Пользователи в восторге от генератора писем в стиле Animal Crossing и делятся тёплыми историями о том, как отправили письма близким.
• IdreesInc удивлён внезапным наплывом сообщений и объясняет, что все «бутылочные» послания модерируются вручную через AWS.
• Найдены мелкие баги: теряются символы перевода строки при сжатии в ссылку, а слово stationary неправильно написано вместо stationery.
• Некоторые советуют сменить название и убрать «Tom Nook», чтобы избежать проблем с правообладателями.
• Появились ссылки на похожие инструменты: Death Generator и библиотека animalese для озвучки.

21 августа 2025
Инцидент Cloudflare ↔ AWS us-east-1

• 16:27 UTC — один клиент на AWS us-east-1 резко увеличил объём запросов к кэшу Cloudflare.
• Проблема — ответный трафик переполнил прямые линии пиринга между Cloudflare и AWS, вызвав высокую задержку, потери пакетов и сбои до origin-серверов.
• 19:38 UTC — влияние существенно снизилось; остаточные задержки до 20:18 UTC.
• Масштаб — только трафик между Cloudflare и AWS us-east-1; глобальные сервисы не пострадали. Это не атака и не BGP-хайджек, а перегрузка каналов.

Почему произошло

Cloudflare работает как обратный прокси: если контент не в кэше, запрос идёт к origin-серверу клиента. Внутренняя сеть рассчитана с запасом, но несколько edge-линков к AWS-оборудованию оказались недостаточны для внезапного скачка. AWS, пытаясь снять нагрузку, отозвала часть BGP-префиксов, что лишь перенаправило трафик на ещё более узкие каналы через офф-сайт интерконнект.

Что делаем дальше

1. Увеличим пропускную способность всех линков к AWS us-east-1.
2. Внедрим более агрессивное автоматическое шейпирование трафика, чтобы локальные перегрузки не распространялись.
3. Улучшим алгоритмы балансировки и отказоустойчивости между пиринговыми точками.
4. Добавим ранние оповещения и автоматические сценарии отключения «проблемных» клиентов при аномальном росте трафика.

Приносим извинения за неудобства и благодарим за терпение.

• Один клиент Cloudflare сгенерировал всплеск трафика, перегрузив каналы к AWS us-east-1 и вызвав отказ.
• Проблема усугубилась тем, что AWS автоматически отозвал BGP-маршруты, а резервные линии оказались недостаточными.
• Участники обсуждают необходимость пер-клиентских лимитов, rate-limiting на краю сети и улучшенной наблюдаемости.
• Некоторые считают, что единственное долгосрочное решение — уход из us-east-1 из-за хронических проблем масштабирования.
• Возникли шутки и догадки о том, кто именно был «тем самым клиентом».

Google и Meta заключили 6-летний контракт на облачные услуги стоимостью более $10 млрд. Ранее Meta в основном полагалась на AWS и Microsoft Azure, теперь расширяет партнёрство с Google Cloud. Сделка усиливает позиции Google в борьбе за крупных клиентов и отражает общий рост инвестиций в ИИ-инфраструктуру.

• Meta тратит $65B+ на собственные дата-центры, но пока они строятся, арендует мощности у Google как у «перестраховки».
• Сделка может быть просто объединением старых GCP-проектов в единый корпоративный контракт.
• Google нужен контракт, чтобы остановить отток клиентов и продемонстрировать спрос на свои TPUs.
• Meta ценит именно уникальные TPU Google, которых нет у AWS/Azure.
• Спор о «лучшем» облаке: одни считают GCP слабым, кроме BigQuery и Cloud Run, другие ставят GCP выше «ненадёжного» Azure.

• AWS CEO Матт Гарман назвал «глупейшей идеей» замену младших сотрудников ИИ.
• На конференции AWS Summit в Лондоне он объяснил: джуны учатся, наблюдая за опытными коллегами; без них не будет новых экспертов.
• Гарман подчеркнул, что ИИ — инструмент, усиливающий людей, а не заменяющий их.

• AWS CEO: нельзя заменять джуниоров ИИ — иначе через 10 лет не останется сеньоров.
• Участники сходятся: навыки «учиться учиться», критическое мышление и декомпозиция задач важнее любого кода.
• Опыт показывает: «вайб-кодинг» без людей быстро превращается в спагетти-ад без архитектуры и без роста команды.
• ИИ полезен как ускоритель для джуниоров, но не как их замена; иначе пропадёт естественный путь «intern → senior».
• Главный вывод: компании, которые сейчас экономят на обучении молодых, потом заплатят отсутствием экспертов.

Не выбирайте странные подсети для встраиваемых сетей, используйте VRF

Встраиваемая сеть — это, например, переносная стойка с видео- и сетевым оборудованием, которую подключают к сети площадки. Устройства внутри стойки должны общаться между собой, но перенастраивать их IP при каждой смене локации неудобно. Обычно добавляют маршрутизатор с NAT и используют простую подсеть вроде 10.0.0.0/24. Проблема возникает, если внешняя сеть площадки использует ту же подсеть — возникают конфликты. Люди начинают выбирать «редкие» диапазоны (172.16.42.0/24, 10.11.12.0/24), но конфликты всё равно случаются.

IPv6-решение
Использовать link-local адреса fe80::/64 и протоколы обнаружения (avahi). Маршрутизатор раздаёт маршруты, и внутренние устройства получают доступ в интернет. Недостаток: большинство встраиваемых устройств (аудио- и видеомикшеры) не поддерживают IPv6. Аналогичный IPv4-механизм APIPA (169.254.0.0/16) не даёт шлюза и интернета.

Универсальное решение
Вместо экзотических подсетей ограничьте «странность» настройками маршрутизатора. Используйте VRF (Virtual Routing and Forwarding), чтобы изолировать внутреннюю сеть и избежать конфликтов, не меняя адресацию устройств.

• Docker случайно выбирает подсеть RFC1918, которая может конфликтовать с корпоративной сетью; это частая проблема в AWS и вызывает головную боль при отладке.
• IPv6-поддержка всё ещё редка, поэтому обсуждают альтернативы: IPv4 link-local, CGNAT 100.64.0.0/10, «benchmark» 198.18.0.0/15 и даже выделение «мертвой» подсети.
• Некоторые просто используют VRF или VLAN, чтобы изолировать трафик и избежать конфликтов, хотя это требует понимания маршрутизации.
• Участники сомневаются, что IPv4 исчезнет скоро: у провайдеров его много, а стимул перехода на IPv6 минимален без внешнего давления.

• EC2

  • Менять IAM-роли и security-groups можно без остановки инстанса.
  • EBS можно расширять, подключать и отключать «на горячую».
  • Принудительный stop/terminate без ожидания таймаута.
  • Live-migration между хостами почти убрала деградацию инстансов.
  • Надёжность выросла: «исчезновение» инстансов стало редкостью.
  • Spot-рынок стал стабильнее, без аукционов.
  • Dedicated Instances почти не нужны — даже для HIPAA.
  • AMI Block Public Access включён по умолчанию.

• S3

  • Стал строго согласованным (read-after-write).
  • Не нужно рандомить префиксы ключей для равномерного распределения.
  • ACL устарели и отключены по умолчанию.
  • Block Public Access включён на новых бакетах.
  • Шифрование покоя включено по умолчанию.

• AWS теперь по умолчанию блокирует публичный доступ к новым S3-бакетам; это снижает утечки, но усложняет легитимное открытие доступа.
• Пользователи обсуждают, что многие «улучшения» AWS — это просто исправление первоначально неудобных решений, и это влияет на репутацию.
• По-прежнему спорны детали: нужно ли случайное префиксирование ключей S3, почему NAT Gateway взимается за трафик внутри одного региона и почему Transit Gateway дороже peering.
• Некоторые разработчели «деградируют» от сложных serverless-стеков к простым EC2 + S3 + Route 53 ради простоты и экономии времени на IAM.
• Участники просят ежегодные сводки изменений и жалуются на ослабление платной поддержки AWS.

Positron — бесплатный IDE для дата-сайенса, поддерживающий Python и R.
Скачать

Продукты

• Enterprise: Posit Connect, Workbench, Package Manager
• Cloud: Posit Cloud, Connect Cloud, shinyapps.io

Open Source

• IDE: Positron, RStudio, RStudio Server
• Библиотеки: Tidyverse, ggplot2, dplyr, Quarto, Shiny, vetiver
• Интеграции: dbplyr, sparklyr, googlesheets

Истории клиентов

• Suffolk, Trillium, Unity Health, NASA, Dow

Партнёры

• Платформы: Snowflake, Databricks, SageMaker
• Облака: AWS, Azure, GCP

• Пользователи хвалят Positron за плавный переход из RStudio/VSCode и улучшенные возможности DS, но жалуются на отсутствие inline-графиков в Quarto и медленное внедрение.
• Разработчики подтверждают: форк нужен, потому что VSCode-расширения не позволяют глубоко интегрировать языковые сервисы, тулбары и кастомные UI.
• Некоторые считают продукт «ещё одним форком VSCode» и сомневаются в его нишевости между RStudio, VSCode, Spyder и PyCharm.
• Поддержка WSL пока отсутствует, а цены на RStudio Server выросли, что усиливает интерес к Positron в академической среде.
• Важнейший запрос — inline-вывод в Quarto; его уже рассматривают, и есть настройка для привычных хоткеев RStudio.

Основы

• Определите цель: чётко сформулируйте задачу перед генерацией кода.
• Начинайте с README: описание проекта помогает ИИ и команде.
• Используйте шаблоны: готовые структуры (FastAPI, React) экономят время.

Промпты

• Контекст: указывайте язык, фреймворк, стиль (PEP8, camelCase).
• Мелкие задачи: дробите фичи на куски по 50–100 строк.
• Примеры: прикладывайте JSON-ответы или SQL-запросы.
• Итерации: улучшайте код по одному аспекту за раз.

Рабочий процесс

• Сессии: 30-минутные циклы «запрос-ревью-запуск».
• Git-коммиты после каждого шага для отката.
• Линтеры/тесты сразу: pytest, eslint, mypy.
• Code Review: проверяйте всё, даже «очевидное».

Инструменты

• Copilot Chat в IDE для быстрых правок.
• Cursor / Windsurf для многофайлового рефакторинга.
• Playwright для e2e-спек, сгенерированных из текста.
• Docker для воспроизводимого окружения.

Качество

• Типы: добавляйте аннотации (TypedDict, Pydantic).
• Док-строки: пишите для всех публичных функций.
• Тесты: покрывайте критические пути ≥80 %.
• Логи: структурированные (structlog) для отладки.

Безопасность

• Секреты: проверяйте .env и git history.
• OWASP Top 10: сканируйте зависимости (pip-audit, npm audit).
• RBAC: реализуйте роли и разрешения сразу.

Производительность

• Профилирование: cProfile, py-spy для горячих точек.
• Кеш: Redis для частых запросов.
• CDN для статики фронтенда.

Деплой

• CI/CD: GitHub Actions → Docker → ECS/Fargate.
• Feature flags для постепенного релиза.
• Мониторинг: CloudWatch + Grafana.

Советы

• Не доверяйте 100 %: всегда читайте сгенерированный код.
• Учитесь у ИИ: спрашивайте «почему так» для роста навыков.

• Подавляющее большинство участников считает «vibe-coding» либо вредным, либо вообще не тем, что описано в документе.
• Настоящий vibe-coding — это «не смотреть код, а принимать результат, если визуально работает»; любые советы «тщательно читайте код» противоречат самому термину.
• Многие предпочитают писать чёткие спецификации и использовать LLM как «парного программиста», но подчёркивают, что это уже не «vibe», а обычная работа с AI.
• Частый риск — накопление непонятного, неотрефакторенного кода и «отравление» контекста при изменении требований.
• Итоговый совет большинства: «Don’t go full vibe» — даже при активном использовании LLM нужно понимать и контролировать результат.

• Security: киберпреступность, патчи, исследования, CSO
• Off-Prem: edge + IoT, канал, PaaS/IaaS, SaaS
• On-Prem: системы, хранение, сети, HPC, персональные технологии, CxO, госсектор
• Software: ИИ + ML, приложения, БД, DevOps, ОС, виртуализация
• Offbeat: дебаты, колонки, наука, юмор, юр. новости, блоги
• Спецпроекты: месяц облачной инфраструктуры, сети ЦОД, хранение, европейские суперкомпьютеры, ИИ-инфраструктура, RSAC, разработка ИИ, аварийное восстановление, GTC Nvidia, ransomware, будущее ЦОД, кибербезопасность, VMware Explore
• Vendor Voice: Siemens + AWS, Mendix + AWS, финансовые потоки, BigQuery, AWS Global Partner Security, GE Vernova
• Ресурсы: whitepapers, вебинары, рассылки

• Все, что вы отправляете в онлайн-сервисы (AI, почта, соцсети), сохраняется навсегда и может быть использовано против вас.
• Большинству пользователей всё равно: удобство «бесплатных» сервисов перевешивает риски.
• Есть альтернатива — локальные модели (Ollama, LM Studio, Oobabooga), но они требуют мощного железа и навыков.
• Даже если вы не пользуетесь сервисом, друзья могут передать ваши данные через чат-ботов.
• Пока не появится жёсткое регулирование, единственный надёжный способ — не делиться чувствительной информацией и минимизировать использование облачных AI.

Codemia
Подготовка к систем-дизайн-интервью через практику:
Начать | Блог | Системный дизайн

Юридика
Условия | Конфиденциальность | Контакт

Соцсети
Twitter | LinkedIn

• Обсуждение подтверждает: для HPC, высоконагруженных и чувствительных к задержкам систем NUMA-распределение критично, и ручное pinning процессов/потоков к нужным узлам остаётся основным способом добиться стабильной производительности.
• В публичных облаках (AWS, GCP) NUMA-топология скрыта, VM часто выглядят как однонодовые UMA; полезны lscpu, lstopo, cpu-latency, но настроек управления NUMA почти нет.
• Сообщество делится инструментами: mpibind, sched_ext, DAMON, fake NUMA, идеями эмуляции NUMA даже на Raspberry Pi 5.
• Kubernetes уже умеет NUMA-affinity, но вручную выбирать 64-ядерный инстанс вместо 96-ядерного (чтобы не пересекать сокеты) всё равно приходится самим.
• Крайняя альтернатива — односокетные серверы с NPS=1: «равномерно медленно», но без головной боли.

Год в корпорации
18 августа — ровно 12 месяцев в $ENTERPRISE. До этого десятилетие в стартапах и SME. Решил «продаться» ради денег и приключений.

Что раньше не было проблемой, теперь — непроходимое болото

Первый PR: красный билд из-за $TOOL.
— «Спроси у владельца».
— «Кто это?»
— «Не знаю».

Неделя переписок в Teams, случайно нашёл в Confluence владельца, которого сократили два года назад. Инструмент живёт сам по себе, глотает тысячи, но никто не поддерживает. Решение: одна строчка в конфиге, игнорируем всё.

В стартапе: «Кэрол, что за $TOOL?» — «О, видела, вот как…»

Скупердяйство на миллионы

Видел, как команды из 3-4 человек на бюджете, который здесь теряют в диване, решали реальные задачи. Здесь:

• пенсия улетела за две недели на обречённый проект;
• AWS-вилла Безоса из-за нагрузки, которую Raspberry Pi бы осилил;
• часы споров о SaaS за $100/мес;
• двухлетний проект закрыли перед релизом «чтобы сэкономить»;
• заявка на мышку — отказано.

Коллеги — лотерея

В малой компании некомпетентных быстро увольняют. В $ENTERPRISE увольняют только «по сокращению». Результат:

• глава техотдела не умеет пользоваться компьютером;
• аналитик не говорит по-английски;
• отчёты полны «—», но все делают вид, что нормально.
  Упоминать слона в комнате невыгодно.

Срочность как фетиш

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

• Пользователи подтверждают: в крупных корпорациях главное — стабильная зарплата и «чеки не отскакивают», особенно после 40 и при наличии семьи.
• Оргструктура настолько запутана, что найти ответственного за продукт или сервис почти невозможно; «настоящая срочность» определяется только тем, что тебе звонят «из поля».
• Реальные достижения редки: огромные бюджеты тратятся впустую, команды годами создают «негативный выхлоп», безопасность часто сводится к театру, а карьерный рост — это просто смена названий отделов и добавление слов вроде «Innovation».
• Работа в Enterprise учит не технологиям, а внутренним инструментам, бюрократии и «негласному этикету»; навыки становятся гиперспецифичными для компании.
• Многие признают: это ад, но платят хорошо, поэтому удовлетворение получают, создавая что-то своё после работы.

Porffor — экспериментальный JS-движок, компилирующий код в WebAssembly и нативные бинарники. Вместо упаковки рантайма (как Node/Bun) он генерирует крошечные (<1 MB) и быстрые (миллисекунды) исполняемые файлы.

porf native hi.js hi   # 12.9 KB
./hi                   # 631 µs

Сравнение с Deno/Bun: размер 16 KB против 80–100 MB, старт в 631 µs против 15–37 ms.

Lambda

На AWS Lambda Porffor показал:

• Node (baseline): до 300 ms холодного старта.
• LLRT: ~3× быстрее Node, но дороже из-за отсутствия managed runtime.
• Porffor: ~12× быстрее Node и ~4× быстрее LLRT, при этом дешевле даже с учётом «managed runtime» Node.

P99 Porffor быстрее P50 у конкурентов.

Итог

Porffor ещё pre-alpha: поддержка JS ≈60 %, нет I/O и Node-совместимости. Подходит для маленьких лямбд без Node-API.
Код и данные бенчмарков: GitHub.

• Porffor — экспериментальный AOT-компилятор JS/TS → WASM → C, обещает убрать «холодные» старты Lambda и дать ~16 мс инициализации, но пока без GC, без полной совместимости с Node API и лишь ~60 % тестов ECMAScript проходит.
• Участники спорят, насколько критичны 200-600 мс холодного старта: кто-то считает проблемой для миллионов мелких запросов, кто-то — редким неудобством, решаемым резервными инстансами или переходом на Go/Rust.
• Сомнения в зрелости: «раньше быстро, пока не реализуешь оставшиеся 20 % фич»; безопасность и поддержка всей экосистемы JS вызывают скепсис.
• Плюсы: возможность компилировать в маленькие бинарники, использовать WASM-рантаймы, обходиться без JIT и доверять «своему» коду.
• Минусы: нет GC (хотят прикрутить WasmGC или Fil-C), нет I/O и полной Node-совместимости, корпоративные пользователи опасаются «экспериментов».

Двухуровневая модель

Основной агент ведёт диалог, помнит контекст, раздаёт задачи.
Под-агенты — чистые функции: получили вход, вернули результат, забыли всё.
Больше двух уровней — лишние точки отказа.

Под-агенты без состояния

Каждый вызов — как вызов функции:

• одинаковый вход → одинаковый выход
• легко кешировать, тестировать, запускать параллельно
  Пример сообщения:

{"task": "sentiment", "data": [...], "constraints": {"timeout": 5}}

Разбиение задач

• Вертикальное: последовательные шаги (сбор → извлечение → сравнение).
• Горизонтальное: параллельные ветки (исследовать 5 конкурентов одновременно).
  Смешиваем: сначала параллельная категоризация фидбека, потом последовательная приоритизация.

Протокол общения

Каждая команда содержит:

• цель, входные данные, ограничения, формат вывода.
  Ответ: status, result, confidence, processing_time.
  Болтовни и «помни, что мы обсуждали» — нет.

Специализация агентов

• Research — поиск по базе фидбека.
• Analysis — извлечение тем и настроений.
• Summary — генерация отчётов и changelog.
  Один агент = одна чёткая функция.

Оркестрация

• Round-robin — когда порядок важен.
• Priority queue — сначала критичные фидбеки.
• Fan-out/fan-in — параллельные под-агенты, потом сбор результатов.
  Состояние хранит только основной агент; под-агенты не знают о существовании друг друга.

Управление контекстом

• Сжатие: оставляем только релевантные куски.
• Слайды: отправляем под-агенту только нужную подборку.
• Версионирование: каждый результат имеет id, чтобы легко откатиться.

Обработка ошибок

• Повторы с экспоненциальной задержкой (до 3 раз).
• Fallback-агенты: если «анализатор» упал, включаем «резервный».
• Circuit breaker: после N ошибок отключаем агента и пишем алерт.

Производительность

• Кешируем по хешу запроса.
• Параллельные вызовы без блокировок.
• Пакетная обработка: отправляем 50 фидбеков за раз, а не по одному.

Мониторинг

Отслеживаем:

• latency под-агентов,
• точность (сравниваем с разметкой),
• частота ошибок,
• объём контекста (токенов).
  Всё пишем в Prometheus + Grafana.

Уроки из продакшена

• Начинайте с 2–3 под-агентов, добавляйте постепенно.
• Пишите юнит-тесты для каждого под-агента.
• Не давайте агентам доступ к внешним API без rate-limit.
• Держите промпты в git; версионируйте как код.

Принципы

1. Простота > масштаб.
2. Чистые функции > разделяемое состояние.
3. Структурированные сообщения > свободный текст.
4. Мониторинг с первого дня > дебаг в проде.

Частые ошибки

• «Умные» под-агенты с памятью → гонки и непредсказуемость.
• Слишком большой контекст → таймауты и лишние токены.
• Отсутствие таймаутов → зависшие цепочки.
• Игнорирование кеширования → лишние $$$ на API.

Как начать

1. Определите 1–2 ключевые задачи (например, «суммаризировать фидбек»).
2. Создайте под-агентов: research, summarize.
3. Напишите структурированные схемы входа/выхода.
4. Покройте тестами, добавьте метрики.
5. Подключите к реальному потоку данных и наблюдайте.

• Автор делится опытом построения практичных «агентов» как чистых функций без состояния и истории разговоров, что экономит токены и упрощает отладку.
• Поддержка: дешёвые/локальные модели на 75 % задач, жёсткое разбиение на под-агентов, явное описание шагов вместо «умных» решений.
• Критика: часть читателей считает описанное не настоящим агентством, а обычным workflow с LLM-вызовами; стиль текста вызывает раздражение как «AI-generated».
• Практические инструменты: Claude Code (файлы .claude/agents), AWS Lambda + Step Functions, Spring AI, кеширование промптов.
• Сообщество обсуждает, где грань между «агентом» и «инструментом», просит примеров и данных, а также делится ссылкой на оригинальный пост Anthropic.