Hacker News Digest

В 2026 году автор запустил коммерческий веб-сервис — marketyour.games — полностью на C через CGI, без фреймворков, контейнеров или отдельного сервера баз данных. Стек: OpenBSD, httpd, SQLite и статически скомпилированный бинарник. Все активы встроены в исполняемый файл, запросы обрабатываются через fork-процессы, а обновление — заменой одного файла без простоя. Использованы только три библиотеки: libcurl, libsodium и libcjson (включён как один файл), SQLite — в виде амальгамации. Система работает без JavaScript, поддерживает Stripe, Postmark и пользовательские аккаунты, при этом полностью изолирована через pledge, unveil и chroot.

Преимущества — полная прозрачность: нет слоёв абстракции, отладка — как у обычной программы через gdb, HTTP-логика проста и неизменна с 2004 года. SQLite устраняет необходимость в управлении сервером БД. Недостаток — отсутствие базовых утилит: автор сам написал cgi.h для обработки кук, параметров и валидации, но хотел бы стандартных библиотек в стиле stb. CGI не устарел — современные ядра эффективно оптимизируют fork, а FastCGI остаётся простым шагом вперёд. Стек оказался проще, надёжнее и легче в поддержке, чем любые современные решения.

Чистый C‐CGI‐подход прост, но в реальных проектах требует дополнительных мер: наблюдаемости (метрики, логирование, алертинг отсутствуют), конкурентного доступа к SQLite (каждый запрос открывает отдельный процесс, риск блокировок при записи), безопасности (уязвимости, риск RCE — нужна проверка кода и дополнительная защита) и удобства деплоя. Альтернативы: Go‐бинар без CGO (всё в одном файле, удобен для контейнеров), Rust‐фреймворки (Tokio, Actix — безопасность и производительность без проблем с памятью), FastCGI на C (стабильно работает, например, на FreeBSD с PostgreSQL). Простота архитектуры выигрывает в небольших проектах, но минимализм требует компромиссов. BusyBox содержит CGI‐bin — позволяет быстро развернуть веб‐интерфейс без отдельных серверов. Nginx не поддерживает CGI из коробки — нужен сторонний модуль или Lighttpd. Исторически в 1990‐х CGI‐скрипты писали на Perl, а не на C. Для безопасности C‐кода полезны инструменты вроде Fil‐C (проверка памяти). Отсутствие примеров кода в статье усложняет понимание — полезно добавить демонстрации запросов и ответов. Критика простоты C‐подхода в обсуждении почти отсутствует — возможно, недостаточно обсуждены потенциальные проблемы. Bash‐скрипты показывают минималистичный веб‐сервер, но не подходят для продакшна.

Talorys — это личный AI-агент, который развёртывается полностью в вашем собственном Cloudflare-аккаунте через одну команду npx create-talorys@latest. Он работает без внешних серверов, баз данных или телеметрии, используя только ресурсы Cloudflare: Pages для фронтенда, Durable Object для хранения состояния и Workers AI для генерации ответов. Агент поддерживает чат с потоковыми ответами, долговременную память (только релевантные факты передаются модели), управление задачами, заметками и проектами, а также автоматизации — напоминания и рутины, запускаемые через alarms Durable Object, поэтому ничего не нужно держать онлайн постоянно.

Система спроектирована для одного пользователя: при установке задаётся пароль владельца, а авторизация происходит в воркере, не на фронтенде. Даже если quota Workers AI исчерпана, функции задач, памяти и напоминаний продолжают работать. Обновление выполняется той же командой — оно переразвёртывает код, сохраняя данные, пароль и сессии благодаря append-only миграциям SQLite в Durable Object. Всё взаимодействие браузера ограничено вашим *.pages.dev сайтом, а /api-запросы проксируются через service binding к приватному воркеру без публичного URL.

В ходе обсуждения возник спор о термине «self-hosted»: одни считают его применимым к облачным ресурсам под собственным управлением, другие — только к физическому контролю над оборудованием. Поскольку Cloudflare контролирует инфраструктуру и логи, многие полагают, что название Talorys вводит в заблуждение, и предлагают заменить его на «self-managed» или «hosted on Cloudflare». Также предложено разделить понятия на «self-running» (собственное железо) и «self-hosting» (управление развертыванием). Особенности использования Cloudflare: — Workers AI слишком медленен для интерактивного чата. — Durable Objects эффективны для хранения состояния агента благодаря мгновенному пробуждению и интеграции данных без внешних баз. — Бесплатный тариф (Free Tier) ненадежен из-за риска внезапного отзыва. — Пользователь @hung предупреждает о скрытых списаниях в AI-тарифе и игнорировании обращений поддержкой. Технические замечания и советы: — @vlovich123 отметил, что замена Workers AI на локальную модель занимает менее 20 минут и не меняет архитектуру. — @andrewdb выявил отсутствие семантической памяти (агент не учитывает контекст, например, вегетарианство) и предложил внедрить семантическое извлечение. — @ahel указал, что чат-интерфейс не всегда приносит значимую пользу. Talorys не требует сторонних сервисов, кроме аккаунта Cloudflare, что делает его примером «open-source, vendor-locked» решения: независимого от разработчика, но зависимого от платформы.

Supabase приобретает Turso, чтобы совместно построить инфраструктуру, способную поддерживать рост спроса на базы данных, вызванный ростом агентного ИИ. Агенты сейчас создают миллионы баз в неделю для прототипов, дашбордов и приложений, и текущая инфраструктура не справляется с таким масштабом. Цель — сделать создание баз данных таким же простым и дешёвым, как создание файла: без необходимости выделения dedicated-машин для малых нагрузок, с мгновенным доступом и плавным переходом в продакшен.

Turso уже реализовал именно такую архитектуру: переписал SQLite на Rust и построил облачную платформу, где один сервер может управлять миллионами баз, загружая их по требованию и приостанавливая при простое. Это позволяет provisioning баз для каждого агента по требованию — как в Turso Cloud, так и в собственных облаках клиентов (Superhuman, Sauna.ai, CTO.new, Mastra). Supabase продолжит развивать Postgres для масштабируемых приложений, Turso — SQLite для лёгких нагрузок, а вместе они обеспечат единый developer experience от прототипа до продакшена. Команда Turso во главе с Glauber Costa присоединяется к Supabase, чтобы вести это направление. Ничего не меняется для существующих пользователей: оба продукта продолжают развиваться независимо, но теперь с общей стратегией поддержки агентного будущего.

Пользователи рады покупке Turso Supabase и ожидают ускорения развития проекта благодаря новым ресурсам. Однако они сталкиваются с реальными проблемами: низкой производительностью при работе с ClickBench (загрузка данных 4 KB/s, зависания), задержками более 100 мс в некоторых регионах и отсутствием автоматического мониторинга, что привело к уходу части пользователей. Команда Supabase признаёт эти проблемы, но считает их не приоритетными. Ведётся спор о целесообразности замены SQLite: одни считают это бессмысленным и рискованным из-за проверенной надёжности SQLite, другие видят в Turso улучшенную версию с потенциальной совместимостью с Postgres. Некоторые советуют сохранять SQLite в текущем виде, чтобы избежать новых багов. Есть положительные отзывы о Turso в Rust‐проектах — хорошая производительность при асинхронных запросах. Также обсуждается необходимость базы для агентного ИИ, поддерживающей SQL, векторный поиск и графовые запросы, которой atualmente не обладает SQLite, поэтому Turso рассматривается как потенциальное решение. Однако некоторые сомневаются в нужде отдельной инфраструктуры для агентного ИИ. Существуют опасения, что открытый код Turso может стать закрытым после поглощения Supabase, и вопросы о финансовой устойчивости проекта.

Pi Durable — это фреймворк для создания долгоживущих, устойчивых к сбоям и гибких агентов, способных работать в любой среде с JavaScript-рантаймом. Он не заменяет Pi как код-агента, а предоставляет универсальную основу для построения агентных приложений, включая самого Pi. Фреймворк построен на принципах минимализма и изменяемости, делится кодом с Pi (например, pi-ai), и позволяет экспериментировать с новыми архитектурами без риска для основного продукта. Весь исходный код без тестов составляет около 15 000 строк (150–250 тыс. токенов), но для большинства задач достаточно меньшей части — например, хранилища занимают всего 3 000 строк и легко подменяются.

Харнесс в Pi Durable — это сочетание хранилища и механизма для параллельного запуска множества разговоров с LLM. Он предоставляет инструменты, которые модели могут вызывать, и среды их выполнения (локальная машина, удалённая VM, песочница). Разговор — это транскрипт взаимодействия пользователя с агентом (LLM + настройки + инструменты). Каждый вызов модели или инструмента — это задача. Хранилище может быть in-memory, SQLite или JSONL, с возможностью подключения собственных бэкендов через простой интерфейс. На SQLite активные данные (транскрипты, задачи, отправки) держатся в памяти, а остальное — на диске, что обеспечивает эффективность и устойчивость к сбоям. Один процесс владеет хранилищем, другие клиенты подключаются к нему.

Pi Durable поддерживает бесконечно длинные диалоги, выживает при катастрофических сбоях и позволяет нескольким людям управлять одним агентом одновременно. Пример — агент для планирования отпуска (~1300 строк TypeScript, mostly TUI), который демонстрирует параллельный поиск (погода, музеи, поезда), устойчивость к перезапуску (только незавершённые задачи повторяются), переключение между суб-агентом и главным, и автоматическое формирование плана из результата. Для запуска достаточно собрать проект и выполнить две команды; для использования в своих проектах — установить три пакета через npm. Выбор TypeScript обусловлен простотойbootstrap, но порт на Rust или ассемблер не исключён в будущем.

Обсуждение подтверждает практическую ценность Pi Durable для длительных задач: аналитика, мониторинг cron‐задач, автоматическое создание PR и ежедневный триаж алертов. Pi Durable не предоставляет встроенный sandbox; разработчики должны подключать собственный (например, Gondolin от Earendil) в соответствии с политиками. Спор: одни считают фреймворк должен быть sandbox‐агностичным, другие видят отсутствие first‐class sandbox‐а недостатком. Разговоры в Durable реализованы как линейный список записей с указателем на предшествующий (fork); ветвление дерева заменено плоской структурой. requestId используется как ключ идемпотентности для exactly‐once, но некоторые считают, что одного ID недостаточно. Токенизация кода зависит от модели: 15 000 строк ≈ 150 000 токенов GPT и 250 000 токенов Claude. Создание хранилища, координирующего несколько экземпляров vanilla Pi, сложно и может превзойти выгоды от durability. Для синхронизации внешних хранилищ с состоянием разговора рекомендуется задача‐синхронизатор (например, SyncToPostgres). Многопользовательский режим отмечен как важный плюс для удалённых контрольных инструментов. Durability достигается хранением JSON‐документов локально и минимизацией объёма данных в памяти. Совет: не «запекать» инструменты по умолчанию; лучше предоставить профиль с опцией включения нужных. Совет: добавить полити‐движок для sandbox‐ов (например, интеграция с NVIDIA openshell). Pi Durable позиционирует себя как более агностичный по сравнению с LangChain, Vercel Eve, OpenAI Agents и другими решениями. Вопрос синхронизации состояния агента и состояния VM/контейнера остаётся открытым. Жалобы на читаемость шрифта кода в статье не относятся к техническим аспектам.

Маленькие знания часто дают большой эффект в повседневной работе инженера. Например, ctrl + r в терминале можно улучшить с помощью fzf для нечёткого поиска истории или atuin, который хранит историю в SQLite и позволяет искать по директориям. В SQL можно выполнять SELECT без FROM — удобно для тестирования функций или проверки выражений вроде SELECT TRUE <> NULL. Для оптимизации запросов в PostgreSQL и MySQL полезно EXPLAIN ANALYZE, которое выполняет запрос и показывает детальную производительность. В регулярных выражениях \b помогает находить границы слов, а логарифмы удобны для bucketing метрик — например, Math.floor(Math.log10(count)) группирует значения по порядкам величины. В современном JavaScript полезны Array.flatMap, Object.entries и Promise.withResolvers, а в Node.js — повторное использование HTTPS-соединений через https.Agent, что снижает латентность. В Git: git log -S pattern ищет коммиты, где строка была добавлена или удалена («git pickaxe»), git checkout - переключается на предыдущий HEAD, а вместо find часто достаточно **/*.md при включённом globstar в Bash. Для поиска по содержимому файлов лучше использовать rg (ripgrep), а в Zsh стоит включить автодополнение через compinit и настроить FPATH для функций от Homebrew. Эти приёмы не требуют глубоких знаний, но экономят время и снижают когнитивную нагрузку. Аналогично в компаниях ценны небольшие внутренние лайфхаки: какой источник данных смотреть при проблеме, кто эксперт в определённой области, где лежит документация по сложной теме, когда нужно вручную масштабировать систему, какая команда делает rolling restart, какой утилитой удобно скриптировать рутинную задачу. Один такой совет в день — достаточно, чтобы не перегружать команду, но полезно для тех, кто ещё не знал этого трюка. Даже если вы знаете 9 из 10, десятый может сэкономить час работы и спровоцировать полезное обсуждение. Старшим инженерам стоит делиться такими знаниями — они формируют культуру эффективной работы.

Эффективность мелких трюков зависит от привычки и системного закрепления, а не от их наличия. Инженеры годами используют неоптимальные методы из-за привычки и лени, несмотря на знание более быстрых альтернатив. Записывайте полезные трюки в легко доступный документ — это помогает вспомнить их при необходимости, не полагаясь на память или поиск в интернете. Размещайте чит-листы на стене или в рабочем пространстве — физическое присутствие подсказок повышает вероятность их применения. Создавайте bash-алиасы или скрипты, которые 'порицают' за использование устаревших команд — это формирует новую привычку (как @lelandbatey с git switch). Храните редко используемые, но важные команды в файле типа ~/scratch.txt с grep-доступом — это надежнее, чем история shell. Используйте zoxide вместо cd — он запоминает частые директории и позволяет прыгать между ними без цепочек ../.. (как @disinterred). Используйте zhist для улучшенного поиска истории Zsh с контекстом — он лучше стандартного fzf (как @overflowy). Сохраняйте полезные команды в Makefile или инструментарии приложения — это делает их воспроизводимыми и устраняет необходимость вводить их вручную (как @cachvico). Пишите полезные трюки на собственном сайте — это делает их долговечными и удобными для обмена (как @AJRF). Изучайте трюки, наблюдая за тем, как AI выполняет задачи — часто AI использует неизвестные вам команды (например, в perf, как @kccqzy и @SebasDev). Спор: Некоторые считают, что трюки вроде SELECT без FROM зависят от СУБД — например, IBM-продукты могут не поддерживать это (как @rf15). Спор: Некоторые считают, что эти трюки — не программирование, а администрирование или CLI-навыки (как @ozim и @1vuio0pswjnm7). Спор: Некоторые считают, что трюки устаревают из-за AI — например, @bufordtwain и @monideas считают, что AI делает их менее полезными. Используйте git ls-files вместо find для поиска файлов в репозитории — это быстрее и точнее (как @lucasoshiro). Используйте rg --hidden -g '!*.lock' для фильтрации шума в поиске — это эффективно для повседневной работы (как @ahmedhossamdev). Используйте pbcopy на macOS для копирования вывода команды в буфер обмена — это ускоряет работу с API-ответами (как @okinternets).

Capsule — это инструмент, который упаковывает полноценное приложение — интерфейс, данные и логику — в один портативный файл с расширением .capsule. Он работает полностью офлайн, без облака, регистрации или подписок: всё хранится локально внутри файла, включая пользовательский интерфейс на HTML/CSS и локальную базу данных SQLite. Такой файл можно отправить как обычный документ — через WhatsApp, AirDrop или email — и при открытии на другом устройстве он мгновенно запускается с уже загруженными данными, готовый к использованию.

Формат основан на открытых веб-технологиях, что исключает привязку к конкретным вендорам и обеспечивает кроссплатформенность: один и тот же .capsule файл запускается на macOS, Windows и Linux без конвертации. Поддержка iOS и Android планируется в ближайшее время. Capsule позиционируется как бесплатное решение для создания личных инструментов — трекеров, портфолио, заметок — с полным контролем над данными и нулевой зависимостью от сети или серверов. Для работы достаточно установить хост-плеер под свою ОС, после чего любые .capsule файлы становятся исполняемыми приложениями в один клик.

Концепция Capsule решает проблему распространения интерактивных приложений с локальным состоянием без сервера, что актуально для малых групп и AI-генерации в условиях стремления к автономности и контролю над данными. Формат, объединяющий UI, логику и данные (SQLite) в одном файле, позволяет создавать «умные документы» по аналогии с Jupyter Notebook, MS Access или Lotus Notes. Подобные идеи уже реализованы в проектах uapp, Decker и sqlar. Однако решение вызывает критику: 1. **Дистрибуция и доступность**: необходимость установки проприетарного клиента усложняет запуск по сравнению с полноценными приложениями или использованием File System Access API в браузерах. Для массового принятия требуется нативная поддержка браузерами. 2. **Синхронизация и совместная работа**: отсутствие механизмов слияния изменений при редактировании разных копий файла ведет к конфликтам и потере данных. Ручная пересылка файлов менее эффективна, чем веб-хостинг. 3. **Безопасность и надежность**: закрытый формат и клиент вызывают недоверие. Для аудита необходим просмотр исходного HTML/JS и схемы SQLite перед запуском, чтобы исключить вредоносный код. Также SQLite в одном файле уязвим к повреждениям при некорректном завершении работы, что не надежнее IndexedDB. Из-за проблем с управлением, безопасностью и отсутствием прозрачности концепция плохо масштабируется на корпоративные среды.

Open Executive — это система виртуального исполнительного руководства, построенная на восьми специализированных агентах Claude (CSO, CFO, CHRO, GC, COO, CMO, CPO, Director of Board Communications), которые работают за кулисами, но отвечают единым, согласованным голосом старшего исполнителя с уровнем знаний Harvard MBA. Система использует архитектуру RAG: каждый запрос проходит через Executive Orchestrator (claude-sonnet-4-6), который параллельно вызывает специалистов, извлекающих релевантный контекст из двух слоёв — встроенной MBA-базы знаний (в ChromaDB, git-tracked) и загруженных пользователем корпоративных документов (в отдельной коллекции company_docs). После генерации ответа фоновый процесс claude-haiku-4-5 сохраняет ключевые решения и инициативы в SQLite как эпизодическую память, которая подгружается в начало следующей сессии в блоке <past_decisions>. Также есть встроенный планировщик для проактивных напоминаний о времени чувствительных действиях.

Для расширения системы под новые домены требуется: добавить alias в DOMAIN_ALIASES, разместить Markdown-документы в knowledge/builtin/your_domain/, подготовить минимум два сценария оценки в evals/scenarios/ и отправить PR — CI проверяет наличие всех компонентов. Оценка качества проводится через набор из 29 сценариев, где claude-opus-4-7 выступает в роли LLM-as-judge по пяти измерениям (коherence persona, domain accuracy, использование контекста компании, качество маршрутизации, actionability), требуя среднего балла ≥3.5/5; падение любого измерения более чем на 10% относительно main блокирует PR. Все пользовательские данные (профиль YAML, загруженные файлы, ChromaDB) хранятся локально и игнорируются git, никогда не покидая устройство или приватный том в облаке, кроме как в промптах, отправляемых в Anthropic API, которые не используются для обучения моделей. Лицензия — Apache 2.0.

Тред воспринимает проект преимущественно как шуточный PR-ход и сатиру на замену разработчиков AI. Главное добавление дискуссии — концептуальное: @Animats выделяет это как новый класс «corporate-level AI» (организация из агентов), а не «human-level AI», и сравнивает с Gas Town и подходом «Fences, not Sandboxes». Скептики (@janalsncm, @walrus01) указывают на практические минусы — высокая стоимость токенов и качество ответов на уровне обычного ChatGPT. @reillyse возражает против самой посылки тредa: роль CEO — защищать капитал, а не отвечать на вопросы, поэтому замена AI нерелевантна.

• Спор: @reillyse спорит с доминирующим нарративом треда: CEO должен «исчезнуть на год» без ущерба для компании, его функция — защита инвестированного капитала, а не ответы на вопросы; поэтому AI-замена бьёт мимо цели. Большинство же (@Animats, @theodorewiles, @drTobiasFunke) считают, что AI лучше справится с обзором данных и принятием решений, чем люди-CEO.

• Почти все сходятся, что проект — это сатира и PR-жест, а не рабочий инструмент: @hypfer называет это «petty performative PR stunt», @janalsncm не видит преимущества над ChatGPT из коробки, @walrus01 предупреждает о раздувании счёта за Anthropic-токены.

• Несколько комментаторов (@Animats, @theodorewiles, @arjie) сходятся, что реальная ценность — не «AI-CEO», а AI как структурированный корпоративный decision-maker с прозрачной историей решений; @yunnpp добавляет, что auditable executive сам по себе — это новинка.

• Совет: @thelastgallon советует продвигать замену CEO через shareholder resolutions с готовыми промптами, предлагая формат SKILLs.md для инициативы.

• Совет: @dchftcs предлагает конкретный сценарий: технари, застрявшие в низкоуровневых задачах, должны использовать AI, чтобы подняться до product/decision-making ролей и конкурировать с текущими CEO.

• Спор: @Animats утверждает, что multi-agent «организационный» AI — это новая важная категория, требующая внимания, хотя такие системы «expensive to operate» из-за внутренних коммуникаций агентов. @walrus01 подтверждает высокую стоимость токенов, но это скорее практическая претензия, чем возражение по существу.

• @edoceo, @drTobiasFunke, @bwhiting2356 отмечают, что часть функций CEO (vision, prioritization, координация, data-driven decisions) теоретически воспроизводима AI, но @bwhiting2356 возражает: high-order strategy, relationship building и управление людьми будут автоматизированы последними.

• Совет: @chanux предлагает обратный эксперимент: пусть C-suite попробует управлять только с AI и посмотрит на результат, чтобы сравнить с гипотезой AI-CEO.

• Спор: @holoduke жалуется на разрыв между «gold plated stories» об автономных агентах и реальностью: он сам использует AI весь день, но ни разу не видел полностью рабочую замену команды людей — это прямой прод-опыт против хайпа.

• Ряд комментаторов (@arjie, @nullorempty, @matheusmoreira) распространяют идею замены дальше: на worker cooperatives, политиков, чиновников — аргумент, что AI не подвержен компромату и bias-у.

• @__MatrixMan__ ставит экспериментальный вопрос: если компании под управлением людей систематически проигрывают AI-управляемым, это говорит больше об AI или о том, как власть коррупционирует людей — прямого ответа в треде нет.

Идея заменить ELF-формат исполняемых файлов на SQLite — не шутка, а прототип под названием SELF, где сам файл — это SQLite-база, которую можно запускать как обычную программу. Вместо readelf и objcopy теперь можно писать SQL-запросы: SELECT name FROM elf_symbols или SELECT soname FROM ldd, чтобы узнать зависимости. Формат хранит все метаданные — символы, секции, зависимости — как таблицы, а не как бинарные структуры, что делает анализ и модификацию тривиальной задачей.

ELF на самом деле уже похож на базу данных — он вручную реализует индексы, строковые интернирование и внешние ключи, но без схемы и надёжности. SELF использует встроенную стабильность SQLite: изменения вроде LD_PRELOAD становятся транзакциями — можно вставить строку в таблицу preload, запустить программу, получить другой результат, а потом откатить всё одним ROLLBACK. Это позволяет атомарно перехватывать функции везде в системе без пересборки. Прототип работает с glibc, поддерживает конвертацию ELF ↔ SELF и даже запускается в NixOS-виртуальной машине. Nix даёт возможность перестроить мир — и SELF показывает, как можно переписать фундаментальные соглашения операционных систем.

Идея использования SQLite в качестве формата исполняемых файлов (SELF) интересна как попытка унификации метаданных, но практически необоснованна: ELF уже структурирован, но жёстко привязан к конвенциям — SQLite не решает его основную проблему, а добавляет избыточность. Существующие инструменты (osquery, nushell, виртуальные таблицы над /proc) и форматы (PE/COFF, .NET) уже обеспечивают структурированный доступ к системным данным без изменения формата исполняемых файлов. SQLite упрощает манипуляции с ELF-секциями по сравнению с objcopy/readelf, но не оправдывает замену ELF — особенно из-за невозможности эффективного mmap BLOB-данных из-за структуры страниц, что критично для исполняемых файлов. Для SELF требуется загрузчик, преобразующий его в ELF — приемлемо для демонов, но не для коротких утилит. Удаление метаданных через sstrip уже распространено, так как секционная таблица не обязательна для загрузки. Идея напоминает проваленные WinFS, AS/400 и PICK — это не техническая, а системная проблема: унификация на уровне формата не решает архитектурных ограничений. SELF не добавляет распределённости или транзакционности, в отличие от DBOS. Реальное внедрение требует полноценной экосистемы инструментов — их сейчас нет, и разработка неоправданна. Лучше развивать стандарты метаданных (ELF-расширения, DWARF), а не переписывать всё на SQLite, что лишь заменяет один барьерный API (fopen) другим (SQLite) без реального упрощения.

В конце 2023 года у Tailscale появилась система‑широких сбоев, вызванных редкой формой повреждения SQLite‑базы. Инциденты начались в августе, когда резервные копии, сохраняемые каждые несколько минут в S3, начали падать: PRAGMA integrity_check фиксировал повреждение, а восстановление требовало ручного ввода нескольких конфигураций. За полгода было зафиксировано 19 повторяющихся случаев, пока не выяснилось, что виновником стал баг в самом SQLite, связанный с особенностями WAL‑режима и агрессивным чекпоинтом.

Ключевой факт — SQLite не предназначен для одновременного чтения и записи в режиме «многократных» контрольных точек; при слишком частых сохранений он может «перезаписать» журнал и повредить файл. Команда обнаружила, что в их конфигурации WAL‑файл сбрасывается в момент, когда открывается новый процесс‑чтение, что приводит к гонке условий. Исправив настройку резервного копирования и добавив небольшую задержку перед сбросом WAL, они устранили проблему, а также подготовили патч для ядра SQLite, который будет включён в будущие версии. Теперь сервис стабилен уже несколько месяцев, а команда планирует более тщательно тестировать любые нестандартные схемы использования «скучной» технологии.

Тред анализирует выявление 16-летней ошибки в SQLite, подчеркивая важность тщательного тестирования и поддержки открытого исходного кода. Участники отмечают значимость этого открытия и ценят прозрачность команды Tailscale в публикации результатов. Некоторые рекомендуют использовать Postgres для систем с высокой конкуренцией, считая SQLite неоптимальным выбором, другие оспаривают эту позицию.

В последние дни появилось несколько «критических» CVE в SQLite, опубликованных в репозитории, где почти все они оказались выдуманными. Проверка показала, что в них ссылаются на несуществующие функции, указаны неверные номера строк и даже содержат противоречивые метаданные — типичный признак LLM‑slop. Одна из записей (CVE‑2026‑51302) получила первоначально оценку 9.8, но позже её CVSS‑балл был снижен до 7.6, а официальная страница SQLite с advisories её вовсе не упоминает.

Проверка проводилась в трёх шагах: сравнение кода в официальных версиях 3.41.0, 3.51.2 и 3.51.3 с описанием уязвимостей; сборка этих релизов в изолированных Docker‑контейнерах; запуск PoC‑SQL‑запросов под AddressSanitizer. Во всех случаях уязвимости не воспроизводились, а функции, на которые ссылались в advisories, либо отсутствовали, либо находились в других версиях. Эти случаи подчёркивают риск автоматического доверия к новым CVE, особенно когда они генерируются ИИ и быстро заполняют базы данных, создавая лишний шум для команд по управлению уязвимостями.

Тред обсуждает риски автоматического обнаружения уязвимостей с помощью LLM: высокий уровень ложных срабатываний и шума. Участники подчеркивают необходимость ручной верификации всех обнаруженных уязвимостей и критическую роль опытных специалистов в их оценке. Некоторые считают, что проблема — не в LLM, а в системе CVE, позволяющей публиковать уязвимости без должной проверки, что открывает возможность для злоумышленников намеренно загружать систему ложными данными и снижать её эффективность. Организациям рекомендуется не полагаться на автоматизированные системы без ручной проверки.

SQLite по умолчанию игнорирует ограничения внешних ключей и допускает хранение данных неверного типа, что приводит к скрытым ошибкам. В частности, ограничения foreign key отключены, а ROWID может переиспользоваться, поэтому удаление пользователя без удаления его записей не вызывает ошибки, а при создании новой записи с тем же id получается ссылка на чужой пост; включив PRAGMA foreign_keys=ON, получаем сообщение «Runtime error: FOREIGN KEY constraint failed (19)». Эти особенности делают базу уязвимой, хотя и обеспечивают совместимость со старым кодом.

Автор предлагает ввести «редацию» SQLite, аналогичную системе версий Rust, где PRAGMA edition=2026 будет включать набор pragmas: foreign_keys=ON, busy_timeout=5000, journal_mode=WAL, synchronous=NORMAL и включать строгий режим таблиц. Такое изменение сохраняет обратную совместимость, но позволяет постепенно улучшать параметры, например в будущих версиях добавить WAL2. Настройки повышают надёжность (проверка внешних ссылок), производительность (WAL, NORMAL) и упрощают миграцию на новые версии.

Эти pragmas также включают busy_timeout=5000, чтобы избежать блокировок, и включают строгий режим, который требует указания всех обязательных полей, что упрощает поддержку схемы. Таким образом, пользователь получает набор «безопасных» настроек, который можно активировать одной командой, не ломая старый код.

Обсуждение добавляет к статье практические примеры использования SQLite, возражения против введения 'изданий' и опасения по поводу совместимости и фрагментации.

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

• Совет: Участники рекомендуют использовать wrapper-библиотеки, которые устанавливают sensible defaults, или использовать альтернативные базы данных, такие как PostgreSQL, для проектов, требующих более строгих гарантий.

• Большинство участников согласны с тем, что текущие настройки по умолчанию SQLite могут быть не подходящими для всех случаев использования, но расходятся во мнениях о том, как следует изменить эти настройки.

• Спор: @kccqzy возражает против введения 'изданий' в SQLite, поскольку это может нарушить совместимость с более старыми версиями и усложнить использование базы данных.

• Совет: @Rendello предлагает обсудить эту идею на форуме SQLite, поскольку разработчики могут быть заинтересованы в рассмотрении этого предложения.

I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. — @bambax

Разработчик создал неофициальную реализацию Microsoft Recall для Linux, позволяющую автоматически записывать действия пользователя для последующего поиска. Проект использует Wayland для захвата экрана и работает в средах GNOME и KDE Plasma, сохраняя данные локально в базе SQLite. Интерфейс поиска позволяет находить нужные моменты по текстовому запросу, аналогично оригинальной функции Windows.

Ключевое отличие — полное локальное хранение данных без отправки в облако, что повышает приватность. Реализация использует Python и GTK4, поддерживает фильтрацию по приложениям и временным промежуткам. Проект находится на ранней стадии разработки, но уже демонстрирует основной функционал Recall. Разработчик отмечает, что это экспериментальный проект, не связанный с Microsoft.

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

SQLite написан на C, а не на более современных языках, по нескольким ключевым причинам.

Производительность и контроль: C позволяет разработчикам писать код, который выполняется максимально близко к аппаратному уровню, что критично для низкоуровневых библиотек, таких как SQLite. Хотя некоторые языки могут заявлять о схожей производительности, C остается эталоном. Кроме того, его "портабельность" (работа практически на любой платформе) делает его универсальным.

Совместимость и стабильность: Библиотеки на C могут использоваться практически из любого другого языка программирования, что делает SQLite доступным для разработчиков на разных платформах и в разных экосистемах. C также является зрелым и стабильным языком, что минимизирует риски, связанные с изменчивостью более молодых языков.

Минимальные зависимости: В отличие от многих современных языков, которые требуют объемные среды выполнения, код на C имеет минимальные зависимости. Это делает развертывание легким и надежным, что критично для встраиваемых систем, где SQLite часто используется.

Хотя существуют аргументы в пользу использования объектно-ориентированных или "безопасных" языков (таких как Rust), эти варианты были либо недоступны, либо незрелы, когда начиналась разработка SQLite. Более того, переход на новый язык потребовал бы значительных усилий без гарантии улучшений, особенно учитывая, что SQLite уже хорошо отлажен и оптимизирован в своей текущей реализации на C.

• Обсуждение вращается вокруг того, стоит ли переписывать SQLite на другие языки, но аргументы сводятся к тому, что существующий код уже безупречен, а переписывание может внести новые баги и даже замедлить работу.
• Подчеркивается, что SQLite — это не только код, но и 100% покрытие тестами и 25 лет отладки, что делает язык менее важным, чем для других проектов.
• Участники обсуждения отмечают, что языки вроде Rust всё ещё молоды и меняются, а также не предоставляют преимуществ в контексте уже готового кода.
• Поднимается вопрос о том, что важнее — язык или разработчики, и подчеркивается, что последние могут писать на любом языке, если бы это действительно было нужно.

Запуск собственного XMPP-сервера на базе ejabberd позволяет избежать слежки за перепиской и утечек данных, которые характерны для коммерческих мессенджеров. Это особенно актуально на фоне планов ЕС по автоматическому мониторингу всех чатов и сообщений. XMPP поддерживает шифрование OMEMO, обмен файлами, групповые чаты и аудио-/видеозвонки, оставаясь ресурсоэффективным решением.

Для развёртывания сервера требуется настроить DNS-записи для оснвных и вспомогательных поддоменов, установить ejabberd через официальный репозиторий или GitHub, открыть необходимые порты (5222, 5269, 5280 и другие) и настроить конфигурацию в YAML. Ключевые настройки включают отказ от модулей, нарушающих приватность (mod_last, mod_bosh), использование SQLite вместо Mnesia и генерацию свежих DH-параметров. Все шаги автоматизированы с помощью Ansible-ролей в открытом репозитории.

• Участники обсуждают проблемы с клиентами XMPP, особенно на iOS: отсутствие реакций, ненадежные уведомления, неудовлетворительный пользовательский интерфейс и недостаток современных функций (гифки, звонки).
• Многие отмечают простоту настройки и надежность серверов XMPP (Prosody, ejabberd), но подчеркивают, что основная сложность для широкого внедрения — это сетевой эффект и нежелание неподготовленных пользователей мириться с отсутствием привычного удобства.
• В качестве альтернатив упоминаются Matrix (критикуется за сложность и нестабильность), Delta.Chat (на основе email) и Signal (отмечаются проблемы с приватностью из-за номера телефона и возможный уход из ЕС).
• Поднимается вопрос цензуры и тотального мониторинга в ЕС, что может подтолкнуть пользователей к самохостингу и децентрализованным решениям.
• Обсуждаются технические аспекты развертывания: проблемы с блокировкой портов на публичных сетях, необходимость reverse proxy, использование Docker для упрощения установки и управления.

Выпуск Litestream v0.5.0 знаменует переход от простого резервного копирования к эффективному восстановлению на определённый момент времени (PITR). Ключевое нововведение — формат LTX, позаимствованный из проекта LiteFS. Вместо потоковой передачи отдельных страниц базы данных Litestream теперь группирует изменения в рамках транзакций, что значительно ускоряет восстановление после сбоя.

Формат LTX решает проблему "горячих страниц" — например, при частых вставках в таблицу с автоинкрементным ключом, когда изменения концентрируются на ограниченном числе страниц. Раньше Litestream обрабатывал каждую страницу отдельно, что замедляло процесс. Теперь транзакции записываются целиком, сокращая количество операций ввода-вывода и ускоряя восстановление. Это делает SQLite ещё более надёжным решением для полноценных приложений.

• Пользователи обсуждают сложности развертывания SQLite-приложений на Fly.io, включая проблемы с инициализацией и миграцией баз данных.
• Litestream получает положительные отзывы за простоту использования, низкую стоимость репликации в S3 и надежность как инструмента для резервного копирования и репликации.
• Обсуждаются технические детали Litestream: поддержка S3-совместимых хранилищ, условные записи для реализации временных lease и планы по реализации read-replicas через VFS.
• Участники сравнивают Litestream с другими решениями (LiteFS, rsync, управляемые БД), отмечая его операционную простоту и отсутствие необходимости в отдельном сервере.
• Поднимаются вопросы о практическом применении SQLite и Litestream: восстановление после сбоев, работа с нестабильным интернетом, целесообразность использования против PostgreSQL/MySQL для разных сценариев.

Автор перевел свой блог с Racket на Lua, чтобы снизить сложность и обеспечить долгосрочную стабильность. Основная причина — разочарование в быстро меняющихся экосистемах вроде JavaScript и Ruby, где постоянные обновления и ломающие изменения усложняют поддержку. Lua привлек медленным развитием: между версиями 5.1 (2006) и 5.4 (2020) различия минимальны, а язык требует лишь компилятора C89.

Блог работает по старинке — через CGI-скрипты, с SQLite в качестве базы и шаблонизацией Mustache. Несмотря на кажущуюся архаичность, автор ценит простоту, минимальное количество зависимостей (около десяти) и возможность писать собственные легковесные библиотеки. Ключевой вывод: блог — это пространство для экспериментов, где можно отказаться от модных инструментов в пользу того, что действительно работает и приносит удовольствие.

• Предложение возродить создание собственных движков для блогов как учебного проекта для инженеров из-за его низкого риска и возможностей для экспериментов.
• Обсуждение выбора Lua как стабильного и минималистичного языка для веб-разработки, несмотря на его недостатки (1-based индексация, разрыв между версиями, мало стандартных библиотек).
• Критика сложности современных стеков для блогов и аргументы в пользу простых решений: статические генераторы (Hugo), чистый HTML или минимальные скрипты (Python, Lua).
• Упоминание альтернативных технологий и подходов: Redbean, Perl, Caddy, XSLT, Web Components, Fennel, OpenResty и другие.
• Подчёркивание важности личного выбора, удовольствия от процесса и независимости от внешних сервисов при создании блога.

Как устроен bun install

• Один бинарник — весь менеджер зависимостей живёт внутри Bun, нет внешних вызовов к npm, yarn, node-gyp.
• Сишный движок — парсинг package.json, yarn.lock, node_modules происходит на Zig, без JS-оверхеда.
• HTTP-пул + кэш — 50–100 параллельных потоков, кэш на диске + SQLite-индекс, повторный install — <100 мс.
• Symlink-ферма — модули не копируются, а hard-link’ются из глобального кэша; экономия 70 % диска.
• Муравьиный алгоритм — сначала скачиваются «листья» дерева зависимостей, потом родители; сеть греется максимально.
• Платформенные пакеты — если в lock-файле есть запись под Linux, macOS и Windows, скачиваются сразу три архива и раскладываются в node_modules/.cache, при запуске выбирается нужный.
• postinstall без shell — скрипты запускаются встроенным JS-движком, нет overhead’а на spawn bash/cmd.
• Проверка целостности — каждый tarball сверяется по SHA256 из lock-файла, кэш защищён от подмены.
• Мониторинг прогресса — терминал обновляется раз в 16 мс, рисуется ASCII-полоса и счётчик «пакетов/сек».
• Фоллбек к npm — если пакет не найден в официальном реестре, Bun автоматом лезет в npm и кладёт tarball в кэш, пользователь не замечает разницы.

• Пользователи обсуждают статью о внутреннем устройстве и производительности менеджера пакетов Bun.
• Многие хвалят скорость и простоту Bun, но отмечают проблемы совместимости с Node.js и стабильностью.
• Часть комментаторов сомневается в практической пользе высокой скорости установки пакетов и считает переход с Node.js рискованным.
• Упоминаются альтернативы — Deno, pnpm, npm — и сравнение с ними по скорости и надёжности.
• Некоторые считают, что Bun не предлагает «убийственных» фич, чтобы оправдать переход с зрелой экосистемы Node.js.

Immich — быстрый и бесплатный аналог Google Фото, который ставится у себя на сервере.
Хранит фото/видео, делает резервные копии, группирует по лицам и геометкам, ищет по объектам и тексту.
Есть веб, мобильные приложения, автозагрузка, совместные альбомы и RAW.
Запускается в Docker за пару минут.

• Пользователи хвалят Immich за быстрый рост, «почти идеальный» клиент и удобную замену Google Photos.
• Ключевые претензии: нет стабильного релиза, агрессивные обновления зависимостей, отсутствие официального пакета в Debian.
• Некоторые страдают от слабого поиска, отсутствия OCR, сжатия и SQLite-варианта.
• Часть людей отказывается от самостоятельного хостинга из-за «bus-factor = 1», дорогого блок-хранилила и риска потерять фото.
• Альтернативы: Ente.io (E2E-шифрование), PhotoPrism, Nextcloud Photos; кто-то просто докупает место у PikaPods.

Base — компактный и мощный редактор SQLite для macOS.

Скачать бесплатно | Купить

Возможности

• Инспектор схем
  Быстро просматривайте структуру таблиц, типы столбцов и связи без SQL.

• Визуальный редактор таблиц
  Создавайте и изменяйте таблицы мышью, без CREATE/ALTER.

• Браузер данных
  Просматривайте, фильтруйте и правьте записи прямо в таблице.

• SQL-редактор
  Пишите запросы с подсветкой синтаксиса, автодополнением и сохранением сниппетов.

• Импорт/Экспорт
  Загружайте CSV и SQL-дампы; выгружайте в CSV, SQL, JSON и Excel.

Системные требования

macOS 15 Sequoia и выше.
Бесплатная версия ограничена; полная — единоразовая покупка.

Документация | Контакты

• Пользователи удивлены, что Base существует уже 15 лет, но плохо заметен в поиске.
• Хвалят «ремесленный» подход: маленькая команда, узкая задача, высокое качество.
• Часто сравнивают с TablePlus, Postico и sqlitebrowser, отмечая превосходство в «родном» macOS-UX.
• Просят добавить DuckDB, UUID, автозагрузку расширений, FK по умолчанию и диаграммы схемы.
• Покупатели благодарны за возможность покупки вне Mac App Store и за льготную цену.