Редкий Docker-трюк для баз данных: отдельный volume под WAL

У Postgres есть место, куда он пишет журнал изменений: WAL.

Если база активно пишет данные, WAL может стать узким местом. В Docker его можно вынести в отдельный volume:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_INITDB_WALDIR: /var/lib/postgresql/wal
    volumes:
      - pg_data:/var/lib/postgresql/data
      - pg_wal:/var/lib/postgresql/wal

volumes:
  pg_data:
  pg_wal:

Зачем это нужно:

1. данные базы лежат отдельно
2. журнал транзакций лежит отдельно
3. проще мониторить рост WAL
4. меньше риска забить основной volume логами

Особенно полезно для staging, pet-проектов с нагрузкой и локальных стендов, где внезапно «почему Postgres сожрал весь диск».

Мелочь, но уже уровень не “я просто поднял базу в Docker”, а нормальная инженерная привычка.

10 GitHub-репозиториев, которые заставят вас навсегда забыть о платном ПО

Полностью бесплатно.

1.LocalSend / http://github.com/localsend/localsend
Воздушная передача файлов между платформами. Передача файлов между Windows, Mac, Linux, Android, iOS — без регистрации и облака

2.yt-dlp / http://github.com/yt-dlp/yt-dlp
Скачивание видео и аудио с любого сайта. YouTube, Bilibili, Twitter — всё покрыто, мощнее любого платного загрузчика

3.Stirling-PDF / http://github.com/Stirling-Tools/Stirling-PDF
Самостоятельный универсальный инструмент для PDF. Объединение, разделение, сжатие, конвертация в Word, добавление водяных знаков, OCR — замена всему семейству Adobe

4.FreeTube / http://github.com/FreeTubeApp/FreeTube
Десктопный плеер для YouTube. Без рекламы, без слежки, без аккаунта Google — что вы смотрите, знает только вы

5.Syncthing / http://github.com/syncthing/syncthing
Альтернатива Baidu Netdisk и iCloud. Прямая синхронизация файлов между устройствами, сквозное шифрование, данные не проходят через серверы третьих лиц

6.Vaultwarden / http://github.com/dani-garcia/vaultwarden
Самостоятельный менеджер паролей. Бесплатная замена 1Password и LastPass навсегда, данные хранятся только на вашем устройстве

7.Immich / http://github.com/immich-app/immich
Самостоятельный Google Фото. Автоматическое резервное копирование фото с телефона, распознавание лиц, поиск по ИИ — больше не платите аренду за хранилище ежемесячно

8.AdGuard Home / http://github.com/AdguardTeam/AdGuardHome
Блокировка рекламы по всей сети. Блокировка на уровне роутера — все устройства в доме, включая смарт-телевизоры, без рекламы

9.Jellyfin / http://github.com/jellyfin/jellyfin
Самостоятельный Netflix. Свои фильмы, сериалы и музыка — транслируйте сколько угодно, без ежемесячных платежей платформам

10.Uptime Kuma / http://github.com/louislam/uptime-kuma
Самостоятельная панель мониторинга. Следит за вашими сайтами и сервисами, мгновенно уведомляет о сбоях — замена платному мониторингу за $50 в месяц.

ИИ заставляет перестраивать инфраструктуру

Когда говорят про развитие ИИ, обычно обсуждают модели, агенты и новые возможности.

Но есть менее заметная проблема: всё это нужно где-то запускать. На infra.conf’26 Александр Чубинский из Яндекса рассказал, как компания перестраивает физическую и ML-инфраструктуру под растущие нагрузки.

Изменения происходят сразу на нескольких уровнях:
- вместо отдельных дата-центров развивают кампусы дата-центров мощностью до 180 МВт;
- внедряют жидкостное охлаждение, потому что традиционные подходы уже не всегда справляются с плотностью вычислений;
- запустили внутренний сервис Dev Cluster, который ускоряет эксперименты и разработку ML-моделей.

Чем больше ИИ, тем меньше это история только про софт.

Основы Git и GitHub за 30 секунд: настройка, коммиты, ветки, Pull Request

GitHub пугает новичков не сложностью, а количеством команд, в которых легко утонуть в первый же день. Эта шпаргалка собирает весь базовый путь от пустого терминала до открытого Pull Request, чтобы не держать всё в голове и не гуглить каждый шаг.
Сначала первая настройка: задаёшь имя и email, иначе коммиты уходят непонятно от кого. Дальше старт работы: клонируешь репозиторий, заходишь в папку и сразу создаёшь свою ветку под задачу. Потом ежедневный цикл, который повторяется каждый день: status, pull, add, commit, push. Проверил, обновил, добавил, закоммитил, отправил. Отдельно блок полезных команд на каждый день: log с графом, diff, stash, branch и переключение на main.

C умел «объектный стиль» задолго до модных споров про ООП.

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

file_operations из include/linux/fs.h - хороший пример. Ядро говорит: вот набор операций, которые может поддерживать файл, сокет или устройство. Драйвер сам решает, какие обработчики дать:

open
read
write
release
mmap
fsync
unlocked_ioctl

Если операция не нужна, поле остаётся NULL, и ядро использует поведение по умолчанию там, где это возможно.

По сути это тот же контракт между системой и реализацией, только без классов, наследования и рантаймовой магии. Есть таблица функций, есть объект, есть набор действий, которые с ним можно выполнить.

Именно поэтому C до сих пор живёт в ядрах, драйверах и системном коде. Он не навязывает модель абстракций, но даёт достаточно низкоуровневых инструментов, чтобы собрать нужную модель самому.

Просто вместо красивого слова interface у тебя struct с function pointers.

#programming #linux #c

ScrapeComfort — бесплатный инструмент для безболезненного веб-скрапинга прямо с вашего рабочего стола.

Интуитивно понятный интерфейс обеспечивает бесперебойный процесс извлечения данных независимо от вашей технической подготовки.

Kroc - небольшой, но очень показательный проект для тех, кто хочет понять Kubernetes Operators не по слайдам, а по коду.

Идея простая: вы описываете CRD Kroc, указываете, за какими объектами в Kubernetes нужно следить, и задаёте шаблон ресурса, который должен быть создан на основе найденного объекта.

Например, оператор может смотреть за Deployment, брать из него нужные поля и автоматически создавать связанные Pod, Service, ConfigMap или другие Kubernetes-объекты.

Внутри используется Go и Kubebuilder.

Самое интересное - реактивная модель.

Если исходный объект изменился, производные ресурсы пересоздаются.

Если кто-то вручную удалил созданный объект, оператор создаст его снова, чтобы вернуть кластер в нужное состояние.

По сути, это хороший минимальный пример того, как работает operator pattern в Kubernetes:

наблюдаем за состоянием
сравниваем с желаемым
создаём или пересоздаём ресурсы
держим систему синхронизированной

Архитектура тоже полезная для разбора: проект разделяет логику на несколько контроллеров.

Один отвечает за CRD и конфигурацию, второй наблюдает за внешними Kubernetes-объектами, третий создаёт производные ресурсы из шаблонов.

Для новичков в Kubernetes Operators это намного понятнее, чем сразу лезть в большие production-операторы.

Kroc хорошо показывает базовую механику: CRD, reconcile loop, watch, template rendering и управление жизненным циклом дочерних объектов.

https://github.com/pawelcit/kroc

Забавная игрушка на ночь: GitHub-профиль теперь можно превратить в карточку в стиле FIFA.

GitFut прогоняет аккаунт по метрикам вроде коммитов, звёзд, репозиториев, подписчиков и активности, а потом собирает карточку с рейтингом от 0 до 99.

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

https://gitfut.com/

Алгоритму почти 70 лет, а он до сих пор живёт в ядре Linux.

В 1957 году Wilkes, Wheeler и Gill описали быстрый способ считать количество установленных битов в числе. Не циклом по одному биту, а через маски и арифметику сразу над группами битов.

Идея простая:

- сначала считаем биты парами
- потом группами по 4
- потом по байтам
- в конце умножение собирает сумму в старший байт

Если в процессоре нет инструкции POPCNT, Linux использует похожий подход в __sw_hweight64.

Красивый пример того, как старый битовый трюк пережил десятилетия и всё ещё работает в современном системном коде.

Data-платформа растет, а TCO улетает в космос?

Собрать данные с датчиков — полдела. На практике платформенные инженеры и DevOps тонут в зоопарке инструментов. Развёртывание ИТ-систем без чёткого плана (особенно на собственных серверах) грозит хаосом в обслуживании, трудностями с обновлениями и нарушением требований безопасности.

10 июля в 12:00 подключайтесь к вебинару «Реализация IoT-сценариев на продуктах Deckhouse: быстрый запуск, масштабирование, аналитика».

На примере live demo покажем, как Deckhouse Kubernetes Platform (DKP) объединяет сбор, обработку и визуализацию данных датчиков в единую надёжную систему.

Обсудим:
• как собрать event-driven-архитектуру на Kafka, PostgreSQL и ClickHouse без ручного управления;
• зачем изолировать operational и analytical workloads в enterprise-контуре;
• как выстроить telemetry pipeline с managed-подходом и observability «из коробки» с помощью DKP;
• как работает сквозная аналитика от датчика до отчёта — live demo IoT-сценария на примере готового решения

Зарегистрироваться бесплатно

Большинство “простых” shuffle-алгоритмов дают кривой рандом

Частая ошибка:

for (int i = 0; i < n; i++) {
    int j = rand() % n;
    swap(a[i], a[j]);
}

На вид всё нормально: каждый элемент случайно меняется местами с другим.

Но проблема в вероятностях.

Для массива из n элементов существует n! перестановок.

Хороший shuffle должен давать каждой перестановке одинаковый шанс.

Наивный вариант делает n шагов, и на каждом шаге выбирает индекс из полного диапазона 0..n-1.

В итоге некоторые перестановки появляются чаще других.

Правильный подход — Fisher-Yates shuffle:

for (int i = n - 1; i > 0; i--) {
    int j = random(0, i);
    swap(a[i], a[j]);
}

Идея простая:

на каждом шаге мы выбираем элемент только из ещё не зафиксированной части массива.

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

Так каждая перестановка получает одинаковую вероятность.

В C++ лучше не писать через rand() % n, потому что там может быть ещё и modulo bias.

Нормальный вариант:

std::mt19937 rng(std::random_device{}());

for (int i = n - 1; i > 0; --i) {
    std::uniform_int_distribution<int> dist(0, i);
    int j = dist(rng);
    std::swap(a[i], a[j]);
}

Shuffle - хороший пример, где код может выглядеть “рандомным”, но математически быть неправильным.

Cuckoo hashing даёт O(1) lookup в худшем случае

Не амортизированно.

Не «в среднем».

А именно worst case.

Идея красивая: у каждого ключа есть ровно две возможные позиции в таблице.

Поэтому поиск тупо проверяет оба места и заканчивается.

return table1[h1(key)] == key
    || table2[h2(key)] == key;

Вставка работает интереснее: если место занято, новый ключ «выталкивает» старый в его альтернативную позицию.

Отсюда и название: как кукушка, которая выкидывает чужие яйца из гнезда.

Если начинается цикл, таблицу перестраивают с новыми хеш-функциями.

Алгоритм предложили Rasmus Pagh и Flemming Rodler в 2001 году.

И это не просто академическая штука: Linux kernel использует cuckoo hashing в connection tracking table.

Один из тех случаев, когда простая идея даёт очень сильную гарантию по lookup.

NASA только что выпустила WASM-runtime для космических аппаратов… написанный на Rust! 🦀🎉

🛰️ SpaceWasm — детерминированный интерпретатор WebAssembly, созданный для бортового программного обеспечения космических аппаратов.

https://github.com/nasa/spacewasm

#rustlang #wasm #space #nasa #opensource

⚡️ Kali Linux Roadmap: с чего начать в этичном хакинге

Нашёл нормальный roadmap по Kali Linux для тех, кто хочет не просто «поставить Kali и открыть терминал», а постепенно разобраться, как всё это работает.

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

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

Хороший подход здесь простой: сначала понять систему, потом сеть, потом инструменты, и только после этого переходить к практике в легальных лабораториях и CTF.

Такой roadmap удобно проходить как чек-лист: открыл раздел, разобрал команды, повторил руками, закрепил на тестовом окружении.

Для старта в Kali Linux это намного лучше, чем хаотично смотреть ролики и копировать команды без понимания.

https://github.com/justxor/Kalilinuxroadmap/tree/main

Алерт в 2 ночи: латентность API выросла в 10 раз

Сначала кажется, что проблема в приложении. Открываешь дашборды — часть метрик зелёная. Идёшь в логи, потом в трассировки, потом проверяешь инфраструктуру. Контекст собирается вручную, а сервис всё это время продолжает деградировать.

На вебинаре 17 июля покажем, как этот сценарий выглядит в Deckhouse Observability Platform (DOP).

Например: API тормозит, а источник проблемы в поде базы данных, где резко выросло потребление IOPS. DOP помогает увидеть деградацию в разрезе инфраструктуры, понять, какие компоненты затронуты, какие зависимости участвуют в инциденте и какой бизнес-сервис под ударом.

Проведём live-демо: от настройки DOP до сценария «алерт → локализация → первопричина». Расскажем, как платформа заранее подсвечивает признаки деградации и помогает сокращать время простоя. А ещё покажем AI-ассистента, который находит причину инцидента за вас.

17 июля в 12:00| онлайн

👉 Зарегистрироваться бесплатно