Hacker News Digest

WebDAV всё ещё жив и может быть отличной альтернативой AWS S3 для многих пользователей. Автор критикует повсеместное использование S3, которое удобно Amazon, но создаёт проблемы для остальных. Для личных проектов, самостоятельного хостинга или базовых файловых операций WebDAV предлагает простое решение с необходимым функционалом: аутентификация, запись файлов, синхронизация, приватность по умолчанию и лёгкий доступ к публичным файлам. При этом не требуются сложные ACLs, подписанные URL, версионирование или многоуровневое хранилище.

Многие инструменты уже поддерживают WebDAV — от Finder и Explorer до rclone и curl. Интересно, что WebDAV активно используется для синхронизации контактов и календарей через CardDAV и CalDAV. Автор приводит пример конфигурации Apache с LDAP-аутентификацией, которая обеспечивает изолированный доступ пользователей к их личным директориям. Среди приложений, использующих WebDAV в его setup: Joplin для заметок, Keepassium для паролей, VLC и Infuse для медиа.

• WebDAV и FTP продолжают использоваться, но вопросы безопасности и производительности остаются открытыми.
• S3-совместимые API становятся де-факто стандартом, но не всегда это оправдано.
• Пользователи сталкиваются с отсутствием нормальной поддержки WebDAV в инструментах вроде Nextcloud, что ведёт к необходимости использовать сторонние решения.
• Проекты вроде Alist и rclone предоставляют обёртки вокруг различных протоколов, включая WebDAV, S3 и FTP.

Выпущена StringZilla v4 — первая версия библиотеки для обработки строк с поддержкой CUDA, которая ускоряет вычисления на GPU. Она обеспечивает до 500 гигаопераций в секунду для расчёта расстояний Левенштейна и других метрик схожести строк, что в 109 раз быстрее решений на NVIDIA H100. Библиотека оптимизирована для больших объёмов данных в базах данных, биоинформатике и информационном поиске, включая алгоритмы с аффинными штрафами за разрывы и мини-хэширование.

Новые функции включают хэш-функции на основе AES, генераторы псевдослучайных строк и алгоритмы сортировки для работы с коллекциями строк. StringZilla использует SIMD-инструкции на CPU и GPU, поддерживает несколько архитектур и языков программирования. Библиотека распространяется под лицензией Apache 2.0 и доступна через pip, предлагая надёжный и быстрый базис для масштабируемых workloads.

After publishing this a few days ago, 2 things have happened.First, it tuned out that StringZilla scales further to over 900 GigaCUPS around 1000-byte long inputs on Nvidia H100. Moreover, the same performance is obviously accessible on lower-end hardware as the algorithm is not

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.

Кратко:
Разработчик ICEBlock (приложение для анонимных доносов на ICE) проигнорировал мой отчёт об уязвимости. 1 сентября я сообщил, что его сервер на Apache 2.4.57 содержит критические CVE, и попросил обновиться до публикации критического поста. В ответ — блокировка и обвинения во лжи. Через два дня уязвимость всё ещё не закрыта; исправление занимает одну команду apt upgrade.

• Автор сообщил разработчику ICEBlock о «уязвимости» (устаревший Apache), но дал всего 90 минут до публикации критичной статьи — это не responsible disclosure.
• Большинство участников считают «уязвимость» фейком: версия могла быть за-патчена дистрибутивом, PoC отсутствует, эксплуатация не доказана.
• Пост воспринимается как «activism theater»: автор смешал политическую критику приложения и технический аудит, что выглядит как хит-пьеса.
• Разработчик заблокировал автора после первого демонстративного поста; сообщество считает реакцию понятной.
• Вывод: ни сторона автора, ни сторона ICEBlock не выглядят профессионально — шум вокруг пустяковой «уязвимости» никому не помог.

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» диагностики пока нет.

Стек для 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) или вообще отказаться от контейнеров.
• Обсуждение выродилось в дискуссию о «культуре овер-инжиниринга» и самоучках, использующих сложные инструменты без понимания базовых.

Две версии Parquet

DuckDB недавно описали, как SQL-движки, не реализовав полностью спецификацию Parquet, тормозят её развитие. То же происходит в экосистеме: после выхода моей библиотеки Carpet я включил v2 по умолчанию, но быстро откатил изменение — устаревший Pandas не читал такие файлы.

Почему v2 не внедрён

Спецификация готова, но нет согласия, какие именно фичи считать «ядром» v2. Обсуждение в apache/parquet-format длится четвёртый год. Смешиваются два независимых направления:

• новые кодировки (RLE_DICTIONARY, DELTA_BYTE_ARRAY) — ломают только столбец;
• новая структура страниц (Data Page V2) — ломает весь файл.

Логические типы (например, VARIANT) не привязаны к версии формата.

Альтернативы

В ML-среде Parquet и ORC стали тесны, поэтому появились форматы Nimble (Facebook) и LV2 (LanceDB), но в data-engineering Parquet остаётся королём.

Производительность v2

Достаточно выставить WriterVersion.PARQUET_2_0.

Датасет	Алгоритм	v1, МБ	v2, МБ	Δ
Италия	без сжатия	564	355	–37 %
Италия	SNAPPY	220	198	–10 %
NYC	без сжатия	760	511	–33 %
NYC	SNAPPY	542	480	–11 %

Новые кодировки лучше уплотняют данные до компрессии, поэтому выигрыш больше у несжатых файлов, а у ZSTD размер даже немного вырос.

• Parquet разделён на две версии: v2 экономит место и ускоряет чтение, но экосистема (Spark, Iceberg, Delta Lake и др.) всё ещё в основном на v1.
• Справочная реализация — гигантская Java-библиотека с 74 000 строк кода на каждую комбинацию кодировки, что вызывает сомнения в оптимальности.
• Совместимость между библиотеками (PyArrow, Fastparquet, Spark) долго была проблемой, как и разные версии Scala в Spark.
• Даже простые оптимизации (мета-данные о сортировке) фактически не используются, а многие разработчики не знали о существовании v2.
• Несмотря на критику, Parquet всё равно крупный шаг вперёд по сравнению с предыдущими форматами, и вопросы скорее в медленной эволюции стандарта, чем в самой идее.

AGENTS.md — открытый формат инструкций для AI-агентов, используется >20k проектов.
Это «README для агентов»: единое место для команд сборки, тестов, стиля кода и прочих деталей, которые не нужны людям, но критичны для ИИ.

## Команды
- `pnpm i` — зависимости  
- `pnpm dev` — запуск  
- `pnpm test` — тесты  

## Стиль
TypeScript strict, одинарные кавычки, без точек с запятой, функциональный стиль.

Зачем отдельный файл?

• README — для людей, AGENTS.md — для агентов.
• Не загромождает документацию.
• Один формат подходит всем: Codex, Amp, Jules, Cursor, Factory, RooCode и др.

Как использовать

1. Создайте AGENTS.md в корне.
2. Добавьте: обзор проекта, команды сборки/тестов, стиль, security, правила PR.
3. В монорепозиториях кладите отдельные файлы в каждый пакет; агент читает ближайший.

Примеры

• openai/codex
• apache/airflow
• temporalio/sdk-java
• PlutoLang/Pluto

Ещё 20k примеров

• Участники спорят, нужен ли отдельный AGENTS.md или достаточно README/CONTRIBUTING.
• Одни считают файл полезной «эргономичной ручкой» — люди охотнее пишут инструкции для ИИ, чем для людей.
• Другие критикуют: это не формат, а просто соглашение; нет импортов, иерархии, стандарта между агентами.
• Практики варьируются: кто-то хранит роль-файлы в .agent, кто-то делает симлинки на CLAUDE.md, кто-то использует .agdocs/guides/.
• Общий вывод: AGENTS.md пока временный костыль, пока ИИ не научится полноценно читать человеческую документацию.

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.