mkcert — локальные HTTPS-серты без боли
Недавно прикрутил mkcert на сайд-проекте — прям кайф. Это маленькая утилита, которая создаёт локальный центр сертификации (CA) и выпускает для вас “валидные” dev-сертификаты (браузеры им доверяют, потому что корневой CA ставится в системные хранилища). Никаких плясок с OpenSSL.
Технически это не self-signed: сертификат подписан вашим локальным CA, поэтому пропадают жёлтые варнинги в браузере.
Быстрый старт
Файлы окажутся в текущей папке: *.pem и *-key.pem. Где лежит сам корневой CA:
(эту папку удобно шарить в контейнер/VM, если нужно доверие там).
Подключаем к серверу
Nginx (dev):
Node.js нюанс: Node не берёт системный trust store. Добавьте корневой CA:
Traefik/Docker: удобно выпустить *.docker.localhost и отдать Traefik’у — получите HTTPS на всех локальных сервисах.
Мобильное тестирование
Чтобы телефон доверял вашим dev-сертам, установите корневой CA (rootCA.pem) на устройство (iOS — профиль и «полное доверие», Android — импорт CA и включение user roots в dev-сборке).
Безопасность и ограничения
Не для продакшена. mkcert — только для локальной разработки.
Храните в секрете rootCA-key.pem. Потеряете — перевыпускайте CA и серты.
#DevOps
Недавно прикрутил mkcert на сайд-проекте — прям кайф. Это маленькая утилита, которая создаёт локальный центр сертификации (CA) и выпускает для вас “валидные” dev-сертификаты (браузеры им доверяют, потому что корневой CA ставится в системные хранилища). Никаких плясок с OpenSSL.
Технически это не self-signed: сертификат подписан вашим локальным CA, поэтому пропадают жёлтые варнинги в браузере.
Быстрый старт
# 1) Устанавливаем mkcert
# macOS
brew install mkcert && brew install nss # nss — если используете Firefox
# Linux (пример для Debian/Ubuntu)
sudo apt install libnss3-tools && brew install mkcert # либо возьмите готовый бинарник из релизов
# Windows
choco install mkcert # или scoop install mkcert
# 2) Создаём и устанавливаем локальный CA (один раз)
mkcert -install
# 3) Генерим сертификаты под локальные домены/IP
mkcert localhost 127.0.0.1 ::1
# пример для прокси/мультисервисной разработки
mkcert "*.docker.localhost"
Файлы окажутся в текущей папке: *.pem и *-key.pem. Где лежит сам корневой CA:
mkcert -CAROOT
(эту папку удобно шарить в контейнер/VM, если нужно доверие там).
Подключаем к серверу
Nginx (dev):
ssl_certificate /path/to/localhost.pem;
ssl_certificate_key /path/to/localhost-key.pem;
Node.js нюанс: Node не берёт системный trust store. Добавьте корневой CA:
export NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem"
Traefik/Docker: удобно выпустить *.docker.localhost и отдать Traefik’у — получите HTTPS на всех локальных сервисах.
Мобильное тестирование
Чтобы телефон доверял вашим dev-сертам, установите корневой CA (rootCA.pem) на устройство (iOS — профиль и «полное доверие», Android — импорт CA и включение user roots в dev-сборке).
Безопасность и ограничения
Не для продакшена. mkcert — только для локальной разработки.
Храните в секрете rootCA-key.pem. Потеряете — перевыпускайте CA и серты.
#DevOps
❤3👍3
Нереальный кейс в DevOps с LLM, который полностью перевернул моё представление о разработке! 🤯
Привет, ребята! Хочу поделиться просто невероятными впечатлениями, которые я получил, активно погружаясь в мир новейших Large Language Models. Это не просто эксперименты – это реальный прорыв в подходе к задачам, с которыми мы, DevOps-инженеры, сталкиваемся каждый день.
Сейчас я плотно тестирую самые свежие новинки LLM, и особенно меня поразила связка Antigravity с моделью Gemini 3. Это просто фантастика! Представьте: мне удалось создать полноценное приложение для учёта времени, и самое интересное – я не написал НИ ЕДИНОЙ строчки традиционного кода! Весь процесс разработки свёлся к грамотному составлению промптов. Это был чистый "промпт-инжиниринг", который позволил мне реализовать функционал от идеи до работающего прототипа без углубления в синтаксис конкретного языка программирования.
И что самое крутое: после того, как приложение было готово, я успешно его задеплоил! Сначала поднял на своём локальном кластере Kubernetes, чтобы убедиться в стабильности и возможностях контейнеризации, а затем развернул и в Docker Compose на сервере Selectel. Весь процесс занял значительно меньше времени, чем обычно, и подтвердил колоссальный потенциал LLM в автоматизации и ускорении разработки и развёртывания.
Современные LLM – это просто космос! Они не только помогают писать код, но и позволяют создавать работающие решения практически "из воздуха", значительно сокращая цикл разработки и открывая новые горизонты для продуктивности в DevOps.
Ссылка на результат: https://timetracker.graywrk.ru/
Кто ещё экспериментировал с подобным подходом или использовал LLM для автоматизации рутинных задач? Делитесь своими кейсами и впечатлениями в комментариях! Какие LLM используете, и для чего? Будет интересно обсудить! 👇
P.S.: пост написан через LLM )))
P.P.S: тестировать лень, тестировала LLM, если найдете баги - пишите, "оно" поправит )
Привет, ребята! Хочу поделиться просто невероятными впечатлениями, которые я получил, активно погружаясь в мир новейших Large Language Models. Это не просто эксперименты – это реальный прорыв в подходе к задачам, с которыми мы, DevOps-инженеры, сталкиваемся каждый день.
Сейчас я плотно тестирую самые свежие новинки LLM, и особенно меня поразила связка Antigravity с моделью Gemini 3. Это просто фантастика! Представьте: мне удалось создать полноценное приложение для учёта времени, и самое интересное – я не написал НИ ЕДИНОЙ строчки традиционного кода! Весь процесс разработки свёлся к грамотному составлению промптов. Это был чистый "промпт-инжиниринг", который позволил мне реализовать функционал от идеи до работающего прототипа без углубления в синтаксис конкретного языка программирования.
И что самое крутое: после того, как приложение было готово, я успешно его задеплоил! Сначала поднял на своём локальном кластере Kubernetes, чтобы убедиться в стабильности и возможностях контейнеризации, а затем развернул и в Docker Compose на сервере Selectel. Весь процесс занял значительно меньше времени, чем обычно, и подтвердил колоссальный потенциал LLM в автоматизации и ускорении разработки и развёртывания.
Современные LLM – это просто космос! Они не только помогают писать код, но и позволяют создавать работающие решения практически "из воздуха", значительно сокращая цикл разработки и открывая новые горизонты для продуктивности в DevOps.
Ссылка на результат: https://timetracker.graywrk.ru/
Кто ещё экспериментировал с подобным подходом или использовал LLM для автоматизации рутинных задач? Делитесь своими кейсами и впечатлениями в комментариях! Какие LLM используете, и для чего? Будет интересно обсудить! 👇
P.S.: пост написан через LLM )))
P.P.S: тестировать лень, тестировала LLM, если найдете баги - пишите, "оно" поправит )
Я собрал домашний мониторинг с физическим пейджером алертов. Несколько мыслей по пути.
Дано: одна VM (Ubuntu 24.04, 6 vCPU, 22 GB RAM) на домашнем гипервизоре.
Хотелось:
- full observability как в «большой» инфре;
- уведомления о critical-алертах не в почту, а на физический девайс;
- IaC-подход — конфиги в git, никаких ручных правок на сервере.
Что в итоге крутится:
📊 Мониторинг: VictoriaMetrics + vmagent + vmalert + Alertmanager + karma + Grafana, всё за Traefik. Выбрал VM вместо Prometheus не потому что «модно», а потому что single-binary + лучше сжимает — на пет-проекте это освобождает диск и голову.
🔔 Пейджер на M5StickC Plus 2 (ESP32): каждые 10с опрашивает /api/v2/alerts, при новом severity=critical играет мелодию. Бузер через LEDC, LCD через LovyanGFX. Заодно выяснил, что на этом конкретном экземпляре отсутствует PMIC на I2C — пришлось обходить M5.begin() и пилить инициализацию руками.
🤖 OpenHands (Agent Canvas) — self-hosted AI-coding агент. Разве что чтобы был.
🔗 n8n в продакшен-схеме: postgres + redis + main + worker в queue mode. SQLite — это хорошо для теста, не для automation в проде.
Пару раз устроил стресс-тест: stress-ng --cpu 6 --vm 2 --vm-bytes 2G --timeout 180s. Pipeline отработал честно: через ~30с пикнул пейджер, через минуту после снятия нагрузки всё резолвится само.
Мнения по дороге:
1. Homelab — самый дешёвый способ практиковать SRE-мышление. Стажёр с годом пет-проектов в резюме часто полезнее, чем обладатель сертификатов без них.
2. VictoriaMetrics для pet-project — отличный выбор. Меньше памяти, меньше диска, всё single-binary. Grafana с datasource type=prometheus всё ещё лучший вариант для визуализации.
3. Polling с ESP32 надёжнее webhook'а. M5StickC за WiFi/NAT, ещё и засыпать может — заморачиваться с входящим сервером не стоит.
Конфиги и код пейджера — в git, секреты в .env (gitignored). Если кому интересно — могу расписать отдельные куски подробнее.
А у вас есть физический пейджер для алертов? Или только Slack/Telegram-боты?
#homelab #DevOps #SRE #observability #VictoriaMetrics #Alertmanager #ESP32 #selfhosted
Дано: одна VM (Ubuntu 24.04, 6 vCPU, 22 GB RAM) на домашнем гипервизоре.
Хотелось:
- full observability как в «большой» инфре;
- уведомления о critical-алертах не в почту, а на физический девайс;
- IaC-подход — конфиги в git, никаких ручных правок на сервере.
Что в итоге крутится:
📊 Мониторинг: VictoriaMetrics + vmagent + vmalert + Alertmanager + karma + Grafana, всё за Traefik. Выбрал VM вместо Prometheus не потому что «модно», а потому что single-binary + лучше сжимает — на пет-проекте это освобождает диск и голову.
🔔 Пейджер на M5StickC Plus 2 (ESP32): каждые 10с опрашивает /api/v2/alerts, при новом severity=critical играет мелодию. Бузер через LEDC, LCD через LovyanGFX. Заодно выяснил, что на этом конкретном экземпляре отсутствует PMIC на I2C — пришлось обходить M5.begin() и пилить инициализацию руками.
🤖 OpenHands (Agent Canvas) — self-hosted AI-coding агент. Разве что чтобы был.
🔗 n8n в продакшен-схеме: postgres + redis + main + worker в queue mode. SQLite — это хорошо для теста, не для automation в проде.
Пару раз устроил стресс-тест: stress-ng --cpu 6 --vm 2 --vm-bytes 2G --timeout 180s. Pipeline отработал честно: через ~30с пикнул пейджер, через минуту после снятия нагрузки всё резолвится само.
Мнения по дороге:
1. Homelab — самый дешёвый способ практиковать SRE-мышление. Стажёр с годом пет-проектов в резюме часто полезнее, чем обладатель сертификатов без них.
2. VictoriaMetrics для pet-project — отличный выбор. Меньше памяти, меньше диска, всё single-binary. Grafana с datasource type=prometheus всё ещё лучший вариант для визуализации.
3. Polling с ESP32 надёжнее webhook'а. M5StickC за WiFi/NAT, ещё и засыпать может — заморачиваться с входящим сервером не стоит.
Конфиги и код пейджера — в git, секреты в .env (gitignored). Если кому интересно — могу расписать отдельные куски подробнее.
А у вас есть физический пейджер для алертов? Или только Slack/Telegram-боты?
#homelab #DevOps #SRE #observability #VictoriaMetrics #Alertmanager #ESP32 #selfhosted
✍1👍1
AI-агенты в DevOps перестали быть игрушкой
Прикололся на работе: заиспользовал GLM 5.1, развёрнутый внутри контура, вместе с OpenCode для своих DevOps-задач.
И это уже совсем другое ощущение.
Не «чатик, подскажи команду kubectl», а нормальный рабочий напарник рядом с инфраструктурой. Разобрать конфиг, накидать скрипт, проверить гипотезу, помочь с рутиной, не вынося данные наружу. Для корпоративного DevOps/SRE это, кажется, главный сдвиг: локальная модель в доверенном контуре сильно меняет правила игры.
Дома я пошёл ещё дальше. Всю хоумлабу и сервера для пет-проектов поставил под управление GLM 5.2. Плюс сделал пейджер для алертов на M5 Stick (об этом писал в прошлом посте).
Получилась такая маленькая SRE-лаборатория: сервера живут, алерты приходят на железку, агент помогает разруливать задачи, а я смотрю на это и понимаю, что мы очень быстро переходим от «AI пишет тексты» к «AI участвует в эксплуатации систем».
И вот тут становится интересно.
DevOps с агентами - это не про замену инженера. Это про то, что у инженера появляется второй контур мышления: быстрый, неустающий, подключённый к контексту. Он не принимает решения за тебя, но резко снижает стоимость мелких действий.
А в SRE половина боли как раз в мелких действиях.
Раньше для этого нужен был кусок внимания. Теперь можно делегировать агенту рутину и оставить себе главное - архитектуру и ответственность.
Похоже, следующий нормальный навык DevOps/SRE будет не «умею пользоваться ChatGPT», а умею строить безопасный agent-driven workflow вокруг инфраструктуры.
Кто уже пробовал агентов в реальной эксплуатации, а не только для README и баш-скриптов?
Прикололся на работе: заиспользовал GLM 5.1, развёрнутый внутри контура, вместе с OpenCode для своих DevOps-задач.
И это уже совсем другое ощущение.
Не «чатик, подскажи команду kubectl», а нормальный рабочий напарник рядом с инфраструктурой. Разобрать конфиг, накидать скрипт, проверить гипотезу, помочь с рутиной, не вынося данные наружу. Для корпоративного DevOps/SRE это, кажется, главный сдвиг: локальная модель в доверенном контуре сильно меняет правила игры.
Дома я пошёл ещё дальше. Всю хоумлабу и сервера для пет-проектов поставил под управление GLM 5.2. Плюс сделал пейджер для алертов на M5 Stick (об этом писал в прошлом посте).
Получилась такая маленькая SRE-лаборатория: сервера живут, алерты приходят на железку, агент помогает разруливать задачи, а я смотрю на это и понимаю, что мы очень быстро переходим от «AI пишет тексты» к «AI участвует в эксплуатации систем».
И вот тут становится интересно.
DevOps с агентами - это не про замену инженера. Это про то, что у инженера появляется второй контур мышления: быстрый, неустающий, подключённый к контексту. Он не принимает решения за тебя, но резко снижает стоимость мелких действий.
А в SRE половина боли как раз в мелких действиях.
Раньше для этого нужен был кусок внимания. Теперь можно делегировать агенту рутину и оставить себе главное - архитектуру и ответственность.
Похоже, следующий нормальный навык DevOps/SRE будет не «умею пользоваться ChatGPT», а умею строить безопасный agent-driven workflow вокруг инфраструктуры.
Кто уже пробовал агентов в реальной эксплуатации, а не только для README и баш-скриптов?
❤1😁1
Моя домашняя лаборатория постепенно превратилась в маленькую production-подобную инфраструктуру.
В центре стоит домашний сервер на Ubuntu с Docker Compose. На нем живут мониторинг, Git, Home Assistant, n8n, OpenHands, Vaultwarden, Paperless, Uptime Kuma, Loki и Forgejo. Все внутренние сервисы закрыты за Traefik с HTTPS на домене *.home.arpa.
Отдельный mini PC на Intel N100 теперь работает как single-node k3s-кластер. На нем поднят Argo CD, а конфигурация кластера хранится в отдельном GitOps-репозитории в локальном Forgejo. В кластер уже добавлен мониторинг Kubernetes-слоя: kube-state-metrics, kubelet/cAdvisor, Argo CD metrics и in-cluster vmagent.
Мониторинг построен вокруг VictoriaMetrics, vmagent, vmalert, Alertmanager, Karma и Grafana. Собираются метрики с домашних машин, роутера на OpenWrt, TrueNAS, k3s, внешних серверов Selectel и VPN-сервера с Amnezia. Для k3s отдельно настроены алерты и dashboard в Grafana.
Из домашней автоматизации работает Home Assistant с интеграциями Яндекса, включая устройства умного дома и Яндекс Станцию.
Главная идея всей лабы: не просто "поставить сервисы", а вести инфраструктуру как код, документировать изменения, хранить конфиги в Git и постепенно приближать домашнюю сеть к нормальной инженерной практике.
#homelab #selfhosted #k3s #devops
В центре стоит домашний сервер на Ubuntu с Docker Compose. На нем живут мониторинг, Git, Home Assistant, n8n, OpenHands, Vaultwarden, Paperless, Uptime Kuma, Loki и Forgejo. Все внутренние сервисы закрыты за Traefik с HTTPS на домене *.home.arpa.
Отдельный mini PC на Intel N100 теперь работает как single-node k3s-кластер. На нем поднят Argo CD, а конфигурация кластера хранится в отдельном GitOps-репозитории в локальном Forgejo. В кластер уже добавлен мониторинг Kubernetes-слоя: kube-state-metrics, kubelet/cAdvisor, Argo CD metrics и in-cluster vmagent.
Мониторинг построен вокруг VictoriaMetrics, vmagent, vmalert, Alertmanager, Karma и Grafana. Собираются метрики с домашних машин, роутера на OpenWrt, TrueNAS, k3s, внешних серверов Selectel и VPN-сервера с Amnezia. Для k3s отдельно настроены алерты и dashboard в Grafana.
Из домашней автоматизации работает Home Assistant с интеграциями Яндекса, включая устройства умного дома и Яндекс Станцию.
Главная идея всей лабы: не просто "поставить сервисы", а вести инфраструктуру как код, документировать изменения, хранить конфиги в Git и постепенно приближать домашнюю сеть к нормальной инженерной практике.
#homelab #selfhosted #k3s #devops
❤2
Восстановил свой блог:
https://blog.graywrk.ru/posts/recovering-lost-blog-source/
https://blog.graywrk.ru/posts/recovering-lost-blog-source/
Опенсорснул свою канбан-доску для AI-агентов.
Обычно оркестраторы агентов работают по пуш-модели: диспетчер решает,
кто что делает, и раздаёт задачи. Я сделал наоборот — доска пассивная,
агенты сами забирают работу через MCP. Как разработчик берёт тикет из
настоящего канбана, только тут агент вызывает get_next_task и claim_task.
Что под капотом:
▪️ 11 MCP-инструментов поверх streamable-HTTP (FastAPI + PostgreSQL)
▪️ Hard assignment — можно зарезервировать задачу за конкретным агентом,
остальные её просто не видят
▪️ Живая лента прогресса: агенты стримят диффы, артефакты, ошибки.
Пишешь комментарий → агент читает на следующем ходу
▪️ Автосборка ревью-диффов: git diff base...branch при request_review
▪️ UI на двух языках (RU/EN), тёмная тема, один янтарный акцент
▪️ ~112 тестов, Docker, MIT
Проверял в бою: codex и hermes ходят на одну доску, каждый берёт своё,
никакого связующего кода между ними.
🔗 github.com/graywrk/agent-kanban
Pull beats push.
Обычно оркестраторы агентов работают по пуш-модели: диспетчер решает,
кто что делает, и раздаёт задачи. Я сделал наоборот — доска пассивная,
агенты сами забирают работу через MCP. Как разработчик берёт тикет из
настоящего канбана, только тут агент вызывает get_next_task и claim_task.
Что под капотом:
▪️ 11 MCP-инструментов поверх streamable-HTTP (FastAPI + PostgreSQL)
▪️ Hard assignment — можно зарезервировать задачу за конкретным агентом,
остальные её просто не видят
▪️ Живая лента прогресса: агенты стримят диффы, артефакты, ошибки.
Пишешь комментарий → агент читает на следующем ходу
▪️ Автосборка ревью-диффов: git diff base...branch при request_review
▪️ UI на двух языках (RU/EN), тёмная тема, один янтарный акцент
▪️ ~112 тестов, Docker, MIT
Проверял в бою: codex и hermes ходят на одну доску, каждый берёт своё,
никакого связующего кода между ними.
🔗 github.com/graywrk/agent-kanban
Pull beats push.
GitHub
GitHub - graywrk/agent-kanban: AI-native kanban board where agents pull tasks via MCP
AI-native kanban board where agents pull tasks via MCP - graywrk/agent-kanban
👀3🔥1
Голосовой пульт для умного дома за два вечера, или как я мучил брелок за сорок баксов
Купил M5StickS3. Это ESP32-S3 с крошечным экраном, батарейкой, динамиком и кнопкой. Со стороны игрушка, но мне хотелось голосовой пульт: жмёшь кнопку, говоришь, локальный ассистент (Hermes) отвечает голосом. Ну и чтобы попутно показывал часы, погоду и что играет на колонке.
Получилось. Не с первого раза.
Шум на экране
С завода дисплей показывал снег. Снизу и слева. Оказалось, при программном повороте экрана надо поменять местами gap по осям. Не (52, 40), а (40, 52). Нигде об этом не написано. Поменял, шум исчез.
OTA
Сначала каждую прошивку заливал по проводу. Потом надоело. Собрал пайплайн: билдю бинарник, кидаю по scp на bridge, отправляю MQTT-команду reboot. M5 сам скачивает прошивку, шьёт второй слот, перезагружается. Если всё плохо, откатывается обратно.
За вечер двадцать с лишним выкаток.
Постукивание
Хотел переключение экранов двойным тапом. Сначала не работало вообще: порог стоял восемьсот милли-же, а реальный стук даёт триста-пятьсот. Потом ловил ложные срабатывания. Берёшь в руки, экран сам скачет.
В итоге сделал так: тапы детектятся только когда экран активен. Погас, движение только будит. Плюс две секунды после пробуждения тапы игнорируются, чтобы само движение подъёма не считалось кликом. Получилось как у нормальных девайсов. Поднял, загорелся, тапнул, сменил экран.
Память
Решил добавить BLE-маяк. NimBLE, WiFi и библиотека дисплея не влезли в IRAM. Переполнение на пять с половиной килобайт.
Час ковырял sdkconfig. Выкидывал в flash всё подряд: кэш-обходные либы SPIRAM, прерывания PHY, SPI, таймеров. Освободил шесть килобайт. Маяк влез, всё работает. Не понимаю, как люди вообще пишут под эмбеддед без боли.
Что в итоге
Голосовой терминал. Распознавание речи, синтез через Azure, мужской голос. MQTT в Home Assistant, сенсоры появляются сами. Голосовые уведомления: стиралка кончила стирать, M5 скажет. Четыре экрана: часы, система, климат, что играет. Двойной тап, пробуждение по движению. Звуковые бипы на события, потому что вибромотора тут нет. BLE-маяк.
Полтора мегабайта бинарника на чипе с восемью. ESP32-S3, оказывается, карманный компьютер.
#ESP32 #SmartHome #HomeAssistant #M5Stack #DIY
Купил M5StickS3. Это ESP32-S3 с крошечным экраном, батарейкой, динамиком и кнопкой. Со стороны игрушка, но мне хотелось голосовой пульт: жмёшь кнопку, говоришь, локальный ассистент (Hermes) отвечает голосом. Ну и чтобы попутно показывал часы, погоду и что играет на колонке.
Получилось. Не с первого раза.
Шум на экране
С завода дисплей показывал снег. Снизу и слева. Оказалось, при программном повороте экрана надо поменять местами gap по осям. Не (52, 40), а (40, 52). Нигде об этом не написано. Поменял, шум исчез.
OTA
Сначала каждую прошивку заливал по проводу. Потом надоело. Собрал пайплайн: билдю бинарник, кидаю по scp на bridge, отправляю MQTT-команду reboot. M5 сам скачивает прошивку, шьёт второй слот, перезагружается. Если всё плохо, откатывается обратно.
За вечер двадцать с лишним выкаток.
Постукивание
Хотел переключение экранов двойным тапом. Сначала не работало вообще: порог стоял восемьсот милли-же, а реальный стук даёт триста-пятьсот. Потом ловил ложные срабатывания. Берёшь в руки, экран сам скачет.
В итоге сделал так: тапы детектятся только когда экран активен. Погас, движение только будит. Плюс две секунды после пробуждения тапы игнорируются, чтобы само движение подъёма не считалось кликом. Получилось как у нормальных девайсов. Поднял, загорелся, тапнул, сменил экран.
Память
Решил добавить BLE-маяк. NimBLE, WiFi и библиотека дисплея не влезли в IRAM. Переполнение на пять с половиной килобайт.
Час ковырял sdkconfig. Выкидывал в flash всё подряд: кэш-обходные либы SPIRAM, прерывания PHY, SPI, таймеров. Освободил шесть килобайт. Маяк влез, всё работает. Не понимаю, как люди вообще пишут под эмбеддед без боли.
Что в итоге
Голосовой терминал. Распознавание речи, синтез через Azure, мужской голос. MQTT в Home Assistant, сенсоры появляются сами. Голосовые уведомления: стиралка кончила стирать, M5 скажет. Четыре экрана: часы, система, климат, что играет. Двойной тап, пробуждение по движению. Звуковые бипы на события, потому что вибромотора тут нет. BLE-маяк.
Полтора мегабайта бинарника на чипе с восемью. ESP32-S3, оказывается, карманный компьютер.
#ESP32 #SmartHome #HomeAssistant #M5Stack #DIY
👍3❤1
Научил Hermes генерить видосики с озвучкой моим голосом: https://youtube.com/shorts/MsjuIPvRupw?si=s6GC_46pht4FJAjx
YouTube
16 июля 2026 г.
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
Linux-курсы — мошенничество.
Нет, серьёзно. Платишь 100к за лекцию про права файлов.
Читаешь. Киваешь. Через неделю не помнишь, чем chmod 2750
отличается от 4750. И не вспомнишь, пока не сломаешь что-то
в проде.
CTF — другая крайность. Там не Linux, там security-кунг-фу.
«Найди уязвимость в легаси-сервисе за 10 шагов» — это не
практика сисадмина, это спортивное программирование с бейджами.
Хочется просто: открыл сайт, прочитал задачу, запустил
контейнер, потыкал руками, понял, проверился. Без VPN,
без VirtualBox, без курсов за 100к, без CTF-элитизма.
Собрал → labs.graywrk.ru
36 лабораторных. Реальный градиент:
easy — file-perms, symlink, sort-unique, tar-extract,
grep-extract, hostname-set, cron-entry
medium — kill-cpu-hog, stale-pid, remove-setuid, disk-hog
hard — fd-leak, recover-deleted через /proc/<pid>/fd,
supervisord-down, zombie-reaper, nginx-log-top,
perms-layered
Темы: filesystem, processes, permissions, config, security,
logs, recovery, internals. Это то, что реально всплывает
в on-call — а не «пойми теорию планировщика Linux за 4 часа».
Каждый раз: изолированный контейнер → терминал в браузере
(xterm.js, обычный bash) → делаешь руками → чекер проверяет
состояние системы → pass/fail с разбором.
Что в этом есть opinion:
→ Leaderboard различает «решал чисто» и «решал с подсказками».
Открыл hints — уже ниже в рейтинге. Учит не здаваться сразу.
→ Подсказки разбиты на секции (диагностика / исправление /
проверка). Можно открыть только наводящий шаг и не сдавать
весь ответ.
→ /proc-recovery, supervisord, setuid, zombie reaping —
учебных материалов по этому почти нет. Обычно это «случай
в проде», а не упражнение.
→ Нет SPA. Vanilla JS, Jinja2, никаких npm install.
Тёмная тема по дефолту.
→ Можно попробовать без регистрации.
Кому зайдёт:
→ джунам, которые устали от tutorial-hell
→ миддлам перед собеседованием
→ тимлидам, которые хотят дать джунам задания
без настройки стендов
→ https://labs.graywrk.ru
Критика и идеи по лабам — в комменты. Open-source,
152-ФЗ-compliant, без аналитики.
#devops #linux #sysadmin #практика
Нет, серьёзно. Платишь 100к за лекцию про права файлов.
Читаешь. Киваешь. Через неделю не помнишь, чем chmod 2750
отличается от 4750. И не вспомнишь, пока не сломаешь что-то
в проде.
CTF — другая крайность. Там не Linux, там security-кунг-фу.
«Найди уязвимость в легаси-сервисе за 10 шагов» — это не
практика сисадмина, это спортивное программирование с бейджами.
Хочется просто: открыл сайт, прочитал задачу, запустил
контейнер, потыкал руками, понял, проверился. Без VPN,
без VirtualBox, без курсов за 100к, без CTF-элитизма.
Собрал → labs.graywrk.ru
36 лабораторных. Реальный градиент:
easy — file-perms, symlink, sort-unique, tar-extract,
grep-extract, hostname-set, cron-entry
medium — kill-cpu-hog, stale-pid, remove-setuid, disk-hog
hard — fd-leak, recover-deleted через /proc/<pid>/fd,
supervisord-down, zombie-reaper, nginx-log-top,
perms-layered
Темы: filesystem, processes, permissions, config, security,
logs, recovery, internals. Это то, что реально всплывает
в on-call — а не «пойми теорию планировщика Linux за 4 часа».
Каждый раз: изолированный контейнер → терминал в браузере
(xterm.js, обычный bash) → делаешь руками → чекер проверяет
состояние системы → pass/fail с разбором.
Что в этом есть opinion:
→ Leaderboard различает «решал чисто» и «решал с подсказками».
Открыл hints — уже ниже в рейтинге. Учит не здаваться сразу.
→ Подсказки разбиты на секции (диагностика / исправление /
проверка). Можно открыть только наводящий шаг и не сдавать
весь ответ.
→ /proc-recovery, supervisord, setuid, zombie reaping —
учебных материалов по этому почти нет. Обычно это «случай
в проде», а не упражнение.
→ Нет SPA. Vanilla JS, Jinja2, никаких npm install.
Тёмная тема по дефолту.
→ Можно попробовать без регистрации.
Кому зайдёт:
→ джунам, которые устали от tutorial-hell
→ миддлам перед собеседованием
→ тимлидам, которые хотят дать джунам задания
без настройки стендов
→ https://labs.graywrk.ru
Критика и идеи по лабам — в комменты. Open-source,
152-ФЗ-compliant, без аналитики.
#devops #linux #sysadmin #практика
labctl
labctl — практические лабораторные по Linux и DevOps
Реальные задачи в изолированных контейнерах. Запустил — решил в терминале — чекер проверил.
👍3❤1