Hacker News Digest

Автор разместил свой личный сайт в сети Tor как скрытый сервис, доступный по .onion-адресу, который генерируется из открытого ключа и не требует DNS, сертификатов или раскрытия IP-адреса. Трафик шифруется end-to-end через сеть Tor, обеспечивая анонимность как пользователей, так и самого сервера — никакая сторона не может связать личность посетителя с его действиями или локацию хостинга.

Для настройки скрытого сервиса автор отредактировал файл /etc/tor/torrc, указав директорию для ключей и перенаправление порта 80 на локальный веб-сервер (127.0.0.1:8080). После перезагрузки Tor сгенерировал уникальный .onion-адрес, который был использован в конфигурации nginx для обслуживания статического сайта без TLS, поскольку шифрование обеспечивается Tor. Чтобы избежать перенаправления на clearnet-домен, сайт собирается дважды: один раз для обычного веба, второй — с базовым URL, равным .onion-адресом, используя Hugo с флагом --baseURL. Этот процесс автоматизирован в пайплайне деплоя через GitHub Actions, который синхронно обновляет обе версии сайта. Оба варианта — clearnet и Tor — поддерживаются в актуальном состоянии без ручного вмешательства. Сайт доступен в сети Tor по адресу dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion.

Размещение сайта в Tor реально, но требует ряда оптимизаций. Чтобы снизить нагрузку на соединения и компенсировать низкую пропускную способность, рекомендуется минимизировать HTTP-запросы, использовать серверный рендеринг, CSS-анимации и встраивать мелкие ресурсы через base64. Для ускорения загрузки можно внедрить HTTP/2 и HTTPS-сертификат. Технические рекомендации: — Добавить заголовок Onion-Location на clearnet-версию для автоматического предложения .onion-адреса в Tor Browser. — Привязывать HiddenServicePort к Unix-сокету или нестандартному локальному IP (не 127.0.0.1), чтобы упростить развертывание нескольких сайтов и избежать случайного доступа. — Обязательно резервировать приватный ключ сервиса, иначе при его потере придется менять адрес. — Не совмещать роль скрытого сервиса с ролью exit-ноды из соображений безопасности. Безопасность и доступность: — Против DDoS в Tor часто применяют двойные капчи. — Для защиты от фронтинга следует использовать уникальные заголовки и отдельные домены. — После перезапуска сервиса возможны задержки в доступности; рекомендуется использовать мосты (obfs4, snowflake) и fallback-механизмы. — v3-адреса длинные, а высокая латентность сети делает предпочтительным использование статического контента. Особенности и альтернативы: — Отсутствие DNS, сертификатов и публичного IP усложняет, но не исключает возможность деанонимизации сервиса государственными агентствами. — В качестве альтернатив с иными компромиссами по скорости и анонимности можно рассмотреть I2P и Yggdrasil.

Slop UI — это интерфейсы, сгенерированные ИИ без чёткой дизайнерской визии, которые выглядят дешево, перегружены и лишены смысла. Главные признаки — избыточные градиенты (особенно фиолетовые), случайные радужные сочетания цветов, пульсирующие бейджи, которые ничего не значащие эмодзи и избитые элементы вроде «fingernail cards» (скруглённые карточки, напоминающие ноготь). Эти приёмы используются повсеместно в vibe-coded интерфейсах, где ИИ просто заполняет шаблоны, не учитывая контекст или пользовательскую цель. Например, в обновлённом приложении колледжа появился пульсирующий бейдж «active» на цифровом ID, хотя приложение выходит из системы при неактивности — информация полностью избыточна. Аналогично, бейдж «verified» рядом с логотипом вуза не подкреплён реальной проверкой и не несёт смысловой нагрузки.

Дополнительные признаки slop — стеклянный эффект (glassmorphism), шаблонные хайп-слоганы вроде «Elevate», «Seamless», «Next-Generation» и избыточная самореклама в интерфейсе (например, «Built with Hugo. Written from Neovim» на экране загрузки). Такие детали не улучшают usability, а лишь выдают отсутствие продуманного дизайна. Автор подчёркивает, что vibe-coding сам по себе не плох — его сайт тоже так сделан и выглядит мило — но проблема в том, что многие используют ИИ как «slop cannon»: генерируют интерфейсы без фильтра, усилий и чувства меры, получая в результате визуальный шум вместо функционального инструмента.

Slop UI — это не неизбежный результат работы ИИ, а следствие неконтролируемого использования LLM, отсутствия человеческого надзора и обучения моделей на некачественных данных. Многие его признаки (карточки, карусели, избыточные градиенты) повторяют плохие практики доэпохи ИИ, однако современные шаблоны (пульсирующие бейджи, «fingernail cards», двойные слеши) уже распознаются пользователями и снижают доверие. Существуют споры о том, является ли Slop UI ухудшением дизайна или просто сменой одного набора шаблонов на другой, а также о том, исчезнут ли эти признаки с развитием моделей или останутся из-за неквалифицированного использования. Для предотвращения Slop UI рекомендуется: — использовать четкие инструкции в промптах (например, запрет на serif-шрифты или избыточные анимации fade-in); — применять цепочку рассуждений: от бренд-гайдлайнов и вайрфреймов к интеграции; — создавать собственную дизайн-систему на CSS-токенах и Vue-компонентах, запрещая генерацию произвольного HTML; — использовать LLM только для вдохновения, не копируя макеты напрямую; — выносить тексты в отдельные файлы (i18n) и редактировать их вручную, чтобы избежать шаблонных фраз и неестественных слоганов; — запрещать вывод технических комментариев в интерфейс. Опытные пользователи отмечают, что создание качественного UI с помощью ИИ требует больше времени и усилий, чем ручной дизайн, из-за необходимости постоянной фильтрации и корректировки. Самые частые признаки Slop UI: вложенные карточки, фон «под пергамент», бесполезные дашборды и неоправданный Caps Lock.

Автор перевел свой блог с 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 и другие.
• Подчёркивание важности личного выбора, удовольствия от процесса и независимости от внешних сервисов при создании блога.

Блог работает на переработанном Google Pixel 5

Вдохновившись постами в Mastodon о сайтах на ESP32 и Android-солнечных панелях, решил запустить блог с телефона. Успешно: вы это читаете.

Железо

• Google Pixel 5, от Verizon, без разблокировки загрузчика.
• Поддержка USB-OTG и Ethernet-адаптера.
• Питание: 100 Вт солнечная панель + Jackery 160 Вт — сайт полностью автономен.

Софт
Termux + Hugo из репозитория. Пакеты: git, screen, openssh, hugo, dufs (веб-загрузка файлов).
Сервисы: sshd, cronie через sv-enable.

Опыт
Первые сутки — разные версии Hugo и контроль заряда. Сейчас всё стабильно и быстро; внешне не отличить от VPS.

Планы: не трогать, пока не сломается.

• Автор запустил личный блог на старом Google Pixel 5, питая его от солнечной панели и аккумулятора, чтобы продемонстрировать энергоэффективность и повторное использование техники.
• Участники отмечают, что современные ARM-смартфоны потребляют <5 Вт против 50–100 Вт у x86-сервера, что экономит до 800 кВт·ч в год.
• Обсуждаются риски: старые аккумуляторы при 24/7 работе могут «раздуться» и вызвать пожар, поэтому предлагаются варианты безбатарейного питания по USB-PD.
• Вопросы безопасности: Pixel 5 уже не получает обновлений, а Termux-окружение может ломаться из-за несовместимости пакетов.
• Некоторые считают идею интересной, но для статического сайта дешевле и надёжнее использовать GitHub Pages или S3.