Hacker News Digest

Big O — способ описать, как время работы функции растёт с ростом входных данных, без привязки к конкретным секундам.

Рассмотрим 4 основные категории:

---

O(n) — линейное время

function sum(n) {
  let total = 0;
  for (let i = 1; i <= n; i++) total += i;
  return total;
}

• sum(1e9) ≈ 1 с
• sum(2e9) ≈ 2 с
  Время пропорционально n.

---

O(1) — константное время

function sum(n) {
  return (n * (n + 1)) / 2;
}

• sum(1e9) и sum(100e9) выполняются почти мгновенно.
  Время не зависит от n.

---

Ключевые идеи

• O = «order of growth»; описывает рост, а не абсолютное время.
• O(1) ≠ «быстро», а «не растёт с размером входа».
• При достаточно большом n O(1) всегда обгонит O(n).

• Обсуждение статьи о нотации Big O разделилось на «лайтовое» восхищение визуализациями и «экспертные» споры о точности определений.
• Новички признаются, что статья впервые открыла им глаза на сложность алгоритмов, а ветераны IT спорят, что за 40 лет ни разу не пригодилась.
• Критика сводится к тому, что автор описывает «поп-культурный» вариант Big O, путая его с Θ-нотацией и worst-case.
• Практики напоминают: на реальном железе константы, кэш и NUMA могут перечеркнуть асимптотику, а O(n²) при малых n часто быстрее «константного» хэша.
• Люди делятся шпаргалками (bigocheatsheet.com, visualgo.net) и просят ещё интерактивных уроков.

DeepWiki — сервис от создателей Devin, который мгновенно превращает любой GitHub-репозиторий в интерактивную вики.
Просто замените github.com на deepwiki.com и задавайте вопросы без чтения кода.

8 практических приёмов

1. Разведка репозитория
   За 2 минуты получаю архитектуру, ключевые модули и точки расширения.

2. Контекст для агентов
   Копирую сводку в Claude/Cursor, чтобы сразу писать релевантный код.

3. Быстрый старт
   Генерирую README-инструкции по запуску без ручного изучения docker-compose.yml.

4. Поиск «кухонных» деталей
   Уточняю, где хранятся env-переменные, какие скрипты npm run доступны и т.д.

5. Сравнение форков
   Загружаю две вики и спрашиваю: «Что добавлено в форке X по сравнению с оригиналом?»

6. Онбординг новичков
   Раздаю ссылку на вики вместо 30-минутных экскурсий по коду.

7. Проверка зависимостей
   Запрашиваю список уязвимых пакетов и актуальные версии.

8. Документация API
   Прошу сгенерировать примеры вызовов REST-endpoints прямо из кода.

Ограничения

• Публичные репозитории работают сразу.
• Приватные — через GitHub OAuth с нужными правами.
• Нет поддержки SVN и Mercurial.

DeepWiki экономит часы при изучении чужого кода и делает LLM-агентов значительно точнее.

• DeepWiki вызывает противоречивые ощущения: кто-то хвалит автодиаграммы и «глубокие» ответы, кто-то ругает за неточности и «AI-slop».
• Пользователи LibreOffice, PureLB и других проектов жалуются на ложную документацию и баг-репорты, которые тратят время мейнтейнеров.
• Некоторые считают, что диаграммы слишком абстрактны и не привязаны к реальному коду.
• Появились попытки сделать open-source/локальные аналоги, но официального способа «выключить» DeepWiki для своего репозитория пока нет.

Seed — интерактивная среда разработки на Common Lisp.
Позволяет писать, отлаживать и запускать код в одном окне, поддерживает REPL, графику и встроенные библиотеки.
Подходит для прототипирования, научных задач и обучения.

• Проект Seed вызывает интерес, но README скуден: не хватает скриншотов и понятного описания.
• Многие сравнивают его с CLOG, который лучше документирован, активнее и имеет больше примеров.
• Разработчик (phantomics) заверяет: Seed не заброшен, старый код заморожен, а новый ветви revival ведётся переписывание.
• Старый Seed можно глянуть на Vimeo и YouTube; новый всё ещё требует Node.js только для сборки JS-библиотек, но не для рантайма.
• Пользователи просят встроить демо прямо в README и убрать зависимость от Node/Gulp, а кто-то мечтает запустить Seed на Mezzano.

Разрабатывая CLI-утилиту, я хотел избежать тормозов при тестах из-за fstat, как это было в Bundler. Решил попробовать in-memory FS, как в Go-библиотеке Afero.

В Rust аналогов нет: спросишь — получишь лекцию «в Rust это не нужно». Нашёл два кандидата:

• vfs — поддерживает swap-бэкендов, но без симлинков и прав, а главное — нельзя создавать исполняемые файлы.
• rsfs — старый, почти заброшенный; требует параметризовать весь код типом rsfs::FS, превращая сигнатуры в кашу.

Провёл бенчмарк: vfs, rsfs, ramdisk и обычный SSD — всё показывает ~45 мс. Современные SSD + кеш ОС настолько быстры, что экономия на syscalls незаметна.

Вывод: тестируй прямо на файловой системе — проще и не медленнее.

• Позикс-семантика сложна, поэтому самописная in-memory реализация почти всегда хуже по качеству, чем готовые tmpfs/ramfs.
• Для быстрых тестов достаточно /tmp (часто tmpfs) или /dev/shm — это дёшево и использует проверенный ядром код.
• SSD и кэши ОС настолько быстры, что даже обычное файловое I/O редко становится узким местом; CPU и syscalls чаще ограничивают.
• Несколько участников пожелали стандартным traits для файловой системы, как в Go (fs.FS, afero), но признают, что в std Rust это уже трудно.
• Основная цель обсуждаемого vfs-крейта — встраивать файлы в бинарь, а не мокать диск; об этом автор плохо сообщил в README.

Как превратить старый iPhone в камеру UniFi Protect

Переехав на экосистему UniFi, я захотел добавить в Protect ещё одну камеру. Под рукой оказался старый iPhone — компактный «мини-ПК» с хорошей камерой. Официально Protect работает только с UniFi-камерами, но поддерживает сторонние устройства через ONVIF.

В App Store не нашёл приложений, которые напрямую транслируют по ONVIF, зато понял: ONVIF лишь «рукопожатие», а сам поток идёт через RTSP. Значит, схема такая:

iPhone (RTSP) → ONVIF-прокси → Protect

1. RTSP-поток с iPhone
   Установил IP Camera Lite (бесплатный тестовый режим). Настроил поток:
   rtsp://admin:admin@192.168.17.189:8554/live
   Проверил через ffplay — картинка и звук пошли.

2. ONVIF-прокси в Docker
   Нашёл на Reddit упоминание контейнера rtsp-to-onvif. Поднял его на Synology, поправил config.yaml:

   • интерфейс eth4 (10 GbE-адаптер);
   • IP и путь RTSP-потока;
   • точные width/height, взятые из вывода ffplay.

3. Добавление в Protect
   В веб-интерфейсе Protect включил «Discover 3rd-Party Cameras», увидел новое устройство, нажал Adopt, ввёл admin/admin. После донастройки камера появилась в списке.

Результат: iPhone теперь полноценная камера Protect, а Surveillance Station и Scrypted можно отключить.

• Пользователь подключил iPhone к UniFi Protect, но не раскрыл, как победил «бесконечный спиннер» и зависание видео.
• Сообщество разочаровано отсутствием деталей и подозревает, что сам автор уже не помнит, что именно помогло.
• UniFi Protect не умеет в live-аудио и детекцию людей/машин на сторонних камерах без отдельного «AI-устройства» за ≈ $200.
• Старые iPhone как 24/7-камеры критикуют за перегрев и разбухание батарей; предлагают либо удалить аккумулятор, либо купить $30–50 камеру.
• Кто-то пошутил, что фанаты UniFi — «веганы техно-мира»: всем обязательно расскажут, что у них UniFi.

Купи быстрый процессор

Современные CPU стали шокирующе быстрыми, но большинство по-прежнему используют старые мобильные чипы, теряя продуктивность.

Подписка на AI-инструменты вроде Cursor стоит $480/год, а топовый Ryzen 9 9950X — всего $500. Амортизация за 3 года = $170/год: дешевле, чем AI, и выгода очевидна.

Бенчмарки

• Корпоративный ноутбук 2024 (i7-1165G7, 2020 г.)
• Лучший ThinkPad 2024 (Ryzen 7840U)
• Десктоп 2025 (Ryzen 9950X)

Разница — >10× на компиляции ядра Linux и TLS-операциях. 3 с против 30 с или 300 мс — это кардинально меняет опыт.

Правило:

• Десктоп ≈ 3× быстрее ноутбука
• Топ-CPU 2025 ≈ 3× быстрее топа 2022
• Новые облачные VM тоже 2-3× быстрее за ту же цену

Если вы оправдываете AI-подписку, оправдайте и лучший инструмент — быстрый CPU.

• Почти все согласны: «быстрый процессор = меньше ожидания компиляции → выше продуктивность», и ROI для старших разработчиков окупается за недели.
• Но выгода сильно зависит от задач: многие уже компилят в облаке/сервере, а фронтенд-сборки всё равно тормозят из-за однопоточных инструментов.
• Некоторые 10-летние CPU (i7-4770, Phenom II) всё ещё «достаточно быстры», если добавить RAM и SSD; апгрейд не всегда оправдан.
• Ноутбуки ограничены теплопакетом: «топ-чип в лэптопе ≠ тот же чип в десктопе».
• Итог: берите максимально быстрый десктоп, если компилируете локально; если работаете в облаке — экономьте деньги и нервы.

Как замедлить, чтобы ускорить

Синхронный спрос — когда множество клиентов действуют одновременно.
Пропускная способность μ, фоновая нагрузка λ₀, запас H = μ − λ₀.
M клиентов, синхронизированных по крону, кэшу или перезапуску, превышают H, образуют очереди, таймауты, ретраи и инцидент.
Цель — размазать пик или безопасно его слить, сохраняя справедливость и лимиты.

Источники выравнивания:

• естественные — часы, TTL, SDK-таймеры;
• индуцированные — деплой, рестарт, сброс кэша, обновление токенов;
• внешние — DDoS, флеш-крауд.

Ограничения:

• мягкие — задержка в очереди;
• жёсткие — пулы соединений, дескрипторы, потоки.
  Превышение даёт обрыв: ещё одно соединение → таймаут → ретраи → ещё больше нагрузки.
  Важно, кто ждёт: онлайн-запросы требуют справедливости, офлайн — только пропускной способности.

Математика размагничивания
M действий равномерно в окне [0, W]:
ожидаемый пик M/W, средняя задержка W/2, произведение M/2 — константа.
Чем шире W, тем ниже пик, но выше средняя задержка.

Для выпуклой функции стоимости C(r) равномерное r(t)=M/W минимизирует ∫C(r)dt (неравенство Йенсена).
Равномерный джиттер оптимален и справедлив.

Практика

1. Детерминированные границы:

   • M/W ≤ H ⇒ W ≥ M/H;
   • (M/W)·s ≤ K ⇒ W ≥ Ms/K (s — p95 времени обработки, K — свободная конкурентность).

2. Вероятностные границы:
   Пусть N ~ Poisson(M/W). Требуем Pr{N > H} ≤ ε.
   Для H ≳ 50 нормальное приближение даёт
   λε ≈ ((-z₁₋ε + √(z₁₋ε² + 4(H+0.5)))/2)²,
   W ≥ M/λε.
   Для малых H или ε считать точный хвост Пуассона.

3. Подсказки от сервера:

   • Retry-After: Δ → джиттер в [Δ, Δ+W];
   • rate-limit: R оставшихся запросов до сброса через Δ → λadm = min(H, R/Δ) → W ≥ M/λadm.

4. Продуктовые ограничения:

   • дедлайн D ⇒ W ≤ D;
   • p95 добавленной задержки ≤ L ⇒ W ≤ L/0.95.

Минимально-ожидающая политика
Выбрать наименьший W, удовлетворяющий всем нижним границам и не превосходящий верхние.
Если невозможно — добавить мощность или ослабить ограничения.

• Участники обсуждают парадоксы, при которых «ускорение» ведёт к замедлению: парадокс Браесса, парадокс Джевонса.
• Подчёркивается мысль «slow is smooth, and smooth is fast»: медленные, точные действия итогом быстрее и эффективнее, будь то код, строительство или музыка.
• Пример Facebook: задержки и очереди используются как ресурс — задачи выполняются ближе к максимально допустимому времени отклика, повышая общую пропускную способность.
• Упоминаются практические техники регулировки скорости: nanosleep по объёму данных, параметризуемые «тормоза» в долгих процессах.
• Итог: оптимизация — это не просто «делать быстрее», а баланс скорости, точности и использования ограниченных ресурсов.

Omarchy — мой новый проект: готовая, «моя» версия Arch + Hyprland. Устанавливаешь — получаешь то, что я использую каждый день.

Hyprland красив, но «из коробки» пуст: нет даже экрана блокировки. Omarchy решает это: красивые конфиги и нужный софт уже на месте.

Это не замена Omakub (Ubuntu), а продвинутый путь для тех, кому Arch ближе.

Linux на десктопе? Valve, Steam Deck, креаторы вроде PewDiePie и проекты вроде Hyprland делают его всё более заманчивым.

• Вышел Omarchy 2.0 — готовый Arch-ISO с Hyprland, ставится за ~5 минут.
• Большинство обсуждают Hyprland: кто-то в восторге от тайлинга и «веселья» Linux, кто-то считает слишком «голым» и сложным.
• Часть пользователей предпочитает плавующие окна или другие WM; другие перешли с macOS на Fedora/Gnome.
• Упоминаются альтернативы: NixOS, Bluefin, Omakub, Zorin, Rectangle/AeroSpace на macOS.
• Некоторые критикуют Hyprland за конфликты в сообществе и «токсичность», но число пользователей растёт.

Как собрать код-агента: бесплатный воркшоп

Материалы и исходники: GitHub

Суть

• Агент — это 300 строк кода, работающие в цикле, которому просто подаются токены LLM.
• Поняв принцип, вы перестанете быть потребителем ИИ и станете его продюсером, автоматизируя свою работу.

Зачем

• В 2025 г. знание, как создать агента, стало фундаментальным навыком, как понимание primary key.
• Работодатели ищут тех, кто может оркестрировать ИИ внутри компании.
• Во время Zoom-звонка ваш агент может уже писать код, который вы только обсуждаете.

Что будет на воркшопе

• Live-сборка агента прямо во время доклада.
• Объяснение внутреннего устройства: цикл, токены, промпты.
• Практика: агент строит агента под диктовку.

Дальше

• Если хотите, чтобы я провёл такой воркшоп у вас в компании — пишите.

• Команда Princeton SWE-bench выложила компактный (~100 строк) агент для SWE-bench.
• Пользователи жалуются на перегруженный AI-слайд-стиль и избыточные картинки, которые мешают чтению.
• Спор о необходимости отдельных инструментов: многие действия можно делать через bash, но специализированные утилиты экономят токены и повышают надёжность.
• Обсуждают, что «токены = деньги» и что локальные модели могут изменить ситуацию.
• Критика: пост показывает лишь базовый подход, не раскрывая продвинутые темы (sandbox, snapshot, prompt-инженерия).

port-kill — лёгкий монитор портов для macOS в строке меню.
Показывает занятые порты, позволяет одним кликом освободить нужный.

• Пользователи спорят, почему выбран диапазон портов 2000-6000 вместо привычных 8xxx.
• Многие делятся консольными скриптами (killport, whoseport) и альтернативами вроде Raycast-расширения.
• Критика: README перегружен, не объясняет «зачем» нужен монитор портов в трее.
• Подозрение, что проект сгенерирован ИИ: многословный текст, ASCII-дерево структуры, отсутствие скриншотов.
• Автор отвечает: «сделал для себя, бизнес-кейса нет».