Hacker News Digest

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.

Разработчики создали формат blockdiff для мгновенных снапшотов дисков виртуальных машин, сократив время создания с 30+ минут на EC2 до нескольких секунд — ускорение в 200 раз. Это стало возможным благодаря хранению только изменённых блоков данных, что экономит место и ускоряет операции. Формат работает поверх CoW-механизмов XFS в Linux, обеспечивая нулевые накладные расходы и мгновенное создание снапшотов без полного сканирования диска.

Ключевые применения включают сохранение сред разработки, быстрое пробуждение ВМ из сна и откат изменений. Решение обошло ограничения бинарных диффов и OverlayFS, предложив простую и надёжную реализацию на Rust. Открытый исходный код доступен на GitHub, что позволяет сообществу адаптировать инструмент для схожих задач.

• Удивление отсутствием рассмотрения формата QCOW2 и технологии тонкого provisioning VDO с LVM2 для решения аналогичных задач.
• Вопросы о выборе XFS вместо ZFS/BTRFS, использовании LVM-снимков и возможности интеграции решения с другими гипервизорами и файловыми системами.
• Обсуждение технических деталей реализации: использование флагов для синхронизации файлов, поддержка copy_file_range в qemu-img, сравнение с OverlayBD.
• Интерес к применению технологии для ускорения подготовки виртуальных машин в CI/CD и публичном облаке.
• Замечания о необходимости альтернативного текста для изображений и выбора лицензии для проекта.

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 легко «перепишут» проект и ограничения лицензии станут бесполезными.

• 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.