Talk Python in Production – это книга, которая учит разворачивать Python-приложения без привязки к облачным провайдерам. Вместо микросервисов и Kubernetes автор предлагает «stack-native» подход: один мощный сервер, Docker Compose, NGINX и минимум внешних сервисов. Книга сопровождается GitHub-репозиторием с примерами кода, конфигами и скриптами CI/CD, а также готовыми Docker-образами.

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

Хостинг сайта на одноразовой вейп-системе

Примечание: эта статья НЕ размещена на сервере, работающем на одноразовой вейп-устройстве. Реальный пример можно посмотреть здесь.

Предыстория

Я несколько лет собирал одноразовые вейпы от друзей и семьи, изначально извлекая из них батареи для «будущих» проектов. Современные устройства стали сложнее: с USB-C и перезаряжаемыми аккумуляторами. При разборе одного из таких устройств я обнаружил микроконтроллер PUYA — ARM Cortex-M0+.

Технические характеристики

Микроконтроллер PY32F002B имеет:

• 24 МГц Cortex-M0+
• 24 КБ флеш-памяти
• 3 КБ оперативной памяти
• Несколько периферийных устройств (не использовались)

Подключение к сети

Идея использовать вейп как веб-сервер пришла после экспериментов с semihosting — системными вызовами для embedded-микроконтроллеров.

Для связи использовался протокол SLIP (Serial Line Internet Protocol), эмулирующий модемное соединение через последовательный порт. С помощью pyOCD и socat создаётся виртуальный tty-интерфейс:

pyocd gdb -S -O semihost_console_type=telnet -T $(PORT) $(PYOCDFLAGS) &
socat PTY,link=$(TTY),raw,echo=0 TCP:localhost:$(PORT),nodelay &
sudo slattach -L -p slip -s 115200 $(TTY) &
sudo ip addr add 192.168.190.1 peer 192.168.190.2/24 dev sl0
sudo ip link set mtu 1500 up dev sl0

Для работы с TCP/IP был выбран легковесный стек uIP, не требующий RTOS и легко портируемый на другие платформы.

• Обсуждается использование дешёвых и мощных китайских LTE-донглов и одноразовых вейпов (например, с чипом Qualcomm MSM8916) в качестве мини-компьютеров для нестандартных задач, включая хостинг веб-сервера.
• Участники выражают возмущение расточительством и экологическим ущербом от одноразовых вейпов, содержащих полноценные микроконтроллеры, перезаряжаемые батареи и иногда даже цветные дисплеи или Bluetooth.
• Подчёркивается технологический парадокс: устройства с вычислительной мощностью, превосходящей старые компьютеры (например, Commodore 64), становятся одноразовыми и массово выбрасываются.
• Отмечается юридический и этический аспект: классификация устройств с USB-C и аккумулятором как "одноразовых" вызывает вопросы, особенно в регионах с запретом на подобные изделия.
• Хакерский проект по запуску веб-сервера на вейпе воспринят как креативный и вдохновляющий пример вторичного использования электроники, характерный для духа Hacker News.
• Обсуждаются технические детали реализации: использование SLIP/PPP, Perl, nginx для балансировки нагрузки, а также шуточные предложения вроде запуска Doom или облачного хостинга ("vaperware").
• Упоминается проблема утилизации: несмотря на законодательные ограничения в ЕС, устройства часто выбрасываются с обычным мусором, что усугубляет проблему электронных отходов.
• Участники шутят о "объятиях смерти" от трафика Hacker News (ошибка 503) и предлагают идеи для повторного применения устройств (например, автоматические кормушки для животных).
• Поднимается вопрос о целесообразности столь мощных ядер (Cortex-M0) в одноразовых устройствах и дешевизне их производства, что делает их доступными для экспериментов.

NGINX теперь с ACME
12 авг. NGINX официально добавил встроенный модуль ngx_http_acme (на Rust), который сам получает и продлевает сертификаты Let’s Encrypt.

Зачем

• никаких внешних клиентов;
• работает из коробки: от домашнего лаба до кластеров Kubernetes;
• меньше рутины, больше шифрования.

Кто ещё
Traefik, Caddy, Apache уже умеют; теперь к ним присоединился самый популярный веб-сервер и прокси.

Разработчикам
Протокол ACME, библиотеки и обсуждение — на форуме Let’s Encrypt.

• Кто-то рад встроенному ACME в nginx, кто-то считает, что «сертификат должен получать отдельный клиент», а не каждый сервис в отдельности.
• Спор о безопасности: модуль на Rust, но в нём много unsafe-блоков для взаимодействия с Си-ядром nginx.
• Вопрос «зачем ждать столько лет?» — ответ: корпоративные заказчики F5/medленный релиз-цикл.
• Практика: можно отключить встроенный ACME и продолжать использовать certbot/cert-manager.

• Унаследовал iPad 2 на iOS 9: тормоз и нет приложений.
• Спустились до iOS 6.1.3 через jailbreak + Legacy-iOS-Kit: летает, красиво.

Что делать:

• Cydia: iFile, iTransmission, f.lux, старые игры без IAP.
• Через SSH root-доступ: учимся хостингу.

План: запустить блог на iPad и вывести в интернет.

1. lighttpd из Cydia – весит мало.
2. Jekyll-сайт закинул по SCP – открывается в Wi-Fi.
3. Туннели:
   – localhost.run: старый SSH не принимает RSA, домены случайные, платные.
   – Свой VPS + autossh: OpenSSL 0.9.8 ≠ современные алгоритмы, отказ.
4. Порт-форвард: роутер пускает наружу 80-й на iPad; VPS проксирует nginx → домен.
5. Uptime 3 дня, греется, но работает: старый планшет = живой сервер.

• Пользователь поднял iPad 2 2012 г. как веб-сервер, но сайт быстро выдал 502-ошибку Cloudflare.
• Комментаторы жалуются: Apple прекращает поддержку, устройство нельзя поставить Linux, оно превращается в «электронный хлам».
• Обсуждаются jailbreak, UTM, iSH, Termux+X11, но все способы ограничены, частично «тетеринг» и требуют копаться в сомнительных инструкциях.
• Кто-то делает из старых панелей Home Assistant, кто-то — настенные часы, но батарея всё равно периодически садится даже от сети.
• Общий вывод: пока Apple официально не разрешит ставить альтернативные ОС, старые iPad остаются либо музейными экспонатами, либо выбросом.

Ключевые выводы исследования Cisco по обнаружению открытых серверов Ollama

• Цель: выявить уязвимые LLM-серверы, запущенные через фреймворк Ollama.
• Метод: Python-скрипт, сканирующий Shodan на признаки открытых API /api/tags, /api/ps, /api/chat.
• Результаты: найдено >1 100 публичных инстансов; ~20 % допускают анонимный чат и загрузку моделей.
• Риски: утечка данных, DoS, финансовые потери (GPU-трафик), инъекция вредоносных моделей.
• Рекомендации:
  • включить авторизацию и TLS;
  • фильтровать IP-адреса;
  • отключить --network host;
  • использовать reverse-proxy (nginx, traefik) и WAF;
  • регулярно сканировать инфраструктуру.

• Cisco сообщила об открытых в интернете >1 100 серверов Ollama без аутентификации.
• Ollama по умолчанию не требует пароля и не планирует встроенной защиты API.
• Пользователи решают проблему через firewall, nginx/caddy с токеном или VPN.
• Сообщество спорит: виноваты ли разработчики, админы или «вайб-кодеры».
• Многие считают риск низким, пока 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.

LandChad.net учит запускать сайты, почту и чаты за пару часов и копейки.
Базовый курс (≈1 ч):

1. Домен
2. Сервер
3. DNS
4. Nginx
5. HTTPS (Certbot)

Свои сервисы: Alps (почта), Calibre (библиотека), Cgit, Coturn, Dnsmasq, DokuWiki, ejabberd, Fosspay, Git, Gitea, i2p, IRC, Jitsi, Matrix (Synapse/Dendrite), Monero, Mumble, Nextcloud, PeerTube, Pleroma, Prosody, Radicale, Rainloop, RSS-Bridge, SearXNG, Tor, Transmission, WireGuard, Yarr.

Почтовый курс (≈1 ч + 1 день на открытие портов):

1. SMTP
2. rDNS
3. DNS-записи
4. Входящая почта
5. Защита

Администрирование: Certbot, Cron, Gemini и др.

• Участники спорят, что название «landlord»/«landchad» некорректно: арендуя VPS и домен, ты всё равно арендатор, а не собственник.
• Многие хвалят сайт за простые гайды по самостоятельному хостингу, но отмечают, что материал рассчитан на «интернет-сантехников», а не новичков.
• Поднят вопрос о бесполезности собственного почтового сервера из-за попадания писем в спам; однако некоторые пишут, что у них всё работает без проблем.
• Ключевой пробел — почти нет информации о надёжных бэкапах и восстановлении.
• Упоминаются риски юридического преследования за несоблюдение регуляций и то, что мобильный интернет сместил фокус с «домашних» сайтов.

TuneD — служба тонкой настройки Linux.

• Отслеживает устройства через udev, применяет профили, управляется из CLI и D-Bus.
• Поддерживает sysctl, sysfs, параметры ядра, плагины.
• Работает без демона на ограниченных системах.
• Всё хранится в одном профиле, без разбросанных скриптов.

Профили

• Наследуются: общий HTTP-шаблон → Apache, Nginx.
• Полный откат изменений.
• Готовые пресеты: высокая пропускная способность, низкая латентность, энергосбережение, SAP, dBase и др.

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

• Старая: Fedora Power Management Guide.
• Новая: GitHub.
• Презентация: DevConf 2019.

Скачать
GitHub releases.

Баги
GitHub issues.

Разработка
GitHub.
PR или письма на power-management@lists.fedoraproject.org.

Лицензия
GPL v2+.

• TuneD хвалят за экономию до 40-55 Вт и удобство на рабочих станциях, но на серверах результат «50/50»: иногда отключают и переходят на собственные скрипты.
• Есть адаптер под power-profiles-daemon, поэтому переключать профили можно из GNOME/KDE.
• Критика: дефолтные настройки неверно биндят IRQ для сети, а сам демон написан на Python, что вызывает сомнения в «производительности» инструмента для управления производительностью.
• Нет встроенного ограничения заряда батареи (как в TLP), поэтому для ноутбуков TuneD может быть не идеален.
• Пользователи хотели бы утилиту, которая после установки Linux сразу показывает, что не работает (suspend, GPU, Wi-Fi, диск), но такой «one-shot» диагностики пока нет.

ghrc.io — опечатка к ghcr.io — маскируется под реестр контейнеров, но крадёт GitHub-токены.

Как работает атака

• Обычные пути (/, /404) возвращают стандартную страницу nginx.
• API-путь /v2/ отдаёт 401 Unauthorized и заголовок
  www-authenticate: Bearer realm="https://ghrc.io/token".
  Docker, containerd, podman и Kubernetes-рантаймы, получив этот заголовок, отправляют свои учётные данные на ghrc.io/token.

Когда утекут токены

• docker login ghrc.io
• GitHub Action docker/login-action с registry: ghrc.io
• Секрет Kubernetes для ghrc.io

Простой docker pull ghrc.io/… без логина не передаёт токенов.

Что делать

Если вы когда-либо логинились на ghrc.io:

1. Смените пароль GitHub.
2. Отзовите все PAT и OAuth-токены.

• Пользователи обсуждают, что домен-ошибка ghrc.io (вместо правильного ghcr.io) уже зарегистрирован и может использоваться для атак.
• Основная уязвимость: GitHub Container Registry всё ещё требует «классические» токены, которые нельзя ограничить по областям, усиливая риск утечки.
• Многие открытые проекты уже ошибочно используют ghrc.io в конфигах CI/CD, что делает атаку массовой.
• Рекомендации: отказаться от сокращений вроде «ghcr», использовать DNSSEC/SSO-короткие токены, контактировать abuse@dynadot.com для блокировки злоумышленного домена.

Стек для Python-статики: uv + Caddy + Docker

Я почти полностью перешёл на uv — он быстрый, удобен и сам ставит нужный Python. Статические сайты собираю Python-скриптами, а раздаю через Caddy в многоступенчевом Docker-контейнере.

Пример на sus

Dockerfile (сжато):

FROM ghcr.io/astral-sh/uv:debian AS build
WORKDIR /src
COPY . .
RUN uv python install 3.13
RUN uv run --no-dev sus

FROM caddy:alpine
COPY Caddyfile /etc/caddy/Caddyfile
COPY --from=build /src/output /srv/

1. Берём образ с uv, копируем код.
2. uv ставит Python 3.13 и зависимости, запускает sus, который кладёт сайт в /output.
3. Вторая стадия — лёгкий Caddy. Копируем конфиг и готовые статические файлы в /srv.

Caddyfile минимален:

:80
root * /srv
file_server

Запуск:

docker build -t sus .
docker run -p 80:80 sus

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

• Почти все комментаторы считают выбранный стек (Docker, uv, Caddy, Coolify) избыточным для статического личного сайта.
• Критика сводится к тому, что достаточно «HTML → Nginx/Apache» или даже «HTML → FTP».
• Автор отвечает: хотел остаться в экосистеме Coolify ради единого CI/CD и «zero-SSH» деплоя.
• Некоторые предлагают минимальные Dockerfile (nginx:alpine + COPY) или вообще отказаться от контейнеров.
• Обсуждение выродилось в дискуссию о «культуре овер-инжиниринга» и самоучках, использующих сложные инструменты без понимания базовых.

Кратко: плагин nvim-web-server на чистом Lua отдаёт HTTP-запросы прямо из открытых буферов Neovim, без внешних зависимостей, с нативной поддержкой Djot и быстрее Nginx.

Почему так быстро?

• Однозадачность: только статика.
• libuv + асинхронный I/O Neovim.
• LuaJIT: NaN-тегинг, отсутствие boxing чисел, allocation sinking.
• aiohttp тормозит из-за парсера на чистом Python и boxing в CPython.

Бенчмарк, RPS (среднее):

сервер	1	50	100	200	400
nvim-web-server	3981	15284	15124	14476	14446
Nginx	4451	11306	11576	10011	10461
aiohttp	6391	8477	8448	7696	7132

Развёртывание: живёт на старом ThinkPad, 9 буферов — весь сайт.

Безопасность: да, но мелочи мы игнорируем.

• Пользователи в восторге от статьи: называют её «одной из любимейших» и приводят цитату «они были так заняты тем, могут ли, что не спросили себя, стоит ли».
• Кто-то отмечает, что сайт резолвится на IP Linode, но не объясняется, зачем нужен промежуточный сервер.
• Обсуждают безопасность: пример показывает, что «никогда не бывает так, чтобы код точно не запустили по сети».
• Некоторые шутят, что Neovim теперь можно считать кроссплатформенным рантаймом «ужаса», но признают крутость эксперимента.
• Предполагают, что высокая скорость может быть из-за хранения файлов в RAM, а не на диске, и что всё равно всё закешируется.

Debian 13 «trixie» вышел 9 августа 2025 года после 2 лет разработки.
Поддержка — 5 лет (Security + LTS).

Десктопы: GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1, Xfce 4.20.
Пакетов: 69 830 (+14 100 новых, –8 840 устаревших, 44 326 обновлённых).
Размер: 403 ГБ, 1,46 млрд строк кода.
Ядро: 6.12 LTS; первый релиз с официальной поддержкой riscv64.
Архитектуры: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x.
i386 больше не поддерживается; armel последний релиз.

Ключевые обновления: Apache 2.4.64, Bash 5.2.37, BIND 9.20, GCC 14.2, LibreOffice 25.2, MariaDB 11.8, Nginx 1.26, OpenJDK 21, PHP 8.4, PostgreSQL 17, Python 3.13, Rust 1.85, systemd 257 и др.

Облако: образы для EC2, Azure, OpenStack, PlainVM, NoCloud с cloud-init и оптимизированным загрузчиком.
Live-образы: amd64/arm64, GNOME/KDE и др.; установка через Calamares или стандартный установщик.

• Debian 13 «Trixie» вышла: 63 % пакетов обновлены, поддержка 7 архитектур, включая RISC-V.
• i386 теперь только как «amd32»-совместимый, официального ядра/инсталлятора нет.
• Появился новый формат APT-репозиториев debian.sources, старый sources.list пока работает.
• 95 % пакетов достигают bit-for-bit воспроизводимости на amd64/arm64/riscv64.
• /tmp теперь tmpfs по умолчанию (до 50 % ОЗУ), но можно вернуть старое поведение.
• Пользователи хвалят стабильность, скорость обновления «stable→stable» и отсутствие snap.

OpenFreeMap выдержал 100 000 запросов/с

Внезапно сервис получил 3 млрд запросов за сутки и 215 ТБ трафика.
Пиковая нагрузка — 100 000 rps.
Стоимость такого трафика у конкурентов превысила бы $6 млн/мес.

Единственный замеченный сбой — nginx жаловался на «слишком много открытых файлов», но 96 % запросов успешно обслужены (200 OK), лишь 3,6 % вернули 206 Partial Content.
Система продолжала работать, Cloudflare кешировал даже «пустые» тайлы.

Причина всплеска — новый коллаборативный сайт рисования wplace.live, построенный на OpenFreeMap и ставший вирусным.

• На фоне внезапного хайпа wplace.live (2 млн пользователей, 3 млрд запросов) бесплатный OpenFreeMap получил «объятие смерти» ~1 000 rps, что выявило узкое место в лимите открытых файлов nginx.
• Автор OFM защитил решение ограничить по Referrer и отказаться от IP-рейт-лимита, чтобы не блочить обычных пользователей.
• Часть комментаторов считает, что бесплатный сервис не обязан выдерживать такую нагрузку; другие спорят, кто виноват — отсутствие лимитов или неожиданный виральный проект.
• Обсуждаются альтернативы: Cloudflare-only хостинг, PMTiles-файлы, self-host, но все сходятся, что 96 % доступности при таком наплыве — уже успех.