Hacker News Digest

Стратегии

• Химия прежде всего
  ADHD — биологическая проблема; стимуляторы — первое, что работает. Всё остальное дополняет лекарства, а не заменяет их. Если один препарат не подошёл, пробуйте другие, не мучайтесь «силой воли».

• Память
  Todo-лист = внешняя память. Всё, что не записано, исчезнет. Используйте любой удобный инструмент и держите его синхронизированным.

• Энергия
  Сон, еда, движение. Дефицит любого из них убивает фокус быстрее ADHD. Мелатонин в 20:00 превращает «лечь спать» из подвига в естественное желание.

• Прокрастинация
  Разделите «выбор задачи» и «выполнение». Сначала план, потом действие. Планируйте вечером, когда мозг свежий; выполняйте утром, когда решение уже принято.

• Интроспекция
  Ведите журнал: что помогает фокусу, что мешает. Ищите паттерны, корректируйте среду и привычки.

• Время
  Календарь должен быть единым и безжалостным: встречи, дорога, обед — всё в нём. Повторяющиеся события автоматизируют рутину.

Тактики (хитрости)

• Выбор задачи
  Делайте список «три важных» на день. Остальное — бонус.

• Визуальное поле
  На столе только то, что нужно прямо сейчас. Всё остальное убирается.

• Чек-ин проектов
  Каждое утро 5 минут: что двигаю, что заблокировано, что следующий шаг.

• Централизованные входящие
  Все уведомления, почта, мессенджеры — в один «инбокс». Остальные каналы отключены.

• Inbox Zero / Bankruptcy
  Либо обрабатывайте каждое сообщение до конца, либо раз в месяц нажимайте «отметить всё прочитанным» и начинайте с чистого листа.

• Работайте на своих условиях
  Если нужна музыка, шум, стоячий стол — сделайте так. Не геройствуйте в чужой системе.

• Опрос вместо прерываний
  Отключите push-уведомления; проверяйте почту по расписанию.

• Напарник по ответственности
  5-минутный звонок «что сделал за день» повышает вероятность выполнения в 2-3 раза.

• Используйте OCD против ADHD
  Создайте ритуалы: одна и та же музыка при запуске работы, один и тот же напиток. Мозг быстро привязывает ритуал к фокусу.

• Мастер рутины
  Самую скучную задачу делайте в одно и то же время; превратите её в автоматизм.

• Дорога в календаре
  Время в пути = событие. Это убивает опоздания и нереалистичное планирование.

• Инструменты
  Не ищите идеальное приложение. Выберите одно, настройте и живите с ним минимум месяц.

Ресурсы

• Книги: Driven to Distraction, Taking Charge of Adult ADHD.
• Подкасты: «ADHD Experts», «Translating ADHD».
• Сообщества: r/ADHD, ADHDAlien, HowToADHD (YouTube).

Итог
Медикаменты открывают дверь, системы удерживают её открытой. Пробуйте, записывайте, корректируйте.

• Основной вывод: стимуляторы остаются первой линией терапии ADHD; все остальные стратегии работают лишь как дополнение.
• Пользователи делятся лайфхаками: добавляйте выполненные задачи в TODO, чтобы потом отметить и получить дофамин; ведите «Captain’s Log» для быстрого возвращения в контекст.
• Часть людей не переносит стимуляторы: ищут альтернативы (atomoxetine, modafinil, bupropion) или полагаются на mindfulness, глицин, CBD-weed.
• Диагностика и получение рецепта — узкое место: длинные очереди в NHS, сложности с бумагами, страх «не той» диагностики.
• Подчеркивают важность проверки щитовидной железы и упоминают о PDA/RSD как возможных причинах прокрастинации, которые статья обошла.

• YouTube
  О платформе • Пресс-центр • Авторское право • Связаться • Авторам • Реклама • Разработчикам • Условия • Конфиденциальность • Правила и безопасность • Как работает YouTube • Тест новых функций • NFL Sunday Ticket

© 2025 Google LLC

• Google усиливает блокировку установки сторонних APK (ReVanced, F-Droid), что вызывает раздражение и разговоры о переходе на iPhone или «думфоны».
• Участники предлагают радикальные меры: отмену DMCA, антимонопольные разбирательства, законодательное право на перепрошивку и ремонт.
• Многие рассматривают альтернативы — LineageOS, GrapheneOS, HarmonyOS, Linux-телефоны (FLX1, Jolla) или удалённый рабочий стол.
• Сообщество фиксирует тренд «компьютер в кармане превращается в закрытую игровую приставку» и обсуждает, как долго ещё можно пользоваться старыми Galaxy без обновлений.

Зачем «перефразировать телеграмму»?

Во Второй мировой на американских телеграммах встречается пометка:
«This telegram must be closely paraphrased before being communicated to anyone».

Смысл не в «размывании» содержания, а в криптографической безопасности.
Если дословно цитировать текст, противник, перехвативший шифр-телеграмму, получает известный открытый текст («crib»). Сравнивая его с шифртекстом, криптоаналитикам легче подобрать ключ.

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

Инструкция появилась в 1939 г. и касалась всех зашифрованных сообщений, особенно дипломатических.

• Британцы использовали «саженые» открытые тексты в карманах погибших немцев для known-plaintext атак на Enigma.
• Повтор одних и тех же фраз («weather…», «Heil Hitler») и «сообщения в глубину» (in depth) позволяли взламывать и Enigma, и более сложный Lorenz/Tunny.
• Ключевое правило: нельзя повторять один и тот же текст ни в открытом, ни в зашифрованном виде; при перефразе лучше сокращать, чем расширять.
• Современные шифры устойчивы к таким атакам благодаря IV, CBC и другим приёмам; изучать старые методы помогают военные руководства и книги вроде «Between Silk and Cyanide».

Почему квантовые компьютеры всё ещё не разложили 21 на множители?

В 2001 году удалось разложить 15, но к 2025-му 21 остаётся «недоступным». Это не из-за отсутствия прогресса, а из-за взрывного роста сложности схемы.

• Схема для 15 требует всего 21 запутывающий двух-кубитный гейт (6 CNOT/CPHASE + 2 Toffoli, каждый из которых эквивалентен 6 CNOT).
• Схема для 21 содержит 191 CNOT и 369 Toffoli, то есть ≈ 2405 запутывающих гейтов — в 115 раз больше.

Три причины такой разницы:

1. Большинство констант при 15 равны 1, поэтому умножения «пропускаются».
2. Первое умножение почти бесплатно, так как аккумулятор известен.
3. Оставшееся умножение на 4 по модулю 15 сводится к двум CSWAP.

Для 21 все восемь умножений нужны, и каждое требует полноценного модульного умножения. Даже после агрессивной оптимизации схема остаётся на два порядка дороже.

• Квантовые компьютеры пока не факторизуют даже 21 без «подсказок»; эксперименты с 15 обошлись лишь потому, что задача свелась к сдвигам.
• Для RSA-2048 оценивается ≈ 7 млрд Toffoli-гейтов и миллионы логических кубитов с коррекцией ошибок; RSA-1024 всё ещё вне досягаемости.
• Реальные препятствия — экспоненциальный рост шума и количества физических кубитов, а не просто масштабирование схемы.
• Основной практический путь — квантовая химия и симуляция, а не взлом криптографии; «пост-квантовые» алгоритмы уже снижают мотивацию строить «крипто-разрушители».
• Общий вывод: полезные квантовые вычисления в XXI веке возможны, но факторизация крупных RSA-ключей остаётся гипотетической.

Телефон стал ридером

С 2016-го читаю на Kobo, но у него проблемы: книги из библиотеки не всегда открываются, синхронизация статей через Pocket требует предварительных действий, а сам сервис теперь закрыт. Партнёр читает на смартфоне, но мне мешает подсветка и соблазн переключиться на что-то другое.

Узнал о Minimal Phone — Android-телефоне с электронной бумагой. Заказал как подарок себе: размер почти как Pixel 8, внизу физическая клавиатура, сверху 6-дюймовый e-ink. Под капотом чистый Android, можно выбрать лаунчер. Сбоку кнопка: короткое нажатие убирает «ghosting», долгое — вызывает быстрые настройки дисплея и подсветки.

Главный параметр — режим обновления. «Медленный» даёт полутона и минимум шлейфов, но экран мерцает. «Быстрый» (всё равно не 60 Гц) рисует только чёрное-белое, мерцания почти нет. «Гибрид» переключается сам: движение — быстрый, статика — медленный. Им и пользуюсь.

Клавиатура приятная, но…

• Пользователи обсуждают «Minimal Phone» с e-ink и физической клавиатурой: кто-то хвалит за снижение зависимости от скроллинга, кто-то ругает за баги, цену ($399–499) и неудобную клавиатуру.
• Основные претензии: теряются нажатия, медленный Google Maps, нет нормальной камеры, сложности с WhatsApp/банками, отсутствие кнопок листания.
• Часть аудитории ищет альтернативы (Boox Palma, старый Kindle, просто ч/б-режим на iPhone) или предлагает «самоограничение» вместо нового устройства.
• Некоторые мечтают о e-ink-ноутбуке или модульном экране, другие сомневаются в надёжности компании-производителя.

Magic Lantern 2025: Midsummer Edition
21 июня 2025

Возвращение официальных сборок

• Регулярные релизы для всех камер
• Проверенные билды на сайте, а не в форуме
• Баги исправляются
• Поддержка новых моделей расширяется

Что изменилось
После ухода a1ex в 2020 остались фрагментарные доки и нерабочая система сборки. Несколько волонтёров восстановили проект:

• обновили сайт и репозиторий;
• перешли на Git, современные ОС и инструменты;
• код стал чище, быстрее, компактнее;
• добавлена поддержка Digic 6/7.

Новая команда
g3gg0, kitor, names_are_hard, WalterSchulz.
Lead-dev: names_are_hard.

Новые камеры

• 200D / Kiss X9 / Rebel SL2
• 6D Mark II
• 750D / Rebel T6i / Kiss X8i
• 7D Mark II

Хотите помочь? Нужны разработчики C.

• Magic Lantern возвращается: это бесплатная надстройка, расширяющая возможности старых и новых Canon-ов за счёт реверса прошивки.
• Проект перешёл на Git, современный тулинг и чистую сборку без варнингов, что упрощает вход новым разработчикам.
• Нужен C и желание покопаться в «железе»; камеры стоимостью <$100 подходят, сообщество приглашает помогать.
• Пользователи вспоминают RAW-видео, таймлапсы, HDR-скрипты и другие «фичи», которых нет в штатной прошивке.
• Нет поддержки новых Sony/Nikon/Fujifilm, но многие мечтают о таких же проектах для других марок.

• Fediverse (Mastodon, Pixelfed и др.): серверы разделены на «крупнейший» и «остальные» в процентах.
• Atmosphere (Bluesky, WhiteWind и др.): аналогичное деление.

Данные обновляются регулярно.
Концентрация измеряется индексом Херфиндаля-Хиршмана (HHI):

• 0 ≈ полная децентрализация,
• 10 000 ≈ монополия.
  В экономике: <100 — высокая конкуренция, <1500 — неконцентрировано, >2500 — высокая концентрация.

Отслеживаются активные пользователи: для Fediverse — на серверах (инстансах), для Atmosphere — на PDS (личных серверах данных).

Код и данные на GitHub. Предложения и PR приветствуются.
Автор: Rob Ricci (@ricci@discuss.systems, @ricci.io).

• Обсуждение крутилось вокруг того, насколько реально «избежать централизации» в разных сетях: Fediverse, ATProto/Bluesky, Nostr, Git, BitTorrent, SMTP, Bitcoin.
• Участники согласились, что полной децентрализации не существует: всегда появляются «точки притяжения» — GitHub, крупные инстансы Mastodon, Coinbase, трекеры.
• Сравнивали HHI-метрику: Mastodon выглядит менее сконцентрированным, но уступает по числу пользователей; Bluesky проще для массового пользователя, но дороже в инфраструктуре.
• Поднимали риски: спам и DDoS в открытых сетях, исчезновение мелких узлов, дефедерация, отсутствие UX-консистентности.
• Главный вывод: «децентрализация» сама по себе не цель, а баланс между устойчивостью к цензуре, удобством и экономикой узлов.

Исследование PNAS: рост продолжительности жизни в богатых странах замедляется; средняя продолжительность не достигнет 100 лет ни у одного поколения, рождённого после 1939.

• Данные: 23 страны с высоким доходом и низкой смертностью, база Human Mortality Database, шесть методов прогнозирования.
• Динамика:
  – 1900–1938: +5,5 мес за поколение (с 62 до 80 лет).
  – После 1939: +2,5–3,5 мес за поколение.
• Причина: ранние скачки объяснялись падением младенческой смертности; теперь этот резерв исчерпан.
• Выводы: даже при удвоении темпов улучшения выживаемости взрослых прирост останется ниже исторического.
• Значение: пенсии, здравоохранение, личное планирование должны учитывать более медленный рост продолжительности жизни.

• Участники спорят, замедляется ли рост продолжительности жизни или мы уже достигли предела; многие считают, что ранние приросты были за счёт снижения детской смертности.
• Обсуждаются генетика, образ жизни, отсутствие эволюционного отбора в пользу долгожительства и необходимость признать старение болезнью.
• Поднимаются опасения: качество жизни в старости, социальное неравенство, накопление власти долгоживущими, а также этический вопрос «жить дольше или лучше».
• Часть комментаторов скептически относится к обещаниям «бессмертия», видя в них веру вместо науки, и предлагают сместить фокус здравоохранения на улучшение качества жизни.

Ты должен почувствовать это

Галочки стоят: сроки, документация, демо — всё готово. Повышение близко.
Но ты не почувствовал. Не почувствовал.

Люди испытывают чувства при каждом взаимодействии: радость, раздражение, уверенность. Это чувство — часть работы. Оно должно быть в требованиях.

Когда ты чувствуешь — знаешь: функция заставляет улыбнуться, будто всегда была здесь. Хочется использовать снова и рассказать другим.

Метрики и спецификации не ловят чувство. Пользователи живут им каждый день. Поэтому недостаточно поставить галочки: нужно посидеть, попользоваться, прожить.

Ты должен почувствовать это.

• Всё сводится к чувствам: даже «рациональные» решения в итоге определяются «вайбом».
• Корпоративная машина чувств не имеет, поэтому продукты без души побеждают по метрикам, но не вызывают восторга.
• «Тест выходного дня»: если хочется ковыряться в проекте в свободное время — значит, он «чувствуется» правильно.
• Некоторые считают, что чувства можно (и нужно) анализировать, другие — что это неизмеримая эволюционная сверхспособность.
• Маленькие команды могут позволить себе «неправильные» продукты, которые не проходят корпоративные чек-листы, но вызывают любовь пользователей.

AI-модели нуждаются в виртуальной машине

Современные приложения с ИИ включают модель в «обвязку», которая обеспечивает вызов инструментов, поиск контекста, безопасность и прочие сервисы. Первые чат-боты были простым REPL-циклом: запрос → модель → ответ. С появлением протоколов вроде MCP логика управления стала сложнее и требует свойств ОС: изоляции, расширяемости, переносимости, контроля доступа к файлам и инструментам.
Мы предлагаем рассматривать этот слой как виртуальную машину для ИИ-моделей (MVM), где одна из «инструкций» — вызов LLM. Это развязывает разработку моделей от кода интеграции и даёт «write once, run anywhere» аналогично JVM.

Зачем MVM

• Безопасность и приватность «из коробки», а не как дополнение.
• Повторное использование: любая модель подключается к экосистеме инструментов и политик безопасности.
• Переносимость: модель и политики можно поставлять и запускать в разных средах.

Пример работы

1. Пользователь: «Забронируй рейс».
2. MVM передаёт запрос модели.
3. Модель: «вызови booking-tool».
4. MVM проверяет, разрешён ли этот инструмент, и только потом вызывает его.
   Такой контроль есть в любом коммерческом ИИ-продукте; MVM выносит его в стандартизированную платформу.

Инструкции MVM

• загрузка/выгрузка модели и инструментов;
• вызов модели с контекстом;
• парсинг её ответа;
• вызов разрешённых инструментов;
• работа с памятью, историей, вводом пользователя;
• стандартные управляющие конструкции (if, seq, loop).

• Критики считают, что статья расплывчата: «VM для ИИ» сводится к обычной песочнице/контейнеру, а не к полноценной машине.
• Основная проблема — не инструменты, а разрешения: нужно точно ограничить, какие действия и данные доступны агенту, иначе он может, например, купить билет с 37-часовой пересадкой ради 3 $.
• Многие предлагают использовать уже существующие механизмы: Docker, отдельный пользователь, контейнеры, WebAssembly или capability-модель вроде Fuchsia.
• Часть комментаторов указывает, что продвинутые модели (ChatGPT Code Interpreter, OpenHands) уже работают в изолированных средах, но этого всё равно недостаточно.
• Итог: вместо новой «ОС для ИИ» нужно чёткое управление правами и данными; VM лишь метафора для этой задачи.