Hacker News Digest

Обновлено: 22 августа 2025 г. в 04:35

Постов: 773 • Страница 51/78

Tor: How a military project became a lifeline for privacy (thereader.mitpress.mit.edu) 🔥 Горячее 💬 Длинная дискуссия

Как военный проект стал щитом приватности

На скрипучем поезде в тумане я пытаюсь зайти на сайт, но Wi-Fi блокирует его. Запускаю Tor Browser — страница открывается мгновенно.

Tor, или «тёмная сеть», ассоциируется с криминалом, но финансируется частично правительством США, а BBC и Facebook ведут в нём «зеркала» для обхода цензуры. Суть: трафик шифруется и прыгает по серверам мира, скрывая пользователя и обходя блокировки.

От криптовойн до Tor

90-е: хакеры-циферпанки вооружают гражданских военным шифрованием, предупреждая, что интернет может стать тоталитарным. Бизнес и Пентагон поддерживают: свободный поток данных = рыночная победа.

В исследовательской лаборатории ВМС США (NRL) инженеры ищут способ скрыть IP подлодок. Их решение — луковая маршрутизация — ложится в основу Tor.

Двойная игра государства

Сегодня одни ведомства финансируют Tor, другие требуют «задних дверей». Технологии, рождённые для шпионажа, стали инструментом сопротивления цензуре и массовой слежке.

by anarbadalov • 08 августа 2025 г. в 15:45 • 375 points

ОригиналHN

#tor#privacy#encryption#vpn#proxy#censorship#military#networking

Комментарии (179)

  • @neilv использовал Tor для скрытого мониторинга международной торговой площадки, выбирая выходные узлы под нужные регионы.
  • @palsecam и @jmclnx рассказали, что запускать ретранслятор или bridge дёшево (VPS за $5) и безопасно, помогая обходить цензуру.
  • Некоторые считают Tor «мертвым» или скомпрометированным; другие советуют прятаться в толпе, использовать VPN, residential-прокси или переходить на i2p.
  • Книга «Tor: From the Dark Web to Your Browser» доступна бесплатно от MIT Press и получила положительные отзывы.
  • Основные советы по безопасности: брать Tails на флешке, не ставить расширений в Tor Browser, не логиниться личными данными.

GPT-5 vs. Sonnet: Complex Agentic Coding (elite-ai-assisted-coding.dev)

Задача: перенести TypeScript-утилиту Ruler на Rust, проверить идентичность через bash-тест.
Модели: GPT-5 (новый, превью) и Claude 4 Sonnet.

GPT-5

  • Сразу прочитал код, составил подробный plan.md, получил одобрение.
  • Работал почти без остановок, дважды отчитывался о статусе.
  • Сначала написал bash-скрипт, который запускает оригинал и порт во временной папке и сравнивает вывод.
  • Затем сгенерировал структуру src/, Cargo.toml, CLI-аргументы, логику apply/init/revert, обработку конфигов и MCP.
  • Итеративно правил код, пока тест не прошёл «зелёным».
  • Время: ~20 мин, 1 коммит, ветка feat/rust-port.

Claude 4 Sonnet

  • Та же инструкция.
  • Сразу начал писать Rust, но упустил bash-тест; пришлось напомнить.
  • Тест написал быстрее, но менее читаемый.
  • Порт делал «пачками»: сначала CLI, потом логика, потом MCP.
  • После 3-х итераций тест прошёл.
  • Время: ~30 мин, 3 коммита.

Вывод

  • GPT-5 агентнее: сам планирует, реже спрашивает, меньше ошибок.
  • Claude надёжнее в деталях, но требует чётких шагов.
  • Оба справились, но GPT-5 ощущается «ближе к одной команде — один результат».

by intellectronica • 08 августа 2025 г. в 15:38 • 155 points

ОригиналHN

#typescript#rust#bash#gpt-5#claude-4-sonnet#ai-assisted-coding#code-refactoring#testing#tdd#llm

Комментарии (124)

  • Пользователи сомневаются в объективности сравнений: результаты сильно зависят от системных промптов, харнесов и задач.
  • Критика выбора моделей: вместо топ-версии Claude Opus сравнивали более дешёвый Sonnet, что искажает оценку «лучшей» модели.
  • Стоимость vs качество: большинство разработчиков не готовы платить 10× за Opus, поэтому GPT-5 рассматривают как «cost-effective» вариант.
  • Опыт в продакшене: многие находят Claude Code (Sonnet/Opus) надёжнее при работе с большими кодовыми базами и TDD, тогда как GPT-5 хорош для разовых скриптов.
  • Нет единой метрики: из-за недетерминированности моделей и субъективных критериев «хорошего кода» каждый получает разные результаты.

Why tail-recursive functions are loops (kmicinski.com)

Хвостовая рекурсия превращает рекурсию в цикл: компилятор заменяет вызов на безусловный jmp, поэтому стек не растёт.

Обычная рекурсия кладёт промежуточные значения в стек, тратит O(n) памяти и вытесняет кэш.
Цикл же держит результат в аккумуляторе, использует O(1) памяти и линейное время.

Ключевое правило хвостовой рекурсии:
вызов должен быть последним выражением функции. Тогда компилятор может выбросить текущий фрейм и передать управление напрямую.

Пример суммы списка

Обычная версия:

(define (sum l)
  (if (empty? l) 0
      (+ (first l) (sum (rest l)))))

Хвостовая версия:

(define (sum l acc)
  (if (empty? l) acc
      (sum (rest l) (+ acc (first l)))))

Аргументы l и acc перезаписываются «на месте», как переменные цикла.

Упражнение 1 — счётчик чётных/нечётных:

(define (even-odd l [e 0] [o 0])
  (if (empty? l) (cons e o)
      (let ([x (first l)])
        (if (even? x)
            (even-odd (rest l) (add1 e) o)
            (even-odd (rest l) e (add1 o))))))

Упражнение 2 — сглаживание дерева:
используйте аккумулятор-список и обход в обратном порядке, чтобы сохранить хвостовой вызов.

by speckx • 08 августа 2025 г. в 15:10 • 115 points

ОригиналHN

#recursion#tail-call-optimization#racket#functional-programming#algorithms

Комментарии (121)

  • Теоретически хвостовая рекурсия и циклы эквивалентны: любую хвостовую рекурсию можно превратить в цикл (и наоборот), но взаимно-рекурсивные функции требуют дополнительной работы.
  • На практике циклы чаще проще для чтения и не ломают стек, тогда как хвостовая рекурсия нуждается в оптимизации (TCO), которую не все языки поддерживают (Python, V8 её нет).
  • Некоторые языки (Scala, Clojure, F#) дают компромиссные конструкции (@tailrec, recur), сохраняющие функциональный стиль и гарантирующие отсутствие переполнения стека.
  • Вместо явной хвостовой рекурсии часто достаточно высокоуровневых комбинаторов вроде fold/map, но они не всегда позволяют досрочный выход и могут расходовать O(N) памяти.
  • Участники сходятся во мнении: владеть обоими подходами полезно, выбор зависит от языка, задачи и привычек команды.

AI must RTFM: Why tech writers are becoming context curators (passo.uno)

Разработчики всё чаще пишут документацию в специальных «контекст-папках», чтобы ИИ мог самостоятельно и точно решать задачи. Это docs-driven development: кодят меньше, пишут больше, потому что ИИ теперь обязан «RTFM».

Качество ответа LLM прямо зависит от качества входных данных. Чем больше контекстное окно, тем больше релевантной информации можно подать. Поэтому инженеры учатся писать структурированные инструкции и создавать целые библиотеки контекста.

Контент-куратор — это технический писатель, который строит стратегию знаний и для людей, и для ИИ. Контекст важнее «контента»: он ограничен, релевантен и придаёт смысл. Писатели должны владеть процессами AI-документации, включая подготовку контекста (docs-as-data).

Четыре года назад я утверждал, что писатели влияют на дизайн API словами. Теперь это распространилось на всю разработку: мы можем «вызывать» программы текстом. Большинство команд уже отдают llms.txt и Markdown для ИИ, но следующий шаг — упаковывать контекст в удобные для LLM форматы (возможно, на базе DITA). Цель — сделать знания доступными и человеку, и машине.

by theletterf • 08 августа 2025 г. в 15:04 • 124 points

ОригиналHN

#llm#documentation#api#context

Комментарии (64)

  • AI заставляет писать больше документации — скучно, но полезно и исключает оправдания прокрастинации.
  • LLM плохо справляются с новыми/обновлёнными API, часто предлагают устаревший код, если явно не указать «смотри свежие доки».
  • Чтобы LLM был полезен, нужно самому понимать задачу и давать точный контекст; иначе результат неточен.
  • Некоторые компании уже отдают приоритет AI-читабельным форматам (llms.txt, claude.md), но это пока редкость, а не норма.
  • Хорошая документация полезна людям вне зависимости от ИИ; если ИИ подталкивает улучшать её, это плюс.

AI is impressive because we've failed at personal computing (rakhim.exotext.com) 💬 Длинная дискуссия

Современные ИИ-чаты умеют отвечать на сложные вопросы, потому что мы так и не научились структурировать информацию. Пример: «Какое животное изображено на флаге страны, где первая британская колония появилась в год, когда Швеция объявила войну Франции?» — ChatGPT за секунды выдал «попугай сиссеро на флаге Доминики, колония 1805 г.», а Google AI-виджет провалился.

Такой «поисковый» паттерн повсюду: Google Drive — облачная папка, которую легче искать, чем упорядочивать; сайты вместо структуры набиты ключевыми словами; документацию заменяют чат-боты.

Семантический веб, где данные должны были быть машиночитаемыми и связанными, так и не случился: вместо структурированного HTML — динамические div-ы без метаданных. Личные компьютеры не стали персональными базами знаний с семантическими связями, как мечтал ХайперКард.

Если бы знания хранились структурированно, ответ нашёл бы простой алгоритм без миллиардов параметров. ИИ — не триумф элегантного дизайна, а грубое решение: он выстраивает мимолётную семантику из хаоса, но само знание остаётся недоступным и непрозрачным.

by ambigious7777 • 08 августа 2025 г. в 14:57 • 184 points

ОригиналHN

#llm#google#semantic-web#knowledge-graph#html

Комментарии (155)

  • Участники сравнивают идею «всё структурировать» с утопией «если бы все просто были хорошими людьми» – красивая теория, но нереалистична.
  • Напоминают, что Semantic Web, Knowledge Graph и Cyc пытались кодировать знания вручную, но масштабировались плохо: люди не умеют быстро и точно описывать мир.
  • Отмечают, что современные ИИ-модели стали «пластырем», который сам строит семантические связи из хаотичных данных, хотя и с ошибками.
  • Подчёркивают: поисковики и LLM дополняют друг друга; ни один не решает всё, но вместе дают результат.
  • Главный вывод: неудача не в «плохих людях», а в сложности мира и в том, что рутинная работа по разметке никому не принадлежит и никем не финансируется.

Google's Genie is more impressive than GPT5 (theahura.substack.com)

AGI стремится к универсальности, но нельзя просто import everything. Решение — компрессия и обобщение: небольшая модель покрывает огромное пространство задач. Глубокое обучение сжимает терабайты данных в десятки гигабайтов весов, и LLM не только имитируют текст, но и умеют, например, играть в шахматы без явного обучения.

Следующий шаг — world-models, способные представлять не только текст и картинки, но и всю окружающую реальность. Такая модель могла бы «смоделировать Тибет» и сообщить погоду, а робот — планировать движения, опираясь на внутреннюю симуляцию мира. Проблема в колоссальном объёме видеоданных и вычислений, поэтому мало кто рискует.

Google DeepMind рискнул: три дня назад представил Genie 3 (Generative Interactive Environments). Если GPT создаёт текст, Veo и Sora — видео, то Genie превращает описание в интерактивную видеоигру, где можно бродить минутами. Пока коротко, но это качественный скачок и намёк на будущее, где модели будут поддерживать длинную когерентность не только в тексте, но и в «живых» мирах.

by theahura • 08 августа 2025 г. в 14:46 • 177 points

ОригиналHN

#agi#google-deepmind#genie#llm#world-models#deep-learning#machine-learning#google

Комментарии (58)

  • Пользователи высмеяли идею «стимулировать Тибет» вместо обычного запроса погоды.
  • Рынки ставок и графики вызвали споры: одни видят рост ожиданий Gemini-3, другие указывают, что Gemini 2.5 уже выше GPT-5 в бенчмарке.
  • Многие считают статью пустой и отказываются верить демо, пока Genie 3 не станет публично доступен.
  • Обсуждение свелось к тому, что ни GPT-5, ни Gemini пока не близки к AGI, а термин «AGI» постоянно меняется под маркетинг.

Astronomy Photographer of the Year 2025 shortlist (rmg.co.uk)

Сокращённый перевод на русский

Короткий список конкурса «Астрономический фотограф года 2025» (ZWO) уже опубликован. На сайте Royal Museums Greenwich представлены отобранные работы, но полный список фотографий и авторов в предоставленном фрагменте не указан.

by speckx • 08 августа 2025 г. в 14:29 • 234 points

ОригиналHN

#hdr#llm#raw

Комментарии (36)

  • Участники восторгаются красотой снимков, но обсуждают, насколько они «настоящие».
  • Норвежец и другие отмечают, что северное сияние и другие объекты на фото выглядят ярче, чем вживую из-за длинной выдержки, HDR и прочей обработки.
  • Спорят о композитах: кто-то считает их обманом, кто-то — способом показать невидимое глазу.
  • Подозревают AI-генерацию, но организаторы требуют RAW-файлы и описание обработки, чтобы проверить подлинность.
  • Уточняют, что «солнечные вспышки» снимают через H-alpha-фильтр, а геометричные постройки на одном кадре — реальные скульптуры в Китае.

Getting good results from Claude Code (dzombak.com) 🔥 Горячее 💬 Длинная дискуссия

  • Чёткое ТЗ — пишу заранее, чтобы агент видел контекст.
  • Файл-инструкция по запуску линтервов и сборки.
  • Саморевью — прошу Claude проверить свой код.
  • Глобальный гайд ~/.claude/CLAUDE.md с правилами: мелкие шаги, TDD, простые решения, максимум 3 попытки при ошибке.

Качество
Я вручную читаю и тестирую всё, что выходит из LLM; отвечаю за PR независимо от автора кода.

by ingve • 08 августа 2025 г. в 13:45 • 439 points

ОригиналHN

#tdd#code-review#legacy-code#testing#documentation#llm

Комментарии (180)

  • Ключ к успеху — писать подробные спецификации: кто-то тратит 2 часа на 12-шаговый документ и получает отличный результат, другие же считают, что даже «чистые» спеки не спасают от схода с курса и бесконечных правок.
  • Мнения о CLAUDE.md разделились: одни держат файл коротким (<100 строк) и минималистичным, другие вообще не видят в нём пользы из-за «context rot» и субъективных инструкций.
  • Работа с большими старыми кодовыми базами по-прежнему сложна: большинство признаёт, что Claude Code лучше справляется с новыми pet-project’ами, чем с «грязными» legacy-фичами.
  • Популярные тактики: шаг-за-шагом микро-PR, TDD-агент, запуск puppeteer-тестов для «замыкания цикла», code-review собственных патчей самим агентом.
  • Некоторые вообще отказались от спецификаций: инкрементально подсказывают «следующий шаг, какой сделал бы я», сразу коммитят дифф и правят на лету.

How we replaced Elasticsearch and MongoDB with Rust and RocksDB (radar.com) 🔥 Горячее

HorizonDB — новая гео-БД на Rust, заменившая Elasticsearch и MongoDB.
Обрабатывает 1 млрд вызовов/день, 1 000 QPS на ядро, 50 мс прямого и <1 мс обратного геокодирования.

Проблемы старого стека

  • Elasticsearch: шардирование, дорогие батчи, отсутствие отката.
  • MongoDB: нет нормального bulk-импорта, переподбор ресурсов, сложный откат.

Архитектура HorizonDB

  • Однопроцессный многопоточный бинарник.
  • Данные Spark → S3 → RocksDB (версионные ассеты).
  • Индексы: S2 (гео), Tantivy (поиск), FST (префиксы), LightGBM/FastText (ML-ранжирование).

Почему Rust

  • Скомпилирован, без GC, предсказуемая латентность.
  • Абстракции высокого уровня, pattern matching.
  • Один процесс вместо Node.js-кластера → экономия памяти.

Ключевые компоненты

  • RocksDB — быстрая запись/чтение с SSD.
  • S2 — O(1) point-in-polygon через квадродерево.
  • FST — компрессия префиксов, кэш «happy path» в МБ.
  • Tantivy — встроенный инвертированный индекс, избегаем сетевого Elasticsearch.

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

by j_kao • 08 августа 2025 г. в 12:57 • 258 points

ОригиналHN

#rust#rocksdb#mongodb#elasticsearch#s2#tantivy#lightgbm#fasttext

Комментарии (84)

  • Пост вызывает много вопросов: детали шардирования, отказоустойчивость, latency и open-source-статус не раскрыты.
  • Альтернативы: Typesense, DuckDB+spatial, Quickwit/Tantivy — всё open-source и уже показывает высокую производительность.
  • RocksDB хвалят за надёжность и производительность, но кто-то вспоминает старые проблемы LevelDB.
  • LMDB/OSM Express тоже предлагают более лёгкое решение для геопоиска.
  • Многие считают, что 95 % задач решаются обычным Postgres/SQLite, а «заменить ES» сейчас модный лозунг.

Modos Paper Monitor – Open-hardware e-paper monitor and dev kit (crowdsupply.com) 🔥 Горячее

Modos Paper Monitor — открытый e-paper монитор 75 Гц и dev-kit.
Собрано $61 611 из $110 000, 37 дней до конца кампании.

В комплекте

  • Плата на FPGA (Caster, 60 Гц, открытая прошивка).
  • 6" и 13" монохромные панели; контроллер подходит и к другим экранам 6–13,3".
  • HDMI/USB, Linux/macOS/Windows.
  • Корпус-чертежи и ПО на GitHub.

Почему это важно

  • Закрытые драйверы и высокие цены тормозят e-paper.
  • Мы даём инженерам и энтузиастам свободу экспериментировать и формировать стандарты (Discord, Mastodon, Matrix, Bluesky).

Возможности

  • Низкая задержка: независимые области обновления, отмена прежних пикселей.
  • Гибкие режимы: бинарный для скорости + гибридный серый для деталей.
  • C API: полный контроль режимов и обновлений.

Цены

$199–$599, 6 вариантов комплектации.

GitHub-список совместимых экранов

by RossBencina • 08 августа 2025 г. в 12:38 • 303 points

ОригиналHN

#fpga#hdmi#usb#linux#macos#windows#verilog#c#gitlab#git

Комментарии (72)

  • Проект Glider — полностью открытый: исходники, Verilog, документация и файлы платы на GitHub/GitLab.
  • NLnet и ЕС профинансировали разработку; обсуждаются условия грантов и гражданство авторов.
  • Контроллер на низкобюджетном FPGA выдаёт HDMI/USB-C, но пока не предлагает LVDS/eDP для моддинга ноутбуков.
  • Демо показывает высокую скорость обновления при заметном «ghosting»; блики — особенность дешёвой панели, не самой платы.
  • Участники хотят 21–24″ монохромный 30 Гц дисплей дешевле $500, сенсорный слой и драйверы X11/Wayland.
  • Упомянуты альтернативы: Inkplate, TRMNL, Boox, а также DIY-кибердеки и ноутбуки ThinkPad T480 с e-ink.